RE: Internal processes and/or external choreographies (was RE: Ev ents and States ...

I've just read all of this rapidly expanding thread but wanted to really
reply to this earlier email from Martin.

I agree with Martin that we have:
1. External choreography definitions that imply a shared state machine
between multiple roles
2. Internal process definitions that define a process that is not shared and
is executed by one role, and
3. Glue that binds the internal end external together.

Now let's think about implementation for a moment as I think the way you
probably want to implement the internal and external is different ...

INTERNAL DEFINITIONS
These definitions can be executed much like a programming language where
there is an engine that decides once one step in the process is complete
what the next step should be and then invokes it, i.e. it can be a
turing-complete language.

EXTERNAL DEFINITIONS
These definitions are used to validate that the observable behavior is as
expected. For example, when a message arrives, it is checked that it is
valid to receive a message at this point in the choreography. There is no
engine that can execute the next step in the choreography, you can only flag
problems as they arise.

Bottom line, Internal Definitions can (should?) be used in an *active way*
to control a process, whereas External Definitions are used in a *passive
way* to check that the behavior of others beyond your control is correct.

As these are *so* different, do we think we can have one choreography
definition language that can be used for both?

I don't think so.

Thoughts?

David


-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Friday, April 11, 2003 9:43 AM
To: 'Burdett, David'; 'Cummins, Fred A'; 'Assaf Arkin'
Cc: jdart@tibco.com; public-ws-chor@w3.org
Subject: RE: Internal processes and/or external choreographies (was RE:
Events and States ...


Maybe the answer is staring us in the face:

When we talk about external definitions we seem to be implying a shared
state machine. There is a common understanding between all parties about
who is playing what role, what states each role can  get into, the
(shared) state of the process itself etc. [is this what is commonly
called a global model?]

On the other hand an internal defintion seems to define a state machine
that is not shared  (tho may or may not be visible i.e. could be black
box or white box). So what states you need, what tranistions you make,
how you name other parties is totally private.

Obviously the two have to be glued together at some point.
As a group we have to decide whether we are working on shared state
machines vs priavte ones, or both. In all case we will have to look at
the "glue" requirements.

Martin.

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of Burdett, David
> Sent: Thursday, April 10, 2003 6:42 PM
> To: 'Cummins, Fred A'; Assaf Arkin; Burdett, David
> Cc: 'jdart@tibco.com'; public-ws-chor@w3.org
> Subject: Internal processes and/or external choreographies 
> (was RE: Events and States ...
> 
> 
> 
> Thanks ... but one thing we haven't nailed down yet is the 
> extent to which the scope of this group covers definition of 
> languages to define internal process definitions (as in WSCI 
> and BPEL4WS) as well as external choreographies. I have been 
> focusing on the latter but we need to be clear what we are 
> doing about the former.
> 
> For example we could have the following as requirements for 
> internal process definitions ...
> 
> "An internal process definition MUST be capable of defining 
> the sequence and rules by which software is executed within a 
> 'Control Domain' " ... Control domain has been 
> defined/described/discussed earlier.
> 
> "An internal process definition MUST be capable of 
> identifying the relationships and dependencies it has on an 
> external choreography definition."
> 
> .. I am sure there are more, like internal process 
> definitions being Turing complete ...
> 
> Any thoughts chairs?
> 
> David
> 
> -----Original Message-----
> From: Cummins, Fred A [mailto:fred.cummins@eds.com]
> Sent: Thursday, April 10, 2003 5:38 PM
> To: Assaf Arkin; Burdett, David
> Cc: 'jdart@tibco.com'; public-ws-chor@w3.org
> Subject: RE: Events and States (was: timeouts & states (was: 
> Abstract Bind able Choreography))
> 
> 
> David,
> 
> I'm not sure why I haven't received your message directly, 
> but I like your linkage of state machine to process 
> functionality. This provides a clean separation of the 
> external choreography from the internal process.  We can then 
> focus on how messages are exchanged between participants 
> according to the state 
> transitions of their public state machines.
> 
> Fred
> 
> > -----Original Message-----
> > From: Assaf Arkin [mailto:arkin@intalio.com]
> > Sent: Thursday, April 10, 2003 7:17 PM
> > To: Burdett, David
> > Cc: 'jdart@tibco.com'; Cummins, Fred A; public-ws-chor@w3.org
> > Subject: Re: Events and States (was: timeouts & states 
> (was: Abstract 
> > Bind able Choreography))
> > 
> > 
> > +1
> > 
> > arkin
> > 
> > Burdett, David wrote:
> > 
> > > >>>Very good questions. But what do you want (or perhaps more
> > > importantly,
> > > need) it to do? As you say, a state machine is really a
> > mechanism. What
> > > is the functional requirement?<<<
> > >
> > > I would put the functional requirements for which state
> > machines are a
> > > possible answer as follows:
> > >
> > > "An implementation of a process that is following a
> > choreography MUST
> > > be able to verify that the choreography is being followed
> > correctly as
> > > specified in the choreography definition."
> > >
> > > I would then have two further more closely defined but related
> > > requirements of the products of this group ...
> > >
> > > "A choreography definition should be usable at Design Time
> > to validate
> > > that a process should be capable of carrying out a choreography
> > > correctly as specified."
> > >
> > > "A choreography definition shoule be usable at Run Time 
> to validate
> > > that a process is executing a choreography correctly as 
> specified".
> > >
> > > ... and finally one more ...
> > >
> > > "If a process detects that a choreography is not being followed
> > > correctly, then the process SHOULD be able to use the 
> choreography 
> > > definition to identify exactly what went wrong."
> > >
> > > This last one means that you stand a better chance of 
> being able to
> > > fix the problem when it occurs.
> > >
> > > Thoughts?
> > >
> > > David
> > >
> > >
> > > -----Original Message-----
> > > From: Jon Dart [mailto:jdart@tibco.com]
> > > Sent: Thursday, April 10, 2003 2:56 PM
> > > To: Cummins Fred A
> > > Cc: public-ws-chor@w3.org
> > > Subject: Re: Events and States (was: timeouts & states
> > (was: Abstract
> > > Bindable Choreography))
> > >
> > >
> > >
> > > Cummins, Fred A wrote:
> > > > This raises questions about the scope of a choreography.
> > When does
> > > > it end?  When a disconnect occurs?  When a particular business 
> > > > transaction is completed?  When a relationship is terminated? 
> > > > Maybe any of the above?
> > > >
> > > > Do the state machines provide the mechanism for nesting
> > of component
> > > > choreographies?
> > >
> > > Very good questions. But what do you want (or perhaps more
> > importantly,
> > > need) it to do? As you say, a state machine is really a
> > mechanism. What
> > > is the functional requirement?
> > >
> > > At minimum, I would guess it is the ability to transition
> > to a distinct
> > > state when a timeout occurs. This state could be the
> > termination of the
> > > choreography (implying no more processing will occur). Or
> > it could be an
> > > error state (implying there might be some warning given, or some 
> > > recovery effort made, e.g. a retry - this assumes you are
> > doing this at
> > > the application level and not in some lower-level 
> reliable messaging 
> > > protocol). Certainly I can think of real-world examples
> > where you'd need
> > > this functionality. This is something of a simplification 
> of earlier 
> > > proposals. If we need something more complex, I'd like to 
> see some 
> > > rationale behind it.
> > >
> > > --Jon
> > >
> > 
> > 
> > --
> > "Those who can, do; those who can't, make screenshots"
> > 
> > 
> ----------------------------------------------------------------------
> > Assaf Arkin                                          
> arkin@intalio.com
> > Intalio Inc.                                           
> www.intalio.com
> > The Business Process Management Company     
>             (650) 577 4700
> > 
> > 
> > This message is intended only for the use of the Addressee and may 
> > contain information that is PRIVILEGED and CONFIDENTIAL. If you are 
> > not the intended recipient, dissemination of this communication is 
> > prohibited. If you have received this communication in 
> error, please 
> > erase all copies of the message and its attachments and notify us 
> > immediately.
> > 
> > 
> 
>