mtat.03.229 enterprise system integration lecture …...11 types of enterprise java beans •...

MTAT.03.229 Enterprise System Integration

Lecture 2: Middleware & Web Services

Marlon Dumas

marlon.dumas ät ut.ee

2

Reminder from Week 1 Lecture

•  RPC –  Simple and useful programming abstraction –  …but problematic in terms of failure handling

•  Alternatives to “pure” RPC –  Decouple request from response (two RPCs) –  Transactional RPC –  Message queuing (Message-Oriented Middleware – MOM)

•  Interface vs. Payload Semantics –  Interface semantics: Applications are programmed against an

interface –  Payload semantics: Applications produce and consume self-

contained documents

3

Semantics vs. Interaction Style

Interface Semantics

Payload Semantics

RPC

MOM

4

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

5 © 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

6

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

7

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

8

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…

9

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.

10

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

11

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

12

Simple Session Bean Example

13

Example EJB client

14

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

15 © 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

16

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

17

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

18

Thinking Asynchronously: Hohpe’s Enterprise Integration Patterns

© 2003 Gregor Hohpe

19

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

20

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

21

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

22

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

23

Web Services: Technology Stack

24

Architectural Style: REST •  Principles:

–  A service exposes resources identified by URI –  Uniform interface: create, read, update, delete (PUT, GET, POST,

DELETE) –  Stateful interactions through connections only – each request is self-

contained

•  Realizations: –  POX (Plain XML) over HTTP –  Hypermedia REST

•  Benefits: –  Simplicity, lightweight infrastructure

•  Drawback: –  Lack of methods for producing well-described RESTful services

25

Architectural Style: WS-*

•  Principles –  One service endpoint (URI) = multiple operations –  Operations are service-dependent –  Separation of message meta-data (header) and body (payload) –  Protocol transparency

•  Realization –  SOAP + WS-* standards

•  Benefits: –  Can operate on top of several protocols –  Enables the delivery of infrastructure services (e.g. security, transactions,

routing, reliability) –  Well-tied with methods for contract-first development

•  Drawbacks: –  Requires heavier, more specific infrastructure; can be easily misused

26

SOAP Message Structure

Header •  Carries metadata for

infrastructure services •  WS-* standards define types of

header elements & semantics Body •  contains the payload •  interpreted by the target

component (i.e. Web Service), •  can contain fault elements

27

HTTP Binding: POST HTTP Binding: Response

<PurchaseOrder xmlns="..."> <LineItem> <product>P19</product> <amount>20</amount> </LineItem> </PurchaseOrder>

POST /webshare/ws1/TestWS1.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: XX SOAPAction: "http://tempuri.org/PO"

<PurchaseOrderResponse xmlns="...">

<LineItemAck> <product>P19</product> <status>OK</status> </LineItemAck> </PurchaseOrderResponse>

HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: XX

SOAP over HTTP: Example

28

WSDL

Abstract (Structural Interface)

Concrete (Implementation)

29

WSDL: Types and Messages <definitions name="sales" targetNamespace="http://tempuri.org/sales" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:salesX="http://tempuri.org/salesX" ...> <import namespace="http://tempuri.org/salesX" location="salesX.xsd"/> <message name="rfQMsg"> <part name="payload" element="salesX:rfQ"/> </message> <message name="quoteMsg"> <part name="payload" element="salesX:quote"/> </message> <message name="orderMsg"> <part name="payload" element="salesX:order"/> </message> <message name="cancelOrderMsg"> <part name="payload" element="salesX:cancelOrder"/> </message> <message name="rejectRfQMsg"> <part name="payload" element="salesX:rejectRfQ"/> </message>

Imported Schema

WSDL Example

30

WSDL: PortTypes and Operations <portType name="providerPT"> <operation name="rfQ"> <input message="tns:rfQMsg"/> </operation> <operation name="order"> <input message="tns:orderMsg"/> </operation> <operation name="cancelOrder"> <input message="tns:cancelOrderMsg"/> </operation> </portType> <portType name="requesterPT"> <operation name="quote"> <input message="tns:quoteMsg"/> </operation> <operation name="rejectRfQ"> <input message="tns:rejectRfQMsg"/> </operation> </portType>

