中间件应用程序是否需要执行业务逻辑？
假设我有一个大型中间件基础设施，用于协调多个业务组件（客户应用程序、网络、支付等）之间的请求。 中间件堆栈负责编排、路由、转换和其他内容（类似于 Gregor Hohpe 的《企业集成模式》一书）。
我的问题是：在中间件上放置一些业务逻辑是一个好的设计吗？
假设我的应用程序 A 向中间件请求一些客户数据。 但为了获取此数据，我必须提供客户 ID 和一些其他参数。 此参数的获取应由请求应用程序完成，还是中间件负责“促进”并提供接收客户 ID 并在内部获取其他参数的接口？
我意识到这不是一个简单的问题（因为业务逻辑的定义），但我想知道这是否是通用方法或一些准则。
Let's suppose I have a large middleware infrastructure mediating requests between several business components (customer applications, network, payments, etc). The middleware stack is responsible for orchestration, routing, transformation and other stuff (similar to the Enterprise Integration Patterns book by Gregor Hohpe).
My question is: is it good design to put some business logic on the middleware?
Let's say my app A requests some customer data from the middleware. But in order to get this data, I have to supply customer id and some other parameter. The fetching of this parameter should be done by the requesting app or is the middleware responsible for 'facilitating' and providing an interface that receives customer ids and internally fetches the other parameter?
I realize this is not a simple question (because of the definition of business logic), but I was wondering if it is a general approach or some guidelines.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这就是“组合应用”模式； 面向服务的架构的核心。 这就是 ESB 供应商所销售的：一种将额外业务逻辑放置在现有应用程序之外创建组合应用程序的方法。
这并不简单，因为您的复合应用程序不仅仅是路由。 这是一个位于路由之上的全新复合事务。
暗示。 在走得更远之前先考虑一下获得一个好的 ESB。 这很快就会失去控制，获得一些额外的支持会有所帮助。 即使您不购买 Sun 的 JCAPS 或 开放 ESB，您会很高兴了解它的用途以及它们如何组织复杂的组合应用程序。
This is the "Composite Application" pattern; the heart of a Service Oriented Architecture. That's what the ESB vendors are selling: a way to put additional business logic somewhere that creates a composite application out of existing applications.
This is not simple because your composite application is not just routing. It's a proper new composite transaction layered on top of the routing.
Hint. Look at getting a good ESB before going too much further. This rapidly gets out of control and having some additional support is helpful. Even if you don't buy something like Sun's JCAPS or Open ESB, you'll be happy you learned what it does and how they organize complex composite applications.
编排、路由和转换。
您不会出于技术原因、随机或只是为了好玩而执行这些操作，您执行这些操作是因为您有一些业务需求 - 因此涉及业务逻辑。
对于完整的业务系统，您唯一缺少的是计算和报告（让我们假设您已经具备适当的安全性！）。
除了非常低级的网络、操作系统和存储问题之外，组成计算机系统的几乎所有内容都在那里，因为企业/政府/最终用户希望它在那里。
选择“业务逻辑”作为术语非常糟糕，并导致了设计和架构的无尽扭曲。
大多数优秀的设计师/建筑师所说的业务逻辑是计算和分析。
如果您“%s/业务逻辑/计算/g”，则大多数架构法令都会更有意义。
Orchestration, Routing and Transformation.
You don't do any of these for technical reasons, at random, or just for fun, you do these because you have some business requirement -- ergo there is business logic involved.
The only thing you are missing for a complete business system is calculation and reporting (let us assume you already have security in place!).
Except for very low level networking, OS and storage issues almost everything that comprises a computer system is there because the business/government/end users wants it to be there.
The choice of 'Business Logic' as terminoligy was very poor and has led to endless distortions of design and architecture.
What most good designers/architects mean by business logic is calculation and analysis.
If you "%s/Business Logic/Calculation/g" most of the architectural edicts make more sense.
中间件应用程序应该做到这一点。 系统A不应该知道另一个参数的存在，并且肯定不知道如何获取它。
The middleware application should do it. System A should have no idea that the other parameter exists, and will certainly have no idea about how to get it.
除了路由、转换和编排之外，在加载具有功能需求的中间件时还应该考虑性能。 中间件应该只占用整个端到端事务生命周期的一小部分。 这只能通过专注于中间件核心功能来实现，而不是试图补充主机系统功能。
Apart from the routing, transformation and orchestration, performance should be kept in mind while loading middleware with functional requirements. Middlware should take a fraction of the entire end-to-end transaction life time. This can be achieved only by concentrating on the middleware core functionalities, rather than trying to complement the host system functionalities.