Managing Asynchronous Web Services Interactions

Transcription

1 Managing Asynchronous Web s Interactions Marco Brambilla, Stefano Ceri, Mario Passamani, Alberto Riccio Dipartimento di Elettronica e Informazione, Politecnico di Milano, Milano, Italy mbrambil ceri@elet.polimi.it, marpass@tin.it, albertor@stardock.com Abstract Asynchronous interactions are becoming more and more important in the implementation of complex B2B Web applications. This paper addresses correlation and coordination issues involved with asynchronous Web services, by studying different mechanisms and metadata structures for supporting them; in addition, several interaction patterns for building asynchronous computations are discussed, and the trade-offs between the various patterns are shown. In conclusion, we illustrate the use of asynchronous Web services in the context of some concrete B2B applications. 1. Introduction In the last years, the Web has consolidated as the primary platform for application development; the advent of Web services has contributed to establishing the Web as the ubiquitous technical platform for implementing B2C and B2B applications. In such context, asynchronous interactions are becoming more and more important; they support operations that are non-blocking for the client, i.e. client execution continues immediately after the request, and the response is then processed later, by a different execution context or thread. By asynchronous Web s we mean Web operations designed to be called through an asynchronous interaction. They provide a good solution to one or more of the following cases: (i) when service time is expected to be too long to make it comfortable to wait for a response; (ii) when response time is not predictable, because of the interactive nature of the application (e.g., a task which requires human intervention); (iii) when users may not be continuously online (e.g., wireless connections); (iv) when strict reliability and performance requirements are imposed. All these trends involve the need of managing temporal latency between a user request and the subsequent system s response. Actually, the business application world has showed growing interest in achieving loosely coupled, message based interaction s forms for its Web application using Web s [9]. Asynchrony is seen as a solution also for reliability and performance: simple asynchronous systems, e.g. the e- mail delivery system, are intrinsically more reliable than real-time synchronous systems, and they can spawn multiple requests in parallel, instead of answering each requests exactly when it s made. Obviously, asynchronous operations introduce an additional degree of complexity, because of the fact that the service context remains suspended, in the sense that its usefulness is not accomplished within the call execution lifetime. Two main problems must be addressed to achieve effective asynchronous service calls. (i) Long persistence of the call state information: conceptually, we can say that context information of a specific call are pointed by a context identifier. (ii) Correlation between requests and associated responses, both at server and client side: since request and response are loosely coupled, it is necessary an additional mechanism that logically binds the two parts of the same call context. To summarize (see Figure 1), building the correlation between an asynchronous call and its response means to provide a logical connection between request and response messages as well as retrieving the service call context; by this term we mean the application and request status data that are used by the implementation of the service to satisfy the request. In the most general case, both the client and service provider need an effective asynchronous correlation mechanism, since a Web is typically consumed by multiple users at

