topic2 understanding middleware

Middleware

Sanjoy Sanyal (Tech for NonGeek)

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


In this section we are going into detail on the first aspect

Understanding MiddlewareOffers programming abstractions that hides the complexities

of bridging between heterogeneous platforms Middleware implements the functionality of the abstraction


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

Types of MiddlewareRPC-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

scenarioMessage-oriented middleware

Queuing systems for asynchronous interactions Message brokers

Application logic to transform and filter messages in queues


Developing Distributed Applications with RPC


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

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


Static Binding Dynamic Binding

Simple and EfficientTightly CoupledNot possible to use dynamic load balancing

The directory server can assist in load balancing Decoupling leads to flexibilityThere is additional cost of implementation

RPC functioning with Dynamic binding


ClientProcedure

Call

Client StubBind

Marshal Serialize

Client Process

Communication Module

Name and directory service (binder)

Query for server implementing the procedure

Address of server

ServerProcedure

Server Process

Server Stub

Register Un-

marshalDe-

serializeReceive Dispatch

Communication Module

Register server and procedure

Asynchronous Extension to RPC Conventional RPC uses a synchronous, procedural callAsynchronous RPC allows the client thread not to be

blockedThe 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


RPC Middleware Extension: DCE

Distributed Computing Environment (DCE) provided by the Open Software Foundation (OSF)

Provides RPC with additional services:


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

TP Monitors For long the dominant form of middlewareImplementations:

IBM (CICS), BEA (Tuxedo), Microsoft (MTS)Main goal is to support execution of distributed

transactionsHere 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


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


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 serverSeq. 4: When EOT is reached, the client stub notifies that transaction managerSeq. 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

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


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 commitBy saying that it is ready to commit a server guarantees that it will be able to commit the procedure even if failures occur subsequentlyIf 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)

Transactional RPC


Client1.BOT4. Procedure call10. EOT

Client Stub2. Register txn and create context5. Add txn id and context to call 11. Request commit14. Confirm termination

Client ProcessServer

9. procedure

Server Process

Server Stub6. 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 idRun 2PCNotify client of outcome

8. Lookup txn idRegister server for txn

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 databasesDone using stored procedures where

application logic is written within the scope of the database


TP Monitor FunctionalityFunctionality 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


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 GroupDistributed Component Object Model

(DCOM) and COM+ specific to Microsoft is another example


CORBA: System Architecture


Object Request Broker

financials Supply chain

distributeddocuments

information management

systemsmanagement

Vertical facilities

horizontal facilities

CORBA facilities

naming transactions events lifecycle time relationshipsproperties licensing

trader concurrency query security startupexternalizationcollection persistence

User Defined Objects

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 distributionStub is a proxy object that makes method

calls in the client look like they are local Skeleton similarly shields the server object


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


However, we will quickly learn how this is possible

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


Interface Repository Dynamic Invocation Interface

Stores IDL definitions for all objects known to the ORBApplications 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 propertiesClients are able to look for objects which have specified values (selling history or IT books)

How CORBA works



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

CORBA: Encapsulation & Advantages Client and server objects need not be implemented

in the same language or run on the same OSNeither needs to know in which

language/environment the object has been implemented

All a client needs to know is the Server’s IDL specificationAll 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


TP Monitors

Represents the convergence of TP monitors and Object Brokers


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


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


ClientService Provider

Message-Oriented Middleware (MOM)

ClientService 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

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


Interacting with a Message Queuing SystemQueuing 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)


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

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


CORBA Architecture: Explained

Component Description


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….)


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)

topic2 understanding middleware

Technology

server server stub

rpc client

nongeek client procedure

server binding

middleware middleware

nongeek remote procedure

client stub formats

client thread