MTAT.03.229 Enterprise System Integration Lecture …...11 Types of Enterprise Java Beans •...
Transcript of 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.