John Reynolds's Blog

Is an Enterprise Service Bus (ESB) appropriate for volume-performance critical consumer applications?

"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 do 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 application tier that must be managed and accounted for in a queuing/performance analysis? Any thoughts in this space are appreciated "

I believe the value proposition for an ESB drops considerably unless it is the mediator for all service consumer-provider conversations. The advantage of an ESB over point-to-point service invocations is mostly about managing services across the enterprise. If "rogue applications" bypass the service bus, you will lose much of its value.

At the heart of cparziale's question is the gnawing concern:

"We do not want to incur the overhead or support of additional mediation tiers."

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.

An 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 itself (Check out the links to various ESB implementations at the end of this blog entry).

Tha value of an ESB comes into play when you consider the burden that would be placed on individual service consumers if the ESB was not there... so we have to look at the benefits that the ESB provides and decide whether or not we need them.

One benefit of an ESB is the aforementioned abstraction of the "physical" address. If the location of a service moves, or if a new version of a service becomes available, the consumers of the service will not have to be modified. You could of course build this logic into the service consumer itself, but imagine where that leads.

An ESB could also be a mechanism for providing scalability and load balancing. Assume that overall performance could be enhanced by instantiating multiple copies of a specific service: The ESB could function as a load balancer, hiding from service consumers any knowledge that multiple service instances exist. Of course you could accomplish the same thing by hosting a service on a clustered server, but the ESB offers the promise of creating service instances "on demand" if coupled with the appropriate provisioning software.

Some ESB implementation provide these capabilities, but others certainly do not, and it is very important for us to ask these questions before commiting ourselves. If "high volume-performance critical consumer applications" are a part of our enterprise, then we'd better be very sure that the ESB that we adopt is up to the task... Ask the right questions early, or we could end up very disappointed.

Comments

• but if the consumer’s ESB "agent" caches "physical" addresses the overhead could be quite low

  Isn't that the reason why we have UDDI in the first place? To make dynamic lookups? If you cache them, they become static lookups and they require a caching strategy to deal with the stale addresses. It sounds exactly like using the "ServiceLocator" J2EE pattern to cache JNDI lookups...

  if a new version of a service becomes available, the consumers of the service will not have to be modified

  Is that a realistic assumption? After all, this suggests that the new version is backward-compatible, which, I think, is not the case most of the time. Versioning is a big topic in SOA and there's a reason for it. It brings some design *challenges* on the architect's table :).

  Regarding the load balancing: Web Services are HTTP based and they should be designed stateless. Therefore any decent load balancer, software or hardware, would know how to effectively serve them. I don't think it is a good enough argument to promote an ESB.

  he ESB offers the promise of creating service instances "on demand"

  I don't really understand this point. What is an instance in this context? Does on demand mean when the service request arrives?

  Last but not least, I'd seriously doubt that a high volume-performance critical consumer application should be architectured around HTTP and SOAP based Web Services. I think that would be the ideal recipe for failure.

  Posted by: yagiz on March 03, 2006 at 07:11 AM

• You are right on track yagiz... in many respects the ESB products are not introducing new capabilities, they are consolidating these capabilities into a "product" that can be deployed and managed across an enterprise.

  The ESB offers the promise of creating service instances "on demand

  Poor choice of words... "on demand" is more from the perspective of a "control center/provisioning software" approach. As the operator notes increased need for a specific service due to varying loads, the operator can spawn additional instances of a service (on additional computing nodes, to meet a Service Level Agreement), which the ESB would start using to satisfy requests.

  --JohnR
  

  Posted by: johnreynolds on March 03, 2006 at 08:15 AM

• David Chappel just posted a blog entry that is relates to this topic:

  "regardless of how diligent an organization is about creating policies and procedures for deploying services, there always seems to be new services or new versions of services being deployed that bypass or go outside of those procedures. The introduction of these "rogue services" in an enterprise can open up severe holes in an organization's security and governance plans."
  

  Posted by: johnreynolds on March 03, 2006 at 01:39 PM

