Pull to refresh

Comments 16

До боли знакомые картинки. Пользовался последний раз лет 10 назад. Ничего не изменилось в интерфейсе :-). С тех пор перешли на Mule и забыли об этом ужасе. Надеюсь навсегда.
Как я вас понимаю. С тех пор перешел на Camel, и сделал тоже самое.
Не могу согласится с «ужасом», вполне рабочая система, которая пользуется спросом на рынке.
Если сравнить с Mule, то насколько помню, Mule компилируется в Java, а поток с ESQL при определённых условиях в C, производительность теоретически должна быть больше.
Не могу согласиться с не ужасом. Впрочем, на вкус и цвет… вот смотрите:

>Одной из самых удобных вещей в IIB это графическое программирование.
На мой вкус, нет ничего более неудобного, при условии, что вы работаете в команде, потому хотя бы, что придя завтра на работу, вы никогда не сможете понять, какие изменения были сделаны, и почему оно вдруг «вжух, и не работает». Картинки и диаграммы в качестве средства разработки — это как правило ужас при версионировании.

Но раз кому-то нравится — то почему бы и нет?

Можно привести другой кейс, когда есть схема с 100*n полями и нужно собирать такой xml. Очевидно, что упустить что-то в коде гораздо легче чем в мапинге, namespase например. Но конечно предмета для спора тут нет, кому что нравится.

У любого подхода есть свои плюсы. Ну и тот факт, что система рабочая, никто не отрицает.
Если вам нравится мапить мышкой, то в Мule есть графический мапер. Гораздо удобнее и легче. Кроме того, язык DW мощнее гораздо.
Прелесть Мulе в том, что все реализовано с одной стороны гораздо проще, а с другой, по-человечески удобнее и есть выбор. Хочешь мапь в GUI, хочешь — пиши код. Это только один пример.
Отличная, надежная система, но ее надо уметь пользоваться. В неумелых руках она может превратится в кошмар и головную боль. Т.к. система дорогая, то не очень многие могут себе ее позволить, как следствие недостаток хороших ресурсов (админы, разработчики). На своей прошлой работе я пробеседовал более 2х десятков разработчиков из Индии, у многих резюме на десять страниц, опыт работы в крупнейших банках США и Британии, но по факту все задачи решают в лоб и там где процесс может обрабатывать данные 1 минуту на простенькой машине строится кластер с огромным оверхедом.

По-статье есть одно замечание:
До последних версий IIB был неразрывно связан с IBM MQ, но в последней версии IIB (IBM App Connect Enterprise 11) это уже не требуется.

Данная связка требуется до сих пор, например, TimeoutNotification node не будет работать без MQ.

Использую в работе IBM Integration Bus и IBM MDM, главный плюс — стабильная работа, но интерфейс ужасный.
До последних версий IIB был неразрывно связан с IBM MQ, но в последней версии IIB (IBM App Connect Enterprise 11) это уже не требуется.

В v10 уже MQ не обязательно, а ACE ака v11 это вообще уже шаг куда-то в сторону контейнеризации.

АСЕ оставляет странное ощущение, внутри кишОчки вроде и IIB-шные (по крайней мере пока), а сверху приркручен сингл-процесс сервер с обособленным Work-dir и конфигом, что бы по «докерному» было. Пока это больше похоже на тестовую площадку технологии, хотя вполне работоспособно за счет использования наработок предыдущих версий. Интересно будет понаблюдать во что это вырасте, и вырастет ли вообще…
Один из удобных способов трансформации сообщения из одного формата в другой это Data Mapping:

никогда не используйте это, т.к. оно не отлаживается (в отличие от ESQL)
в ссылочки можно добавить ещё sharavara.com/category/iib и developer.ibm.com/integration/docs/ibm-integration-bus/self-study-labs
в ссылочки можно добавить ещё sharavara.com/category/iib и developer.ibm.com/integration/docs/ibm-integration-bus/self-study-labs


Не ожидал увидеть тут ссылку на свой блог :)
Этот раздел может скоро помрет у меня в блоге, если будет время то перенесу его на Медиум или в Хабр.
этот блог в своё время здорово мне помог. жду цикл статей. хотя сам я уже благополучно слез с IIB (переводим интеграционные приложения на Java/Spring Boot), почитать всё равно будет интересно.
Sign up to leave a comment.

Articles