Middleware

                 Today, industries need to transform their client/server infrastructures into services-oriented setups to stay competitive. Focus of IT has shifted from a technology-centric approach to a flexibility-driven approach measured in time-to-delivery and ability to change.

Though it is universally accepted that service-oriented architectures implementations lead to quantifiable benefits, yet in practice, their adoption has been sluggish.

The strategy to remedy this situation is via middleware.

In the computer industry, middleware is a general term for any programming that serves to "glue together" or mediate between two separate and often already existing programs.

In essence, Middleware is a computer software that interconnects software components or applications. This software consists of a set of enabling services that allow multiple processes running on one or more machines to interact across a network. Middleware is especially integral to modern information technology based on XML, Web services, and service-oriented architecture.

A common application of middleware is to allow programs written for access to a particular database to access other databases. Typically, middleware programs provide messaging services so that different applications can communicate.

   How middleware evolved

Till 1980 s most of computing was based on central host computers equipped

with powerful processors and memory. Users interact with the host through the terminals that captures keystrokes and sends the information to host. A major bottleneck for this architecture was that the processing power was limited to that of central host system, over dependence on the vendor for application software, lack of support for GUI and access to multiple databases. The mainframes prevalent at that time were based on this architecture. With advent of PC s the files were downloaded from the shared location, processed and uploaded back to file server. This had major drawback as it generated too much of network traffic. However with emergence of client /server architecture, the computing power or process management was distributed between the client and server.

For example client could query database server using relational database management system (DBMS) through standard query language (SQL). The results of query are sent to the client, which then manipulates and processes the data. This two-tier client/server architecture has limitation as the number of users grows beyond certain limit, due to the fact that server has to maintain a dialog of connection even when client is idle. Moreover any changes in application or parameter would entail changes at all clients like a change in VAT rate would need update on all the users’ workstation. To overcome these limitations middle-tier was added between the user system interface client environment and database management server environment. The middle tier or middleware is now one of the emerging technologies in client server paradigm. It provides for connectivity across heterogeneous platform and for more generalization of Application Programming Interface (API) than operating system or network services.

      Application Programming Interface (API): In order to fully understand middleware, one must first understand the concepts surrounding Application Programming Interfaces (APIs). The API, by definition, is a software program that is used to request and carry out lower-level services performed by the computer’s operation system or by a telephone system’s operating system.

In a Windows environment, APIs also assist applications in managing windows, menus, icons, and other GUI elements. In short, an API is a “hook” into software. An API is a set of standard software interrupts, calls, and data formats that application programs use to initiate contact with network services, mainframe communications programs, telephone equipment or program-to-program communications. For example, applications use APIs to call services that transport data across a network. Standardization of APIs at various layers of a communications protocol stack provides a uniform way to write applications. This technology is a way to achieve the total cross-platform consistency that is a goal of open systems.

    Middleware Basic

As the distributed model of enterprise computing has become more common, the term middleware has acquired numerous meanings that would allow it to be just about any piece of software that sits between systems. Terms such as enterprise application integration (EAI) and extensible markup language (XML) often are mistakenly used to describe middleware.

In the strict sense, middleware is transport software that is used to move information from one program to one or more other programs, shielding the developer from dependencies on communication protocols, operating systems, and hardware platforms. Middleware provides the “plumbing” necessary for applications to exchange data, regardless of the environment in which they are running. Transactions, data broadcasts, EAI packages, and XML data often ride on middleware in the enterprise.

The concept of middleware dates back to the 1980s when companies wanted one package to move data between mainframes, databases, and user terminals. Modern middleware extends this concept to the widespread distribution of data in real time across a remarkable variety of servers, clients, and sites. Middleware as used in this sense tends to be message-oriented. That is, data is sent between systems in messages, which are similar to data packets on the network. These messages have headers that indicate the destination and payloads of varying sizes and formats that contain the actual data. Message- oriented middleware (or MOM) originally appeared in the form of message queues.

When a message was sent to another system, it was stored in a message queue on the destination system. Whenever the destination system needed the data, it looked in the queue for the message. If it was there, the message was retrieved; if not, the system would wait until the data arrived in the queue. This approach proved reliable, but slow. It still is used today in many transaction-oriented environments, where security of transactions and integrity of message delivery is a high priority. A second model, called publish and subscribe (or pub/sub), evolved from the need to deliver messages in real time, especially to a large number of clients. In the pub/sub model, clients register for certain kinds of messages they are interested in, and a server sends the clients those messages in real time. The emphasis of the pub/sub model is to send data from one server to many clients as fast as possible. Typical applications might be stockbrokers needing the latest prices on certain bonds or equities. These prices typically are sent in real time to all brokers who subscribe to this information. One company today, Talarian Corp., combines the two models of MOM: its product SmartSockets delivers messages in real time with the reliability and integrity of message queuing. In fact, SmartSockets can be installed as either a pub/sub implementation or a message-queuing package.

 Categories of Middleware

The previous section briefly introduced the two types of message-oriented middleware. Other types of middleware are commonly found today performing narrow functions.

The middleware market can be broken into five different segments:

1. Transaction processing(TP) monitors
2. Message-oriented middleware (MOM)
3. Remote procedure calls(RPC)
4. Object request brokers(ORB)
5. Homegrown middleware solutions