2 the same time (or multiple business partners, if we consider Web s as part of a coreographed conversation [6, 8]), and a client submits multiple parallel requests to the same Web, since asynchronous calls are non-blocking. Therefore, at server side it is necessary to send the response (together with correlation information, obtained through a look up to status and application data related to current context, as in Figure 1) to the client which requested it, and client needs to logically connect the received response to the request that generated it. In Out Correlation mechanism Context Figure 1 Logic schema of correlation The paper is organized as follows: Section 2 presents the different methods for building an asynchronous correlation, while Section 3 offers a view of the main interaction patterns for implementing asynchronous Web service calls. Section 4 presents an implementation experience, and Section 5 concludes. 2. Methods for asynchronous correlation This section discusses methods for implementing correlation in asynchronous Web operations. Asynchronous correlation can be achieved (i) at transport level, (ii) by data semantics, and (iii) by correlation- and conversation- specific metadata. 2.1 Correlation at transport level lication/ status data Since HTTP is the ubiquitous transport protocol for Web applications, it is also the ideal solution for binding Web s messaging. With respect to problems stated in Section 1, HTTP has two big limitations: (i) it is stateless and (ii) it is synchronous. HTTP only allows implicit synchronous correlation, which still is the most common request/response correlation used nowadays. In case of HTTP synchronous interactions, timeout mechanisms abruptly resolve too long response times by aborting the calls. From an application level standpoint, correlation is implicit (there aren t additional data or meta-data involved) and automatic (there is only one execution thread). If more Web s interactions are needed to be composed into a coreographed process, this mechanism is rarely effective. Actually, transport level protocols natively supporting asynchrony exist. They feature mechanisms to pass and hold status and service data, and make both client and server implementations simpler. An example is HTTPR by IBM [7]. However, we believe the main advantage about Web s is standardization and the use of widely adopted technologies and platforms. This encourages easier integration, modularity, and cost effective implementation. Using new protocols seems to close back Web s into restricted contexts and to sacrifice interoperability. Non-HTTP transports that could prove to be very useful for asynchronism are SMTP (for light clients, since an always-on listener is no more mandatory) and even FTP (because of reliable delivery). However, these transports don t provide correlation features. 2.2 Correlation by application semantics With this correlation method, correlation information comes from semantics of data exchanged between Web s. This means that correlation between requests and responses is implicit within the application data. A typical example is the exchange of business documents between companies. For example, suppose that a customer wants to get an quote from a provider. The interaction can be implemented through an asynchronous Web service that asks for the quote request document and provides the quote. Correlation will be stored inside the quote document itself, which will contain a field called request reference number, with the ID of the related quote request. This is a very common interaction design approach, but has three main drawbacks: (i) application data structure must be completely shared between customer and provider; (ii) codes formats may be not very suitable for implementation (e.g., because they require conversions among the peers); (iii) there is no separation between application data and implementation issues. 2.3 Correlation by conversation metadata Conversation meta-data are additional structures, which do not describe application information but only Web services interaction details, describing exchanged messages, operation calls (one operation can have up to one inbound message and one outbound message), and

3 conversations (an higher level context that groups more Web s calls). Purposes of metadata are: - conversation management through information describing services to be called and order of the calls, - logging, tracking, and data warehousing of Web messages, operations and conversations. We will now quickly review a possible meta-data structure describing correlation and conversations, depicted as an ER schema in Figure 2. Message MessageID Content MessageType Name Format In 0:1 Out 0:1 In Out Operation OperationID 0:N 0:N PartOf 1:N OperationType PartOf OpName 0:1 PortName 1:N Binding 0:1 Name NetworkAddress Timeout Conversation ConversationID Status Conversation Type Name Timeout Figure 2 A possible metadata structure Conversation Types describe all the possible conversation models. Each of them is composed by a set of Operation Types, each one involving one or two messages, described by Message Type entity. Respective level entities describe runtime information about executed conversations. This schema can be integrated into the application data model. Usually application data entities are connected with or 1:N relationships with Conversation. Conversation, and in particular Conversation ID, is the typical connecting information that is exchanged between services. Actually, metadata can implement two distinct roles, that are pretty independent: (i) conversation description, management and logging; (ii) correlation information in single asynchronous calls. From an execution standpoint, metadata will be passed in both request and response messages, in addition to application data. Since this will likely bring to automated metadata parsing, correlation resolution and associated status data retrieval, the most appropriate solution would be to standardize metadata. Actually, lots of new standards and proposals exist. Many of them are very complex and cover several other aspects of Web s operations: transactions, reliability, coordination, and so on. 0:N We won t adopt a specific proposal here, but rather describe general methods of correlation, starting from the presented metadata schema, that seems the most complete and suited to the purpose. We will examine different solutions to achieve correlation by means of sub-parts of the presented metadata Correlation by Conversation context The first solution consists in using Conversation as correlation information for asynchronous interactions. This means that the Conversation identifier (ConversationID) is passed in each exchanged message, as shown in Figure 3, where Partner-A marks the request message with ConversationID attribute of his Conversation entity, and Partner-B returns the same identifier in the response message, through a ResponseTo field. This will make Partner-A able to perform correlation and to retrieve application data, related to current conversation (see Figure 4). WS Partner A Figure 3 Correlation through ConversationID Advantages of this approach are: - Easy application data retrieving (thanks to direct connection to Conversation ); - Only ConversationID needed for correlation among all different Web s calls; - Low overhead for metadata storage and management. Conversation SOAP Message ID: ConversationID(A) SOAP Message ResponseTo: ConversationID(A) 0:1 lication data Attribute1 Attribute2 WS Partner B Figure 4 lication data related to Conversation The main disadvantage is that coarse-grained context referencing (Conversation rather than single operation IDs) can produce response mismatches. Actually, if multiple asynchronous Web calls happen in the context of a single conversation, responses cannot be unambiguously related to their requests, as shown in

