Destroying a subscription ws-resource terminates the subscription. A 
termination notification will then be sent to anyone listening; this 
allows you to terminate subscriptions in a robust manner from the producer 
or consumer side of things.

1. No - the unsubscribe/renew support goes on the subscription resource 
type, not the producer. You would make a new capability with the two 
properties and two operations and either copy/paste the WSRL 
implementation or forward to the WSRL implementation (notice that the 
properties/operations/faults are about identical). My earlier response to 
Steve goes into more detail on an easy way to implement these operations 
in a new capability.

2. No - since Java has no deterministic destruction, we don't have any 
kind of destruction/shutdown code in the client classes. Besides, in many 
cases, a client object may just be a temporary thing used by a service to 
make a request - gc'ing the object doesn't mean the resource should be 
destroyed.

Also - if you accidentally release the SubscriptionClient object, you 
wouldn't be able to call unsubscribe() either - you call this operation on 
the subscription ws-resource, not the producer.

3. WSN leaves this as an exercise for the reader. Muse's implementation 
keeps trying until someone kills the subscription, since we can't tell if 
the resource is just temporarily down (because of a reboot) or destroyed 
or what. The spec is vague on this, and if you wanted to alter that 
behavior I could show you how.

Dan



"Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 12/15/2006 
05:00:17 PM:

> Thanks Dan,
> I saw the SubscriptionClient.destroy() method, but I wasn't sure if it
> actually unsubscribed itself since the javadocs didn't mention it.  This
> brings up the next few questions:
> 
> 1) To support unsubscribe, I assume that the producer resource must
> define an "unsubscribe" capability.  Would this be done by including the
> following action mapping in service.xml (or something similar since I
> just renamed it from the SubscribeRequest action)?
> 
> <actionMapping>http://docs.oasis-open.org/wsn/bw-2/NotificationProducer/
> UnsubscribeRequest</actionMapping>
> 
> 2) If the client accidentally releases the SubscriptionClient object
> reference and it gets gc'd, will it automatically unsubscribe itself?
> If not, is there another route which the subscriber can still call the
> producer to unsubscribe?  Perhaps directly call the "unsubscribe"
> capability mentioned above?
> 
> 3) If a subscriber goes down, and the producer can't get the
> notifications across to the subscriber, what does the producer do?  Do
> is continue to try and send the notifications, or stop them completely?
> -Vinh
> 
> 
> -----Original Message-----
> From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] 
> Sent: Friday, December 15, 2006 11:39 AM
> To: [email protected]
> Subject: Re: unsubscribe notifications
> 
> Hi - I think this is the answer you're looking for:
> 
> http://marc.theaimsgroup.com/?l=muse-user&m=116559218207332&w=2
> 
> 
> "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 12/15/2006
> 02:32:53 PM:
> 
> > What is the proper way for a client to unsubscribe from notifications?
> > There's a NotificationProducerClient.subscribe() method, but no 
> > corresponding unsubscribe().
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to