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


Help: OASIS Mailing Lists Help | MarkMail Help

wsn message

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

Subject: Issue: Lifetime of PullPoints


I'm concerned that there are some issues relating to lifetime of a
PullPoint which could lead to interoperability problems.

The spec suggests that PullPoints can be modelled as WS-Resources, and that
WS-RL can be used to update the termination time, however we don't provide
an initialTerminationTime element on the createPullPoint operation in the
same way that we do for Subscriptions. This means that unless the PullPoint
supports WS-RL it is easy for the application to forget to destroy it,
leaving state on the CreatePullPoint service indefinitely.

Clearly this is a dangerous situation to be in, so I suspect that
implementors will then make a decision about when the PullPoint should be
destroyed. I would like to update the spec to clarify the situation in one
way or another. Here are the options I have been considering;

1. Leave as currently specified - in the absence of WS-RL the lifetime of a
PullPoint is infinite (potential for orphaned state).

2. Match the style used for Subscriptions (initialTerminationTime on create
- values can be finite, or infinite using xsi-nil. Not specifying the
timeout leaves it at the discretion of the implementor. Return the
initialTermTime in the create response. Add a non WS-RL Renew operation)

3. State that the lifetime of the PullPoint is tied to that of the
Subscription with which it is associated. (what does it mean if the
PullPoint is destroyed but the associated Subscription is not?). This
avoids having to talk about lifetime of a PullPoint, although we should
probably mention something about the length of time a PullPoint is valid
before it must be associated with a Subscription.

4. Mandate use of WS-RL to handle the scheduled termination of the

My personal preference is for option 3 since it provides a very simple
model - what are your opinions?


Matt Roberts
IBM WebSphere Messaging Design and Development
Hursley Park, England. +44 1962 815444
MP 211 / DE3H22

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