World Wide Webber

Just a plea - less about your conferences agenda - and more real content.

Jim, loved your sessions at the SOA Symposium. Not only the content but also your style of presenting impressed me and my students. More about our visit to the symposium is availble at http://wiki.icaprojecten.nl/display/EADPUBL/Home (several parts are not in Dutch :))

Jim, 

I also really enjoyed your presentation at the SOA Symposium. I agree with nearly everything in the presentation. The one area that I disagree is that the argument you make is not against ESBs but rather against what my colleagues and I derisively refer to as the BFB (Big Fat Bus). As you so eloquently pointed out, the BFB is, in fact, an architecture anti-pattern. 

However, just because an ESB can be used incorrectly it does not follow that all ESBs are bad. IMO the proper way to use an ESB is (for lack of a better term) as an ‘enterprise service façade’. So, for example, in the case of web services, the ESB provides an enterprise-class web service stack that can front a new service or existing legacy functionality. The ‘enterprise’ aspects include security, monitoring, management, QoS, etc. 

Used in this manner, the ESB provides the ‘smarts’ for the smart endpoints. The network stays dumb, the routing is done via HTTP/DNS/etc. (not inside the bus), and there is no vendor lock-in since each endpoint could use a different ‘enterprise service façade’.  

The very name ESB contributes to the misuse of the technology. Combine that with the ‘legacy knowledge’ built up from EAI and MOM and it is no wonder that the new products are frequently misused; thus resulting in the same old mess using new technologies and products. But, the underlying problem is an education issue not an ESB issue. 

In the interest of full disclosure, I work for an ESB vendor. However, I consider myself a consultant who happens to work for a product vendor (by way of two acquisitions). Hopefully you can see past my employer and evaluate the above verbiage on its merit (and veracity) rather than dismissing it as vendor propaganda.

Hello Bob, 

I completely agree with your observations (and love the BFB acronym). Using an ESB behind an endpoint to provide smarts may be a good engineering decision for some services - indeed protocol-centric integration encourages services to innovate behind their endpoints. 

Still I think ESBs have an uphill battle in this sector. They're being squeezed by increasingly sophisticated platforms (Java and .Net spring immediately to mind) which come with quite capable integration software baked in.  

So given ESBs are behind the endpoints, they're now fighting for turf which is already well and truly occupied by (for example) WCF or Spring Web Services. 

Perhaps the key element is management though. I don't know what real capabilities for service management the commodity stacks have - maybe an ESB can play out well there, if it avoids the BFB pattern. 

What do you reckon? 

Jim

Hi Jim, 

I totally agree that the application platforms provide most (or all) of the ‘localized’ capability necessary to create a shared service. However, I believe most companies will need the ability to centrally administer and manage policies that are then consistently enforced across all their shared, enterprise services. These policies include things like security, SLAs, throttling, usage reports, charge back, etc. 

I’m only aware of two architectural approaches to provide consistent enforcement across a variety of service implementations: mediation and agents. ESBs take the mediation approach whereas WSM products (e.g. Amberpoint) take the agent approach. Both approaches have their advantages and disadvantages.  

The main disadvantage with the mediation approach is that there is an extra stop in the communication path. The main disadvantage with the agent approach is the need for a compatible agent for every possible service implementation (HW, OS version, JVM version, App server version, …).  

I expect both approaches will close the gap. ESBs will include more federation capabilities to the point where each service could have its very own instance of ESB fronting it. Agent approaches will include a stand alone ‘agent interceptor’ so that the agent does not have to be co-located with the service implementation (I believe Amberpoint already has this type of thing).  

There is also the possibility that policy enforcement will become standardized enough that the platforms themselves can be administered to provide consistent policy enforcement. Security is nearly there already. However, there is very little standardization on other policy types. 

Personally I’m partial to the mediation approach because I’ve been burned too many times on version incompatibilities (but not by WSM products, yet). But that is just my scar tissue showing through… 

Bob