Web Service Choreography Interface 1.0

Authors (alphabetically):

• Assaf Arkin, Intalio
• Sid Askary, Intalio
• Scott Fordin, Sun Microsystems
• Wolfgang Jekeli, SAP
• Kohsuke Kawaguchi, Sun Microsystems
• David Orchard, BEA Systems
• Stefano Pogliani, Sun Microsystems
• Karsten Riemer, Sun Microsystems
• Susan Struble, Sun Microsystems
• Pal Takacsi-Nagy, BEA Systems
• Ivana Trickovic, SAP
• Sinisa Zimek, SAP

Status of this Document

This draft proposes a language standard that can be used in conjunction with existing Web-service protocols to provide a description of the observable behavior of Web services. It is provided by the authors for consideration and review by the web services community.

Feedback and comments are welcome and may be sent to BEA Systems, Intalio, SAP AG, or Sun Microsystems.

Please note that feedback to any one of these aliases is automatically shared amongst all co-editors. For more information on the shared privacy policy regarding any feedback information, please visit any of the co-editor's sites where the WSCI specification is now hosted.

Abstract

The Web Service Choreography Interface (WSCI) is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services.

WSCI describes the dynamic interface of the Web Service participating in a given message exchange by means of reusing the operations defined for a static interface. WSCI works in conjunction with the Web Service Description Language (WSDL), the basis for the W3C Web Services Description Working Group; it can, also, work with another service definition language that exhibits the same characteristics as WSDL.

WSCI describes the observable behavior of a Web Service. This is expressed in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. WSCI also describes the collective message exchange among interacting Web Services, thus providing a global, message-oriented view of the interactions.

WSCI does not address the definition and the implementation of the internal processes that actually drive the message exchange. Rather, the goal of WSCI is to describe the observable behavior of a Web Service by means of a message-flow oriented interface. This description enables developers, architects and tools to describe and compose a global view of the dynamic of the message exchange by understanding the interactions with the web service.

Table of Contents

• Web Service Choreography Interface 1.0
• Authors
• Status
• Abstract
• 1. Introduction
  • 1.1 Overview
  • 1.2 The Reference Framework
  • 1.3 Problem
    • 1.3.1 The current Web Services stack
    • 1.3.2 The need for describing complex interactions
  • 1.4 Challenges
  • 1.5 Solution
  • 1.6 External Architecture
    • 1.6.1 Relationship to Web Service Description Language (WSDL)
    • 1.6.2 Relationship to Implementations
    • 1.6.3 Relationship to Collaborations
    • 1.6.4 Relationship to Workflow
  • 1.7 Simple Example
    • 1.7.1 Scope
    • 1.7.2 Simple scenario
    • 1.7.3 The static definition
    • 1.7.4 What is missing
    • 1.7.5 The WSCI definition
    • 1.7.6 Benefits
  • 1.8 Notational Conventions
    • 1.8.1 Keywords
    • 1.8.2 Namespaces
    • 1.8.3 Informal Syntax
• 2. Language Overview
  • 2.1 Concepts
    • 2.1.1 Interface
    • 2.1.2 Activities and their choreography
    • 2.1.3 Processes
    • 2.1.4 Properties
    • 2.1.5 Context
    • 2.1.6 Message correlation
    • 2.1.7 Exceptional behavior
    • 2.1.8 Transactional behavior
    • 2.1.9 Global Model
  • 2.2 Extensibility
• 3. Language Elements
  • 3.1 Introduction
    • 3.1.1 Terminology conventions
    • 3.1.2 The root element
    • 3.1.3 Documentation and naming
  • 3.2 Selector
  • 3.3 Message Correlation
    • 3.3.1 Correlation
  • 3.4 Atomic behavior
    • 3.4.1 Action
    • 3.4.1.1 Example
    • 3.4.2 Correlating the Action Context
    • 3.4.3 Calling a process from within an action
    • 3.4.4 Extensibility of the action element
  • 3.5 Choreography Description
    • 3.5.1 Activity
    • 3.5.2 Activity Set
    • 3.5.3 Complex Activity
    • 3.5.4 Context
  • 3.6 Choreography Elements
    • 3.6.1 All
    • 3.6.2 Choice
      • 3.6.2.1 Example
      • 3.6.2.2 Message Event Handler
      • 3.6.2.3 Timeout Event Handler
      • 3.6.2.4 Fault Event Handler
    • 3.6.3 Behavior
    • 3.6.4 Foreach
    • 3.6.5 Sequence
      • 3.6.5.1 Example
    • 3.6.6 Switch
      • 3.6.6.1 Example
    • 3.6.7 Until
    • 3.6.8 While
  • 3.7 Other activities
    • 3.7.1 Delay
    • 3.7.2 Empty
    • 3.7.3 Fault
  • 3.8 Composition and Re-use
    • 3.8.1 Process
    • 3.8.2 Call
    • 3.8.3 Spawn
    • 3.8.4 Join
  • 3.9 Exception Handling
    • 3.9.1 Exception
  • 3.10 Transactional behavior
    • 3.10.1 Transactions
      • 3.10.1.1 Atomic Transactions
      • 3.10.1.2 Open Transactions
      • 3.10.1.3 Compensation
      • 3.10.1.4 Behavior
      • 3.10.1.5 Syntax
      • 3.10.1.6 Example
    • 3.10.2 Compensate
  • 3.11 Interface
    • 3.11.1.1 Example
• 4. Global model
• 5. Example
  • 5.1 Overview
  • 5.2 Use Case definition
  • 5.3 Building from the simple example
  • 5.4 WSCI Interfaces
    • 5.4.1 The Travel Agent Interface
      • 5.4.1.1 Modeling details
      • 5.4.1.2 The WSCI interface
    • 5.4.2 The Traveler Interface
      • 5.4.2.1 Modeling details
      • 5.4.2.2 The WSCI interface
    • 5.4.3 The Airline Interface
      • 5.4.3.1 Modeling details
      • 5.4.3.2 The WSCI interface
  • 5.5 Correlations and Selectors definitions
  • 5.6 Global Model
    • 5.6.1 Modeling details
    • 5.6.2 The WSCI global model
  • 5.7 WSDL Types and Messages
• 6. Dynamic Participation
  • 6.1 Locate
  • 6.2 Locator
• 7. Future Work
  • 7.1 Exclusion Groups
  • 7.2 Web based Collaboration
  • 7.3 Global Model
• 8. Appendix
  • 8.1 Known Issues
  • 8.2 References
  • 8.3 Glossary
  • 8.4 WSCI Schema
    • 8.4.1 Standard
    • 8.4.2 Extended: Locate

1. Introduction

1.1 Overview

WSCI describes how Web Service operations – such as those defined by WSDL [WSDL]– can be choreographed in the context of a message exchange in which the Web Service participates. Interactions between services – either in a business context or not – always follow and implement choreographed message exchanges (processes). WSCI is the first step towards enabling the mapping of services as components realizing those processes.

WSCI also describes how the choreography of these operations should expose relevant information, such as message correlation, exception handling, transaction description and dynamic participation capabilities.

WSCI does not assume that Web Services are from different companies, as in business-to-business; it can be used equally well to describe interfaces of components that represent internal organizational units or other applications within the enterprise. Again, WSCI does not address the definition of the process driving the message exchange or the definition of the internal behavior of each Web Service.

WSCI describes the interdependencies among the Web Service’s operations so that any client:

• Can understand how to interact with such service in the context of the given process; and
• Can "anticipate" the expected behavior of such service at any point in the process’ lifecycle.

Being able to describe the dynamic interface of a service in the context of a particular process enables the developer/architect to abstract from the implementation and to focus on the role the Web Service plays in such process.

1.2 The Reference Framework

Web Services are a key component of the emerging, loosely coupled, Web-based computing architecture. A Web Service is an autonomous, well-defined, standards-based component that can be accessed via established Web-based protocols.

A "stack" of layered standards is emerging that aims to ensure semantic and technical interoperability of Web Services. This stack, developed by the W3C, is still in its early stages and is currently being built from the ground up; several additional layers are needed in order to enable true Web Service collaborations.

In parallel, other standards are building semantics and interoperability for business processes and collaborations in a top-down approach.

It is anticipated that these two stacks will meet in the middle. Although there is still a need for an overall architecture to make this happen in an effective way, WSCI provides the first step to linking the two.

WSCI is primarily a participant in the bottom-up stack, but it anticipates the emergence and integration of higher-level layers in the area of collaboration.

1.3 Problem

1.3.1 The current Web Services stack

The current Web Service stack does not define a choreography language or any other relationship among atomic operations. It does, however, provide the basic layers:

• SOAP defines the basic formatting of a message and the basic delivery options. A SOAP compliant Web Service knows how to send and receive SOAP-based messages

• WSDL describes the static interface of a Web Service. It defines the protocol and the message characteristics of end points by means of four basic operations; a WSDL compliant Web Service knows how to support any of these four operations. The operations defined in this way:

  • Are atomic in nature (that is, no intermediate state is visible from the outside)

  • Describe the direction of messages (incoming or outgoing) but not the behavior of the service as a result of each individual operation.

The current Web Service technologies may be adequate for simple information retrieval in a stateless message exchange, such as a stock quote Web Service; for some services, it may even be sufficient for messages to maintain state in remote procedure calls by passing tokens or state variables within objects.

