Asanka The current implementation implements the following: * A flexible model of storing subscriptions. A subscription is logically some combination of a filter, a sequence and an endpoint. This extends the WS-Eventing core model with the idea of a sequence. * This model is implemented through a "subscription manager" interface, which can then be exposed via WS-Eventing, Notification or some other API or interface. If you try to delete subscriptions or add them to some kind of read-only SubScription Manager then you would get a fault. * So far we aren't implementing WS-N, just WS-Eventing. * The way we have modelled static subscriptions is very basic: they are simply added into the subscription manager at start/init time. So if you delete them then they stay deleted till next reboot. However, I think its highly unlikely anyone is going to try to delete a static subscription using WS-Eventing!!!
You would logically plug in something like Esper as a different filter. I haven't exactly figured out how that would work yet :) Paul On Fri, Sep 19, 2008 at 10:31 AM, Asanka Abeysinghe <[EMAIL PROTECTED]> wrote: > Hi, > I'm not clear about the dynamic subscriptions, current implementation will > provide 3 options, using WS-Eventing, WS-Notification and user define > messages, how we are going to identify the subscription in the user define > mode ? What happens when a user unsubscribe for a static subscriptions ? > (Remove it or stop sending till the instance up) What happens when a user > unsubscribe where registry is on read only mode ? > With the current model synapse act as the event processing engine and the > event channel, IMO we have to make provision to plug a CEP (like Esper) to > the model as well. > Asanka A. > Ruwan Linton wrote: >> >> Sorry Paul, I was also unable to comment on your last queries.... as you >> may know I am traveling. I think the above 2 points that you made have some >> interesting value in it. Therefore I would like to keep the ability to >> configure the event source and the notification service sections in the >> configuration. >> >> As you told, I just started the implementation and you can expect the >> initial version soon. For that lets go with the proposed configuration and I >> will keep the two elements to configure the notification section and >> publishing section. >> >> BTW: I am seeing a test failure in the trunk? Do any one know the reason >> for this? Andreas? >> >> (PS: please make sure all tests are passing before commit) >> >> Thanks, >> Ruwan >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Paul Fremantle Co-Founder and CTO, WSO2 Apache Synapse PMC Chair OASIS WS-RX TC Co-chair blog: http://pzf.fremantle.org [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