• JohnR,

  See, now you've gone and done it. Regarding the comment that "An ESB could also be a mechanism for providing scalability and load balancing......but the ESB offers the promise of creating service instances "on demand" if coupled with the appropriate provisioning software"

  I don't doubt that a Bus offering integration-fabric can participate in load balancing and supply feedback about the need for more instances 'on-demand', I do wonder about us abusing the Analogy implied by the "B" in ESB. If the ESB fabric is going to include the service containers (generally responsible for provisioning and quantity of instances) then don't we need to move off the analogy of a Bus? A city bus, doesn't created more buildings for people to work in, the SCSI or USB bus doesn't spin up more scanners for me to scan from, or printers to print to. I believe in what you are saying, but shouldn't we avoid extending the ESB analogy to be broader then the BUS construct?

  Posted by: cparziale on March 09, 2006 at 11:41 AM

• btw...I appreciate that we are stuck with the ESB term likely because of crazy-gartner-wild-hair fabrication that allows companies to capitalize on unsuspecting CIO's, but if we allow the ESB to lack any real definition, or limits aren't we just Belling-the-Cat?

  Posted by: cparziale on March 09, 2006 at 11:45 AM

• cparziale,I knew that you'd figure out sooner or later that I am a snake oil slaesman at heart ;-)

  "shouldn't we avoid extending the ESB analogy to be broader then the BUS construct?"

  I have mixed feelings about this. If the ESB concept isn't broad enough, then it may not be worth the trouble. If the bus is just for transporting messages, then it is not much more than a layer on top of reliable messaging. If we add too much to ESB, then we run the risk of sounding like Bill Gates when he was claiming that Internet Explorer is an integral part of the Windows operating system.

  
  I don't want to invent a new term, but what I am thinking is along these lines...
  Assume that I have a rack of servers (to make Jonathan Schwartz happy, let's also assume they are Niagra servers with Solaris installed). What I am looking for is a package of software that I can install on each server in the rack. This "package" of software will be able to host services and connect all of the hosted services to all of the services that are hosted on the other servers in the rack.

  From a management console, I want to be able to see all of the services that are running in the rack, and I also want to see all of the services that are available to be deployed in the rack. From the management console, I want to "drag and drop" services onto each server. I would also like to be able to configure rules... "If the demand for service A on node 1 exceeds a threshold, create a copy of service A on another node".

  Is what I am describing more then and ESB? Probably... but we need to make things easier on the folks who are maintaining the computing centers. They should not have to install an appserver, and an ESB, and so forth.

  
  On kind of a related note..."ServiceMix is completely integrated into Apache Geronimo, which allows you to deploy JBI components and services directly into Geronimo. ServiceMix is being JBI certified as part of the Geronimo project."
  I assume that means if we deploy Geronimo, then we've also deployed the ServiceMix ESB... I am sure there's a line between the two, but it seems very fuzzy.

  
  I'm not sure, but I think that I have managed to muddy the water even further ;-)

  --JohnR

  Posted by: johnreynolds on March 09, 2006 at 03:51 PM

• See, now you've gone and done it. Regarding the comment that "An ESB could also be a mechanism for providing scalability and load balancing......but the ESB offers the promise of creating service instances "on demand" if coupled with the appropriate provisioning software" I don't doubt that a Bus offering integration-fabric can participate in load balancing and supply feedback about the need for more instances 'on-demand', I do wonder about us abusing the Analogy implied by the "B" in ESB. If the ESB fabric is going to include the service containers (generally responsible for provisioning and quantity of instances) then don't we need to move off the analogy of a Bus? A city bus, doesn't created more buildings for people to work in, the SCSI or USB bus doesn't spin up more scanners for me to scan from, or printers to print to. I believe in what you are saying, but shouldn't we avoid extending the ESB analogy to be broader then the BUS construct?
  

  Posted by: sallee on October 11, 2006 at 02:13 AM

• I read "Some ESB implementation provide these capabilities, but others certainly do not..."

  Is Open ESB provide scalability capacities?

  Posted by: jlbt on March 29, 2007 at 08:07 AM

This work is licensed under a Creative Commons License.