Post on 02-Jun-2018
8/10/2019 Anu Seminar
1/24
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
8/10/2019 Anu Seminar
2/24
SEETHI SAHIB MEMORIAL POLYTECHNIC COLLEGE
TIRUR-5
DEPARTMENT OF COMPUTER ENGINEERING
2012-2013
CERTIFICATE
Certified that this is the bonafide seminar onMIDDLEWAREhas been presented by ANEESHA.K.M Fifth semester ComputerEngineering, S.S.M.P.T.C, Tirur on ..9.9.2012..............................inpartial fulfillment of requirement for the aard of the diploma in!omputer "n#ineerin#. $nder dire!torate of Te!hni!al "du!ation,%erala State, durin# the year 2012&201'
Staff in !a"#$% H$a& 'f S$ti'n%
Int$"na( E)a*in$"% E)t$"na( E)a*in$"%
P(a$% Ti"+"
Date:11.9.2012
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
3/24
ACKNOWLEDGEMENT
ir!t of "## $ %ou#& #i'e to pr"i!e t(e go& for )#e!!ing me to*omp#ete t(i! !emin"r !u**e!!fu##+.
$ "m &eep#+ in*epte& to Mr.S"#eem. ,.N -e"& of&ep"rtment in Computer engineering: Seet(i S"(i) Memori"#Po#+te*(ni* Co##ege Tirur/ for proi&ing me t(e opportunit+ topre!ent t(e !emin"r on t(i! topi*.
$ eten&e& m+ unep#"in")#e gr"titu&e to%"r&! "## of m+te"*(er! 2 #i)r"ri"n! %(o g"e me " #ot of inform"tion "n&!upport! for t(i! !emin"r.
$ g"e m+ (e"rt fu## t("n'! to m+ frien&! 2 f"mi#+ %(omoere& me "## 'in& of !upport! for t(i!.
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
4/24
TABLE OF CONTENTS
CHAPTER NO
REFERENCES TITLE PAGE
NO1 ABSTRACT
2 INTRODUCTION !"#
$ HISTORY OF ATM 9"11
% WHAT IS GRMATELLER 12"1
DE&ELOPMENT OF GRAMATELLER 1!
! WORKING OF GRAMATELLER 1'"21
' COMPARISON BETWEEN ATM(SOLARATM
22
# AD&ANTAGE 2$
9 DISAD&ANTAGE 2%
10 FEATURES 2"2!
11 CONCLUSION 2'12 REFERENCES 2#
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
5/24
ABSTRACTRur"# $n&i" oer! gre"t )u!ine!! opportunit+: 60 mi##ionpeop#e in 730000 i##"ge! t("t *ontri)ute to oer 508 of$n&i"! tot"# gro!! &ome!ti* pro&u*t -DP/. T(e pro)#em i!t("t t(e+ ("e t(e !"me nee&! "! t("t of ur)"n $n&i" )utunre#i")#e e#e*tri*it+ "n& minim"# ")i#it+ to p"+ for !eri*e!.;u!ine!!e! !ee'ing ne% !tr"tegie! "re #oo'ing to rur"#m"r'et! e!pe*i"##+ t(o!e for %(i*( it %"! )e#iee& t("t &oing
!o m"&e #itt#e e*onomi* !en!e.
Rur"# m"r'et &ee#opment i! m"&e &i
8/10/2019 Anu Seminar
6/24
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, !iddleware 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 networ". !iddleware is
especially integral to modern information technology based on #!$, %eb services, and
service-oriented architecture.
& 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.
H* -/+ea,e e*+e
Till '()* s most of computing was based on central host computers equipped
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
7/24
with powerful processors and memory. +sers interact with the host through the
terminals that captures "eystro"es and sends the information to host. & maor bottlenec" for
this architecture was that the processing power was limited to that of central host system, over
dependence on the vendor for application software, lac" of support for +I and access tomultiple databases. The mainframes prevalent at that time were based on this architecture.
%ith advent of s the files were downloaded from the shared location, processed and
uploaded bac" to file server. This had maor drawbac" as it generated too much of networ"
traffic. 0owever with emergence of client /server architecture, the computing power or
process management was distributed between the client and server.
For exampleclient could query database server using relational database management
system 123!45 through standard query language 146$5. 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. !oreover any changes in
application or parameter would entail changes at all clients li"e a change in 7&T rate would
need update on all the users8 wor"station. 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
generali9ation of &pplication rogramming Interface 1&I5 than operating system or networ"
services.
A,,(iati'n P"'#"a**in# Int$"fa$ API.%
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
8/24
In order to fully understand middleware, one must first understand the concepts
surrounding &pplication rogramming Interfaces 1&Is5. The &I, by definition, is a software
program that is used to request and carry out lower-level services performed by the computer8s
operation system or by a telephone system8s operating system.
In a %indows environment, &Is also assist applications in managing windows,
menus, icons, and other +I elements. In short, an &I is a :hoo"; into software. &n &I
is a set of standard software interrupts, calls, and data formats that application programs
use to initiate contact with networ" services, mainframe communications programs,
telephone equipment or program-to-program communications. For example, applications
use &Is to call services that transport data across a networ". 4tandardi9ation of &Is at
various layers of a communications protocol stac" 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.
/Fi#+"$-0 A,,(iati'n P"'#"a**in# Int$"fa$ API.
Mi&&($a"$ Bai
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
9/24
&s the distributed model of enterprise computing has become more common,
the term middleware has acquired numerous meanings that would allow it to be ust about any
piece of software that sits between systems. Terms such as enterprise application integration
1
8/10/2019 Anu Seminar
10/24
send data from one server to many clients as fast as possible. Typical applications might be
stoc"bro"ers needing the latest prices on certain bonds or equities. These prices typically are
sent in real time to all bro"ers who subscribe to this information. =ne company today, Talarian
orp., combines the two models of !=!? its product 4mart4oc"ets delivers messages in realtime with the reliability and integrity of message queuing. In fact, 4mart4oc"ets can be
installed as either a pub/sub implementation or a message-queuing pac"age.
Cat$#'"i$ 'f Mi&&($a"$
The previous section briefly introduced the two types of message-oriented middleware.
=ther types of middleware are commonly found today performing narrow functions.
The middleware mar"et can be bro"en into five different segments?
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
11/24
'. Transaction processing1T5 monitors
@. !essage-oriented middleware 1!=!5
A. Bemote procedure calls1B5
C. =bect request bro"ers1=B35D. 0omegrown middleware solutions
T"anati'n P"'$in# M'nit'"
Typically, transaction-processing 1T5 monitors are not used for general purpose
program-to-program communication. Bather, they provide a complete environment for
transaction applications that access relational databases. In T monitors, clients invo"e remote
procedures that reside on servers, which also contain a 46$ database engine. rocedural
statements on the server execute a group of 46$ statements 1transactions5, which either all
succeed or all fail as a unit. The applications based on transaction servers are called on-line
transaction processing 1=$T5. They tend to be mission-critical applications that require a
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
12/24
rapid response '**E of the time and tight controls over the security and integrity of the
database. The communication overhead in this approach is "ept to a minimum because the
exchange typically consists of a single request/reply 1as opposed to the multiple 46$
statements required in database servers5. T monitors provide application development tools1such as user interaction and database interfaces5, system administration 1such as security and
tuning5, and transaction execution 1such as scheduling and load balancing5. #/=pen, a vendor-
neutral standards group, has done a considerable amount of wor" toward defining a process
model and related services interfaces for distributed processing applications. !ost vendors
have pledged to support some or most aspects of the #/=pen model. T monitors should be
considered when transactions need to be coordinated and synchroni9ed over multiple
databases. T monitors tend to be heavyweight and expensive, and they require a great deal of
expertise to implement properly. !ost T vendors have a large service side to their business.
M$a#$-'"i$nt$& *i&&($a"$ MOM.
In general, !=! products wor" 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. !=! products, in
general, cover more than ust passing information> they usually include services for
translating data, security, broadcasting data to multiple programs, error recovery, locating
resources on the networ", cost routing, prioriti9ation of messages and requests, and
extensive debugging facilities. +nli"e both =B3 and B products, !=!, in general,
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
13/24
does not assume the system has a reliable transport layer underneath. !=! tries to
address the problems that surface when the transport layer is unreliable, as occurs when
programs must communicate over a %& or over the Internet.
Two different types of !=! have emerged?
'. !essage queuing
@. !essage 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. & 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. !essage queuing provides safe storage of information and is most appropriate where
applications cannot be connected directly 1for example, in mobile computing5. 0owever,
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)
!essage 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. =ne increasingly popular flavor of message passing uses a model of
communication "nown as publish-subscribe 1pub/sub5. In pub/sub, programs subscribe to
1register interest in5 a subect. rograms also publish 1send5 messages to the subect. =nce
a subect has been subscribed to by a program, the program will receive any messages
published to that subect in the distributed application. 4ubects are defined bythe
application developer. In traditional networ" applications, when two processes must
communicate with each other, they need networ" addresses to begin communicating. If a
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
14/24
process wants to send a message to many other processes, it first would need to "now the
physical networ" 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 subect as the destination property while
the middleware routes the message to all programs that have subscribed to that subect.
!=! vendors typically implement publishsubscribe with a set of agents that maintain a
realtime database, listing which programs are interested in which subects. & program
publishes a message by connecting with one of the agents 1it may or may not be on the
same machine5 and sending the message to it. The agent then routes the message to the
appropriate programs. =ften, 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. ub/sub is most appropriate for highly distributed applications
where fault tolerance and high performance are important. It does not wor" well in
situations where processes may be disconnected from the networ" for long periods of time.
R$*'t$ ,"'$&+"$ a(( RPC.
Bs 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 programmer8s
point of view, Bs are easy to understand. The code invo"es a procedure that is located on a
remote system, and the results are returned. enerally, the application components
communicate with each other synchronously, meaning they use a request/wait for- reply
model. Bs wor" well for smaller, simple applications where communication is primarilypoint-to-point 1rather than one system to many5. Bs do not scale well to large, critical
applications, as they leave many crucial details up to the programmer, such as the following?
'. 0andling networ" or system failures
@. 0andling multiple connections
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
15/24
A. ortability
C. 3uffering and flow control
4ynchroni9ation between processes 2ue to their synchronous nature, Bs are not a
good choice to use as the building bloc"s for enterprise-wide applications where highperformance and high reliability are needed. The B standards have not evolved in any
significant way during the last five years, primarily because of the emergence of the =bect
Bequest 3ro"ers described in the next section.
O4$t "$+$t "'6$" ORB.
=bect Bequest 3ro"ers 1=B345 can be thought of as language-independent, obect-
oriented Bs.
There are two competing standards for =B3s?
'. =B3&, bac"ed by more than G** companies from the =bect !anagement
roup 1=!5
@. 2=!, bac"ed by !icrosoft 1Hava8s Bemote !ethod Invocation 1B!I5 could be
considered an =B3, although it is useful primarily for facilitating communication
between two programs written in Hava and does not address other programming
languages as do both 2=! and =B3&.5
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
16/24
=B3s are designed for use in proects that require a strict obect-oriented approach,
where :obects are the only way.; $i"e Bs, =B3s are generally synchronous and operate in
a point-to-point manner. In general, both =B3& and 2=! assume the system has a
reliable communications layer, and they do not address the problems involved when this layeris not reliable.
8/10/2019 Anu Seminar
17/24
O4$t Mana#$*$nt G"'+, OMG.7C'**'n O4$t
R$+$t B"'6$" A"!it$t+"$ CORBA.
3elow Figure ' displays the =bect !anagement &rchitecture of the =bect !anagement
roup 1=!5. It identifies different categories of obects of a distributed obect system as
well as an obect request bro"er by means of which these obects communicate. =B3&
services represent obects that provide very basic services, which are required for the
construction of distributed systems.
8/10/2019 Anu Seminar
18/24
or a printing and spooling facility. 2omain Interfaces obects that are useful within particular
application domain. &mong others, the =! is currently standardi9ing 2omain interfaces for
0ealth care, Telecommunication, !anufacturing and Finance. Finally, &pplication =bects are
built for particular applications. Their construction averages =B3& services, =B3&facilities and the 2omain Interfaces using the mechanisms provided by the =B3& obect
model.
The =B3& obect model determines an informal semantics for obect-oriented
concepts. The concepts are defined in a way that they can be mapped to a large variety of
programming languages. The obect-model defines concepts for obect and non-obect types,
operations and attributes exported by obects, type-specific exceptions that may be the obects
integrity is violated. The model also includes a mechanism for subtyping by means of which
obect types inherit attributes and operations of their super types. The =B3& obect model is
used as a distributed system component model. 2istributed system components are
implemented by =B3& obects. omponent types are
implemented by obect types. The services offered by components are determined by
obect type definition. & client component can interact with a server component by means of
obect requests. These are messages that trigger the execution of an operation in a server
obect. 4ystem 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
8/10/2019 Anu Seminar
19/24
The =! Interface 2efinition $anguage 1I2$5 includes constructs for all the concepts
of the =B3& obect model. I2$ is designed to be independent of a particular programming
language, though its syntax is oriented towards JJ. I2$ is not computationally complete. It
does not include language constructs to store variables or to express algorithms.
&s shown in Figure @, the =B3& defines bindings to? , JJ, 4malltal", &da, Hava
and ==-obol. These programming language bindings determine how obect types with their
attributes, operations and exceptions are implemented in server obects and how clients can
ma"e obect requests and catch exceptions the server may raise.
Figure A shows the components that are involved in the interaction between obect
request bro"er, client and server obects at run-time. 3oth client and
server obects initiali9e themselves using the =B3 interface. The =B3 interface also
determines the operations that any server obect inherits from the pre-defined root of the
inheritance hierarchy. The client obect issues the request and uses either the static or the
dynamic invocation interface. & static request is issued by calling a client stub that is
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
20/24
generated from an I2$ interface description. 4tatic obect requests are synchronous. &
dynamic invocation is done using the dynamic invocation interface. The dynamic invocation
interface supports both synchronous and deferred synchronous requests. &fter having issued a
deferred synchronous request, control is given bac" to the client obect until a point in timewhen it polls for the operation result. The obect bro"er uses the obect reference that is
submitted by the client as part of the request in order to locate the server obect. If necessary,
the bro"er activates the obect using an obect adapter. The bro"er then invo"es the
implementation s"eleton, which is also generated from the I2$ interface definition of the
client obect. The s"eleton finally calls the operation that was requested by the client.
F/3,e$:C*-4*5e5t) /5*+e /5 O67e8t Re3e)t)
Dept of Computer Engg S.S.M.P.T.C Tirur
8/10/2019 Anu Seminar
21/24
Mi&&($a"$ T''(
ondor
The ondor middleware supports mechanisms and policies for high
throughput computing on collections of distributed computing resources, in
particular des"top grids and clusters. It is or was used in the reedy and 4eed
proects.
&B
The &dvanced Besource onnector is the lobus-based middleware
developed by the ordurid collaboration of the 4candinavian countries. It is
or was used in the &T$&4, Know&B, 4eed, 4!4 and 4wiss 3io rid
proects.
g$ite
g$ite is a further development of lobus and the middleware produced and
utili9ed by the
8/10/2019 Anu Seminar
22/24
The lobus Tool"it is an open source software tool"it to build rid systems
and applications, developed by the lobus &lliance. It is used in the 4
8/10/2019 Anu Seminar
23/24
those are tas" forces for business obects, finance, electronic commerce, telecommunication,
health care and manufacturing. !ore tas"forces are going to be started.
The =B3& obect model only supports interactions between one client and oneserver obect. !oreover, in order to achieve integration the client obect needs to be changed
to invo"e a client stub or use the dynamic invocation interface. The =B3& omponent
!odel that is part of the =B3& A.* standardi9ation effort L4iegel, '(((M will address these
issues and allow more exible ways of integrating client and server obects. In particular
=B3& components can have multiple interfaces and they can publish and subscribe to event-
based communication. =B3& 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 "nown
from
8/10/2019 Anu Seminar
24/24
R$f$"$n$
http?//www.chetanasproects.com/Thread-!I22$