On Wed, Oct 2, 2013 at 11:36 PM, Lasantha Fernando <[email protected]>wrote:
> Hi Srinath, > > > On 2 October 2013 21:25, Srinath Perera <[email protected]> wrote: > >> Hi Lasantha, >> >> >> 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. > > >> > >>> 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. > > >> >>> 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
