Anu Seminar

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


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



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



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#



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


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



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



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



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


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?



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



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,



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



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



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



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.


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.


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.



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



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)



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


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


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


24/24

R$f$"$n$

http?//www.chetanasproects.com/Thread-!I22$

Anu Seminar

Documents

Transcript of Anu Seminar