Friday, March 27, 2009

A Federated Service Bus Infrastructure

How to obtain high autonomy and low mutual dependencies of the functional entities in an organization with regard to message interaction and service exposure of SOA? In this pattern I'll describe a model for a federated multi-bus SOA-platform that satisfies the desired autonomies and low mutual dependencies in complex organizations.

The Enterprise Service Bus, what’s in a name

First of all: what is an ESB? Despite of what the market tries to make us believe, an ESB is not for sale. An ESB is an enterprise wide role of a service bus. It's the enterprise itself who decides about the role of the service bus products offered by the vendors. In this pattern, I will not mention the Enterprise Service Bus, as this name does not clearly qualify its position in a federated service bus infrastructure; is it the corporate level service bus or is it the entire service bus infrastructure of the whole enterprise? I take the short way: avoiding the acronym. I will only use the acronym when referring to marketed service bus products.

Levels of federation

This pattern suggests four levels of interest in a federated service bus infrastructure consisting of multiple logical buses:

  • Application level – multiple application buses per domain, one for each application
  • Domain level – multiple domain buses, one for each domain
  • Corporate (enterprise) level – one corporate bus for the enterprise
  • External level – one external gateway for the enterprise

[Click the picture to enlarge]

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). Complex distributed multi-technology applications may take advantage of a dedicated service bus implementation like SonicESB or JBoss.

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.

The corporate level service bus supports cross domain processes and activity monitoring. At the corporate level also enterprise wide generic services are exposed to be accessed by the domains.

The external level service bus supports interaction with the company’s outside world, the business partners, consumers and suppliers. The external service bus exposes external services to the company and supports exposing the company’s services tot the external world.

The different service buses in this pattern need not be different products or different instances of a product. Depending on the organization’s standardization policies, solutions may vary from one multi-tenant product implementation, multi-instance implementations of one product, multi-product implementations to any combination of these.

Services and messages

A distinction is made between services and messages. In this pattern services are synchronously callable modules to be called from within process steps and messages are asynchronously passable data objects between process steps.

Service interactions are by nature tightly coupled: sender and receiver know each other and must both be available at the same time of interaction; the called service influences the performance of the calling service.

Messages allow for loosely coupled interaction: sender and receiver don’t know each other; they need not be available at the same time and they do not influence each other’s performance. The sender publishes the message to a “medium”, and the interested receivers subscribe to the message. The medium is typically the publishers local service bus which - by configuration - propagates the message to the receivers’ local service buses. The receivers subscribe to the message in their own local environment.

How to avoid spaghetti?

“If you like pasta but hate to eat spaghetti, try lasagna.”

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. In this federated service bus pattern parents and children are defined as follows:

  • An application is a child of one domain (n:1); a domain is the parent of one ore more applications (1:n)
  • A domain is a child of the enterprise (n:1); the enterprise is the parent of one ore more domains (1:n)
  • The enterprise (corporate level) is a child of the external level (1:1); the external level is the parent of the enterprise (1:1)

The parent-child approach for communication in this pattern is comparable to the fundamental principles used in structured design approaches, and in defining inheritance and encapsulation in object oriented environments. It creates the “universal system physics” in order to guarantee the ability to keep control over construction and modification of complex software systems (a.k.a. “avoiding spaghetti”).

This leads to the following restrictive policies in cross-boundary communications:

  • 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

No other cross-boundary communication channels are allowed. Horizontal message communications between different applications always take place via the respective domain bus. And horizontal message communications between different domains always take place via the corporate bus.


From a cost-efficiency point of view it would be preferable to implement all levels of this federated model within one product- and administration environment.

Practice, however, is more subtle. 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. Especially when domains originate from fusions and merges with other companies the enterprise will have to cope with redundancy and duplicate solutions. Maintaining this redundancy for the sake of autonomy and independence has an enterprise value. Departments are more loosely coupled which improves agility and offers the possibility to excel. Maintaining redundancy might pay off better than avoiding redundancy which creates constraining dependencies.

With regard to a federated service bus infrastructure, the use of different products - if smartly delimited with regard to different independent administration environments - is no big deal anymore in these days of mature open standards. Supporting interoperability is the main focus in the current IT-industry.

The available interoperability between multiple ESB-products also supports choosing ESB-products based on the characteristics of the specific application- or domain environment. Think of products that are strong or weak in aspects like centralization (hub), decentralization (distributed), multi-tenant (logical separation), multi-instance (physical separation, clustering), device footprint, high volume message routing, back-office processing. E.g. a service bus in an environment of moving trains and gates and vending machines on stations is of quite a different characteristic than an service bus in a centralized data center environment.

By choosing a standards based ESB-solution conformed to a federated and distributed implementation model, the IT-infrastructure will mature to an enormous, agile - yet relatively cheap - business enabler for most (if not all) enterprises.


eelco said...

Makes sense. When i discussed this with an ESB vendor some time ago, they called this pattern Big Bus/Little Bus. The Little Bus would be the domain level bus, the Big Bus the Enterprise Bus.

Hugo said...

I agree/have been putting these same ideas in place for a while now. You can have the high way and the secondary roads working together.

Love the 'try lasagna' joke ;)

Hugo said...

One application can belong to multiple domains. Example: Different SAP modules belong to different business domains: Finance, CRM, etc.
So we should split the end-applications in business oriented instances.
Do you agree?

Jack van Hoof said...

Hi Hugo,

Thanks for your comments. With regard to SAP modules belonging to different business domains, you hit the complex challenges in defining domains.

If you define the domain-buses in terms of information domains (which is ideal from an application point of view), there is only one logical SAP-FIN or SAP-CRM module which maps respectively to the FIN-domain or CRM-domain. There may be a multi-tenant or multi-instance implementation to separate between organizational user groups (business domains), who make use of these FIN- or CRM-processes. These processes are living in the FIN-bus or CRM-bus.

