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]
