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. > >> 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? > >> 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... :-) > >> 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