1.3.2 The need for describing complex interactions

Most Web Services, however:

• Participate in longer conversations, spanning beyond the boundaries of a single operation. In these conversations, the ability to perform certain operations depends upon the previous exchange of messages as well as the way to interpret the content of each message may be influenced by the previous exchange.

• Provide compound services, rather than atomic actions. For instance, this is the case of Web Services that interact with complex back-end business processes. Such processes are often automated and require a defined choreography of messages to properly operate and provide the service that is required.

Therefore, there is a need to address questions such as the following:

• Can messages be sent and/or received in any order?
  Without a clean and precise description of the message choreography supported by the Web Service, it would be difficult for a client – which wants to interact with the service – to properly understand the sequence of messages the Web Service is expecting and the sequence of messages it will deliver.

• What rules govern sequencing of messages?
  Without a precise description of the way in which information carried by the exchanged messages affect the observable behavior of a Web Service, it would be difficult for a client to properly manage situations in which messages of different types can be expected depending upon the value of some condition.

• Is there any relation among any incoming and/or outgoing messages?
  In order to properly prepare and interpret the messages that are exchanged within a given process, it is very important to understand and describe the correlation between these messages, i.e. the mechanism by which the Web Service can manage concurrent conversations.

• Is there a "start" and an "end" of a given sequence? Can a given sequence be partially "undone"?
  In order for a Web Service to be part of a long message exchange, it is important to clearly define when the message exchange is actually triggered, when it is considered to terminate and which parts of it can be considered as managed in a transactional way.

• Can a global view of the overall exchange of messages be drawn?
  A static Web Service definition language alone does not address the need for composing a global model of how two (or more) Web Services interact. Without something like WSCI, it is not possible to understand how the services interoperate and thus:

  • To verify if the service behaved as stated by a given process specification

  • To derive the choreography of the overall process to describe and thus, potentially, to modify it.

  • To monitor the behavior of the service on respect to all other participants in the message exchange

1.4 Challenges

The answers to questions such as the ones listed in the previous section are addressed by EAI middleware in a traditional, intra-enterprise environment,. But the loosely coupled, distributed nature of the Web prevents a central authority (or a centralized implementation of a middleware) from exhaustively and fully coordinating and monitoring the activities of the enterprise applications that expose the Web Services actually participating in the message exchanges. The reasons are:

• Traditional workflow models rely on message-based computing methods that are tightly coupled to protocols for business-to-business or application integration. These protocols assume a different, more tightly linked and controllable environment, which is not the nature of the Web.

• Participants in traditional workflow are, normally, known in advance. When moving to the Web environment, it is very likely that Web Services will be dynamically chosen to fulfill certain roles.

• Traditional models normally call for centralized engines, while the nature of the Web is decentralized.

This provides a fundamental challenge in defining and running a complex, process-aware Web Service based on traditional workflow models.

Thus, the challenge for WSCI is to provide answers to the previous (and other related) questions in the domain of the Web based computing. Fundamentally, the challenge will be to describe Web Services:

• From an external point of view (without knowing how internally they operate)

• Independently of any particular integration model (workflow, MOM etc)

• Precisely enough to allow other components to have a clear understanding of how to properly interact with them.

• In the context of each specific message exchange in which they participate.

1.5 Solution

To be part of a useful and manageable Web Service collaboration, individual operations must be allowed to convey enough information about how they can be used in a given scenario in order to enable them to participate in more complex processes.

WSCI achieves this by defining a layer on top of the existing Web Service stack. This layer describes the required behavior of a Web Service relative to the message exchange it must support.

WSCI supports the following key requirements for a long lasting, choreographed, stateful message exchange:

• Message choreography: a WSCI interface describes the order in which messages can be sent or received in a given message exchange, the rules which govern such ordering, the boundaries of a message exchange (when it starts and when it ends).

  WSCI does not define how the Web Service internally manages such choreography. Instead, it allows a Web Service to assert what is the observable choreography of messages it is capable of managing in the context of a given message exchange.

• Transaction boundaries and compensation: A WSCI interface describes which operations are performed in a transactional way and, thus, informs other participants of the capability of such Web Service to perform these operations in an "all or nothing" way. This capability also enables the Web Service to eventually join a distributed transaction with other services with which it interacts.

  WSCI does not define a two-phase commit protocol over the Web or how transactions are carried over by Web Services. Rather, it allows a Web Service to assert when it is capable of managing operations in a transactional way, to precisely define the transaction boundaries and the externally observable compensation behavior.

• Exception handling: A WSCI interface describes how the Web Service will react when exceptional conditions happen, thus providing a description of alternative patterns of behavior.

  However, WSCI itself does not define the mechanism by which a Web Service reacts and manages exceptional situations and faults. Again, it allows a Web Service to describe its observable behavior when it’s dealing with deviations from the normal behavior.

• Thread management: A WSCI interface describes if and how a Web Service is capable of managing multiple conversations (based on the same message exchange) with the same partner or with different partners. In the same way, it also describes the required relationship among parts of different messages belonging to the same message exchange.

  WSCI does not define how the Web Service is capable of managing multiple conversations in a concurrent way. It allows a Web Service to assert the observable elements of the exchanged messages that allow it to properly treat each conversation separately from the others. Further, WSCI allows a Web Service to describe the relationships among the parts of different messages that collectively guarantee the consistency of the message exchange.

• Properties and Selectors: A WSCI interface describes the elements that influence the observable behavior of a Web Service, such as alternatives based on the runtime values of some parts of the messages.

  Although WSCI is not an executable language that provides the semantic for variables used to automate it, it allows a Web Service to assert which are the relevant elements of the exchanged messages that influence its observable behavior at any given time.

• Connectors: A WSCI interface describes how the operations performed by different Web Services acting in the same message exchange actually link together. WSCI enables the mapping of "consume" operations from a Web Service to "produce" operations from another Web Service in order to unambiguously build a model of the global exchange. By means of the WSCI Global Model it is also possible to describe how interfaces from different services participating in the same message exchange can be linked together to build the end-to-end model of interactions.

  WSCI does not define the middleware connecting the Web Services involved in the message exchange, nor does it define the order in which different Web Services happen in the course of a message exchange.

• Operational context: A WSCI interface describes how the same Web Service behaves in the context of different message exchanges.

  Different WSCI interfaces (observable behaviors) can be associated with the different operational contexts in which the Web Service participates. WSCI does not define the behavior of a Web Service independently on how it is used.

• Dynamic participation: A WSCI interface describes how the identity of the target service is dynamically selected. This selection is based on some criteria that are known at runtime and that depend on information described by the WSCI interface itself, such as message parts. By knowing the properties used to identify the target service, it is possible to understand how, changing the value of such properties, the behavior of the corresponding service is affected.

  The definition of a particular mechanism used to identify the target service is out of the scope of WSCI and can be addressed by existing and future specifications.

In summary, a WSCI interface describes all the artifacts required to provide:

• The external, observable view of how the Web Service interacts with other services within a given message exchange, or, in other words, how the Web Service is perceived to behave by the external world in the context of a given message exchange,

• The view of the message exchange as seen by the Web Service, or, in other words, how the Web Service perceives the behavior of the external world in the context of a given message exchange.

In doing this, the interface promotes the capabilities the Web Service provides in a given message exchange (transactional, correlation etc).

The above features and concepts are described in further detail in subsequent sections of this specification.

1.6 External Architecture

WSCI defines a new layer in the emerging stack of standards associated to Web Services.

WSCI works on top of the current Web Service stack and below layers in the emerging Web Service architectural model that may be thought of as process or collaboration modeling layers.

WSCI describes the interface between an implementation and the message exchange (collaboration) in which it participates.

1.6.1 Relationship to Web Service Description Language (WSDL)

WSCI is designed to work in conjunction with Web Service description languages, which provide the static interface of a Web Service. While WSCI can work with different description languages, particular attention is devoted to the binding to WSDL, which is the basis for the W3C Web Services Description Working Group and rapidly gaining momentum.

Both WSDL and WSCI can be seen as interfaces. WSDL describes a static interface that evenly lists the entry points to the service. WSCI describes the dynamic interface by providing for the interrelationship between multiple operations in the context of a well-defined message exchanges. The very idea of WSCI as an interface lies in the fact that it can operate on WSDL (or any other static description language) artifacts, which are mainly messages exchanged by services.

When used in conjunction with WSDL, WSCI enables the description of complex choreographies across multiple operations as defined by WSDL. The messages and their associated "operations", "services", "ports" are directly referenced from the relevant WSDL definitions. Where WSDL describes each "operation" in a vacuum, WSCI enables the description of complex choreographies across multiple "operations". One of the basic concepts of WSCI – Action – directly maps to the execution of any of the four types of WSDL operations.

Whilst it is possible for a static description language to provide a single interface for a Web Service, it is very likely that the same Web Service exhibits more than one WSCI interface; each WSCI interface describes the observable behavior of that service in a specific message exchange context. It is also possible that the behavior in the same message exchange context would be described by multiple WSCI interfaces, each one providing a "view" for a different party.

1.6.2 Relationship to Implementations

WSCI is an interface description language. It describes the observable behavior of a service and the rules for interacting with the service from the outside. It does not specify the possible implementation on the inside. It is declarative and cannot, by itself, be executed. However, it is precise and unambiguous enough that external actors will know at each stage in the given process which messages that service may or must send or receive next.

