Tastes great but less functionality - Light ESB

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Dain Hansen's Blog | November 5, 2007  10:19 AM | Comments (0)

So why is it we can never get this definition right?

I’ve seen countless number of blogs (SearchWebServices) on the mythical light ESB. But I don’t agree with many of the statements on what a light ESB is; and hence many of the conclusions that are drawn.

• Is a Light ESB an ESB that is easy to install? No, that’s just nonsense. In which case an iPod is an ESB.
• Is a Light ESB an ESB that doesn’t run on an application server? No. In fact by embedding it’s own built-in application server functionality, it is in fact much heavier
• Does a heavy ESB includes governance functionality? No, I would say if there is no way to manage it, it is not really an ESB in the first place.
• Does light ESB mean open source? Not necessarily. Because many of the open sources are just as heavy weight in terms of memory and in terms of how they perform in a run-time environment.
• Does Light ESB have functionality removed? No, That’s how many use the term, the question is only what functionality would you take out? Routing, Transformation, IDE, Security, Monitoring, Scalability, Performance, Standards, Extensibility. They are all important. You can’t do Service Mediation
• Is a Light ESB an appliance? Well not all rhombuses are squares as the saying goes. This too is what I would say for the appliance. Just because you put your ESB in a square box (or is it a rhombus?!); doesn’t make it lightweight. Especially if you require multiple boxes + some software to do what a single ESB can do.

So how does an ESB get lighter?

• Lower memory footprint for the entire ESB, as well as overall SOA Integration solution.
• Support real-time systems with deterministic garbage collection
• Supporting time and event driven computing in ESB environments.
• Optimzed design time plugins for Eclipse which support better tooling integration for the entire SOA & BPM stack
• Optimizing it for secure, reliable transports with co-located integration capabilities as plugins: ERP Connectivity, Integration, BPM, Data Services.
• Build it with policy in mind for SOA Governance. And leverage a separate Registry/Repository component for visibility and control at all levels.
• Support all aspects WS* which are by nature light already.
• Don’t force Java on everything that the Bus does
• The same solution should be interchangeable for both small and large scale environments to scale out as your business grows.

Today the market needs a fully functional bus, but one that can grow and evolve as enteprise needs for SOA evolve and mature, but that starting point is an ESB. Call it what you want, light or heavy you decide. I like to call it AquaLogic Service Bus.

Comments