Thanks Dan, It's clear now. I think I've been confusing myself after looking at so much stuff lately, that I forgot about the couple lines in ConsumerCapabilityImpl where it added itself as the message listener. So receiving notifications is a 2-step process:
1) Subscribe a resource to the notification producer. This specifies the EPR where XML notification messages should be sent to. 2) The resource that receives the notifications (consumer) must implement a NotificationMessageListener, which can actually do something with the messages. The NotificationConsumer object in the consumer resource manages the message listeners, and will pass messages to the corresponding listeners when the XML notifications are received. For some reason, I got confused and was thinking that the producer needed to figure out what object to directly invoke in the consumer resource, in order to pass the notification message to. Not sure why I was thinking that:) -----Original Message----- From: Daniel Jemiolo [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 06, 2006 10:49 AM To: [email protected] Subject: Re: wsn consumer The NotificationConsumer implementation handles the firing of NotificationMessageListeners for each message received throughthe Notify operation. These NotificationMessageListener objects can be registered at any time using the NotificationConsumer's add/removeListener() methods. The objects do *not* have to be capability implementations - they just have to implement the NotificationMessageListener interface. Normal Java stuff. In the wsn-consumer example, there is not much code, so I just made the capability double as the listener and add itself (addListener(this)). I could have also created a separate class, instantiated it, and added that object with addListener(). Either way is fine. For more complicated listeners, the latter is probably better. To make it so that a listener only executes its tasks for a specific producer, you need to implement the NotificationMessageListener.accepts() method such that the producer's EPR is taken into consideration. Something like: ----------------- start sample code ---------------------- public class MyListener implements NotificationMessageListener { public boolean accepts(NotificationMessage message) { EndpointReference producer = message.getProducerReference(); // test EPR content to verify producer's identity } public void processMessage(NotificationMessage message) { // this is only called if accepts() returns 'true' } } ----------------- end sample code ------------------------ If you are filtering based on producer, I imagine you are going to add some constructor code that will allow you to tell the object what producer(s) it is responding to. Of course, if you have one WS-resource instance responding to notifications from multiple resource types, I imagine the topics and message patterns of the events will be quite different... a more robust solution might be to filter based on the topics or XPath. Also, since you can add/remove listeners at any time, you can also create listeners for a specific subscription, at the time of the subscription: ----------------- start sample code ---------------------- public class MySubscriptionListener implements NotificationMessageListener { private EndpointReference _mySubscription = null; public MySubscriptionListener(EndpointReference subscription) { _mySubscription = subscription; } public boolean accepts(NotificationMessage message) { EndpointReference subscription = message.getSubscriptionReference(); return _mySubscription.equals(subscription); } public void processMessage(NotificationMessage message) { ... } } ... // // code to make a subscription and then create a listener for it // NotificationProducerClient producer = new NotificationProducerClient(...); SubscriptionClient subscription = producer.subscribe(...); EndpointReference subEPR = subscription.getEndpointReference(); MySubscriptionListener listener = new MySubscriptionListener(subEPR); NotificationConsumer nc = getResource().getCapability(WsnConstants.CONSUMER_URI); nc.addListener(listener); ----------------- end sample code ------------------------ Does this clarify your options? Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 12/06/2006 03:42:54 AM: > In the wsn-consumer example, the code shows how to register a resource > as a notification consumer. Then, to receive the notifications, the > NotificationMessageListener interface must be implemented. In the > example, this is done by a ConsumerCapabilityImpl capability class > associated with the "consumer" resource. > > My question is: how does Muse know what resource component to call in > order to pass the notification message? Does it scan thru the > consumer resource's list of capability classes and invoke the one the > implements the NotificationMessageListener interface? The muse.xml > descriptor file doesn't seem to have a place to explicitly tell Muse > what class to call, but somehow Muse knows already. > > So what happens if my resource has 2 capability classes, both of which > are NotificationMessageListeners. How does Muse know which one to call? > > There's also the case where each of the 2 capability classes can be > listening to notifications from different producers (i.e. different > Muse applications). > --------------------------------------------------------------------- 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]
