SEETHI SAHIB MEMORIAL POLYTECHNIC COLLEGE

TIRUR-5

DEPARTMENT OF COMPUTER ENGINEERING

2012-2013

SEMINAR ON

MIDDLEWARE

SUBMITTED BY:

ANEESHA.K.M
ROLL NO: 4
Reg. No: 10130395

Dept of Computer Engg

S.S.M.P.T.C Tirur

SEETHI SAHIB MEMORIAL POLYTECHNIC COLLEGE

TIRUR-5

DEPARTMENT OF COMPUTER ENGINEERING

2012-2013

CERTIFICATE
Certified that this is the bonafide seminar on MIDDLEWARE
has been presented by ANEESHA.K.M Fifth semester Computer
Engineering, S.S.M.P.T.C, Tirur on ..9.9.2012..............................in
partial fulfillment of requirement for the award of the diploma in
computer Engineering. Under directorate of Technical Education,
Kerala State, during the year 2012-2013

Staff in charge:

Head of Section:

Internal Examiner:

External Examiner:

Place: Tirur
Date:11.9.2012
Dept of Computer Engg

S.S.M.P.T.C Tirur

ACKNOWLEDGEMENT
First of all I would like to praise the god for blessing me to
complete this seminar successfully.

I am deeply incepted to Mr.Saleem. K.N (Head of

department in Computer engineering: Seethi Sahib Memorial
Polytechnic College Tirur) for providing me the opportunity to
present the seminar on this topic.

I extended my unexplainable gratitude towards all of my

teachers & librarians who gave me a lot of information and
supports for this seminar.

I gave my heart full thanks to my friends & family, whom

offered me all kind of supports for this.

Dept of Computer Engg

S.S.M.P.T.C Tirur

TABLE OF CONTENTS
CHAPT
ER NO
1
2
3
4
5
6
7
8
9
10
11
12

REFERENCES TITLE
ABSTRACT
INTRODUCTION
HISTORY OF ATM
WHAT IS GRMATELLER
DEVELOPMENT OF GRAMATELLER
WORKING OF GRAMATELLER
COMPARISON BETWEEN ATM&SOLAR
ATM
ADVANTAGE
DISADVANTAGE
FEATURES
CONCLUSION
REFERENCES

Dept of Computer Engg

PAG
E
NO
5
6-8
9-11
12-15
16
17-21
22
23
24
25-26
27
28

S.S.M.P.T.C Tirur

ABSTRACT
Rural India offers great business opportunity: 720 million
people in 630,000 villages that contribute to over 50% of
Indias total gross domestic product (GDP). The problem is
that they have the same needs as that of urban India but
unreliable electricity and minimal ability to pay for services.
Businesses seeking new strategies are looking to rural
markets, especially those for which it was believed that doing
so made little economic sense.

Rural market development is made difficult for services are

dependent on energy; however, solar products and
technologies along with supportive business models are
opening up new business opportunities in rural, untapped
markets. Vortex Engineering Pvt. Ltd. of Chennai, India, has
developed solar ATMs called Gramtellers, with a biometric
touch pad , a solar panel and a 12-hour backup battery. These
devices are needed in rural areas where people would
previously have had to travel long distances to a bank. The
solar ATMs also offer a great business opportunity by tapping
the rural market segment. By powering the ATMs with solar
energy, banks can place the systems in areas that may be
grid connected, but that experience frequent power
shortages, making grid-connected ATMs not feasible for
regular use.

INTRODUCTION
Dept of Computer Engg

S.S.M.P.T.C Tirur

Today, industries need to transform their client/server infrastructures into servicesoriented 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
Dept of Computer Engg

S.S.M.P.T.C Tirur

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

Dept of Computer Engg

S.S.M.P.T.C Tirur

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

Middleware Basic
Dept of Computer Engg

S.S.M.P.T.C Tirur

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
Dept of Computer Engg

S.S.M.P.T.C Tirur

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:
Dept of Computer Engg

S.S.M.P.T.C Tirur

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
Dept of Computer Engg

S.S.M.P.T.C Tirur

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 vendorneutral 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,
Dept of Computer Engg

S.S.M.P.T.C Tirur

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 bythe
application developer. In traditional network applications, when two processes must
communicate with each other, they need network addresses to begin communicating. If a
Dept of Computer Engg

S.S.M.P.T.C Tirur

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.

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
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
Dept of Computer Engg

S.S.M.P.T.C Tirur

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.

Object request brokers (ORB)

Object Request Brokers (ORBS) can be thought of as language-independent, objectoriented 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 communication
between two programs written in Java and does not address other programming
languages as do both DCOM and CORBA.)

Dept of Computer Engg

S.S.M.P.T.C Tirur

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.

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.
Dept of Computer Engg

S.S.M.P.T.C Tirur

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
Dept of Computer Engg

S.S.M.P.T.C Tirur

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

Dept of Computer Engg

S.S.M.P.T.C Tirur

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 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
Dept of Computer Engg

S.S.M.P.T.C Tirur

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.

Figure3:Components involved in Object Requests

Dept of Computer Engg

S.S.M.P.T.C Tirur

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

Dept of Computer Engg

S.S.M.P.T.C Tirur

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.

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
Dept of Computer Engg

S.S.M.P.T.C Tirur

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

Dept of Computer Engg

S.S.M.P.T.C Tirur

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

Dept of Computer Engg

S.S.M.P.T.C Tirur