[wsf-c-dev] Re: [wsf-java-dev] Client API for Eventing

[Chamikara Jayalath]

Hi Paul,

Mostly I agree. But I think the proposed functionality should come in a 
different tool that is separate from the general eventing client API 
(I.e. the EventingClient  class). 

The implementation will not be that difficult. We can have a API like 
following.

NotificationManager.createListenerEndpoint (Callback callback): 
EndpointReference

Underneath the NotificationManager will be

1 starting a listener (if one has not already been started)
2. deploying a service instance to it wrapping the passed callback.
3. returning the endpoint reference of this service instance.

Then the user can pass this EndpointReference as the delivery EPR of the 
EventingClient.

I see unsubscription and 'stopping the listener' as two separate issues. 
The user should be able to subscribe to two different eventing sources 
with the same delivery EPR and later unsubscribe from one of them 
without stopping the client listener.

XMPP subscription will behave the same way.  It is just another 
transport in Axis2.

Chamikara



Paul Fremantle wrote:
> One of our customers has asked us what the "client" api to receive 
> notifications is with WS-Eventing.
>
> Normally, the receiver of notifications is in fact a service, and so 
> would be implemented by a service. However, this isn't always the 
> easiest model for a developer who wants to see notifications.
>
> So my proposal is that we think of notifications like the response 
> half of an async interaction - i.e. a callback.
>
> So we could basically allow a user to subscribe to a service, and pass 
> the callback handler.
>
> This would do:
> 1) start the simple HTTP server listener just like when you do 
> setUseSeparateListener(true)
> 2) Create a new endpoint on that listener
> 3) Register the callback as the handler for any messages coming into 
> that endpoint
> 4) Send that EPR as the subscription EPR to the Eventing source
>
> We could also ensure that unsubscribing to the endpoint de-activated 
> the HTTP listener (I guess we'd need a counter in case there were 
> other subscribers using the listener). We could also make sure that 
> the HTTP listener timed out in line with the subscription.
>
> I'd also like us to think about other transports. For example, can we 
> make an XMPP subscription behave the same.
>
> Paul
>
> PS I think we should also think about Atom. I've got some ideas but 
> they aren't fully formed yet.
>


-- 
Chamikara Jayalath
WSO2 Inc.
http://wso2.com/
http://wso2.org/ - For your Oxygen needs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wso2.org/pipermail/wsf-c-dev/attachments/20070330/96c2d04f/attachment.htm