MTAT.03.229 Enterprise System Integration Lecture 2: … · 2012. 9. 17. · – IBM WebSphere MQ...

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.