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”.