The Simple Solution to SOA is ESBs?

Posted by Mark Little on Jun 01, 2008

Sections

Operations & Infrastructure,

Enterprise Architecture

Topics

SOA Appliance ,

Virtualization ,

SOA ,

ESB ,

SOA Platforms

Tags

SOA Adoption

Joe McKendrick has posted an article on a recent podcast that ebizQ did with IBM SOA expert Lief Davidson on the role ESBs have in SOA. According to Joe:

In physics, they say the simplest solution to a problem is usually the right solution. Applying the laws of physics to SOA, then, it stands to reason that enterprise service buses (ESBs) are the simplest path to SOA within organizations -- and perhaps in many cases, the right path for the organization.

Lief agrees and goes further by indicating that in the current tough economic climate, SOA and ESB are an excellent match. As IT has to struggle with even smaller budgets and yet even more requirements on those budgets ...

Now, SOA is actually aiming to strengthen the alignment of business and IT with the IT assets and the [infrastructure] better able to meet those urgent business demands as well being more flexible and agile for future changes. Key to the flexibility and agility that SOA is trying to deliver is the Enterprise Service Bus, which is at the core of the IT infrastructure.

Obviously IBM believes that their ESB is the best option, which is always interesting given how relatively negative they have been in the past about the need for ESBs at all. The debate around whether or not ESBs are needed at all for SOA has raged for a while. Those against ESBs often cite complexity and vendor lock-in problems as the reasons to stay clear. Whereas others say that the inherent complexity of rolling-your-own is more than mitigated by using an ESB. Unfortunately some vendors don't do the latter argument any favours and this podcast does not go any way to removing the complexity issues around IBMs product suite: 3 ESB solutions?! WebSphere ESB, WebSphere Message Broker, and a SOA appliance, WebSphere DataPower. According to Lief, WebSphere ESB (which is build on the WebSphere application server) is probably closest to the common understanding of the term ESB:

... we built an ESB specially focusing on meeting the integration and connectivity needs based around standards and interactions between services. So even if all of your assets to be connected are Web services, define using Web Services Definition Language or WSDL, you still need to mediate between those services, or very quickly you’ll end up with a static complex environment that doesn’t deliver the SOA benefits you need and want.

The reference to standards probably means WS-* and JEE, since IBM does not participate in JBI and SCA is not yet a standard. Lief goes on to discuss the rest of the WebSphere family of solutions and how they should be used in a good SOA development. Fortunately for customers, all 3 ESB solutions can be purchased and used together. However, the podcast doesn't really live up Joe's original assertion concerning simplicity, with Joe's final comment being more debate-worthy:

There's been a lot of discussion across the industry as to how far organizations that don't necessarily have the resources or executive political can pursue SOA. Add budget crunches, and SOA becomes an impossible sell -- even though it does provide cost savings and containment in the long run. ESBs may provide a way to kick-start SOA in any climate.

So the question still remains: are ESBs the simple route to SOA adoption or should everyone "go ad hoc"?

1. Back to top

   So many options. Work with what you have, just don't compromise your team.

   by Zubin Wadia

   It isn't unusual for Big Blue to throw many options @ a customer. That's just an evolutionary remnant :).
   
   
   
   Given what we have today, I think Websphere Process Server (Orchestration of System/Human Processes) running on App Server, along with MQ (Message backbone) + Broker (for transforms) is all you really need. Build your services in Java. Go REST if allowed.
   
   
   
   @Neil: Languages give you expression/abstraction. You still need HW/SW infrastructure to move the artifacts within your expression around. Oh, and languages don't usually charge on a per-core basis :).
   
   
   
   
   Cheers,
   
   
   
   Zubin Wadia
   
   
   CTO
   
   
   www.imagework.com
   
   
   "Business Acceleration through Process Automation."

   Reply

2. Back to top

   Re: So many options. Work with what you have, just don't compromise your te

   by Zubin Wadia

   Hi Neil,
   
   
   
   Can't speak for IBM or what they recommend. We've worked with a good number of their products, and have a vendor-neutral stance to the ECM/BPM/SOA composite app space.
   
   
   
   In our estimation, WPS6.x has come a long way from what Websphere Business Integration Server Foundation 5.x used to be. It's a good engine as long as you don't read too much into what it can do and use it for what it is good for (Orchestration of SVCs).
   
   
   
   We've run everything from short-running processes to 9-month long ones with 400+ activities (20+ process blocks) and have even gone down the "Einstein" route by writing a mini composition block DSL for it. We also have a helper API that allows our Dev teams to not have to acquaint themselves with a 600-page Red Book prior to interacting with a process :).
   
   
   
   Zubin Wadia
   
   
   CTO
   
   
   www.imagework.com
   
   
   "Business Acceleration through Process Automation."

   Reply

• Older >