1. The Future of Middleware R&D Geoff Coulson Distributed Multimedia Research Group Computing Dept, Lancaster University geoff@comp.lancs.ac.uk

2. The original goals of middleware  masking heterogeneity networks, end-systems, OSs, programming languages networks, end-systems, OSs, programming languages  providing a useful distributed programming model simplicity with generality simplicity with generality CORBA, Java RMI, etc. have been very successful in this... business applications; wrapping of legacy systems...

3. “So, let’s apply the middleware concept more widely...”  applications eCommerce, 7x24 back-end servers eCommerce, 7x24 back-end servers eScience eScience real-time, embedded real-time, embedded mobile agent systems mobile agent systems peer to peer platforms peer to peer platforms mobile computing applications mobile computing applications ubicomp ubicomp telecomms/ programmable networking telecomms/ programmable networking  underlying systems PCs/ workstations PCs/ workstations supercomputers supercomputers wireless PDAs wireless PDAs embedded devices embedded devices network processors network processors wireless, sensor, infrared etc. networks wireless, sensor, infrared etc. networks

4. A victim of its own success?  CORBA tries to cope... add asynch., transactions, fault-tolerance, persistence, components, load balancing, logging, real-time/ embedded/ lightweight CORBA,... add asynch., transactions, fault-tolerance, persistence, components, load balancing, logging, real-time/ embedded/ lightweight CORBA,...  complexity and unmanageability  prototypes arise to fill the gaps asynchronous middleware (pub-sub, eventing, message queueing) (MSMQ, JMS, JavaSpaces,...) asynchronous middleware (pub-sub, eventing, message queueing) (MSMQ, JMS, JavaSpaces,...) Grid middleware (Legion, Globus, OGSA,...) Grid middleware (Legion, Globus, OGSA,...) web services (SOAP, WSDL, WSFL,...) web services (SOAP, WSDL, WSFL,...) mobility middleware (Rover, MOST,...) mobility middleware (Rover, MOST,...) mobile agent systems (Tacoma, Aglets,...) mobile agent systems (Tacoma, Aglets,...) peer-to-peer (JXTA, Jtella,...) peer-to-peer (JXTA, Jtella,...) real-time/ multimedia middleware (ReTINA, DIMMA,...) real-time/ multimedia middleware (ReTINA, DIMMA,...) etc. etc.  different assumptions, models, implementation environments,...  muddleware!

5. Some major problems  middleware heterogeneity the “let’s do our own platform” syndrome the “let’s do our own platform” syndrome application programmers can’t make appropriate choices and cope with the diversity and complexity of all the programming models and APIs application programmers can’t make appropriate choices and cope with the diversity and complexity of all the programming models and APIs solution: trumping? wait for a standards-war winner? NO! solution: trumping? wait for a standards-war winner? NO!  middleware bloat (esp. CORBA) the “kitchen sink” syndrome the “kitchen sink” syndrome wasted computational resources wasted computational resources solution: simplify; but how? solution: simplify; but how?  other problems the focus on wide applicability and building new platforms has resulted in insufficient attention to pressing issues like the focus on wide applicability and building new platforms has resulted in insufficient attention to pressing issues like  management: deployment, configuration, adaptation, resilience, recovery,...  quality: dependability, integrity, scalability,...

6. A possible solution approach  build middleware from fine-grain components configure-in functionality and services as required configure-in functionality and services as required use reflection to facilitate (re)configuration use reflection to facilitate (re)configuration can ‘wrap’ successful existing functionality (e.g., IIOP, RTP, JMS, JavaSpaces,...) can ‘wrap’ successful existing functionality (e.g., IIOP, RTP, JMS, JavaSpaces,...)  reify successful design patterns as component frameworks composite components that take plug-ins composite components that take plug-ins build in rules, constraints build in rules, constraints e.g. CFs for pluggable protocols or binding-types e.g. CFs for pluggable protocols or binding-types  MDA tools generate appropriate component/ CF machinery generic, high level programming; reduced bloat generic, high level programming; reduced bloat

