Middleware facilitates interactions between applications across different computing platforms by providing programming abstractions. Common types of middleware include RPC-based systems, transaction processing (TP) monitors, object brokers, and message-oriented middleware. RPC extends procedure calls to work remotely, while TP monitors add transaction management to distributed RPC calls. Object brokers like CORBA standardize object distribution, and message queues in message-oriented middleware enable asynchronous communication.

1. Middleware Sanjoy Sanyal (Tech for NonGeek)

2. Middleware Middleware facilitates and manages the interaction between applications across heterogeneous computing platforms Three different aspects: Middleware in sub-systems that are physically close to each other Middleware in systems that are completely different applications Middleware in Web applications Sanjoy Sanyal (Tech for NonGeek) In this section we are going into detail on the first aspect

3. Understanding Middleware Offers programming abstractions that hides the complexities of bridging between heterogeneous platforms Middleware implements the functionality of the abstraction Sanjoy Sanyal (Tech for NonGeek) Remote Procedure Call Sockets TCP/UDP IP A simple example Remote Procedure Call: Hides communication details behind a procedure call Sockets: operating system level interface to the underlying communication protocols Underlying communication protocol

4. Types of Middleware RPC-based systems Infrastructure to transform procedure calls to remote procedure calls TP monitors At a basic level, RPC with transactional capability Object brokers Platforms to support invocation of remote objects Object monitors Convergence of TP Monitors and Object brokers in a OO scenario Message-oriented middleware Queuing systems for asynchronous interactions Message brokers Application logic to transform and filter messages in queues Sanjoy Sanyal (Tech for NonGeek)

5. Developing Distributed Applications with RPC Sanjoy Sanyal (Tech for NonGeek) Client Code Client Stub Language specific call interface Development Environment IDL Compiler IDL Sources Interface headers IDL Server Stub Language specific call interface Server Code Client Process Step 1: Define the interface for the procedure. This is done using an interface definition language (IDL). The IDL provides an abstract representation of the procedure in terms of input and output parameters. Step 2: Compile the IDL description. Client Stub is a piece of code compiled and linked to client When a client makes a remote call the stub takes care of: Locating the server ( binding) Formatting the data ( Marshalling and serilaizing ) The stub is a proxy for the procedure implemented by the server Server Stub implements the Server side of the invocation Receives the invocation from the client stub Formats the data ( unMarshalling and de- serilaizing ) Invokes the actual procedure call at the server Forwards the results to the client stub

6. Binding in RPC Client creates a local association ( handle to) a server Static Binding Client stub is hardcoded to already contain the handle of the server where the procedure lies Dynamic binding Uses a name and a directory server to resolve server addresses based on signature of procedures Sanjoy Sanyal (Tech for NonGeek) Static Binding Dynamic Binding Simple and Efficient Tightly Coupled Not possible to use dynamic load balancing The directory server can assist in load balancing Decoupling leads to flexibility There is additional cost of implementation

7. RPC functioning with Dynamic binding Sanjoy Sanyal (Tech for NonGeek) Client Procedure Call Client Stub Bind Marshal Serialize Client Process Communication Module Name and directory service (binder) Query for server implementing the procedure Address of server Server Procedure Server Process Server Stub Register Un-marshal De-serialize Receive Dispatch Communication Module Register server and procedure

8. Asynchronous Extension to RPC Conventional RPC uses a synchronous, procedural call Asynchronous RPC allows the client thread not to be blocked The communication handle returns control to the client program immediately after sending request How this works? The stub provides two entry points – one to invoke the procedure and one to obtain the results of the invocation The stub extracts the input parameters from a client call and returns control to client The stub makes a call to server and waits for a response Later the client makes a second call for the resuts Sanjoy Sanyal (Tech for NonGeek)

9. RPC Middleware Extension: DCE Distributed Computing Environment (DCE) provided by the Open Software Foundation (OSF) Provides RPC with additional services: Sanjoy Sanyal (Tech for NonGeek) Additional Service Description Cell directory server Sophisticated name and directory server used to create and manage RPC domains that can exist over the same network Time Service Provides mechanisms for clock synchronization across all nodes Thread service Support to thread and mutiple processors Distributed File Service Support to sharing of data files Security Service Support for authentication and secure communication

10. TP Monitors For long the dominant form of middleware Implementations: IBM (CICS), BEA (Tuxedo), Microsoft (MTS) Main goal is to support execution of distributed transactions Here there are > 1 entity and > 1 procedure calls Conventional RPC treats the procedure calls (wrongly) as independent TP monitors extend the RPC protocol with the ability to wrap a series of RPC invocations into a transaction so if… … group of procedure calls is committed all have been … group of procedure calls is aborted , as if is that all have been Sanjoy Sanyal (Tech for NonGeek)

