[January 12, 2002] Web Services Conversation Language (WSCL) provides an XML schema for defining legal sequences of documents that web-services can exchange. WSCL "allows defining the abstract interfaces of web services, i.e., the business level conversations or public processes supported by a web service. 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, e.g., to provide protocol binding information for abstract interfaces and to specify the abstract interfaces a concrete service is supporting." [From the WSCL specification abstract]
WSCL version 1.0 is derived from the Conversation Definition Language (CDL) as defined in the HP Service Framework Specification (SFS). The service framework specification "is a layered specification that enables interoperability through the use of XML and formal definitions of interactions amongst services. It also provides mechanisms for dynamically discovering services as well as interacting with them through the exchange of XML documents. The specification has two parts: the first part specifies more horizontal infrastructural services such a messaging, service definition, transactions, management, vocabularies, and discovery of services. The second part focuses on higher level business interactions such as negotiation and contract formation."
WSCL description from the 2001-05 specification:
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. We also have to define in which order these documents need to be exchanged, thus specifying a business level conversation. By specifying the conversations supported by a web service, i.e. by defining the documents to be exchanged and the order in which they may be exchanged, we define the external visible behavior of a web service, its abstract interface. Conversations focus on the public processes in which the participants of a web service engage... By clearly distinguishing between the concepts of abstract interface, communication protocol, and concrete service, we enable the loose coupling desired for web services. 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 and then be bound to different protocols and be 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.
There are various possible ways to describe business level conversations. The conversation definition language WSCL has chosen a formal approach, based on XML. WSCL is defined by an XML schema. WSCL 1.0 is a simple conversation definition language 1 . Its purpose is to provide and define the minimal set of concepts necessary to specify conversations. It is expected that WSCL will be extended for more complex web services framework, e.g. to include multi-party conversations, quality of service attributes, transactions, or composition of conversations.
A key advantage of formal specification languages such as WSCL 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. For example, a service developer could create WSCL specifications documenting their service's abstract interface, and make this documentation available to potential users. A software developer can then use WSCL compliant web services servers and tools that would provide such functionality as document type validation, conversation tracking, and message dispatching to the application logic. Ideally, software developers creating and using 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 separating cleanly between the conversational and the application logic. Without any formal definition of the conversations, such tool support will not be possible.
"In the traditional application model, services are tightly coupled with the processes they support. For example, whenever a server's process changes, existing clients that use that process must also be updated. However, electronic commerce is moving towards e- service based interactions, where corporate enterprises use e-services to interact with each other dynamically, and a service in one enterprise could spontaneously decide to engage a service fronted by another enterprise. In this paper, we clarify the relationship between currently developing standards such as the Universal Description Discovery and Integration (UDDI), the Web Services Description Language (WSDL), and the Web Services Conversation Language (WSCL), and propose a conversation controller mechanism that leverages such standards to direct services in their conversations. Using such a mechanism means that services can be written as pools of methods independent of the conversations they will participate in. Even the specific method names can be decided on independently of the conversations. The services can spontaneously discover each other and then engage in complicated interactions without the services themselves having to explicitly support conversational logic. The dynamism and flexibility enabled by this decoupling is the essential difference between applications offered over the web and e- services." [abstract from TR 'HPL-2001-127' cited below]
"The prevalent model for web-service communication is that web-services will publish information about the specifications that they support. UDDI facilitates the publication and discovery of web-service information. 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. Together, UDDI, WSDL, and WSCL enable developers to implement web services capable of spontaneously engaging in dynamic and complex inter-enterprise interactions. 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. The Web Services Conversation Language (WSCL) addresses this issue, providing an XML schema for defining legal sequences of documents that web-services can exchange; it provides a standard way to model the public processes of a service, thus enabling network services to participate in rich interactions. Web services interact by exchanging messages. Each message can be expressed as a structured document (e.g., using XML) that is an instance of some document type (e.g., expressed using XML Schema). A message may be wrapped (nested) in an encompassing document, which can serve as an envelope that adds contextual (delivery or conversation specific) information (e.g., using SOAP). We define a conversation to be a sequence of message exchanges between two or more services. We clarify the relationship between WSCL, UDDI, and WSDL; in particular, we describe how together these three components can be used to create an environment in which services can spontaneously discover each other and then engage in complicated interactions.We define a conversation specification to be a formal description of 'legal' message type-based conversations that a service supports..." [from 'Using WSCL in a UDDI Registry 1.02']
References:
- HP web services
- WSCL 1.0 submission to W3C:
- Web Services Conversation Language (WSCL) 1.0. W3C Note 14-March-2002.
- HP's WSCL submission request to W3C
- W3C Staff comment from Hugo Haas (Team contact for the Web Services Architecture Working Group)
- Web Services Conversation Language (WSCL) 1.0. By Arindam Banerji, Claudio Bartolini, Dorothea Beringer, Venkatesh Chopella, Kannan Govindarajan, Alan Karp, Harumi Kuno, Mike Lemon, Gregory Pogossiants, Shamik Sharma, and Scott Williams. May 2001. Hewlett-Packard Company. 21 pages. [cache]
- WSCL XML Schema Definition and Example WSCL Specification. From the May 2001 specification (Appendices A and B).
- Conversations + Interfaces = Business Logic. By Harumi Kuno, Mike Lemon, Alan Karp, Dorothea Beringer (Software Technology Laboratory, HP Laboratories Palo Alto, CA). Reference: HPL-2001-127/20010601. May 23, 2001. 15 pages. See also the overview. [cache]
- Using WSCL in a UDDI Registry 1.02. UDDI Working Draft Best Practices Document. May 5, 2001. By Dorothea Beringer, Harumi Kuno, and Mike Lemon (Hewlett-Packard Company). [cache, alt URL]
- Service Framework Specification, Part I, Version 2.0. By Arindam Banerji, Claudio Bartolini, Dorothea Beringer, et al. Hewlett-Packard Company. Reference: HPL-2001-138/20010626. June 7, 2001. 199 pages. "The service framework specification is a layered specification that enables interoperability through the use of XML and formal definitions of interactions amongst services. It also provides mechanisms for dynamically discovering services as well as interacting with them through the exchange of XML documents. The specification has two parts: the first part specifies more horizontal infrastructural services such as messaging, service definition, transactions, management, vocabularies, and discovery of services. The second part focuses on higher level business interactions such as negotiation and contract formation." [cache]
- Schemas and Example Documents. From the HP Service Framework Specification, Part I, Version 2.0. June 7, 2001.
- "Transformational Interactions for P2P E-Commerce." By Harumi Kuno, Mike Lemon, and Alan Karp (Software Technology Laboratory, HP Laboratories Palo Alto, California). HP Reference: HPL-2001-143 (R.1). October 10, 2001. To be published in and presented at IEEE HICSS-35, Hawaii International Conference on System Services, January 2002. "We propose a facilitator service mechanism that can leverage 'reflected' XML-based specifications (borrowed from the web service domain) to direct and enable coordinated sequences of mes-sage exchanges (conversations) between services. We extend the specification of a message exchange with the ability to specify transformations to be applied to both inbound and outbound documents. We call these extended message exchanges transformational interactions. The facilitator service can use these transformational interactions to allow service developers to decouple internal and external interfaces. This means that services can be developed and treated as pools of methods that can be composed dynamically... We extended the Web Service Conversation Language (WSCL) to meet our need for a conversation definition language that includes document transformation specifications. WSCL is an XML-based specification that defines a service interface in terms of a list of interactions (keyed by document type), a list of transitions that describe legal interaction orderings. We extended our usage of WSCL to include mappings of the input and output document types to corresponding document transformations... WSCL addresses the problem of how to enable services from different enterprises to engage in flexible and autonomous, yet potentially quite complex, business interactions. It adopts an approach from the domain of software agents, modelling protocols for business interaction as conversation policies, but extends this approach to exploit the fact that service messages are XML-based business documents and can thus be mapped to XML document types. Each WSCL specification describes a single type of conversation from the perspective of a single participant. A service can participate in multiple types of conversations. Furthermore, a service can engage in multiple simultaneous instances of a given type of conversation. For example, a service that supports the 'secured album' conversation type [from Figure 1] expects a conversation to begin with the receipt of a LoginRQ or a RegRQ document. Once the service has received one of these documents, then the conversation can progress to either a 'logged in' state or a 'registered' state, depending on the type of message the service generates to return to the client. There are three elements to a WSCL specification: Document type descriptions specify the types (schemas) of XML documents that the service can accept and transmit in the course of a conversation; Interactions model the state of the conversation as the document exchanges between conversation participants; Transitions specify the ordering relationships between interactions... Our solution is unique in that we distinguish between the conversational protocols and service-specific interfaces. This allows us to provide an extremely lightweight solution relieving service developers from the burden of implementing conversation-handling logic. In addition, we also introduce transformational interactions that allow facilitator services to leverage document transformations and make possible the automated coordination of complex conversations between peer services that do not support compatible message document types. In the future, we plan to investigate more sophisticated uses of conversation policies. For example, we would like to provide a model for the explicit support of deciding conversation version compatibility. We would also like to explore how to support both nested conversations and multi-party. Finally, we hope to address how to exploit document type relationships when manipulating message documents. For example, we would like to use subtype polymorphism to establish a relationship between a document type accepted as input by an interface specification and a corresponding document type in a conversation specification..." [cache]
- [January 12, 2002] "Tying the Application Knot." By Mario Apicella. In InfoWorld (January 10, 2002). "Web services promise to deliver an open, Web-based architecture to connect business processes, which could potentially turn upside down the way we think of, create, and use software... WSCL (Web Services Conversation Language), an interesting set of specifications released in May by Hewlett-Packard, complements the service descriptions of WSDL with essential elements to describe the flow of a business process between partners. WSCL completes a UDDI registry for a company with business process information such as the document formats to exchange, the activities needed to carry on the transaction, and their sequence. However, even with the addition of WSCL, UDDI registries could fall short describing all the roles and interactions that make a cooperative e-business scenario. A competing set of specifications for e-business, called ebXML (E-Business XML), promises a more comprehensive approach to discovering services and partners and defining business scenarios involving multiple parties... New specifications, including WSCL (Web Services Conversation Language) and ebXML (e-business XML), take a more comprehensive approach to describing process flows..."
- "CDL: Conversation Definitions: Defining Interfaces of Web Services." By Kannan Govindarajan, Alan Karp, Harumi Kuno, Dorothea Beringer, and Arindam Banerji (Hewlett Packard Company). Presented at the W3C Workshop on Web services, 11-12 April 2001 - San Jose, CA, USA.
- A different WSCL: see the XML DTD for the 'Workspaces Coordination Language (WSCL)'; the 'WSCL' DTD was created from the Workflow Process Description Language (WPDL). See "Design and Implementation of an XSL-T and XML-based Workflow System," presented at XML Europe 2001 by Marc Stauch and Dr Robert Tolksdorf.
