RE: Internal processes and/or external choreographies

Here "observable behavior" means "message exchanges". Right ?
"Observable" also means "observable by at least two roles that are 
exchanging messages".  It doesn't mean observable to all roles.  Right ?
I think "Timeout" is an observable thing.  Basically, if you haven't 
observed message exchange happen within a time period, you have observed a 
"timeout".

Rgds, Ricky

At 09:51 AM 4/11/2003 +0100, Steve Ross-Talbot wrote:

>I'd like to echo Fred's comments. I think external is the way to go and
>if we can provide "compatibility" as a minimum and "verifiablity" as a
>nice to have we would have done a great job.
>
>The notion of "observable behaviour" and the associated "bi-simulation"
>are in essence how we should approach the issue of verfiability. We want
>to ensure that "contracually" the external behaviour defined (allowable
>message patterns over given states) is the observably equivalent to any
>implementation. It doesn't matter if the implemetation is done over
>BPML, Java, BPEL or even by people. If we can observe it as equivalent
>then we can say it bi-simulates the externally defined behaviour and so
>meets the contract.
>
>One issue I am less sure on is the issue of time. If observable
>behaviour is allowable message patterns over given states, what role
>does time play in all of this? Does it have a role? Thoughts .....
>
>Cheers
>
>Steve T
>
>-----Original Message-----
>From: public-ws-chor-request@w3.org
>[mailto:public-ws-chor-request@w3.org] On Behalf Of Cummins, Fred A
>Sent: 11 April 2003 03:43
>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:
>Ev ents and States ...
>
>
>
>David,
>
>My view is that the scope should be external only, but for now that
>should be the same as external first.  There may be many implementations
>of a choreography with diverse processes as appropriate to the
>particular processes.  Consequently, there must be a clear separation
>between external and internal, and the same choreography should be
>suitable for designing the various internal implementations that marry
>to it.
>
>I will be useful for tools to be able to validate the compatibility of
>an internal process with a choreography (but not necessary). In any
>event, the choreography should be specified such that this compatibility
>can be determined, hopefully in a straightforward manner.
>
>Essentially, a participant must send a message when in an
>external state that calls for it to send a message, and the message must
>be such that it will cause the recipient to transition to the state
>desired by the sender based on the choreography.  A participant has no
>control over the other participant(s) except through sending an
>appropriate message--it cannot control what the other participant sends,
>when it is sent, or if it is sent at all.
>
>I suggest that the proper actions of a participant can be defined by its
>public state machine.  Typically, each state will have two or more exit
>transitions that depend on what is sent or received. The selection of
>the exit transitions is made by the message sender (unless there is an
>error or time-out which may be viewed as a third message/transition
>type).
>
>So an internal process can be validated against the participant's public
>state machine specification.
>
>Fred
>
> > -----Original Message-----
> > From: Burdett, David [mailto:david.burdett@commerceone.com]
> > Sent: Thursday, April 10, 2003 9: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.
> > >
> > >
> >
>
>This email is confidential and may be protected by legal privilege. If
>you are not the intended recipient,  please do not copy or disclose its
>content but  delete the email and contact the sender immediately. Whilst
>we run antivirus software on all internet emails we are not liable for
>any loss or damage. The recipient is advised to run their own antivirus
>software.
>
>
>
>This email is confidential and may be protected by legal privilege. If you 
>are not the intended recipient,  please do not copy or disclose its 
>content but  delete the email and contact the sender immediately. Whilst 
>we run antivirus software on all internet emails we are not liable for any 
>loss or damage. The recipient is advised to run their own antivirus software.

Received on Friday, 11 April 2003 13:14:09 UTC