OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsrm] Persistence requirement in the WS-RM specification

> <scott>
> I was thinking that there would be a parameter passed as part of the WSRM
> message that indicated the desired service level, e.g.,
> <soap:header>
>   <wsrm:ReliableMessage>
>      <wsrm:MessageType ServiceLevel="MUST_PERSIST">
>         .......
>      </wsrm:MessageType>
>   </wsrm:ReliableMessage>
> </soap:header>
> The spec would define 2 or 3 base levels of service, such as MUST_PERSIST,
> DO_NOT_CARE, and MUST_DELIVER. The semantics of the latter would be (for
> example):
> An ACK indicates the service level was met by the receiver. A Fault would be
> available to indicate the WSRM node cannot meet the requested service level.
> Putting pre-defined service levels in the spec will allow WSRM apps to be
> written once without having to write special code for each WSRM vendor that
> comes along that someone wants to send messages to.
> </scott>

Seems to me to be a simple way to accomodate the need to allow devices
with no persistance capabilities to use our protocol.
I can't see the difference between DO_NOT_CARE and MUST_DELIVER.
I think that any WS Reliable Messaging implemantion MUST always deliver
the (non-duplicated and in-order) messages to the application.
May be, we could cut even shorter and just prescribe two persistance
	1) MUST_PERSIST: whose semantic is quite obvious
	2) DO_NOT_CARE : whose semantic may be the one mentioned by Scott
in his mail and that I copy for reference.
> "You MUST deliver the message to the application, whether that QoS
> assurance is met through using persistance (to non-volitile storage) is up
> to the WSRM implementation".

May be, we could add a note where we claim that if no persistance is used
the RM processor ONLY tolerates communication failures, but no crash


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]