RE: State Alignment and Standard Signals

 

The main point I wanted to make from David's previous email was that I
don't think we should be encoding legal significance of a message in
CDL, especially not as different message types. I think this is a
business level consideration that should be catered for in the business
protocol - precisely because of the potential delays between different
stages of the transaction - or the fact that the business transaction
may be performed across multiple choreographies.

<JJ>That I totally agree, but please do not associate "legal
significance" with "state alignment" as one and the same. However, you
require state alignment to achieve legal significance. All I am
suggesting is that WS-CDL can only claim state alignment once it can
bind to a state alignment protocol (I am not suggesting that WS-CDL
should yet define a new state alignment protocol)

 

I have proposed since last September to add the capability to WS-CDL to
describe protocols that can be used in combination of the choreography.
In other words I claim that a choreography is in general made of
substantive messages and protocol signals. WS-CDL should provide a
capability for describing protocols, and then using one of them in a
given choreography.  </JJ> 

 

Cheers,

 

JJ-

 

	----- Original Message ----- 

	From: Jean-Jacques Dubray <mailto:jeanjadu@Attachmate.com>  

	To: Gary Brown <mailto:gary@enigmatec.net>  ;
david.burdett@commerceone.com ; tony.fletcher@choreology.com ;
public-ws-chor@w3.org 

	Cc: Robin.Milner@cl.cam.ac.uk ; kohei@dcs.qmul.ac.uk ;
yoshida@doc.ic.ac.uk 

	Sent: Thursday, July 15, 2004 5:26 PM

	Subject: RE: State Alignment and Standard Signals

	 

	Gary:

	 

	The "paper world" is really hard to emulate electronically. It
is far easier to forge an XML text file than a piece of paper. It is
also very easy to blame something like an Enigmatec infrastructure for
not having delivered an XML document to my ERP system than the
postmaster for not delivering a registered piece of mail. 

	 

	So here is a scenario that could happen in business (either by
mistake or wrongfully):

	- You send me an invoice and I don't "respond". Then I call you
