Conversation Definitions: defining interfaces of web services
Kannan Govindarajan, Alan Karp, Harumi Kuno, Dorothea Beringer, Arindam Banerji
Hewlett Packard Company
10450 Ridgeview Court MS 49EL-FR
Cupertino, CA 95014
In this position paper, we advocate a novel methodology for defining interfaces of web services. This novel methodology is motivated by the realization that web-services have unique characteristics not addressed by traditional methods of defining interfaces. In particular, our methodology addresses the fact that web-services are characterized by loose coupling amongst the participating entities, as well as a message oriented interaction model. We identify various characteristics of a desirable solution.
Web services, or e-services are applications that interact over the open internet through the use of standard protocols. In order for web services in one enterprise to interact with web services in other enterprises, we must establish technical conventions for standardizing interactions with web services. These technical conventions range from the messaging formats to interaction definitions, to properties of the interactions such as security, transactionality, etc.
Traditional distributed object models use the concept of interfaces to model interactions. This is a useful technique because the language in which an interface is defined can be completely independent of any language used to implement that interface. However, most traditional distributed object infrastructures were designed for distributed systems whose deployments were limited to within a single enterprise. They are thus suited to deploying services across organizational boundaries due to the following inherent characteristics of the inter-enterprise web services:
Web services are loosely coupled: Changes to a web service should not require re-installation of software components by the users of the web service.
Web services require dynamic binding: Typically, application designers bind software components to one another at development time. Web services, on the other hand, are likely to be implemented and provided by different service providers. In addition, we must enable easy changes to the services we are using, easy discovery of new services, of new capabilities of existing services, and of new binding or location information of services.
Web services communication is based on a Document Exchange Model: Traditional component frameworks support a network-object model of interaction in which objects of strictly defined types are transferred between components using a request-response interaction pattern. Cross-organizational business interactions do not fit this framework well for two reasons. The interfaces of services may need to be changed in ways that cannot be captured by simple extensions. This precludes the use of object inheritance to support the inter-operability in presence of change. Secondly, interactions can be long lived. Therefore, asynchronous exchange of XML documents is better suited for cross-organizational business transactions.
Web services in different enterprises are likely to use different semantics. The interpretation of the data communicated among enterprises is different for each enterprise. For instance, the address field of a purchase order may have different significance for the parties. If a uniform object model is used, the semantics of data often tends to be similar or homogeneous contributing to tighter coupling.
Web services in different enterprises require a distributed model of security. Security responsibilities are split amongst the enterprises. Each enterprise manages its end of the security infrastructure independently.
Web services from different enterprises may be built using heterogeneous technology stacks. Each enterprise decides on the computing infrastructure independently taking into consideration many factors.
Web service interactions must be able to traverse corporate firewalls. Traditional distributed systems are tuned for applications that are deployed within the enterprise; Web services may be deployed from behind Firewalls.
It is our position that in the web-services world, there needs to be a clear distinction between the public interface supported by a service and its private process that implements the public interface. This distinction enables flexible and dynamic inter-operability between Web services; for example, a service implementor can re-implement a service as long as it still supports the public interface. We base the definition of these public interfaces on the document exchange model, meaning that service interaction points are defined in terms of the documents that are exchanged with the service rather than method signature definitions.
In addition to defining service interaction points, an enterprise deploying a web service also needs to specify the valid sequences of message exchanges (interactions) that the service supports. For instance, RosettaNet PIPs define the interaction sequences that are specific to supply-chain like interactions amongst enterprises. However, RosettaNet does not support loosely coupled web services, and thus does not provide a generic mechanism for defining new interactions among services running in different enterprises. We identify that a generic, open ability to define the valid interaction sequences as part of the interface definition is necessary for enabling loose coupling amongst web-services. Such definitions would enable clients to determine dynamically the relative order in which the documents are to be exchanged to perform any unit of work with the service.
The Conversation Definition Language (CDL) is an XML schema for defining valid sequences of documents exchanged between web services. Conversations have been studied in the agent community, and provide a means of defining the interfaces of services in terms of the interactions that the service supports. The interaction definitions are at a level that is higher than the transport layer and allow high-level modeling of the interfaces that the service supports. For example, the details of the transport binding are the responsibility of a separate layer in our architecture and can use existing technologies such as WSDL  for this purpose. Essentially, CDL allows web services to model their public process in a lightweight manner. CDL also provides an extensional view of a web service in terms of the messages that are exchanged with it.
Conversation based interface definition enables loose coupling among web services by defining an asynchronous document exchange model, as opposed to a remote procedure call model, for interaction amongst web services. Web services can inter-operate with each other as long as they conform to the conversation definitions exposed by them irrespective of the implementation stack that supports the conversation definitions. CDL as described in this paper suffices to model interactions amongst two web services. We plan to extend it to support secure, mediated, and multi-party conversations.
The notion of interactions amongst services can be expressed in many ways. One way is to express the concept of the shared interaction that abstracts away the entities in the interactions. CDL, however, specifies the view of the interaction from the viewpoint of the entities that are interacting. This means that a programmer who is programming a service can define the CDL for his service just as programmers today define the interface for the code that they write. In many vertical industries, there may be standard ways of defining conversations that can be found at an internet-wide registry. In this case, the programmer can select the conversation that she wants her service to support. This allows the clients of the service to interact with the service in a well-defined, though loosely-coupled, manner.
The design of CDL separates the mapping of external interactions between services from mappings to internal legacy business logic, which most service implementations will typically encapsulate. This latter mapping is described through business logic mapping layer documents that are outside the scope of this paper. Furthermore, the conversations that a service supports can become one of the pieces of information that is required at service registration, just as tModels for services are required when services are registered at UDDI registries today. Furthermore, the CDL definitions themselves can be listed in registries so that clients can discover the CDL definitions required to interact with services that support the CDL.
One can extend CDL in a variety of ways in order to capture various kinds of semantics. Some of the possible extensions include:
4. Relationship to existing standards
The conversation definition language defines the notion of interfaces and protocols of web services. Here we use the word "protocols" to denote the ordering of invocations. It presents an abstraction that is above the format of the XML message on the wire that other standards such as SOAP define.
For example, an interaction amongst the services could be a SOAP message, where the body of the SOAP message contains the document that represents the request from the client to the service. CDL defines conversations that take place on top of a messaging layer. However, CDL is independent of any particular messaging protocol.
The current version of WSDL (1.0) is an XML-based format that describes the interfaces and protocol bindings of web service functional endpoints. WSDL also defines the payload that is exchanged using a specific messaging protocol; SOAP is one such possible messaging protocol. However, neither UDDI nor WSDL currently addresses the problem of how a service can specify the sequences of legal message exchanges (interactions) that it supports. Like WSDL, CDL does not expose the service implementation. Both CDL and WSDL provide a language to define interactions amongst the entities. Unlike WSDL, CDL relies on a separate specification to define method dispatch, and relegates the binding to various message protocols to a lower layer in the stack.
Note that conversation definitions are not workflow definitions. The key difference between a conversation and a workflow is that a conversation models the externally visible interaction model of the web service. A workflow is one way to actually implement the web service.
 Web Services Definition Language (WSDL) available at http://msdn.microsoft.com/xml/general/wsdl.asp