Thursday, July 19, 2007

The Death of Middleware??


Recent attempts - no I'm not saying who :) - to justify centralized approaches to enterprise middleware, in the light of current application modularization trends, triggered a fond memory of driving from San Francisco to Palo Alto, probably sometime 2004.

In between the usual process of struggling with US road signs, the in-car navigation system, and for us Brits, being on the wrong side of the road, I noticed two advertisements. The first, "Middleware Everywhere" was courtesy of IBM, this seemingly in response to a billboard a mile or so further down the road (or visa versa) "The End of Middleware" courtesy of Sun Microsystems.

Ironically, counter to what tradition middleware companies may have you believe, both marketing messages may now be rapidly realized by application modularization, fueled by OSGi and dynamic composition, exemplified by SCA.

Whilst SCA allows Service bindings to be defined at application composition time, OSGi allows these bindings to be dynamically loaded and used by dynamically assembled runtime applications. In principle, the relevant infrastructure messaging / caching components may also be dynamically deployed alongside business logic; see the Newton open source project, and its commercial big brother - Infiniflow - for examples of this approach to dynamic "Business System" assembly.

So - no longer strategic, high cost, high risk, monolithic frameworks that constrain application agility and scalability - "middleware" will simply be the ensemble, or aggregate, of all applications bindings and associated infrastructure components - in use - at each point in time!

The impact on the industry should be significant. Enterprise Service Buses, Space Based Architectures, Message Centric, direct synchronous / asynchronous communication, Web Services?? Ultimately why should we care? Rather than purchasing that strategic "all-purpose" Hammer, and treating all Enterprise inter-service interaction as Nails, lets start using the right tool for the right job; dynamically deploy the appropriate infrastructure service alongside the applications they serve!! And whilst we're at it, lets do this in a manner that increases overall resilience and rips OPEX costs out of the operational environment.

So perhaps IBM's "Middleware is Everywhere" was nearer the mark - that said perhaps Sun's response should now be "Yes But - Enterprise Middleware is rapidly becoming Irrelevant".

Friday, July 06, 2007

We live in exciting times!

Java EE 6 is announced. The Interface21 folks think its finally "right", and the daggers are drawn as the old JBoss boys feel the need to defend their position as popular open source JEE appserver vendor (see theserverside).

Extensibility and Profiling are a couple of key features in Java EE 6.

Mmmm. So I can take my very bloated Java EE infrastructure and reduce it to merely bloated.

I'm almost sold on the idea ;-)

But hang on? What about OSGi and SCA. Can I not already dynamically build very sophisticated distributed composite applications that adapt and evolve to their resource landscapes? Such distributed application services only running loading and running what is required at each specific point in time. These solutions self-managing, self-configuring and self healing?

Well actually, yes I can - and Java EE - in any form - doesn't figure!

On a finishing note - a nice article (concerning Web Services) whose underlying message is, I'd suggest, as equally applicable to the monolith Java EE v.s. composite OSGi / SCA debate.