On the Integration of Heterogeneous Web Service Partners

On the Integration of Heterogeneous Web Service Partners Francisco Curbera, Ignacio Silva-Lepe and Sanjiva Weerawarana IBM T. J. Watson Research Center {e-mail: curbera, isilval, sanjiva @us.ibm.com } August 9, 2001 Abstract A new distributed computing model for the Web is now being defined as a result of several ongoing standardization initiatives. This effort is driven by the need to enable open business to business (B2B) interactions on the Web, and is centered around the development of new vocabularies based on the Extensible Markup Language (XML) standard. The Web Services Description Language (WSDL), the interface definition language of the new computing stack, introduces a new generic model of application interactions. This position paper maintains that, while WSDL promotes the use of both messages and operations, it falls short of supporting the full integration of Web Service interactions, at least as it pertains to the timing and coupling aspects of such interactions. We further maintain that this integration can be better understood and approached from the point of view of a generalized framework for Web Service interactions. 1 Introduction Up until now, the Web has fundamentally been a vehicle for human to application interactions. This situation is already changing, as more and more businesses move their interactions with other business to the Web. It is expected that business to business (B2B) interactions will be dominant in the near future. B2B usage of the Web is bringing a new focus on application to application interactions and on the need to enable distributed computing on the Web. The goal of an application-to-application Web is to formalize today s ad hoc B2B scenarios into a standard platform for application-to-application integration. Ongoing standardization efforts have a common reference on the Extended Markup Language (XML). The Web services model [8, 5] develops a componetized view of Web applications, and could is quickly becoming the articulating concept for the new computing platform. It considers a loosely integrated component model, where a component (a Web service ) encapsulating any type of application logic is described in a standardized interface definition language, the Web Services Description Language, WSDL [4]. Web service components interact over a standard XML messaging protocol that guarantees broad interoperability between components, such as the Simple Object Access Protocol, SOAP [3]. The composition model for Web services is explicitly addressed by a recent proposal, the Web Services Flow Language [6], which builds on the component interaction model defined by the interactions types supported by the WSDL interface definition language (a connection oriented model, see [10]). In this paper we consider interaction models of the Web services framework. In particular, we maintain that a systematic clasification of interactions types according to timing and targeting semantics is a fundamental first step in integrating Web Services interactions. The first interaction type refers to the synchronous and asynchronous nature of the interaction, while the second looks at the difference between purely targeted interactions like remote procedure calls and anonymous interactions like messaging. Appropriate bridging and middleware can enable connectivity across interaction models. This paper is organized as follows. In Section 2 we present a brief description of the Web services standards that are just now emerging. In Section 3 we consider the integration of Web Service partners. Section 4 reviews related work in this area, and Section 5 concludes the paper. 1

2 Service Description Language: WSDL We briefly describe the Web Services Description Language, paying special attention to the characteristics that are more relevant to our discussion. WSDL is an interface definition language that allows pluggable protocol bindings. WSDL interface descriptions are structured in two sections: abstract message and interface definitions, and interface protocol bindings. Abstract messages are composed of one or more parts, each part being defined using a type definition language, typically XML Schema. It is important to note that these message definitions are abstract, and may not necessarily correspond to the actual message as encoded on the wire : additional encoding steps can (and typiclly will) be specified at binding time. Service interfaces are defined as collections of actions offered by a service component. A set of actions or operations constitute an interface or porttype. The operations themselves can follow four patterns, which include not only the traditional provided type of operations, but also required operations. Thus, together with the usual single incoming message ( one-way ), and request-response patterns, WSDL allows a single outgoing message ( notification ), as well as an outgoing message followed by a related response ( solicit-response ). A porttype may contain any mix of these four types of operations. The signature of each operation is defined by its exchange pattern and by the types of the messages being exchanged. Thus, at the abstract interface definition level every operation is modeled as a message exchange, and no hard distinction is made between message and procedure (or RPC) oriented actions. The additional features that distinguish one from the other are considered as binding-time details. The binding part of a WSDL description maps the abstract functionality to a specific set of deployment mechanisms, defining the details of how the service is provided. The types of information that are included in an interface binding include: transport protocol bindings, message envelope formatting details, data serializations mechanisms (message encoding to be used), out of band information like headers, etc. Since many of the interface binding details are different for each or the operations supported, the WSDL bindings use the operation name as a convenient way of matching deployment details to individual actions in the interface. This is the reason why the operation name is required when the operatoin is defined, regardless of whether it has any run-time significance. WSDL bindings are a flexible mechanism to provide deployment information for abstract interfaces, albeit in the current model, the binding element can be easily overloaded with too many unrelated deployment details. 2.1 Service Flow Language: WSFL The Web Services Flow Language [6] is a language for describing Web service compositions. WSFL considers two kinds of compositions: flow models and global models. Flow models provide an abstract representation of the execution of an application and the sequencing of the interactions it conducts with its partners. The model is extremely simple: a flow is a directed acyclic graph, in which the nodes or activities represent either internal processing steps or interactions with other applications. The execution graph controls and represents the sequencing of the interactions between an application and its external partners, and can thus be used to represent application behavior. Global models define compositions of Web services by describing the distributed interaction of a collection of applications. The interaction model in WSFL derives directly from the WSDL interaction model. A service interaction is based on the connection between WSDL operations with similar but dual signatures, where the dual relationship refers to the direction of the operations. The composition of Web services is modeled by so called plug links, representing a connection between two applications through two compatible operations on their interfaces. It is important to observe that this model implies that only one-to-one connections between operations are allowed. 2

