Copyright © 2001-2002 Hewlett-Packard Company
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.
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/.
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:
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. 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. UML Activity Diagram of a Conversation Definition
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.
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.
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.
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.
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.
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.
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.
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.
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:
The Conversation element contains the following attributes:
For a conversation definition to be well-formed, it has to adhere to the conversation schema in Appendix A and fulfill the following restrictions:
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.
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.
There are three main aspects of Web services (see Figure 1):
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:
<?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.
<?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>
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:
[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"
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>
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>