Transaction Processing Monitors

              Typically, transaction-processing (TP) monitors are not used for general purpose program-to-program communication. Rather, they provide a complete environment for transaction applications that access relational databases. In TP monitors, clients invoke remote procedures that reside on servers, which also contain a SQL database engine. Procedural statements on the server execute a group of SQL statements (transactions), which either all succeed or all fail as a unit. The applications based on transaction servers are called on-line transaction processing (OLTP). They tend to be mission-critical applications that require a rapid response 100% of the time and tight controls over the security and integrity of the database. The communication overhead in this approach is kept to a minimum because the exchange typically consists of a single request/reply (as opposed to the multiple SQL statements required in database servers). TP monitors provide application development tools (such as user interaction and database interfaces), system administration (such as security and tuning), and transaction execution (such as scheduling and load balancing). X/Open, a vendor-neutral standards group, has done a considerable amount of work toward defining a process model and related services interfaces for distributed processing applications. Most vendors have pledged to support some or most aspects of the X/Open model. TP monitors should be considered when transactions need to be coordinated and synchronized over multiple databases. TP monitors tend to be heavyweight and expensive, and they require a great deal of expertise to implement properly. Most TP vendors have a large service side to their business.

Message-oriented middleware (MOM)

                In general, MOM products work by passing information in a message from one program to one or more other programs. The information can be passed asynchronously, where the sender does not have to wait for a reply. MOM products, in general, cover more than just passing information; they usually include services for translating data, security, broadcasting data to multiple programs, error recovery, locating resources on the network, cost routing, prioritization of messages and requests, and extensive debugging facilities. Unlike both ORB and RPC products, MOM, in general, does not assume the system has a reliable transport layer underneath. MOM tries to address the problems that surface when the transport layer is unreliable, as occurs when programs must communicate over a WAN or over the Internet.

Two different types of MOM have emerged:

1. Message queuing

2. Message passing

Message Queuing

In message queuing, program-to-program communications occur via a queue, which is typically a file. It allows programs to send and receive information without having a direct connection established between them. A program simply gives messages to the message queuing service, identifying by name the queue in which it wishes the message to be placed. The message queuing service acts as an intermediary, and the mechanism by which the message is transmitted is completely hidden from the application programs.

In large, enterprise-wide applications, queues can be set up to forward the messages to other queues. Message queuing provides safe storage of information and is most appropriate where applications cannot be connected directly (for example, in mobile computing). However, message queuing tools require considerable configuration to set up correctly and performance can be poor. If access to a queue is lost for any reason, the entire system can be affected.

Message Passing (Publish-Subscribe)

Message passing has proven popular for building large, distributed applications. This approach differs from message queuing in that rather than oblige applications to retrieve the information they request, the information is more efficiently pushed to the interested parties. One increasingly popular flavor of message passing uses a model of communication known as publish-subscribe (pub/sub). In pub/sub, programs subscribe to (register interest in) a subject. Programs also publish (send) messages to the subject. Once a subject has been subscribed to by a program, the program will receive any messages published to that subject in the distributed application. Subjects are defined by the application developer. In traditional network applications, when two processes must communicate with each other, they need network addresses to begin communicating. If a process wants to send a message to many other processes, it first would need to know the physical network addresses of the other processes and then create a connection to all those processes. This architecture does not scale well because configuration is complicated and tedious. The publish subscribe communications model provides location transparency, allowing a program to send the message with a subject as the destination property while the middleware routes the message to all programs that have subscribed to that subject. MOM vendors typically implement publishsubscribe with a set of agents that maintain a realtime database, listing which programs are interested in which subjects. A program publishes a message by connecting with one of the agents (it may or may not be on the same machine) and sending the message to it. The agent then routes the message to the appropriate programs. Often, the pub/sub middleware has greater fault tolerance because the agents can perform dynamic routing of the messages as well as provide hot fail over should any of system fail. Pub/sub is most appropriate for highly distributed applications where fault tolerance and high performance are important. It does not work well in situations where processes may be disconnected from the network for long periods of time.

Conclusion

                     In this short paper, we have given a concise overview of the distributed object technology supported by the mature part of the OMG/CORBA standard that is widely implemented by CORBA products. We have discussed the object model and its availability in the OMG interface definition language, we have discussed different programming language bindings, the object management architecture and the components that are involved when an object request is make. Finally, we have given a brief overview of the different object services that have been accepted so far.

The literature reports about a number of successful usages of OMG/CORBA for building distributed system architectures.[Emmerich et al., 2001] reports about such a use for integrating different systems of the trading department of a large German bank.

A considerable effort is spent by the OMG now on the definition of Domain Interfaces. Those will standardize interfaces that can be demonstrated to be common within a particular vertical market segment. The OMG has created different task forces for these domains. Among those are task forces for business objects, finance, electronic commerce, telecommunication, health care and manufacturing. More taskforces are going to be started.

The CORBA object model only supports interactions between one client and one server object. Moreover, in order to achieve integration the client object needs to be changed to invoke a client stub or use the dynamic invocation interface. The CORBA Component Model that is part of the CORBA 3.0 standardization effort [Siegel, 1999] will address these issues and allow more exible ways of integrating client and server objects. In particular CORBA components can have multiple interfaces and they can publish and subscribe to event-based communication. CORBA components also solve some of the difficulties in achieving enterprise computing, such as the difficulties in implementing twophase commit transactions or persistence, by providing a container-based programming model, similar to the one known from Enterprise Java Beans [Monson-Haefel, 1999].

Most current CORBA products are only of limited use in real-time and embedded systems because all requests have the same priority. Moreover the memory requirements of current middleware products prevent deployment in embedded systems. These problems have been addressed by various research groups. TAO [Schmidt et al., 1998] is a real-time CORBA prototype developed that supports request prioritization and the definition of scheduling policies. The CORBA 3.0 specification [Siegel, 1999] builds on this research and standardizes real-time and minimal middleware.