RE: BurdettML comments

Jon

See comments inline below.

David

-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Monday, June 23, 2003 3:50 PM
To: 'public-ws-chor@w3.org '
Subject: BurdettML comments



I've had a chance to look over David Burdett's WS Choreography spec 
(http://lists.w3.org/Archives/Public/public-ws-chor/2003Jun/0107.html) 
in more detail, and view it in a decent schema editor (which helps a lot).

I used a simple example choreography to see how this works.

In this choreography, there's a client and server role. The client has 
the ability to perform a "login" interaction with the server. Once 
logged in, he/she can perform one of five operations: query, add, 
modify, delete, and logout. The first four of these can be done in any 
order and multiple times. However, logout ends the choreography. (Sorry 
for the textual description: I don't have a good diagrammer for this).

In this example, we'd have to have at least three states: NotLoggedIn, 
LoggedIn, LoggedOut. The "login" interaction transitions betweens 
NotLoggedIn and LoggedIn. Any of query/add/modify/delete transition from 
LoggedIn to LoggedIn (in other words, loop). The "logout" interactions 
transitions from state LoggedIn to LoggedOut.

A couple of comments from looking at this use case:

1. As I mentioned at the F2F, IMO it would be more convenient if the 
states could be implicitly named. For example, I could do:

<InteractionDef name="DoLogin" fromRole="client" toRole="server"
messageFamily="Login">
</InteractionDef>
<InteractionDef name="DoLogout" fromRole="client" toRole="server"
messageFamily="Logout">
<InteractionEndStates fromState="DoLogin:end">
</InteractionDef>
<DB>I think that the three states, NotLoggedIn, LoggedIn and LoggedOut are
states that belong only to the client. However for the client to reach a
LoggedIn or a LoggedOut state it has to pass through additional states
associated with doing the login request and getting the response, for
example, LoginRequestSent and LoginRequestAccepted. The server has a
different set of states, for example: LoginRequestReceived and, once the
login request is checked either LoginRequestOk or LoginRequestFail.

The point I am trying to make is that I think that a state is *always*
associated with a role and not the choreography as a whole. I discussed this
in an earlier email which described how the state of a choreography as a
whole is unknowable by any single role unless the choreography is halted. In
this case, the client does not know it has been logged in until the login is
accepted by the server, the server sends a login response message back and
the client receives the login response and processes it. All these activties
take a finite time and which means that each role, at a point in time can
think it is in different states, for exmple the server could consider that
the client is logged in but the client doesn't know it yet because it has
not received the response.
Also in my spec I assumed that an Interaction was implmented by a single
message (ignoring signals) sent from one role to another. In your example
for "DoLogin" to succeed, you would need two messages the LoginRequest from
the client to the server and the LoginResponse from the server to the
client. The result could be either succeed or fail. Similarly a "Query" is
not an interaction as you would need a QueryRequest followed by a
QueryResponse. Now maybe we design the Choreography language so that an
Interaction always consisted of two messages, i.e. a "request" followed by a
"response", but that is not what I intended in the spec. I also think that
you can have "one-way" messages which I don't think would be allowed
following the ideas you suggest. 
I also tried to describe your ideas using a state diagram, but could not so
I've done my interpretation in the attached picture - I'd love to see an
equivalent diagram following your own ideas.
</DB>


Here, instead of using a state called "LoggedIn", I use the convention 
that state "DoLogin:end" means the end result of the DoLogin 
InteractionDef. I also omit the "toState" in the DoLogout InteractionDef 
- if I had to name it, I would use "DoLogout:end". And I didn't put any 
named InteractionEndStates in the DoLogin InteractionDef - again, the 
name is implicitly "DoLogin:end".
<DB>Basically, I like this idea. Given that an Interaction always has a
fromState and a toState, then adopting a convention for naming them based on
the name of the interaction could make sense as their existence could be
assumed implicitly. However, I don't think that "end" is the right suffix to
use since the processing of any message can either succeed or fail and "end"
does not indicate this. Also, as said earlier, an interaction in the spec is
always asociated with the single sending of a message (ignorinng signals).
So if we follow your idea of using a suffic, then I think the states
associated with an interaction should be, for example, "LoginRequest:sent"
for the fromState and "LoginRequest:received" for the toState. The only
issue is that there could be additional semantics associated with the from
and to states that need description somewhere. However you could include
these semantics in the description of the interaction as a whole.</DB>

This is just shorthand, but IMO it also makes modelling tools simpler, 
because you can just connect interactions without having to name the 
connections - this is like UML, where you can name a relationship, but 
don't have to.

2. I notice that a Precondition on an Interaction element is mandatory. 
But in some (most?) cases, this is redundant, because you've already 
specified in the InteractionDef what the state prior to the interaction 
is. For example, in my simple use case, the "query" interaction would be 
modelled like this:

<InteractionDef name="DoQuery">
<InteractionEndStates fromState="DoLogin:end" toState="DoLogin:end">
</InteractionDef>

<Interaction name="DoQuery">
<Precondition condition="DoLogin:end">
</Interaction>

But you already know from the "fromState" attribute that "DoLogin:end" 
is a precondition for DoQuery. IMO in this simple case the precondition 
could/should be omitted. We do not need to specify that the client is 
not logged out, because DoLogout will be an end state for the 
choreography. I am assuming that reentering a choreography via other 
than a state state after an end state has been reached is an error.

Notice also that removing the precondition makes the Interaction itself 
redundant: you've already specified what you need in the InteractionDef.
<DB>I think your ideas only make sense if you think of an interaction as
consisting of a request and a response. As stated earlier this was not my
intention as states are always associated with an individual role. I also
think that if you remove an Interaction, then you a removing an exchange of
information between the roles which in practice has to occur.</DB>

Comments welcome .. it is still possible I am misunderstanding some of this.

--Jon