- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Fri, 16 Jul 2004 19:41:24 +0100
- To: <public-ws-chor@w3.org>
- Message-ID: <005901c46b64$819f2a10$5a00000a@ie.oracle.com>
Jean-Jaques,
we have a whole category of issues related to concrete bindings, QOS
etc.
I'm hoping we have proposals very soon to do what you ask for.
Martin.
-----Original Message-----
From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org] On Behalf Of Jean-Jacques Dubray
Sent: 16 July 2004 16:10
To: Gary Brown; 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
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)
Received on Friday, 16 July 2004 14:48:37 UTC