This article will be exploring the relationship between the WS-CDL choreography description language, defined by W3C and implemented by the pi4soa open source project, and the Scribble protocol notation.

The various areas that need to be discussed are listed below. The structure is based on the sections within the WS-CDL specification.

Collaborating Participants

This section of the WS-CDL specification covers the definitions of Role Types, Relationship Types, Participant Types and Channel Types.

WS-CDL defines interactions between role types, with those Role Types being 'implemented' by Participant Types. One way of looking at this is that the Participant Types simply represent a grouping of behaviours.

In Scribble, we just have a single concept (at the moment) of Participant. This is equivalent to the WS-CDL Role Type. Therefore Participant Types (in the WS-CDL sense) are outside the scope of a Scribble protocol description.

In the pi4soa tools, we also introduced the concept of Participant instances. This was to enable two 'participants' of the same type to potentially interact, as well as being able to pass different instances into the same sub-choreography.

Scribble is more closely aligned with concept of Participant instances in the pi4soa version of WS-CDL.

Relationship Types are not necessary to be able to describe the source and destination participants.

WS-CDL requires channels and channel types to be explicitly defined and specified with each interaction. Scribble currently does not support channels. There only use is to distinguish between two different sources sending messages concurrently to the same participant. Their other purpose is in support of channel passing, but this is currently not used widely - and WS-CDL has issues in this area related to passing identify information with the channel.

Scribble limitations:

1) Does not support channel types or channels, although this may be added in future versions of Scribble.

Information Driven Collaborations

Information Type

Scribble and WS-CDL both require the use of Types to define what message types are being exchanged.

In WS-CDL, the abstract types (i.e. Information Types) are generally associated with XML schema types.

The import statements in Scribble have recently been updated to enable the specification of concrete type bindings.

Variables

QUESTION: Are variables going to be defined in Scribble?

Variables are not currently supported - and even in discussions about assertions and commitments they have not be used in examples. So it is not likely in the medium term that variables will be supported.

Expressions

QUESTION: Are expressions going to be defined? If so, are they going to be defined using assertions?

Expressions will be supported as part of the assertions layer, but no standard notation has been agreed yet.

Token/TokenLocator

Scribble limitations:

1) Scribble does not support an identify mechanism currently. One possible approach would be to define the identity related to messages on the protocol. Need to consider how best to support (translate from) WS-CDL and BPMN2. Identity information does not necessarily need to be defined explicitly in the language - it could be associated with the relevant entities in the object model, so only used between different parts of the tool chain, but not persisted.

Choreography

The WS-CDL choreography unit (i.e. the definition of a unit of behaviour) and the Scribble protocol unit are similar in nature.

They both have a 'root' definition, which represents the top level behavioural unit, and they both can define sub-definitions (which are discussed in more detail in the section on Composition.

However WS-CDL allows choreography units to also be defined at the top level, along side (but not contained within) the 'root' choreography unit. This is not supported by Scribble.

WS-CDL choreography unit also enables a 'completion condition' to be defined. If this condition becomes true, during the life of the choreography, then it will immediately complete.

Scribble limitations:

1) Choeography completion may not be supported. Depending on how the 'try/catch/interupt' concept develops, it is possible that an expression could be defined to trigger an interrupt, which could be defined at the top most level within the protocol (representing the choreography unit).

Workunit

The semantics of the WS-CDL workunit construct have been explained in terms of three capabilities:

Repetition

The WS-CDL workunit has the ability to define whether the guard condition should be re-evaluated (i.e. repeated). For this situation, the Scribble 'repetition' construct would be equivalent.

In more general terms, the 're-evaluation' attribute is simply an expression, and therefore could represent more than a simple boolean 'true' value (i.e. unconditional return to evaluate the primary condition).

Scribble limitations:

1) If the repetition based workunit defines anything other than a boolean 'true()' value, then the construct will not be able to be translated into a Scribble repeat construct.

Conditional

This construct represents an optional block of interaction behaviour. If the guard condition evaluates to false, then the interaction behaviour defined within the scope of the conditional construct will be ignored.

WS-CDL and Scribble both have this as a common construct.

When

