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?
>
In this case, when a <builder> tag is found, event processor can forward
that to the builder service without actually parsing it. same for the
<formatter>.
So I think its not necessary that Event processor knowing the syntax or
having a redundant implementation inside it. But still this can involve
some work considering the current flow, when it comes to validations and
handling erroneous configurations.
Thanks
Rajeev
>
> 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
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Rajeev Sampath
Senior Software Engineer
WSO2, Inc.; http://www.wso2.com.
Mobile:* +94716265766
*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