and you claim you never received it. How would you strategy work in that
case?

	- You can also have (very common scenarios - see my article:
http://www.ebpml.org/state.htm article) the case where the response can
only come, days or weeks after the request (e.g. an RFQ). It is a very
good practice to indicate that you received the RFQ and you were able to
process it, it does not mean that you are in the position to respond
just yet. Imagine how disastrous it could be for both parties if the RFQ
fell through the cracks and you waited on a timeout on the response to
detect it.

	 

	So at the end of the day, we are either in the business of
Distributed computing or in the business of B2B, but applying DC tricks
to B2B will lead to a vastly suboptimal solution. When you apply DC
internally, you tend to detect all these situations and find an ad-hoc
solution. When you problem is to get a 1000 or 10000 companies to
interoperate over some message interchanges definition, you cannot
afford to have little tricks figured two by two. You need a holistic
solution.

	 

	I hope you understand a little more the value a little signal
can have.

	 

	CQFD.

	 

	Jean-Jacques

	 

	
________________________________


	From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Gary Brown
	Sent: Wednesday, July 14, 2004 11:41 PM
	To: david.burdett@commerceone.com; tony.fletcher@choreology.com;
public-ws-chor@w3.org
	Cc: Robin.Milner@cl.cam.ac.uk; kohei@dcs.qmul.ac.uk;
yoshida@doc.ic.ac.uk
	Subject: Re: State Alignment and Standard Signals

	 

	Hi David

	 

	As Monica pointed out in a previous email, "we are implementing
the technical interactions, as the 
	business aspects are outside of WS-CDL".

	 

	I would suggest that the legal status of a message
(signal/acknowledgement) is a business level consideration. For example,
if participant A sends a request to participant B, and the CDL defines a
sequence that indicates that a response is then sent from B to A
following the receipt of this request, then that implies participant B
has received and processed the message.

	 

	<sequence>

	    <interaction A->B />

	    <interaction B->A />

	</sequence>

	 

	As Participant B has sent a follow-up communication that could
only have resulted as a consequence of receiving the request, it would
not be able to argue that it hadn't received the request.

	 

	I am not sure what value defining a specific message type would
add.

	 

	Regards

	Gary

	 

	 

	----- Original Message ----- 

		From: david.burdett@commerceone.com 

		To: tony.fletcher@choreology.com ; public-ws-chor@w3.org


		Cc: Robin.Milner@cl.cam.ac.uk ; kohei@dcs.qmul.ac.uk ;
yoshida@doc.ic.ac.uk 

		Sent: Thursday, July 15, 2004 1:24 AM

		Subject: State Alignment and Standard Signals

		 

		Tony

		 

		I thought it might be worthwhile putting on record the
comment I made on the call on Tuesday in that I think that there are two
different "state alignment" problems to be solved: "real" state
alignment, and standard signals.

		 

		REAL STATE ALIGNMENT

		The first is the problem you discuss below that there is
a general requirement at various points in a choreography that each
participant has a common shared understanding of the state of the other
participants in terms of the messages that have (or have not) been
received ... I hope I am paraphrasing/simplifying your requirement as
described below.

		 

		STANDARD SIGNALS

		The second is the problem that Anders Tell described in
his email [1] that I responded to in my email [2]. Anders talks about a
need that a recipient of a message "legally" accepts that he has
received the message. In this case, the message is more like a signal
that informs the sender of the original message what their "state" is
with respect to legal acceptance of the message. There are also other
signal messages that can occur, for example to indicate that a message
has been received, i.e. a simple Ack, or has been "Accepted for
Processing" as standards like BPSS suggest.

		 

		SOLVING THE PROBLEMS

		To solve the problem you are suggesting, then we need to
continue discussing the state alignment approaches you describe below.

		 

		To solve Anders problem and also the issues I think
Jean-Jacques was raising, we could define some "standard" Message
Content Types that have specific semantics, message flow patterns and
behaviors associated with them and then recommend use of these standard
types when choreography designers have a need to use them. Note that
these would specify the types and not the representation of those
messages in XML which could potentially be done in different ways.

		 

		Thoughts?

		 

		David

		 

		[1]
http://lists.w3.org/Archives/Public/public-ws-chor/2004Jul/0009.html

		[2]
http://lists.w3.org/Archives/Public/public-ws-chor/2004Jul/0012.html

			-----Original Message-----
			From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Tony Fletcher
			Sent: Tuesday, July 13, 2004 3:56 AM
			To: public-ws-chor@w3.org
			Cc: Robin Milner; 'Kohei Honda'; Nobuko Yoshida
			Subject: Tony's nightmare - wake me up please

			Dear Colleagues,

			 

			I hope this is a nightmare and someone can wake
me up and re-assure me that everything is all right really!  I know that
Nick (who could answer this concern as one of our main language
designers) is on holiday for awhile now, so I have copied this message
to your resident experts as well, though Steve, Gary or somebody else
may well be able to answer simply.  I started writing this email a few
days ago before Gary Brown's message on 'Perform' came out.  Having now
had a look at that I wonder if my concern is a more extreme form of his.

			 

			Following discussions with Peter last week I
have a major concern about how we are designing the choreography
description language.

			 

			I am no mathematician, but my understanding is
that pi-calculus describes each 'node' (a partner according to our
current definitions) as a process and the allowed message sequences (I
think mathematicians call these 'traces') are generated by
mathematically 'composing' each node process with the others and letting
the maths tell you what the various allowed message exchanges are (etc.)

			 

			Now I am more familiar with state machines, and
I will therefore continue the discussion based on these, but I think the
same principles apply to process algebras.

			 

			Consider a relationship between two nodes that
we wish to describe.  The usual way to describe this fully suing state
machines is to develop a state machine for each end and see how they
interact.  Suppose one state machine has N states and the other M (N and
M will be close to the same integer value but not necessarily equal).
So we have had to use N + M (approx 2*N) states to describe this
relationship precisely.  However, there are altogether N*M (approx N
squared) states that the system can be in.  Now depending on the whether
each of our state machines are relatively simple and only have entries
on the diagonal cells (or nearly so) or a very complicated with entries
in most cells the number of valid, reachable states may be near to 2N or
to N squared).  The answer is usually a lot more than 2N even if less
than the worst case.

			 

			Now it is possible, in principle (I think) to
have a single state machine that describes the permitted message
sequences for the relationship but this is usually only attempted for
very simple cases due to the state 'explosion' described above.  This
single state machine has to represent all the valid states which is
between N+M and N*M and usually well above N+M for any 'interesting'
protocol.

			 

			In the current version of CDL we do not seem to
be describing the process at each node then letting these interact with
the others, but describing the interactions directly.  My concern is
that this approach will suffer from state space explosion when one tries
to include every conceivable message sequence that could happen, and
that actually the current CDL may be fine for describing message
sequence charts in XML (which is useful but not I thought what we were
attempting to achieve) which are fine for illustrating message flows,
but do not, in general, cover every possible case the protocol designer
needs to allow for, but will become unwieldy / impossible to use for a
complete description.

			 

			I hope the point is clear and that someone can
answer it.

			 

			Best Regards     Tony

			A M Fletcher

			 

			Cohesions  (TM)

			 

			Business transaction management software for
application coordination       www.choreology.com
<http://www.choreology.com/> 

			 

			Choreology Ltd., 68 Lombard Street, London EC3V
9LJ     UK

			Tel: +44 (0) 1473 729537   Fax: +44 (0) 870
7390077  Mobile: +44 (0) 7801 948219

			tony.fletcher@choreology.com     (Home:
amfletcher@iee.org)