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

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

Sent: Wednesday, May 05, 2004 4:21 AM

To: ; 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: 

phone: +44 870 739 0066

mobile: +44 7951 536168

> -----Original Message-----

> From: Tom Rutt [mailto:] 

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

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