MTAT Enterprise System Integration. Lecture 2: Middleware & Web Services

Transcription

1 MTAT Enterprise System Integration Lecture 2: Middleware & Web Services Luciano García-Bañuelos Slides by Prof. M. Dumas

2 Overall view 2 Enterprise Java 2

3 Entity classes (Data layer) 3 Enterprise Java 3

4 Session bean (Data access object) 4 Enterprise Java 4

5 Servlets (Controller) 5 Enterprise Java 5

6 Java Server Pages (View) 6 Enterprise Java 6

7 Variations Single Application Server 7 Enterprise Java 7

8 Variations WS Client applicatio n SOAP Application Server Application Server RMI Sessio n Bean ItemDAO Item Sessio n Bean Entity class Databa se 8 Enterprise Java 8

9 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. 10

11 Remote Procedure Call (RPC) Applies the concept of a local procedure call to distributed applications. Client Stub Server Stub Client Server 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) Gustavo Alonso, ETH Zurich 11

12 Characteristics of Synchronous RPC: Blocking / Time-coupled client server 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 Answer idle time Drawbacks: connection overhead Receive Response higher probability of failures it is a one-to-one system; it is not really practical for nested calls and complex interactions Gustavo Alonso, ETH Zurich 12

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 Gustavo Alonso, ETH Zurich request() do with answer request() do with answer session duration Context is lost Needs to be restarted!! receive process return receive process return 13

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? Gustavo Alonso, ETH Zurich request() do with answer request() do with answer timeout try again do with answer receive process return receive process return receive process return

15 Solutions Decouple request from response (two RPCs) Transactional RPC Message queuing 15

16 Request and response decoupled Client Client Program 1: Call 7: Call-back 2: Request 4: Acknowledge 6: Result Server 3: Store request 5: Fetch request Processing Thread Request Database 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 16

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 request() do with answer queue queue receive process return Notable implementations of message queuing include MQSeries, MSMQ, JMS implementations Gustavo Alonso, ETH Zurich 17

18 Note: RPC can still be done on queues: Asynchronous RPC Request Queue Server Client Synchronous wrapper Message Queue API Correlation Program Reply Queue 18

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 19

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 20

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 21

22 Semantics vs. Interaction Style Interface Semantics RPC Payload Semantics MOM 22

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

24 Classification of Middleware Application servers TP-Monitors Object brokers Message Brokers - MOM Transactional RPC Object-oriented RPC (RMI) Asynchronous RPC Specialized forms of RPC with additional functionality or properties Remote Procedure Call sockets TCP, UDP Internet Protocol (IP) Gustavo Alonso, ETH Zurich 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 24

25 RPC-based Middleware: DCE client code client process DCE development environment server process server code language-specific call interface client stub IDL sources IDL compiler Language-specific call interface server stub RPC API RPC API RPC run time service library interface headers RPC run time service library RPC protocols security service cell service distributed file service thread service Gustavo Alonso, ETH Zürich. DCE runtime environment 25

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 Gustavo Alonso, ETH Zürich Client (CORBA object) client stub (proxy) CORBA library interface to remote calls Marshalling/ serialization Server (CORBA object) server stub (skeleton) CORBA Basic Object Adaptor Object Request Broker (ORB) CORBA services 26

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 27

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 28

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

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 30

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

32 Simple Session Bean Example 32

33 Example EJB client 33

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 34

35 Message-Oriented Middleware Aimed at achieving decoupling and reliability System A Message Channel System B Channels are separate from applications Channels are asynchronous & reliable (queues or topics) Data is exchanged in selfcontained messages 2003 Gregor Hohpe Remove location dependencies Remove temporal dependencies Payload semantics: Avoids data format dependencies 35

36 Traditional MOM platforms IBM WebSphere MQ MOM Platforms 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 36

37 Thinking Asynchronously Web Site New Order Order Mgmt Inventory Shipping New Order Order Mgmt Shipping Web Site Inventory Confirm New Order Idle Confirm New Order Confirm Confirm Synchronous Asynchronous 2003 Gregor Hohpe 37

38 Thinking Asynchronously: Hohpe s Enterprise Integration Patterns 2003 Gregor Hohpe 38

39 Pattern: (Asynchronous) Request-Reply Consumer Request Provider Request Channel Reply Channel 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? 2003 Gregor Hohpe 39

40 Pattern: Correlation Identifier Correlate Request & Reply Consumer Message Identifier 1 Request Channel Response Channel Provider 1 Provider 2 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 2003 Gregor Hohpe 40

41 Pattern: Return Address Consumer 1 Requests Request Channel Requests Provider Consumer 2 Reply Channel 1 Reply Channel 2? Replies 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 2003 Gregor Hohpe 41

42 Pattern: Return Address (continued) Consumer 1 Reply Channel 1 Reply Channel 2 Request Channel Provider Consumer 2 Reply Channel 1 Reply Channel 2 Replies Consumer specifies Return Address (reply channel) in the request message Service provider sends reply message to specified channel 2003 Gregor Hohpe 42

43 Web Services: Technology Stack 43

44 References and acknowledgments Some slides on RPC taken from lecture material by Gustavo Alonso, ETH Zurich Slides on MOM taken from Gregor Hohpe s talk at JAOO Reading of the week: Gregor Hohpe: Enterprise Integration Patterns Chapter 3, Messaging Systems. Addison-Wesley,