4 Figure 5, where the two responses can be reversely interpreted, since the correlator is always CID1. now solved (see Figure 8). can now track the correct request from the response correlator. Quote (CID1) Quote (OPID2) Quote (CID1) Quote (OPID3) QuoteResponse (CID1) QuoteResponse (OPID3) QuoteResponse (CID1) QuoteResponse (OPID2) Figure 5 Example of ambiguous correlation Thus, if you use this method, you should be sure to never have multiple pending request for a single operation at the same time Correlation by Operation context The second solution implements correlation by mean of the Operation identifier. Figure 6 shows the metadata used by each party, which include conversation instances and the connected operation instances. In request and response messages, OperationID is passed and returned back by the service provider (Partner B in Figure 7). Operation OperationID Conversation PartOf 1:N ConversationID Status. data ConvType Attribute1 Attribute2 Figure 6 Metadata for correlation by OperationID Each message is marked with the corresponding operation identifier. The service provider reads the message identifier and uses it as correlator, returning it back into the ResponseTo field. From this ID, partner A can then retrieve Conversation and application data through relationships. Note that OperationID(B) is not needed for correlation, but only to provide a unique identifier to each message. WS Partner A SOAP Message Figure 7 - Correlation by OperationID This solution is a general mechanism, that can always be used, since the problem of responses mismatches is 0:1 MessageID: OperationID(A) SOAP Message MessageID: OperationID(B) ResponseTo: OperationID(A) WS Partner B Figure 8 - Example of correct correlation On the other side, global complexity of the application will probably increase: several Operation s need to be stored for each Conversation, to keep track of each message, and application data retrieval will probably require heavier database queries Complete metadata structure In this solution, we suppose to implement the whole medatadata structure presented in Figure 2. As previously mentioned, the complete meta-schema grants the following features: logging, tracking, data warehousing of Web calls, management of different operations and message types, that is necessary in complex or non-static configurations to store information about the services to be called. The complete schema does not add expressive power to asynchronous correlation though. The most fine grained context found in Web calls, remains the actual Operation. Independent representation of IN and/or OUT messages (depending on the WSDL operation [14]) won t unveil uncovered scenarios, while just increasing the overall overhead, if only used for correlation. 2.4 Duality and comparison So far, correlation has been presented by means of two-message interactions. and Server takes the role of First message sender Return message sender. This is an operational notation rather than an high-level application category. A basic asynchronous interaction can be seen in the dual way by switching the message directions as well, just like WSDL Solicit- Response is the dual operation of -Response. The correlation mechanisms remain the same. Therefore, we can talk about generic peers of conversation, instead of and Server.

