mtat.03.229 enterprise system integration lecture 2: … · 2012. 9. 17. · – ibm websphere mq...
TRANSCRIPT
MTAT.03.229 Enterprise System Integration
Lecture 2: Middleware & Web Services
Luciano García-Bañuelos
Slides by Prof. M. Dumas
2
Overall view
Enterprise Java 2
3
Entity classes (Data layer)
Enterprise Java 3
4
Session bean (Data access object)
Enterprise Java 4
5
Servlets (Controller)
Enterprise Java 5
6
Java Server Pages (View)
Enterprise Java 6
7
Single Application Server
Variations
Enterprise Java 7
8
Application Server
Variations
Enterprise Java 8
Application Server
Session Bean
Session Bean
Entity class Databa
se
WS Client
application
RMI
SOAP
ItemDAO
Item
Part III
Integration Concepts
10
Dimensions of Coupling in Middleware
• Synchronization coupling – Blocking: a thread of an interacting party has to wait (block) to
produce or to consume an event. – Non-blocking
• Space coupling – Directed communication: the interacting parties need to know
each other. – Undirected.
• Synchronization coupling occurs between the app and the middleware. Time/space coupling occur between two apps.
11
Remote Procedure Call (RPC)
• Applies the concept of a local procedure call to distributed applications.
• Most RPC mechanisms are “synchronous”, request-reply protocol, the client blocks until the server replies.
• First RPC standards proposed by Sun in 1980s. • Notable examples of RPC-based middleware are DCE
and CORBA (although CORBA is broader)
Client Server
Client Stub
Server Stub
© Gustavo Alonso, ETH Zurich
12
Characteristics of Synchronous RPC: Blocking / Time-coupled
• Requires both parties to be “on-line”: the caller makes a request, the receiver gets the request, processes the request, sends a response, the caller receives the response.
• The interaction requires both client and server to be “alive” at the same time
Call Receive
Response
Answer
idle time
• Drawbacks: – connection overhead – higher probability of failures – it is a one-to-one system; it
is not really practical for nested calls and complex interactions
client server
© Gustavo Alonso, ETH Zurich
13
Issues with Synchronous RPC
• RPC requires a session between the caller and the receiver.
• Maintaining sessions consumes CPU and memory resources.
• For this reason, systems often resort to “connection pooling” – have a pool of open
connections – associate a thread with
each connection – allocate connections as
needed
request()
do with answer
receive process return
session duration
request()
do with answer
receive process return
Context is lost Needs to be restarted!!
© Gustavo Alonso, ETH Zurich
14
Failures in Synchronous RPC
• If the client or the server fail, the context is lost and resynchronization is difficult. – If the failure occurred
before 1, nothing has happened
– If the failure occurs after 1 but before 2 (receiver crashes), the request is lost
– If the failure happens after 2 but before 3, side effects may cause inconsistencies
– If the failure occurs after 3 but before 4, the response is lost but the action has been performed (retry?)
• Who is responsible for finding out what happened?
request()
do with answer
receive process return
1 2
3 4
request()
do with answer timeout try again
do with answer
receive process return
1 2
3
receive process return
2’
3’ © Gustavo Alonso, ETH Zurich
15
Solutions
• Decouple request from response (two RPCs) • Transactional RPC • Message queuing
16
Request and response decoupled
• Request – Client sends a request to the server – Server stores request in DB and replies with acknowledgement to client
• Response – Server thread takes pending requests from the DB and processes them – Server sends result back to originating client using callback
Server
Request Database
Client 2: Request
4: Acknowledge 3: Store request
Processing Thread
5: Fetch request
6: Result 7: Call-back
1: Call
Client Program
17
Message queuing • Queuing complements
synchronous RPC: – Suitable to modular design:
the code for making a request can be in a different module (even a different machine!) than the code for dealing with the response
– It is easier to also achieve space decoupling
• Notable implementations of message queuing include MQSeries, MSMQ, JMS implementations
do with answer
request()
receive process return
queue
queue
© Gustavo Alonso, ETH Zurich
18
Note: RPC can still be done on queues: “Asynchronous RPC”
Client
Sync
hron
ous
wra
pper
M
essa
ge Q
ueue
A
PI
Server
Program Correlation
Request Queue
Reply Queue
19
Interface vs. Payload Semantics
• Typically, interaction between a client and a server results in the execution of some processing operation on the server.
• The action to be performed can be specified in one of two ways: – Interface semantics – Payload semantics
20
Interface Semantics • The operation to be performed is encoded in the
operation signature of the server component interface that the message is sent to. – Self descriptive operation names such as getCustomer(),
transferMoney() – used in RPC style systems – interfaces are intuitive and semantically rich – changes to the interface require modification of all dependent
applications
21
Payload Semantics
• Specifies the action to be performed within the message passed – results in a generic interface with standard functions – e.g. sendMessage(), receiveMessage() – widely used in Message-Oriented Middleware – changing the message format does not necessarily affect all
dependent applications
22
Semantics vs. Interaction Style
Interface Semantics
Payload Semantics
RPC
MOM
23
Document-centric Messaging
• With RPC style communication, programming language values (objects) are seamlessly serialized for transport over the network. At the other end, they are automatically converted back into objects.
• In heterogeneous environments, the programming language of the receiver may be different to that of the sender. – Arguably, that the format of the message sent over the network
should be our central focus rather than what programming language objects those messages might get mapped to.
– Clients and Receivers should exchange programming language -neutral documents that both end-points must understand.
24
Classification of Middleware
Remote Procedure Call
sockets
TCP, UDP
Internet Protocol (IP)
sockets: operating system level interface to the underlying communication protocols
TCP, UDP: User Datagram Protocol (UDP) transports data packets without guarantees Transmission Control Protocol (TCP) verifies correct delivery of data streams
Internet Protocol (IP): moves a packet of data from one node to another
Transactional RPC
Object-oriented RPC (RMI)
Asynchronous RPC
TP-Monitors Object brokers
Message Brokers - MOM
Application servers
Specialized forms of RPC with additional functionality or properties
© Gustavo Alonso, ETH Zurich
25 © Gustavo Alonso, ETH Zürich.
RPC-based Middleware: DCE
DCE runtime environment
RPC protocols
security service
cell service
distributed file service
thread service
IDL sources
interface headers
IDL compiler
client code
client stub
RPC run time service library
language-specific call interface
RPC API
server code
server stub
RPC run time service library
Language-specific call interface
RPC API
client process server process DCE development environment
26
Beyond RPC: CORBA • The Common Object
Request Broker Architecture (CORBA) is an architecture for component- based distributed middleware
• Includes: – Object Request Broker (ORB):
in charge of the interaction between components
– CORBA services: standard definitions of system services
– A standardized Interface Definition Language (IDL)
– Protocols for allowing ORBs to talk to each other
Client (CORBA object)
Server (CORBA object)
client stub (proxy)
server stub (skeleton)
CORBA library
CORBA Basic Object Adaptor
Object Request Broker (ORB)
Marshalling/ serialization
CORBA services
interface to remote calls
©Gustavo Alonso, ETH Zürich
27
Example of an interface definition in CORBA’S IDL
module Bank { typedef float CashAmount; ... interface Account { exception InsufficientFunds { string reason; }; void withdraw(in CashAmount amount)
raises(InsufficientFunds); ... }; };
Partly taken from IONA’s Orbix Programmer's Guide
28
CORBA Application Structure
• Stubs and skeletons are generated from IDL interface descriptions
• They can be generated for multiple programming languages (e.g. C++, C, Ada, Smalltalk, Java) and multiple platforms
• With the widespread adoption of the JVM, this feature lost its appeal…
29
Other RPC-based frameworks
• Java Remote Method Invocation – Similar to CORBA RPC but without IDL (uses Java interfaces that
inherit from java.rmi.Remote) – Includes a registry to publish & retrieve objects by names – Uses CORBA’s Inter-ORB Object Protocol (IIOP) to transfer
objects over TCP/IP
• .Net Remoting: similar to Java RMI but: – Doesn’t require use of (remote) interfaces – Doesn’t require a name service to locate remote servers, uses
known URIs instead. – More customizable with respect to communication channels and
serialization protocols.
30
Enterprise JavaBeans (EJB) • EJB is a server-side component model for enterprise
applications developed in Java • Enterprise beans run in an EJB container, a runtime
environment within the Application Server
31
Types of Enterprise Java Beans
• Session Bean – Used for dealing with a single client – Bean’s lifetime corresponds to the client’s “session”. – May be stateless or stateful (“conversational state”). – Not the same as a Servlet/JSP session (maintained by the web
container)
• Message-Driven Bean – Beans which listen for messages arriving at a message
destination. – Unlike other EJBs, can’t be accessed directly via an interface. – Execute asynchronously (relative to the original message send).
32
Simple Session Bean Example
33
Example EJB client
34
When to Use Enterprise Beans?
• You should consider using enterprise beans if your application has any of the following requirements: – The application logic needs to be distributed. To
accommodate a growing number of users, you may need to distribute an application's components across multiple machines. The location of EJBs remains transparent to the clients.
– Transactions needed to ensure data integrity. Enterprise beans support transactions.
• Lightweight alternative to EJBs: Spring Framework
35 © 2003 Gregor Hohpe
Message-Oriented Middleware
• Channels are separate from applications
• Channels are asynchronous & reliable (queues or topics)
• Data is exchanged in self-contained messages
Remove location dependencies
Remove temporal dependencies
Payload semantics: Avoids data format dependencies
Aimed at achieving decoupling and reliability
System B
System A
Message Channel
36
MOM Platforms
• Traditional MOM platforms – IBM WebSphere MQ – Microsoft MSMQ – Java Message Service (JMS) implementations, e.g.
• SUN’s reference implementation • TIBCO, WebMethods, WebLogic, WebSphere MQ, …
• MOM wrapped as Asynchronous Web services – Sun’s Metro Stack (on top of Message-Driven Beans) – Microsoft’s Windows Communication Foundation (WCF)
The Underlying Design Principles Are the Same!
© 2003 Gregor Hohpe
37
Thinking “Asynchronously”
Web Site New Order
Order Mgmt Inventory
Shipping
Confirm
Web Site New Order
Order Mgmt Inventory
Shipping
Confirm
Confirm
New Order
Synchronous Asynchronous
Idle
Confirm
New Order
© 2003 Gregor Hohpe
38
Thinking Asynchronously: Hohpe’s Enterprise Integration Patterns
© 2003 Gregor Hohpe
39
Pattern: (Asynchronous) Request-Reply
• Service Provider and Consumer (similar to RPC) • Channels are unidirectional • Two asynchronous Point-To-Point Channels • Separate request and reply messages • But how do we know which reply matches which request?
Request Channel
Reply
Request
Reply Channel
Provider Consumer
© 2003 Gregor Hohpe
40
Pattern: Correlation Identifier
• Equip each message with a unique identifier – Message ID (simple, but has limitations) – GUID (Globally Unique ID) – Business key (e.g. Order ID)
• Provider copies the ID to the reply message • Consumer can match request and response
Message Identifier 1
2
Provider 1
Provider 2 Request Channel
Response Channel
1 2
1 2 1 2
1 2
1 2
Correlation Identifier
Correlate Request & Reply
Consumer
© 2003 Gregor Hohpe
41
Pattern: Return Address
Consumer 1
Replies
Requests
Consumer 2
?
• Each consumer has its own reply queue • How does the provider know where to send the reply?
– Could send to all consumers very inefficient – Hard code violates principle of context-free service
Requests Request Channel
Reply Channel 1
Reply Channel 2
Provider
© 2003 Gregor Hohpe
42
Consumer 1
Replies Consumer 2
Request Channel
Reply Channel 1
Reply Channel 2
Pattern: Return Address (continued)
• Consumer specifies Return Address (reply channel) in the request message
• Service provider sends reply message to specified channel
Reply Channel 1
Reply Channel 2 Provider
© 2003 Gregor Hohpe
43
Web Services: Technology Stack
44
References and acknowledgments
• Some slides on RPC taken from lecture material by Gustavo Alonso, ETH Zurich
• http://www.inf.ethz.ch/personal/alonso/teaching.html • Slides on MOM taken from Gregor Hohpe’s talk at
JAOO’2003 – http://www.eaipatterns.com/
• Reading of the week: – Gregor Hohpe: Enterprise Integration Patterns –
Chapter 3, Messaging Systems. Addison-Wesley, 2003.