By

Sudipta Dhara
Roll-1070100 Section-B
Submitted to the School of Computer Application.
In 4th Semesters seminar for the degree of

Master of Computer Application

KIIT University

Bhubaneswar, Orissa, India

ACKNOWLEDGEMENT
The satisfaction that accompanies the successful completion of any project work would be incomplete without expressing my gratitude that helped me in every part of the work, whose guidance and encouragement made this work. My sincere thanks to Dr. VEENA GOSWAMI, Dean, School of Computer Application for providing me good lab facilities. I express our deep sense of gratitude to DR J. R. MOHANTI, Associate Dean, School of Computer Application. I also take this humble opportunity to express my deep sense of gratitude to my seminar guide Prof. MANAS MUKUL, Prof. PRASANT KUMAR SWAIN who in all respect helped me tangibly from the beginning till the fulfillment of my seminar .His expert guidance and inspiration brought completion of the seminar. I would also like to thank to all my teachers who directly or indirectly supports me time to time.

Thank you & Regards. Sudipta Dhara (1070100) MCA 4th Semester

Sudipta Dhara (MCA-1070100), KiiT University

Contents
1. Introduction 2. How middleware evolved
Application Programming Interface (API)

1 2 3 4 6 6 7 9 10 11 12 15 16 18

3. Middleware Basic 4. Categories of Middleware

4.1 Transaction Processing Monitors 4.2 Message-oriented middleware (MOM) 4.3 Remote procedure calls (RPC) 4.4 Object request brokers(ORB) 4.5 Homegrown middleware solutions

5. OMG/CORBA 6. Middleware Tools 7. Conclusion 8. References

Figure- 0. Application Programming Interface (API) ----------------------- 3 Figure- 1. The Object Management Architecture----------------------------- 12 Figure- 2. Programming Language Binding to CORBA/IDL--------------- 13 Figure- 3. Components involved in Object Requests------------------------- 14

Sudipta Dhara (MCA-1070100), KiiT University

1. INTRODUCTION
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 timeto-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.

Sudipta Dhara (MCA-1070100), KiiT University

2.

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.

Sudipta Dhara (MCA-1070100), KiiT University

2.1. 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 computers operation system or by a telephone systems 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-toprogram 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.

Sudipta Dhara (MCA-1070100), KiiT University

[Figure-0] Application Programming Interface (API)

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

Sudipta Dhara (MCA-1070100), KiiT University

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

Sudipta Dhara (MCA-1070100), KiiT University

4. 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 4. 1. Transaction Processing Monitors Typically, transaction-processing (TP) monitors are not used for general purpose program-to-program communication. Rather, they provide a

Sudipta Dhara (MCA-1070100), KiiT University

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.

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

Sudipta Dhara (MCA-1070100), KiiT University

10

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

Sudipta Dhara (MCA-1070100), KiiT University

11

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.

4.3. Remote procedure calls (RPC)

RPCs have been around for a long time. They are one of the earliest forms of interprogram communication, and they operate at a very low level. From a programmers point of view, RPCs are easy to understand. The code invokes a procedure that is located on a remote system, and the results are returned. Generally, the application components communicate with each other synchronously, meaning they use a request/wait for- reply model. RPCs work well for smaller, simple applications where communication is primarily pointto-point (rather than one system to many). RPCs do not scale well to large, critical applications, as they leave many crucial details up to the programmer, such as the following:

Sudipta Dhara (MCA-1070100), KiiT University

12

1. Handling network or system failures 2. Handling multiple connections 3. Portability 4. Buffering and flow control Synchronization between processes Due to their synchronous nature, RPCs are not a good choice to use as the building blocks for enterprise-wide applications where high performance and high reliability are needed. The RPC standards have not evolved in any significant way during the last five years, primarily because of the emergence of the Object Request Brokers described in the next section.

4.4. Object request brokers (ORB)

Object Request Brokers (ORBS) can be thought of as languageindependent, object-oriented RPCs. There are two competing standards for ORBs: 1. CORBA, backed by more than 700 companies from the Object Management Group (OMG) 2. DCOM, backed by Microsoft (Javas Remote Method Invocation (RMI) could be considered an ORB, although it is useful primarily for facilitating

Sudipta Dhara (MCA-1070100), KiiT University

13

communication between two programs written in Java and does not address other programming languages as do both DCOM and CORBA.) ORBs are designed for use in projects that require a strict object-oriented approach, where objects are the only way. Like RPCs, ORBs are generally synchronous and operate in a point-to-point manner. In general, both CORBA and DCOM assume the system has a reliable communications layer, and they do not address the problems involved when this layer is not reliable. Early on, the OMG recognized that CORBAs request-reply communication was not going to be adequate for building true, enterprise-wide, mission-critical applications. Some of the CORBA vendors added proprietary extensions to their products to address these shortcomings. The OMG specified the CORBA Event Service, a standard set of services layered on top of CORBA, which brought most of the vendor extensions into the CORBA model. In 1998, the OMG approved the Asynchronous Messaging Service. However, this facility is not widely used in CORBA deployments today.

4.5. Homegrown middleware solutions

When companies first encounter the need for a middleware layer, they often have a specific problem to address that requires a modest solution. Rather than invest in a middleware package, smaller firms will allow their own development staff to write a middleware-like solution to solve the particular problem. Although initially workable, this approach tends to lack scalability and flexibility as new problems have to dovetail with the old solution. As a result,

Sudipta Dhara (MCA-1070100), KiiT University

14

supporting the homegrown middleware becomes expensive as it has to be customized and extended constantly generally by staff members who have never written middleware software before. The final result is an expensive solution that tends to break easily and does not scale well.

5.

Object Management Group (OMG)/Common