5 Correlator Advantages Disadvantages Transport level lication semantics Metadata: ConvID only Metadata: ConvID + OperationID Metadata: ConvID + OperID + MessageID Simplest and lightest implementation. Correlation comes directly from application data. Metadata not needed for correlation. Quite simple, adds little overhead to each call, easier application data retrieval. It works in every case. Same as previous. Async transports are not broadly supported and reduce interoperability. Sync transports only let synchronous interactions. It needs for a shared, high level semantic between partners. Correlation can t usually be automatic. It doesn t work in every case (need of a special hypothesis). Higher overhead; need of registering each operation instance; heavier data retrieval. Same as previous (but adds useless redundancy, from correlation point of view). Table 1 Pros and cons of correlation mechanisms Table 1 summarizes advantages and disadvantages of the different solutions. Next section will raise the view to synthesize what asynchronous configurations (or patterns) make sense and are actually useful in realworld scenarios, with special attention to B2B applications. 3. Asynchronous patterns An asynchronous pattern is a basic asynchronous configuration for interaction with Web s. Each pattern presented here has its own peculiarities together with a set of advantages and disadvantages, making it best suited for certain uses with respect to others. Starting from these basic patterns, variants can be studied to better suit all needs, and in real applications different patterns will be combined as part of a complex coreographed Web conversation. The following patterns will be discussed: Polling, Callback, lish-subscribe, Callback with acknowledgement, and lish-subscribe with acknowledgement. These patterns are inspired from use cases from W3C [13, 15] and industrial case requirements. Other pattern-based approaches already exist (e.g., [1]), but they are either at the implementation level, or simple scenarios, or do not clearly separate and motivate the various patterns. The main idea of our proposal is to describe how to compose simple (synchronous) WSDL operations [14] in a composite, asynchronous Web interaction. Additional correlation mechanisms, required in order to achieve asynchrony, are performed at the metadata level, not at transport level. This lets asynchronous Web s be built on a standard transport protocol like HTTP, which is stateless and synchronous. An ad hoc notation has been specifically developed for this task: each message-exchanging operation (corresponding to a WSDL operation), both on client and on server side, has been labeled with one of the following markers: - (lication): the operation has been performed as a result of a decision of either a human or an application. It is a consequence either of direct user interaction with the application, or automatic triggering of the operation because it is part of an automatic response service built by assembling simpler services. - (lishing): it represents a Web operation published at a given address, as specified in the related WSDL file, together with porttypes, operation and types details. These are typically oneway and request-response WSDL operations. Informally, these are the operations that are actually called. - Adv (Advertising): it describes publishing of a WSDL notification and solicit-response operations via WSDL file, for advertising. Actually, these types of Web s will not be exposed at a specific URL. The Web that will be invoked, is the dual one(oneway or request-response operation) which has been published by the corresponding client-side; these will be actually invoked, by the server side. 3.1 Polling pattern Polling is the simplest pattern to be implemented: by enacting this pattern, client acts only as consumer of the services the server will produce for him. Thus, we can say that it exploits a true client/server architecture. This pattern encompasses two WSDL operations: (i) a request-response to send the request; (ii)another request-response to ask for the answer. The client submits the request and receives immediately a synchronous acknowledgement, together with a request context identifier (CID). Later, the client invokes the service to obtain the answer; it will therefore send a message including the CID received before, in order to

