Middleware (contd.)

1

Middleware(contd.)

2

What are the benefits of middleware?

• Simplicity: – In today's corporate computing environments, many applications

have to share data. – Putting middleware in the middle can mean each application

needs only one interface—to the middleware—instead of a separate interface to each application it needs to talk to.

– (However, if you're connecting just two applications to one another, it might actually be more complicated to introduce middleware than simply coding the two apps to talk to each other.)

• Persistence: Middleware can capture data and hold on to it until it has been recorded appropriately by all the applications or databases that need the information.

3

What are the benefits of middleware? (contd.)

• Services:– If your data needs to be checked for integrity, printed

out, reconciled with data from other applications, merged, split or reformatted, various kinds of middleware can handle those tasks efficiently.

• This means you don't have to rewrite those services again and again for each application that uses them.

– As middleware products evolve, the breadth of services they can provide grows.

– Incidentally, vendors that sell such robust products often try to disassociate themselves with the term middleware.

4

Distributed Objects and Distributed Processing

• Distributed objects have the biggest potential to solve a wide range of challenges faced by designers of large software systems.

• Some of these challenges include – component packaging, – cross-language interoperability, – interprocess communication, and– intermachine communication.

• We separate distributed object architectures into two categories:– component architectures and – remoting architectures.

• Component architectures focus primarily on component packaging and cross-language interoperability.

• Remoting architectures focus primarily on support for remote method invocation on distributed objects.

5

Main Remoting Architectures

• Open Software Foundation’s (OSF) Distributed Computing Environment (DCE) – which actually is a distributed processing environment based on

the Remote Procedure Call (RPC) paradigm (purely procedural)

• Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA). – The notion of component packaging and deployment has only

recently been added to CORBA 3.0.

6

DCE Architecture and Services

7

The Object Management Architecture

8

Component Architectures of distributed systems

• Microsoft’s Component Object Model (COM) – addresses packaging and deployment of binary component as well

as cross-language interoperability• JavaBeans and Enterprise Java Beans (EJB) component models

introduced by SUN Microsystems. • Both, COM and EJB address remoting to some extend:

– the COM model has been extended to Distributed COM (DCOM) using an extended version of DCE RPC as transport.

– EJB supports client/server communication based on Java Remote Method Invocation (RMI).

– RMI is special as it integrates closely with the Java language without requiring a special Interface Definition Language (IDL) to describe component interfaces accessible for remote invocations.

• In an evolutionary sense, Microsoft’s .NET is the newest and most advanced component architecture available in the market today.

9

Types of middleware1. Remote Procedure Call (RPC)

Historic interest

2. Object-Oriented Middleware (OOM)Java RMI

CORBA

Reflective Middleware

3. Message-Oriented Middleware (MOM)Java Message Service

IBM MQSeries

Web Services

4. Event-Based Middleware

Cambridge Event Architecture

10

Remote Procedure Calls

• Remote Procedure Calls (RPCs) enable the logic of an application to be distributed across the network.

• Most prominent examples:– SUN RPC, introduced with the network file system (SUN NFS), – DCE RPC, served as technical foundation of Microsoft’s COM.

• Object Request Brokers (ORBs) enable the objects that comprise an object-oriented application to be distributed and shared across heterogeneous networks. – Extending the procedural programming model of RPC, – Distributed object systems such as CORBA, DCOM, .NET, and

EJB enable processes to be run anywhere in the network.

11

Remote Procedure Call (RPC)

• Masks remote function calls as being local• Client/server model• Request/reply paradigm usually implemented with message passing• Marshalling of function parameters and return value

Caller RPC Service RPC Service RemoteFunction

call(…)

1) Marshal args

2) Generate ID3) Start timer

4) Unmarshal5) Record ID

6) Marshal7) Set timer

8) Unmarshal9)

Acknowledge

fun(…)

message

12

Properties of RPC Language-level pattern of function call

• easy to understand for programmer Synchronous request/reply interaction

• natural from a programming language point-of-view

• matches replies to requests• built in synchronisation

Distribution transparency• hides the complexity of a distributed system

Various reliability guarantees• deals with some distributed systems aspects of

failure

13

Disadvantages of RPC Synchronous request/reply interaction

• tight coupling between client and server• may block for a long time• leads to multi-threaded programming

Distribution Transparency• Not possible to mask all problems

Lacks notion of services• programmer not interested in server but in service

RPC paradigm is not object-oriented• invoke methods on objects as opposed to functions on

servers

fork(…)

join(…)

remote call

14

Object-Oriented Middleware (OOM)• Objects can be local or remote• Object references can be local or remote• Remote objects have visible remote interfaces• Masks remote objects as being local using proxy objects• Remote method invocation

object A

proxy object B

OOM OOM

skeleton object B

object B

local remote

objectrequestbroker

/object

manager

objectrequestbroker

/object

manager

15

Properties of OOM

Support for object-oriented programming model• objects, methods, interfaces, encapsulation, …• exceptions

Location Transparency• mapping object references to locations

Synchronous request/reply interaction• same as RPC

Services

16

Java Remote Method Invocation (RMI)

• Distributed objects in Java

public interface PrintServer extends Remote { int print(Vector printJob) throws RemoteException;}

• RMI compiler creates proxies and skeletons• RMI registry used for interface lookup

17

CORBA• Common Object Request Broker Architecture

– Open standard by the OMG (Version 3.0)– Language- and platform independent

• Object Request Broker (ORB)– General Inter-ORB Protocol (GIOP) for communication– Interoperable Object References (IOR) contain object location– CORBA Interface Definition Language (IDL)

• Stubs (proxies) and skeletons created by IDL compiler

– Dynamic remote method invocation

• Interface Repository– Querying existing remote interfaces

• Implementation Repository– Activating remote objects on demand

18

CORBA IDL• Definition of language-independent remote interfaces

– Language mappings to C++, Java, Smalltalk, …– Translation by IDL compiler

• Type system– basic types: long (32 bit),

long long (64 bit), short, float, char, boolean, octet, any, …

– constructed types: struct, union, sequence, array, enum– objects (common super type Object)

• Parameter passing– in, out, inout– basic & constructed types passed by value– objects passed by reference

typedef sequence<string> Files;interface PrintServer : Server { void print(in Files printJob);};

19

CORBA Services

• Naming Service– Names remote object references

• Trading Service– Attributes (properties) remote object references

• Persistent Object Service– Implementation of persistent CORBA objects

• Transaction Service– Making object invocation part of transactions

• Event Service and Notification Service– Asynchronous communication based on messaging

(cf. MOM)

20

Disadvantages of OOM

Synchronous request/reply interaction• So CORBA oneway semantics added and - • Asynchronous Method Invocation (AMI)• But implementations may not be loosely coupled

Distributed garbage collection• Releasing memory for unused remote objects

OOM rather static and heavy-weight• Bad for ubiquitous systems and embedded devices

21

Reflective Middleware

• Flexible middleware (OOM) for mobile and context-aware applications

• Interfaces for reflection– Objects can inspect middleware behaviour

• Interfaces for customizability– Dynamic reconfiguration depending on environment– Different protocols, QoS, ...– e.g. use different marshalling strategy over unreliable

wireless link

22

Message-Oriented Middleware (MOM)• Communication using messages

• Messages stored in message queues

• Optional message server decouples client and server

• Various assumptions about message content

Client App.

local messagequeues

Server App.

local messagequeues

messagequeues

Network Network Network

Message Server

23

Properties of MOM Asynchronous interaction

– Client and server are only loosely coupled

– Messages are queued

– Good for application integration Support for reliable delivery service

– Keep queues in persistent storage Processing of messages by intermediate message server

– Filtering, transforming, logging, …

– Networks of message servers Natural for database integration

24

IBM MQSeries• One-to-one reliable message passing using queues

