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

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

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

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

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

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:

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 Communication • Message content expressed in XML • Simple Object Access Protocol (SOAP) • Lightweight protocol for sync/async communication • Use well-known web standards for distributed computing 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 • Publisherspublishevents (messages) • Subscribers express interest in events with subscriptions • Event Servicenotifies interested subscribers of published events • Events can have arbitrary content or name/value pairs subscribe publish Subscriber Publisher notify Event Service subscribe publish Publisher Subscriber notify subscribe publish Publisher Subscriber 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 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

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 filtering event 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. 1 2 3 4 5 * Source: Visibroker Progammer’s Guide

43. * Source: Visibroker Progammer’s Guide

44. * Source: Visibroker Progammer’s Guide

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

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