John Reynolds's Blog

SOA/ESB Level Set

	This figure shows the basis of an application developed using SOA principles and an ESB. Specific services are plugged into the bus, making them available to any application.
The service bus is responsible for routing messages to and from each service, eliminating the problems associated with "point-to-point" programming. Many ESBs are built on top of reliable messaging technologies. Messages are often XML based, but some ESBs allow for multiple protocols and formats. Applications are composed by developing driver programs that orchestrate the available services. Languages such as BPEL are tailored for writing these "driver" programs. Any number of "driver" programs can be written to utilize the services on the bus.
	If the application requires a user interface it is generally bolted on to the driver program.
Any user interface technology can be used; Rich Interfaces using Swing, Browser Interfaces using JSF and/or AJAX.
	If the application requires an external interface to the world beyond the service bus, those interfaces are also generally bolted on to the driver program.
Although it is certainly possible to expose all of the services to the outside world, that is usually not desirable. Generally only "composite services" that represent a service offered to a business partner will be exposed. Before exposing any service to the outside world, security issues must be addressed.
	Legacy programs are added to the mix by creating custom “service adaptors” between the legacy code and the service bus.
The success of integrating any legacy asset into the mix is related to the difficulty of crafting an adaptor (a.k.a. connector) for that asset. If the adaptor is fairly straight-forward, successful integration is more likely. If the adaptor is convoluted, only minimal success is likely. Although reuse of legacy assets is touted as a major SOA selling point, in reality many legacy assets will require refactoring to be of much use. The real payoff is adopting a style of programming that will make new services much easier to reuse later.
	The services that are plugged into the bus should be loosely coupled. Invoking one service should ideally have no side effect on other services. Care must be taken if the services directly access a shared database.
If services share records in a common database, they are coupled in a manor that may not be obvious to the author of the driver program. "Hidden" coupling in an underlying database can be a real problem. When possible, services should be stateless and operate only on the documents that are passed to them.
	To avoid hidden database coupling, some vendors recommend plugging a data service into the service bus.
The primary concern with the data access service approach is the performance issue associated with accessing all data through the bus. The use of data access services has let to several related ideas, such as using Service Data Objects to pass working data between services.

Please let me know what else you think I should add...

Comments

• In researching esb direction, I'm trying to assess if a "service bus" is a just another service 'on the side' of the primary services, to be used when needed, like UDDI, or if it will become a physical mediator of all service consumer-provider conversations. I ask because I'm trying to visualise what to do when we have high volume-performance critical consumer applications (such as in a financial institution) who have well defined providers and don't need externalized orchestration, transformation or even routing and don't not want to to incur the overhead or support of additional mediation tiers. So will the ESB concept become mediation-integration fabric, like DNS, or will it become an applicaiton tier that must be managed and accounted for in a queuing/performance analysis? Any thoughts in this space are appreciated

  Posted by: cparziale on March 02, 2006 at 05:56 AM

• cparziale,
  This is a great question, and I am prompted to write another blog entry to answer this question fully, but my shorter answer is that I believe the value proposition for an ESB drops considerably unless it is the mediator for all service consumer-provider conversations.

  At the heart of your question is the concern: “We do not want to incur the overhead or support of additional mediation tiers.” This is obviously a legitimate concern, and one that every ESB architect must address.

  What additional overhead (latency) is incurred by invoking a service via an ESB versus invoking it directly?

  There are many factors to consider beyond this concern to determine whether or not an ESB is appropriate for your company, but we must still answer this question as best we can.

  The answer will depend on the architecture of the specific ESB, but I believe that it is quite possible that the additional overhead could be quite low.

  Here’s my thought rationale for this statement...

  The ESB allows you to abstract the address of the service endpoint that you wish to invoke. To make this work, the ESB has to map the logical address of the service to a “physical” address. Presumably, a service registry (akin to UDDI) will be used to look up the “physical” address. Looking up the address each time a specific consumer accesses a service could be costly, but if the consumer’s ESB “agent” caches “physical” addresses the overhead could be quite low… it all depends on the implementation of the ESB.

  Certainly, the value proposition for an ESB is about flexibility and about building that flexibility into the ESB infrastructure rather than having to implement it in each service consumer. The ESB should eliminate the consumer’s need to deal with upgrades to the consumed services. The ESB should eliminate the consumer’s need to deal with “load balancing” between instances of a specific service (the consumer invokes a service, not realizing that there may be many instances).

  Some of today's ESBs may provide some or all of these capabilities, but others certainly don't... which makes it all the more important for us to ask these types of questions early on in our evaluations of these technologies.

  --JohnR

  Posted by: johnreynolds on March 02, 2006 at 12:36 PM

• JohnR,

  Thank you for your thoughts. I'd like to further explore one of your comments above because it lingers in my head, and also because it is my gut-feeling as well: "...I believe the value proposition for an ESB drops considerably unless it is the mediator for all service consumer-provider conversations..."

  We have ubiquitously adopted support services such as DNS into our integration fabric, but DNS is not between all the IP endpoints, Its used "on the side", chutney-like so to speak. However we do accept concepts like Routers between many IP endpoints.

  I'm wanting to explore if ESB's aren't monolithic intermediaries, but there are integration 'fabric' components and there are "chutney-like' components?

  Posted by: cparziale on March 03, 2006 at 05:36 AM

• cparziale,Your original comment did result in a blog entry where I provide a few more thoughts.

  
  I am of the opinion that the ESB is more like "fabric" than "chutney".

  In many ways, ESB is the "product" that makes SOA a manageable option for a corporations that have many services. If your company only has a few services, then there isn't a huge need for an ESB. If your company has 100s of services, then they might be totally unmanageable without an ESB.
  Assuming that your company needs the ESB to manage the 100s of services... you would probably frown on "rogue applications" that bypass the ESB to invoke services directly.

  These are (of course) just my thoughts on the matter based on what I've expereinced thus far.

  --JohnR

  Posted by: johnreynolds on March 03, 2006 at 12:13 PM

This work is licensed under a Creative Commons License.