<operation name="rfQ"> <input message="tns:rfQMsg"/> <output message="tns:rfQAckMsg"/> <fault name="cannotUnderstandRfQ" message="tns:rfQFaultMsg"/> </operation>

One-way Operation

Two-Way Operation, also with fault

WSDL Example

31

WSDL: Bindings <binding name="providerPTBinding" type="tns:providerPT"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="rfQ"> <soap:operation style="document" soapAction="rfQ"/> <input> <soap:header message="tns:ReplyToHeader" part="ReplyTo" use="literal"/> <soap:header message="tns:MessageIDHeader" part="MessageID“ use="literal"/> <soap:body use="literal"/> </input> </operation> ... </soap:binding> </binding>

WSDL Example

32

WSDL: Services <service name="salesBP"> <port name="providerPTPort" binding="tns:providerPTBinding"> <soap:address location="http://localhost:8080/salesBP/1.0"/> </port> </service> <service name="requesterPTService"> <port name="requesterPTPort" binding="tns:requesterPTBinding"> <soap:address location="http://set.by.caller"/> </port> </service> ... </definitions>

URI where the provider is accessible

The requester’s location is set on the fly in the SOAP header

WSDL Example

33

Developing Web Services using WSDL Programming language first:

WSDL first (or Contract-first):

34

WS-* in Action (design-time)

35

WS-* in Action (runtime)

Requester Provider

36

Additional WS-* Specifications •  WS-Addressing: Defines SOAP headers for:

–  Including sender, return addresses and message IDs –  Including references to related messages (can be useful to relate a

request and a reply)

•  WS-Security: Defines extensions to SOAP for: –  propagation of security tokens which securely identify and

authenticate clients, –  message integrity via XML Signature, –  message confidentially via XML Encryption.

•  WS-ReliableMessaging –  Extensions for reliable delivery of messages (exactly-once delivery)

37

Web Services Programming

•  Java –  SUN Metro Stack (implemented by Glassfish)

including JAX-WS and JAXB –  Open-source Web service platforms: Mule, JBossWS,

Apache Axis2 –  Proprietary Web Service platforms: Oracle SOA Suite,

IBM Websphere –  Spring Web Services

•  Windows Communication Foundation

38

Windows Communication Foundation

•  Programming model for distributed applications, supporting RPC and message queues

•  Part of .Net Framework (v3.0 and above) •  Key abstractions:

–  Service: class bound to a service contract –  Endpoint: Deployed in a host, available at a URL

•  Classes and methods are turned into services & operations through annotations (.Net attributes)

39

WCF Interaction Styles

•  One Way –  Fire-and-forget

•  Request-Reply –  Immediate Reply on same logical thread

•  Duplex (asynchronous request-reply) –  Reply “later” and on return channel (callback-style)

One Way

Request-Reply

Duplex (Dual)

© Clemens Vasters, Microsoft

40

WCF Services: Main Elements

© Clemens Vasters, Microsoft

41

Service Contract: Duplex Asymmetric

[ServiceContract(Session=true,CallbackContract=typeof(ICalculatorResults)]publicinterfaceICalculatorProblems{[OperationContract(IsOneWay=true)]voidSolveProblem(ComplexProblemp);}

publicinterfaceICalculatorResults{[OperationContract(IsOneWay=true)]voidResults(ComplexProblemp);}

© Clemens Vasters, Microsoft

42

Data Contract

[DataContract]publicclassComplexNumber{[DataMember]publicdoubleReal=0.0D;[DataMember]publicdoubleImaginary=0.0D;

publicComplexNumber(doubler,doublei){this.Real=r;this.Imaginary=i;}}

© Clemens Vasters, Microsoft

43

Message Contract

[MessageContract]publicclassComplexProblem{[MessageHeader]publicstringoperation;[MessageBody]publicComplexNumbern1;[MessageBody]publicComplexNumbern2;[MessageBody]publicComplexNumbersolution;

//Constructors…}

© Clemens Vasters, Microsoft

44

WCF Bindings

•  Binding includes information about: –  Transport: e.g. HTTP, TCP, MSMQ –  Encoding: text, binary, custom –  Protocol characteristics: security, reliability,

transactions

45

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/

•  Some slides on WCF taken from Microsoft online material •  Reading of the week:

–  Gregor Hohpe: Enterprise Integration Patterns – Chapter 3, Messaging Systems. Addison-Wesley, 2003.