ws choreography v.0-1 overview this is work-in-progress david burdett, commerce one 18 june 2003

WS Choreography v.0-1 Overview

This is work-in-progress

David Burdett, Commerce One18 June 2003

Commerce One Copyright © 20032

Topics

Feature Overview XML Structures What’s missing Issues

Feature Overview


Features Reusability

A choreography definition is reusable in different contexts with different software and different message formats

State Driven Processes or organizations that take part in choreographies maintain

their state in the choreography

Cooperative Organizations Describes how independent organizations or processes cooperate

Verifiable Choreography definition can be used to verify that a Choreography is

being followed correctly (How not yet defined)

Multi-Party The specification allows Choreography Definitions with any number of

organizations or processes involved

Modular An "import" facility allows separately define components to be

imported


Reusability

Roles Describes the type of a process/organization behavior e.g. a

Buyer or a Seller

States Identifies the point within a choreography a Role has reached

e.g. a Buyer State could be OrderSent after sending an Order

Interactions Communicating information from one Role to another for a

reason. e.g sending an Order to request a purchase of goods

Message Families The set of messages that serve the same or similar purpose. e.g

a RosettaNet Order, a UBL Order, an EDI Order, are all the same

Processes Occurs as a result of some event such as a change of State


Why Reusability is importantBig Co ($$$$$)

Medium Co ($$$)

Small Co ($)

1. Work my way or you don’t get my business!

2. OK

3. Work Big Co’s way or we can’t do business!

4. STOP!!!!I can’t afford to implement all these

ways. I’ll just continue with fax!

3a. Work Bigger Co’s way or we can’t do business!

Medium Co 23b. Work even Bigger Co’s

way or we can’t do business!

Medium Co 3

3c. Work Mega Co’s way or we can’t do business!

Medium Co 4

Developing reusable ways of doing business* that are based on common standards are a pre-requisite to bringing smaller businesses into widespread eCommerce

5. Big Co doesn’t realize the benefits of automation as they can’t extend all the way down the supply chain

*Choreography definitions are just one of the essential parts!


Legend

State Driven

SellerBuyer

Check OrderSend Order

Send Order ErrorProcess Order

Error

New OrderCreated

Order ErrorMessage Checked

OrderChecked OK

Order CheckedRejected

Order CheckedError

OrderSent

OrderReceived

Order ErrorReceived

Order ErrorSent

Interaction ProcessState


Interactions, Reliable Messagingand Signals

SellerBuyer

Check OrderSend OrderOrderSent

OrderReceived

Reliable Messaging Ack.

Message Checked OK

Message Processing Started

Message Processing Complete

Signals

Reliable Messaging

Interaction

… the other messages are implementation dependent

The Choreography definition defines just the messages that cause the state to change …


Cooperative Organizations

SellerBuyer

Check

OrderSend Order

Send Order ErrorProcess

Order Error

New OrderCreated


OrderChecked

OK


Order CheckedError

OrderSent

OrderReceived

Order ErrorReceived

Order ErrorSent

xxx

xxx

xxxxxx

xxx

The Buyer can’t control what the Seller does and vice versa …

… but they both have to agree how they will

cooperate …

Private ProcessPrivate

Process

… which means they must have a shared understanding of what

each will do!


Checking Choreography ProgressSellerBuyer

Send OrderOrderSent

OrderReceived

ERPRecordState

Choreo-graphyDefin-ition

StateDB

Shared Common Choreography Definition

CheckState

State Errors

Send Order ErrorOrder ErrorReceived

Order ErrorSent

RecordState

Choreo-graphyDefin-ition

CheckState

StateDB

ERP

State Errors


Other Features

Multi-Party Choreographies Any number of roles can take part One definition for all roles – makes sharing easier

Importing Definitions Allows reusability of individual definitions, e.g. messages, roles,

etc

Extending Choreography Definitions Allows one Choreography to extend another … perhaps should

be composition instead!

Choreography Dependencies Once choreography can only execute after another, e.g. You can

only query the state of a choreography if there is another choreography instance to query

Semantic Definitions Two ways of defining semantics: in the XML, or at a URL Multi-lingual

XML Structures

Note all attributes are required unless stated as optional


ChoreographyDefinitions in multiple languages

Import definitions from other files (works like

WSDL)

Define the roles involved

Define the Message Families

Define the Interactions

Define one or more Choreography

Definitions

The same definitions can be reused in

multiple choreographies


Choreography XML

<Choreography defaultLanguage="us-en" xmlns="..." xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ...</Choreography>

Default language for content of Description

elements


Description XML

<Description language="en-uk" ref="http://www.example.com/ChorSpecs/en-uk/OrderManagement.htm"> This section contains a set of choreographies for Order Management</Description>

Optional. If present, over-rides default

language for contentOptional. If present is URL of more detailed readable specification

Semantic definitions

Description elements can always occur zero or more times. Each occurrence

must be for a different language


Import XML

<Import namespace="http://example.com/chor/OrderManagement/Roles" location="http://example.com/chor/OrderManagement/Roles"/>

Import works in the same way as a WSDL Import


Role & State

A Role may have one or more states


Role & State XML

<Role name="Seller"> <Description>This role represents the seller of goods or services </Description> <State name="OrderReceived"/> <State name="OrderCheckedOK"/> ...</Role>

A Role name must be unique within a

choreography file

State names must also be unique within a choreography file

States can also have a Description (not shown)


Message Family

<MessageFamily name="Order"urn="http://example.com/MessageFamilies/OrderManagement/Order"> <Description>Messages in this family contain information to convey a request to purchase goods or services </Description></MessageFamily>