3 Considering the Integration of Web Service Partners To understand the problem of integrating heterogeneous Web Service partners, it is useful to consider aspects of heterogeneity. Web clients and services can be synchronous or asynchronous, they can be RPC-based or message-based. Let us consider how these interaction aspects pertain to the domain of Web Services as they, in turn, provide a paradigm for heterogeneous, cross-enterprise application interaction. 3.1 WSDL As we have noted, a Web Service description, as expressed in WSDL, includes a number of abstract specifications of port types consisting of any number of operations, a number of bindings (one for each port type), and a number of service specifications that denote associations of application components, as indicated by their location, with bindings for abstract port types. It is our position that WSDL could better support the integration of heterogeneous Web Services, by addressing the timing and coupling aspects of heterogeneity, as follows: Timing Aspect. The types of a port type s operation, as given by the implicit order and combination of its input and output sub-elements, only focus on either synchronous/two-way or on one-way interactions, and there is no support for the notion of an asynchronous/two-way interaction. Coupling Aspect. Even though the elements of a port type are operations, there is no implied assumption about their interaction coupling aspect. In other words, a port type s operation can represent either a targeted or an anonymous interaction. In particular, an operation can stand for an anonymous invocation by conveying a command pattern or a more generic send pattern. In addition, at the bindings level, WSDL is not explicit either about the timing or coupling aspects of Web Service interactions, although the WSDL specification does include extensibility elements for SOAP, HTTP and MIME bindings. With exception of SOAP used in conjunction with non-synchronous transports, all of these extensions only focus on a choice of synchronous, targeted interactions. But this does not have to be the case. Message-oriented applications are also legitimate Web Service partners, provided the appropriate integration framework is in place. We maintain that by integrating their interaction aspects, Web Service partners (be them RPC-based or Message-oriented applications) can have a homogeneous perspective when interacting with each other. With the two interaction aspects under consideration in hand, we can start to tackle the integration of interacting partners that incorporate both of these aspects. Specifically, we are interested in how such a conceptual framework can leverage the integration of heterogeneous kinds of Web Service partners, in particular, RPC-based and Message-Oriented Applications. We believe that, to concretely address the integration of Web Service interactions, WSDL must be extended with the following features. Specification of asynchronous/two-way operations. There should be an explcit way to distinguish this kind of operation to then enable its integration with synchronous operations. Specification of bindings for interaction coupling choices. It should be possible to specify not only services, but also clients, and even the medium item, to enable meaningful combinations. Specification of correlation information. This information is not necessarily infrastructure-related only. That is, it could be useful as application-level information as well; for example, a social security number. As such, it should be possible to manipulate this information explicitly as well. 3.2 WSFL From a WSFL perspective, the integration becomes a requirement. In this context, the meaning of Web Service partners interacting asynchronously depends on what side of the interaction we are on. For a Web Service client this means that it will use notification operations to send asynchronous requests, and oneway operations to receive asynchronous replies. While this is not the typical kind of client, it is certainly a 3

