Hi, On 27 September 2013 15:44, Srinath Perera <[email protected]> wrote:
> Hi Lasantha, > > This is what I meant. You can call the same parsing code from event > processor. I do not think it is a problem to refer to that code from event > processor. > > Yes. I guess it can be done that way. We can pass the configuration syntax to the relevant component and get that component to deploy a related artifact. Some API changes and internal architecture changes would have to be done to get this done AFAIU. Currently CEP does not support a concept of anonymous event builders or formatters. At a high level, I think with the given suggestions, the following would have to be done at backend (excluding UI support). 1. Support for default configurations for event adaptors (e.g. thrift/json) 2. Default configurations for event builders/event formatters which allows all events to hit the event processor and go out without any input/output mapping. (User would configure input/output mapping only if needed) 3. Anonymous event builder/formatter configurations 4. Let event-processor component read configuration related to builders/formatters and pass that config to the EB/EF component to deploy the configuration. I may have missed some stuff so please add/correct if so. With this change, I think the event-processor component will play a more central role and will have the capability to manage the EB,EF components. In the current architecture streams and stream definitions are a central concept, so reflecting that to the UI level will not take much of an effort. Am +1 for these changes if others are OK. But guess we will have to revisit the current internal architecture details a bit IMO... :-) Thanks, Lasantha --Srinath > > > On Fri, Sep 27, 2013 at 1:24 PM, Lasantha Fernando <[email protected]>wrote: > >> Hi Srinath, >> >> +1 for the first 3 suggestions. At the UI level, it should be simple for >> the user to configure. It makes sense to keep default configurations for >> some event adaptors like data-bridge/thrift. >> >> However, at the deployment config files, it would be tricky to include >> the configuration of different components in a single file. >> >> Can you verify what you mean by inline configuration a bit more? >> When you mean inline event builders and inline event formatters, do you >> mean something like the following (Just pseudo syntax, not actual)? >> >> <executionPlan> >> <builder from="jmsAdaptor" toStream="stockStream"> >> <inputMapping type="xml"> >> <property> >> <from xpath="//StockQuote/LastTradedAmount" /> >> <to name="price" type="double" /> >> </property> >> .... >> </inputMapping> >> </builder> >> <siddhiQuery> >> .... {query goes here}... >> </siddhiQuery> >> <formatter from="processedStockStream" to="emailAdaptor"> >> <outMapping type="text"> >> .... >> <mappingText>Stock Price: {{price}}</mappingText> >> </outMapping> >> </formatter> >> </executionPlan> >> >> Putting a configuration file like this to the execution plan would mean >> that the event processor component has to know about syntax for event >> builders and event formatters as well IMO? >> >> Am not sure whether this would be a clean approach. >> >> Thanks, >> Lasantha >> >> >> >> On 27 September 2013 12:48, Srinath Perera <[email protected]> wrote: >> >>> Playing with CEP 3.0, i feel we have taken backward step in terms of >>> usability. >>> >>> Note I am not saying we should change this in the version we are putting >>> out now, but fix it soon afterword. >>> >>> CEP 3.0 has introduced a processing pipeline that give users lot of >>> flexibility. >>> pipeline includes: event receiver, event builder, cep plan, event >>> formatter, event sender >>> >>> This is great. Ideas come from Axis2 arch and we all agreed. >>> >>> However, CEP forces users to configure all parts of the pipeline all the >>> time. >>> Now users have to go though all the steps (and we do not have a wizard >>> that guide you though :(). >>> >>> Problem 1: This is BAD idea, and this make life of the users very hard >>> and force them to understand lot of new concepts. >>> >>> Axis2 has even bigger pipeline, but it does not ask at least one of the >>> questions when you want to deploy a service. All extensions are hidden >>> inside defaults and users will only see them if the want to extend the >>> flow. If user do not >>> know about them, still simple case is simple. >>> >>> Problem2: Another key issue is while streams are core concept, there is >>> no way to list all available streams or add them. >>> >>> Following is my proposal to fix the problem. >>> >>> 1) Add default event listeners (e.g thrift) and senders and make them >>> available out of the box. Others users may configure via Carbon configure >>> view (not in main). Then even without configuring a listener, users can >>> use thrift listener. >>> >>> 2) In main menu, have only ExecuationPlan and Streams. Those are only >>> central concepts. (E.g. In WSAS we have services and webapps here). When >>> you creating new Execution plans, it is configured with thrift and data >>> bridge formatters for default. Users can edit and change that. When they >>> edit, then can either define formatters inline (they are not named .. and >>> not added to list .. just like anonymous endpoints in ESB) or they can >>> look them up from global list configured via Configure menu. >>> >>> 3) Same for streams. But streams are always named. But they can add >>> streams without leaving execution plan UI. >>> >>> 4) In in deployment config files, we should support user to give >>> anonymous event formatters and builders inline in the execution plan if the >>> wish to. They can skip them altogether and then thrift default event >>> formatters and builders are used. >>> >>> Goal is to keep simple things simple. Now if I need to define a query, I >>> say "Add Execution Plan", define streams inline, give the query and I am >>> done. >>> If I like to do complex things, I can do that too. >>> >>> Pls note we (including myself) did not catch this earlier. I am just >>> trying to fix the problem, not to put down the nice architecture we have >>> done with the pipeline. >>> >>> WDYT? >>> >>> --Srinath >>> >>> -- >>> ============================ >>> 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 >>> >>> >> >> >> -- >> *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
