Middleware contd 1 What are the benefits of

Middleware (contd. ) 1

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

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

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

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

DCE Architecture and Services 6

The Object Management Architecture 7

Component Architectures of distributed systems • Microsoft’s Component Object Model (COM) – addresses packaging and deployment of binary component as well as cross-language interoperability • Java. Beans 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. 8

Types of middleware 1. 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 9

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

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 call(…) RPC Service 1) Marshal args 2) Generate ID 3) Start timer 8) Unmarshal 9) Acknowledge RPC Service message 4) Unmarshal 5) Record ID Remote Function fun(…) 6) Marshal 7) Set timer 11

Properties of RPC ü Language-level pattern of function call • easy to understand for programmer ü Synchronous request/reply interaction • natural from a programming language point-ofview • 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 12

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 fork(…) remote call join(…) Ó 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 13

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 local object A proxy object B OOM object request broker / object manager remote skeleton object B 14

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 15

Java Remote Method Invocation (RMI) • Distributed objects in Java public interface Print. Server extends Remote { int print(Vector print. Job) throws Remote. Exception; } • RMI compiler creates proxies and skeletons • RMI registry used for interface lookup 16

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 17

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), typedef sequence<string> Files; long (64 bit), short, interface Print. Server : Server { void print(in Files print. Job); 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 18

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) 19

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 20

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, Qo. S, . . . – e. g. use different marshalling strategy over unreliable wireless link 21

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. Server App. Message Server local message queues Network 22

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 23

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 MQclose MQput MQget Open a queue Close a queue Put message into opened queue Get message from local queue 24

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 25

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 26

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 27

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 http: //api. google. com/Google. Search. wsdl ü WSDL says how to use a web service ü UDDI helps to find the right web service • Exports SOAP API for access 28

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 Publisher subscribe publish Event Service publish notify subscribe notify Subscriber 29

Topic-Based and Content. Based Pub/Sub • Event Service matches events against subscriptions • Topic-Based What do subscriptions look like? Publish/Subscribe – Publishers publish events belonging to topic or subject – Subscribers subscribe to topic subscribe(Print. Job. Finished. Topic, …) Content-Based Publish/Subscribe – Publishers publish arbitrary events – Subscribers provide a filter based on content of events subscribe(type=printjobfinshed, printer=‘aspen’, …) • […] 30

Properties of Publish/Subscribe ü Asynchronous communication ü Publishers and subscribers are loosely coupled ü Many-to-many interaction between publishers and subscribers ü Scalable scheme for large-scale systems ü Publishers do not need to know subscribers ü Content-based pub/sub very expressive ü Information delivered to all interested parties 31

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 event Printer. Job. Finished { String printer; String print. File; int user. ID; } • Events are typed messages – Attributes for content-based pub/sub filtering 32

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) 33

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 34

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) -- Open. Doc • Allowing for the presentation and interchange of objects based on a document model facilitating the linking of a spreadsheet object into a report 35 document

Some ORBs • CORBA Software (http: //www. infosys. tuwien. ac. at/Research/Corba/softwar e. html) – Orbix (IONA) – Visi. Broker (Inprise) – Object. Broker (BEA) – Power. Broker (Expersoft) – ORB Plus (HP) – ORBacus (Object-Oriented Concepts, Inc. ) – NEO/Java. IDL (Sun. Soft) 36

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 37

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 38 middleware

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 39 * Source: Java-CORBA E. Arch. , expede. com

CORBA and Distributed Architectures * Source: Java-CORBA E. Arch. , expede. com 40

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 41

1 2 3 4 5 * Source: Visibroker Progammer’s Guide 42

* Source: Visibroker Progammer’s Guide 43

* Source: Visibroker Progammer’s Guide 44

What are considerations for using CORBA? • • Security Performance Fault-Tolerance Scalability 45

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

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 47 for IIOP traffic.

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 48 embedded and card-based systems.

COM Characteristics • COM is a very mature component architecture that has many strengths. – Thousands of third-party Active. X 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. 49

Microsoft. NET Framework 50

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

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

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

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/ ws 2001/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/cpsc 689/hohin/ fall 00/notes http: //www. darwinmag. com/learn/curve/column. html? Article. ID=93 www. ics. uci. edu/~muccini/ics 123 http: //www. iona. com/hyplan/vinoski/pdfs/IEEE-Where_is_Middleware. pdf Internet 2: middleware. internet 2. edu dsonline. computer. org/middleware/RM. htm www. cl. cam. ac. uk/Teaching/2003/ Dist. Sys 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/ spring 02/lectures 54