Hi,
On Wed, Oct 2, 2013 at 9:06 PM, Lasantha Fernando <[email protected]> wrote: >>> >>>> Hi all, >>>> >>>> The following changes were proposed to CEP 3.0.0 to improve the >>>> usability of CEP. >>>> >>>> 1) EventStream UI is the central place to store all the event streams. >>>> Event stream management will be decoupled from the EB/EF/EP components and >>>> a separate component will be created to manage event streams. >>>> >>>> 2) Execution Plan UI is the main UI that user is going to use. It will >>>> popup a dialog to create event streams if a new event stream is needed. It >>>> will also pop up event builder creation dialog and event formatter creation >>>> dialog if it is needed for the user. >>>> >>>> But it will not store any values in the backend until the execution >>>> plan is saved and will save all the related configurations once as an >>>> atomic transaction. >>>> >>> It is OK to do that if that make it easier for you to implement (but it >>> is not a requirements). >>> >> >> I think I made everyone misunderstand by using a word like 'atomic >> transaction'... :-). What I meant was something like this. >> >> If the user is doing a custom mapping and wants to save an event >> builder/formatter, I think we can save it then and there at the time of >> creation in the UI. >> >> However, if the user opts to just create a stream definition and just >> saves the execution plan, the event processor component will have the >> responsibility of creating an event builder (or formatter) to match that >> stream which allows passthrough of events. The event builder would do >> nothing and simply expose the stream definition that is already incoming >> via the event adaptor. >> >> However, after saving this automatically created builder, when trying to >> save the execution plan, there might be some exception due to incorrect >> siddhi syntax or because some other dependency for the execution plan to >> become active is not met. In that case, the execution plan might not get >> deployed at all and the created event builder will be leftover. I was >> thinking that to maintain consistency, in such a case, we would have to >> ensure that the created event builder would be deleted as well (or the >> steps done so far be rollbacked). >> >> If it is an edge case, then am OK with simply trying to deploy the >> execution plan + associated event builder + associated event formatter and >> in case of some deployments being unsuccessful, we can simply leave the >> artifact in inactive/faulty state. >> > > Ah ok, yes we should cleanup if the execution deployment failed. > >> >> >>> >>>> The saving of the execution plan can include the following sub steps. >>>> >>>> 1. Create a related event-builder (optional) >>>> >>>> 2. Create an execution plan (mandatory) >>>> >>>> 3. Create related event-formatters (optional) >>>> >>>> 4. Create stream definitions >>>> >>>> Out of the above sub steps, only step 4 will be persisted to the >>>> backend immediately (since stream definitions are independent from the flow >>>> configuration). Persisting configuration of sub steps 1-3 would go to >>>> backend at once and the event-processor component will have the >>>> responsibility of creating the needed event-builders/formatters and ensure >>>> the wiring of the flow properly. >>>> >>>> Also, for the case of custom mapping for event builders, changing the >>>> event builder mapping will effectively change the stream definition that is >>>> exported by the event builder. Since this stream definition is managed by >>>> another component, I think we would have to decide on a policy on whether >>>> we cascade changes for a builder or not. Some possible options regarding >>>> this will be >>>> >>>> 1. When event builder mapping is changed, the exported stream >>>> definition will change >>>> >>>> 2. When the event builder mapping is changed, we force the user to >>>> change the associated streamdef name or version >>>> >>>> Similarly, when changing the stream definition, we would need to decide >>>> how the changes will be handled by the separate components. >>>> >>> >>> Stream definition is the first class thing. There is no concept of >>> builder importing an stream definition. Builder must agree with stream >>> definition. >>> If user change stream definition, we mark corresponding builders/ >>> formatters as faulty. If user try to change the builder/ formatter and it >>> does not agree with stream definition, we throw an error. So you first fix >>> stream definition, then fix the builder. >>> >> >> Hmm... am totally +1 with this from an architectural point of view. It >> will be clean. But from a usability perspective, it will be a bit of a >> hassle to the user if they want to change the stream definition since they >> will have to change in one more additional place when changing the stream >> definition. But probably this is an unavoidable issue and maybe we can >> think of something to make it a bit more user-friendly for the next release? >> > > I think it is unavoidable. Lets do the simple version for this round. > +1 for the approach.. I think as Srinath mentioned it is unavoidable if going to make Streams as higher level.. > > >> >> >>> >> >>>> We would also have to address the issue of the event processor >>>> component attempting to deploy artifacts related to two other components in >>>> a transactional manner as well. >>>> >>> IMHO this is not a requirement. Number of CEP artifact deployments will >>> be small, and we do not need to worry about transactions here. We make >>> similar assumptions with Carbon Admin UI. >>> >>> >> >> Well, actually I was referring to the scenario described above. If it is >> not an issue with a big impact, will implement so that the different >> artifacts belonging to different components are deployed in a fire and >> forget manner... :-) >> > It is OK to cleanup as I mentioned above. > Since, we have a better clean solution, we'll go and implement this and will fix, if there any issues arises.. Regards, Mohan > >> >>> >>>> Please share your thoughts/suggestions on the proposed changes. >>>> >>> >> Will also create some diagrams regarding the architecture and send.... :-) >> >> Thanks, >> Lasantha >> >> >>> >>>> @Mohan, Rajeev, Suho - Please add if I’ve missed anything from the >>>> changes discussed. >>>> >>>> >>>> Thanks, >>>> >>>> Lasantha >>>> >>>> >>>> -- >>>> *Lasantha Fernando* >>>> Software Engineer - Data Technologies Team >>>> WSO2 Inc. http://wso2.com >>>> >>>> email: [email protected] >>>> mobile: (+94) 71 5247551 >>>> >>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> Director, Research, WSO2 Inc. >>> Visiting Faculty, University of Moratuwa >>> Member, Apache Software Foundation >>> Research Scientist, Lanka Software Foundation >>> Blog: http://srinathsview.blogspot.com/ >>> Photos: http://www.flickr.com/photos/hemapani/ >>> Phone: 0772360902 >>> >> >> >> >> -- >> *Lasantha Fernando* >> Software Engineer - Data Technologies Team >> WSO2 Inc. http://wso2.com >> >> email: [email protected] >> mobile: (+94) 71 5247551 >> > > > > -- > ============================ > Srinath Perera, Ph.D. > Director, Research, WSO2 Inc. > Visiting Faculty, University of Moratuwa > Member, Apache Software Foundation > Research Scientist, Lanka Software Foundation > Blog: http://srinathsview.blogspot.com/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *V. Mohanadarshan* *Software Engineer,* *Data Technologies Team,* *WSO2, Inc. http://wso2.com * *lean.enterprise.middleware.* * * email: [email protected] phone:(+94) 771117673
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
