I think the issue here is that the spec doesn't define how you should implement a PullPoint. It just defines how it should behave.
A PullPoint allows a user to directly retrieve messages from the underlying system/datasource. Muse itself is unaware of an implementor's datasource. So, a developer like me and you would have to implement our own PullPoint logic to directly pull messages from our own backend. Remember, integration is rarely automated:) So Muse's default PullPoint basically acts as a notification consumer and producer. It subscribes for notifications, becomes a sink for the messages, and allows a user to retrieve those messages in case the real producer itself (i.e. the backend) doesn't cache a history of those messages. So out of the box, at least this PullPoint implementation can be useful for some people. It does require some tweaking though, like if an implementor wants to limit how long the messages stay in the cache. Since you want a PullPoint to not be a consumer/cacher at all, you'd have to override Muse's implementation and provide your own logic to retrieve messages from your backend. Clients can still subscribe to your PullPoint, but you'd have the generate the messages yourself. Muse can't provide that logic for you. -----Original Message----- From: Marjan Sterjev [mailto:[EMAIL PROTECTED] Sent: Friday, July 13, 2007 4:12 AM To: [email protected] Subject: RE: PullPoint default (simple) implementation bug Hi, I strongly disagree with you explanationJ. I don't want to cite the specification again. The idea behind a PullPoint and the usage pattern are clearly specified in that document and they are different from what you explained here. The basic functionality is having an ability a client behind a firewall being an able to pull stored messages. This is the first aspect. The second aspect is why should PullPoint store every notification (situation) for each possible topic bound to the Notification Producer in interset (it is a waste of memory or db resources as well as network bandiwth for transfering something that will be rejected anyway). I believe that multiple change requests will arise related to this "issue" in the future when more and more people start using PullPoint functionality. Thanks for your comments anyway. Regards, Marjan -----Original Message----- From: Vinh Nguyen (vinguye2) [mailto:[EMAIL PROTECTED] Sent: Friday, July 13, 2007 12:24 PM To: [email protected] Subject: RE: PullPoint default (simple) implementation bug Hi Marjan, I think that's the correct behavior by design. A PullPoint is itself a consumer, too, although its primary responsibility is to cache the notifications so that clients can request the history of notifications at any given point in time. So when you create a PullPoint, it should automatically subscribe itself for notifications. Otherwise, it will never get notifications from the real producer. Then, for your client to receive notifications from the PullPoint, you'd have to subscribe to the PullPoint, too. In this case, the PullPoint also acts as a "producer". Or, you don't have to subscribe to it, but just call various operations directly on it to retrieve the stored notifications as needed. If you don't want your PullPoint to automatically subscribe upon initialization, you can override the Muse implementation. But, then you'd have to explicitly subscribe the PullPoint for notifications from the producer at some point, else it won't get any notifications to store. -----Original Message----- From: Marjan Sterjev [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 11:17 PM To: [email protected] Subject: RE: PullPoint default (simple) implementation bug Hi Vinh, That's I'm talking about. When we create a PullPoint, subscription is automatically created and only this automatically created one is bound to the PullPoint. If we use NotificationProducerClient in order to subscribe to the PullPoint using filtering, we are creating the second subscription and this one is not bound the PullPoint in the current implementation. Thanks Marjan Sterjev -----Original Message----- From: Vinh Nguyen (vinguye2) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 8:56 PM To: [email protected] Subject: RE: PullPoint default (simple) implementation bug Hi Marjan, I haven't used the PullPoint implementation yet, but for your question about the filter, I think you would pass that in the Subscribe operation. So the subscription does the filtering on the "server" end, instead of the PullPoint "consumer" end. Of course, you can still take advantage of the notification consumer framework to apply further filtering on the consumer end. The PullPoint itself can just act as a storage. -----Original Message----- From: Marjan Sterjev [mailto:[EMAIL PROTECTED] Sent: Thursday, July 12, 2007 2:35 AM To: [email protected] Subject: PullPoint default (simple) implementation bug Hi, I didn't get any response on my question about PullPoint working example, so I was investigating and digging the source code in the mean time (it is always about time). I added the required WSDL modifications for PullPoint and CreatePullPoint port types and I was able to create PullPoint. However GetMessages operation returns no messages at all. Why? The Muse PullPoint simple implementations didn't work without modifications and recompilation of the code. The problem is with the class org.apache.muse.ws.notification.impl.SimplePullPoint in the method accepts(). public boolean accepts(NotificationMessage message) { EndpointReference subEPR = message.getSubscriptionReference(); //return subEPR != null && getSubscription().equals(subEPR); return subEPR != null && subEPR.equals(getSubscription().getEndpointReference()); } I commented the wrong line and added the correct line comparing objects of the same type, i.e. getSubscription() should be replaced with getSubscription().getEndpointReference()). The Muse PullPoint implementation mechanism is rather strange. The specification (wsn-ws_base_notification-1.3-spec-os.pdf page 25) says: The intended pattern of use is that a Subscriber or other party creates a PullPoint through the factory interface, and then uses it as the ConsumerReference in one or more Subscribe requests. The actual consumer then pulls Notifications from the PullPoint. I was following this pattern, i.e. I created PullPoint and after that I was using the returned ConsumerReference in a separate Subscribe request. I found that this way we get 2 subscriptions. We can see that in the class org.apache.muse.ws.notification.impl.SimplePullPointCreation subscription is automatically created when the PullPoint is created. Is this correct? Subscription on what? The Simple implementation produces subscription using PublishAllMessagesFilter: public Filter getFilter() { return PublishAllMessagesFilter.getInstance(); } Ok, someone can argue that we can write our own implementations that will support filtering. However the question is how we can supply filter parameters? The interface org.apache.muse.ws.notification.Interface PullPointCreation has method createPullPoint(), i.e. there are no arguments at all. Am I missing something? Regards Marjan --------------------------------------------------------------------- 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]
