Middleware - An Introduction

Middleware – An Overview

INTRODUCTION TOMIDDLEWARE

Middleware is a software layer present between the OS and the application software. Application Programming Interfaces (APIs) are used to interact and communicate between different applications, across the distributed components.  It is a runtime environment where it facilitates connection of components, that are written in different languages and that run on different OS.

PREREQUISITES

A middleware basically requires

ü  Network communication (for communication b/w components in different hosts).

ü  Co-ordination (for managing  multiple communication)

ü  Reliability (types: Best effort, At-most-once, at-least-once, exactly-once)

ü  Scalability (to scale the system without changes in architecture or design)

ü  Heterogeneity (uniqueness).

MIDDLEWARECLASSIFICATION

          Based on the foresaid prerequisites, Middleware can be classified into 4 major Types, which are discussed below.                    

1. TRANSACTIONALMIDDLEWARE (TM)

Also called Transaction Processing (TP) monitors were proposed to support distributed synchronous transactions.  Their main function is to coordinate requests between clients and servers, which are able to process these requests.  TM clusters the service requests into transactions, which has to support ACID properties.

Typical products: IBM's CICS, BEA's Tuxedo, Transarc's Encina, etc.

ü  Network Communication: The client and the server components can exist in different hosts.  This makes the request carried in the network to be transparent to client and server components.

ü  Coordination: Two-phase commit protocol (2PC), used to coordinate the transactions, is based on the "prepare to commit phase" and the "commit phase". TM supports both synchronous and asynchronous communication.

ü  Reliability: The transaction is committed only when all processes involved are ready to commit. Fault-tolerance and reliability are promoted by the failure/recovery service. Transaction logs are maintained to undo changes. TM also supports message queues (enabling reliability) and DBMS (assuring fault-tolerance).

2. MESSAGE ORIENTEDMIDDLEWARE (MOM)

Message Oriented Middleware (MOM) enables a communication through messages.  Two types of MOM,

ü  Message Queuing

ü  Message Passing.

Message from one program is stored into a particular queue, identified by a name, which is later sent to a receiver.  This is called Message Queuing (indirect communication model).  In the Message Passing (direct communication model), the information is sent to the concerned parties. After subscribing, the client receives any message relevant to a subscribed topic. This is called publish-subscribe (pub/sub) model (the ability to subscribe to the interested subjects).

Typical products: IBM's MQ Series, Sun's Java Message Queue.

ü  Network Communication:  MOM uses messages, strings of bytes implies the applications exchange them. A message holds application data and control data (used to store, route, deliver, retrieve and track).  A reply message from server contains results of the service execution.

ü  Coordination: MOM supports synchronous communication, via message passing, which requires manual implementation in the client using triggers. Asynchronous communication (via message queuing) is accomplished as the message is passed to a server, without blocking a client (does not need to wait for a reply and can proceed with other actions).

ü  Reliability: Persistent queues, stored on hard disc, are used to attain fault tolerance.

ü  Scalability: It is affected by access transparency, migration and replication transparency. And the queues set up by administrators which are hard-coded.

ü  Heterogeneity: As marshalling is not automated, data heterogeneity is limited.

ü  Advantages:

Ø  Group communication (either all clients receive a delivery or none).

Ø  Reliability increases by the use of persistent queues and as MOM sends a message exactly-once.

ü  Disadvantages:

Ø  Scalability and heterogeneity support.

Ø  Due to lack of standards, doesn’t support portability.

ü  Where to use: where unwarranted network or components is used.

3. PROCEDURALMIDDLEWARE (PM)

Remote Procedure Calls (RPCs), developed by Sun Microsystems.  RPCs are supported by most OS, including most UNIX and MS Windows systems.

 Typical products: Open Software Foundation's Distributed Computing Environment DCE, Microsoft RPC Facility.

ü  Network Communication: RPC program have parameterized procedures, which remote clients invoke using TCP or UDP.  RPC connects the client to the server components using stub (a dummy server).  It holds every function that a client could call.  On a need for a service, the client requests the server.  IDL compiler in stubs automate marshalling and un-marshalling.

ü  Coordination: A RPC client is blocked until the remote procedure is executed or an error occurs making it a synchronous communication.

ü  Reliability: PM possesses an at-most once reliability. An exception returns on the failure of RPC. RPCs' communication is reliable based on TCP/IP protocol.

ü  Scalability: As RPCs lack replication mechanisms, the scalability is limited.

ü  Heterogeneity: The heterogeneity in RPCs is realized via IDL (Interface Definition Language). It can define Language independent interfaces that signifies relationship between servers and clients are defined by RPCs using IDL.

ü  Advantages:

Ø  RPC has a good heterogeneity as it binds multiple OS and programming languages.  Marshalling and un-marshalling are automatically generated.

ü  Disadvantages:

Ø  Limited scalability as no direct support for asynchronous communication, replication and load balancing.

Ø  As many errors are handled within the program, fault tolerance is worse.

ü  Where to use: RPCs can be used in small applications for point-to-point communication.

4. OBJECT ORIENTEDMIDDLEWARE (OOM)

ü  Object middleware, evolved from extending RPCs with the inclusion of object-oriented concepts like inheritance, object oriented middleware came into existence.  OOM supports remote object referencing and operations on them.  Typical products: OMG's CORBA, Microsoft COM, Java RMI and Enterprise Java Beans.

ü  Network Communication: OOM supports distributed object requests. With reference to a server object on another host, by the client, it can request an operation.  Marshalling is automated in client and server stubs.

ü  Coordination: The client remains blocked as OOM basically supports a synchronous communication. Both deferred synchronous and asynchronous (e.g. CORBA) is also supported. Server objects are started on demand or remain active. OOM coordinates concurrent access to shared resources using threading.

ü  Reliability: By default, at-most-once reliability is set.  Exceptions are used to handle errors on component requests. Messaging exactly-once (CORBA) and fault-tolerance provide reliability.

ü  Scalability: It remains limited, though some support load-balancing. Replication support provided by Enterprise Java Beans increases scalability.

ü  Heterogeneity: Heterogeneity is widely supported via CORBA and COM, both supporting multiple programming language bindings and Java/RMI with its JVM.

ü  Advantages:

Ø  As most OOM products support for messaging and transactions, it can replace other three types of middleware in many different aspects.

ü  Disadvantages: Lack of scalability.