Требуются ли промежуточные приложения для ведения бизнес-логики?

Question

Предположим, у меня есть обширная инфраструктура промежуточного программного обеспечения, обеспечивающая передачу запросов между несколькими бизнес-компонентами (клиентские приложения, сеть, платежи и т. Д.). Стек промежуточного программного обеспечения отвечает за оркестровку, маршрутизацию, преобразование и другие вещи (аналогично книге Грегора Хопе «Шаблоны интеграции предприятия»).

У меня такой вопрос: хорошо ли проектировать какую-то бизнес-логику на промежуточном программном обеспечении?

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

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

Answer 1

Помимо маршрутизации, преобразования и оркестровки следует учитывать производительность при загрузке промежуточного программного обеспечения с функциональными требованиями. Промежуточное программное обеспечение должно занимать часть всего времени жизни сквозной транзакции. Этого можно достичь, только сосредоточившись на основных функциях промежуточного программного обеспечения, а не пытаясь дополнить функциональные возможности хост-системы.

Answer 2

Это шаблон «Составное приложение»; сердце сервис-ориентированной архитектуры. Это то, что продавцы ESB продают: способ поместить дополнительную бизнес-логику в то место, которое создает составное приложение из существующих приложений.

Это не просто, потому что ваше составное приложение - это не просто маршрутизация. Это правильная новая составная транзакция, размещенная поверх маршрутизации.

Подсказка. Посмотрите на получение хорошего ESB, прежде чем идти слишком далеко. Это быстро выходит из-под контроля и полезна дополнительная поддержка. Даже если вы не купите что-то вроде Sun JCAPS или Open ESB , вы будете рады, что узнали, что он делает и как они организовывают сложные составные приложения.

Answer 3

Оркестровка, Маршрутизация и Преобразование.

Вы не делаете ничего по техническим причинам, случайным образом или просто для удовольствия, вы делаете это, потому что у вас есть какие-то бизнес-требования - следовательно, здесь задействована бизнес-логика.

Единственное, чего вам не хватает в полной бизнес-системе - это расчеты и отчетность (допустим, у вас уже есть система безопасности!).

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

Выбор «бизнес-логики» в качестве терминологии был очень скудным и привел к бесконечным искажениям дизайна и архитектуры.

То, что большинство хороших дизайнеров / архитекторов подразумевает под бизнес-логикой, - это расчет и анализ.

Если вы "% s / Business Logic / Calculation / g", большинство архитектурных указов имеют больше смысла.

Answer 4

Промежуточное приложение должно это сделать. Система A не должна знать, что другой параметр существует, и, конечно, не будет знать, как его получить.