On the Emergence of a Web Services Component Model - CiteSeerX

On the Emergence of a Web Services Component Model Francisco Curbera, Nirmal Mukhi and Sanjiva Weerawarana Component Systems Group IBM T.J. Watson Research Center Hawthorne, NY. {curbera, nmukhi, sanjiva} @us.ibm.com June 1, 2001 Abstract The Web services framework is an effort to transform the set of technologies that are used today in ad hoc business-to-business scenarios into a standard platform for distributed application-to-application integration. This platform can be organized in three sets of specifications: the description of the formats and protocols for communicating between applications, the models and languages used to describe how applications interact, and a framework to enable the discovery of such descriptions. The architecture of this platform and its constituent parts are currently being defined by industry groups and standards bodies. In this paper we present a brief overview of the Web services platform. We maintain that the underlying problem is naturally well suited to benefit from a component oriented architecture, and we examine the possible component interaction models that can be supported by the new platform.

1

Introduction

Until recently the use of the World Wide Web has been mostly limited to the interaction between Web applications and browsers, with HTTP and HTML forms as the primary support mechanisms for this clientserver interaction. During the last few years the Web has been used more and more for ad hoc business-tobusiness integration using the basic infrastructure of HTTP, XML and forms. The Web services framework is an effort to transform the set of technologies that are used today in ad hoc business-to-business scenarios into a standard platform for distributed application-to-application integration. This platform can be organized in three sets of specifications [3]: the description of the formats and protocols for communicating between applications, the models and languages used to describe how applications interact, and a framework to enable the discovery of such descriptions. The architecture of this platform and its constituent parts are currently being defined by industry groups and standards bodies. In what respect is this stack different from previous distributed computing models? A computing model for the World Wide Web must address the open, heterogeneous and dynamic nature of the medium. A set of key requirements derive from these characteristics (see [2]): • The level of common infrastructure that can be safely assumed to be present at each computing node must be minimal. Following the example of the early Web, a small set of supported standard protocols and data formats is all that can be expected. • The acceptable level of application integration is necessarily very low, and the coupling between applications very loose. • Instead of assuming a common set of predefined interfaces, the model should rely on a basic set of message and document formats. The focus shifts from the APIs supported by each platform to what

1

“goes on the wire”. In this environment, message brokering and translation become a key mechanism for providing service interoperability. • Ad hoc integration replaces systematic application integration. Enabling short-term relationships is a central goal of the model. • Applications (services) are located by their abstract characteristics and technical capabilities instead of by name (as used in JNDI lookup, for example.) The above list states three required characteristics of a successful Web computing model: encapsulation, loose coupling, and dynamic binding. We maintain that these three general principles, and the characteristics listed above, can be appropriately addressed by a Web services component framework. Moreover, a component model for Web applications can be instrumental in enabling a component market for Web services and value added service compositions. This paper is organized as follows: in Section 2 we present a brief overview of the current state of the Web services platform. In Section 3 we discuss the possible component interaction models that can be supported by the Web services framework, and the Web infrastructure required to support each one. Section 4 presents a summary and conclusions.

2

A Web Services Computing Stack

The Web services framework is a platform for application-to-application integration on the Web. Several Web services specifications address basic interoperability issues as well as high level services. All these initiatives share a common characteristic: the acceptance of XML and the fundamental XML specifications (XML Schema in particular, see [13]) as the cornerstone of interoperability on the Web. In particular, this implies the assumption that the data exchanged will be XML data described by an XML Schema, and that every language used will have XML syntax.

2.1

Stack Overview

In this section we present a brief overview of the Web services computing stack as described in [2] and [3]. It is now customary to organize these efforts into three Web services sets of standards or “stacks” [3]: the formats and protocols for communicating between applications, the models and languages used to describe how applications interact, and a framework to enable the discovery of such descriptions. In the interest of conciseness we concentrate on four specifications: • Communication protocols: SOAP. Despite its name, the Simple Object Access Protocol (SOAP, [6]) is nothing but a basic XML messaging protocol. SOAP provides a few conventions about how to structure headers and body in an XML message, and about how to interact with intermediaries. SOAP is declared to be transport independent, but the SOAP specification defines an HTTP binding for the protocol. SOAP also defines a mechanism for doing remote procedure calls using XML messages: in doing so, the specification introduces a synchronous request-response type of interaction between applications, in addition to message passing. SOAP is being extended to define how to deal with non-XML data, implement reliable transmission, and provide basic security functions. SOAP is being standardized by the XML Protocol Activity in the World Wide Web Consortium, [7]. • Service interface description: WSDL The Web Services Description Language (WSDL) is a language for describing abstract service interfaces, and their protocol bindings and deployment details as well. A single WSDL document can provide a consuming application with complete information on the service’s interface as well as how and where to access it.

2

