Mulesoft и иже с ним

[KVA]

А кто-нибудь тут знаком с Mulesoft? Не было горя но больше начальство выдимо какую-то статью прочитало и стало пропихивать Mulesoft во все дыры.

Хочется аргументировано попытаться отбится от него. Посоветуйте что-нибудь почитать о реальных случаях использования и чем это грозит (c Mulesoft блогом и веб сайтом я знаком).

[Bansai]

Та же херня с проталкиванием Mulesoft. Посетил два их семинара. Осталось стойкое ощущение, что навязывают хрень. Но руководству нравятся картинки вместо кода.

[Alexander Troyansky]

нормальная вещь. Забацать бизнес-процесс, связывающие пачки различных подпроцессов (не два и не пять, а стопицот). Такое кодить - "уебаццаиневстать", я ваше руководство понимаю (наглядность, не в ущерб производительсности/масштабируемости), вас - тоже (ваша жоб секьюрити как никак).

P.S. mulesoft - наш конкурент в определённой сфере.

[KVA]

А можно пример бизнес-процесса хорошо ложащегося на mulesoft?

btw, жоб секьюрити никак не затронута. Удачи им пытаться наши UI на осле кодить. Пока мой непосредственный начальник на моей стороне и согласен что кроме как data layer и для интеграции с вендорами ослик нафик не нужен. Мы отрапортуем что пользуем его и больше начальство будет довольно. Бонус на носу как никак.

[Alexander Troyansky]

А можно пример бизнес-процесса хорошо ложащегося на mulesoft?

Такое лучше, конечно, рисовать, чем вот так объяснять в словах на форуме. Ну скажем, например, обработка транзакций для медстраховок, где имеют место быть многочисленные потребители усулги, поставщики услуг (доктора, госпитали), плательщики (страховки), причём каналы обмена могут быть разные (телефон, факс, электронные сообщения, фтп), и при этом надо обеспечить приём-отправку данных, как в режиме реального времени, так и пакетном, обеспечить валидацию в соответствии с мегатоннами бизнес-правил и госрегуляций, обеспечить сохранность этих данных, избежать их дупликации, аналитика и предсказание и всё-такое. В конце концов у нас эти процессы "рисуют" бизнес-аналисты, плюс допиливают инженеры, где специфика требует.

btw, жоб секьюрити никак не затронута. Удачи им пытаться наши UI на осле кодить. Пока мой непосредственный начальник на моей стороне и согласен что кроме как data layer и для интеграции с вендорами ослик нафик не нужен. Мы отрапортуем что пользуем его и больше начальство будет довольно. Бонус на носу как никак.

Вполне возможно, что уже существующий заматеревший продукт не имеет смысла на осла или какую-либо другую переводить. Тем более, что вы уже нашли компромисное решение.

[KVA]

Ну вот что-то такое и представлялось как более-менее годящееся для ослика (куча интеграций и т.д.). А когда все завязано на свою базу данных и пару вызовов сторонних веб-сервисов нафик он не сдался.

[Вячеслав Викторович]

А можно пример бизнес-процесса хорошо ложащегося на mulesoft?

Такое лучше, конечно, рисовать, чем вот так объяснять в словах на форуме. Ну скажем, например, обработка транзакций для медстраховок, где имеют место быть многочисленные потребители усулги, поставщики услуг (доктора, госпитали), плательщики (страховки), причём каналы обмена могут быть разные (телефон, факс, электронные сообщения, фтп), и при этом надо обеспечить приём-отправку данных, как в режиме реального времени, так и пакетном, обеспечить валидацию в соответствии с мегатоннами бизнес-правил и госрегуляций, обеспечить сохранность этих данных, избежать их дупликации, аналитика и предсказание и всё-такое. В конце концов у нас эти процессы "рисуют" бизнес-аналисты, плюс допиливают инженеры, где специфика требует.

btw, жоб секьюрити никак не затронута. Удачи им пытаться наши UI на осле кодить. Пока мой непосредственный начальник на моей стороне и согласен что кроме как data layer и для интеграции с вендорами ослик нафик не нужен. Мы отрапортуем что пользуем его и больше начальство будет довольно. Бонус на носу как никак.

Вполне возможно, что уже существующий заматеревший продукт не имеет смысла на осла или какую-либо другую переводить. Тем более, что вы уже нашли компромисное решение.

Вообще конечно какой то детский сад. Задачи, которые уже мнократно и качественно решены во многих странах, расписываются как супер-пупер неразрешимо сложные системы с недетерминированными формулами и массой других непонятных слов.
Обычно платят не за бла-бла-бла, вот по моему опыту. Хотя конечно где-то бывает и иначе.

[Вячеслав Викторович]

А кто-нибудь тут знаком с Mulesoft? Не было горя но больше начальство выдимо какую-то статью прочитало и стало пропихивать Mulesoft во все дыры.

Хочется аргументировано попытаться отбится от него. Посоветуйте что-нибудь почитать о реальных случаях использования и чем это грозит (c Mulesoft блогом и веб сайтом я знаком).

