On Wed, Feb 16, 2011 at 9:56 AM, Amila Suriarachchi <[email protected]> wrote:
> > > On Wed, Feb 16, 2011 at 8:16 AM, Srinath Perera <[email protected]> wrote: > >> I will schedule a meeting early next week. --Srinath >> > > +1. > > From the registry side, I think first we need to consider how registry > suppose to work with eventing. > > In the current implementation there is a concept of subscribing to a > resource. But always users need to subscribe to > a topic. The person who subscribes to the topic should not have any idea of > the type of event source but the event message format. > > In the current implementation when someone subscribes to a resource, > registry create a topic with that resource name and > subscribe to user to it. Then when ever some change happen it publish the > event to the broker. > > But I think this should have happen like this. When someone create a > registry resource, registry should create a topic > in the broker for that resource (if creating topis for all resources > inefficient we can have a parameter like use as an event soruce ). Then when > ever some change happens registry has to publish that event with some > generic format to the event broker. Now who ever the interesting user for > this topic can subscribe to it either using ws-Eventing or JMS (or event > osgi level). > In other words all the other components (Registry, ESB, DSS, BAM data publisher) have to assume them selves as event sources. I.e. they need to create a topic and publish events to that. Who ever interesting can subscribes to those topics with ws-eventing and jms. If the message format generated by those event sources are not in the format subscribers need they have to subscribe through a proxy service which does necessary mediation and transformations. thanks, Amila. > > And also old event core support some xslt transformation to format events. > This should also done by subscribing through a proxy service to do any > transform and mediation required at proxy service level. > > And also current event implementation does not support > 1. Multi tenancy. > Old event implementation also does not have this support (at least I > can not find any related code in EmbeddedRegistryBasedSubscriptionManager). > In order to add this feature we need to save the topic space to tenant > registry and see how Qpid supports multitenancy. > > 2. Clustering > We have not thought of this yet. > > In summary what we have to do is to first figure out correct event model > for registry, then find gaps in the event componet and fix them. After that > registry should implement that model rather than thinking it as an API > conversion. > > For others (BAM, DSS) we can have a hackaton and fix any issues related to > builds. > > thanks, > Amila. > > > > >> On Tue, Feb 15, 2011 at 10:03 PM, Amila Suriarachchi <[email protected]> >> wrote: >> > >> > >> > On Tue, Feb 15, 2011 at 9:39 PM, Hiranya Jayathilaka <[email protected]> >> > wrote: >> >> >> >> >> >> On Tue, Feb 15, 2011 at 9:35 PM, Amila Suriarachchi <[email protected]> >> >> wrote: >> >>> >> >>> >> >>> On Tue, Feb 15, 2011 at 3:23 PM, Hiranya Jayathilaka < >> [email protected]> >> >>> wrote: >> >>>> >> >>>> >> >>>> On Tue, Feb 15, 2011 at 3:08 PM, Hiranya Jayathilaka < >> [email protected]> >> >>>> wrote: >> >>>>> >> >>>>> A Few days back we had a discussion about migrating the ESB to the >> new >> >>>>> eventing component and realized that there are several things to be >> done in >> >>>>> this space. We also need some features to be implemented in the >> eventing >> >>>>> component before we can do a proper migration. So I think we should >> take >> >>>>> this slow. And as Senaka has mentioned, if there are MT related >> issues etc, >> >>>>> we better make sure that are properly dealt with first. >> >>>> >> >>>> Having said that, we also need a plan for implementing the necessary >> >>>> features in the new eventing component. I can think of following >> >>>> requirements: >> >>>> 1. Support hierarchical subscriptions (which is the root of this >> >>>> discussion) >> >>>> 2. Support static subscriptions >> >>>> 3. Ability to configure topics etc through a configuration file >> >>>> Do we have a plan for implementing these stuff? In the mean time >> product >> >>>> teams can do the necessary evaluations and initiate the migration >> process if >> >>>> things are in order. May be Amila can do an intro session to the >> teams >> >>>> describing the new API, features etc so we can see how easy or >> difficult to >> >>>> use the new component? >> >>> >> >>> +1. >> >>> >> >>> These features were not there with the old event implementation as >> well. >> >>> So it has nothing to do with the new event API. >> >> >> >> Synapse event sources impl supports 2 and 3. So we want the new API to >> >> support them too. >> > >> > +1. to support them with the new event API. But first we need to solve >> the >> > problem regarding conflicting services. >> > >> > thanks, >> > Amila. >> >> >> >> Thanks, >> >> Hiranya >> >> >> >>> >> >>> I think there is a confusion between eventing and event. What I >> recently >> >>> done was changing the API of the event component. >> >>> >> >>> thanks, >> >>> Amila. >> >>> >> >>>> >> >>>> Thanks, >> >>>> Hiranya >> >>>> >> >>>>> >> >>>>> Thanks, >> >>>>> Hiranya >> >>>>> >> >>>>> On Tue, Feb 15, 2011 at 2:58 PM, Afkham Azeez <[email protected]> >> wrote: >> >>>>>> >> >>>>>> Yes, it seems that multiple people have messed up (there is a >> better >> >>>>>> word for this, but I cannot say it on a public mailing list) the >> eventing >> >>>>>> API. Don't do a hackathon and **** it up any further. >> >>>>>> Azeez >> >>>>>> >> >>>>>> On Tue, Feb 15, 2011 at 2:55 PM, Senaka Fernando <[email protected]> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> On Tue, Feb 15, 2011 at 1:57 PM, Tharindu Mathew < >> [email protected]> >> >>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> NACK from the product teams. :) >> >>>>>>>> How about Monday next week for a hackathon to go for the new >> event >> >>>>>>>> implementation? >> >>>>>>> >> >>>>>>> -1 for looking into this in a haste. We need to come up with a >> proper >> >>>>>>> execution plan before moving into the new API. For instance, this >> has >> >>>>>>> changed all data-types, and the way MT is handled in eventing etc. >> So, >> >>>>>>> unless the migration is clear enough, its a lot of work, >> especially from the >> >>>>>>> products which have mature eventing implementations. >> >>>>>>> >> >>>>>>> So, let's have a meeting on Monday first, and then decide on the >> best >> >>>>>>> way forward. >> >>>>>>> >> >>>>>>> Thanks, >> >>>>>>> Senaka. >> >>>>>>> >> >>>>>>>> >> >>>>>>>> I suppose at least a member for eachl products who use eventing >> >>>>>>>> should be present for this. I'm not sure which products do not >> use eventing! >> >>>>>>>> >> >>>>>>>> On Sun, Feb 13, 2011 at 12:57 PM, Afkham Azeez <[email protected]> >> >>>>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>> +1 >> >>>>>>>>> >> >>>>>>>>> On Sunday, February 13, 2011, Tharindu Mathew < >> [email protected]> >> >>>>>>>>> wrote: >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > On Sun, Feb 13, 2011 at 9:50 AM, Amila Suriarachchi >> >>>>>>>>> > <[email protected]> wrote: >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > On Sun, Feb 13, 2011 at 8:48 AM, Afkham Azeez <[email protected] >> > >> >>>>>>>>> > wrote: >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > This is something urgently needed for mars since the existing >> >>>>>>>>> > synchronizer has many issues. So Mars cannnot live with it. >> Can we get this >> >>>>>>>>> > fixed urgently? >> >>>>>>>>> > Registry still uses the old event implementation. so we need >> to >> >>>>>>>>> > figure out which version should have this feature. >> >>>>>>>>> > >> >>>>>>>>> > In the new model if the Qpid support this we can add the >> feature >> >>>>>>>>> > easily. >> >>>>>>>>> > >> >>>>>>>>> > To avoid this issue of old and new event implementation, shall >> we >> >>>>>>>>> > have a hackathon to move all products to the new >> implementation? >> >>>>>>>>> > >> >>>>>>>>> > thanks, >> >>>>>>>>> > Amila. >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> > ------ >> >>>>>>>>> > Sent from my APD® >> >>>>>>>>> > On Feb 13, 2011 12:09 AM, "Hiranya Jayathilaka" >> >>>>>>>>> > <[email protected]> wrote:> Hi, >> >>>>>>>>> >> >> >>>>>>>>> >> On Sat, Feb 12, 2011 at 9:29 PM, Amila Suriarachchi >> >>>>>>>>> >> <[email protected]> wrote: >> >>>>>>>>> >> >> >>>>>>>>> >>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> On Sat, Feb 12, 2011 at 9:15 PM, Senaka Fernando >> >>>>>>>>> >>> <[email protected]> wrote: >> >>>>>>>>> >>> >> >>>>>>>>> >>>> Hi Hiranya, >> >>>>>>>>> >>>> >> >>>>>>>>> >>>> On Sat, Feb 12, 2011 at 3:17 PM, Hiranya Jayathilaka >> >>>>>>>>> >>>> <[email protected]>wrote: >> >>>>>>>>> >>>> >> >>>>>>>>> >>>>> Hi Folks, >> >>>>>>>>> >>>>> >> >>>>>>>>> >>>>> I have developed a component which subscribes for the >> >>>>>>>>> >>>>> CollectionUpdate >> >>>>>>>>> >>>>> event of a particular collection in the registry >> >>>>>>>>> >>>>> (/repository/deployment/server). This collection can have >> a >> >>>>>>>>> >>>>> lot of >> >>>>>>>>> >>>>> sub-collections and child resources. Now if I add/remove a >> >>>>>>>>> >>>>> resource directly >> >>>>>>>>> >>>>> under the above collection my component receives the >> update >> >>>>>>>>> >>>>> event. But if >> >>>>>>>>> >>>>> something happens in a sub-collection or if I update a >> child >> >>>>>>>>> >>>>> resource (eg: >> >>>>>>>>> >>>>> modify content) nothing happens. >> >>>>>>>>> >>>>> >> >>>>>>>>> >>>>> Is there a way to subscribe to the collection, so that any >> >>>>>>>>> >>>>> update to the >> >>>>>>>>> >>>>> collection or its children will fire an event? >> >>>>>>>>> >>>>> >> >>>>>>>>> >>>> >> >>>>>>>>> >>>> IIRC, Srinath, and I discussed this before, and we agreed >> to >> >>>>>>>>> >>>> provide some >> >>>>>>>>> >>>> mechanism to programatically subscribe to /foo/bar/* which >> >>>>>>>>> >>>> will make it >> >>>>>>>>> >>>> possible to capture events for sub-collections under bar. >> I'm >> >>>>>>>>> >>>> not sure >> >>>>>>>>> >>>> whether this made it to the event component's source code. >> >>>>>>>>> >>>> >> >>>>>>>>> >>> >> >>>>>>>>> >>> This feature is not there with the existing code. (both new >> and >> >>>>>>>>> >>> old) But we >> >>>>>>>>> >>> plan to put it in a future release. >> >>>>>>>>> >>> >> >>>>>>>>> >> >> >>>>>>>>> >> Thanks Amila and Senaka for the clarifications. Based on this >> it >> >>>>>>>>> >> seems we >> >>>>>>>>> >> have to change our plans for the deployment synchronizer >> >>>>>>>>> >> component (registry >> >>>>>>>>> >> based repository) a little bit. Our intention was to use the >> >>>>>>>>> >> registry >> >>>>>>>>> >> eventing model to monitor the collection and checkout the >> >>>>>>>>> >> contents to the >> >>>>>>>>> >> file system only when needed. We'll have to live with the >> >>>>>>>>> >> existing periodic >> >>>>>>>>> >> checkout model for a while until this feature is implemented >> in >> >>>>>>>>> >> registry >> >>>>>>>>> >> eventing. >> >>>>>>>>> >> >> >>>>>>>>> >> Thanks, >> >>>>>>>>> >> Hiranya >> >>>>>>>>> >> >> >>>>>>>>> >> >> >>>>>>>>> >>> >> >>>>>>>>> >>> thanks, >> >>>>>>>>> >>> Amila. >> >>>>>>>>> >>> >> >>>>>>>>> >>>> >> >>>>>>>>> >>>> From the Registry PoV we generate events for all updates, >> and >> >>>>>>>>> >>>> we rely on >> >>>>>>>>> >>>> the SubscriptionManager to return a list of endpoints >> >>>>>>>>> >>>> subscribed to a topic. >> >>>>>>>>> >>>> >> >>>>>>>>> >>>> Thanks, >> >>>>>>>>> >>>> Senaka. >> >>>>>>>>> >>>> >> >>>>>>>>> >>>>> >> >>>>>>>>> >>>>> Thanks >> >>>>>>>>> >>>>> -- >> >>>>>>>>> >>>>> Hiranya Jayathilaka >> >>>>>>>>> >>>>> Senior Software Engineer; >> >>>>>>>>> >>>>> WSO2 Inc.; http://wso2.org >> >>>>>>>>> >>>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >> >>>>>>>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com >> >>>>>>>>> >>>>> >> >>>>>>>>> >>>>> _______________________________________________ >> >>>>>>>>> >>>>> Carbon-dev mailing list >> >>>>>>>>> >>>>> [email protected] >> >>>>>>>>> >>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>>>>> >>>>> >> >>>>>>>>> >>>>> >> >>>>>>>>> >>>> >> >>>>>>>>> >>>> >> >>>>>>>>> >>>> -- >> >>>>>>>>> >>>> *Senaka Fernando* >> >>>>>>>>> >>>> Product Manager - WSO2 Governance Registry; >> >>>>>>>>> >>>> Associate Technical Lead; WSO2, Inc.; http://wso2.com* >> >>>>>>>>> >>>> Member; Apache Software Foundation; http://apache.org >> >>>>>>>>> >>>> >> >>>>>>>>> >>>> E-mail: senaka AT >> >>>>>>>>> > >> >>>>>>>>> > -- >> >>>>>>>>> > Regards, >> >>>>>>>>> > >> >>>>>>>>> > Tharindu Mathew >> >>>>>>>>> > Software Engineer,WSO2 Inc.,http://wso2.com >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> *Afkham Azeez* >> >>>>>>>>> Senior Software Architect & Senior Manager; WSO2, Inc.; >> >>>>>>>>> http://wso2.com, >> >>>>>>>>> * >> >>>>>>>>> * >> >>>>>>>>> *Member; Apache Software Foundation; >> >>>>>>>>> **http://www.apache.org/*<http://www.apache.org/> >> >>>>>>>>> * >> >>>>>>>>> email: **[email protected]* <[email protected]>* cell: +94 77 3320919 >> >>>>>>>>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >> >>>>>>>>> twitter: >> >>>>>>>>> **http://twitter.com/afkham_azeez*< >> http://twitter.com/afkham_azeez> >> >>>>>>>>> * >> >>>>>>>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >> >>>>>>>>> * >> >>>>>>>>> * >> >>>>>>>>> *Lean . Enterprise . Middleware* >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> Carbon-dev mailing list >> >>>>>>>>> [email protected] >> >>>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Regards, >> >>>>>>>> >> >>>>>>>> Tharindu Mathew >> >>>>>>>> Software Engineer, >> >>>>>>>> WSO2 Inc., >> >>>>>>>> http://wso2.com >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> Carbon-dev mailing list >> >>>>>>>> [email protected] >> >>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Senaka Fernando >> >>>>>>> Product Manager - WSO2 Governance Registry; >> >>>>>>> Associate Technical Lead; WSO2, Inc.; http://wso2.com >> >>>>>>> Member; Apache Software Foundation; http://apache.org >> >>>>>>> >> >>>>>>> E-mail: senaka AT wso2.com >> >>>>>>> P: +1 408 754 7388; ext: 51736; M: +94 77 322 1818 >> >>>>>>> Linked-In: http://www.linkedin.com/in/senakafernando >> >>>>>>> >> >>>>>>> Lean . Enterprise . Middleware >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Carbon-dev mailing list >> >>>>>>> [email protected] >> >>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Afkham Azeez >> >>>>>> Senior Software Architect & Senior Manager; WSO2, Inc.; >> >>>>>> http://wso2.com, >> >>>>>> >> >>>>>> Member; Apache Software Foundation; http://www.apache.org/ >> >>>>>> email: [email protected] cell: +94 77 3320919 >> >>>>>> blog: http://blog.afkham.org >> >>>>>> twitter: http://twitter.com/afkham_azeez >> >>>>>> linked-in: http://lk.linkedin.com/in/afkhamazeez >> >>>>>> >> >>>>>> Lean . Enterprise . Middleware >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Carbon-dev mailing list >> >>>>>> [email protected] >> >>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Hiranya Jayathilaka >> >>>>> Senior Software Engineer; >> >>>>> WSO2 Inc.; http://wso2.org >> >>>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >> >>>>> Blog: http://techfeast-hiranya.blogspot.com >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Hiranya Jayathilaka >> >>>> Senior Software Engineer; >> >>>> WSO2 Inc.; http://wso2.org >> >>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >> >>>> Blog: http://techfeast-hiranya.blogspot.com >> >>>> >> >>>> _______________________________________________ >> >>>> Carbon-dev mailing list >> >>>> [email protected] >> >>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Carbon-dev mailing list >> >>> [email protected] >> >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>> >> >> >> >> >> >> >> >> -- >> >> Hiranya Jayathilaka >> >> Senior Software Engineer; >> >> WSO2 Inc.; http://wso2.org >> >> E-mail: [email protected]; Mobile: +94 77 633 3491 >> >> Blog: http://techfeast-hiranya.blogspot.com >> >> >> >> _______________________________________________ >> >> Carbon-dev mailing list >> >> [email protected] >> >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> >> > >> > >> > _______________________________________________ >> > Carbon-dev mailing list >> > [email protected] >> > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > >> > >> >> >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> Senior Software Architect, WSO2 Inc. >> Visiting Lecturer, University of Moratuwa >> Member, Apache Software Foundation >> Research Scientist, Lanka Software Foundation >> Blog: http://srinathsview.blogspot.com/ >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > >
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
