Top Banner
The Future of Middleware R&D Geoff Coulson Geoff Coulson Distributed Multimedia Research Group Distributed Multimedia Research Group Computing Dept, Lancaster University Computing Dept, Lancaster University [email protected] [email protected]
21

The Future of Middleware R&D Geoff Coulson Distributed Multimedia Research Group Computing Dept, Lancaster University [email protected].

Dec 21, 2015

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: The Future of Middleware R&D Geoff Coulson Distributed Multimedia Research Group Computing Dept, Lancaster University geoff@comp.lancs.ac.uk.

The Future of Middleware R&D

Geoff CoulsonGeoff Coulson

Distributed Multimedia Research GroupDistributed Multimedia Research Group

Computing Dept, Lancaster UniversityComputing Dept, Lancaster University

[email protected]@comp.lancs.ac.uk

Page 2: 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 masking heterogeneity networks, end-systems, OSs, programming languagesnetworks, end-systems, OSs, programming languages

providing a useful distributed programming providing a useful distributed programming modelmodel simplicity with generalitysimplicity with generality

CORBA, Java RMI, etc. have been very successful in CORBA, Java RMI, etc. have been very successful in this... business applications; wrapping of legacy this... business applications; wrapping of legacy systems...systems...

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

“So, let’s apply the middleware concept more widely...”

applicationsapplications eCommerce, 7x24 back-end serverseCommerce, 7x24 back-end servers eScienceeScience real-time, embeddedreal-time, embedded mobile agent systemsmobile agent systems peer to peer platformspeer to peer platforms mobile computing applicationsmobile computing applications ubicompubicomp telecomms/ programmable networkingtelecomms/ programmable networking

underlying systemsunderlying systems PCs/ workstationsPCs/ workstations supercomputerssupercomputers wireless PDAswireless PDAs embedded devicesembedded devices network processorsnetwork processors wireless, sensor, infrared etc. networkswireless, sensor, infrared etc. networks

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

A victim of its own success?

CORBA tries to cope...CORBA tries to cope... add asynch., transactions, fault-tolerance, persistence, add asynch., transactions, fault-tolerance, persistence,

components, load balancing, logging, real-time/ embedded/ components, load balancing, logging, real-time/ embedded/ lightweight CORBA, ...lightweight CORBA, ... complexity and unmanageabilitycomplexity and unmanageability

prototypes arise to fill the gapsprototypes arise to fill the gaps asynchronous middleware (pub-sub, eventing, message asynchronous middleware (pub-sub, eventing, message

queueing) (MSMQ, JMS, JavaSpaces, ...)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 different assumptions, models, implementation environments, ... environments, ... muddleware! muddleware!

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

Some major problems

middleware heterogeneitymiddleware heterogeneity the “let’s do our own platform” syndromethe “let’s do our own platform” syndrome application programmers can’t make appropriate choices application programmers can’t make appropriate choices

and cope with the diversity and complexity of all the and cope with the diversity and complexity of all the programming models and APIsprogramming 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)middleware bloat (esp. CORBA)

the “kitchen sink” syndromethe “kitchen sink” syndrome wasted computational resourceswasted computational resources solution: simplify; but how?solution: simplify; but how?

other problemsother problems the focus on wide applicability and building new platforms the focus on wide applicability and building new platforms

has resulted in insufficient attention to pressing issues like has resulted in insufficient attention to pressing issues like management: deployment, configuration, adaptation,

resilience, recovery, ... quality: dependability, integrity, scalability, ...

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

A possible solution approach

build middleware from fine-grain componentsbuild middleware from fine-grain components configure-in functionality and services as requiredconfigure-in functionality and services as required use reflection to facilitate (re)configurationuse reflection to facilitate (re)configuration can ‘wrap’ successful existing functionality (e.g., IIOP, can ‘wrap’ successful existing functionality (e.g., IIOP,

RTP, JMS, JavaSpaces, ...)RTP, JMS, JavaSpaces, ...) reify successful design patterns as reify successful design patterns as component component

frameworksframeworks composite components that take plug-inscomposite components that take plug-ins build in rules, constraintsbuild in rules, constraints e.g. CFs for pluggable protocols or binding-typese.g. CFs for pluggable protocols or binding-types

MDA tools generate appropriate component/ CF MDA tools generate appropriate component/ CF machinerymachinery generic, high level programming; reduced bloatgeneric, high level programming; reduced bloat

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

Some implied research topics

need experience in building systems from need experience in building systems from componentscomponents

need to minimise and optimise run-times for need to minimise and optimise run-times for resource-scarce areas like real-time resource-scarce areas like real-time embedded and programmable networkingembedded and programmable networking

MDA is still immature and it’s even harder to MDA is still immature and it’s even harder to map to a library of components than to a map to a library of components than to a fixed APIfixed API