11. TP Monitors: How it works? Procedure calls enclosed within transactional brackets (BOT & EOT) are treated as one unit. A transaction management module coordinates interaction between clients and servers Sanjoy Sanyal (Tech for NonGeek) Seq. 1: When it encounters a BOT, the Client Stub contacts the transaction manager to create a transactional identifier and a transactional context for the sequence of calls. Seq. 2: When the Client calls one of the Servers, the server stub extracts the transactional identifier and notifies the transaction manager that it is participating and forwards the call as a normal call. Seq. 3: The same is done when the client invokes a second server Seq. 4: When EOT is reached, the client stub notifies that transaction manager Seq. 5: The transaction manager initiates a two-phase commit (2PC) protocol to determine the outcome of the transaction Seq. 6: The transaction manager informs the client stub once the protocol terminates

12. 2 PC Protocol Standard mechanism for guaranteeing atomicity in distributed information systems First a part of CICS and then standardized by the Open Group within the X/Open Specification Sanjoy Sanyal (Tech for NonGeek) The transaction manager executes the commit in two phases: Phase 1: It contacts each server involved in the transaction by sending a prepare to commit message asking whether the server is ready to execute a commit By saying that it is ready to commit a server guarantees that it will be able to commit the procedure even if failures occur subsequently If the server could not complete the transaction it replies abort Phase 2: The transaction manager examines all the replies received and if all of them are “ready to commit” it instructs each server to commit the changes performed If there is at least one abort (or a lack of responses) it instructs all servers to abort the transaction Fault tolerance is achieved through logging (writing the state of the protocol to persistent storage)

13. Transactional RPC Sanjoy Sanyal (Tech for NonGeek) Client 1.BOT 4. Procedure call 10. EOT Client Stub 2. Register txn and create context 5. Add txn id and context to call 11. Request commit 14. Confirm termination Client Process Server 9. procedure Server Process Server Stub 6. Extract context and txn id 7. Register server for txn 13. Participate in 2PC Register server and procedure Transaction manager 3. Create txn id Register txn Regsiter txn for client Return txn id 8. Lookup txn id Run 2PC Notify client of outcome 8. Lookup txn id Register server for txn

14. TP-lite and heavy TP-heavy systems provide rich tools and middleware functionality TP-lite systems are implemented as a 2-tier system to provide an RPC interface to databases Done using stored procedures where application logic is written within the scope of the database Sanjoy Sanyal (Tech for NonGeek)

15. TP Monitor Functionality Sanjoy Sanyal (Tech for NonGeek) Functionality Description RPC Support IDLs, name and directory servers, security and authentication, stub compilers …. Programming abstraction deal with T-RPC BOT, EOT, and may include additional callback and workflow mechansisms (on commit, on abort) Transactional Manager for implementing TRPC Transaction Manager functionality: logging, recovery, locking Monitor Systems Scheduling threads, assigning priorities, load balancing, replication, starting and stopping components Run-time environment Provides the resources and services applications may need (transactional services, security services, transactional file systems…) Specialized Components Ranging from proprietary protocols for interacting with mainframes to persistent queuing systems for asynchronous interaction Tools For installing, managing and monitoring the performance of all components

16. Object Brokers Middleware infrastructure that support the development of distributed object-oriented applications CORBA (Common Object Request Broker Architecture) is the most common example Developed in the early 1990s by the Object Management Group Distributed Component Object Model (DCOM) and COM+ specific to Microsoft is another example Sanjoy Sanyal (Tech for NonGeek)

17. CORBA: System Architecture Sanjoy Sanyal (Tech for NonGeek) Object Request Broker financials Supply chain distributed documents information management systems management Vertical facilities horizontal facilities CORBA facilities naming transactions events lifecycle time relationships properties licensing trader concurrency query security startup externalization collection persistence User Defined Objects

18. How CORBA works Objects declare their interface so that clients are aware of the methods it provides Mechanisms used are similar to RPC and support OO concepts such as inheritance/polymorphism IDL compiler generates a stub and a skeleton which hide the distribution Stub is a proxy object that makes method calls in the client look like they are local Skeleton similarly shields the server object Sanjoy Sanyal (Tech for NonGeek)

19. Dynamic Service Selection and Invocation The IDL compiler statically generates a stub specific to a service interface CORBA allows client applications to dynamically discover new objects, retrieve their interfaces and construct invocations of this object on the fly even if no stub has been generated and linked to the client However, this is not used as the client object must understand service properties which requires a shared ontology between clients and service providers Sanjoy Sanyal (Tech for NonGeek) However, we will quickly learn how this is possible