The observable behavior of each party in a message exchange is described independently of the others; each party could actually be implemented by completely abstracting from its WSCI description; WSCI’s main goal is to describe an observable behavior, not to define how the implementation works.

Thus, in a message exchange, any Web Service described by WSCI can interact with:

• Other Web Services, whose implementation has been derived by their WSCI description

• ‘Hard-coded’ software components with internally encoded mechanisms to guarantee the correct sequence of the exchange

• Or human controlled software agents where the human determines the sequence of interaction within the constraints of the WSCI description.

For that matter, the message exchange could actually be several human controlled software agents interacting.

Although WSCI has no explicit constructs for implementation, it is assumed that every sending of a message is mapped to some identifiable processing in the implementation (actually, the processing required for or resulting in the sending of the message). Likewise, it is assumed that every receipt of a message is mapped to some identifiable processing in the implementation (actually, the processing triggered by the receipt of the message).

Non-observable mappings, such as the use of some internal software are outside the scope of WSCI.

A specific kind of mapping between messages and implementation that may be observable is the recursive use of services, so that an incoming message might cause the invocation of another lower level or auxiliary service through a separate message exchange.

1.6.3 Relationship to Collaborations

Business processes are increasingly relying upon collaboration. Businesses must automate these collaborative processes in order to achieve greater productivity. Likewise, government agencies, educational institutions, and non-profit organizations are looking to Web-based collaboration to increase efficiency and expand horizons.

The ultimate purpose for a Web Service is to facilitate such collaborations; in order for a Web Service to fully represent the role of a participant in these collaborations and to properly grant the required level of interoperability, many layers of capabilities need to be addressed.

Whilst a process or collaboration modeling language may support full definition of roles, responsibilities, contracts, artifacts, state management and state transitions, the goal of WSCI is to present the interface that a given Web Service exhibits in such a complex scenario, when it is called to cover one or more roles.

Thus, when used in a collaboration context, the objective of WSCI is to unambiguously describe the choreography of message exchanges that involve a specific Web Service covering one (or more) role(s) in such collaboration. Each Web Service is considered a peer in the collaboration and, as such, exhibits its own interface as part of the collaboration.

1.6.4 Relationship to Workflow

WSCI is not a "workflow description language"; it is envisaged that this role will be covered by some other specification that would properly address the description of collaborative processes.

WSCI can describe the observable behavior of a Web Service interacting with a workflow; as well, it can describe the observable behavior of a system that implements a workflow (or which behaves as such).

WSCI does not address the definition of the behavior required by a Web Service when it needs to coordinate its own activities with the activities performed by other Web Services; but it can describe the observable behavior of a Web Service behaving as such.

Thus, in a model describing the way in which multiple participants interact, WSCI addresses the description of the "boundaries" for each participant.

1.7 Simple Example

The example presented in Section 5, taken from the well-known Travel Reservation System use case, describes the use of most of the WSCI features in the context of a real-life example.

In order to familiarize the reader with key WSCI artifacts, a subset of the full example is presented here. This subset does not account for all the modeling possibilities offered by WSCI but is simple enough to show its power. Section 3 provides a more thorough description of how additional WSCI features can be used to better model the overall scenario and to arrive to the full-fledged model described in Section 5's example.

1.7.1 Scope

The following example illustrates, in the scope of a real life use case, how WSCI models the following concepts:

• The Action, the basic construct of WSCI, and its binding to some WSDL operation

• How multiple actions are choreographed in a simple sequence

• How groups of actions can be grouped in a process which represents an identifiable (and reusable) behavior exhibited by the Web Service

• The use of Correlation to describe how messages exchanged within a choreography are related

• How to define the WSCI interface of a Web Service

1.7.2 Simple scenario

The scenario describes the basic behavior that is exposed by a Web Service implementing the functionalities of a Travel Agent in a Travel Reservation System; this scenario will be enhanced in Section 5 to better reflect the real-life use case and to show the use of the majority of the WSCI language features.

In this scenario, the Travel Agent only interacts with a Traveler according to a very simplified choreography:

1. A Traveler can order a trip with the Travel Agent

2. Some time later, the Traveler confirms the previous order

3. The Travel Agent bills the Traveler for the trip

The goal is to show how WSCI enhances the model provided by WSDL.

1.7.3 The static definition

Here is a representation of the Travel Agent Web Service as provided by a static definition language, such as WSDL.

<? xml version = "1.0" ?>
<definitions name = "Travel Agent Static Interface"
   targetNamespace = "http://example.com/consumer/TravelAgent"
   xmlns:xsd = "http://www.w3.org/2000/10/XMLSchema"
   xmlns:tns = "http://example.com/consumer/TravelAgent"
   xmlns = "http://schemas.xmlsoap.org/wsdl/">

   <types>
     <schema xmlns = "http://www.w3.org/2000/10/XMLSchema">

<!-- ************************************************************* -->
<!-- ****************** COMPLEX TYPES ************************** -->
<!-- ************************************************************* -->
        <complexType name = "Traveler">
        <sequence>
          <element name = "name" type = "xsd:string" />
          <element name = "travelerID" type = "xsd:string" />
        </sequence>
        </complexType>

        <complexType name = "trip">
        <sequence>
          <element name = "itineraryID" type = "xsd:string" />
          <element name = "startDate" type = "date" />
          <element name = "startCity" type = "xsd:string" />
          <element name = "arrivalDate" type = "date" />
          <element name = "destinationAirport"
               type = "xsd:string"/>
          <element name = "numberOfSeats"
               type = "nonNegativeInteger"/>
          <element name = "preferredCarrier"
               type = "xsd:string" />
          <element name = "comments" type = "xsd:string" />
        </sequence>
        </complexType>

        <complexType name = "proposedItinerary">
        <sequence>
          <element name = "itineraryID" type = "xsd:string" />
          <element name = "startTime" type = "timeInstant" />
          <element name = "startAirport" type = "xsd:string" />
          <element name = "destinationTime"
               type = "timeInstant" />
          <element name = "destinationAirport"
               type = "xsd:string" />
          <element name = "carrier" type = "xsd:string" />
          <element name = "availability" type = "boolean" />
          <element name = "totalCost" type = "float" />
          <element name = "validityDeadline"
               type = "timeInstant" />
        </sequence>
        </complexType>

        <complexType name = "statement">
        <sequence>
          <element name = "bookingID" type = "xsd:string" />
          <element name = "creditCard" type = "tns:CCInfo" />
          <element name = "date" type = "date" />
          <element name = "amount" type = "float"/>
          <element name = "transactionID" type = "xsd:string"/>
        </sequence>
        </complexType>

        <complexType name = "CCInfo">
        <sequence>
          <element name = "number" type = "xsd:string" />
          <element name = "issuer" type = "xsd:string" />
          <element name = "expiryDate" type = "month" />
        </sequence>
        </complexType>
     </schema>
   </types>

<!-- ************************************************************* -->
<!-- ****************** MESSAGES ******************************* -->
<!-- ************************************************************* -->
   <message name = "tripOrderRequest">
     <part name = "traveler" type = "tns:traveler"/>
     <part name = "trip" type = "tns:trip"/>
   </message>

   <message name = "tripOrderAcknowledgement">
     <part name = "proposedItinerary" type = "tns:proposedItinerary"/>
   </message>

   <message name = "bookingRequest">
     <part   name = "itineraryID" type = "xsd:string"/>
   </message>

   <message name = "bookingConfirmation">
     <part   name = "bookingID" type = "xsd:string"/>
     <part   name = "status" type = "xsd:string"/>
   </message>

   <message name = "statement">
     <part   name = "bookingID" type = "xsd:string"/>
     <part   name = "body" type = "tns:statement"/>
   </message>

<-- ************************************************************** -->
<-- *************TRAVEL AGENT PORT TYPES ************************* -->
<-- ************************************************************** -->
   <portType name = "TAtoTraveler">
     <documentation>
        This port type references the operations the Travel Agent
        performs with the Traveler service
     </documentation>

     <operation name = "OrderTrip">
        <input message = "tns:tripOrderRequest"/>
        <output message = "tns:tripOrderAcknowledgement"/>
     </operation>

     <operation name = "bookTickets">
        <input message = "tns:bookingRequest"/>
        <output message = "tns:bookingConfirmation"/>
     </operation>

     <operation name = "SendStatement">
        <output message = "tns:statement"/>
     </operation>
   </portType>
</definitions>

1.7.4 What is missing

From the previous example, it is clear that a static interface, whilst able to capture important information about the atomic operations that are performed by the Travel Agent Web Service, is not enough to cope with:

• Choreography aspects.
  The WSDL definition does not describe how to interpret a set of operations happening in a given order; in this example, it is not clear if all the 3 operations supported by the Travel Agent Web Service should happen (and in which order) in order for a Traveler to complete the reservation of a trip.

• Correlation aspects.
  Even if exposing the basic choreography of the supported operations, it is not possible to describe which information allow the Travel Agent Web Service to associate a confirmation request with a previously submitted trip request.

Other important behavioral elements that are introduced in the following sections include:

• Transactions.
  The WSDL definitions of the Travel Agent Web Service does not describe if the Web Service operations are performed in a transactional way. It may be important for the Traveler to know that a trip request would be logically rolled back in case of any error happening during the process.