components and CFs can’t directly address components and CFs can’t directly address the management and quality issues the management and quality issues (although they can help)(although they can help) autonomic computing?

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

Conclusions

CORBA v2 (etc.) has been a victim of its CORBA v2 (etc.) has been a victim of its own successown success

attempts to apply the middleware attempts to apply the middleware concept more widely has lead to concept more widely has lead to “muddleware” and “bloat”“muddleware” and “bloat”

management and quality issues have management and quality issues have not received sufficient attentionnot received sufficient attention

is MDA + reflective component-based is MDA + reflective component-based middleware a promising approach?middleware a promising approach?

many problems still to address...many problems still to address...

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

Design time

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

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

Run time

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

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

Applications

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

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

Conclusions

HmmmHmmm

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

Component model

componentscomponents encapsulated functionalityencapsulated functionality language neutrallanguage neutral third-party deployablethird-party deployable can also encapsulate other components to can also encapsulate other components to

arbitrary degrees of nestingarbitrary degrees of nesting

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

Component model

interfacesinterfaces components can support any number of components can support any number of

interfaces to help in separating concernsinterfaces to help in separating concerns expressed in a language-independent IDLexpressed in a language-independent IDL interaction points for ‘signals’ as well as interaction points for ‘signals’ as well as

operationsoperations

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

Component model

load()load()unload()unload()

container runtimecontainer runtime

containerscontainers run-time environment for componentsrun-time environment for components containers may be implemented as OS containers may be implemented as OS

processes, but not necessarilyprocesses, but not necessarily load() unload() services available from both load() unload() services available from both

inside and outside the containerinside and outside the container

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

Component model

load()load()unload()unload()

container runtimecontainer runtime

receptaclesreceptacles ‘‘anti-interfaces’ – express a service anti-interfaces’ – express a service

requirement rather than a service provisionrequirement rather than a service provision components may support any number of components may support any number of

receptacles to express a variety of receptacles to express a variety of requirements on its environmentrequirements on its environment

key to third party deployabilitykey to third party deployability

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

Component model

load()load()unload()unload()

bind()bind()unbind()unbind()

container runtimecontainer runtime

local bindinglocal binding only possible between interfaces and only possible between interfaces and

receptacles receptacles in same containerin same container assumed lightweight implementation (e.g. assumed lightweight implementation (e.g.

vtables) – more needed in case of mixed vtables) – more needed in case of mixed languageslanguages

container offers bind() and unbind() servicecontainer offers bind() and unbind() service

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

Further issues (1)

coping with distributioncoping with distribution to bind non-local components, we simply to bind non-local components, we simply

load the containers with components that load the containers with components that implement suitable protocols/ middlewareimplement suitable protocols/ middleware

we then delegate – locally bind the we then delegate – locally bind the application components to this ‘middleware’application components to this ‘middleware’

no inherent difference between ‘middleware’ no inherent difference between ‘middleware’ and ‘applications’ – both are just and ‘applications’ – both are just compositions of appropriate componentscompositions of appropriate components

middlewaremiddleware middlewaremiddleware

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

Further issues (2)

the the first-class bindingfirst-class binding pattern pattern a common pattern is to wrap (part of) the required a common pattern is to wrap (part of) the required

middleware functionality as a ‘distributed component’ middleware functionality as a ‘distributed component’ called a binding componentcalled a binding component

these are instantiated by a central factory which these are instantiated by a central factory which delegates to multiple local factory instancesdelegates to multiple local factory instances

a wide variety of binding types can be implementeda 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

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

Further issues (3)

component frameworkscomponent frameworks provide structure to component provide structure to component

compositions and constrain adaptationcompositions and constrain adaptation define roles and constraints for plug-insdefine roles and constraints for plug-ins act as run-time life support environments in act as run-time life support environments in

a particular doamin of functionalitya particular doamin of functionality e.g. a pluggable

protocols framework or first-class binding

types or the OpenORB

middleware...Transport plug-ins

BindingLayer

CommsLayer

ResourceLayer

BindingCF

ProtocolCF

BufferMgt. CF

BT implementations

Protocols Filters

Buffer policies

TransportMgt. CF

ThreadMgt. CF

Schedulers

MultimediaStreamingCF

...

Middleware Top CF

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

Further issues (4)

reflectionreflection support for configuring and reconfiguring support for configuring and reconfiguring

sets of componentssets of components inspection, adaptation, extension via inspection, adaptation, extension via

causally connected meta-models of aspects causally connected meta-models of aspects of underlying components and compositionsof underlying components and compositions

we provide a set of orthogonal meta-models we provide a set of orthogonal meta-models that expose different aspectsthat expose different aspects architecture interface interception resources