Все ли идет через автобус?

Мы внедрили BizTalk в нашу организацию как служебную шину, она связывает новый веб-интерфейс с многочисленными существующими серверными системами. Мы обернули наши существующие системы как службы (WCF) и подключили их к шине.

Мы также заменяем некоторые из устаревших системных графических интерфейсов на наш новый веб-интерфейс (гарантируя, что мы реплицируем существующие функциональные возможности), но мне любопытно, должны ли мы предоставлять все устаревшие сервисы / api через шину, подключаться к ним напрямую или составлять их по-другому и выставить их через автобус. Например, допустим, в нашей системе управления клиентами есть 5 существующих служб / API: поиск, добавление, получение, обновление, установка платежных данных.

Имеет ли смысл предоставлять каждую из этих служб через ШИНУ (некоторые утверждают, что это увеличивает задержку)? Или шина должна предоставлять только грубые сервисы, такие как поиск, добавление, извлечение и обновление, а не мелкозернистые? Должен ли графический интерфейс напрямую подключаться к мелкозернистой службе?

У меня сложилось впечатление, что в идеальном SOA / ESB вы бы скомпоновали и Update, и Set billing Details в одну крупнозернистую службу, это правильно?

Я хотел бы оставаться верным парадигме SOA / ESB, не могли бы кто-нибудь просветить меня, пожалуйста.


architecture biztalk web-services esb soa
person Student for Life    schedule 22.02.2009    source источник

Ответы (2)


arrow_upward
4
arrow_downward

ESB лучше всего применять для создания "составных" приложений.

Во-первых, вы должны предоставить множество детализированных сервисов из множества отдельных приложений.

Это создает основу для создания составных приложений.

Дело в том, чтобы создать составные службы, которых нет ни в одном одиночном приложении. Эти службы существуют только в ESB. Они построены на мелкозернистых сервисах.

Обратите внимание, что композиты полагаются на мелкозернистые сервисы, оба из которых находятся в ESB, сокращая накладные расходы, связанные с обнаружением и выполнением мелкозернистых сервисов. Однако реальная работа выполняется внешними приложениями, что приводит к некоторым накладным расходам.

Обратите внимание на то, что производительность приложений на основе ESB настолько проигрывает другим методам взаимодействия, что, ломая руки над «задержкой», упускается огромная победа от немедленной прямой интеграции.

person S.Lott    schedule 22.02.2009

arrow_upward
0
arrow_downward

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

Однако BizTalk также (и некоторые утверждают, что в первую очередь) является механизмом интеграции и часто используется для маскировки потребителя от реализации службы.

Вот возможный сценарий (опять же, не зная, применимо ли это к вашему случаю и в какой степени) - у вас есть устаревшее приложение, которое вы упаковываете в службу для включения SOA. Через 18 месяцев вы завершите внедрение службы замены, но у нее другой интерфейс (поскольку он имеет больше функций) - если у вас есть BizTalk посередине, у вас есть слой, на котором вы можете потенциально сопоставить старый формат, предоставленный вызывающей стороной, с новый формат, требуемый службой, и наоборот в ответе. это означает, что вам не нужно менять все клиентское приложение (в любом случае сразу).

Итак - ответ, я полагаю, зависит от обстоятельств.

person Yossi Dahan    schedule 23.02.2009