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

Reply via email to