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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

Оркестровка, маршрутизация и трансформация.

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

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

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

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

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

Если вы "%s / Бизнес-логика / Вычисления / g", большинство архитектурных указов имеют больше смысла.

Answer 4

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