Web Services Conversation Language
From Wikipedia, the free encyclopedia
The Web Service Conversation Language (WSCL) proposal defines the overall input and output message sequences for one web service using a finite state automaton FSA over the alphabet of message types.
[edit] External links
Web Services Conversation Language (WSCL) 1.0 W3C Note 14 March 2002
This version:
http://www.w3.org/TR/2002/NOTE-wscl10-20020314/
Latest version:
http://www.w3.org/TR/wscl10/
Previous version:
n/a
Authors (alphabetically):
Hewlett-Packard Company: Arindam Banerji Claudio Bartolini Dorothea Beringer Venkatesh Chopella Kannan Govindarajan Alan Karp Harumi Kuno Mike Lemon Gregory Pogossiants Shamik Sharma Scott Williams
Copyright © 2001-2002 Hewlett-Packard Company Abstract
This document specifies the Web Services Conversation Language. WSCL allows the abstract interfaces of Web services, i.e. the business level conversations or public processes supported by a Web service, to be defined. WSCL specifies the XML documents being exchanged, and the allowed sequencing of these document exchanges. WSCL conversation definitions are themselves XML documents and can therefore be interpreted by Web services infrastructures and development tools. WSCL may be used in conjunction with other service description languages like WSDL; for example, to provide protocol binding information for abstract interfaces, or to specify the abstract interfaces supported by a concrete service. Status of this Document
This document is a submission to the World Wide Web Consortium (see Submission Request, W3C Staff Comment). This document is a Note made available by W3C for discussion only. This indicates no endorsement of its content, or that W3C has had any editorial control in its preparation, or that W3C has, is, or will be allocating any resources to the issues addressed by the Note.
This Note proposes a simple conversation language standard that can be used for various Web-service protocols and frameworks. It focuses on modeling the sequencing of the interactions or operations of one interface. It fills the gap between mere interface definition languages that do not specify any choreography and more complex process or flow languages that describe complex global multi-party conversations and processes.
Feedback and comments are welcome and may be sent to dorothea_beringer@hp.com.
A list of current W3C technical documents can be found at http://www.w3.org/TR/. Table of Contents
* 1. Introduction * 2. Elements of a WSCL Specification * 3. Mapping to Protocol Bindings and Error Handling * 4. Using WSCL and WSDL to Describe Web Services * 5. Extending WSCL * 6. References * Appendix A: WSCL Schema Definition * Appendix B: Example WSCL Specification
1. Introduction
Electronic commerce is moving toward a vision in which corporate enterprises use Web services to interact with each other based on well-defined standards in a dynamic and loosely coupled way. To use Web services effectively, the interacting parties need to know and agree on the following:
* Business payload – Both parties need to know which information to exchange. * Protocol – Both parties need to know how to exchange business payload. They must agree on the message structure, message header information, mapping to underlying transfer protocols, and overall framework for communication and error handling. Protocols for Web services include SOAP-RPC [1], asynchronous SOAP with specific profiles, RNIF [2], and ebXML TR&P [3]. * Service location – To interact with a specific service, both parties need to know which protocols the service supports, which payload it exchanges, and its location; for example, an HTTP URL.
In the context of Web services, business payload is mostly expressed in XML. Therefore, one possible and often used way to define the business payload is to use XML schemas. Yet, defining which XML documents are expected by a Web service or are sent back as a response is not enough. It is also necessary to define the order in which these documents need to be exchanged; in other words, a business level conversation needs to be specified. By specifying the conversations supported by a Web service — by defining the documents to be exchanged and the order in which they may be exchanged — the external visible behavior of a Web service, its abstract interface, is defined. Conversations focus on the public processes in which the participants of a Web service engage. Conversations may not define the application logic or private process, i.e. the internal implementation and mapping to back-end applications within the various enterprises that are interacting.
Figure 1 shows that a Web service specification consists of three main parts: (1) abstract interfaces, conversations; (2) communication protocols; and (3) concrete services (address, conversations provided, protocol bindings required). [1] Figure 1. Basic Concepts for Specifying Web Services
By clearly distinguishing between the concepts of abstract interface, communication protocol, and concrete service, we enable the loose coupling desired for Web services. All three aspects can be specified independent of each other. Protocols can be specified once for very different Web services. The abstract interfaces defining the business-level conversations can be specified once for a specific industry, bound to different protocols, and used by any number of services with completely different implementations. A single concrete service can implement several abstract interfaces, which can also be implemented by other concrete services hosted on other service providers. This enables more flexibility and ease in choosing and changing service providers and, finally, allows us to move toward a model of discovering and using e-services dynamically.
There are various possible ways to describe business level conversations. The conversation definition language WSCL has chosen a formal approach, which is based on XML. WSCL is defined by an XML schema. WSCL 1.0 is a simple conversation definition language. The purpose of WSCL 1.0 is to provide and define the minimal set of concepts necessary to specify conversations. The expectation is that WSCL will be extended for more complex Web services frameworks; for example, multi-party conversations, quality of service attributes, transactions, or composition of conversations.
A key advantage of WSCL and other formal specification languages is that they pave the way for the creation of service frameworks that will enable service implementers to offload the responsibility for conversation-related tasks to infrastructure. A service developer, for example, could create WSCL specifications documenting their service’s abstract interface and make the documentation available to potential users. A software developer could then use WSCL-compliant Web services servers and tools that provide document type validation, conversation tracking, and message dispatching to the application logic, and other such functionality. Ideally, software developers that create and use Web services will be supported by tools that allow them to easily and quickly map the interactions outlined in the conversation definition to any existing applications and back-end logic, while cleanly separating the conversational logic from the application logic. Without any formal definition of the conversations, such tool support would not be possible.
Conversation definitions may be specified directly by service providers or by industry-specific standards groups in the same way that, for example, RosettaNet PIPs are specified by RosettaNet and used by participating enterprises. Unlike the specification guideline for RosettaNet PIPs, WSCL provides a formal language for specifying conversations. Its basic set of concepts is targeted at less complex frameworks. A service provider can either provide conversation definitions directly to the users of the service — for example, as part of a trading partner agreement — or register them as UDDI tModels in a UDDI registry [4], where they may also be referred to by businessService entries and be available to anyone having access to the registry. For details on registering WSCL specifications, see [6].
Figure 2 depicts a UML diagram of a simple purchase conversation definition from the perspective of the seller. A service that supports this conversation definition expects a conversation to begin with the receipt of a LoginRQ or a RegistrationRQ document. Once the service has received one of these documents, it answers with a ValidLoginRS, an InvalidLoginRS, or a RegistrationRS, depending on the type and content of the message received. The WSCL specification for this conversation is given in Appendix B. Although this conversation is defined from the perspective of the seller, it can be used to determine the appropriate message types and sequences for both the seller and the buyer. The buyer simply derives his conversation definition by inverting the direction of the messages.
Figure 2 shows an example of a conversation in the form of a UML activity diagram. [2] Figure 2. UML Activity Diagram of a Conversation Definition 2. Elements of a WSCL Specification
The complete schema for WSCL is listed in Appendix A. There are four main elements to a WSCL specification, as depicted in the UML model shown in Figure 3.
* Document type descriptions specify the types (schemas) of XML documents the service can accept and transmit in the course of a conversation. The schemas of the documents exchanged are not specified as part of the WSCL specification document; the actual document schemas are separate XML documents referenced by their URL in the XMLDocumentType elements of the conversation specification. * Interactions model the actions of the conversation as document exchanges between two participants. WSCL supports five types of interactions: Send (the service sends out an outbound document); Receive (the service receives an inbound document); SendReceive (the service sends out an outbound document and then expects to receive an inbound document in reply); ReceiveSend (the service receives an inbound document and then sends out an outbound document); Empty does not contain any documents exchanged, but is used only for modeling the start and end of a conversation. * Transitions specify the ordering relationships between interactions. A transition specifies a source interaction, a destination interaction, and, optionally, a document type of the source interaction as an additional condition for the transition. * Conversations list all the interactions and transitions that make up the conversation. A conversation contains additional information about the conversation, including the conversation’s name and the interaction the conversation can start with and end with. Conversations can be thought of as interfaces or public processes supported by a service. They differ from interfaces as defined by CORBA IDE or Java interfaces because they also specify the possible ordering of operations, i.e. the possible sequences in which documents may be exchanged.
Figure 3 shows a UML diagram illustrating the relationships between the various elements modeled in a WSCL conversation specification. [3] Figure 3. UML Class Diagram of WSCL
A conversation definition defines the conversation from the perspective of one of the participants. In most cases, a conversation published in a service directory is the one defined from the perspective of the listener; the first interaction to happen is a Receive or ReceiveSend interaction. An initiator can derive its conversation definition from the conversation definition of the listener simply by converting Receive and ReceiveSend interactions into Send and SendReceive interactions, and vice versa. Two participants can successfully interact if the conversation definitions they use are duals of each other. 2.1 Document Types
The interaction between service-consumer and service-provider is achieved through XML document exchange. A conversation definition language must be able to define all the input and output document types. The attribute hrefSchema of the elements InboundXMLDocument and OutboundXMLDocument refers to the schema to which the document corresponds. WSCL supports only XML schema specifications of payload because schemas seem to be the prevailing means of describing data exchanged on the Internet. Existing DTD specifications can be translated easily into XML schemas. WSCL, a very simple and basic conversation definition language, does not directly support the specification of non-XML payload-like binary attachments. Yet the attribute hrefSchema is optional, which allows the schema definition to be omitted in case of binary payload.
InboundXMLDocument and OutboundXMLDocument also serve to declare an ID for the document that can be used within the rest of the conversation definition. In the following example, the definition defines an input document that conforms to a purchase order schema defined in PurchaseOrderRQ.xsd.
<InboundXMLDocument
hrefSchema="http://foo.org/PurchaseOrderRQ.xsd" id="PurchaseOrderRQ"
</InboundXMLDocument>
In a WSCL conversation definition, the document types are declared within the interaction definitions as either an InboundXMLDocument or OutboundXMLDocument, depending on whether the document is expected as input or is produced as output in the interaction.
WSCL only references the schemas for the business payload of any messages. Of course, the business documents will be complemented by XML message header information for the exchange over the Internet. These message header schemas, however, are defined by the protocol binding and should not appear in the business documents referenced by the document types. 2.2 Interactions
An interaction is an exchange of one or two documents between a service and its client. WSCL only models business level interactions. It only specifies which business level documents are exchanged and does not model how this exchange is carried out by lower-level messaging protocols. The actual messaging may involve more than one message per business document exchange; for example, an HTTP-POST as well as an HTTP-RESPONSE per business document. The messaging logic may even introduce additional transport level acknowledge messages; for example, to achieve reliable messaging.
The following interaction types are currently defined in WSCL: Receive and Send (one-way interactions), ReceiveSend and SendReceive (two-way interactions), and Empty. 2.2.1. One-Way Interactions
One-way interactions represent a single one-way message being sent or received by a participant. There are two sub-types of one-way interactions: Receive and Send. Send represents a document sent out by a participant. Receive represents a document received by a participant.
The following example represents a Receive interaction that receives a login document:
<Interaction interactionType="Receive" id="LoginRegInput">
<InboundXMLDocument id="LoginRequestData"
hrefSchema=http://foo.org/LoginRequestData.xsd />
</Interaction>
A Receive interaction must contain one InboundXMLDocument element. A Send interaction must contain one OutboundXMLDocument element. 2.2.2. Two-Way Interactions
Two-way interactions can be either SendReceive or ReceiveSend, depending on whether the participant sends out a message for which it gets a response (SendReceive) or responds to a request that it receives (ReceiveSend).
SendReceive: Each SendReceive interaction is the logical unit of sending a request and then receiving a response. The interaction is not complete until the response has been exchanged.
<Interaction interactionType="SendReceive" id="Payment">
<OutboundXMLDocument id="Invoice"
hrefSchema="http://foo.org/InvoiceRS.xsd">
</OutboundXMLDocument>
<InboundXMLDocument id="Payment"
hrefSchema="http://foo.org/Payment.xsd">
</InboundXMLDocument>
</Interaction>
ReceiveSend: Each ReceiveSend interaction is the logical unit of receiving a request and then returning a response. The interaction is not complete until the response has been sent.
<Interaction interactionType="ReceiveSend" id="Quotation">
<InboundXMLDocument id="PurchaseOrderRQ"
hrefSchema="http://foo.org/PurchaseOrderRQ.xsd">
</InboundXMLDocument>
<OutboundXMLDocument id="InvoiceRS"
hrefSchema="http://foo.org/InvoiceRS.xsd">
</OutboundXMLDocument>
</Interaction>
A ReceiveSend interaction can specify more than one OutboundXMLDocument. This ability allows the modeling of the type of cases in which there are multiple types of response messages that a service might return in response to a specific request. Having additional possible responses is mainly used for error messages. If a ReceiveSend interaction specifies more than one outbound document type, only one of them is being exchanged at runtime. For modeling the cases where a request message initiates several response messages, several interactions have to be used.
The following example shows a Purchase interaction that specifies two additional outbound document types for the cases of invalid payment and out of stock.
<Interaction interactionType="ReceiveSend" id="Purchase" >
<InboundXMLDocument hrefSchema="http://conv123.org/PurchaseOrderRQ.xsd" id="PurchaseOrderRQ" /> <OutboundXMLDocument id="PurchaseOrderAcceptedRS" hrefSchema="http://conv123.org/PurchaseOrderAcceptedRS.xsd" /> <OutboundXMLDocument id="InvalidPaymentRS" hrefSchema="http://conv123.org/InvalidPaymentRS.xsd" /> <OutboundXMLDocument id="OutOfStockRS" hrefSchema="http://conv123.org/OutOfStockRS.xsd" />
</Interaction>
Similarly, a SendReceive interaction can specify more than one InboundXMLDocument.
On the abstraction level of WSCL, SendReceive and ReceiveSend interactions are simply shortcuts for modeling several Send and Receive interactions. If we consider possible bindings of interactions to transport protocols, having SendReceive and ReceiveSend interactions makes it easier to specify bindings to synchronous protocols (see Mapping to Protocol Bindings and Error Handling), although the definition of such bindings is outside the scope of WSCL. Additional reasons for having SendReceive and ReceiveSend interactions come into play when considering extended conversation definition languages where QoS requirements are added to the interaction specifications. 2.3. Transitions
A conversation can proceed from one interaction to another as allowed by the permissible sequencing defined in the transition elements.
<Transition>
<SourceInteraction href="Invoice"/>
<DestinationInteraction href="Receipt"/>
<SourceInteractionCondition href="InvoiceRS"/>
</Transition>
SourceInteraction references an interaction that can precede the DestinationInteraction when the conversation is executed. Similarly, DestinationInteraction references one of the interactions that can follow the SourceInteraction when the conversation is executed. Together, all transitions specify all possible sequences of the interactions.
SourceInteractionCondition is an additional constraint on the transition. It is needed when the SourceInteraction specifies more than one possible document to be exchanged and the type of document exchanged has an influence on the possible next interactions. SourceInteractionCondition references an OutboundXMLDocument of the SourceInteraction when it is a ReceiveSend interaction, or an InboundXMLDocument from the SourceInteraction when it is a SendReceive interaction. If no SourceInteractionCondition is listed, DestinationInteraction can be triggered independent of the types of documents exchanged in SourceInteraction. There is one important limitation to specifying transitions without SourceInteractionCondition: If there exists a transition from SourceInteraction A to DestinationInteraction B that specifies a SourceInteractionCondition, then it is not possible to also specify a transition from SourceInteraction A to DestinationInteraction B without a SourceInteractionCondition.
Transitions define all the permissible orders of interactions but do not specify under which condition which permissible sequence is chosen. This is determined by the internal application logic of both participants, often based on back-end information; for example, in the example in Appendix B, it is the buyer who decides whether the CatalogInquiry interaction is followed by a Quote interaction or a Purchase interaction, by sending either a PurchaseRQ or QuoteRQ document. A PurchaseRQ document triggers the Purchase interaction; a QuoteRQ document triggers the Quote interaction.
The transitions defined in a conversation can be represented by a directed graph or a UML activity diagram. A UML activity diagram represents interactions by action states. These action states model the inbound and outbound document exchanges as actions. The first of these document exchanges also triggers the transition to the action state itself and, therefore, could be drawn as an event on the transition. SourceInteractionConditions appear as additional conditions on the transitions. In Figure 2, after the Login interaction, the client can initiate another Login interaction, a Registration interaction, a CatalogInquiry interaction, a Quote interaction, or a purchase interaction by sending a RegistrationRQ, LoginRQ, CatalogRQ, QuoteRQ, or PurchaseRQ document. The latter interactions are only allowed if the Login interaction ended with a ValidLoginRS document. The Registration and Login interactions are only allowed in case of an InvalidLoginRS. 2.4. Initial and Final Interactions
Part of defining the possible ordering of interactions is the specification of the first and last interactions of a conversation. In WSCL, this is done by the attributes initialInteraction and finalInteraction of the Conversation element. The attribute initialInteraction references the ID of the first interaction to be executed in the conversation. The attribute finalInteraction references the ID of the last interaction to be executed.
<Conversation name="ExampleConversation"
initialInteraction = "Login" finalInteraction = "Purchase" >
Of course, there might be more than one interaction with which the conversation can start or end. In the example shown in Figure 2 and Appendix B, the conversation can end after a CatalogInquiry interaction, a Quote interaction, a Purchase interaction (in case the purchase cannot go through), or the Shipping interaction. In addition, the conversation can start with either a Registration or a Login interaction, depending on whether or not the client is already a registered user. To specify several possible start and end interactions, interactions of type Empty are used. In Figure 2, an empty interaction Start is added, plus transitions from Start to Registration and Login. The attribute initialInteraction references this empty interaction Start. An empty interaction, End, is introduced with various transitions to it, and is referenced in the attribute finalInteraction.
An interactionType Empty is an interaction in which no documents are exchanged. Its specification does not contain the sub-elements InboundXMLDocument and OutboundXMLDocument. Currently, the only situation in which empty interactions can be used in a conversation definition is when several possible final or initial interactions need to be modeled. The conversation example in Appendix B shows empty interactions. 2.5 Conversation
Each conversation definition has the root element Conversation.
<?xml version="1.0" encoding="UTF-8"?> <Conversation name="StoreFrontServiceConversation" version="1.01"
xmlns="http://www.w3.org/2002/02/wscl10"
initialInteraction="Start" finalInteraction="End"
targetNamespace="http://example.com/conversations/StoreFront101"
hrefSchema="http://example.com/schema_files/StoreFront101.wscl"
description="Conversation for a Store Front Service" >
<ConversationInteractions>
list of all the interactions
</ConversationInteractions>
<ConversationTransitions>
list of all the transitions
</ConversationTransitions>
</Conversation>
The Conversation element contains the following two sub-elements:
* ConversationInteractions lists all Interaction elements. * ConversationTransitions lists all Transition elements.
The Conversation element contains the following attributes:
* initialInteraction and finalInteraction reference the initial and final interactions of the conversation. * name is the name of a conversation. The name is the shared piece of information needed by both parties so they realize the same conversation type in their service implementation. This name would also appear in the header elements of the actual messages exchanged. WSCL does not specify how to name conversations. Conversation names do not have to be URIs. If a conversation is published in a UDDI directory, the conversation name could be a tModel key. * version (optional) is the version of the conversation. If no version number is given, the name of the conversation must be unique. * targetNamespace (optional) is the namespace of this conversation as it should be used when elements of this conversation are referenced in other XML documents. * hrefSchema (optional) is the URL of the file containing this conversation definition. * description (optional) is the textual description of the conversation.
2.6 Well-Formed Conversation Definitions
For a conversation definition to be well-formed, it has to adhere to the conversation schema in Appendix A and fulfill the following restrictions:
* All interactions have to be reachable from the initial interaction. The final interaction has to be reachable from every other interaction. * If a transition exists from interaction A to interaction B that does not specify any SourceInteractionCondition, then there may not be another transition from interaction A to interaction B that specifies a SourceInteractionCondition. * The final interaction and the transitions to the final interaction need to be defined in such a way that it is clear for each participant when a conversation is finished. The example in Figure 2 contains a Receive interaction Logout. The only purpose of this interaction is to signal the listener that the initiator is no longer interested in continuing the conversation, and that the listener does not have to wait for a PurchaseRQ or QuoteRQ that may not be sent.
Conversations fulfilling these conditions are considered well-formed. Only well-formed conversations should be published and used.
For conversation executions to be deterministic, transitions should be unambiguous at all times. This can be achieved in two different ways, depending on the service framework and interaction protocol used.
* The protocol requires that the message headers either contain the ID of the inbound or outbound document as specified in the WSCL description of the service, or uniquely identify the interaction as well as the document concerned in some other ways. No additional restrictions concerning the conversation specifications are necessary. IDs of inbound and outbound documents are unique within a conversation definition; therefore, the transition and target interaction can be unambiguously identified at runtime. * The messages exchanged do not carry any meta information about the conversation, interactions, and documents exchanged. The inbound or outbound documents that trigger the transition from the same source interaction with the same source interaction conditions to different destination interactions must have different schemas that differ in their top elements. The transition and target interaction can be unambiguously identified based on the business payload of the message.
3. Mapping to Protocol Bindings and Error Handling
WSCL specifies the business payload being exchanged between two parties and the order of these document exchanges. WSCL does not specify the message structure in which the payload is contained or the header fields of these messages. We can assume that the header fields indicate both parties involved in the message exchange, plus the name of the conversation and an ID referencing the ongoing conversation instance. All these details are defined by the communication protocol used.
When executing a conversation, we can expect two levels of errors: those concerning the document content and those concerning the specified conversations. Errors of the first type occur if a participant receives the correct type of document with the correct document structure but invalid values; for example, invalid user name and password. Such errors need to be handled by the business logic, and the conversation definition and document schemas have to allow their communication; for example, a document type for invalid login, or invalid login fields in a general login response document type.
Errors concerning the document types used, the order of interactions, or the conversations to be used need to be handled by the communication protocol. The protocol might have predefined error messages that signal "unexpected document type" or "unknown conversation." The protocol also has to define whether a conversation instance continues or terminates after the exchange of an invalid document type, or what happens if one of the participants does not react for a long time.
WSCL does not specify how interactions are bound to a specific communication protocol because protocol bindings are outside the scope of WSCL. There are two different approaches for providing binding information.
* The protocol binding is determined by a specific Web services framework used and is applicable to all services and all messages exchanged. * A special protocol binding description language is used to describe the protocol bindings for the individual interactions or conversations. An example of such a protocol binding description language is the protocol binding part of WSDL [5].
4. Using WSCL and WSDL to Describe Web Services
There are three main aspects of Web services (see Figure 1):
* Abstract interfaces (public processes, business models): the messages or documents (business payload) being exchanged and the order in which they are exchanged (choreography of the messages) * Protocol bindings: the protocols used for exchanging the documents * Services: the concrete service implementing a set of abstract interfaces and protocol bindings, and its location
The following listing shows how these three aspects are covered by WSDL and WSCL:
WSDL: WSCL:
Abstract Interfaces choreography out of scope Transition
messages Operation Interaction
Protocol Bindings Binding out of scope Concrete Services Service out of scope
It is evident that the only overlap between WSDL and WSCL exists in the specification of the documents being exchanged.
Where WSDL and WSCL overlap, we can map the different terminology used as follows: WSDL WSCL Port Type Conversation Operation: - One-way - Request-response - Solicit-response - Notification Interaction*: - Receive - ReceiveSend - SendReceive - Send Input InboundXMLDocument Output, Fault OutboundXMLDocument Names of Operation, Input, Output, Fault ID of Interaction, InboundXMLDocument, OutboundXMLDocument Message URL of XML schema (WSCL delegates the specification of the payload entirely to an external XML schema, whereas WSDL directly uses XML data types)
- Empty does not appear in this list because it is used only for modeling the start and end state of conversations, and does not contain any documents exchanged.
There are three approaches for combining WSDL and WSCL descriptions of a Web service:
* Adding protocol bindings in WSDL to a conversation described in WSCL: If the abstract interface is already completely described by a WSCL document, we can use the WSDL Binding elements to describe the protocol binding; for example:
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="MyStoreFrontService"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace=...
xmlns:conv="http://example.com/Conversations/StoreFront.cdl" >
<binding name="StoreFrontServiceConversationBinding"
type="conv:StoreFrontServiceConversation">
<soap:binding style="document"/>
<operation name="conv:Login">
<soap:operation soapAction="Login">
</operation>
<operation name="conv:Registration">
<soap:operation soapAction="Registration">
</operation>
... for all other interactions
</binding>
<service name="MyStoreFrontService">
<port name="MyStoreFrontServiceAccessPoint"
binding="StoreFrontServiceConversationBinding">
<soap:Address location="http://mystore.com/storefront" />
</port>
</service>
</definitions>
In the example, the attribute type in the element binding refers to the name of the conversation in the WSCL document describing this conversation. The names of the operations refer to the IDs of the interactions.
* Adding choreography to a WSDL port type description: If a port type is already described by a WSDL document, we can describe the choreography in an additional WSCL document that only contains transition elements. The sub-elements SourceInteraction and DestinationInteraction refer to the names of operations from the WSDL document. The sub-element SourceInteractionCondition refers to an output or fault message of the operation. WSCL uses attributes of type HREF to refer to other elements. Therefore, to refer to operations from a WSDL document, the WSCL schema needs to be slightly adapted to also accept values of type QNAME.
* Providing a full WSDL and WSCL description for the same port type/conversation: We can also express which documents get exchanged by both a WSDL port type and a WSCL conversation with the conversation also describing the choreography used. The following example describes the interaction "Login" from the WSCL example in Appendix B as a WSDL operation:
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="MyStoreFrontService"
xmlns="http://schemas.xmlsoap.org/wsdl/"
targetNamespace=...
xmlns:xsd1="http://example.com/types/LoginRQ.xsd"
xmlns:xsd2="http://example.com/types/ValidLoginRS.xsd"
xmlns:xsd3="http://example.com/types/InvalidLoginRS.xsd" >
<message name="LoginRequestDocument">
<part name="body" element="xsd1:LoginRQElement" />
</message>
<message name="ValidLoginDocument">
<part name="body" element="xsd2:ValidLoginRSElement" />
</message>
<message name="InvalidLoginDocument">
<part name="body" element="xsd3:InvalidLoginRSElement" />
</message>
<portType name="StoreFrontServiceConversation" >
<operation name="Login">
<input name="LoginRQ" message="LoginRequestDocument"/>
<output name="ValidLoginRQ" message="ValidLoginDocument"/>
<fault name="InvalidLoginRQ" message="InvalidLoginDocument"/>
</operation>
</portType>
</definitions>
5. Extending WSCL
The WSCL specification contains the smallest possible set of elements and attributes to describe conversations. This set is sufficient to model many of the conversations needed for Web services. However, there are more complex B2B interactions that need additional capabilities from a conversation definition language. Such additional requirements include the following examples:
* Defining document types that have non-XML content; for example, binary attachments * Explicit description of roles of participants * Multi-party conversations with three or more participants or roles * Expressing timeouts and other quality of service characteristics of individual interactions * Expressing more complex SourceInteractionConditions; for example, listing several documents, excluding documents, or even referencing the content of documents * Events, i.e. interactions that can occur at any time within a conversation instance * Recursive conversations, aggregating conversations into larger conversations * Sub-typing and extending existing conversation definitions
6. References
[1] Simple Object Access Protocol (SOAP) 1.1, W3C Note, May 8, 2000, "http://www.w3c.org/TR/2000/NOTE-SOAP-200000508/"
[2] RosettaNet Implementation Framework RNIF, Version 2.0, RosettaNet Consortium, "http://www.rosettanet.org"
[3] Message Service Specification, ebXML Transport, Routing & Packaging, April 2001, EBXML, "http://www.ebxml.org"
[4] Ariba, International Business Machines Corporation, Microsoft Corporation, UDDI Technical White Paper, September 6, 2000, "http://www.uddi.org"
[5] Web Services Description Language (WSDL) 1.0, "http://msdn.microsoft.com/xml/general/wsdl.asp"
[6] Kuno, H., Lemon, M., Beringer, D., Using WSCL in a UDDI Registry: UDDI Best Practices Document. May 2001, "http://www.uddi.org" Appendix A: WSCL Schema Definition
The following shows a WSCL schema definition (note: a previous version of this specification was using the following namespace URI: http://www.e-speak.net/schema/WSCL).
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xsd:id="WSCL" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xsd:targetNamespace="http://www.w3.org/2002/02/wscl10" xsd:elementFormDefault="unqualified" xsd:attributeFormDefault="unqualified">
<xsd:element name="Conversation">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="ConversationInteractions"/>
<xsd:element ref="ConversationTransitions"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required"/>
<xsd:attribute name="version" type="xsd:string" use="optional"/>
<xsd:attribute name="description" type="xsd:string" use="optional"/>
<xsd:attribute name="targetNamespace" type="xsd:anyURI" use="optional"/>
<xsd:attribute name="hrefSchema" type="xsd:anyURI" use="optional"/>
<xsd:attribute name="initialInteraction" type="xsd:IDREF" use="required"/>
<xsd:attribute name="finalInteraction" type="xsd:IDREF" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="ConversationInteractions">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Interaction" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Interaction">
<xsd:complexType>
<xsd:choice minOccurs="0" maxOccurs="1">
<xsd:group ref="ReceiveSendDocumentGroup"/>
<xsd:group ref="SendReceiveDocumentGroup"/>
<xsd:group ref="ReceiveDocumentGroup"/>
<xsd:group ref="SendDocumentGroup"/>
</xsd:choice>
<xsd:attribute name="id" type="xsd:ID" use="required"/>
<xsd:attribute name="interactionType" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="SendReceive"/>
<xsd:enumeration value="ReceiveSend"/>
<xsd:enumeration value="Receive"/>
<xsd:enumeration value="Send"/>
<xsd:enumeration value="Empty"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:group name="ReceiveSendDocumentGroup">
<xsd:sequence>
<xsd:element ref="InboundXMLDocument" />
<xsd:element ref="OutboundXMLDocument" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="SendReceiveDocumentGroup">
<xsd:sequence>
<xsd:element ref="OutboundXMLDocument"/>
<xsd:element ref="InboundXMLDocument" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="ReceiveDocumentGroup">
<xsd:sequence>
<xsd:element ref="InboundXMLDocument"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="SendDocumentGroup">
<xsd:sequence>
<xsd:element ref="OutboundXMLDocument"/>
</xsd:sequence>
</xsd:group>
<xsd:element name="InboundXMLDocument" type="XMLDocumentType"/>
<xsd:element name="OutboundXMLDocument" type="XMLDocumentType"/>
<xsd:complexType name="XMLDocumentType"> <xsd:attribute name="id" type="xsd:ID" use="required"/> <xsd:attribute name="hrefSchema" type="xsd:anyURI" use="optional"/> </xsd:complexType>
<xsd:element name="ConversationTransitions">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Transition" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Transition">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="SourceInteraction" />
<xsd:element ref="DestinationInteraction" />
<xsd:element ref="SourceInteractionCondition" minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SourceInteraction">
<xsd:complexType>
<xsd:attribute name="href" type="xsd:IDREF" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="DestinationInteraction">
<xsd:complexType>
<xsd:attribute name="href" type="xsd:IDREF" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="SourceInteractionCondition">
<xsd:complexType>
<xsd:attribute name="href" type="xsd:IDREF" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Appendix B: Example WSCL Specification
The following XML document is a WSCL specification for the example conversation shown in Figure 2.
<?xml version="1.0" encoding="UTF-8"?> <Conversation name="StoreFrontServiceConversation"
xmlns="http://www.w3.org/2002/02/wscl10"
initialInteraction="Start" finalInteraction="End" >
<ConversationInteractions>
<Interaction interactionType="ReceiveSend" id="Login">
<InboundXMLDocument hrefSchema="http://conv123.org/LoginRQ.xsd"
id="LoginRQ"/>
<OutboundXMLDocument hrefSchema="http://conv123.org/ValidLoginRS.xsd"
id="ValidLoginRS"/>
<OutboundXMLDocument hrefSchema="http://conv123.org/InvalidLoginRS.xsd"
id="InvalidLoginRS" />
</Interaction>
<Interaction interactionType="ReceiveSend" id="Registration">
<InboundXMLDocument hrefSchema="http://conv123.org/RegistrationRQ.xsd"
id="RegistrationRQ"/>
<OutboundXMLDocument hrefSchema="http://conv123.org/RegistrationRS.xsd"
id="RegistrationRS"/>
</Interaction>
<Interaction interactionType="ReceiveSend" id="Logout">
<InboundXMLDocument hrefSchema="http://conv123.org/Logout.xsd"
id="LogoutMessage"/>
<OutboundXMLDocument hrefSchema="http://conv123.org/LogoutRS.xsd"
id="LogoutRS"/>
</Interaction>
<Interaction interactionType="ReceiveSend" id="CatalogInquiry" >
<InboundXMLDocument hrefSchema="http://conv123.org/CatalogRQ.xsd"
id="CatalogRQ"/>
<OutboundXMLDocument hrefSchema="http://conv123.org/CatalogRS.xsd"
id="CatalogRS" />
</Interaction>
<Interaction interactionType="ReceiveSend" id="Quote" >
<InboundXMLDocument hrefSchema="http://conv123.org/QuoteRQ.xsd"
id="QuoteRQ" />
<OutboundXMLDocument hrefSchema="http://conv123.org/QuoteRS.xsd"
id="QuoteRS" />
</Interaction>
<Interaction interactionType="ReceiveSend" id="Purchase" >
<InboundXMLDocument hrefSchema="http://conv123.org/PurchaseOrderRQ.xsd"
id="PurchaseOrderRQ" />
<OutboundXMLDocument id="PurchaseOrderAcceptedRS"
hrefSchema="http://conv123.org/PurchaseOrderAcceptedRS.xsd" />
<OutboundXMLDocument id="InvalidPaymentRS"
hrefSchema="http://conv123.org/InvalidPaymentRS.xsd" />
<OutboundXMLDocument id="OutOfStockRS"
hrefSchema="http://conv123.org/OutOfStockRS.xsd" />
</Interaction>
<Interaction interactionType="Send" id="Shipping" >
<OutboundXMLDocument id="ShippingInformation"
hrefSchema="http://conv123.org/ShippingInformation.xsd" />
</Interaction>
<Interaction interactionType="Empty" id="Start" />
<Interaction interactionType="Empty" id="End" />
</ConversationInteractions>
<ConversationTransitions>
<Transition>
<SourceInteraction href="Start"/>
<DestinationInteraction href="Login"/>
</Transition>
<Transition>
<SourceInteraction href="Start"/>
<DestinationInteraction href="Registration"/>
</Transition>
<Transition>
<SourceInteraction href="Registration"/>
<DestinationInteraction href="Login"/>
</Transition>
<Transition>
<SourceInteraction href="Login"/>
<DestinationInteraction href="Registration"/>
<SourceInteractionCondition href="InvalidLoginRS"/>
</Transition>
<Transition>
<SourceInteraction href="Login"/>
<DestinationInteraction href="Login"/>
<SourceInteractionCondition href="InvalidLoginRS"/>
</Transition>
<Transition>
<SourceInteraction href="Login"/>
<DestinationInteraction href="CatalogInquiry"/>
<SourceInteractionCondition href="ValidLoginRS"/>
</Transition>
<Transition>
<SourceInteraction href="Login"/>
<DestinationInteraction href="Quote"/>
<SourceInteractionCondition href="ValidLoginRS"/>
</Transition>
<Transition>
<SourceInteraction href="Login"/>
<DestinationInteraction href="Purchase"/>
<SourceInteractionCondition href="ValidLoginRS"/>
</Transition>
<Transition>
<SourceInteraction href="CatalogInquiry"/>
<DestinationInteraction href="CatalogInquiry"/>
</Transition>
<Transition>
<SourceInteraction href="CatalogInquiry"/>
<DestinationInteraction href="Quote"/>
</Transition>
<Transition>
<SourceInteraction href="Quote"/>
<DestinationInteraction href="CatalogInquiry"/>
</Transition>
<Transition>
<SourceInteraction href="Quote"/>
<DestinationInteraction href="Purchase"/>
</Transition>
<Transition>
<SourceInteraction href="Purchase"/>
<DestinationInteraction href="Purchase"/>
<SourceInteractionCondition href="InvalidPaymentRS"/>
</Transition>
<Transition>
<SourceInteraction href="Purchase"/>
<DestinationInteraction href="Shipping"/>
<SourceInteractionCondition href="PurchaseOrderAcceptedRS"/>
</Transition>
<Transition>
<SourceInteraction href="Shipping"/>
<DestinationInteraction href="End"/>
</Transition>
<Transition>
<SourceInteraction href="Purchase"/>
<DestinationInteraction href="End"/>
<SourceInteractionCondition href="InvalidPaymentRS"/>
</Transition>
<Transition>
<SourceInteraction href="Purchase"/>
<DestinationInteraction href="End"/>
<SourceInteractionCondition href="OutOfStockRS"/>
</Transition>
<Transition>
<SourceInteraction href="Quote"/>
<DestinationInteraction href="Logout"/>
</Transition>
<Transition>
<SourceInteraction href="CatalogInquiry"/>
<DestinationInteraction href="Logout"/>
</Transition>
<Transition>
<SourceInteraction href="Logout"/>
<DestinationInteraction href="End"/>
</Transition>
</ConversationTransitions>
</Conversation>
![[1]](http://www.w3.org/TR/wscl10/Fig1.png){kind=link}
![[2]](http://www.w3.org/TR/wscl10/Fig2.png){kind=link}
![[3]](http://www.w3.org/TR/wscl10/Fig3.png){kind=link}