Message Family name must be unique within a

choreography fileURN uniquely identifies

the Message Family


Interaction Definitions

<InteractionDef name="SendOrder" fromRole="Buyer" toRole="Seller" messageFamily="Order"> <Description>Send the order From the Buyer to the Seller </Description> <InteractionEndStates fromState="OrderSent" toState="OrderReceived"/></InteractionDef>

The name of the InteractionSending

RoleReceiving

RoleWhat’s

being sent

State of the sending role after the

message is sent

State of the receiving role after the

message is received


SellerBuyer

Interaction End States

Check OrderSend OrderNew Order

CreatedOrderSent

OrderReceived

Sending Role

Receiving Role

From State

To State


Choreography DefinitionAllows one Choreography

Definition to be the extension of another

Declares a Choreography can only be followed if

another choreography has been followed first

Identifies the states that indicate the start and end of

a choreography

Defines the usage of an interaction

Defines a processInteractions and processes can

occur in any order


Choreography Definition (XML)

<ChoreographyDefinition name="OrderManagementChoreography1" urn="http://example.com/choreographies/OrderManagement1"> <Description>A simple Order Management Choreography that includes the sending of an order from a Buyer to a Seller and the Seller returning an error if a problem is found. </Description> <StartEndStates> ... </StartEndStates> <Interaction ... /> <Process ... /> ...</ChoreographyDefinition>

Unique name Unique URN

List of start and end states

List of Interactions and Processes in

any order


Start End States

A state that indicates the start of

the choreography

A state that may be a last state for a Role in

the choreography

A state that is a last state for a Role in the choreography


Start End States example

Start State

Conditional End State SellerBuyer

Check OrderSend Order

Send Order ErrorProcess Order

Error

New OrderCreated


OrderChecked OK


Order CheckedError

OrderSent

OrderReceived

Order ErrorReceived

Order ErrorSent

End State

End State

End State

End State

If the Seller finds no problems with the Order, then OrderSent is the Buyer’s final state. But if problems are found then OrderErrorMessageChecked is

the Buyer’s final state

There is one Start state, but each Role must have one or more end states

<StartEndStates> <Start state="NewOrderCreated"/> <ConditionalEnd state="OrderSent"/> <End state="OrderCheckedOK"/> <End state="OrderCheckedRejected"/> <End state="OrderErrorSent"/> <End state="OrderErrorMessageChecked"/></StartEndStates>


Interactions and Processes

A Boolean expression of states that must be true for

the Interaction to occur

A Boolean expression of states that must be true for

the Process to occur

A list of the possible end states for a process


Interaction and Process XML

<Interaction name="SendOrder"> <Description>Send the order to the seller</Description> <PreCondition condition="NewOrderCreated"/></Interaction><Process name="CheckOrder" role="Seller"> <Description>The seller checks the order.</Description> <PreCondition condition="OrderReceived"/> <ProcessEndState state="OrderCheckedOK"/> <ProcessEndState state="OrderCheckedRejected"/> <ProcessEndState state="OrderCheckedError"/></Process>

SellerBuyer

Check OrderSend OrderNew Order

Created

OrderChecked OK


Order CheckedError

OrderSent

OrderReceived

Reference to Interaction Definition

Role that executes the process


Complete Choreography Example<ChoreographyDefinition name="OrderManagementChoreography1" urn=“..."><Description>In this Choreography Definition, a Buyer sends an Order to a Seller. The Seller returns an Error Message, if the Order cannot be processed</Description> <StartEndStates> <Start state="NewOrderCreated"/> <ConditionalEnd state="OrderSent"/> <End state="OrderCheckedOK"/> <End state="OrderCheckedRejected"/> <End state="OrderErrorSent"/> <End state="OrderErrorMessageChecked"/> </StartEndStates> <Interaction name="SendOrder"> <Description>Send the order to the seller</Description> <PreCondition condition="NewOrderCreated"/> </Interaction> <Process name="CheckOrder" role="Seller"> <Description>The seller checks the order.</Description> <PreCondition condition="OrderReceived"/> <ProcessEndState state="OrderCheckedOK"/> <ProcessEndState state="OrderCheckedRejected"/> <ProcessEndState state="OrderCheckedError"/> </Process> <Interaction name="SendOrderError"> <Description>The order was in error - send an error</Description> <PreCondition condition="OrderCheckedError"/> </Interaction> <Process name="ProcessOrderErrorMessage" role="Buyer"> <Description>Buyer Processes Order Error Message</Description> <PreCondition condition="OrderErrorReceived"/> <ProcessEndState state="OrderErrorMessageChecked"/> </Process></ChoreographyDefinition>


What’s Missing from the spec Choreography Bindings to WSDL and SOAP Handling errors

e.g. Message (document) errors, Process timeouts, transmission errors, etc

Composing new choreographies out of existing choreographies Relationships to Reliable Messaging, signals and other

protocols such as BTP and WS Transaction How Imports work Detailed schema validation rules, e.g. interdependencies Guidance on how to do run-time checks that a choreography is

being correctly followed Inquiring on another role’s choreography state Recovering from a failure of the choreography

… this list is definitely not complete …


Issues

Import Should also allow imports of process definitions Handling name conflicts between imports

Roles & States “name” attributes are “ID’s”, should probably make

them unique just within their scope Roles should also be identified by a URI

Processes Should be independently defined and importable

ws choreography v.0-1 overview this is work-in-progress david burdett, commerce one 18 june 2003

Documents

order order

error order

ok order

order interactions

rejected order

ubl order

rosettanet order

edi order