Thanks, that got me going and i was able to realize it using a customer NotificationProducerClient and SubscriptionClient.
Gero Vinh Nguyen (vinguye2) wrote: > > Gero, > Where you put Unsubscribe on the client side depends on where it is > defined on the server. > > 1) On the server, if Unsubscribe is implemented in your notification > producer resource, then you call it from your notificationProducerClient > proxy. > > 2) On the server, if Unsubscribe is implemented in a custom > SubscriptionManager resource, then you'll call it in your custom > subscriptionClient proxy. If you do it this way, you'll have to edit > your notificationProducerClient proxy to return your custom > SubscriptionClient, instead of Muse's base implementation. > > NOTE: > Subscribe is associated with the notification producer resource, which > creates an instance of a SubscriptionManager resource to manage the > single subscription. So ideally, Unsubscribe would also be implemented > on this same producer resource, and called from the > notificationProducerClient. > > It doesn't make sense to have Unsubscribe on the SubscriptionClient, > which references the SubscriptionManager directly. To unsubscribe here > is the same as calling SubscriptionClient.destroy(), or > SubscriptionClient.setTerminationTime(now). Or, you can just add > unsubscribe() in this proxy and just have it call destroy(). > > So you have several options here. Hope this helps:) > > > -----Original Message----- > From: Gero [mailto:[EMAIL PROTECTED] > Sent: Friday, June 22, 2007 11:15 AM > To: [email protected] > Subject: RE: unsubscribe notifications > > > Hi, > > I need to implement the unsubscribe on the client side (server already > supports it, build by other party). The suggested approach below looks > simple, but I do not see how it would enable to to do an unsubscribe > from the client. Would it be possible to provide a bit mode detailed > instructions on how to implement this. I'd like to be able to do a > SubscriptionClient.unsubscribe(). > > Questions I have are: > - How do I register the "Unsubscribe" capability on the client > - How do I implement the unsubscribe (Do I need to create my own > Resource implementation? If so, how would I ensure that it is used by > the "subscribe" > call,..) > - ... > > (I did see issue https://issues.apache.org/jira/browse/MUSE-212 that > states that it will be supported in version 2.3.0, but that is only due > in september... which is to late for us). > > Thanks for the information. > > Regards, > Gero > > > Daniel Jemiolo wrote: >> >> The WSN spec provides two ways of doing two different tasks - >> immediate termination of subscriptions and scheduled termination of > subscriptions. >> The former is possible through WSRF's Destroy or through Unsubscribe; >> the latter is possible through WSRF's SetTerminationTime or Renew. The > >> reason they have duplicated the WSRL functionality in the spec is so >> that people can implement WSN without using WSRF - if your >> subscriptions aren't WS-resources, you can't very well terminate them >> with WS-resource operations. I have never heard a cogent argument for >> why someone would want WSN but not WSRF, but this was the inspiration >> behind the duplication of semantics. >> >> Since Muse's WSN implementation builds on WSRF, we just use WSRF's >> Destroy and SetTerminationTime rather than duplicating the code with >> different names. You could easily implement the Unsubscribe and Renew >> operations if you wanted to - just copy the WSRL ImmediateTermination >> and ScheduledTermination code and do a search-and-replace: >> >> s/destroy/unsubscribe >> s/setTerminationTime/renew >> >> I see this as kind of bloated, but possible nonetheless. >> >> Dan >> >> >> "Steve Jerman \(stjerman\)" <[EMAIL PROTECTED]> wrote on 12/16/2006 >> 03:02:05 PM: >> >>> OK, So I've been looking at the spec some more and the Muse >>> implementation doesn't seem to match the 1.3 released > specification... >>> It seems to be using the RL 'Destroy' unstead of unubscribe for >>> instance... >>> >>> Steve >>> >>> >>> >>> -----Original Message----- >>> From: Steve Jerman (stjerman) >>> Sent: Saturday, December 16, 2006 11:32 AM >>> To: [email protected] >>> Subject: RE: unsubscribe notifications >>> >>> Hi Folks, >>> >>> I started looking at this and discovered a problem (I may just be >>> imagining this but ....) >>> >>> So the WSDL in the Muse repo >>> http://svn.apache.org/viewvc/webservices/muse/trunk/modules/muse-wsn- >>> api /specs/WS-BaseNotification-1_3.wsdl?revision=438334&view=markup >>> >>> which I think should match the WSDL from the WSN 1.3 spec, doesn't. >>> >>> Specifically, there is no definition for the base subscription >>> manager port type (which is where unsubscribe is defined). >>> >>> The messages are defined earlier on.. >>> >>> I can cut and paste from the standard, but it would be good if this >>> file was updated to match the spec... >>> >>> Steve >>> >>> -----Original Message----- >>> From: Vinh Nguyen (vinguye2) >>> Sent: Friday, December 15, 2006 2:00 PM >>> To: [email protected] >>> Subject: RE: unsubscribe notifications >>> >>> 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/NotificationProduc >>> er/ >>> 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] >>> >>> --------------------------------------------------------------------- >>> 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] >> >> >> > > -- > View this message in context: > http://www.nabble.com/unsubscribe-notifications-tf2829021.html#a11257175 > Sent from the Muse User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > 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] > > > -- View this message in context: http://www.nabble.com/unsubscribe-notifications-tf2829021.html#a11284402 Sent from the Muse User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
