reliability options presentation (was RE: [wsrm] Preliminary minutes of wsrm tc teleconf 5/4/04)

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Sorry I wasn't on the call last night, though I'm only an observer at
the moment. 10:30 pm is not a good time for me :-)

On the presentation responding to the New Orleans comparison, one point
that perhaps could be made more strongly concerns the amount of
"implementation guidance". (I was about to head for the microphone at
the meeting when the queue was closed)


Chris Ferris argued that WS-RM was better than WS-R because WS-RM
confined itself to saying what was sent on the wire, without making
statements about end-system behaviour. In practice, it is always very
difficult to get the balance right in this. 

A protocol specification that sticks too strictly to the wire-only rule
will define a set of meaningless bit-patterns that do not carry any
semantics. This doesn't matter in an environment where the meaning of
the messages is understood implicitly. This is often the case for a
proprietary protocol, especially if there is an existing implementation
and the protocol specification is being written down to allow
interworking - the semantics of the messages is effectively defined as
"this is what you need to send to make the XYZ implementation do
<whatever>, and this is the reply you will get", but without actually
spelling that out.

Letting the semantics be implied is less suitable to the specification
of a new protocol that is intended to allow interworking between
yet-to-be-created implementations. Some way has to be found of stating
what the messages (and headers etc.) are doing. This is most commonly
done by defining an abstract model and then stating the meanings with
respect to that model. The difficulty then is that readers are liable to
take minor features of the  model, not as abstractions that could map to
various concrete alternatives, but as particular and specific
requirements. (e.g. WS-R's concept of delivering the message to the
"application"). A common defence against such mis-interpretation is to
outline one or more acceptable implementation approaches. To make clear
that these implementation notes are not themselves restrictions, it is
important that they are distinguished from normative text. To make them
effective, I would favour placing them in the same document and on the
same page as the normative text they clarify, with some convention to
make their status clear, but that's a matter of style. 

In the present comparison, WS-RM, developed within a semi-closed process
has followed an  implicit approach, WS-R, with a more open process, has
found it necessary to express the semantics of the messages within the
spec.  (From my reading of the minutes, WS-R is currently sharpening
some of the normative/informative distinction, which is right.) If and
when WS-RM arrives in an open environment, it may be necessary to add
implementation notes to it to make clear what is currently implicit, to
avoid WS-RM appearing to be just a bunch of meaningless messages.


Above is a personal view, rather than a Choreology position, but based
on a long experience of working with and editing protocol
specifications, especially higher-layer infrastructure protocols (such
as transaction protocols), that need to specify what they mean in a way
that avoids over-specificity.

Peter
 
------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email: peter.furniss@choreology.com
phone: +44 870 739 0066
mobile: +44 7951 536168



> -----Original Message-----
> From: Tom Rutt [mailto:tom@coastin.com] 
> Sent: 05 May 2004 00:58
> To: wsrm
> Subject: [wsrm] Preliminary minutes of wsrm tc teleconf 5/4/04
> 
> 
> The prelim minutes are attached.
> 
> Please post any corrections before Thursday pm to the entire list.
> 
> Tom Rutt
> WSRM Chair
> 
> -- 
> ----------------------------------------------------
> Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133
> 
> 
>