Groups - Issue 2.28: Durability Proposal(Durability_Proposal.doc) uploaded

[rcobb@knownow.com]

Just for you folks who don't want to download a Word document:

There are two aspects of durability we have identified: the durability of
subscriptions, and the durability of messages. These two are orthogonal in
concept but might intertwine in implementations.

1. A subscription has a lifetime. When a subscription is intended to
outlive sessions, it is a durable subscription (or resumable subscription).
In the web-services context, we use the term session to connote the
ability for the producer to notify the consumer without receiving a
delivery fault.. A session can be terminated by unexpected events, or
terminated by either the producer/subscription manager or consumer
intentionally. In these cases, a web service consumer may not need to issue
another subscribe (connect) request. All we need may just be the
PauseSubscription and ResumeSubscription operations already defined in base
notification. There are policies associated with these operations. Will
messages be lost when a subscription is paused? Will messages be duplicated
when the subscription is resumed?

Proposal:

We define a durable subscription policy element for use in subscribe
operations. This policy can be encapsulated in the SubscriptionPolicy
element and no syntax change is necessary. Subscriptions default to
volatile if no durability is requested. An InitialTerminationTime of
xsi:nil may not indicate durability, although we could stretch ourselves
hard to merge these two. The NotificationProducer MUST fault if it does not
support durable subscriptions.

For sub-policies associated with a durable subscription, we can utilize the
policies defined in base notification spec for ResumeSubscription:
1.	Generate NotificationMessages for all the Situations related to the
Subscription that occurred while the Subscription was paused (as well as
for any new Situations that occur after the Subscription has been
resumed).
2.	Generate a NotificationMessage for the last Situation that occurred
while the Subscription was paused (as well as for any new situations that
occur after the topic has been resumed).
3.	Generate no NotificationMessages until a Situation occurs after the
Subscription has been resumed.

Option 3 is the default policy.

However, for pull notification, should we also use the same operations to
pause and resume subscriptions? It seems pausing a subscription does not
make much sense to a pull notification. Or if we look at it from a
different angle, the common operation between pull and push model is the
one to request different styles of message accumulation at the
producer/broker. That is, when one pauses the subscription, one pauses the
delivery of messages from the producer to the accumulator, not the delivery
from the accumulator to the consumer. 

2. Messages can also have a lifetime. A timeToLive property defines when a
message expires. A producer may set this property (field) of a message. In
brokers, there is also the notion of persisting before (or during)
message delivery. Brokers can persist messages to disk to prevent message
loss during transit, and brokers can also choose not to persist messages to
enhance performance. Message durability can also be influenced by message
reliable policies, such as the ones defined by WSRM, including AtLeastOnce,
AtMostOnce, and ExactlyOnce. For guaranteed delivery, acknowledgement of a
message is required. Note that in the brokered case, acknowledgement pairs
are between the producer and the broker, and between the broker and the
consumer.  There is (typically) no end-to-end acknowledgement from the
consumer to the producer.

Proposal:
Individual messages may provide timeToLive or expiration headers as
additional policy-specific information in the NotificationMessage.  We
propose that this be done with an additional optional element, perhaps
something like:

<wsnt:PolicyInfo>
<wsnt:Policy dialect=http://www.purl.org/wsnt/Durability>
     <timeToLive>wsd:Duration</timeToLive>
</wsnt:Policy>
</wsnt:PolicyInfo>

The subscriber may provide the information that it can support a durability
policy in the policy elements of the Subscription message exchange.

We may also need policies to cover pull notification policies such as when
a message can be safely discarded from a mailbox or a queue. This can also
be defined in the SubscriptionPolicy.

Reliable delivery is composed in using other web services specifications,
and affects only the relationship between a single producer/consumer pair
(e.g., a producer and a broker, or a broker and a consumer, etc).



 -- Mr Rick Cobb

The document named Issue 2.28: Durability Proposal
(Durability_Proposal.doc) has been submitted by Mr Rick Cobb to the OASIS
Web Services Notification (WSN) TC document repository.

Document Description:
First proposal for how to handle message & subscription durability

Download Document:  
http://www.oasis-open.org/apps/org/workgroup/wsn/download.php/11589/Durability_Proposal.doc

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/wsn/document.php?document_id=11589


PLEASE NOTE:  If the above links do not work for you, your email application
may be breaking the link into two pieces.  You may be able to copy and paste
the entire link address into the address field of your web browser.

-OASIS Open Administration