pro arguments:
- divide and conquer philosophy: hide and package structural complexity, only expose services to the upper level that are required there -- hide domain-internal services
- the bus infrastructure effectively models the organizational structure
- distributed governance -- i.e., each business unit can manage and control governance according to its particular requirements (also see the IBM article Choose an ESB topology to fit your business model)
- extra complexity ("middleware for your middleware")
- heterogeneous technology mix - leads to duplicate license costs, operational & maintenance costs
An alternative?
An alternative to the hierarchical ESB topology that Steve proposes would be the "intermediary layer" pattern: Only the business-unit or domain-specific services are encapsulated by an ESB or other type of intermediation layer (legacy wrappers or adapters, domain-specific intermediation services, XML appliances, etc.). This intermediation layer is necessary so that a standard SOAP + WS* protocol can be exposed to the upper level.
Instead of using the BSB one would then rely on the SOAP stack plus the advanced WS-standards to govern the reliability, security, availability, location, routing and other non-functional aspects of the message exchange. The endpoints exposed by the different intermediary layers would also need to agree on messaging patterns and on data formats (see www.soapatterns.org: canonical schema (158)).
I've modified Steve's diagram and replaced the BS with "SOAP and WS*" so that it looks like this:
Now I'd be really curious: what are the pros and cons of this alternative model compared to the original hierarchical topology pattern?
No comments:
Post a Comment