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). > > 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. > > 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. > > Please share your thoughts/suggestions on the proposed changes. > > @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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