WSDL does not explicitly define a component interaction model for Web services. While the specification refers several times to WSDL “components”, it does not provide an explicit definition of its defining features, composition properties, or communications channels. We return to this point in Section 3. • Description of service compositions: WSFL. The Web Services Flow Language is a language to describe compositions of Web services. WSFL considers two types of Web Services compositions: The first type specifies the appropriate usage pattern of a collection of Web Services, according to a “flow model”; the result is a description of a business process. The second type (a “global model”) specifies the interaction pattern of a collection of Web Services by means of connections established between endpoints in their public interfaces. We return to these two types of composition in Section 3. • Service registry: UDDI. Web services directories are required to enable and support the expansion of the B2B Web [10]. A directory must allow direct retrieval of information about known services, as well as discovery of services based on taxonomical descriptions. The Universal Description Discovery and Integration specification (UDDI, [11]) defines data structures for the description and classification business services, and a SOAP interface for accessing this information.

2.2

Web Services Component Infrastructure

The Web services framework defines a very basic component infrastructure. One of the main objectives of SOAP is to enable communication between disparate application parts, that is, components belonging to different component models. WSDL is a component description language which focuses on the definition of component interfaces and protocol bindings. However, WSDL is likely to grow to include the ability to describe “non-functional” characteristics of Web service components such as quality of service parameters, see [2]. WSFL serves the role of a component composition language. It addresses many of the requirements of a component composition language [16, 17] and is built cleanly on the component model of WSDL. Finally, UDDI serves as the component registry or marketplace; applications use UDDI dynamically to find other components based on their interfaces (as described in WSDL) or their non-functional characteristics, see [12]. Web services therefore present an immense opportunity for the component-oriented programming community: It offers the promise of a widely distributed component platform upon which higher level component orientation issues can be addressed.

3

Component Interaction Models for Web Services

We have just seen that WSDL does not explicitly formalize a component interaction model for Web services. However, the basic operations of a WSDL interface implicitly define a certain component interaction mechanism that constitutes the base for a service component model. This model is in turn the base for the component composition mechanisms introduced by WSFL. In this section we present this interaction model, and we discuss possible extensions and alternative models.

3.1

A WSDL Component Interaction Model

WSDL interfaces (port types in WSDL terminology) support four types of operations, corresponding to the incoming and outgoing versions of two basic operation types: an incoming single message passing operation and its outgoing counterpart (“one-way” and “notification” operations), and the incoming and the outgoing versions of a synchronous two-way message exchange (“request-response” and “solicit-response”). Any combination of incoming and outgoing operations can be included in a single WSDL interface. As a result, the four kinds of operations provide support for both pull and push interaction models at the interface level. The inclusion of outgoing operations is motivated by the need to support loosely coupled peer-to-peer interactions between services; it is not related to any attempt to provide an architectural description of the service component. In the most basic service interaction mechanism, a connection is established between endpoints with dual signatures, and represents a single invocation of the target (an incoming operation type) by the client source 3

(a compatible outgoing operation). Note that the connection does not represent a permanent communication channel, as in even notification models. This interaction mechanism is particularly well suited for supporting very loose and dynamic coupling between components, especially when it is combined with dynamic binding of target endpoints (clearly, in a tightly coupled model there is little reason to representing both the caller and callee as separate operations). It has to remarked that WSDL does not specify explicit mechanisms for configuring connections, a fact that constitutes a major drawback in the basic WSDL component model. This very basic model has the virtue of accurately representing existing Web infrastructure in which interactions are mediated by either message exchanges or remote method invocations. Moreover, the lack of explicit configuration mechanisms is only a consequence of the non- existence of these mechanisms on deployed services, which rely on ad hoc internal methods for connection configuration. The composition model of WSFL relies on this connection-oriented interaction model as the basic form of communication channel in distributed service compositions (which it names “global models”). WSFL also considers flow models, compositions of services according to a workflow metamodel; however, the basic component interactions that could support the flow composition model are not supported by WSDL, and must be provided by a controlling workflow engine.

3.2

Alternative Models for Web Services Interactions

We now consider three possible extensions and alternatives to the component interaction model presented in the previous section. These additions would allow WSDL to more accurately reflect the interaction types supported by current Web applications. 3.2.1

Support for Asynchronous Interactions

Two-way interactions in WSDL are always assumed to be synchronous. This is quite a restrictive assumption, which does not reflect the reality of Web service interactions. Two aditional elements are enought to enable full support of the asynchronous case: the correlation of operations and messages, and the specification of “reply-to” addresses. Consider for instance the definition of the “client” interface: asynchronous two-way functionality is enabled by associating a one-way outgoing to a one-way incoming operation, in such a way that the incoming message is defined to be to be the asynchronous response to the outgoing one. The correlation has to be explicitly declared in the interface, but the mechanism can be either implicit (managed by supporting middleware) or explicit (defined at the application level by reference to the information that is exchanged). In turn, the reply-to address allows the “server” to find the appropriate target where the response must be sent. 3.2.2

Event Notification