20. Dynamic Service Selection and Invocation: How? To dynamically construct a method invocation: interface repository & dynamic invocation interface components To identify services needed by the client: Naming and Trader Services Sanjoy Sanyal (Tech for NonGeek) Interface Repository Dynamic Invocation Interface Stores IDL definitions for all objects known to the ORB Applications can access the repository to browse, edit or delete IDL interfaces Provides operations such as get_interface and create_request that can be used by clients to browse the repository and dynamically construct the method invocation Naming Service Trading Service Allows for retrieval of object references based on the name of the service needed Clients are able to look for objects implementing a certain interface (Purchasing books) Allows for retrieval of services based on their properties Clients are able to look for objects which have specified values (selling history or IT books)

21. How CORBA works Sanjoy Sanyal (Tech for NonGeek) Object Request Broker Dynamic Invocation Interface Application object (client) IDL of service provider stub Application object (client) IDL compiler (client side) IDL compiler (server side) Application object (service provider) skeleton Interface repository

22. CORBA: Encapsulation & Advantages Client and server objects need not be implemented in the same language or run on the same OS Neither needs to know in which language/environment the object has been implemented All a client needs to know is the Server’s IDL specification All method calls flow thru the ORB where invocation parameters are converted into a common data format The data parameters are converted back at the skeleton This allows development flexibility on both client and server sides Sanjoy Sanyal (Tech for NonGeek)

23. TP Monitors Represents the convergence of TP monitors and Object Brokers Sanjoy Sanyal (Tech for NonGeek)

24. Message Oriented Middleware Supports asynchronous forms of interaction Evolved from asynchronous versions of RPC and queuing systems of TP monitors Well known MPM platform: IBM WebSphere, Microsoft MSMQ, WebMethods Enterprise, CORBA messaging service Sanjoy Sanyal (Tech for NonGeek)

25. MOM Basics Message is a structured data set characterized by: A Type (typically XML) A set of <name,value> pairs Clients and service providers communicate by exchanging messages Sanjoy Sanyal (Tech for NonGeek) Client Service Provider Message-Oriented Middleware (MOM) Client Service Provider Message-Oriented Middleware (MOM) Client sends a message The service provider servers the request by another message Note : to the MOM all objects are alike the distinction between clients and service providers depends on the context

26. Message Queues Messages sent by the MOM clients are placed in a queue When the recipient is ready to process a new message it invokes the MOM to retrieve the first message in the queue Advantages: Recipients do not have to continuously listen for new messages and process them right away – they do so when they can More robust to failures – if the application is down or unable to send messages these will be stored in the queue Queues can be shared across applications – if they provide the same service they can be used for load balancing Sanjoy Sanyal (Tech for NonGeek)

27. Interacting with a Message Queuing System Queuing Systems provide an API that can be invoked to send messages or to wait for and receive messages Sending message is typically not a blocking operation receiving is Java Programmers use a standard API to interact with MOM systems: Java Message Service (JMS) Sanjoy Sanyal (Tech for NonGeek) In JMS each message is characterized by: A header, which includes meta data like the message type, expiration, priority Optional properties that extend the haeder metadata attributes for example to support compatibility with specific JMS implementations A body which includes the application-specific information Senders (receivers) first bind to a queue and then start sending (receiving) messages

28. Transactional Queues Transactional queuing is also called reliable queuing The MOM ensures that once a message is sent: it will be eventually delivered once and only once to the intended recipient (even if the MOM goes down) Messages are stored in a persistent storage Can be used to overcome failure situations: A set of message retrievals and notifications are bundled within an atomic unit of operation (all or nothing) Messages within the atomic unit are maintained by MOM and made visible for delivery only on completion of the entire operation Sanjoy Sanyal (Tech for NonGeek)

29. CORBA Architecture: Explained Sanjoy Sanyal (Tech for NonGeek) Component Description Object Request Broker Provides basic object interoperability functions CORBA Services Provide functionality commonly needed by most objects such as persistence, lifecycle management and security Accessible thru a standardized API CORBA facilities Provide higher level services needed by applications - Horizontal facilities: document management, internationalization, support for mobile agents - Vertical facilities: services specific to a market vertical (healthcare, education….)

30. Summary Middleware Offers programming abstractions that hides the complexities of bridging between heterogeneous platforms Middleware implements the functionality of the abstraction RPC provides basic form of distribution TP monitors extended RPC to become the dominant form of middleware Object brokers tried to standardize middleware platforms in a OO environment (superseded by J2EE and .NET) Queuing systems evolved into MOM middleware to cope with the demands of cluster architecture and enterprise integration applications (the material in this topic is based on Web Services: Concepts, Architectures and Applications by Alonso, Casati, Kuno, Machiraju) Sanjoy Sanyal (Tech for NonGeek)