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

[Jacques Durand <JDurand@us.fujitsu.com>]

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

Peter:

inline <JD>

-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
Sent: Wednesday, May 05, 2004 4:21 AM
To: tom@coastin.com; wsrm
Cc: *OCTO
Subject: [wsrm] reliability options presentation (was RE: [wsrm]
Preliminary minutes of wsrm tc teleconf 5/4/04)

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.

<JD> Right: restricting the normative to what happens "on the wire"
is not enough: all this is not just an interoperability exercise, but
there is a QoS contract behind, and it is about quality of "delivery",
which is pure "behavior" from whatever implements WS-R (that we abstracted as the "RMP").
When you think of it, all major RM features (dup elimination, ordering, and even guaranteed deliv) go beyond the RMP-to-RMP behavior: they are contract between RMP-to-"whatever beyond".

Although it is hard to define the contracting parties without stepping
into implementation details (we abstracted well enough the "RMP" I think,
but the other party cannot be reduced to the "application") we have tried
in the last revision to:
- abstract the "other" party as consumer and producer, defined generically in the Terminology section (still need to replace all references to "application layer" throughout the spec).

- define abstractly these contracts as when and how the "deliver" operation must be invoked,
after the "submit" operation has been, without even mentioning the parties on each side of
this operation (saying that "deliver" will pass the message from RMP to an application can be
seen as just one possible interpretation of these abstract operations).
In fact, an RM spec does not even need to define these contracting parties:
it can be formally defined
as a set of constraints on the invocation of these abstract operations (deliver, submit, notify), intertwined with protocol state transitions. Only, that would not be very intuitive for implementors.

Under this persepctive these operations (deliver, submit, notify...) should not be considered as accessory to the protocol: instead they are at the core of RM semantics, and the protocol

is there to implement this semantics. I think the other spec is not emphasizing this enough,
and lacks clear definitions of the RM contracts, beyond the protocol aspect.

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.

<JD> we have tried to do that in the latest revision, and might need to go further.
It seems impractical to split the normative from non-normative into separate docs,
as we wanted to do initially, agree.

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
>
>
>

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.