• Possible Choices.
  In real life, the Travel Agent Web Service may be able to choose the execution of different actions based on some information that can be carried in the message exchange:

  • The Web Service may be able to accept a Confirmation request or a Cancellation request and it will react accordingly. In this case the choice is based on the type of the incoming message.

  • The Web Service may be able to send either a Bill or a Notification that the trip cannot be confirmed based on the validity of the Credit Card info provided by the Traveler or based on the availability of the trip as communicated by the Airline Reservation system.

1.7.5 The WSCI definition

The following code example shows how the previous WSDL static interface can be enriched using WSCI concepts.

<? xml version = "1.0" ?>
<definitions name = "Travel Agent Dynamic Interface"
   targetNamespace = "http://example.com/consumer/TravelAgent"
   xmlns:xsd = "http://www.w3.org/2000/10/XMLSchema"
   xmlns:tns = "http://example.com/consumer/TravelAgent"
   xmlns = "http://www.w3.org/TR/2002/wsci10">                    1.

   <!-- WSDL complex types -->                                    2.
   <!-- WSDL message definitions -->
   <!-- WSDL operations and port types -->
   <!—- selectors -->

   <correlation name = "itineraryCorrelation"                     3.
            property = "tns:itineraryID">
   </correlation>

   <interface name = "TravelAgent">                               4.
     <process name = "PlanAndBookTrip"                            5.
          instantiation = "message">                              6.

        <sequence>                                                7.
        <action name = "ReceiveTripOrder"                         8.
            role = "tns:TravelAgent"                              9.
            operation = "tns:TAtoTraveler/OrderTrip">            10.
        </action>

        <action name = "ReceiveConfirmation"                     11.
            role = "tns:TravelAgent"
            operation = "tns:TAtoTraveler/bookTickets">
           <correlate correlation="tns:itineraryCorrelation"/>   12.

          <call process = "tns:BookSeats" />                     13.
        </action>

        <action name = "SendStatement"                           14.
            role = "tns:TravelAgent"
            operation = "tns:TAtoTraveler/SendStatement"/>
        </action>
        </sequence>
     </process>

     <process name = "BookSeats" instantiation = "other">        15.
        <action name = "bookSeats"
           role = "tns:TravelAgent"
           operation = "tns:TAtoAirline/bookSeats">
        </action>
     </process>
   </interface>
</wsdl:definitions>

The important information that the WSCI interface provides on top of the static WSDL interface:

1. The WSCI interface definition is embedded inside the wsdl:definitions element; it does not require a root element nor does it require to be written in a separate file. The reason for this choice is explained in Section 3.1.2.

2. The standard WSDL definitions for types, messages, operations and portTypes as seen in the previous code example (see Section 1.7.3) apply.

3. The itineraryCorrelation definition indicates that messages carrying the same itineraryID refer to the same trip; this will help the implementation of the Web Service to properly manage concurrent executions of the same message exchange (from the same or different users).

4. The interface element is the WSCI container; it is designed to contain all the WSCI process definitions that describe the dynamic behavior of the Web Service in the context of a given message exchange (in our case, the Travel Reservation System process).

   Each WSCI interface has a name to properly distinguish multiple interfaces exposed by the same Web Service.

5. The PlanAndBookTrip process models the observable behavior of the Travel Agent Web Service in the context of the Travel Reservation System process; thus it describes how the Travel Agent Web Service behaves in that context.

   The PlanAndBookTrip is the image of the Travel Reservation System process as seen by the Travel Agent Web Service.

   The process element is, in WSCI, the basic unit of re-use; thus an interface can only contain process definitions.

6. The process is qualified with the "instantiation=message" attribute. This means that the execution of the process will be triggered as soon as the first action referred to by the process is ready. In this case, the PlanAndBookTrip process will be triggered when the tripOrderRequest message is received by the Travel Agent Web Service (this is the consume message referenced by the OrderTrip operation).

7. The sequence construct indicates that the 3 WSCI actions are executed sequentially.

   According to this, the Web Service highlights that the 3 WSDL operations associated with the 3 WSCI actions cannot happen just in any order but that the Travel Agent Web Service can engage in the Travel Reservation System process (PlanAndBookTrip) only by performing the 3 actions in the correct order.

8. The action is the basic WSCI construct; it identifies a unit of work associated with a given operation.

   Here, the WSCI interface describes that the Travel Agent executes the OrderTrip operation whilst performing the ReceiveTripOrder action.

9. A WSCI interface can describe the observable behavior of a Web Service in the context of a given message exchange. The Web Service can represent more than one logical role in such exchange; the "role=travelAgent" attribute specifies that the ReceiveTripOrder action is executed on behalf of the travelAgent role.

10. The operation attribute associates the WSCI action with a WSDL operation as specified by the WSDL definitions. Via this operation, it will be possible to determine the type of the operation (1-way or 2-way), the messages that are actually exchanged and the bindings.

11. The ReceiveConfirmation is the second action in the sequence; after accepting a trip order from the Traveler, the Travel Agent Web Service is able to accept a confirmation for the booking.

    This means that if the Travel Agent Web Service receives another tripOrderRequest message, a new instance of the same process is created instead than continuing the current one.

12. It is important to be able to correlate the ReceiveConfirmation action with the ReceiveTripOrder action that could have happened long time before; this is done via the reference to the itineraryCorrelation correlation.

    In this example, if the value of the itineraryID field carried by the BookingRequest message is the same as the itineraryID field carried by the previous tripOrderRequest message, then the ReceiveConfirmation action is part of an already established conversation (the one that was previously started when the ReceiveTripOrder action was executed).

    The itineraryCorrelation is implicitly instantiated when the ReceiveTripOrder action is executed.

13. The BookSeats process is called as part of the WSCI action. This means that the actions defined by the BookSeats process are executed between the consume and the produce parts of the bookTickets operation.

    The use of the call construct allows re-use of process definitions.

14. The SendStatement action does not require a Correlation since it references a produce operation.

15. The BookSeats process is defined with "instantiation=other". This means that this process will never be instantiated by the reception of a triggering message but can only be instantiated when explicitly invoked.

    This process is not described in detail since it references the relations between the Travel Agent and the Airline Reservation system.

1.7.6 Benefits

The simple WSCI example shown before highlights how WSCI can help the Web Service architect and programmer.

• The architect of the Travel Agent Web Service can provide the WSCI definition of the service, along with the static definition. The WSCI definition is precise enough to describe the behavior of the Travel Agent Web Service when used inside the Ticket Reservation System process.

  This may become part of a standard worksheet associated with the Web Service.

• Anyone interested in interacting with the Travel Agent Web Service knows its expected behavior. A programmer that is interested in building a software agent for the Traveler can use the Travel Agent Web Service WSCI definition to properly build it. The WSCI definition allows the client programmer to clearly understand how to interact with the Travel Agent Web Service.

• The WSCI interface could also be of help for the programmer of the Travel Agent Web Service itself.

  Sometimes WSCI can be used to describe the observable behavior of an existing Web Service; sometimes it can be used to define how a newly created Web Service should behave. In the latter case, the server programmer could use the WSCI definition to build the communication layer on the top of some legacy code that implements the basic functionalities of the Travel Agent service.

1.8 Notational Conventions

1.8.1 Keywords

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC 2119].

1.8.2 Namespaces

The following namespace prefixes are used throughout this document:

1.8.3 Informal Syntax

The definition of each WSCI element is given in XML-like grammar using the monospace typeface. The definition of an element is shown with the element name enclosed in angle brackets.

Required attributes appear in bold typeface. Where the attribute type has an enumerated type definition, the values are shown as separated by vertical bars. Where the attribute type is given by a simple type definition, the type definition name from either XSD or the WSCI schema is used. Where the attribute is optional and has a default value, it is shown following a colon.

Support for extension attributes is shown by {extension attribute}. Where used in the grammar, it indicates support for any number of attributes defined in a namespace other than the WSCI namespace.

The allowed content of WSCI elements is shown using a simple grammar:

• An element name is used for any content part that must be an element of that type

• A name enclosed in curly braces and appearing in italic typeface refers to content parts of some other type. For example, {any activity} refers to any element that defines an activity.

• Support for extension elements is shown by {extension element}. Where used in the grammar, the content part may be any element defined in a namespace other than the WSCI namespace.

• Support for mixed content is shown by {mixed}. Where used in the grammar, the allowed content is a mix of character data and of elements defined in any namespace.

• The cardinality of any content part is specified using the operators "?" (zero or one), "*" (zero or more) and "+" (one or more). If no operator is used, the content part must appear exactly once. Cardinality that cannot be expressed using either operator is shown using curly braces, with the minimum and maximum values separated by comma, e.g. "{2,*}" denotes two or more.

• Content parts may be grouped together using parentheses "( )" to form a new content part. A choice group consists of all consecutive content parts, separated by a vertical line "|". A sequence group consists of all consecutive content parts that are separated by a comma ",".

XSD schemas are provided as a formal definition of WSCI grammar (see WSCI Schema, Section 8.4).

2. Language Overview

This section introduces the main modeling concepts underlying the WSCI interface and the WSCI model definitions as well as the extensibility features of the WSCI language.

2.1 Concepts

The following concepts are part of the underlying model:

• Interface
• Activities and choreography of activities
• Processes and units of reuse
• Properties
• Context
• Message correlation
• Exceptions
• Transactions and compensation activities
• Global model