If, on the other hand, you define the organizational departments as domains (which usually is practice) you expose the SAP-modules as enterprise-wide services living in the corporate bus to be accessed by the domain processes in the domain buses. In this case the modules should be context-agnostic (characteristic of a service in an SOA), which means all departments may generically make use of it. Of course, in this case, you may create business oriented instances of the processes, but you must be aware of moving away from the reuse aspect of SOA (which may be an adequate trade-off).

You see, in practice things are more complex then our SOA guru's generally would like us to believe ;-)

Does this answer make any sense?

Hugo said...
This comment has been removed by the author.
Hugo said...

It's definitely not simple ;) and I am not sure I understand you correctly in some points.
Basically, I think we can build (orchestration) processes at the domain and corporate levels (not at the application level here, we expose atomic services to the domain bus).
I see domains as organizational departments, encapsulating the specific business domain functionality. We can expose services (orchestration processes) from that domain to the corporate bus if they have enterprise wide value. If not they will be contained in their domains (FIN, CRM, etc).
For departments to call other departments services in a context-agnostic way we can make use of a Canonical Data Model (CDM) that represents Business Objects enterprise wise, aiming for service reuse.

Shekhar said...

When dealing with COTS Business Applications like eBiz Suite, CRM etc. does it make sense to expose their internal service to the domain bus and orchestrate them when the process is collocated and encapsulated within, I mean sits within those product.

I understand that these vanilla capabilities (of the COTS products) are hardly suitable for use unless they are customized but does that mean we should expose them to domain bus and orchestrate them to develop domain specifc processes?

In my opinion,mainly in cotext of COTS application service, unless there is a situation wherein domain specific processes themselves are dependent on other domain services to realize them and/or these pre-ordained services need to be orchestrated in a different manner practically there is no need to pull them in a domain bus and orchestrate them. But then the question is whether it should be dealt with using a Domain bus or an Enterprise bus.

Jack van Hoof said...

Hi Shekhar,

Besides of exposing and calling services the concept exists of publishing and consuming messages. This distinction is essential in the discussion of domain architectures. In a COTS-environment you will rather publish and consume messages to and from the environment then exposing internal services to be externally called. In an ideal situation these messages represent pure business events.

In fact my idea is not to orchestrate lower level services (child-level), but make use of generic higher level services (parent-level) when you compose a processes at a certain level.

See also a previous post.


Peter L. Gratzer said...

On a short note: looking at the approach it seems to fit well for a functional oriented business, but what kind of approach would you consider if you are faced with a divisional or matrix organization ?

Jack van Hoof said...

@Peter L. Gratzer,

Indeed, things may get very complicated when you are faced with multiple dimensions. This is one reason more the strive for structured solutions.

You might create hard boundaries between the divisions and apply instances of the model within these divisions.

What's your suggestion?


Peter L. Gratzer said...


Not sure if there is an easy answer to the topic. As architects and part business analysts it is our role to translate business requirements into solutions. Putting a solution aka a hierarchical bus model ahead of the requirements is in my view a not a proper direction to address a problem space. As the hierarchical model probably fits a lot of bills, in my view you should come from a business understanding, extrapolate an enterprise wide domain(and not data !!) model and distribute the Services in respect to an organizational fit.

As a structure will form, a hierarchical model may well be the solution, though it could also mean that you have to establish several sub-domain busses communicating in a more horizontal, network oriented fashion.

Bottom line - the application of an architectural approach should be driven by the business requirements, to a portion reflected in a domain model. Important hereby is, that the domain model is maintained and changes over time reflected in the Service portfolio and associated architecture. Do you agree ?

Jack van Hoof said...


I'm not quite sure how the structure will work out if you take the business requirements as a starting point to model an infrastructural layer.

What are the effects if the business requirements change? Are you going to redesign the infrastructure? I prefer a more systematic approach to design an infrastructure that is agnostic to business requirements. Only then real agility can be offered to the business.


Peter L. Gratzer said...


Taking your point you would suggest a cookie-cutter approach ? I doubt that that would fit in the real world.

A business requirements driven solution ? Yes. Otherwise you are architecting for your own pleasure.

Keep in mind - the solution I referred to was more domain driven. Services are categorized and distributed accordingly, as to functional and non-functional requirements incl SLA's. Then they are mapped to an infrastructural solution ... which may be hierarchical, but also could mean a different approach.

Jack van Hoof said...

No, I don't think I am architecting for my own pleasure.

My approach as an IT-architect is always to look for the commonalities, especially with regard to infrastructural matters, because you just want infrastructure to be a commodity by definition. (See how the Internet - with the cloud computing initiatives - including all of it's standards is evolving at the moment). Of course you may create industry-specific patterns and deviations if appropriate, but eventually technologies tend to converge and offer ultimate flexible to support every kind of business. E.g. PC-motherboards are equal whether you run Linux of Windows. And governments use the same kind of networks as financial institutions or any other type of company. The business is made "upon" the technology (makes use of it); the business is not made "by" the technology (except for the companies that have technology in their product-portfolio as a product to be sold in contrast to merely use technology to run their business).

If you design a specific infrastructural solution with the current business requirements in mind, you will run into problems once the business changes or once your competitors take benefit of external commodity providers.

Using systematic commonalities at the infrastructural level make your business more agile to unforeseen or radical changes.

I get the same water and electricity in my company as any other company is getting it -for the sake of flexibility and costs reduction.


Delly News Blog said...
This comment has been removed by the author.
home for sale costa rica said...

Hi, i'm really interested in this post...I want to know more about "A Federared Service Bus Infrastructure".

Thats exactly what I was searching in this time...