The following are some common questions and answers about WSCI.
The Web Service Choreography Interface (WSCI) is an XML-based language used to describe the flow of messages exchanged by a Web service in the context of a process. It allows the description of the observable behavior of a Web service in a message exchange.
WSCI also describes the collective message exchange among interacting Web services, providing a global, message-oriented view of a process involving multiple Web services.
WSCI describes a one-sided interface for a Web service, meaning the message exchange is described from the point of view of each Web service. With WSCI, each message exchange can be qualified by message correlation, transaction description and location capabilities.
WSCI describes the observable behavior of stateful services. However, WSCI does not address the definition of the process driving the message exchange, nor does it address the definition of the internal behaviour of each Web service.
With WSCI, developers and architects will be better able to design and create collaborative business processes based on the Web service model. WSCI builds upon current Web service technologies to enable users of a service - such as another Web service or an application - to understand how to interact with it in a way meaningful to a greater collaboration.
WSCI also enables developers and architects to describe and compose a global view of the dynamic of the message exchange, another important part of creating a meaningful collaboration. A standard XML syntax for service choreography -- such as WSCI -- is also essential to ensuring interoperability of Web services.
Current Web service descriptions allow operations to define the direction of messages (incoming or outgoing), but they do not describe the behavior of the service involving multiple individual operations - in other words, they do not provide enough details of what the service can be expected to do.
Today's service descriptions may be adequate for simple information retrieval in a stateless message exchange, such as a stock quote. There is no standard way, though, of correlating the messages that are exchanged by the Web service with the context of the process in which the Web service operates. This is an important function for building useful service collaboration, and this is the area that WSCI addresses.
Information provided by WSCI, along with information on exactly how the Web service can be executed and what role the Web service might play as part of a larger collaboration, is essential to a meaningful and manageable collaboration.
Simple services -- those whose behavior does not depend on the scenario in which they are used -- can be easily defined by means of WSCI. More complex services that would require a more thorough definition of both the collaboration's overall semantics as well as the internal implementation would use WSCI integrated with this other information, with the WSCI interface serving as the linking point between the inter-party collaboration and the intra-service implementation.
WSCI interface could be the service description that is advertised and discovered through the UDDI registries. WSCI could also be used to describe a legacy application in order to expose it as a Web service.
WSCI picks up where WSDL ends. WSDL enables a Web service to be described in terms of the operations it can support and of the protocols bound to such operations. WSCI describes how WSDL operations are choreographed and which properties these choreographies expose, such as transaction and correlation.
BPSS is ebXML's XML-based expression of a choreographed message exchange among business partners. The view point of BPSS is always on the exchange between the parties. An atomic exchange is called a BusinessTransaction. BPSS allows you to specify a choreography of BusinessTransactions. This is called a BinaryCollaboration. WSCI is a generic expression of one party's interface to any message exchange choreography. So while not specifically designed for BPSS, it could serve as the description of a party's interface to either a high level BPSS BinaryCollaboration, and/or a low level BPSS BusinessTransaction.
WSFL is a language that defines how to build a "flow" involving multiple services as well as the Web service representation of this flow. However, it does not describe how a Web service can participate in a stateful collaboration, nor does it describe what a Web service can expose to other peers with respect to a shared collaboration. It is these two points that are essential to providing interoperability of Web services.
WSCI and WSFL could work together, with WSCI describing the interface for a service participating in a flow defined by WSFL.
XLANG's "interface" is bound to a service instance. A WSCI interface, however, is not bound to any specific Web service instance. Rather, it applies to all services supporting a particular static interface and can be bound to any static definition language even if, in the specification, an explicit binding has been described, such as with WSDL.
The value of separating the description of the Web service's capabilities from the service definition and implementation is efficiency through reuse: the description can apply to any service independent of the methodologies and architectures adopted for conceiving and implementing the services. WSCI can be used to describe virtually any Web service that exchanges messages, regardless of the way the service was built.
BTP addresses transaction coordination between parties with a previous relationship and operates at the protocol level. In contrast, WSCI describes how a Web service participates in a message exchange. If parts of the message exchange exhibit transactional behavior, the interface exposes such information, which could be defined by BTP. WSCI itself does not define how the transaction is carried by the Web service nor how it should be coordinated with other services.
WSCI is complementary to BPML. WSCI defines the interaction between services deployed across multiple systems, while BPML defines the business process behind each service, mapping business activities to message exchange. Together, they provide an end-to-end view that depicts the role of each individual business process in the overall choreography, and the business activities performed by each role.
WSCL provides a simple state-transition model for organizing the sequence of WSDL operations. Unlike WSCI, it does not support properties, contexts, transactions, exception handling, time-out, locators, global models, correlations, or any of the other features found in WSCI. Although there is some overlap, WSCI provides a set of useful and necessary additions to WSCL, and there is synergy in their basic concepts.
To date, the co-editors have been testing only with WSDL, but it is conceivable that WSCI could work with DAML-S, XL, or others.
EDOC (Enterprise Distributed Object Computing) is an approved OMG specification. It contains a recursive component model, which in turn contains an expression of the choreography of the component's data exchange with the outside world (and through recursion, with its inside world). This component model aspect of EDOC is being considered as the basis for JSR 159, a proposal for a Process Component for the Java Platform that is under development in the Java Community Process. WSCI contains a generic expression of an interface's choreographed exchange of messages with the outside world. It does not have an explicit expression of any possible exchange of messages within (or behind) that interface. It does, however, specify a set of contextual semantics about each message choreography. As such, WSCI can serve as the generic, and context aware, specification (or description) of an EDOC component, and later possibly of a JSR 159 component.
The XML Pipeline Definition Language addresses the question of how to actually begin processing an XML message or document with XML-related processes (validation, transformation, and so on) once it has been received. XML Pipeline Definition Language operates at a different architectural level from message flow control and business process languages. WSCI is higher in the Web services architectural "stack" and helps to describe the observable behavior of a Web service in the context of a message and document transfer.