|
|
|
|
The charter |
|
The landscape |
|
Formal models |
|
Users |
|
Inputs |
|
Issues |
|
|
|
|
|
|
|
|
|
|
|
Deliverables |
|
A requirements document, including a description
of the factorization of the choreography space. |
|
Usage scenarios. |
|
One of more specifications of choreography
language(s) and its XML Schema. |
|
A primer. |
|
A test suite. |
|
|
|
Focus is on process external description |
|
|
|
|
|
|
|
|
Composition features |
|
Recursive composition model. |
|
Definition of the choreography's externally
observable behavior. |
|
Ability to represent stateful choreographies. |
|
Definition of the identity of an instance of an
execution of a choreography. |
|
Life-cycle management |
|
Message exchange interactions between Web
services |
|
Behavior definitions |
|
Scoping rules. |
|
Activities. |
|
Associations |
|
Roles based on Web service use. |
|
Linkages between Web services. |
|
References to Web services. |
|
Message exchanges |
|
Conversations - correlated message exchanges
that define interactions between Web services. |
|
Correlations and their life cycle management. |
|
Correlation relationships with choreography
instances and state. |
|
State Management |
|
Definition, manipulation, and query
capabilities. |
|
|
|
|
|
|
|
Are you confused by all the 'business process choreography'
specifications out there? |
|
|
|
I am confused 64% |
|
No, BPEL4WS wins 22% |
|
BEA & Sun's WSCI 3% |
|
bpmi.org's BPML 6% |
|
OASIS BTP 0% |
|
Other 6% |
|
|
|
http://www.webservices.org/index.php/poll/result/33? |
|
|
|
|
|
Workflow |
|
Declarative modelling |
|
The Web |
|
Distribution |
|
Links and naming |
|
|
|
|
|
|
BPEL4WS is proprietary |
|
IBM and Microsoft are not here |
|
Open |
|
W3C rules and regs |
|
|
|
|
|
Why formal models? |
|
Unambiguous |
|
Deadlock free |
|
Livelock free |
|
Behavioural equivalence |
|
Petri Nets |
|
Process Algebras (The pi-calculus) |
|
Questions: |
|
Is one better than the other? |
|
Can we have more than one? |
|
Visibility and inclusion? |
|
|
|
|
|
|
|
Users know their own business |
|
This is ultimately for users |
|
Business and technical requirements from users |
|
Different users |
|
fast changing vs slow changing |
|
complex vs simple |
|
|
|
|
|
|
|
Is WSCI enough? |
|
If it isn’t then what does it lack? |
|
What do we understand by the term
conversation?
What do we understands by the term choreography? |
|
What do we mean by the term orchestration? |
|
What role does Semantic Web technology play
here? |
|
Ontologies of process to help query services |
|
Enriching documents based on process |
|
Is this something we should care about now? |
|
WSD and SOAP |
|
Implied patterns for communication (message
exchange or MEPs) |
|
If we have a generic language to describe these
patterns/MEPs is this enough? |
|
|
|
|
|
What is choreography about |
|
Private implementation? |
|
Public service description? |
|
Both? |
|
|
|
“Process external description” suggests it is
public service description. |
|
|
|
|
|
If it is about process external description then
what can we do with process external descriptions? |
|
Is it all about compatibility checks? |
|
I can connect this to that without any problems
in semantics or syntax. |
|
Does this make it query driven over the
description? |
|
What level of expressiveness is required to
support this? |
|
General bi-simulations are not decidable? |
|
Do transactions have a role in a public service description? |
|
|
|
|
If choreography is all about private
implementations what distinguishes it from a programming language? |
|
|
|
How is public service description related to
private implementation in such a way that private implementation can be
verified against public description? Is this where bi-simulations come into
play? |
|
|
|
|
|
|
|
|
Separating the external conversations (e.g. B2B)
from internal workflows. Should they be separate? |
|
Naming things vs public vs private |
|
|
|
|
|
|
Is simplicity better achieved by basing the choreography
language on the same abstract model as proposed by the WSA? |
|
|
|
Can we conceive a fairly simple language for
doing for composition and long-running transactions? |
|
|
|
|
BPM is the scope, and in BPM, a lot more happens
than in narrower definitions of B2B? |
|
Is BPM too narrow? What about process control? |
|
Formal models |
|
|
|
|
|
|
|
|
A conversation may involve more than one
participant |
|
Conversation rules usually allow participants to
join and leave |
|
A conversation may range over multiple
participants but involve only a subset at any sub-conversation |
|
A participation in one conversation could be
identical to a participation in another conversation |
|
Negotiating a script is also a conversation, so
a conversation that leads to a conversation needs to be described |
|