Are middleware apps required to do business logic?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.