[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Groups - Issue 2.28: Durability Proposal(Durability_Proposal.doc) uploaded
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]