legitimate flow-like use case. For a Web Service itself, asynchronous interaction means that it will use oneway operations to receive an asynchronous request and notification operations to send asynchronous replies. This use case is even less typical but no less legitimate. In particular, if the two operations involved in the asynchronous interaction are composed in a flow-like kind of service, then their execution contexts may not necessarily be the same and so it is useful to have a well defined meaning for it. Thus, asynchronous clients and asynchronous services are actually natural in flow-like composition, where the operations become the embodiment of activities that are linked within a flow. This means that a well understood conceptual framework for, at least, synchronous/asynchronous interactions is essential. But also, it is not unreasonable to assume that some implementations of WSFL will be message-based while others may not. Thus the full integration framework becomes necessary. 4 Related Work 4.1 CORBA Messaging The CORBA Messaging service [16] defines an Asynchronous Method Invocation (AMI) model to allow CORBA objects to be invoked asynchronously from clients. This way, a CORBA client does not need to wait for an invocation on a CORBA object to complete, it can receive a reply at a later time. A CORBA object is unaware that this is actually happening. From its point of view the invocation could as well have been made synchronously. This illusion is accomplished by transforming a plain IDL interface into an implied IDL interface for clients to use and by poten-tially storing and forwarding requests and replies. Asynchronous invocations can be made in two modes: callback and polling. In the callback mode a callback object reference is passed by a client as part of the invocation. When a reply is ready, the callback object is invoked with it. This callback object is defined as a ReplyHandler in the implied IDL. In the polling mode, the invocation returns an object that can be queried at any time to obtain the status of the outstanding request. This object is defined as a Poller value in the implied IDL. CORBA Messaging is a facility for allowing CORBA clients to interact asynchronously with CORBA servers, both of which are entities that are interacted with via object references, that is, in a targeted fashion. Furthermore, one of the goals of CORBA Messaging is to make AMI opaque to servers. In other words, CORBA servers are always synchronous. 4.2 Container-managed Messaging Container-managed Messaging [17] is aimed at providing a uniform view of either object-oriented components or message-oriented applications to object-oriented components. To this end, an architecture and programming model is defined that approach messaging as a container-managed service. The programming model includes a modes of interaction aspect that is analogous to the interaction timing aspect we present. It also includes a degrees of transparency aspect that addresses the exposure of an objec-oriented component to the messaging domain. The architecture includes artifacts such as a message proxy, a result proxy, a message listener, and a callback proxy. While container-managed messaging presents an approach to integrating object-oriented components and message-oriented applications, it does so from the point of view of the object-oriented component. In particular, the interaction coupling aspect we have presented is not fully addressed. Also, there is no attempt at providing a more neutral specification mechanism for the kinds of interacting partners. References [1] The Business Process Management Initiative, http://www.bpmi.org. [2] BizTalk, http://www.biztalk.org. 4

[3] E. Box, D. Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. F. Nielsen, S. Thatte, D. Winer, Simple Object Access Protocol (SOAP) 1.1, May 2000. Available at http://www.w3.org/tr/soap. [4] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana, Web Services Description Language (WSDL) 1.0, September 2000. Available at http://www.ibm.com/developer/web. [5] IBM Corporation, Web Services Architecture Overview, September 2000. Available at http://www.ibm.com/developer/webservices. [6] IBM Corporation, Web Services Flow Language (WSFL 1.0), available at http://www- 4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf. [7] IBM Corporation and Microsoft Corporation, Web Services Framework, Available at http://www.w3.org/2001/03/wsws-popa/paper51 [8] Microsoft Corporation, XML, Web Services, and the.net Framework, 2000. Available at http://www.microsoft.com/net. [9] J. Siegel, CORBA 3. Fundamentals and Programming, John Wiley & Sons, New York, 2000. [10] C. Szyperski, Component Software : Beyond Object-Oriented Programming Addison-Wesley, Harlow, England, 1997. [11] UDDI Project, UDDI Executive White Paper, September 2000. Available at http://www.uddi.org. [12] UDDI Project, UDDI Technical White Paper, September 2000. Available at http://www.uddi.org. [13] World Wide Web Consortium, XML Schema Part 1: Structures, W3C Candidate Recommendation, October 2000 Available at http://www.w3.org/tr/xmlschema-1. [14] World Wide Web Consortium, XML Protocol Activity, http://www.w3.org/2000/xp/. [15] XAML - Transaction Authority Markup Language http://www.xaml.org. [16] CORBA Messaging, May 1998, OMG TC Document orbos/98-05-05, Available at http://www.omg.org/cgi-bin/doc?orbos/98-05-05 [17] I. Silva-Lepe, C. Codella, P. Niblett, D. Ferguson, Container-Managed Messaging: An Architecture for Integrating Java Components and Message-Oriented Applications, Proceedings of the 37th International Conference on Technology of Object-Oriented Languages and Systems (TOOLS-Pacific 2000), November 2000, Sydney Australia. 5