2.1.1 Interface

WSCI aims to describe how Web Services participate in choreographed, long-lasting and stateful message exchanges. More precisely, WSCI aims to describe the externally observable behavior of a Web Service in such a message exchange. The focus of the described behavior is on the temporal and logical dependencies among the messages the Web Service exchanges with one or more other services in the context of a given scenario. WSCI maps this description to the notion of an interface.

The details of the behavior of the Web Service are described in the processes that are contained in the interface. Usually, an interface contains at least one process whose execution can be initiated by the receipt of a message. This indicates that the service will not proactively perform the behavior described in that process, but instead will wait until triggered by the respective message.

A Web Service may expose multiple interfaces for supporting multiple scenarios. In this sense, each interface describes how a Web Service is perceived to behave in the context of a particular scenario. A Web Service may also expose multiple interfaces for supporting different views of the behavior of the service in a single scenario. Such a view might, for instance, show only the interactions of the service with one specific client, thus allowing the client to fully understand how to interact with the service in that scenario.

2.1.2 Activities and their choreography

WSCI describes the behavior of a Web service in terms of choreographed activities. Activities may be atomic or complex, i.e. recursively composed of other activities. Choreography describes temporal and/or logical dependencies among activities.

Atomic activities represent the basic unit of behavior of a Web service, such as sending and/or receiving a message, or waiting for a specified amount of time. They are termed atomic because any observer of the Web service cannot observe intermediate states during their execution. Atomic activities dealing with messages correspond to the execution of operations defined in static service definition languages such as WSDL.

Complex activities are recursively composed of other activities; ultimately, each complex activity is composed of actions. Each complex activity defines a specific kind of choreography for the activities it is composed of. WSCI supports the definition of the following kinds of choreographies:

• Sequential execution: The activities must be executed in sequential order.

• Parallel execution: All activities must be executed, but they may be executed in any order.

• Looping: The activities are repeatedly executed based on the evaluation of a condition or an expression. WSCI supports for-each, while, and repeat-until style loops.

• Conditional execution: One out of several sets of activities is executed based on the evaluation of conditions (switch) or based on the occurrence of an event (choice).

2.1.3 Processes

A process is a portion of behavior that is labeled with a name. The behavior described by a process can be reused by referencing its name. As such, the process is the WSCI unit of reuse.

The way in which a process is used (or re-used) is by properly instantiating it. A process can be instantiated by:

• Receipt of one or more messages that are defined as triggering the choreography described by the process.

• Calling or spawning the process (see below). The respective Call or Spawn statements are explicitly shown in the interface.

• Instantiating the process from within the service implementation. In this case, the actual instantiation of the process is not shown in the interface.

In each of the above cases, the Web Service needs to be in a state where instantiating the process is allowed. Whether or not a process can be instantiated also differs on the type of the process. WSCI allows the definition of two types of processes:

• Top-level processes: These processes are defined at the interface level and can be referenced from everywhere within the interface.

• Nested processes: These processes are defined within complex activities. A nested process can be referenced only from within the complex activity that defines it.

A process can be referenced using a Call or a Spawn statement:

• The process is called: The behavior contained in the process will be executed, while the call waits for the called process to complete. This is very similar to calling a subroutine in a programming language.

• The process is spawned: The behavior contained in the process will be executed in a parallel thread of control. The parallel thread can later be joined again.

The ability to call processes introduces the concept of reuse into WSCI. The ability to spawn/join processes introduces the concept of parallel execution of activities into WSCI.

2.1.4 Properties

Properties are introduced in WSCI as a modeling artifact used to reference a "value" within the interface definition. They are the equivalent of variables in other languages. The concept of properties, though, provides an additional layer of abstraction in WSCI. This layer eliminates dependencies between the interface definition and abstract message definitions (such as those defined by WSDL). Additionally, it allows referencing values instantiated by the service implementation.

Properties can be used to avoid, within the interface definition, explicit references to abstract messages (or message parts) described in a service definition language (such as WSDL). This is accomplished in two ways:

• For each incoming or outgoing message there is a property with the same value as the message content and with the same name as the abstract message name. The property is instantiated upon the receipt of the incoming message or the construction of the outgoing message, respectively. It has the same data structure as the abstract message.

• A property may holda value obtained applying an expression to a part of an incoming message. The value of that property is obtained from any incoming message that includes the particular message part. The service should behave as if the value of the property is derived every time the service receives a message containing the specific message part. WSCI introduces the selector element (see Section 3.2 for more details), which defines how the value of a property is obtained from an incoming message.

Properties may also be used to reference a value that is instantiated by the service implementation and could be used in the interface definition. Such properties are useful for specifying abstract conditions for loops and branches in message choreographies.

Accordingly, properties can be used as:

• An abstraction of the message itself;
• A reference to a value established from a message part upon receipt of a message;
• A reference to a value established by the service itself upon instantiation.

A property is defined as a name-value pair. The name must be unique among all properties defined in the same scope. Properties do not need to be explicitly defined in order to be used. Consequently, their values are not explicitly restricted to any data type. WSCI does not prescribe any type system and values of properties may be of any data type. Properties are visible in the context in which they are instantiated including all its parent contexts, unless they are defined as local properties to that context.

Properties do not have to map to any concrete artifact implemented by the service; they are just a modeling artifact for WSCI and can be used whenever the description of the external behavior of the service requires referencing to "named objects". For this reason, a precise algebra for properties has not been specified.

2.1.5 Context

Context is a WSCI concept that describes the environment in which a set of activities is executed. Each context definition pertains to a particular set of activities, and each activity is defined in exactly one context definition. The context definition for top-level processes, when not present, is assumed to be empty. The context definition describes the environment for the set of activities it pertains to in terms of:

• The set of declarations that are available to the activities;

• The set of exceptional events that might occur during the execution of the activities, and the exceptional behavior triggered by those events;

• The transactional properties associated with the execution of the activities.

A context definition may contain two different kinds of declarations: local properties, and local process definitions.

• Local properties are only available to the activities executing in this context.

• Local process definitions designate exactly those processes that may be instantiated in this context. A local process can only be called or spawned from a context where the definition of the local process is visible (see the scoping rules for nested contexts below). Called/spawned processes execute in the context where they are defined.

Context definitions may be nested to an arbitrary level. The scoping rule for nested contexts specifies that contexts see "outward" but neither "inward" nor "sideward". This means that an activity can refer to all local declarations defined in its own context and, recursively, in all of its parent contexts; this is referred to as the execution context for that activity. An activity cannot refer to local declarations defined in other contexts. Local declarations override local declarations with the same name in parent contexts.

Web Services may implement the concept of context in many different ways; WSCI does not prescribe nor encourage any particular such implementation, but aims to describe in a neutral way how the presence of context affects the observable behavior of the Web Service.

2.1.6 Message correlation

In WSCI, a conversation represents a message exchange between two or more services participating in a particular scenario. A service can be engaged in multiple conversations at the same time, with the same or with different services. The concept of correlation describes how conversations are structured and which properties must be exchanged to retain the semantic consistency of the conversation. A correlation is not limited to a single conversation between two participants; it can span multiple conversations between different participants.

In the example presented in Section 5, a traveler exchanges messages with the travel agent. Initially the traveler will submit a chosen trip to the travel agent. The travel agent will, as response, return an itinerary. After that the traveler has a choice to change the proposed itinerary or make the reservation. This conversation between the traveler and the travel agent will be extended over a period of time.

The travel agent can enter into many conversations with the same traveler. For example, the traveler can send multiple requests for creating different itineraries for different trips. A request to change a proposed itinerary sent from the traveler to the travel agent need to be associated with a particular conversation – one that deals with the specific itinerary. For each new trip a new conversation is initiated. Each conversation is related to a particular trip request. For each trip request the travel agent will return a unique itinerary identification number, which the traveler must use in all subsequent messages related to the proposed itinerary (e.g. change the proposed itinerary or make the reservation).

In the example, we assume that the travel agent will contact the same airline company for each leg of the journey. Generally, it is possible that for different legs of the same journey a travel agent contacts different airline companies. In this case the travel agent engages in multiple conversations with different airline companies. These multiple conversations are considered as part of the larger conversation that relates to a single trip request. These (sub)conversations are distinguished by the itinerary identification number and the leg identification number.

Correlation is the mechanism by which a message received by the service is associated with a particular conversation. Different conversations can be distinguished by correlation instances. The correlation instance is a set of properties' values. Each message that belongs to a conversation must be designated by a particular correlation instance. The correlation properties are communicated as part of messages exchanged in the actions.

The service may implement the way in which it actually correlates messages belonging to the same logical conversations in multiple ways. WSCI aims to model this mechanism as seen from outside and it does not prescribe any implementation.

2.1.7 Exceptional behavior

WSCI allows declaring exceptional behavior that is exhibited by a Web Service at a given point in a choreography. The declaration of exceptional behavior is part of the context definition, and associates exceptions with a set of activities that the Web Service will perform in response to those exceptions. It is possible to declare the occurrence of the following kinds of exceptions:

• Receipt of a particular message that is considered as exceptional in that context.

• Occurrence of a fault; this fault might correspond to the receipt of a WSDL fault message, or to the generation of a fault by the service itself.

• Occurrence of a timeout.