6 allow correlation at server side. If in the meanwhile the server prepared the answer, the response is ready and the server provides it, otherwise the server returns a message stating the response is not ready yet, and asking the client to retry later. Ack Reply with CID Mail notification with CID Reply with Response Provider Figure 9 - Polling pattern The main advantage of this pattern is that it s not necessary to make any service available at client s premises, since it totally relies on invoking the server s services. On the other hand, this pattern is not very efficient, because: (i) the client should query the server many times to get the needed information; (ii) the client gets its answer not when it becomes actually available, but later in the future, when the client itself will actively ask for it. Nonetheless, these problems could be overcame by enabling the server to send a just-in-time notification e- mail to the client once the response is ready, thus letting the client know exactly when it s time to query the service. However, this assumes that the server should know a valid address of the client, which should be able to (automatically) read s. Typically this pattern will be used when a thin client is needed, not willing or not allowed to publish its own services to enact the callback mechanisms, e.g., e- commerce services and Web s integrators for B2C customers. Electronic purchase operations through the use of Web could this way be made possible, letting only the presentation be delegated to portals or third-parties. Customers of similar services browse online catalogues, fill up a shopping cart, and finally commit the order; first and second of these operations are usually performed synchronously, while the order commit is asynchronous, because the user cannot wait for an operation that may take hours or days to complete. Response Response 3.2 Callback pattern In the Callback pattern (Figure 10), the service provider publishes a one-way service, whose purpose is to accept the incoming client calls. Each request must include an identifier, the required input parameters and the Reply-to address. The Reply-to address is the address of the service which has to be invoked to provide the client with the response. (Peer) One way with: - CID - Reply-to address Response with CID to Reply-to address Figure 10 - Callback pattern Provider One way When the response for the client is ready, the service provider sends a message at the Reply-to address, bearing the response data. The Notification service at server side is therefore advertised, because the client must publish a service that fulfills the format of expected response from the service provider. The description of the structure of the message the client will receive lies in the WSDL description of the service, at service provider s premises, but the invoked service resides actually at client side and it is the service provider that calls the one-way operation published by the client. A typical example is a delivery service which uses Web s to receive shipment orders from several commercial partners. The client calls the transportation service and specifies the return address for its request. The one-way service published by the client must be compatible with the specification of the Notification operation published by the shipment company. Callback can implement also complex interaction between more than two partners, in which a peer delegates the response of a request to another one. In this case, suppose partner A sends a request to partner B, which in turn sends a request to partner C, specifying as reply-to address the url of partner A, together with a valid CID for partner A. The response of the service C will be sent directly to partner A of the conversation, without involving peer B again. Some proposals for supporting callback have been presented by various organizations: (i) WS-Callback Adv Notification

7 [12], which defines a SOAP Callback header and a WSDL definition for it. A Callback header becomes necessary when the Web is asynchronous and the reply-to address is unknown at deployment time; (ii) WS-Addressing [3] provides transport-neutral mechanisms to identify Web service endpoints and to secure end-to-end endpoint identification in messages, also in case of intermediate nodes processing. 3.3 lish-subscribe pattern lish-subscribe pattern generalizes callback at the purpose of modeling subscription to repetitive information delivery and event notification services. This is actually done by simply letting the client receive more than just an answer, as depicted in Figure 11. (Peer) One way StockInfoSubscribe StockUpdates Figure 11 lish-subscribe pattern 3.4 Callback with acknowledgement Provider One way This pattern is a generalization of callback pattern, in the sense that now each involved operation is bidirectional. In callback with acknowledgement (Figure 12), the client contacts the service provider by invoking a request-response service. This call can either succeed, and the client will thus receive the correlation ID as acknowledgement, or fail, and the server sends a denial of service message to the client. After acknowledge, to get the actual service response the client should now publish, a request-response operation to receive the response message from the dual solicit-response operation in the provider side, and send back an ack message. The main advantage of this pattern stands in the ability of sending a synchronous confirmation message. In business applications, this is often a mandatory requirement. The need for exchanging reliable and verifiable business messages is summarized in [18]. Adv Notification (Peer) response Figure 12 - Callback with acknowledgement pattern An example for this pattern is the client invoking a CommitOrder operation, asking for some products to be delivered. Depending on some conditions, shipping can either be confirmed (and returns an ack with service ID), or refused. If all goes well, at a latter time an OrderShipped service operation will return an asynchronous notification of shipment committed, with some other details about the shipment. 3.5 lish-subscribe with acknowledgement Since acknowledgement is an orthogonal mechanism, it can be used in single-request, multiple-responses configuration, thus generating a lish-subscribe with acknowledgement pattern. Its description is trivial, and omitted for lack of space. A possible example for this pattern comes again from the delivery service company. Once a client calls a CommitOrder service, he gets and ack message, and then, from time to time, an OrderUpdate operation called asynchronously from the shipping company, could notify the client with new information about the order status. 3.6 Pattern comparison Table 2 summarizes features and use cases of asynchronous patterns. Each of them appears to have a specific application area. 4. Experiences, Reply-to Address Ack with CID Response with CID to reply-to address Ack Provider response These concepts and categories have been implemented in several Web applications. Our approach to Web application development starts from a high-level specification through a conceptual model called WebML[5, 16], and provides automatic code generation [17]. Some primitives have been defined for Adv Solicit response

