Шина = 1 миллион долларов


#1

Значит смотрите и запомните пожалуйста.

Первое

Внедрить шину стоит 1 миллион долларов. Ровно. Любую.
Потому что шина состоит из 13 различных программок - список элементов любой шины можно наглым образом подсмотреть у wso2 https://wso2.com/platform

Второе

Если Вам говорят что это стоит не миллион долларов - кто-то хитрит. Какие возможности есть для хитрости:

  • в их шине, которую они называют шиной нет нескольких компонентов шины - поэтому она дешевле, но вам об этом не говорят
  • шина может быть бесплатной, но миллион вы все равно потратите на команду владения/внедрения - не сразу, а скорее года за три-пять. Собственно вам об этом не скажут.

Третье

Кто вообще придумал “шину” и этот термин - обычно ссылаются на Фаулера

Обратите внимание - именно у него я в свое время подсмотрел слово design для доменного имени isthisdesign (в вольном переводе “Разве это дизайн ?”)

https://martinfowler.com/design.html

но это не так - Фаулер написал книжку про “шаблоны интеграции корпоративных приложений” и очень активно двигал книжку и потом двигал продукты типа “шина”

Но понятие “шина” принято ассоциировать с ребятами из Sonic http://www.progress-tech.ru/products/sonic/mq

но вы должны знать - что теперь эти ребята с рынка шин “ушли” и теперь они называются лидерами в рынке “Мобильной платформы разработки” https://www.progress.com/campaigns/progress-named-a-leader-in-gartner-magic-quadrant-2017

Обратите внимание - господин Фаулер c 2014 года активно двигает новые концепты интеграции https://martinfowler.com/articles/microservices.html

И не прекращает:

Четвертое

есть прецеденты (я знаю трех человек) которые в одиночку могут владеть и внедрять шины, но это большое исключение из правил. В общем случае команда которая должна заниматься шиной - от 5 человек. И это обычно не 1С специалисты, а в основном Java люди.

Пятое

А что делать ?

  • во первых наши друзья зовут нас как субподрядчиков если слово шина звучит в проекте - это опять же не реклама, это напоминание для @Gleb_Stalnoy чтобы не забывал :wink:

  • во вторых - термин “шина” не использовать, использовать любые другие

  • Транспорт данных

  • Трансформатор данных

  • Движок интеграционные процессов

  • Контролер квот

и т.д - то есть четко понимать какая интеграционная задача в проекте и от неё исходить при выборе формулировок

P.S. sonicMQ - мертвый продукт, я напомню


#2

И еще - если вам делают скидку 90% от стоимости шины: смотри пункт про стоимость владения. будет все равно миллион долларов ;-). На сегодня это около 60 мегарублей.


Та самая Кафка (Apache Kafka)
#3

Сегодня опять задали вопрос про Шину для 1С. Такое впечатление что мы идем по граблям западных компаний, которые покупали “шины”, а потом оказывалось что называется ESB - шина ;-).

В порядке развития компетенций делюсь информацией:

15 компонентов правильной ESB - функции

1 API менеджер

позволяет архитектурному комитету вводить новые APi, разграничивать доступ к конкретному API, мониторить клиентов использующих API

2 API магазин

позволяет командам желающим использовать API, заказывать себе доступ, иметь витрину с документацией по API, быть подписанной на новости об API

3 Сервер бизнес процессов

позволяет архитектурному комитету выстроить последовательность вызовов систем в рамках одного бизнеса процесса, визуализировать бизнес-процесс, управлять версиями бизнес-процессов

4 Сервер правил бизнес процессов

позволяет инженерами по интеграции описать и ввести в действие - правила трансформации данных между системами создать правила маршрутизации между точками интеграционного бизнес-процесса

5 Процессор комплексных событий

позволяет инженерами по интеграции построить последовательный процесс (аналог машины Тюьринга) передачи событий между системами

6 Анализ данных

позволяет инженерами по интеграции построить сложные алгоритмы BI для поиска закономерностей внутри данных построить алгоритмы приведения в порядок “сырых данных”

7 Службы анализа данных

позволяет инженерами по интеграции создать алгоритмы обеспечивающие bulk (массовую загрузку) из файлов, таблиц SQL
преобразовать массовый объем данных в формат гранулярных событий

8 Сервер биллинга

Позволяет архитектурному комитету, оценить в денежном эквиваленте стоимость использованных ресурсов при интеграции используется для монетизации сервисов

9 Шина данных

Позволяет обеспечить выполнение интеграционного кода в рамках кластера интеграции

10 Служба регистратора

позволяет архитектурному комитету: мониторить нарушения контрактов администраторами сервисов

11 Служба публичного регистратора

позволяет администраторам сервисов мониторить нарушение контрактов интересующих их систем

12 Служба идентификации

позволяет администраторам сервисов управлять доступом к API

13 Служба ключей доступа

позволяет инженерами по интеграции организовать службу самообслуживания

14 Служба организации распределённых транзакций

позволяет организовать хранилище МАКРОтранзакции размером “вся компания”

15 Федеративный Транспорт данных

позволяет организовать доставку данных между службами и системами поверх сетевого уровня в условиях сложной топологии сети предприятия.


#4

Прокомментирую: ESB формально как концепция уже изживает себя - те кто внедряю ESB формально не понимают что они делают.

А концепция микросервисов (микрослужб) перешла в новую фазу развития

ESB для 1С кстати не существует :wink:


#5

Для тех кто придет по ссылке и дочитает до конца хотел еще одним интересным поделиться.

Почти постоянно возникает вопрос:

интеграционный код, на чем его писать ?

На сегодняшний день лучшим выбором являются - 1С (OScript), Python, JS и “Балерина” (ожидаю вопроса что это)

  • НИ в коем случае для интеграционного кода НЕ использовать чистый Java, C#, GoLang, С++ - они для другого.

#6

#7

Не иначе как диспетчер распределенных транзакций :slight_smile:


#8

Хуже. Это язык для программирования интеграций


#9

Пробовали плясать с балериной? Впечатлениями не поделитесь?


#10

Я лично не пробовал, а Леша и @nixel2007 пробовали


#11

пробовал на версии 0.9.сколькото, было не круто. Поддержка ide почти никакая, без нормального автокомплита тяжело, родной отладчик и редактор крашатся и проматывают окно с кодом, куча грамматических конструкций, которые не всегда понятно как друг с другом соотносятся, дизайн мод на реальной интеграционной задаче оказался бесполезен, документация вроде и есть, но апи референс дырявый и порой в нем невозможно разобраться. Возможно сейчас уже что-то поменялось, все же индусы очень активно вливают в нее деньги.


#12

Сейчас лучше - за год изменений много. Но по мере развития добавляется некоторое количество магии в язык.