– Persistent and non-persistent messages– Message priorities, message notification

• Queue Managers – Responsible for queues– Transfer messages from input to output queues – Keep routing tables

• Message Channels – Reliable connections between queue managers

• Messaging API:

MQopen Open a queue

MQclose Close a queue

MQput Put message into opened queue

MQget Get message from local queue

25

Java Message Service (JMS)

• API specification to access MOM implementations• Two modes of operation:

– Point-to-point• One-to-one communication using queues

– Publish/Subscribe• cf. Event-Based Middleware

• JMS Server implements JMS API• JMS Clients connect to JMS servers• Java objects can be serialised to JMS messages

26

Disadvantages of MOM Poor programming abstracting

• Rather low-level (cf. Packets)• Results in multi-threaded code• Request/reply more difficult to achieve

Message formats unknown to middleware• No type checking

Queue abstraction only gives one-to-one communication• Limits scalability

27

Web Services• Use well-known web standards for distributed computing

Communication• Message content expressed in XML• Simple Object Access Protocol (SOAP)

– Lightweight protocol for sync/async communication

Service Description• Web Services Description Language (WSDL)

– Interface description for web services

Service Discovery• Universal Description Discovery and Integration (UDDI)

– Directory with web service description in WSDL

28

Properties of Web Services

Language-independent and open standard SOAP is best of both worlds:

• Synchronous request/reply like OOM

• Asynchronous messaging like MOM

• Supports internet transports (http, smtp, ...)

• Uses XML Schema for marshalling types

WSDL says how to use a web service

UDDI helps to find the right web service

• Exports SOAP API for access

http://api.google.com/GoogleSearch.wsdl

29

Event-Based Middleware• Publishers publish events (messages)• Subscribers express interest in events with subscriptions• Event Service notifies interested subscribers of published events• Events can have arbitrary content or name/value pairs

Event ServiceSubscrib

er

Subscriber

Subscriber

Publisher

Publisher

Publisher

publish

publish

publish

subscribe

subscribe

subscribe

notify

notify

notify

30

Topic-Based and Content-Based Pub/Sub

• Event Service matches events against subscriptions• What do subscriptions look like?Topic-Based Publish/Subscribe

– Publishers publish events belonging to topic or subject– Subscribers subscribe to topic

subscribe(PrintJobFinishedTopic, …)

Content-Based Publish/Subscribe– Publishers publish arbitrary events– Subscribers provide a filter based on content of events

subscribe(type=printjobfinshed, printer=‘aspen’, …)

• […]

31

Properties of Publish/Subscribe

Asynchronous communicationPublishers and subscribers are loosely coupled

Many-to-many interaction between publishers and subscribersScalable scheme for large-scale systemsPublishers do not need to know subscribers

Content-based pub/sub very expressive Information delivered to all interested parties

32

Cambridge Event Architecture (CEA)

• Publish-Register-Notify Paradim– Standard middleware for building event-based systems– Direct communication between pubs and subs– Event Mediators decouple pubs and subs– Source-side filtering of events

• Events are typed messages– Attributes for content-based pub/sub filteringevent PrinterJobFinished {

String printer; String printFile; int userID;}

33

History and intro to CORBA• CORBA is a standard for object interoperability

– Support for different languages– Support for different platforms– Communications over the network– Additional services (e.g., security)

• CORBA is defined by the OMG (Object Management Group)– Begin since 1989– CORBA 1 was in 1991– Now, toward to CORBA 3– More information: http://www.omg.org

• CORBA is a component of OMA (Object Management Architecture)

34

What is the OMA?• Object Model and Interfaces (e.g., Domain Interfaces,

Application Interfaces)– Defines what a CORBA object is

• Common Object Request Broker Architecture (CORBA)– Standard for an ORB (Object Request Broker)– Defines the IIOP (Internet Inter-ORB Protocol) --

the standard for communication– Defines the Language interfaces and tools

35

What is the OMA?• Object Services -- common services

