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".
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".
2 comments:
I've heard a lot of buzz around OSGi, however, I'm a "show me" type of developer. I need to try and develop a project using these technologies... or look at one that has already been developed before the new thoughts and ideas sink in. Is there a good place to look for a free as in beer step by step tutorial? If there isn't one what would it take for one of the two of us to develop one?
In the market space I work in many shops are still struggling to get to where they are using Java 5, EJB3, and Spring. OSGi is a departure from ordinary for them.
Shawn
Check out a series of excellent OSGi tutorial articles by Neil Bartlett - see - http://neilbartlett.name/blog/osgi-articles/
Once you / your collegues are happy with OSGi on a single node - check out the Newton project and examples at www.codecauldron.org. Newton is a distributed OSGi / SCA framework - that will support Spring 2.x OSGi bundles.
Cheers
Richard
Post a Comment