Below Figure 1 displays the Object Management Architecture of the

Object Request Broker Architecture (CORBA)

Object Management Group (OMG). It identifies different categories of objects of a distributed object system as well as an object request broker by means of which these objects communicate. CORBA services represent objects that

Sudipta Dhara (MCA-1070100), KiiT University

15

provide very basic services, which are required for the construction of distributed systems. Examples of these are naming, concurrency control, transactions, event notifications, relationships and many more. It is assumed that implementations of the CORBA standard provide most of these services. CORBA facilities are objects that are useful in the construction of distributed systems. Examples are a help facility or a printing and spooling facility. Domain Interfaces objects that are useful within particular application domain. Among others, the OMG is currently standardizing Domain interfaces for Health care, Telecommunication, Manufacturing and Finance. Finally, Application Objects are built for particular applications. Their construction averages CORBA services, CORBA facilities and the Domain Interfaces using the mechanisms provided by the CORBA object model.

The CORBA object model determines an informal semantics for object-oriented concepts. The concepts are defined in a way that they can be mapped to a large variety of programming languages. The object-model defines concepts for object and non-object types, operations and attributes exported by objects, typespecific exceptions that may be the object's integrity is violated. The model also includes a mechanism for subtyping by means of which object types inherit attributes and operations of their super types. The CORBA object model is used as a distributed system component model. Distributed system components are implemented by CORBA objects. Component types are implemented by object types. The services offered by components are determined by object type definition. A client component can interact with a server component by means

Sudipta Dhara (MCA-1070100), KiiT University

16

of object requests. These are messages that trigger the execution of an operation in a server object. System or type-specific failures that may occur are treated as exceptions that should be caught by the client to react on the failure.

The OMG Interface Definition Language (IDL) includes constructs for all the concepts of the CORBA object model. IDL is designed to be independent of a particular programming language, though its syntax is oriented towards C++. IDL is not computationally complete. It does not include language constructs to store variables or to express algorithms. As shown in Figure 2, the CORBA defines bindings to: C, C++, Smalltalk, Ada, Java and OO-Cobol. These programming language bindings determine how object types with their attributes, operations and exceptions are implemented in server objects and how clients can make object requests and catch exceptions the server may raise. Figure 3 shows the components that are involved in the interaction between object request broker, client and server objects at run-time. Both client and server objects initialize themselves using the ORB interface. The ORB interface also determines the operations that any server object inherits from the predefined root of the inheritance hierarchy. The client object issues the request

Sudipta Dhara (MCA-1070100), KiiT University

17

and uses either the static or the dynamic invocation interface. A static request is issued by calling a client stub that is generated from an IDL interface description. Static object requests are synchronous. A dynamic invocation is done using the dynamic invocation interface. The dynamic invocation interface supports both synchronous and deferred synchronous requests. After having issued a deferred synchronous request, control is given back to the client object until a point in time when it polls for the operation result. The object broker uses the object reference that is submitted by the client as part of the request in order to locate the server object. If necessary, the broker activates the object using an object adapter. The broker then invokes the implementation skeleton, which is also generated from the IDL interface definition of the client object. The skeleton finally calls the operation that was requested by the client.

Figure 3: Components involved in Object Requests

6. Middleware Tools

Condor

The "Condor" middleware supports mechanisms and policies for high throughput computing on collections of distributed computing resources, in

Sudipta Dhara (MCA-1070100), KiiT University

18

particular desktop grids and clusters. It is or was used in the Greedy and Seed projects. ARC The "Advanced Resource Connector" is the Globus-based middleware developed by the NorduGrid collaboration of the Scandinavian countries. It is or was used in the ATLAS, KnowARC, Seed, SMSCG and Swiss Bio Grid projects. gLite "gLite" is a further development of Globus and the middleware produced and utilized by the EGEE project (including several Swiss partners). It is or was used in the DEGREE, DILIGENT, EMBRACE and Seed projects. Globus The "Globus Toolkit" is an open source software toolkit to build Grid systems and applications, developed by the Globus Alliance. It is used in the SEPAC and PRAGMA projects. UNICORE The "Uniform Interface to Computing Resources" offers a ready-to-run Grid system including client and server software, originating in Germany. It is used in the Chemomentum and IANOS projects.

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

Sudipta Dhara (MCA-1070100), KiiT University

19

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

Sudipta Dhara (MCA-1070100), KiiT University

20

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.

Sudipta Dhara (MCA-1070100), KiiT University

21

8. References
Web References
http://www.chetanasprojects.com/Thread-MIDDLEWARE-

TECHNOLOGY-Seminar
http://seminarprojects.com/Thread-middleware-technologies http://eprints.ucl.ac.uk/674/1/corba http://www.swing-grid.ch/resources/middleware_tools http://cabibbo.dia.uniroma3.it/ids/altrui/middleware-bakken

Conference References
[ANSA, 1989] ANSA (1989). The Advanced Network Systems Architecture (ANSA). Reference manual, Architecture Project Management, Castle Hill, Cambridge, UK. [Baker, 1997] Baker, S. (1997). CORBA Distributed Objects using Orbix. Addison Wesley. [Emmerich, 2000] Emmerich, W. (2000). Engineering Distributed Objects. John Wiley & Sons.
[Emmerich et al., 2001] Emmerich, W., Ellmer, E., and Fieglein, H.

(2001). Tigra an architectural style for enterprise application integration. In Proc. of the 23rd Int. Conference on Software Engineering, Toronto, Canada. ACM Press. To appear. [Monson-Haefel, 1999] Monson-Haefel, R. (1999). Enterprise Javabeans. O'Reilly UK.

Sudipta Dhara (MCA-1070100), KiiT University

22