The 'when' construct blocks progress until a condition becomes true. From an endpoint execution perspective, this could be considered internal implementation detail that does not need to be reflected in the externally observable behaviour, and is therefore not required from a monitorability perspective.

Therefore, for now, we will ignore this concept, and just interpret the interaction behaviour within the body of the 'when' construct.

Scribble limitations:

1) Delay represented by the 'when' will not be monitorable.

Choreography Exception Handling

There are three aspects to exception handling:

a) Raising an exception - in WS-CDL this is achieved through attributes on 'copy' and 'record details' elements, rather than an explicit raise activity

b) Catching an exception - in WS-CDL, each choreography unit can define a set of exception handlers against exception types, optionally with a 'default' exception handler that is a catch all.

c) Propagation of unhandled exceptions - in WS-CDL, if an exception is not caught by the choreography unit's exception handlers (i.e. if no exception handler matches the thrown exception type and does not have default exception handler), then the exception is propagated to the choreography unit that called the choreography that is dealing with the exception - i.e. it is thrown further up the call stack.

When a choreography unit experiences an exception, all activities within the scope of the choreography unit are terminated before any exception handler is invoked.

In Scribble protocol notation, the notion of exception handling is still being discussed.

QUESTION: Should we include an informal notion of exception handling for now, to enable this common business (and programming) pattern to be described in a Scribble protocol?

QUESTION: Feel that this mechanism should also be used to handle implicit 'interrupt' situations, whether based on a timer or predicate condition that is met?

Scribble limitations:

1) Scribble protocol notation needs (atleast an informal) representation for describing exception handling.

Choreography Finalization

Finalisation is discussed in more detail in the section 'Finalizing a Choreography' further down the page.

However in general the interaction behaviour of a finalizer handler can be described using a sub-protocol defined as a sibling of the choreography's sub-protocol that is being finalised. Because of the nature of the finalizer handlers, they can only be associated with sub-choreographies (as they need to be finalised by a parent choreography), therefore the root choreography would not have any finalizer handlers.

The main limitation with Scribble translation is that in WS-CDL, the finalizer handler has access to the state information of the choreography unit being finalized. Having the finalizer handler defined as a separate sub-protocol (along side the sub-protocol representing the choreography unit being finalized) means they will not be sharing the same state information. Therefore validation may be required to indicate that any reference to the state information from the finalizer handler will not be supported - and therefore not be usable in a monitor.

Scribble limitations:

1) Finalizer handler translated into Scribble protocol unit cannot have access to state information associated with the protocol unit representing the choreography being finalized.

Activities

Ordering Structures

Sequence

Sequence is the same in WS-CDL and Scribble. Within a particular scope, a list of activities will be performed in the order they are defined.

Parallel

WS-CDL has a Parallel construct that defines a set of paths that will be performed concurrently. This construct expects each path to complete before proceeding with activities that follow the Parallel construct.

Scribble now supports a 'par' parallel construct equivalent to the one in WS-CDL, so this should be a straightforward mapping.

Choice

WS-CDL provides a Choice construct that defines a set of mutually exclusive paths that may be followed. A path must be selected, and only when it has completed will any activities following the Choice construct be performed.

In Scribble, there is currently a 'bi-party' choice construct. This means that each path must be associated with an interaction begins at one participant and is destined for a common destination participant. This restriction should not be a problem for many usecases, and makes type checking a protocol much simplier.

QUESTION: Is the multiparty choice going to be included for informal use?

Scribble limitations:

1) Multi-party choice may only be informally supports - i.e. type checking may not deal with this initially.

2) Currently the bi-party choice needs the interaction associated with each path, and all subsequent interactions that are triggered by those paths to other participants, to be defined within the scope of a protocol unit. This is so that the nature of the interactions to the participants in each path can be analysed for each protocol unit, without having to infer interactions that may be defined in other protocol units. This is primarily to overcome an issue where a protocol may be type checked and be considered valid, but then the external protocol unit 'run' by the validated protocol unit is changed, so that it is no longer valid. It is easier to ensure that each protocol unit is internally consistent. This restriction may need to be assessed in the future if it is too restrictive, espectially when dealing with internally defined sub-rotocol units.

Interacting

The WS-CDL interaction activity has the following functionality:

a) it can be used to define a Message Exchange Pattern, so a request, optional response and optional list of faults

b) the exchanges can specify an option source/target variable for the message(s) being exchanged

c) exceptions can be raised as a result of the messages being sent and/or received

d) additional 'record details' can be scheduled store information from a sent/received message or on timeout

e) a timeout can be defined associated with the interaction, that can be used to trigger a 'record details', which can optionally raise an exception.

As you can see, the interaction activity is heavily overloaded. However these capabilities can be decomposed into individual Scribble protocol activities (in most cases), for example:

(a) The  exchange details can be translated into individual interaction activities in the protocol

(b) Currently variables are not associated with the interactions

(c) The ability to raise an exception could be generated/projected to the appropriate participants - once a suitable 'raise' activity has been defined in the protocol notation.

(d) Record details are simply assignments, which will be discussed separately - along with the exceptions they may raise.

(e) Timeout - this is potentially a mechanism that may be part of Scribble protocol's try/catch/interrupt mechanism.

QUESTION: Raise notation?

Scribble limitations:

1) Interactions are not associated with source or target variables for the message content.

2) Timeout handling to be clarified.

3) Assignment to be clarified.

4) Raising exceptions to be clarified.

Composing Choreographies

WS-CDL composes choreography units using the 'Perform' activity. The initial choreography unit that is activated is the 'root' choreography, which is a top level choreography unit with the 'root' attribute set to 'true'. This choreography unit can then 'Perform' any choreography units that it directly contains, or that have been defined at the top level (along side the 'root' choreography).

QUESTION: Should we enable more than just contained sub-protocols to be run?

WS-CDL Perform activity can perform a choreography unit synhronously or asynchronously. If synchronous, then the subsequent activities following perform will not permitted until the performed choreography unit has completed. If asychronous, then any interaction behaviour defined within the performed choreography unit can occur concurrently with behaviour defined following the perform activity.

QUESTION: Async 'run' - should this be a variation of run, or simply a 'run' contained within a 'split'? We therefore would need to formally/informally define a 'split' and therefore possibly 'merge' construct in Scribble.

The WS-CDL Perform activity enables variables (and participant instances in the pi4soa CDL version) to be bound better the performing and performed choreography units, allowing values to be shared.

In Scribble protocol, there is also a binding concept that can be used to map participants from the calling to called protocol unit. When variables are supported, the same mechanism will probably be used. In Scribble protocols, there are no role or participant types. So any participant will be explicitly defined in the top level protocol unit, and bound when running a sub-protocol.

Scribble limitations:

1) Can only 'run' a sub-protocol - so top level choreography units may need to be replicated as sub-protocols in the locations in which they occur.

2) Async 'run' may or may not be supported - needs to be clarified.

Assigning Variables

Scribble limitations:

1) Currently not supported in protocol notation.

Finalizing a Choreography

Finalizing a choreography is used to perform additional interactional behaviour, on the basis that the associated choreography unit has completed successfully.

One approach to generate this to Scribble would be to create a second sub-protocol, along side the sub-protocol representing the choreography unit being finalized, that will be called in place of the 'finalize' activity. However this has the drawbacks listed below in (2), which can be partially overcome by translating the 'finalize' activity into a Scribble Conditional activity that contains a Scribble Run activity to optionally invoke the interaction behaviour associated with the finalizer handler.

Scribble limitations:

1) The scribble protocol unit representing the finalizer will not have access to the same state associated with the original choreography unit

2) The finalizer is only supposed to be invoked if the associated choreography unit completed successfully. So it is possible that the finalizer will have no effect. However, if the translation of the finalizer is simply as another sub-protocol unit that is 'run', then the behaviour associated with that sub-protocol unit will be expected to occur (from a monitorability perspective), regardless of whether the 'associated choreography' protocol unit completed successfully. Wrapping the 'run' that represents the finalise command in a Conditional activity will help, as this indicates that the interaction behaviour in the finalised sub-protocol may or may not occur - however the monitor would not be able to determine if this finaliser interaction behaviour was occurred correctly.

3) The ability to use a finalize as a means to block, waiting for the concurrently performed sub-choreography to complete, will not be supported.