Comments 5
Помимо тюннинга WorkManager ещё какой то тюннинг Java контейнера применялся? Тюннили параметры работы с сетью (неблокирующий муксер, колличество соединений)? На какой JVM и под какой ОС работаете?
Хотелось бы знать, какова реальная необходимость в решении типа «прокси-сервис на Oracle Service Bus»? Все в поверпоинтах выглядит красиво, и картинка с архитектурой ESB тоже очень понятная и логичная. Клиент ненарадуется, что не зря потратил деньги.
В реале же к корпоративным сервисам добавляется тяжелый слой ввиде дорогого софта с командой разработчиков по его обслуживанию. Помимо того, что это вносит дополнительные проблемы с взаимодействием систем, ESB делает противоположную вещь для чего изначально предназначена: команда ESB должна знать все в деталях о всех интерфейсах всех систем всех используемых версий. Где же тут обещанный decoupling? В итоге если изменился интерфейс между двумя внутренними системами, приходится еще умолять команду ESB вставить изменения.
В реале же к корпоративным сервисам добавляется тяжелый слой ввиде дорогого софта с командой разработчиков по его обслуживанию. Помимо того, что это вносит дополнительные проблемы с взаимодействием систем, ESB делает противоположную вещь для чего изначально предназначена: команда ESB должна знать все в деталях о всех интерфейсах всех систем всех используемых версий. Где же тут обещанный decoupling? В итоге если изменился интерфейс между двумя внутренними системами, приходится еще умолять команду ESB вставить изменения.
Я успел сменить дважды отношение этому вопросу.
Когда только начинал работу на шине — восторг и веру в поверпоинты и картинки.
Через пару лет, оно сменилось и совпадало с Вашим!
Но еще через пару лет в результате очередного переосмысления, пришло понимание, что команды Систем всячески отказываются от принятия несколько несвойственных им функций. Так шина может приютить такие нестандартные требования, как менеджер сессий сайта к CRM системе. Или предоставить адаптер отсутствующий в Системе, например SMPP или LDAP.
Но это еще не все, часто внедрение Систем идет параллельно — и интегрировать в процессе разработки не с чем. Тут шина может дать заглушки, которые перерастут в полноценные прокси-сервисы. А так же внедренцы Систем обычно не уделяют должного внимания интеграции — в этом случае аналитик шины может играть роль двигателя и координатора процесса.
Так, что шина часто играет не только системную, а социальную роль.
Когда только начинал работу на шине — восторг и веру в поверпоинты и картинки.
Через пару лет, оно сменилось и совпадало с Вашим!
Но еще через пару лет в результате очередного переосмысления, пришло понимание, что команды Систем всячески отказываются от принятия несколько несвойственных им функций. Так шина может приютить такие нестандартные требования, как менеджер сессий сайта к CRM системе. Или предоставить адаптер отсутствующий в Системе, например SMPP или LDAP.
Но это еще не все, часто внедрение Систем идет параллельно — и интегрировать в процессе разработки не с чем. Тут шина может дать заглушки, которые перерастут в полноценные прокси-сервисы. А так же внедренцы Систем обычно не уделяют должного внимания интеграции — в этом случае аналитик шины может играть роль двигателя и координатора процесса.
Так, что шина часто играет не только системную, а социальную роль.
Это хорошо, если на ESB сидит интегратор, который планирует архитектуру, интерфейсы и интеграцию между системами. В проектах, в которых я работал, ты сам разрабатываешь интерфейс и отсылаешь свой WSDL команде ESB, которые коряво его проксят и расставляют глючные меппинги и потом упираются что-либо изменить. Заглушки для локальных тестов всегда делаем сами mock-ами — так надежнее, и не надо ждать пока ESB пошевелятся.
Я работал плотно со стеком IBM Websphere, поэтому у меня такое пессиместичное мнение. Сейчас клиент пользует OSB, а вся архитектура сервисов построена на SOAP. Но методологически ситуация не изменилась: команда ESB ничего не планирует, ни за что не отвечает, и играет роль такого ненужного звена в цепочке интергации. Плюс ко всему прочему зачастую плохо владеет продуктом. От любой проблемы отнекиваются: типа ошибки в ваших системах, плохо посылаете и разбирайтесь сами между собой.
Пример: клиент долго требовал от нас логгировать SOAP-месседжи, которыми мы обмениваемся со сторонними системами. На агрументы типа, что это 120% задача ESB, он говорил, что ему будет проще видеть все в наших логах, нежели каждый раз просить ESB достать месседж.
Я работал плотно со стеком IBM Websphere, поэтому у меня такое пессиместичное мнение. Сейчас клиент пользует OSB, а вся архитектура сервисов построена на SOAP. Но методологически ситуация не изменилась: команда ESB ничего не планирует, ни за что не отвечает, и играет роль такого ненужного звена в цепочке интергации. Плюс ко всему прочему зачастую плохо владеет продуктом. От любой проблемы отнекиваются: типа ошибки в ваших системах, плохо посылаете и разбирайтесь сами между собой.
Пример: клиент долго требовал от нас логгировать SOAP-месседжи, которыми мы обмениваемся со сторонними системами. На агрументы типа, что это 120% задача ESB, он говорил, что ему будет проще видеть все в наших логах, нежели каждый раз просить ESB достать месседж.
Sign up to leave a comment.
Ускоряем OSB