The Future of Middleware R

1
The Future of Middleware RD

• Geoff Coulson
• Distributed Multimedia Research Group
• Computing Dept, Lancaster University
• geoff_at_comp.lancs.ac.uk

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

3
So, lets 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

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, ...
• ? 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!

5
Some major problems

• middleware heterogeneity
• the lets do our own platform syndrome
• application programmers cant 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,
  ...

6
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

7
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 its even harder to map
  to a library of components than to a fixed API
• components and CFs cant 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 RD on the
  design-time and run-time tools, platforms, and
  techniques

12
Conclusions

• Hmmm

13
Component model

• components
• encapsulated functionality
• language neutral
• third-party deployable
• 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
• expressed in a language-independent IDL
• interaction points for signals as well as
  operations

15
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
16
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
17
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()
18
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
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
• 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

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

21
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