中间件应用程序是否需要执行业务逻辑？

Question

假设我有一个大型中间件基础架构来调解多个业务组件（客户应用程序，网络，支付等）之间的请求。中间件堆栈负责编排，路由，转换和其他内容（类似于Gregor Hohpe的Enterprise Integration Patterns一书）。

我的问题是：在中间件上放置一些业务逻辑是一种好的设计吗？

假设我的应用A从中间件请求一些客户数据。但是为了获得这些数据，我必须提供客户ID 和一些其他参数。此参数的提取应由请求应用程序完成，或者是负责“促进”并提供接收 customer ids 的接口并在内部提取其他参数的中间件？

我意识到这不是一个简单的问题（因为业务逻辑的定义），但我想知道这是一般方法还是一些指导原则。

Answer 1

除了路由，转换和编排之外，在加载具有功能要求的中间件时应牢记性能。 Middlware应该占整个端到端事务生命周期的一小部分。这只能通过专注于中间件核心功能来实现，而不是试图补充主机系统功能。

Answer 2

这是“复合应用”模式;面向服务架构的核心。这就是ESB供应商所销售的产品：将额外的业务逻辑放在某处，从现有应用程序中创建复合应用程序。

这并不简单，因为您的复合应用程序不仅仅是路由。这是一个在路由之上分层的合适的新复合事务。

提示。在进一步研究之前，先看看获得一个好的ESB。这很快就会失去控制，并且有一些额外的支持是有帮助的。即使您不购买Sun的JCAPS或Open ESB之类的东西，您也会很高兴了解它的作用以及它们如何组织复杂的复合应用程序。

Answer 3

协调，路由和转换。

您不会出于技术原因，随机或仅仅是为了好玩而执行这些操作，因为您有一些业务需求 - 因此需要涉及业务逻辑。

完整的业务系统唯一缺少的是计算和报告（假设您已经有安全措施！）。

除了非常低级别的网络，操作系统和存储问题，几乎所有构成计算机系统的问题都存在，因为企业/政府/最终用户希望它在那里。

“商业逻辑”作为终端的选择非常糟糕，导致设计和架构的无休止扭曲。

大多数优秀的设计师/建筑师对业务逻辑的意义是计算和分析。

如果你“％s /业务逻辑/计算/ g”，大多数架构法令都更有意义。

Answer 4

中间件应用程序应该这样做。系统A应该不知道其他参数存在，并且肯定不知道如何获得它。