Middleware a survey Johan Lukkien Department of Mathematics

Middleware: a survey Johan Lukkien Department of Mathematics & Computer Science Eindhoven University of Technology 10/3/2020 spring days on middleware 1

Contents • Part I – Some definitions – “Traditional” middleware • Part 2 – RFC 2768 – middleware as a layer – requirements and developments 10/3/2020 spring days on middleware 2

Definitions • . . . middleware is a general term for any programming that serves to "glue together" or mediate between two separate and usually already existing programs. (. . . ) • Software that provides a link between disparate applications. (Computeruser dictionary; Lycos tech dictionary) 10/3/2020 spring days on middleware 3

Definitons (cnt’d) • . . . middleware must allow the interoperability of the applications that are based on it. (Laurent Kott, General Delegate to Technology Transfers at INRIA. (2002)) • the intersection of the stuff that network engineers don’t want to do with the stuff that applications developers don’t want to do. (Kenneth J. Klingenstein ('99)) 10/3/2020 spring days on middleware 4

Definitions (cnt’d) • Middleware can be viewed as a reusable, expandable set of services and functions that are commonly needed by many applications to function well in a networked environment. (NGI workshop, '97) • . . . a customizable set of components which can be tailored to the needs of an application. (Middleware 2001) 10/3/2020 spring days on middleware 5

Elements of middleware • • • Networking Interoperability Not application Not network Legacy? Application API’s Middleware platform interface OS(incl. network) 10/3/2020 spring days on middleware 6

Something like this. . . • “Top-down” view: factor out common functionality of applications within a certain domain • “Bottom-up” view: hide complex problems that are applicationindependent 10/3/2020 spring days on middleware 7

Interoperability • A program on one system can access programs and data on another system (Bernstein, CACM, Vol. 39, nr. 2, 1996) 10/3/2020 spring days on middleware 8

“Traditional” middleware • Message Oriented Middleware (MOM) • Transaction Processing Monitors (TPMON) • Remote Procedure Calls (RPC) • Distributed Computing Environment (DCE) • Object Oriented Middleware (ORB, . . . ) 10/3/2020 spring days on middleware 9

Message Oriented Middleware (MOM) • Basic service: message transportation – point-to-point, channels – mostly asynchronous. . message queues – publish/subscribe: notification • Quality in delivery types – must or should arrive (e. g. , JMS) – durable: retain message across connection-loss • Message properties – priority – order – expiration time 10/3/2020 spring days on middleware 10

Transaction Processing Monitors • Transaction: series of communications satisfying the ACID properties – – atomic consistent isolation durable transaction is taken or not taken system invariants are maintained transient states not observable transaction is persistent • Associated strongly with distributed data(base) access – transactions implement business logic • Can be built on top of e. g. , MOM 10/3/2020 spring days on middleware 11

Remote Procedure Call • Maintain local procedure semantics • Generate server and client stub from IDL • Synchronous • No real middleware (no API) 10/3/2020 spring days on middleware 12

Distributed Computing Environment • Developed by the OSF (Open Systems Foundation) • Integrated environment offering distributed services – – thread service RPC, directory security file system & diskless support • Free source, C-based 10/3/2020 spring days on middleware 13

Distributed Computing Environment 10/3/2020 spring days on middleware 14

Object Oriented Middleware • Object oriented: data+method remote – DCOM (on top of COM, DCE), RMI (JAVA based), Corba (Object Request Brokers) • ORB as an intermediate (“bus”) – dynamically provide server-object references – variety of other tasks and services 10/3/2020 spring days on middleware 15

Benefits, goals • A simplification of distributed programming – client-server, peer-2 -peer, 3 -tier • Integration of heterogeneous systems – communication is protocol-based • Encapsulation of legacy systems • Abstraction from the transport facility • Think of an application as a dynamic collection of communicating components 10/3/2020 spring days on middleware 16

Contents • Part I – Some definitions – “Traditional” middleware • Part 2 – RFC 2768 – middleware as a layer – requirements and developments 10/3/2020 spring days on middleware 17

RFC 2768 • . . . middleware consists of services and other resources located between both the applications and the underlying packet forwarding and routing infrastructure. . . • but. . . there is no core set of middleware services in the sense that all applications require them. . . 10/3/2020 spring days on middleware 18

The protocol triangle • IP/everything tendency diverse applications – goal in the layering: connect everything – TCP/IP as basic interoperability divergence • Application needs are diverse – use transport layer for private purpose – no direct need to support standards 10/3/2020 spring days on middleware transport layer (TCP/IP) convergence diverse physical layers 19

RFC 2768 (cnt’d) • . . . although middleware could be conceptualized as hierarchical, or layered, such an approach was not helpful, and indeed has been problematic and unproductive in earlier efforts. . . • top-layer middleware • . . . the middleware of yesterday. . may become the fundamental network • bottom-middleware infrastructure of tomorrow. . . 10/3/2020 spring days on middleware 20

Muddle • Middleware: anything hidden within the transport layer of the network. . . – – – Web caching --- interception Network Address Translation Firewalls Proxy service. . • . . changing the end-to-end semantics of the internet (G. Huston, “The Middleware Muddle”, The Internet Protocol Journal, August 2001) 10/3/2020 spring days on middleware 21

Muddle (cnt’d) • Middleware: the (domain specific) layers between application and network facilitating – – – access to DBMS’s general message passing transaction processing remote procedure call/ remote method invocation. . • . . . and admitting a coherent view on distributed applications (D. Ritter, “The Middleware Muddle”, DBMS, May 1998) 10/3/2020 spring days on middleware 22

Elements of middleware • • • Networking Interoperability Not application Not network No set of layers Two cuts: – Internal Application API’s Middleware OS(incl. network) • API protocols – External • protocol 10/3/2020 spring days on middleware 23

Interoperability • A program on one system can access programs and data on another system (Bernstein, CACM, Vol. 39, nr. 2, 1996) • The ability of disparate distributed components to use available resources to achieve shared goals (Lukkien, IPA spring days 2002) – physical connection – information transport – protocols/interfaces on top 10/3/2020 spring days on middleware 24

Interoperability plays at all layers • A layer is defined by interfaces and protocol(s) machine boundary provided interface layer protocols required interface 10/3/2020 spring days on middleware 25

RFC 2768 (cnt’d) • Possible services (API) – environmental discovery • locality, resources, applications, . . – remote execution • presentation, computation – data management • manipulate, replicate, maintain consistency – process & resource management • coordination, Qo. S – security • authentication, authorization, accounting (AAA); • atomic execution 10/3/2020 spring days on middleware 26

Changing requirements • Support of mobility – ad-hoc & nomadic networking • disconnection is common -- no error – separate computations in time and space 10/3/2020 spring days on middleware 27

Cooperation modes • In time. . . – synchronous (RPC, TPMON, OOM) • communicate at the same time • disconnection is an error – asynchronous (MOM, tuple spaces) • computation separated in time • . . . and space – single, explicit data location • data as a --possibly inaccessible-- resource – shared data space & transferable ownership • computation separated in space • replication & consistency control 10/3/2020 spring days on middleware 28

Changing requirements • Support of mobility – ad-hoc & nomadic networking • disconnection is common -- no error – separate computations in time and space • Explicit control over resources – support for Qo. S under application control • applications make better decisions – context awareness support • transparency takes footprint • application needs it for core function 10/3/2020 spring days on middleware 29

Awareness vs. transparency • Advantages of layering – separation of concerns – abstraction; transparency • Disadvantages – lack of control at high level – unclear who can make the best decisions • within OS? within middleware? within applications? – resource claim • Transparency should just be an option! – support “context aware” applications 10/3/2020 spring days on middleware 30

Context awareness • Resources – – energy bandwidth & latency of networks processor capacity, memory network services • Physical infrastructure – neighbors – quality of connection – location • Location of data 10/3/2020 spring days on middleware 31

Changing requirements • Autonomous behavior – self configuration (at several layers) – reflection • inspection and adaptation of behavior (CCSR) – mobile code (agents, “device-drivers”) • Customization – components supporting several interfaces – provide “controls” for applications • Different distributed architectures – peer-to-peer – devices as service provides and service users 10/3/2020 spring days on middleware 32

Developments • Mobile middleware – aynchronous, context aware, decoupled in space • Tspaces (IBM), Lime, Java. Spaces, Globe (van Steen), XMIDDLE (UCL), Mo. Cha • “Automatic” behavior – within the network layer • addressing & naming for ad-hoc networking – at service level • service description, advertisement and discovery • JINI, UPn. P, Salutation, wireless Corba, OSGi – at application level • peer-to-peer, e. g. Pastry, Chord 10/3/2020 spring days on middleware 33

Developments • Quality of service support in middleware – security, bandwidth, timeliness, data consistency • XML as cure for all pains – XML protocol envelope: SOAP, GENA • Domain specific – – 10/3/2020 agent platforms high performance: the GRID mobile middleware in-home spring days on middleware 34

Concluding remarks • Definition of middleware depends on point of view – but don’t forget the protocol part • Tendency to increase “intelligence” in devices – deal with varying external conditions • No convergence to single middleware layer – domain-specific component in each middleware product – generalization and flexibility take resources 10/3/2020 spring days on middleware 35

Finally, • I skipped more than I mentioned. . . Thank you 10/3/2020 spring days on middleware 36