W3C home > Mailing lists > Public > public-ws-chor@w3.org > April 2003

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

From: Burdett, David <david.burdett@commerceone.com>
Date: Thu, 10 Apr 2003 18:41:35 -0700
Message-ID: <C1E0143CD365A445A4417083BF6F42CC053D1973@C1plenaexm07.commerceone.com>
To: "'Cummins, Fred A'" <fred.cummins@eds.com>, Assaf Arkin <arkin@intalio.com>, "Burdett, David" <david.burdett@commerceone.com>
Cc: "'jdart@tibco.com'" <jdart@tibco.com>, public-ws-chor@w3.org

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.
> 
> 
Received on Thursday, 10 April 2003 21:41:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC