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 12:25:16 UTC