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

Question

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

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

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

У меня сложилось впечатление, что в идеальном SOA / ESB вы бы соединили и Обновление, и Задание платежных реквизитов в один грубый сервис, это правильно?

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Итак, ответ, наверное, зависит.