You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-user@ws.apache.org by Gero <gv...@xebia.com> on 2007/06/22 20:15:29 UTC
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\)" <st...@cisco.com> 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: muse-user@ws.apache.org
>> 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: muse-user@ws.apache.org
>> 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:danjemiolo@us.ibm.com]
>> Sent: Friday, December 15, 2006 11:39 AM
>> To: muse-user@ws.apache.org
>> 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\)" <vi...@cisco.com> 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: muse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: unsubscribe notifications
Posted by Gero <gv...@xebia.com>.
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:gvermaas@xebia.com]
> Sent: Friday, June 22, 2007 11:15 AM
> To: muse-user@ws.apache.org
> 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\)" <st...@cisco.com> 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: muse-user@ws.apache.org
>>> 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: muse-user@ws.apache.org
>>> 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:danjemiolo@us.ibm.com]
>>> Sent: Friday, December 15, 2006 11:39 AM
>>> To: muse-user@ws.apache.org
>>> 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\)" <vi...@cisco.com> 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: muse-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>
>>
>>
>
> --
> 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: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
RE: unsubscribe notifications
Posted by "Vinh Nguyen (vinguye2)" <vi...@cisco.com>.
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:gvermaas@xebia.com]
Sent: Friday, June 22, 2007 11:15 AM
To: muse-user@ws.apache.org
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\)" <st...@cisco.com> 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: muse-user@ws.apache.org
>> 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: muse-user@ws.apache.org
>> 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:danjemiolo@us.ibm.com]
>> Sent: Friday, December 15, 2006 11:39 AM
>> To: muse-user@ws.apache.org
>> 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\)" <vi...@cisco.com> 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: muse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: muse-user-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: muse-user-help@ws.apache.org
>
>
>
--
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: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-user-help@ws.apache.org