7. Some implied research topics need experience in building systems from components need experience in building systems from components need to minimise and optimise run-times for resource-scarce areas like real-time embedded and programmable networking need to minimise and optimise run-times for resource-scarce areas like real-time embedded and programmable networking MDA is still immature and it’s even harder to map to a library of components than to a fixed API MDA is still immature and it’s even harder to map to a library of components than to a fixed API components and CFs can’t directly address the management and quality issues (although they can help) components and CFs can’t directly address the management and quality issues (although they can help)  autonomic computing?

8. Conclusions  CORBA v2 (etc.) has been a victim of its own success  attempts to apply the middleware concept more widely has lead to “muddleware” and “bloat”  management and quality issues have not received sufficient attention  is MDA + reflective component-based middleware a promising approach?  many problems still to address...

9. Design time  2-3 most important design-time tools and techniques needed to support next- gen middleware

10. Run time  2-3 most important run-time platforms and techniques needed to support next- gen middleware

11. Applications  2-3 most important types of applications that will benefit from advances in R&D on the design-time and run-time tools, platforms, and techniques

12. Conclusions  Hmmm

13. Component model  components encapsulated functionality encapsulated functionality language neutral language neutral third-party deployable third-party deployable can also encapsulate other components to arbitrary degrees of nesting can also encapsulate other components to arbitrary degrees of nesting

14. Component model  interfaces components can support any number of interfaces to help in separating concerns components can support any number of interfaces to help in separating concerns expressed in a language-independent IDL expressed in a language-independent IDL interaction points for ‘signals’ as well as operations interaction points for ‘signals’ as well as operations

15. Component model load() unload() container runtime  containers run-time environment for components run-time environment for components containers may be implemented as OS processes, but not necessarily containers may be implemented as OS processes, but not necessarily load() unload() services available from both inside and outside the container load() unload() services available from both inside and outside the container

16. Component model load() unload() container runtime  receptacles ‘anti-interfaces’ – express a service requirement rather than a service provision ‘anti-interfaces’ – express a service requirement rather than a service provision components may support any number of receptacles to express a variety of requirements on its environment components may support any number of receptacles to express a variety of requirements on its environment key to third party deployability key to third party deployability

17. Component model load() unload() bind() unbind() container runtime  local binding only possible between interfaces and receptacles in same container only possible between interfaces and receptacles in same container assumed lightweight implementation (e.g. vtables) – more needed in case of mixed languages assumed lightweight implementation (e.g. vtables) – more needed in case of mixed languages container offers bind() and unbind() service container offers bind() and unbind() service

18. Further issues (1)  coping with distribution to bind non-local components, we simply load the containers with components that implement suitable protocols/ middleware to bind non-local components, we simply load the containers with components that implement suitable protocols/ middleware we then delegate – locally bind the application components to this ‘middleware’ we then delegate – locally bind the application components to this ‘middleware’ no inherent difference between ‘middleware’ and ‘applications’ – both are just compositions of appropriate components no inherent difference between ‘middleware’ and ‘applications’ – both are just compositions of appropriate components middleware middleware

19. Further issues (2)  the first-class binding pattern a common pattern is to wrap (part of) the required middleware functionality as a ‘distributed component’ called a binding component a common pattern is to wrap (part of) the required middleware functionality as a ‘distributed component’ called a binding component these are instantiated by a central factory which delegates to multiple local factory instances these are instantiated by a central factory which delegates to multiple local factory instances a wide variety of binding types can be implemented a wide variety of binding types can be implemented  RMI, messaging, eventing, media streaming, group comms, shared data spaces (tuple spaces, blackboard systems, mailboxes), voting and auction protocols, workflow processes,...  we have a framework for defining and deploying such binding types

20. Further issues (3)  component frameworks provide structure to component compositions and constrain adaptation provide structure to component compositions and constrain adaptation define roles and constraints for plug-ins define roles and constraints for plug-ins act as run-time life support environments in a particular doamin of functionality act as run-time life support environments in a particular doamin of functionality  e.g. a pluggable protocols framework  or first-class binding types  or the OpenORB middleware...

21. Further issues (4)  reflection support for configuring and reconfiguring sets of components support for configuring and reconfiguring sets of components inspection, adaptation, extension via causally connected meta-models of aspects of underlying components and compositions inspection, adaptation, extension via causally connected meta-models of aspects of underlying components and compositions we provide a set of orthogonal meta-models that expose different aspects we provide a set of orthogonal meta-models that expose different aspects  architecture  interface  interception  resources