Spring Integration использует те же интеграционные паттерны, что и Mule и активно вытесняет Mule ESB. Лично мой 2-х годичный опыт от Spring Integration более чем положительный.
https://www.google.com/search?q=spring+ ... s+mulesoft
Сейчас Mulesoft пытается "подружить" Spring Integration и Mule ESB.
https://www.mulesoft.com/resources/esb/ ... ntegration
Ну не знаю, сейчас в проекте, где используют централизованную Oracle ESB. Опыт негативный, административные затраты на поддержку слишком высоки.
В связи с миграцией в AWS, система находится в режиме перманентного реконфигурирования, где постоянно происходят ошибки и различные проблемы.
Мне кажется, что разумный компромис между централизацией и децентрализацией попросту утрачен.

[Alexander Troyansky]

А можно пример бизнес-процесса хорошо ложащегося на mulesoft?

Такое лучше, конечно, рисовать, чем вот так объяснять в словах на форуме. Ну скажем, например, обработка транзакций для медстраховок, где имеют место быть многочисленные потребители усулги, поставщики услуг (доктора, госпитали), плательщики (страховки), причём каналы обмена могут быть разные (телефон, факс, электронные сообщения, фтп), и при этом надо обеспечить приём-отправку данных, как в режиме реального времени, так и пакетном, обеспечить валидацию в соответствии с мегатоннами бизнес-правил и госрегуляций, обеспечить сохранность этих данных, избежать их дупликации, аналитика и предсказание и всё-такое. В конце концов у нас эти процессы "рисуют" бизнес-аналисты, плюс допиливают инженеры, где специфика требует.

btw, жоб секьюрити никак не затронута. Удачи им пытаться наши UI на осле кодить. Пока мой непосредственный начальник на моей стороне и согласен что кроме как data layer и для интеграции с вендорами ослик нафик не нужен. Мы отрапортуем что пользуем его и больше начальство будет довольно. Бонус на носу как никак.

Вполне возможно, что уже существующий заматеревший продукт не имеет смысла на осла или какую-либо другую переводить. Тем более, что вы уже нашли компромисное решение.

Вообще конечно какой то детский сад. Задачи, которые уже мнократно и качественно решены во многих странах, расписываются как супер-пупер неразрешимо сложные системы с недетерминированными формулами и массой других непонятных слов. Обычно платят не за бла-бла-бла, вот по моему опыту. Хотя конечно где-то бывает и иначе.

В общем-то да, медстрахование в США - это монстр, который по силу только нашему пионеру из Германии, который лично многократно и качественно решил эти задачи в Европе и теперь его с нетерпеньем ждут США, а он всё не едет, поэтому у нас всё так плохо

[Вячеслав Викторович]

А можно пример бизнес-процесса хорошо ложащегося на mulesoft?

Такое лучше, конечно, рисовать, чем вот так объяснять в словах на форуме. Ну скажем, например, обработка транзакций для медстраховок, где имеют место быть многочисленные потребители усулги, поставщики услуг (доктора, госпитали), плательщики (страховки), причём каналы обмена могут быть разные (телефон, факс, электронные сообщения, фтп), и при этом надо обеспечить приём-отправку данных, как в режиме реального времени, так и пакетном, обеспечить валидацию в соответствии с мегатоннами бизнес-правил и госрегуляций, обеспечить сохранность этих данных, избежать их дупликации, аналитика и предсказание и всё-такое. В конце концов у нас эти процессы "рисуют" бизнес-аналисты, плюс допиливают инженеры, где специфика требует.

btw, жоб секьюрити никак не затронута. Удачи им пытаться наши UI на осле кодить. Пока мой непосредственный начальник на моей стороне и согласен что кроме как data layer и для интеграции с вендорами ослик нафик не нужен. Мы отрапортуем что пользуем его и больше начальство будет довольно. Бонус на носу как никак.

Вполне возможно, что уже существующий заматеревший продукт не имеет смысла на осла или какую-либо другую переводить. Тем более, что вы уже нашли компромисное решение.

Вообще конечно какой то детский сад. Задачи, которые уже мнократно и качественно решены во многих странах, расписываются как супер-пупер неразрешимо сложные системы с недетерминированными формулами и массой других непонятных слов. Обычно платят не за бла-бла-бла, вот по моему опыту. Хотя конечно где-то бывает и иначе.

В общем-то да, медстрахование в США - это монстр, который по силу только нашему пионеру из Германии, который лично многократно и качественно решил эти задачи в Европе и теперь его с нетерпеньем ждут США, а он всё не едет, поэтому у нас всё так плохо

слезами делу не поможешь. надо не языком молотить, а просто расширять кругозор, глубже копать матчасть, упорнее и эффективнее работать.
Рецепт прост! и у вас тоже начнёт всё получаться.

[Alexander Troyansky]

слезами делу не поможешь. надо не языком молотить...

Молодец, Викторыч, можно сказать, что проблема определена, одобряю, можете приступать к исполнению