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/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] >> >> --------------------------------------------------------------------- >> 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]
