Re: Choreography State Definition (was: RE: More requirement

David:

personally, I think that the abstraction should be defined at the MEP level.
Each MEP could be defined by a series of message exchanges, signals exchange
and meaningful state. Then, MEPs could be instantiated in particular
contexts (e.g. Process Purchase Order) with specific messages, signals and
states. Otherwise, it is too expensive to do this work for each MEP
instance.

Now that being said, I thing we might also go too far in the abstraction. As
I said, what you really care about, is to have the information that a given
message was "processed" or if this information does not get back to you
there is a timeout that occurs. The fundamental difference between a message
and a signal is that a signal has a fixed structure so there is no way for
the receiver of the message to not understand it. All you need is RM to know
whether or not the signal goes there. If we start wondering of the syntax of
the signal, we might need to ack the ack.

A good enough solution is a protocol as follows:
Send Message ->
                       <- Send Signal "Message successfully processed" or
"Message not processed"

If no signal is received within a certain period of time, via RM, we both
know that a timeout has occured. With this simple protocol, two states can
be derived (MEP successful or failed). Note that this protocol is optional,
and if an MEP instance is bound to occur in a short time, you might not need
it (when it takes the same time to create the response or the signal). We
have to remember that RM also includes exchanging signals so we don't want
to overload the network.

Now the question of choreography state definition comes on top of the
protocol, you could say that for each message of an MEP instance I can
derive if this message exchange was successful or failed and associate a
"state" to it. Then the choreography could depend on these states. You could
define some global states as combination of the individual states. I think
this is what you are suggesting.

I don't have time to follow the WSDL 1.2 discussion and what an MEP is or
isn't, but, IMHO, an MEP should really be a template that provides place
holders for message interchanges. It should say the "initiator" of the MEP
sends one message, then the "other" party sends a message to the "initiator"
and so on. Some of the message formats could be fixed (e.g. a signal), but
most messages will be specified when someone creates an MEP instance. In
that case, it specifies that this message is a PO and this other one is an
AckPO. In a choreography definition we would then "use" an MEP instance and
specify who is the initiating and the responding role. That way a given MEP
instance could be used in any direction. This is particularly useful for MEP
instances that can be used indifferently by one role or another (e.g. Change
Order MEP instance).


JJ-

----- Original Message -----
From: "Burdett, David" <david.burdett@commerceone.com>
To: "Jean-Jacques Dubray" <jjd@eigner.com>; "Burdett, David"
<david.burdett@commerceone.com>; "'Yaron Y. Goland'" <ygoland@bea.com>
Cc: "'WS Chor Public'" <public-ws-chor@w3.org>
Sent: Wednesday, June 25, 2003 2:05 AM
Subject: RE: Choreography State Definition (was: RE: More requirement


> JJ
>
> I agree that "you need signals to make sure that things are going as
> planned", and you want a "fairly generic mnechanism to do it".
>
> However I don't think that you want to specify either message formats and
> perhaps not even the choreography protocol.
>
> For example in the Choreography spec draft I wrote that we discussed in
the
> F2F last week, I defined an interaction as follows ...
>
> <InteractionDef name="SendOrder" fromRole="Buyer" toRole="Seller"
> messageFamily="Order">
>   <InteractionEndStates fromState="OrderSent" toState="OrderReceived"/>
> </InteractionDef>
>
> Where "OrderSent" is the state of the Buyer after the Buyer has sent the
> Order and "OrderReceived" is the state of the Seller once the Seller has
> received the Order.
>
> You could then extend this definition as follows for several additional
> types of state ...
>
> <InteractionDef name="SendOrder" fromRole="Buyer" toRole="Seller"
> messageFamily="Order">
>   <InteractionEndStates fromState="OrderSent" toState="OrderReceived"
>    transmissionFailureState="OrderTransmissionFailure"
>    messageDeliveredState="OrderMessageDelivered"
>    deliveryFailureState="OrderDeliveryFailure"
>    validationFailureState="OrderValidationFailure"
>    checkedOKState="OrderCheckedOKState"
>    processingStartedState="OrderProcessingStarted"
>    processingCompletedState="OrderProcessingCompleted"
>    signalFailureState="OrderSignalFailure"
> />
> </InteractionDef>
>
> Where each of the additional states have the following semantics ...
>    transmissionFailureState - the message could not be sent at all, for
> example no transport
>    messageDeliveredState - confirmatio of delivery of the message has been
> received - this is what RM provides
>    deliveryFailureState - the message was sent but no confirmation of
> delivery was available - i.e. no ack was ever received although the
message
> might have got there
>    validationFailureState - the message was validated but there were
errors
>    checkedOKState - the message was validated and no errors were found.
Note
> the processing of the message may not have started
>    processingStartedState - processing of the message has started - but is
> not yet complete
>    processingCompletedState - the processing of the message is complete -
> although no response to the message may have been generated, perhaps
because
> there isn't any
>    signalFailureState - indicates that an expected signal message was not
> received when anticipated - this would need to additionally specify what
> signal was not received
>
> I think it unlikely that all these additional states would be used
together
> although it is definitely possible. It also allows for different
technology
> to be used. For example:
> 1. Either a "two phase commit" protocol or a "reliable messaging" protocol
> could be used to guarantee that the message was delivered, and
> 2. Different message content and delivery mechanisms for the messages that
> indicate the additional states.
>
> If you go to the trouble of defining the additional states, then you could
> then include in the choreography additional interactions that could occur
> that are triggered by the existence of these additional states. This, IMO,
> could be a very powerful way of specifying a very robust protocol that can
> handle many exception conditions in a way that is appropriate to the
> specific problem being solved.
>
> Thoughts?
>
> David
>
>
> -----Original Message-----
> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
> Sent: Tuesday, June 24, 2003 9:40 PM
> To: Burdett, David; 'Yaron Y. Goland'
> Cc: 'WS Chor Public'
> Subject: Re: Choreography State Definition (was: RE: More requirement
>
>
> David:
>
> you are absolutely right, unless we can use a "shared" memory space, it is
> impossible to guarantee an absolute state synchronization mechanism at a
> reasonable cost (we don't want to ack the acks !! and so on).
>
> The question is then is it necessary to have more than RM ? and would it
be
> lest cost to the users to use a choreography protocol on top of RM than
> using nothing?
>
> I would tend to think that a choreography protocol is needed because:
> 1) once two party exchange important messages with a large latency between
> them, you need "signals" to make sure that things are going as planed, as
I
> said, you can't ever be 100% sure of what the state is. However, you want
> either a NAK to come back to tell you that something went wrong, or a
short
> timeout on the ACK (not the subsequent messages) so that you don't have to
> wait on the time out of the response to discover that something went
wrong.
> It is exactly like factory automation system, you just sent a new setpoint
> to your production equipment, you either get an ack/nak or it timeouts. In
> each case, you know what to do. Imagine if you had sent the setpoint, and
> the only feedback you get is looking at what is coming out !!
>
> 2) you want to offer a fairly generic mechanism to do that to avoid
> choreography designers to re-invent the wheel. They can always do it by
the
> way, but a great service would be to declaratively specify whether and how
a
> protocol is used, as opposed to specific messages embedded in the
> choreography definition itself.
>
> JJ-
>
>
> ----- Original Message -----
> From: "Burdett, David" <david.burdett@commerceone.com>
> To: "Jean-Jacques Dubray" <jjd@eigner.com>; "'Yaron Y. Goland'"
> <ygoland@bea.com>
> Cc: "'WS Chor Public'" <public-ws-chor@w3.org>
> Sent: Tuesday, June 24, 2003 11:24 AM
> Subject: Choreography State Definition (was: RE: More requirement
>
>
> > JJ
> >
> > I agree with you that a) a choreography is a state machine, and b) the
> > exchange of messages changes the state.
> >
> > However, I don't beleive it is possible for the parties involved in a
> > choreography to know the *full* state of a choreography at any point in
> time
> > because of a) the finite time it takes for a message to be sent, and b)
> > sometimes a message may not be delivered.
> >
> > For example if a Buyer sends an order to a Supplier, then the sequence
of
> > states would be something like:
> > 1. Initial states: Buyer: idle, Supplier: idle
> > 2. Buyer sends the order. States: Buyer, Order Sent; Supplier, Idle
> > 3. Supplier receives the order. States: Buyer, Order Sent; Supplier,
Order
> > Received
> > 4. Buyer sends an acknowledgement. States: Buyer, Order Sent; Supplier,
> > Order Ack Sent
> > 5. Buyer receives the ack. States: Buyer, Order Ack Received; Supplier,
> > Order Ack Sent
> >
> > Even in the last case, the Supplier doesn't really know the state of the
> > Buyer as the Supplier does not know if the ack was received. Similarly,
if
> > one of the messages doesn't get through, e.g. the original order
message,
> > then they Buyer has no way of knowing what the state of the Supplier is
> with
> > the choreography as illustrated above.
> >
> > I tend think that state belongs to an individual role rather than the
> > choreography as a whole and so would propose the folowing "Choreography
> > State Definition" ...
> >
> > "The state of a choreography instance at a point in time is defined as
the
> > combination of the states of the individual roles that are participating
> in
> > that choreography instance at that time".
> >
> > Since communication between roles can't be instantaneous, it also means
> that
> > the actual state of a complete choreography is actually unknowable
whilst
> > the choreography is in progress. Only when the choreography is halted
> (i.e.
> > the states can't change) and queries made of each role to discover their
> > state can the full state of the choreography be discovered. This is also
> one
> > reason why I think that enabling "state queries" is important as you
will
> > often need to know the full state of the complete choreography to
> determine
> > what to do if you want to recover after a failure to execute a
> choreography
> > successfully.
> >
> > Thoughts?
> >
> > David
> >
> >
> >
> > -----Original Message-----
> > From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
> > Sent: Wednesday, June 18, 2003 5:40 AM
> > To: 'Yaron Y. Goland'
> > Cc: 'WS Chor Public'
> > Subject: RE: More requirement
> >
> >
> >
> > If two parties believe that the choreography is in a different state,
> > one can have many surprises about the outcome of this choreography. A
> > choreography is a state machine (in the mathematical sense) and as such
> > is always in a given state. The language must be unambiguous about the
> > different state. It is merely the exchange of a message that changes the
> > state of the choreography. However, it is a very peculiar state machine,
> > since it has no run-time associated with it that keeps ITS state.  Its
> > state is rather "spread" over n parties, which are all represented by
> > their individual state machines participating in the choreography. As
> > you can imagine if these state machines gets out of synch only the most
> > catastrophic results can be expected.
> >
> > Cheers,
> >
> > Jean-Jacques Dubray____________________
> > Chief Architect
> > Eigner  Precision Lifecycle Management
> > 200 Fifth Avenue
> > Waltham, MA 02451
> > 781-472-6317
> > jjd@eigner.com
> > www.eigner.com
> >
> >
> >
> > >>-----Original Message-----
> > >>From: Yaron Y. Goland [mailto:ygoland@bea.com]
> > >>Sent: Dienstag, 17. Juni 2003 13:05
> > >>To: Jean-Jacques Dubray; 'WS Chor Public'
> > >>Subject: RE: More requirement
> > >>
> > >>I have to admit that the term 'choreography state synchronization
> > >>mechanism'
> > >>makes me really nervous only because it is so broad that it could
> > >>potentially mean anything. But let's adopt your proposed new language
> > >>anyway
> > >>and when we do the full requirements review we can do a pass to look
> > for
> > >>phrases such as that one and make sure they are used in a consistent
> > and
> > >>well defined manner throughout the requirements.
> > >>
> > >> Yaron
> > >>
> > >>> -----Original Message-----
> > >>> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
> > >>> Sent: Wednesday, June 11, 2003 12:44 PM
> > >>> To: 'Yaron Y. Goland'; 'Jean-Jacques Dubray'; 'WS Chor Public'
> > >>> Subject: RE: More requirement
> > >>>
> > >>>
> > >>> Yaron:
> > >>>
> > >>> >>
> > >>> >>BPSS has chosen one of a number of possible MEPs and each MEP has
> > its
> > >>> own
> > >>> >>benefits and drawbacks that I don't believe this group needs to
> > >>> address.
> > >>> >>In
> > >>> >>fact I expect that each industry will pick the MEPs that best meet
> > >>> their
> > >>> >>functional and legal requirements. Therefore I would propose that
> > our
> > >>> job
> > >>> >>is
> > >>> >>to enable the creation of such MEPs rather than specifying exactly
> > >>> what
> > >>> >>they
> > >>> >>are.
> > >>> [JJ] +1
> > >>> >>
> > >>> >>As such I would propose rewriting Jean-Jacques' proposed
> > requirement
> > >>> as:
> > >>> >>
> > >>> >>The WS-Chor message sequence description language MUST take into
> > >>> >>consideration the need to manage signals where a signal is defined
> > as
> > >>> an
> > >>> >>application level processing error that is expressed as a message
> > >>> visible
> > >>> >>by
> > >>> >>other partners in the choreography.
> > >>> [JJ] I am not sure I would translate it this way. Signals are not
> > just
> > >>> application level processing error messages. You may also have
> > "message
> > >>> format errors" that could be trapped above the system of record.
> > >>>
> > >>> I would suggest:
> > >>>
> > >>> >>The WS-Chor message sequence description language MUST take into
> > >>> >>consideration the need to manage signals where a signal is defined
> > as
> > >>> <a choreography state synchronization mechanism> that is expressed
> > as a
> > >>> <standard> message visible
> > >>> >>by
> > >>> >>other partners in the choreography.
> > >>>
> > >>>
> > >>> >>
> > >>> >>> -----Original Message-----
> > >>> >>> From: public-ws-chor-request@w3.org
> > >>> >>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Jean-Jacques
> > >>> Dubray
> > >>> >>> Sent: Thursday, June 05, 2003 2:51 AM
> > >>> >>> To: 'WS Chor Public'
> > >>> >>> Subject: More requirement
> > >>> >>>
> > >>> >>>
> > >>> >>>
> > >>> >>> I would like to add another requirement:
> > >>> >>>
> > >>> >>> The WSC-Languange MUST provide specific Message Exchange Pattern
> > >>> >>> templates that establish a reliable state of the WSC-instance
> > when
> > >>> >>> needed.
> > >>> >>>
> > >>> >>> This requirement is essential since RM itself is not enough to
> > >>> guaranty
> > >>> >>> that the state of the choreography is identically represented in
> > >>> each
> > >>> >>> party. For instance a party sends a message with an incorrect
> > >>> format. If
> > >>> >>> we have RM only, then the state of the collaboration says that
> > the
> > >>> >>> message got there, so the choreography should proceed as normal.
> > >>> >>> However, if this is a request, the responding party cannot send
> > the
> > >>> >>> response since the message was structurally incorrect.
> > >>> >>>
> > >>> >>> Unless the WSC-definition specifies that at this point the
> > >>> responding
> > >>> >>> party can send a "INVALID MESSAGE" response, we get into a
> > deadlock
> > >>> >>> (requesting party waiting for response, responding party unable
> > to
> > >>> >>> respond).
> > >>> >>>
> > >>> >>> A similar deadlock can happen when the message is structurally
> > >>> valid,
> > >>> >>> but cannot be processed by the corresponding system of record
> > (that
> > >>> is
> > >>> >>> in charge of producing the response).
> > >>> >>>
> > >>> >>> Providing MEP-templates would greatly simply the work of the
> > >>> designers
> > >>> >>> by establishing clear patterns, with standard error messages
> > that
> > >>> can be
> > >>> >>> used over and over by anybody.
> > >>> >>>
> > >>> >>> This approach also offloads the business logic of the
> > application/or
> > >>> >>> process engine to deal with "protocol" levels. Can you imagine
> > the
> > >>> >>> simplification for the Orchestration/Process Definition-instance
> > if
> > >>> >>> these concepts are implied rather than explicitly handled by the
> > >>> process
> > >>> >>> instance?
> > >>> >>>
> > >>> >>> See also this article:
> > >>> >>> http://www.looselycoupled.com/stories/2003/message-infr0528.html
> > >>> >>>
> > >>> >>> Of course most people would have recognized the BPSS business
> > >>> >>> transaction protocol, that itself has its root in prior work at
> > RN
> > >>> and
> > >>> >>> UN/CEFACT. I think that generalizing this idea would be helpful.
> > >>> >>>
> > >>> >>> Cheers,
> > >>> >>>
> > >>> >>> Jean-Jacques Dubray____________________
> > >>> >>> Chief Architect
> > >>> >>> Eigner  Precision Lifecycle Management
> > >>> >>> 200 Fifth Avenue
> > >>> >>> Waltham, MA 02451
> > >>> >>> 781-472-6317
> > >>> >>> jjd@eigner.com
> > >>> >>> www.eigner.com
> > >>> >>>
> > >>> >>>
> > >>> >>>
> > >>> >>>
> > >>> >>>
> > >>>
> > >>>
> >
>

Received on Wednesday, 25 June 2003 07:14:20 UTC