Hi Manorama, I have added few comments to the PR. Please review them and do the necessary changes to the PR. Is it possible to write some unit tests for the mediator?
Thanks, Chanaka On Wed, Apr 1, 2015 at 10:03 AM, Manorama Perera <[email protected]> wrote: > Hi Nirmal, > > I've sent the PR[1] to carbon-mediation repo > > [1] https://github.com/wso2/carbon-mediation/pull/100 > > Thanks. > > On Wed, Apr 1, 2015 at 6:53 AM, Nirmal Fernando <[email protected]> wrote: > >> [Removing architecture@ and moving the discussion to dev@] >> >> Hi Manorama, >> >> Shall we work with the ESB team and get this mediator merged to the >> relevant repo please? >> >> On Wed, Mar 25, 2015 at 3:35 PM, Nirmal Fernando <[email protected]> wrote: >> >>> Thanks everyone. >>> >>> So, we decided to have following improvements; >>> >>> 1. /s/ml/machineLearner >>> 2. Instead of specifying storage-location, we should get the model-name >>> from the user. >>> 3. feature elements should be wrapped from a features element. >>> 4. prediction element currently replaces an existing element in the >>> incoming message, we can support the append as well. >>> >>> On Tue, Mar 24, 2015 at 11:56 PM, Chanaka Fernando <[email protected]> >>> wrote: >>> >>>> Hi Manorama, >>>> >>>> I guess that the names are not finalized yet. The name "ml" does not >>>> make much impression on the users. Please give a valid name like >>>> "MachineLearner" and that would make life easier for ESB developers. All >>>> our mediators has self explanatory names. >>>> >>>> Thanks, >>>> Chanaka >>>> >>>> On Tue, Mar 24, 2015 at 4:09 PM, Supun Sethunga <[email protected]> >>>> wrote: >>>> >>>>> Hi Maninda, >>>>> >>>>> With the initial release of ML, the model would not update on the fly. >>>>> If we need to update the model, it has to be done in ML by training a >>>>> model >>>>> with the same configurations, but with the new data. In future releases we >>>>> will be looking at this for possible improvements. >>>>> >>>>> Here the term "domain" refers to the definition of the data which use >>>>> to train the model. In the case you mentioned, If the model was trained >>>>> using the data collected from all incoming requests; then domain is "all >>>>> sales". and can be used to handle all incoming requests. But if the model >>>>> was trained using the data collected from the incoming requests of, say >>>>> Seller_A, then it cannot be used to predict/handle incoming requests of >>>>> all >>>>> sellers, which is a different domain. >>>>> When we say "domain", it also includes the Schema (set of >>>>> features/variables) of the dataset on which the prediction is going to be >>>>> done. Handling multiple schema is tricky. If the data from a different >>>>> domain doesn't contain some of the features (variables in the dataset) >>>>> used >>>>> to train the model, then that model cannot be used to predict on that >>>>> particular data. So we have to work with this limitation, hence all the >>>>> data has to be on the same domain (i.e. should have the same schema). >>>>> >>>>> Regards, >>>>> Supun >>>>> >>>>> On Tue, Mar 24, 2015 at 3:10 PM, Maninda Edirisooriya < >>>>> [email protected]> wrote: >>>>> >>>>>> Does this update the model time to time or use the same modal >>>>>> throughout the ESB up time? It is better if we can update the model while >>>>>> the ESB is up and running. >>>>>> There may be some use cases related to multiple domains right? So I >>>>>> think would be more generic and useful if we can apply the mediator not >>>>>> based on the domain but with a custom argument expression. For example if >>>>>> the target service is SalesService and the operation is >>>>>> getTotalSalesCount >>>>>> we want to use the modal to analyze all incoming requests from all >>>>>> domains. >>>>>> WDYT? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> >>>>>> *Maninda Edirisooriya* >>>>>> Senior Software Engineer >>>>>> >>>>>> *WSO2, Inc.*lean.enterprise.middleware. >>>>>> >>>>>> *Blog* : http://maninda.blogspot.com/ >>>>>> *E-mail* : [email protected] >>>>>> *Skype* : @manindae >>>>>> *Twitter* : @maninda >>>>>> >>>>>> On Tue, Mar 24, 2015 at 12:00 PM, Manorama Perera <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> ESB mediator for WSO2 ML enables making use of the models generated >>>>>>> by WSO2 Machine Leaner, to predict values in message mediation in ESB. >>>>>>> >>>>>>> - Machine Learner feature needs to be installed in ESB prior to >>>>>>> configure the ML mediator. >>>>>>> - Mediator will extract the data from the incoming messages and >>>>>>> send to the ML model as features. >>>>>>> - The mediator use the Machine Learner features to predict the >>>>>>> output value for every message passing through the mediator. >>>>>>> >>>>>>> *Proposed Mediator Configuration* >>>>>>> >>>>>>> <ml> >>>>>>> <model storage-location="string"/> >>>>>>> <feature name="string" expression="xpath"/>+ >>>>>>> <prediction expression="xpath"/> >>>>>>> </ml> >>>>>>> >>>>>>> *model* >>>>>>> storage-location : Storage location of the generated model. >>>>>>> >>>>>>> *feature* >>>>>>> name : Feature name according to the generated model. >>>>>>> expression : XPath expression used to determine the feature value. >>>>>>> >>>>>>> *prediction* >>>>>>> expression : XPath expression to determine the location to insert >>>>>>> the predicted value. >>>>>>> >>>>>>> The generated models can be applied to predict only the data coming >>>>>>> from the same domain, as the data used to train the model. So the >>>>>>> mediator >>>>>>> should be configured only to mediate messages which carry data coming >>>>>>> from >>>>>>> the same domain, as the data used to train the model. >>>>>>> >>>>>>> Any suggestion are appreciated. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> -- >>>>>>> Manorama Perera >>>>>>> Software Engineer >>>>>>> WSO2, Inc.; http://wso2.com/ >>>>>>> Mobile : +94716436216 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Supun Sethunga* >>>>> Software Engineer >>>>> WSO2, Inc. >>>>> http://wso2.com/ >>>>> lean | enterprise | middleware >>>>> Mobile : +94 716546324 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> -- >>>> Chanaka Fernando >>>> Technical Lead >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: +94 773337238 >>>> Blog : http://soatutorials.blogspot.com >>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>>> Twitter:https://twitter.com/chanakaudaya >>>> Wordpress:http://chanakaudaya.wordpress.com >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> Thanks & regards, >>> Nirmal >>> >>> Senior Software Engineer- Platform Technologies Team, WSO2 Inc. >>> Mobile: +94715779733 >>> Blog: http://nirmalfdo.blogspot.com/ >>> >>> >>> >> >> >> -- >> >> Thanks & regards, >> Nirmal >> >> Senior Software Engineer- Platform Technologies Team, WSO2 Inc. >> Mobile: +94715779733 >> Blog: http://nirmalfdo.blogspot.com/ >> >> >> > > > -- > Manorama Perera > Software Engineer > WSO2, Inc.; http://wso2.com/ > Mobile : +94716436216 > -- -- Chanaka Fernando Technical Lead WSO2, Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 773337238 Blog : http://soatutorials.blogspot.com LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 Twitter:https://twitter.com/chanakaudaya Wordpress:http://chanakaudaya.wordpress.com
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