– Core services required to develop distributed architectures

– Naming -- allowing clients to find objects based on names

– Trading -- allowing clients to find objects based on their properties

– Others: Security, Transactions, event notification, .

• Common Facilities -- high-level services

– e.g., Distributed Document Component Facility (DDCF) -- OpenDoc

• Allowing for the presentation and interchange of objects based on a document model facilitating the linking of a spreadsheet object into a report document

36

Some ORBs

• CORBA Software (http://www.infosys.tuwien.ac.at/Research/Corba/software.html)– Orbix (IONA)– VisiBroker (Inprise)– ObjectBroker (BEA)– PowerBroker (Expersoft)– ORB Plus (HP)– ORBacus (Object-Oriented Concepts, Inc.)– NEO/JavaIDL (SunSoft)

37

Why CORBA?

• Need to share information and resources within and across diverse computing enterprises– CORBA is a Middleware Standard

– CORBA is a “Software Bus”

– CORBA is a Distributed Object Architecture

38

CORBA is a Middleware Standard

• Before CORBA, middleware was dominated by proprietary tools

• CORBA provides a standard that allows you to:– Develop applications using a common basis– Change CORBA products with minimal rewriting of code– Make objects running on different CORBA products

interoperate– Integrate third-party products that respect the standard

• CORBA is evolving to standardize other types of middleware

39

CORBA and the “Software Bus”• A standard architecture enabling you to plug components into

– Support different languages and platforms

– Connects everything up in a single architecture

• A basis for delivering reusable components

– A CORBA component can be accessed from any client technology

– A CORBA components has a clearly defined interface

* Source: Java-CORBA E. Arch., expede.com

40

CORBA and Distributed Architectures

* Source: Java-CORBA E. Arch., expede.com

41

How Does CORBA Work?

• Step 1: Write a specification for each object using IDL (Interface Definition Language)

• Step 2: Compile the IDL to generate client stub and server skeleton code

• Step 3: Write the client application code.• Step 4: Write the server object code.• Step 5: Compile the client and server code• Step 6. Start the server• Step 7: Run the client application

* Source: Visibroker Progammer’s Guide

42* Source: Visibroker Progammer’s Guide

12

34

5

43* Source: Visibroker Progammer’s Guide

44* Source: Visibroker Progammer’s Guide

45

What are considerations for using CORBA?

• Security

• Performance

• Fault-Tolerance

• Scalability

CORBA 3.0

• Provides well-defined packaging for producing components, quality of service, messaging and other technologies

• Full Java and Internet support– Java portability, XML integration

• Quality of Service management– Messaging, Realtime, Small footprint

• Distributed Component Model– Component-based development, scripting* Source: Soley, OMG

47

Recent CORBA 3.0 Additions• CORBA Component Model (CCM) –

– introduces the notion of server-side components into CORBA and addresses packaging and deployment for CORBA components.

– CCM provides for interoperability with EJB.• Objects passable by value (valuetypes) –

– valuetypes definitely improve integration with Java and also serve as basis for the XML/Value mapping (released as part of CORBA 2.3).

• Java-to-IDL Mapping –– this mapping allows Java RMI objects to interoperate over the network

like CORBA objects using CORBA object references.• XML/Value mapping –

– standardizes the representation of an XML document as a collection of native CORBA types.

• CORBA Firewall Specification – – allows firewalls to be configured for CORBA using access rules for IIOP

traffic.

48

CORBA 3.0 Additions

• CORBA Messaging – – encompasses both asynchronous and messaging-mode invocations

of CORBA objects as well as Quality of Service Control.• Real-Time CORBA –

– extends the CORBA architecture with resource control mechanisms for real-time applications running on a real-time operating system in a controlled environment.

• Fault-Tolerant CORBA – – standardizes redundant software configurations and systems that

give CORBA robust and reliable performance (when run on redundant hardware).

• Minimum CORBA – – defines a small-footprint CORBA configuration that is aimed at

embedded and card-based systems.

49

COM Characteristics

• COM is a very mature component architecture that has many strengths. – Thousands of third-party ActiveX controls (in-process

COM components) are available in the market today. – Microsoft and other vendors have built many tools

that accelerate development of COM-based applications.

• Advanced services such as Microsoft Transaction Server (MTS) and Microsoft Message Queuing Server (MSMQ) support development of enterprise multi-tier systems.– Microsoft has been using the name COM+ to identify

the bundling of the COM runtime with those services.

50

Microsoft .NET Framework

51

.NET Characteristics

• Distributed Computing: – .NET provides a remoting architecture that exploits open Internet standards,

including the Hypertext Transfer Protocol (http), Extensible Markup Language (XML), and Simple Object Access Protocol (SOAP).

• Componentization: – .NET extends the previous COM component model but provides a

significantly simpler way to build and deploy components.• Enterprise services:

– .NET supports the development of scalable enterprise applications without writing code to manage transactions, security, or pooling.

• Web paradigm shifts:– Over the last few years, web application development has shifted from

connectivity (TCP/IP), to presentation (HTML), to programmability (XML and SOAP). .NET enables software to be sold and distributed as a service.

• Maturity factors: – Although .NET is a relatively new framework, it builds upon the mature

COM+ technology and services.

52

Future Trends: Resource Management and Quality-of-Service

• Middleware abstractions provide resource management in a distributed system at a high level. – OS manages: communication, processing, storage

(memory/disks). – Middleware abstractions also are from an end-to-end

perspective, not just of a single host, which allows for a more global and complete view to a resource management system.

– Distributed objects are promising, as they not only encapsulate but also cleanly integrate all three kinds of resource into a coherent package.

– This completeness helps distributed resource management and makes it easier to provide for load balancing, mobility transparency, and overall system reliability.

53

New Capabilities

• Recent middleware frameworks, like the CORBA 3.0 Component Model (CCM), or the Microsoft .NET framework, allow the expression of non-functional component properties.– such as resource requirements, timing and security constraints,

or fault-tolerance assumptions on the component level using language constructs (like C# and .NET attributes) or component meta-data (like CCM’s deployment descriptors).

• Aspect-Oriented Programming (AOP) is a relatively new discipline that focuses on cross-cutting concerns – targeting many components of a system simultaneously and – non-functional component properties.

• AOP investigates software engineering approaches towards predictable component-based systems. – This research opens up new venues for middleware-based

architectures on the enterprise level.

54

References• OMG: www.omg.org/middleware/ • NSF: www.nsf-middleware.org/Middleware/ • CMU: www.sei.cmu.edu/str/descriptions/middleware.html • Resource center: www.middleware.org/ • kbs.cs.tu-berlin.de/teaching/ ws2001/cl/middleware_4.pdf • Bernstein, Philip A. "Middleware: A Model for Distributed Services." Communications of the ACM

39, 2 (February 1996): 86-97. • "Middleware Can Mask the Complexity of your Distributed Environment." Client/Server

Economics Letter 2, 6 (June 1995): 1-5. • courses.cs.tamu.edu/cpsc689/hohin/ fall00/notes • http://www.darwinmag.com/learn/curve/column.html?ArticleID=93• www.ics.uci.edu/~muccini/ics123• http://www.iona.com/hyplan/vinoski/pdfs/IEEE-Where_is_Middleware.pdf• Internet2: middleware.internet2.edu • dsonline.computer.org/middleware/RM.htm • www.cl.cam.ac.uk/Teaching/2003/ DistSys• Eckerson, Wayne W. "Three Tier Client/Server Architecture: Achieving Scalability, Performance,

and Efficiency in Client Server Applications." Open Information Systems 10, 1 (January 1995): 3(20).

• Schreiber, Richard. "Middleware Demystified." Datamation 41, 6 (April 1, 1995): 41-45.• lass.cs.umass.edu/~shenoy/courses/ spring02/lectures