The Future of Middleware R&D

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

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

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

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, ...  complexity and unmanageability • prototypes arise to fill the gaps • asynchronous middleware (pub-sub, eventing, message queueing) (MSMQ, JMS, JavaSpaces, ...) • Grid middleware (Legion, Globus, OGSA, ...) • web services (SOAP, WSDL, WSFL, ...) • mobility middleware (Rover, MOST, ...) • mobile agent systems (Tacoma, Aglets, ...) • peer-to-peer (JXTA, Jtella, ...) • real-time/ multimedia middleware (ReTINA, DIMMA, ...) • etc. • different assumptions, models, implementation environments, ...  muddleware!

Some major problems • middleware heterogeneity • 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 • solution: trumping? wait for a standards-war winner? NO! • middleware bloat (esp. CORBA) • the “kitchen sink” syndrome • wasted computational resources • solution: simplify; but how? • other problems • 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, ...

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

Some implied research topics • 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 • 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) • autonomic computing?

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

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

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

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

Conclusions • Hmmm

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

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

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

Component model • receptacles • ‘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 • key to third party deployability load()unload() container runtime

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

Further issues (1) • coping with distribution • 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’ • no inherent difference between ‘middleware’ and ‘applications’ – both are just compositions of appropriate components middleware middleware

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 • these are instantiated by a central factory which delegates to multiple local factory instances • 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

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

Further issues (4) • reflection • support for configuring and reconfiguring sets of components • 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 • architecture • interface • interception • resources

The Future of Middleware R&D