Middleware seminar report

By

Sudipta DharaRoll-1070100

Section-‘B’

Submitted to the School of Computer Application.

In 4th Semester’s seminar for the degree of

Master of Computer Application

KIIT University

Bhubaneswar, Orissa, India

1

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

2

Contents

1. Introduction 1

2. How middleware evolved 2

Application Programming Interface (API) 3

3. Middleware Basic 4

4. Categories of Middleware 6

4.1 Transaction Processing Monitors 6

4.2 Message-oriented middleware (MOM) 7

4.3 Remote procedure calls (RPC) 9

4.4 Object request brokers(ORB) 10

4.5 Homegrown middleware solutions 11

5. OMG/CORBA 12

6. Middleware Tools 15

7. Conclusion 16

8. References 18

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


3

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


4

2.How middleware evolvedTill 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.


5

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

[Figure-0] Application Programming Interface (API)


6

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


7

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.


8

4. Categories of MiddlewareThe 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

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


9

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

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


10

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.


11

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 programmer’s 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 point-

to-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:

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.


12

4.4. Object request brokers (ORB) Object Request Brokers (ORBS) can be thought of as language-

independent, 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 (Java’s Remote Method Invocation (RMI)

could be considered an ORB, although it is useful primarily for facilitating

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 CORBA’s 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.


13

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


14

5. Object Management Group (OMG)/Common

Object Request Broker Architecture (CORBA) Below Figure 1 displays the Object Management Architecture of the

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

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.


15

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, type-specific 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 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.


16

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 pre-defined root of the inheritance hierarchy. The client object issues the

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


17

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

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.


18

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


19

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.


20

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


http://cabibbo.dia.uniroma3.it/ids/altrui/middleware-bakken

http://www.swing-grid.ch/resources/middleware_tools

http://eprints.ucl.ac.uk/674/1/corba

http://seminarprojects.com/Thread-middleware-technologies

http://www.chetanasprojects.com/Thread-MIDDLEWARE-TECHNOLOGY-Seminar

http://www.chetanasprojects.com/Thread-MIDDLEWARE-TECHNOLOGY-Seminar