FW: Thoughts on describing what goes on the wire.

-----Original Message-----
From: Williams, Stuart 
Sent: 09 October 2001 12:58
To: 'Oisin Hurley'; 'Hugo Haas'; 'David Fallside'; 'Glen Daniels';
'Chris.Ferris@sun.com'; 'Henrik Frystyk Nielsen'; 'Mountain, Highland
M'; 'marc.hadley@sun.com'; 'Mark Nottingham'; 'Noah Mendelsohn';
'ylafon@w3.org'; Mark A. Jones (E-mail)
Cc: 'Doug Davis'; 'w3c-archive@w3.org'
Subject: Thoughts on describing what goes on the wire.


Regarding Doug's appeal [1] that we speak much more in terms of what goes on
the wire (not that we're really that close to the wire!), I had a thought
that we might use something like a process algerba rather than a finite
state machine for specifying the behavioural aspects of requester and
responder for the single-request-response MEP. Basically it goes along the
lines that you need to specify the set of admissable message/event traces
(at some view point).

I mentioned some of this in a note to Doug yesterday[2]... however he
doesn't appear to have responded to the thought.

I have some process algebra guru's around who I haven't managed to speak to
but for the 'wire' it goes something like this:

Alphabet (ie. set of wire events) =
	{ SOReq,		//Start of request (on the 'wire')
	  EOReq,		//End of Request
	  SOResp,		//Start of Response
	  EOResp,		//End of Response
	  fail }	      //Transmission/Reception failure.


Normal message (successful) traces at would be:

	SOReq.EOReq.SOResp.EOResp.stop
	SOReq.SOResp.EOReq.EOResp.stop
	SOReq.SOResp.EOResp.EOReq.stop


Then there are a whole bunch of failure cases that we usally ignore:

	SOReq.fail.stop
	SOReq.EOReq.fail.stop
	SOReq.EOReq.SOResp.fail.stop
	...
	SOReq.SOResp.fail.stop
	...

I played about with this and get the following expression for the on the
wire process:

  SOReq.(   EOReq.(SOResp.(EOResp | fail) | fail)
          | SOResp.(  (EOReq.(EOResp | fail) | fail)
          | (EOResp.(EOReq | fail) | fail) )
          | fail).stop

  [ '.' is sequencing (followed by), '|' is non-deterministic choice ]

This is a bit like a regular expression that matches all the admissable
traces that 'fit' the message exchange pattern.

I think this is very compact, captures (just) the 'on-the-wire' behaviour
request/response, covers ALL the high level failure cases. It also captures
the potential for request and response messages to overlap in time (the
state machines don't capture that properly at the moment).

Done this way, I think the state-machine would disappear from the binding
description... which would probably become more to Doug's taste. 

However, it too may be completely inaccessible...

If we were to re-jig things this way, the formal part of the mep description
would present something like the material above; and the binding description
would detail what goes on the wire between SOReq and EOReq and between
SOResp and EOResp. It would also detail any SOAP specific significance of
HTTP status codes when received and the circumstances under which SOAP
requires particular status codes to be sent. 

So before I do anything more with it I'd appreciate comments encouraging or
otherwise.

BR

Stuart
[1]
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Oct/0036.html
    and following...

[2]
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Oct/0052.html

Received on Tuesday, 8 January 2002 11:05:11 UTC