Date post: | 29-Aug-2014 |
Category: |
Documents |
Upload: | sudipta-dhara |
View: | 149 times |
Download: | 9 times |
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
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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)
Sudipta Dhara (MCA-1070100), KiiT University
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
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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
Sudipta Dhara (MCA-1070100), KiiT University
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
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University
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.
Sudipta Dhara (MCA-1070100), KiiT University