Jack Van Hoof presents a prescriptive guidance on how to model a federated service bus infrastructure such that it affords the various parts on the enterprise interacting with it, the desired levels of autonomy. In his opinion the word ESB doesn't say much about the scope of the audience it services, so he further classifies ESB’s on the basis of their level of federation
This pattern suggests four levels of interest in a federated service bus infrastructure consisting of multiple logical buses:
- Application level – The application level service buses support fine grained application level processes and activity monitoring. Each application is bound to its own logical bus. In practice this boundary will typically be implemented by an application name space on an application server using JMS (java) or WCF (.net).
- Domain level – A domain is a functional cohesive entity, like Human Resource Management, Finance, Logistics, Sales, Acquisition. Service buses at this level support cross application processes and activity monitoring within the boundaries of the distinct domains. Domains also expose domain generic services to be accessed by the domain’s applications. Multiple domain buses [might exist], one for each domain.
- Corporate (enterprise) level – The corporate level service bus supports cross domain processes and activity monitoring. At the corporate level one corporate bus [serves] the enterprise [that can also] be accessed by the domains.
- External level – An external level service bus supports interaction with the company’s outside world, the business partners, consumers and suppliers.
Since the categorization of these buses naturally forms a hierarchy in the types of buses in an enterprise, he warns that if the federation is not effectively modeled it could turn into what he calls “spaghetti”. To avoid this he use a parent-child metaphor to model the topology and scope of the service buses.
In this pattern a layered structure of interaction is promoted to maintain the desired boundaries of autonomy and yet structure controllability. This layered structure leads to a hierarchical parent-child communication approach. A child has only one parent (it's only a metaphor, folks), a parent may have multiple children. [for e.g.] An application is a child of one domain (n:1); a domain is the parent of one ore more applications (1:n)
Having explained that, he recommends the following rules to avoid getting into a “spaghetti” situation
- Child-level processes may deliver messages to their parent’s bus
- Parent-level processes may deliver messages to their children's buses
- Downward skip-level messaging always cascade from parent bus to child bus
- Upward skip-level messaging always cascade from child bus to parent bus
- Parent-level buses may expose services to their children's buses
He also presents considerations that make the practice not as easy as just following the rules.
- Political considerations
Domain models will mostly be shaped on a foundation of autonomy which has organically risen from culture, history and mightiness. Domains tend to make their own choices with respect to IT-resources such as applications, tools and platforms.
- Interoperability considerations
With regard to a federated service bus infrastructure, the use of different products [… and] Supporting interoperability [between them] is the main focus in the current IT-industry.
Jack presents a logical approach to modeling the service bus infrastructure. Do read his original article for details.