The occurrence of an exception causes the current context to be terminated after the activities associated with the exception have been performed; at this point, the behavior defined in the parent context is resumed. Thus, WSCI supports the concept of "recoverable exceptions" that do not cause the overall choreography to terminate (similar to the throw/catch concept in Java). However, the occurrence of a fault for which no exceptional behavior is defined causes the context to be terminated and the fault to be raised in the parent context. More abstractly, exception handling behavior defined in a parent context definition can act as the default behavior for all its children, and in reverse, exception handling behavior defined in a context definition can be used to override exception handling behavior defined in its parent.

Exceptions are a WSCI modeling artifact designed to model the exceptional behavior exhibited by a Web Service at a given point of a conversation; they do not need to necessarily represent any "technical failure."

2.1.8 Transactional behavior

A context may be associated with a transaction. The transaction describes, from an interface perspective, the transactional properties of the activities that are executed in this context. Basically, the presence of transaction asserts that the set of activities is executed in an all-or-nothing manner, i.e. either the context terminates with no exception, in which case the transaction completes successfully, or the context terminates with an exception, in which case the effects of the activities executed so far are assumed to be rolled back by the private implementation of the service.

A transaction may declare a set of compensation activities that will be executed if the transaction has completed successfully, but needs to be undone. Note that the compensation, being a part of the service interface, describes only the externally observable activities required to undo the transaction; compensation does not describe how, from an implementation point of view, the transaction is undone. For instance, assume that a travel agent has performed a transaction to book a hotel room for a traveler. If this booking has to be undone because there is no available flight to that location, the travel agent will probably send a notification of the un-booking to the traveler. In other words, the travel agent service describes its undoing of the "book hotel room" transaction by the compensation activity of sending the relevant notification to the traveler.

A transaction is either atomic or open-nested.

• Atomic transactions have no further inner structure. It is assumed that participants exchanging messages in the context of an atomic transaction rely on some kind of mechanism (e.g. CORBA OTS, JTS) to coordinate the outcome of the transaction, but specification of a specific such mechanism is outside the scope of WSCI. It is also outside the scope of WSCI to specify how the rollback of an atomic transaction is performed.

• Open-nested transactions are composed of other transactions, which in turn may be atomic or open-nested. If an open-nested transaction needs to be rolled back, the currently open sub transactions within the open-nested transaction are rolled back first (recursively), and after that the already completed sub transactions are compensated for in reverse order of completion.

2.1.9 Global Model

As described previously, a WSCI interface models the externally observable behavior of a particular Web Service in a choreographed, long-lasting and stateful message exchange with one or more other services; thus a WSCI interface describes the view of the overall message exchange as seen from one participant. WSCI allows also describing a multi-participant view of the overall message exchange by means of the WSCI Global Model.

The Global Model is described by a collection of interfaces of the participating services, and a collection of links between the operations of communicating services as described by a "static" service description language, such as WSDL. Links between operations indicate that the respective services will exchange messages across those links, i.e. there will be direct message flow(s) between those operations. Therefore, linked operations must be mirror images of each other.

In most scenarios, the information provided by the global model allows to derive between which actions the messages will actually flow. This allows visual modeling, analysis, validation and simulation of the overall message exchange.

The Global Model operates at the logical level of "Service Type". Since actions specify the role on behalf of which the service acts, and since each WSCI action is related to an operation, it is possible to infer the source and target roles for any action described by a WSCI interface from the operation links defined in the Global Model. This is particularly important for granting a top-down mapping from the description of the collaboration view of the overall process.

2.2 Extensibility

Two kinds of extensions of WSCI are allowed:

• Extensions introducing additional semantics that is not part of the normative WSCI specification, and

• Extensions that are used to expand the interface and the model definitions and that do not change the semantics defined in the normative WSCI specification.

There are three ways to accomplish the first type of extensions:

• By adding new types of activities (e.g. a goto construct); this is achieved by using the substitution group mechanism introduced in [XML Schema 1]. It is possible to define a new activity that uses wsci:activity as its substitution group (see Section 3.5.1 for more details about WSCI activity type). Substitution groups are not allowed in any other case.

• By extending the semantics of actions; this is achieved by means of the extensibility features for the action element (see Section 3.4.1 ). For instance, the WSCI specification describes a normative extension, which is used to identify the service against which the action is performed (see Section 6).

• By referencing a WSCI construct from within a document edited according to another specification; this is achieved by using strict naming rules that allow every process, activity, transaction and local property to be unambiguously referenced. For example, RDF can be used to annotate a WSCI interface definition with additional semantics.

The second type of extensions is accomplished supporting extensibility elements. They are used to allow other (existing or future) specifications to extend the interface definition and the model definition by adding elements and/or attributes defined in namespaces different from WSCI namespace. These extensions do not change the semantics defined in the normative WSCI specification; they are optional and must use an XML namespace different from that of WSCI. The use of extensibility elements is restricted to specific tags identified by the informal syntax used in Section 3 (the {extension element} and {extension attribute} placeholders).

An extensible WSCI element can be extended by:

• Zero or more attributes

• And/or at most one element (with the exception of the action element which may be extended by more than one element) defined in a namespace different from WSCI namespace.

The following table lists the extensible WSCI elements.

3. Language Elements

3.1 Introduction

This section describes the WSCI language in detail. We first introduce some principles and notions that apply to all or most of the language elements.

3.1.1 Terminology conventions

Most of the concepts that are introduced by WSCI (such as process, context, or transaction) have the following aspects:

• The actual WSCI syntax (the "syntactical" concept)
• The use of the syntax in an instance of the WSCI schema (the "design time" concept)
• An actual instance of the latter (the "run time" concept).

In order to distinguish these aspects precisely, a consistent terminology will be used in the remainder of this document. This terminology can be explained using the concept of process.

• The term "process construct" refers to the WSCI syntax.
• The term "process definition" refers to an occurrence of the processelement within a WSCI document.
• The term "process instance" refers to the conceptual instance of such a definition. The term "process" is used sometimes instead of "process instance."

3.1.2 The root element

The WSCI top-level definitions (the interface, selector, correlation, and model elements) are nested inside the wsdl:definitions element. This should not be understood as if WSCI extended WSDL, but as a reuse of the wsdl:definitions element due to the fact that this element is convenient and WSDL is the only specification that, as of today, defines a container with the expected semantic. WSCI does not define a wsci:definitions element, envisaging that a neutral container will be defined for all specifications acting in the Web service area.

Since WSCI reuses the wsdl:definitions and the wsdl:import elements, retaining their respective semantics, any tool needs to fully understand the syntax and semantics of these two WSDL elements in order to properly process WSCI.

3.1.3 Documentation and naming

Most of the WSCI constructs may be documented using the documentation element, and may be named using the name attribute. The semantics for these two syntax fragments will be explained here since it is the same wherever the fragments appear.

The documentation element is used to provide any kind of useful and human-readable documentation. Usually, the documentation element will contain pure text, but it may also contain elements defined in a foreign namespace. A WSCI processor will not interpret the contents of the documentation element.

The name attribute is required for correlation definitions, interface definitions, and the model element. It is optional for activity definitions, transaction definitions, fault definitions and the connect element. The value of the name attribute is a non-qualified name. It serves the purpose to reference the named entity from elsewhere. For instance, correlation definitions are referenced in the correlateelement, process definitions are referenced in the spawn or call elements, and interface definitions are referenced from within the global model.

For each of the WSCI top-level constructs (interface, model, and correlation), the names of definitions of that construct form a scope of their own. This means, for instance, that the name of a correlation definition must be unique among the names of all correlation definitions within a given namespace, but need not be different from names of interface or model definitions in the same namespace. The same holds for names of interface definitions and model definitions.

Within a process definition, WSCI only enforces name uniqueness for all local property declarations and nested process definitions within the same context definition (see also Section 3.5.4).

3.2 Selector

Selector is a mechanism to abstract a complex message into a set of properties of interest to the service interface. Each abstract message may consist of one or more logical parts associated with a data type from some type system, e.g. the XML Schema type system [XML Schema 1], [XML Schema 2]. Assuming that a message part is associated with a particular data type allows decoupling between a property and the part of the message from which the value of such property is obtained. The selector definition references a data type from some type system and not an abstract message definition thus allowing the value of a property to be obtained from any message that includes the particular message type.

New message definitions can be added without affecting a previously defined selector. Also, the message structure can be changed (e.g. a part can be excluded); still the same selector definition can be used provided that the particular message part has not been changed. In this way selectors improve reuse and eliminate dependencies on abstract message definitions. They ensure that the interface definition is more resilient to changes. The same selector can be applied to any message that contains the message part associated with the same data type that is referenced in the selector definition. Selectors should be used when a property is derived from a message part using a non-trivial expressions (e.g. sum, count) or the property value can be obtained from any message that contains the message part associated with the particular data type.

The selector definition specifies how the value of a property is obtained from an incoming message. The service should behave as if the value of a property is derived every time the service receives a message containing the specific message part.

The syntax of the selector element is:

<selector property = QName
   element = QName
   type = QName
   xpath = expression
   {extension attribute}>
   Content: (documentation?,
   {extension element}?)
</selector>

The property attribute specifies which property is instantiated (or modified) by the selector. The property is identified by its fully qualified name to allow the referencing of properties defined in any namespace.

