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

is this the glue I alluded to or something slightly different?

Martin.

> -----Original Message-----
> From: public-ws-chor-request@w3.org 
> [mailto:public-ws-chor-request@w3.org] On Behalf Of 
> Jean-Jacques Dubray
> Sent: Friday, April 11, 2003 9:18 AM
> To: steve@enigmatec.net; 'Cummins, Fred A'; 'Burdett, David'; 
> '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 ...
> 
> 
> 
> Has anyone given some consideration about the 3 levels (2 
> levels of choreography and one of orchestration) I have 
> proposed during my presentation at the f2f meeting? Jon had 
> initiated some discussion on the list that seemed to be positive.
> 
> IMHO, ws-chor could easily address the first two levels 
> (which are in no way addressed by BPEL or BPML). One big 
> requirement I see for ws-chor is firewall transparency, in 
> other words, I can define a choreography between services and 
> then decide where I put the firewall (over time, I could also 
> move the firewall by outsourcing some services, or even 
> better based on the parties that are implementing a given 
> role in the ws-chor it could be either invoking an external 
> service or an internal service). Those situations are very 
> common in the PLM space where some design teams are located 
> at suppliers, but other than that these teams act exactly 
> like the internal design teams. I am sure that there are 
> cases outside the PLM space that can benefit from that. In 
> particular, I contend that implementing these two levels are 
> necessary for multi-party choreographies.
> 
> Now to respond specifically to Assaf on how hard it is to 
> create an implementation of an external choreography, I have 
> written in the past an algorithm that takes a choreography 
> specification (defined in ebXML
> BPSS) and creates an orchestration definition that can 
> complies with it. At this point, you can add internal 
> activities in between the activities that are external touch 
> points. This was very easy to do, and I'd be happy to open 
> source such algorithm once the ws-chor specification is 
> stable. However, and ultimately you may never be guaranteed 
> that the internal unit of work will perform as intended from 
> a timing and timeout perspective (your system could be slow 
> or down). This is why one need a special component managing 
> the ws-choreography instances to make sure they comply with 
> the specification (you really don't want to spread that code 
> in the service implementations since you would need to change 
> that code each time the choreography definition changes or 
> spread the choreography instance management across all the 
> services that participate in this choreography).
> 
> Cheers,
> 
> Jean-Jacques 
>  
>  
> 
> >>-----Original Message-----
> >>From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]
> >>On Behalf Of Steve Ross-Talbot
> >>Sent: Friday, April 11, 2003 4:51 AM
> >>To: 'Cummins, Fred A'; 'Burdett, David'; '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 ...
> >>
> >>
> >>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:45:46 UTC