Asynchronous Web Services Communication Patterns in Business Protocols Marco Brambilla, Giuseppe Guglielmetti, and Christina Tziviskou Politecnico di Milano, Dipartimento di Elettronica e Informazione, Via Ponzio 34/5, 20133 Milano, Italy {mbrambil, tzivisko}@elet.polimi.it,
[email protected]
Abstract. Asynchronous interactions are becoming more and more important in the realization of complex B2B Web applications, and Web services are at the moment the most innovative and well-established implementation platform for communication between applications. This paper studies the existing business protocols for Web services interactions, compares their expressive power, extracts a set of patterns for implementing asynchrony, studies the trade-offs and the typical usage scenarios of the various patterns, and finally proposes a sample application that has been implemented based on these patterns. The application has been designed using a high-level modeling language for Web applications, thus showing that the studied patterns can be applied at a conceptual level as well as directly at implementation level.
1 Introduction The Web is more and more consolidating 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: (i) when service time is expected to be either too long to make it comfortable to wait for a response or not predictable, because of the interactive nature of the application; (ii) when users may not be continuously online; (iii) when strict reliability and performance requirements are imposed. Since Web services are at the moment the most innovative and well-established implementation platform for communication between applications, their interactions are currently studied [16, 2]. Actually, the business world has shown growing interest in achieving loosely coupled, message based interaction’s forms for its Web application using Web Services [11]. Web service-specific standards for composition, orchestration and choreography, such as BPEL4WS, WSCI and WS-CDL, are outside the scope of this work, since they work at a much lower level. They do not explicitly address asynchronous mechanisms, although they provide the basic primitives that enable asynchronous implementations. Other authors address the asynchrony problem by means of patterns. In particular, [16] presents a set of patterns very similar to our proposal. The main differences are: they propose a message queue pattern, they do not consider factory and acknowledge
patterns, and they address the problem at a very lower level, by focusing on the design of the software for implementing the interactions. In [5], powerful patterns are presented, integrated with business logic: timers and data values are used to control multilateral interactions. Our approach is instead oriented to high-level design of the interactions, focusing only on the communication between B2B partners. Other pattern-based approaches exist in [1], but they are either at the very implementation level, or simple scenarios without motivating the various patterns. The paper is organized as follows: Section 2 presents a set of protocols for asynchronous Web services interactions; Section 3 presents the patterns that can be extracted from the protocols, while Section 4 compares the protocols’ expressive power based on these patterns; Section 5 presents the implementation experience using a high-level modeling language for Web applications, namely WebML [6, 11] extended with Web services primitives [14], and finally Section 6 concludes.
2 Protocols Various standards have appeared that support interactions among Web services. In this section we present six protocols that have gained acceptance for general use or in specific contexts. Indeed, some of them, like RosettaNet and IHE, are targeted to specific fields (e.g., industry or medical fields), while others, like ebXML, consist of complete specifications of business interactions. RosettaNet [10] is a non-profit business consortium of more than 400 leading companies in Information Technology, Electronic Components, Solution Providers, and Semiconductor Manufacturing. It provides standardization of: the business documents, the sequence of documents exchange, and the attributes that determine the service quality. The RosettaNet Implementation Framework defines the packaging, routing and transport of the messages in a secure and reliable way. Integrating the Healthcare Enterprise (IHE) [8] is a proposal for integration of existing standards, like HL7 and DICOM, in the healthcare environment in order to effectively share patient information across systems. The IHE Technical Framework specifies the workflow-based exchanges of messages among systems. The XML Common Business Library (xCBL) [13] is the standardization proposal from CommerceOne for documents definition. It specifies in XML the most common documents to be exchanged in B2B e-commerce scenarios, their contents and their semantics. The Electronic Business using eXtensible Markup Language (ebXML) [7] by UN/CEFACT and OASIS provides XML specifications for the exchange of business data, from a workflow perspective. The coordination protocol of the possible process scenario is built from the intersection of the partners’ process specifications. Asynchronous Service Access Protocol (ASAP) [3] is the proposal of OASIS for the integration of asynchronous services across the Internet. The asynchrony is based on the creation of an instance of the accessed service, called Instance, and an on-purpose Web service (Factory) used to monitor and control the state of the Instance services. The Open Grid Services Architecture (OGSA) [9] is the standardization effort by the Global Grid Forum, built upon Web services technologies for the description, discovery, invocation and management of Grid resources. The implementation of the architecture model takes place on the Open Grid Services Infrastructure.
3 Extraction of Patterns From the analysis of the considered standards, we can identify some common communication configurations between the involved partners. Two orthogonal aspects emerge: acknowledge mechanisms and interaction patterns. 3.1 Acknowledgement mechanisms In asynchronous communications receiving a response sent by the service provider acknowledging receipt of a request can be useful: this kind of acknowledgement is tied to the business logic of the communication and is independent to the acknowledgement returned by the transport protocol. We can identify three types of business logic acknowledgement: (i) request without acknowledgement; (ii) request followed by synchronous acknowledgement; and (iii) request followed by asynchronous acknowledge. 3.2 Interaction patterns The other aspect emerged from the analysis of the protocols concerns the interaction patterns between the partners involved in the communication. In the rest of this section, we briefly describe the six asynchronous patterns that have been identified, and we present their semantics, general features, and typical usage scenarios. Callback pattern. This pattern is a very general communication method: a request is made to the provider and a response is sent back to the requester when it is ready. In Fig. 1(a), the client submits a request to the service, and then proceeds with its own execution. When the response is completed, the service provider sends it to the requester. Since callback is the most important pattern for asynchronous interactions, some proposals for supporting callback already exist: (i) WS-Callback [15], which defines a SOAP Callback header and a WSDL definition for it; a Callback header becomes necessary when the Web Service is asynchronous and the reply-to address is unknown at deployment time. (ii) WS-Addressing [4] 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. Publish/Subscribe pattern. The Publish/Subscribe pattern allows information distribution to a group of partners. Fig. 1(b) depicts the behaviour of the client that is interested to receive notifications periodically by the published service. The client submits a subscription request to the service and continues its process execution. Whenever information needs to be notified to the client, the service provider sends a message response to him. Polling pattern. This pattern may be used as an alternative to the Callback pattern when the client cannot implement a Web service to accept the callback of his request. It allows the client to send a request to the service (Fig. 1c), to continue with the process execution and to periodically request the response from the service provider.
(a)
Callback
(b)
Service Requester
Service Provider
Publish - Subscribe Service Requester
Start
Request
Accept Request
Accept Response
Service Provider
Start
Request
Accept Request
Accept Response
Response
Response
Semantic Failure End
Success
(c)
Polling
(d)
Client
Service Provider
Request – Response Agent Service Service Agent Requester
Start
Asking Response
Service Requester
Service Provider
Start
Response
Request
Accept Request
Response
Send Request
Receive Request
Semantic Failure Receive Response
Success
Receive Response
Response
Send Response
Semantic Failure Success
(e)
Callback Factory Service Requester
(f)
Service Provider
Publish – Subscribe Factory Service Requester
Request
Request
creates
creates
Receive Response
Semantic Failure
Service Provider
Start
Start
Response
Receive Response
Response
End
Success
Fig. 1. Patterns
Request Response Agent Service pattern. The Request Response Agent Service pattern may be seen as an extension of the Callback pattern when the requester cannot interact directly with the service provider. This configuration is depicted in Fig. 1 (d): the agent requester sends its request to the service requester and continues its computation; the service requester forwards the request to the service provider in an asynchronous way. When the response is ready, the service provider sends it to the service requester that, in its turn, forwards it to the agent requester. One of the main
requester that, in its turn, forwards it to the agent requester. One of the main advantages of this pattern consists in a more strict-decoupling between agent requester and service provider, thanks to the intermediate layer of the service requester. A variant of this pattern exists which allows the service provider to accept the identity of the agent requester and send the response directly to him. Callback Factory pattern. The Callback factory pattern has the same usage of the previously presented Callback pattern but the request is processed by a service instance dedicated to the present interaction. The lifetime of the service instance is dynamically controlled by the Factory service. In Fig. 1 (e), the client sends a request to the Factory service and continues its process execution. The Factory service creates an instance of a service dedicated to fulfil that request. Once the response is ready, the service instance sends it to the requester. The Factory service will terminate the instance when the whole interaction is completed. Therefore, this pattern allows every requester to enjoy a dedicated service for unlimited time. Publish/Subscribe Factory pattern. The Publish/Subscribe factory pattern is similar to the previously described Publish/Subscribe pattern. The server requester submits a subscription request to the factory service and continues its process execution. The factory service creates a new instance dedicated to that subscription. Whenever information needs to be notified to the client, the service instance sends a message response to it (Fig. 1 (f)). Like the Callback factory, this pattern creates a dedicated service to the client, so that further requests may be fulfilled by that instance. These six asynchronous patterns can be used in conjunction with the three types of acknowledgement presented in Section 3.1, according to the needs. Indeed, these two aspects are orthogonal, and can be combined at wish.
4 Comparison of the Protocols In this section, we offer a very simple expressive power comparison between the business protocols introduced in Section 2. In particular, we present the patterns supported by each protocol and explain the mere realizability of patterns due to the very diverse characteristics and targets of the various standards. Therefore, any other way for comparing them would be rather unfeasible. For each protocol, Table 1 registers the existence (+ sign), or the absence (– sign) of the studied patterns. Table 1. Patterns support in the existing standards Callback Publish – Subscribe Polling Request Response Agent Service Callback Factory Publish Subscribe Factory
RosettaNet + + -
XCBL + -
ebXML + + + -
IHE + -
OGSA + + + +
ASAP + -
As we can see from the table, Callback is the pattern supported by most of the protocols. This is justified by the fact that business interactions are mostly based on request-response message exchanges and less on other architectures. Moreover, Call-
back is the simplest asynchronous pattern, which constitutes the basis of asynchrony itself. Thus, business protocols like RosettaNet, xCBL and ebXML implement this pattern and give less importance to the others. In more details, RosettaNet and xCBL are focused on the documents specification and use the traditional request-response pattern for the messaging specification. IHE is another standard where business documents are more important than the messaging techniques, and therefore, it is limited to the Callback pattern. On the other hand, ebXML is the standard that supports the largest number of patterns. It provides a complete business framework that supports even publish-subscribe and polling patterns. The Factory patterns are supported only by OGSA and ASAP. ASAP assumes the Factory pattern as the basis for every asynchronous interaction, thus making it the main philosophy of the protocol. The main reason for OGSA for implementing a Factory pattern stands in the fact that several instances of a Grid service exist at the same time only after respective client requests. After terminating its interactions, every resource may be released and be ready for a new request. The mechanism supported by the Factory patterns can dynamically control such interactions in the grid.
5 Pattern Modeling in WebML WebML is a conceptual language for specifying Web applications developed on top of database content described using the E-R model. A WebML schema consists of hypertexts (site views), expressing the Web interface (pages) used to publish or manipulate the data specified in the underlying E-R schema. Pages enclose content units, representing atomic pieces of information to be published from an underlying entity. Pages and units can be connected with links to express a variety of navigation effects. Besides content publishing, WebML allows specifying predefined or customized operations: the creation and modification of entity instances, the creation of relationship instances, the filling of a shopping cart, and so on. Products page Product Index
Product
Product page Product Details
Product
Resellers page Request Reseller
Resellers Index
Reseller
Creation page New Product
Products page Create Product
Product
New Product
Product
Fig. 2. WebML site view diagram featuring pages, units, operations and Web services
In order to exemplify WebML, we describe the purchase process of goods performed through the interaction of the buyer and the supplier on the Web. In the hypertext diagram of Fig. 2, the buyer selects a product from an index and look at the product details (Product page). To describe Web services interactions, appropriate WebML units have been devised [14] that correspond to the WSDL type description of Web services. In Fig. 2, once the user navigates from the Product page, a request is made (outgoing message) to the Web service in order to gather all the suppliers of the selected product. After the response is constructed (incoming message), the user visualizes all the sellers of the product (Resellers page). Other WebML Web service
alizes all the sellers of the product (Resellers page). Other WebML Web service units correspond to publishing primitives (Fig. 3), since they allow the application to stand and wait for incoming messages. Finally, in the seller’s site, the Creation page (Fig. 2) allows the seller to create a new product through a form and visualize its attributes. (a) Supplier Factory Data Model Group
User 0:N 0..*
1:1 1.. 1
1:N 1..*
1:1 1.. 1 1..* 1:N
1..* 1:N
OID Status
1:1 0:N 1 0..*
0:N 0..*
1:1 1
1:1
OID Address ExtCID
1..1 1..1
1:1
FactoryBinding
InstanceBinding
ObserverBinding
OID Description Expiration Key Name Subject
OID State
OID Key
SiteView OID SiteViewID
External Conversation Instance
Conversation Instance
OID Password Username ...
OID GroupName
0..* 0:N
1.. 1 1:1
1:N 1..* 1..1:1 1
1:1 1..1 1..1 1:1
Order OID Price Status
Item 0:N 0..* 1.. 1:1 1
OID Amount Code
Product 1:1 0:N 1.. 1 0..*
OID Code Description
(b) Supplier Quote Web service publication Accept Quote
Create Order
Order
...
CreateInstance
InstanceBinding
...
AddObserver
ObserverBinding
...
CreateConversation
Conversation Instance
...
CreateExternal
...
External Conversation Instance
Fig. 3. Callback factory pattern: Supplier data model and Web service publication
Fig. 3(a) describes the data model of the application for the Supplier, realized using the callback factory pattern. User’s related data is kept into the User, Group and SiteView entities. The Conversation Instance and External Conversation Instance entities represent the way in which correlation in exchanged messages is realized in WebML: a user participates in a Conversation Instance and each Conversation Instance may be correlated to one or more External Conversation Instances and be connected to application data. The External Conversation Instance contains the Conversation ID that the remote partner internally uses (ExtCID) and the URL of the partner (Address). This model allows to couple different ID mechanisms for different partners. The entities Factory Binding, Instance Binding, and Observer Binding represent the way in which the factory scheme is implemented based on ASAP [3] metadata description. Factory Binding entity contains all the data needed to identify the factory service and is connected to zero or more Instances. Each Instance represents the instance of the web service created on demand by the factory. It is connected to one or more Observers, to Conversation Instance and to application data. Fig. 3(b) illustrates the Web service published by the Supplier. For the sake of simplicity, in the presented WebML diagram we do not represent (1) the connection operations that create associations between objects (we use […]), and (2) data and connect units required for the complete context retrieval of the conversation. The Supplier factory publishes a solicit-response service unit to accept orders to be quoted. Whenever an order arrives, the order is recorded in the database, a new instance of
service is created and part of the data of the Buyer is recorded in an observer binding; then a new conversation is created and the remaining part of data of the Buyer are recorded in an external conversation instance.
6 Conclusions This work presented our study of various business standards for asynchronous interactions. We extracted a set of interaction patterns, and we provided some evaluations and typical usage scenarios for each of them. Our main contribution consists in describing asynchronous interaction between Web services with a high level of abstraction, and then providing implementation experiments of the patterns. Based on these patterns, expressive power of the existing standards has been compared. Identified patterns are also useful in process design, since they provide certified solutions to important problems. The analysis of patterns advantages and drawbacks highlighted that Callback is the most suitable pattern for business transaction, together with fullfledged acknowledgment mechanisms. Each standard usually provides the patterns required for its specific target, but Callback patterns are supported almost everywhere. In the last part of the paper, a simple running case gives an overview of our experience: we modeled the interactions in WebML [6], and we demonstrated the patterns by using the WebRatio [12] CASE tool.
References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Adams, H., Asynchronous operations and Web Services. IBM http://www106.ibm.com/developerworks/library/ws-asynch1/index.html Alonso, G., Casati, F., Kuno, H., Machiraju, V., Web Services - Concepts, Architectures and Applications. Springer Verlag, October 2003. ASAP site http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=asap. Bosworth, A., Web Services Addressing. http://msdn.microsoft.com/ws/2003/03/ Service Interaction Patterns site http://www.serviceinteraction.com. S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera. Designing DataIntensive Web Applications. Morgan-Kaufmann, Dec. 2002. Electronic Business Using eXtensible Markup (ebXML) site http://www.ebxml.org/. Integrating the Healthcare Enterprise (IHE) site http://www.ihe.net/. Open Grid Service Architecture (OGSA) site http://www.globus.org/ogsa/. RosettaNet site http://www.rosettanet.org/. WebML site http://www.webml.org/. WebRatio site http://www.webratio.com/. xCBL site http://www.xcbl.org/. Manolescu, I., Brambilla, M., Ceri, S., Comai, S., Fraternali, P., Model-Driven Design and Deployment of Service-Enabled Web Applications, TOIT, 5 (3), August 2005. Orchard, D., WS-CallBack http://dev2dev.bea.com/webservices/WS-CallBack-0_9.html Yendluri P., Web Services Reliable Messaging, http://webservices.org/ Zdun, U., Voelter, M., Kircher, M., Remoting Patterns: Design Reuse of Distributed Object Middleware Solutions. IEEE Internet Computing, Nov-Dec 2004.