The element and type attributes are used to specify type references. The element attribute refers to an XML Schema element using a qualified name. The type attribute refers to an XML Schema simple type or complex type using a qualified name. These two attributes are mutually exclusive and optional. If both attributes are omitted an extension attribute must be used to reference a type system. The referenced type system must be different than the XML Schema type system. Exactly one type reference must be used.

Note: XML Schema elements and types have different name scopes. It is valid to define an element with the same name as a complex type. Therefore two different attributes are defined in order to distinguish which definition is used.

The xpath attribute provides an XPath expression [XPath]that extracts a node-set from a message part in order to obtain the value for the property. This attribute is optional. If the xpath attribute is used, the content of the selector element may consist only of the documentation element. If the xpath attribute is omitted and the content of the selector element is empty or consists only of the documentation element, the complete message part is used to get the value for the named property. In this case the message part must be identified either by an XML Schema element or type definition.

The selector element is an extensible element. An extension attribute can be used to define a selector that operates on a type system other than XML Schema type system. Zero or more extension attributes may be specified. An extension element can be used to define a selector that uses expressions different from XPath expressions (e.g. XQuery expressions). The selector allows at most one extension element to be used.

If the selector element contains an extension element, the xpath attribute must be omitted. This extension declares how the value of the named property will be obtained from the message part. The message part may be identified either by an element or type from the XML Schema type system or using any other data type.

A selector definition is not limited to a specific interface definition. The selector element is a WSCI top-level element.

Example. The value of the itinerary number property can be carried in different messages. Each of these messages has a message part of either simple type itineraryID or element type itinerary. Consequently, two different selectors must be defined to obtain the value of that property. The accompanying types are provided below.

<selector property = "tns:itineraryNo"
            type = "tns:itineraryID"
            xpath = "./text()" />

<selector property = "tns:itineraryNo"
            element = "tns:itinerary"
            xpath = "./itineraryID/text()" />

<xsd:simpleType name = "itineraryID">
   <xsd:restriction base = "xsd:string" />
</xsd:simpleType>

<xsd:element name = "itinerary" type = "tns:itineraryType" />

<xsd:complexType name = "itineraryType">
   <xsd:sequence>
      <xsd:element name = "itineraryID" type = "xsd:string" />
      <xsd:element name = "leg" type = "xsd:leg"
                    minOccurs = "1" maxOccurs = "unbounded" />
   </xsd:sequence>
</xsd:complexType>

The following selector definition does not specify any expression. The complete message part of element type itinerary is used to get the value for property itinerary. This property has type itinerary.

<selector property = "tns:itinerary"
      element = "tns:itinerary"/>

The value of property legCount is calculated from any message having a message part of element type itinerary using the following selector:

<selector property = "tns:legCount"
      element = "tns:itinerary"
      xpath = "count(./leg)" />

The value of property legNo is obtained from messages, which include a message part of element type itinerary. The property contains identification numbers of all legs of a given itinerary. Complex type leg used in the definition of complex type itineraryType is provided below.

<selector property = "tns:legNo"
            element = "tns:itinerary"
            xpath = "./leg/legID" />

<xsd:complexType name = "leg">
   <xsd:sequence>
     <xsd:element name = "legID" type = "xsd:string" />
     <xsd:element name = "startTime"
                 type = "xsd:timeInstant" />
     <xsd:element name = "startAirport" type = "xsd:string" />
     <xsd:element name = "destinationTime"
                 type = "xsd:timeInstant" />
     <xsd:element name = "destinationAirport"
                 type = "xsd:string" />
     <xsd:element name = "carrier" type = "xsd:string" />
     <xsd:element name = "seat" type = "xsd:string" />
     <xsd:element name = "cost" type = "xsd:float" />
     <xsd:element name = "availability" type = "xsd:boolean" />
   </xsd:sequence>
</xsd:complexType>

3.3 Message Correlation

The correlation mechanism is a general mechanism used in WSCI to describe how a Web service distinguishes between different conversations in which it participates. An informal description of the mechanism and its usage is provided in Section 2.1.6.

WSCI defines two elements, correlation and correlate, that implement the correlation mechanism. The correlation element specifies a set of properties used for the purpose of defining the correlation identity. The correlate element (defined in Section 3.4.2) is used to associate an action with the correlation definition.

3.3.1 Correlation

The syntax of the correlation element is:

<correlation name = NCName
   property = list of QName
   extends = QName>
   Content: (documentation?)
</correlation>

The name attribute holds the name of the correlation. This name must be unique among names of correlations defined in the same namespace. It is used to reference the correlation from a correlate element. The name attribute is mandatory.

The property attribute lists all the properties forming the correlation identity and used to identify a correlation instance. At least one property must be specified and no property can be repeated twice in the same correlation definition. The properties can be listed in any order. A property is referenced using a qualified name.

A correlation can be defined as an extension of another correlation. In this case the correlation is a specialization of the extended correlation. It includes all properties that are part of the base (extended) correlation and adds one or more new properties. The base correlation is specified using the extends attribute. Additional properties are specified using the property attribute. The extends attribute is optional.

A correlation definition is not limited to a specific interface definition. The correlation element is a WSCI top-level definition.

Example. Two correlations are illustrated in this example: itineraryCorrelation and legCorrelation. The former correlation is based on the itinerary number property. The latter presents an extension of correlation itineraryCorrelation and is used to identify the conversation related to a specific leg of the itinerary. The legCorrelation correlation includes property itineraryNo that is part of the base correlation and adds one more property (i.e. the legNo property).

<correlation name = "itineraryCorrelation"
            property = "tns:itineraryNo" />
<correlation name = "legCorrelation"
            property = "tns:legNo"
            extends = "tns:itineraryCorrelation" />

3.4 Atomic behavior

3.4.1 Action

An action is an atomic activity that describes the manner in which the service uses an elementary operation in a context, in particular one involving the exchange of messages with other services.

 <action
   name = NCName
   operation = QName/NCName
   role = QName
   {any attribute with non-WSCI namespace}>
   Content: (documentation?,correlate*,call?,
            {any element with non-WSCI namespace}*)
 </action>

When the action performs an operation defined by WSDL it uses the operation attribute. This attribute names the WSDL operation that is performed by the action. The WSDL definition is referenced using the fully qualified name of the port type definition and the non-qualified name of the operation definition:

@operation =: portTypeName'/'operationName
portTypeName =: QName
operationName =: NCName

For example, the value "tns:traveler/findItinerary" refers to the WSCI operation "findItinerary" that is part of the port type definition " traveler" that is defined in the same namespace as the WSCI interface.

An action can be associated with one of the following types of WSDL operations:

• One-way: The action performed by the service receives a message. A correlation should be used to associate the input message with the context in which the action occurs.

• Request-response: The action performed by the service receives a message and sends a response back to the sender. A correlation should be used to associate the input message with the context in which the action occurs.

• Notification: The action performed by the service sends a message to another service. No correlation is required.

• Solicit-response: The action performed by the service sends a message to another service and waits for a response.

The role attribute associates a role name with the action. The role attribute is optional and takes the form of a fully qualified role name. The role attribute can be used to reference a role definition that is given by some other specification using the role's qualified name. An interface can perform actions on behalf of multiple roles.

3.4.1.1 Example

• The Traveler service indicates its intention to order the trip by performing the solicit-response operation OrderTrip defined as part of the port type definition tns:TravelerToTA as follows:

  <action name = "OrderTrip"
           role = "tns:Traveler"
          operation = "tns:TravelerToTA/OrderTrip"/>
  

• The Traveler service exposes the request-response operation ReserveTickets defined as part of the port type definition tns:TravelerToTA in the following way:

  <action  name = "ReserveTickets"
           role = "tns:Traveler"
           operation = "tns:TravelerToTA/ReserveTickets">
  <correlate correlation="defs:reservationCorrelation"
           instantiation= "true" />
  </action>
  

• The following action references the request-response operation ChangeItinerary that the Travel Agent service exposes and that is defined as part of the port type definition tns:TAtoTraveler. Upon receipt of the request message, the service invokes a nested process for verifying seat availability (tns:VerifySeats), and waits for it to complete before returning the response message. The request message is correlated to the instance of this process through the itineraryCorrelation.

  <action name = "ChangeItinerary"
          role = "tns:TravelAgent"
          operation = "tns:TAtoTraveler/ChangeItinerary">
    <correlate correlation="defs:itineraryCorrelation"/>
    <call process = "tns:VerifySeats"/>
  </action>
  

3.4.2 Correlating the Action Context

The correlate element is used to define a relation between an action within the interface definition and a correlation definition. The purpose of this relation is to exactly indicate which properties serve to correlate an incoming message with a particular conversation, or more formally to indicate a particular execution context in which the action should be performed.

The syntax of the correlate element is:

<correlate correlation = QName
      instantiation = (true|false):false />

The correlation attribute references a correlation using fully qualified name. That allows referencing correlations defined in namespaces different from the namespace in which the interface is defined. This attribute is mandatory.

The instantiation attribute is optional and may have either value true or false. If the attribute has value true properties forming the correlation identity will be used to identify the current execution context in all subsequent message exchanges; the properties forming the correlation identity will be instantiated in that context. If the attribute has value false (the default) the correlation properties are used to identify a previously established execution context in which the action should be performed.

An action may specify zero or more correlate elements. These elements may have different values for the instantiation attributes. If an action specifies, for instance, two correlate elements with the instantiation attributes having values false and true respectively, then:

• the first correlate element (instantiation = false) specifies the correlation whose properties serve to identify the execution context in which the action should be performed

• and the second correlate element (instantiation = true) specifies the correlation whose properties will be used to identify the same execution context in subsequent message exchanges.

An operation references a correlation whenever the message conveyed by the operation contains all the properties that form the correlation identity (as defined by the selectors that apply to such message). This applies to any WSCI action.

In order to associate an action with the proper context in which it is performed, the correlate element is used with the instantiation attribute set to false (or absent); in this case, the properties forming the correlation identity, must have been instantiated in that context before the correlation could be used in that way.

The properties forming the correlation identity can be instantiated:

• Upon the receipt of a message; this is expressed in the interface definition using the correlate element with the instantiation attribute having value true;

• By means not described by the WSCI interface; WSCI would not describe, in this cases, how the instantiation happens and each service implementation could differ; WSCI only enforces the properties qualifying the correlation and their types.

A context can be matched by means of an already established correlation only for operations that receive a message first, such as the WSDL one-way or request-response operations; the properties conveyed in the first message must be matched with properties that identify the context. The correlation identity can be conveyed, though, in any operation and individually in each message of that operation (both received and sent messages). Correlation properties can be instantiated by any operation that allows receiving of messages, such as a WSDL one-way, request-response and solicit-response operations.

The correlate element is not allowed for actions that can only send messages (such as the WSDL notification operation). An action that performs an operation that begins with sending a message followed by receiving a message (such as the WSCI solicit-response operation) may only specify the correlate element with the instantiation attribute having value true; the correlation properties, in this case, must be conveyed by the incoming message.

An action performing an operation that begins with an input message and is not correlated is used as part of the process instantiation, and in cases where all instances of the process are allowed to receive the message and there is no need to correlate the message to a specific instance, for example a broadcast message, which should be received by all process instances.

Example. This example shows a part of the behavior of the Traveler whose interface definition is completely specified in Section 5. The selected part of the behavior includes three actions: BookTickets, ReceiveTickets and ReceiveStatement. The first action performs a solicit-response operation and the last two actions perform one-way operations. In order to correlate the incoming messages (the confirmation of issued tickets and the statement) with the particular execution context (i.e. the context in which action bookTickets has been previously executed) the correlate elements are used. All three actions reference the same correlation bookingCorrelation.

The first action specifies the correlate element with the instantiation attribute having value true. Therefore the incoming message must carry values of the correlation properties and the property values are used to identify the execution context in which action bookTickets is performed in the remaining message exchanges.

 <interface name = "Traveler">

    <process name = "PlanAndBookTrip">
       …
       <action name = "bookTickets"
                  role = "tns:Traveler"
                  operation = "tns:TravelerToTA/bookTickets">
          <correlate correlation = "defs:bookingCorrelation"
                  instantiation = "true"/>
        </action>

       <all>
          <action name = "ReceiveTickets"
                  role = "tns:Traveler"
                  operation = "tns:TravelerToAirline/ReceiveTickets">
             <correlate correlation = "defs:bookingCorrelation"/>
          </action>

             <action name = "ReceiveStatement"
                   role = "tns:Traveler"
                   operation = "tns:TravelerToTA/ReceiveStatement">
             <correlate correlation = "defs:bookingCorrelation"/>
            </action>
        </all>
    </process>
 </interface>

3.4.3 Calling a process from within an action

An action that handles a request-response message exchange can perform an arbitrary set of activities before it completes by calling another process. The call element is used to indicate the activities that would occur while the action is being performed by the service.

<call
   process = NCName>
   Content: (documentation?)
</call>

An action can perform an arbitrary set of activities only if the operational semantics indicate that such activities must occur between the beginning and end of the action. The call element is allowed when performing the WSDL request-response operation, but is forbidden for all other WSDL operations.

Since an action is an atomic activity, the process is invoked and completed before the action completes. If a fault occurs while performing that process, the action will also fault.

3.4.4 Extensibility of the action element

The action element is an extensible element. The action element can refer to operations defined in a specification other than WSDL using extension attributes. Extension attributes are defined in any namespace other than WSCI. The operation attribute and extension attributes are mutually exclusive.

The action element can specify additional semantics pertaining to the operation being performed. Additional semantics are expressed using extension elements that are defined in any namespace other than WSCI.

A WSCI processor may optionally process additional semantics in one or more namespaces. The manner in which such semantics are processed is outside the scope of this specification.

This specification does include one such extension that expresses the manner in which an action can identify a peer service against which an operation is performed. This extension consists of the locate elements which are defined later on in this specification. Both elements are defined in the WSCI/locate namespace (see Section 6.1)

3.5 Choreography Description

Atomic activities are the elementary units of the interface definition. An atomic activity is one that cannot be further decomposed and is performed in an all-or-nothing manner. The most common atomic activity is action. This activity will perform a single operation, e.g. receiving a message (one-way operation) or sending a message and waiting for a reply (solicit-response operation).

Complex activities are containers for sets of activities and define rules for coordinating the order in which activities are performed from within the activity set. Unlike atomic activities, complex activities can be decomposed into atomic and complex activities.

3.5.1 Activity

Interfaces define Web Services as performing activities of varying complexity. The definition of services as performing activities enhances the definition of services as performing operations by adding the proper context in which an operation is said to occur, and allowing operations to be associated over space and time. While operations are stateless in nature, activities are stateful.

As a result the interface can define a complex behavior that can include complex interactions involving multiple operations and services, transactional behavior and exception handling, and the dynamic establishment of links across services.

Similarly, an activity may be as simple as a one-way operation performed against one other service, or as complex as multiple message exchange with a set of services.

When two or more activities perform in the same context they often use the context as a container for shared properties. The activities can establish a relation to each other by appearing to read and write properties in that context. For example, an activity that sends a message can depend on a property established from a message received by a previous activity.

Contexts are also used to distinguish between multiple instances of the same activity. An activity not only establishes its dependency on a previous activity occurring in the same context, but on a specific instance of such activity. This form of continuity allows us to define complex stateful interactions involving the exchange of multiple messages with the same or different peer services.

A context must be established before the activity is performed. For that reason the context is not defined by the activity itself but ahead of the activity definition.

3.5.2 Activity Set

Since contexts are often used to establish a relation between two or more activities, we allow a context definition to be used by a set of activities. An activity set defines a set of activities together with the context in which they execute. The syntax for an activity set is:

Content: (context?,{any activity}+)

An activity set can include any type of activity element. This includes all activities defined in this specification. In addition, activities defined in other specification can be used as long as they are defined in a namespace that is other than WSCI and use the wsci:activity abstract element as their substitution group.

Note that an activity set is not an element or a complex type, but rather a model group. It is used as part of the content of various elements, always in the form depicted above.

The context element is optional. If absent, we treat it as if the context definition as empty.

All activity elements are based on a common type definition with the syntax:

<{activity type}
   name = NCName>
   Content: (documentation?)
</{activity type}>

The optional name attribute provides the non-qualified activity name to distinguish the activity from any other activity defined in the same context. If used, the activity name must be different from any other entity defined in the same context, including other activities, properties, nested processes, etc (see Section 3.5.4 for more details about contexts).

An activity is always performed within some context. The definition of a context makes the distinctive difference between stateless operations and stateful actions. The context in which an activity is performed is referred to as the activity's current context.

3.5.3 Complex Activity

A complex activity is any activity that contains one or more activity sets. The complex activity defines the rules for determining which activity set will be performed, determining the number of times the activity set will be performed, and determining the order in which the activities will be performed from the set:

• The complex activity all operates on a single activity set and performs the activity set exactly once; the activities can be performed in non-sequential order.

• The complex activity sequence operates on a single activity set and performs the activity set exactly once in sequential order.

• The complex activity choice selects one activity set based on a triggered event, and performs that activity set exactly once in sequential order.

• The complex activity foreach operates on a single activity set and performs the activity set zero or more times, performing the activities in sequential order in each iteration.

• The complex activity switch selects one activity set based on a condition, and performs that activity set exactly once in sequential order.

3.5.4 Context

Just like activities, contexts are composed recursively. An activity is performed in the current context, as defined by the activity set in which the activity appears. When that activity set is contained in another activity, that parent activity provides a parent context. The current context encompasses the parent context and all its parent contexts recursively.

In fact, the current context is a combination of the parent context and any local declaration made in that context. A local declaration is a declaration made in the current context that hides any entity with the same name in the parent context. A local declaration can be used to confine an entity to the current context, or to hide changes that could occur in the current context from affecting any parent or sibling context.

The syntax for a context definition is:

<context>
   Content: ((process | property)*,exception?,
           transaction?)
</context>

• Property: Declaring a property as local to a context assures that any changes to the value of that property (as a result of activities occurring in that context) do not affect the value of that property in any parent context.

• Exception: Declaring an exception behavior as local to a context assures that that definition will be honored in case of an exception occurring in that context, without changing the definitions prescribed for a parent context.

• Process: Declaring a process as local to a context (also known as nested process) assures that this particular process definition is not available in the parent or sibling context, and further allows the nested process to establish a relation with any other activity or process occurring in the same context.

• Transaction: Declaring a transaction as local to a context assures that all activities occurring in that context and only these activities are performed as part of that transaction.

Properties and processes declared within a given context must use unique names. It is an error for two property declarations, process declara