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