> <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
levels:
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
failures.
Paolo