8 describing WSDL operations[5, 10]; they are then combined to design and implement the presented asynchronous patterns. This research is part of the WebSI (Web Integrator) project, funded by the EC in the Fifth Framework. Pattern Use cases Features Polling Callback Callback with ack. lishsubscribe lishsubscribe with ack. E-commerce B2C, Web portals. Long running async information retrieval services (not business critical). lish-subscribe services; e.g. news, business information,... Very simple to exploit but not very efficient. Harder to implement (client must publish listener), but more efficient. Suitable for P2P. Dynamic reply-to. Same as Callback pattern. Variant of callback, Inherits Callback features. useful to verify published Adds initial synchronous data reception. information. Variant of publishsubscribe. Useful for tracking purposes and in B2B WS transactions. Inherits lish-subscribe features. Adds initial synchronous information. Table 2 Main features of asynchronous patterns Some running Web applications have been built exploiting the presented design criteria. Among them, Acer Business Portal (that includes remote service calls for providing location and driving information to users), a section of PattiChiari Web site (the Italian Banks Association site, in which remote financial services are called), and MetalC project [11], which includes a set of B2B portals (one for each business partner). The purpose of MetalC is to allow business interactions between Italian companies of the mechanical field by means of their respective Web portals, through asynchronous Web services calls. In this context, all the patterns have been tested, and some of them have been chosen for final implementation. The most widely adopted pattern within this project is the Callback with acknowledgement : when a company sends a business document (e.g. a quote request, or an order or a bill) to a partner in the supply chain, a request is sent and the asker is notified by the acknowledge message. When the response is ready the provider sends it, and the client replies with an acknowledgement. This pattern proved to be the most valuable for business-critic interactions. 5. Conclusions and future work This work allowed to study at conceptual level asynchronous interactions between Web services. We have reviewed the possible levels at which it is possible to implement asynchronous correlation, and we offered a set of design patterns to construct complex asynchronous conversations. The main aspect to be investigated in the future is exception handling, with attention to missing and unexpected delivery of messages, and to their impact upon asynchronous communications. Bibliography [1] H. Adams, Asynchronous operations and Web s. IBM, [2] G. Alonso, F. Casati, H. Kuno, V. Machiraju, Web s - Concepts, Architectures and lications. Springer Verlag, October 2003 [3] A. Bosworth et al., Web s Addressing (WS- Addressing) [4] M. Brambilla, S. Ceri, S. Comai, P. Fraternali, Modeldriven development of Web s and hypertext applications. SCII03, June 2003, Orlando [5] S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera. Designing Data-Intensive Web lications. Morgan-Kaufmann, Dec [6] IBM, BPEL4WS Version 1.1, ibm.com/developerworks/library/ws-bpel/ [7] IBM, Reliable HTTP, com/developerworks/webservices/library/ws-httprspec/ [8] IBM, WS-Coordination. developerworks/library/ws-coor/ [9] Doug Kaye, Loosely Coupled: The Missing Pieces of Web s. RDS Press, June 2003 [10] I. Manolescu, M. Brambilla, S. Ceri, S. Comai, P. Fraternali, Exploring the combined potential of Web sites and Web services. WWW 03 (poster), Budapest, [11] MetalC site. [12] D. Orchard, WS-CallBack Protocol. BEA, CallBack-0_9.jsp [13] W3C, SOAP Version 1.2 Usage Scenarios, July 2003 [14] W3C, WSDL 1.1, [15] W3C, Web Description Usage Scenarios. [16] WebML site. [17] WebRatio site. [18] P. Yendluri, Web s Reliable Messaging,