The key here is that Muse attempts to support several WS-* specs together. In doing so, there is some overlap in functionality between different specs. As Dan pointed out, wsrf:Destroy and wsrf:SetTerminationTime pretty much does the same as wsn:Unsubscribe. So from a Java client perspective, there may be more confusion if several different operations do the same thing, and a client may not know which one to call...unless they really know their WS-* specs.
Also, I don't think Muse can provide base implementations for all the WS-* operations it is trying to support. For example, wsn:Renew really depends on the developer because the notification messages are really coming from the underlying systems, not Muse itself. So even if Muse provides a stub class for Renew, a developer must still fill in the logic to make it do something. For now, the easiest way to support operations that Muse currently doesn't have base implementations for is to add the operation to muse.xml, and specify your own capability class that will provide the logic. -----Original Message----- From: Beil, Matthias [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 6:34 AM To: [email protected] Subject: AW: unsubscribe is a must Hi Dan, thanks for the reply. I personally don't need those methods. I'm an absolute beginner concerning the whole WS-* universe. I started with the WS-N spec and got through it. That's the point where I saw that for the base SubscriptionManager both methods are mandatory. As there are also already some mail threads about this issue I thought it might be useful to settle this by referencing to the spec. As I think it is useful to fulfil the WS-N spec. I will open the Jira item. Concerning the focus of Muse regarding the WSRF: As my focus is on the WS-N implementation, I was wondering why there was so much relationship to the WSRF spec. I think I still don't have a notion on how all those WS-* spec's are correlated to each other. As I wanted to progress with the WS-N implementation, I didn't want to go through the whole WSRF calls and dependencies. But as you said: All WS-N resources are WSRF resources. This is certainly the right way to implement it, but it is new for me and I though that there was from Muse a focus on the WSRF. So I'm still struggling with the relationship between Topic and Resources. As I opened already a thread on this issue, I would like to continue on this thread the issue what I want to achieve. Best regards, Matthias -----Ursprüngliche Nachricht----- Von: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Gesendet: Montag, 19. März 2007 14:11 An: [email protected] Betreff: Re: unsubscribe is a must If you really need unsubscribe() and renew(), just create a JIRA item for them. They are trivial to implement given our current code base, we only left them out because they seemed to duplicate existing WSRF operations (destroy() and setTerminationTime()). In my past experience with the WSN draft specs, unsubscribe() and renew() were defined for the cases where subscriptions were NOT ws-resources and thus, did not have WSRF capabilities. Since everything in Muse IS a ws-resource, and our WSN implementation does build on WSRF, we didn't have that problem. If the ratified standard has introduced a requirement, though, we will do it - but you still have to make a JIRA item. ;) I'm not sure why you think Muse isn't as focused on WSN (WSN certainly took more effort than WSDM). We use it for reporting the notifications defined in the standard, but other than that, it's up to you to package and send your custom notifications. More info here: http://ws.apache.org/muse/docs/2.2.0/manual/how-to/publish-any-notification.html http://ws.apache.org/muse/docs/2.2.0/manual/how-to/publish-wsrp-notifications.html Is there something else you're looking for in the implementation? Perhaps I can point out other features if you describe exactly what you want to achieve. Dan "Beil, Matthias" <[EMAIL PROTECTED]> wrote on 03/19/2007 05:25:22 AM: > Hi, > > > > after reading some mail threads for the unscribe method implementation > I had a look at the spec of WS-N > > > > http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.pd > f > > > > at the chapter 6. line 1134 they state: > > > > All SubscriptionManagers MUST implement the message exchanges > described in the Base Subscription Manager section. > > > > In the next chapter 6.1 at line 1142 the spec states: > > > > The basic behavior of a SubscriptionManager is to renew the duration > of a Subscription resource and terminate a Subscription. > > > > In the mailing thread there was the suggestion to use the returned > subscription to destroy the subscription, but in my regard the > "unsubscribe" method should be used to adhere to the WS-N spec. > > > > My personal impression after 5 days of using Muse is, that Muse is > more focused on the WSDM and the WSRF capabilities and that the WS-N > serves only as a delivery channel for informing the connected clients > of resource changes. > > > > As my focus is on the WS-N spec. and the workflow defined to exchange > notification, my interest is more in having a complete WS-N > implementation. And from this point of view are there some plans to > and the "renew" and "unsubscribe" methods? > > > > Mit freundlichen Gruessen / With kind regards > > Matthias Beil > > > --------------------------------------------------------------------- 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]