WSDL does not provide an event notification interaction model. WSDL notification operations represent a “client” making a single invocation of an operation in a “server” (one-way or two-way). A connection between source and target operations represents a one time event carried over a point-to-point connection, not a stable communication pipeline between an event source and one or many event sinks as in the event notification model. However, publish-subscribe is one of the most relevant interaction types that enable flexible application integration in distributed environments (see for example [15]). While Web applications themselves are seldom modeled as event sources, the increased availability of a publish-subscribe infrastructure enables a “regular” service to behave like and event source or an event sink with little or no required modification of the service. In this respect WSDL will quickly find itself lagging behind the existing Web infrastructure unless it is extended to provide first class support for event notification. To represent event notification in WSDL it is necessary that the language support for outgoing operations be extended in two directions: enabling multitargeted interactions and enabling persistent connections. A new kind of multitargeted outgoing operation is needed to represent an event source. Observe that a mechanism for registering the targets must also be provided, but this mechanism is also needed for existing single target 4

outgoing operations, if dynamic binding scenarios need to be supported in the current model. A common solution to this last problem is to use a design pattern in which an incoming configuration operation is associated to an outgoing dynamically configurable one. Persistent interactions are required to represent communication channels over which multiple interactions are conducted, such as an event channel. It would be enough to define persistence to be a property of every outgoing WSDL operation, taking two possible values, which would distinguish persistent connections (event channels) and transient ones (current single invocation or connection). 3.2.3

Operation Triggering

The workflow model is used by WSFL for the definition of business processes as service compositions. This model relies on two central concepts (see [18]): activities, representing units of work executed by service components on behalf of the flow, and control links, representing the transfer of control between activities. The key behavior in the model is the triggering of an activity execution by the set of control links converging on that activity. Traditionally, a flow model relies on a central workflow engine to provide run-time support for the execution of this model. Here we describe an extension to the event notification mechanism, the trigger model, which makes it possible to orchestrate flow dynamics in a distributed fashion, that is, without a central run-time flow engine. In the trigger composition model, a component can act as both a source and a concentrator of messages (control events). Sources are not different from regular event sources. Concentrators provide the dual behavior of sources, by aggregating incoming messages at a single point, according to a (possibly configurable) pattern. The pattern would typically be a boolean expression relating the information from the messages received at the aggregation point; if the expression evaluates to true the result is the execution of an associated operation. A trigger interaction mechanism puts all the logic required to support flow dynamics at the component that provides each activity’s implementation. The trigger model can be generalized to support any kind of message with arbitrary semantics, and not only control flow messages. Triggers are a natural counterpart of event sources. However, there is no infrastructure available for supporting the trigger model. The most direct path to enable the model is probably the use of trigger containers, which would wrapper existing services with the additional trigger functionality.

4

Conclusion

In this position paper we have presented an introduction to the Web services distributed computing platform that is currently being defined. We described the component model underlying the Web services platform and identified a few areas where a stronger component model could greatly improve the power of the platform. We believe that Web services presents an immense opportunity for the component-oriented programming community: It offers the promise of a widely distributed component platform upon which higher level component orientation issues can be addressed.

References [1] World Wide Web Consortium, http://www.w3.org/2001/01/WSWS.

“Workshop

on

Web

Services”,

April

2001.

[2] D.F. Ferguson, “Web Services Architecture: Direction and Position Paper”, April 2001. Available at http://www.w3.org/2001/03/WSWS-popa/paper44. [3] IBM Corporation and Microsoft Corporation, “Web Services Framework”, April 2001. Available at http://www.w3.org/2001/03/WSWS-popa/paper51 . 5

[4] The Business Process Management Initiative, http://www.bpmi.org . [5] Satish Thatte, “XLANG. Web Services for BUsiness Process Design”, May 2001. Available at http://www.gotdotnet.com/team/xml wsspecs/default.aspx [6] 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 . [7] World Wide Web Consortium, XML Protocol Activity: http://www.w3.org/2000/xp/. [8] 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 . [9] IBM Corporation, “Web Services Flow Language (WSFL 1.0)”, May 2001. Available at http://www4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf . [10] UDDI Project, “UDDI Executive White Paper”, September 2000. Available at http://www.uddi.org . [11] UDDI Project, “UDDI Technical White Paper”, September 2000. Available at http://www.uddi.org . [12] F. Curbera, D. Ehnebuske, and D. Rogers, “Using WSDL in a UDDI Registry 1.02”, UDDI Working Draft Best Practices Document, February 2001. Available at http://www.uddi.org/bestpractices.html . [13] World Wide Web Consortium, “XML Schema Part 1: Structures”, W3C Recommendation, May 2001 Available at http://www.w3.org/TR/xmlschema-1 . [14] XAML - Transaction Authority Markup Language http://www.xaml.org . [15] Tibco Inc., “TIB/Rendezvous http://www.rv.tibco.com/whitepaper.html .

White

Paper”,

1999.

Available

at

[16] S. Weerawarana, F. Curbera, M.J. Duftler, D.A. Epstein, J. Kesselman, “Bean Markup Language: A Composition Language for JavaBeans Components”, Proc. 6th USENIX Conference on Object-Oriented Technologies and Systems, Jan. 2001. [17] F. Curbera, S. Weerawarana, M.J. Duftler, “On Component Composition Languages”, Proc. 5th Intl. Workshop on Component-Oriented Programming, May 2000. [18] F. Leymann, D. Roller, Production Workflow: Concepts and Techniques, Prentice Hall, 1999.

6