Hi Amila, On Sun, Jan 22, 2012 at 8:59 AM, Amila Suriarachchi <am...@wso2.com> wrote:
> > > I think this is not a problem of data related operations. But for a > mediator there is non concept of service and operations. It just take an > xml and output an xml. So it is like invoking an operation directly. If you > look at the rules service and mediator configuration this service and > operations are there only with web service part. Rule mediator does not > have them (Event architecturly there is no relationship with web service > and mediator). > I see the confusion there. The idea on using "operations" in the mediator was to keep the original data service format intact. As in, to re-use the same data service configuration format, so we won't have to create a new separate configuration for that part. And in our current data service configuration, what we have are operations/resources. So we can look it at as an API, rather than a set of operations in a service. And what the mediator does is, pick a certain operations from a set of operations in an API, and call it. Cheers, Anjana. > > But I also see some use case here as you have mentioned. Where users do > need to enrich some xml messages with additional data. (for an example if > ESB receives a customer Id this can be used to add all the customer > formation with his last orders etc.. which will be send to another > service). In this example[1] instead of using a data service we should have > used the data service mediator to do that. > > thanks, > Amila. > > [1] > http://wso2.org/library/articles/2012/01/integrating-different-systems-with-wso2-esb > > >> So the proposal was actually, not to necessarily ship this mediator by >> default with the ESB, but to make it a separate feature and to install it >> on-demand for anyone interested. >> >> Cheers, >> Anjana. >> >> >>> Thanks, >>> Hiranya >>> >>> >>> On Sat, Jan 21, 2012 at 11:52 AM, Amila Suriarachchi <am...@wso2.com>wrote: >>> >>>> >>>> >>>> On Fri, Jan 20, 2012 at 3:00 PM, Dinusha Senanayaka >>>> <dinu...@wso2.com>wrote: >>>> >>>>> Hi Amila, >>>>> >>>>> Thanks for the clarifications and feedbacks. >>>>> >>>>> On Fri, Jan 20, 2012 at 5:16 PM, Amila Suriarachchi <am...@wso2.com>wrote: >>>>> >>>>>> I had a chat with Dinush and suggested to have some thing like this >>>>>> as in rule service. This is also similar to callout mediator >>>>>> calling a data service. Difference is not using the soap/Axis2/tcp >>>>>> layers. >>>>>> >>>>>> <dsMediator serviceName="" operation=""> >>>>>> <source xpath="//" >soapBody|soapHeader|$foo|$bar</source> >>>>>> <target xpath="//" >>>>>> resultXpath="">soapBody|soapHeader|$foo|$bar</target> >>>>>> <dbConfig type="inline|registry"> >>>>>> >>>>>> </dbConfig> >>>>>> </dsMediator> >>>>>> >>>>>> In this model data service is looked as some thing take an xml and >>>>>> outputs an xml. source is the way mediator finds the xml to >>>>>> invoke DS and target is the place it stores the result xml. >>>>>> >>>>> >>>>> Earlier what we have suggested is to map the input parameters one by >>>>> one using xpath or provide them as inline or map the whole set of >>>>> parameters @ once using xpath. In new suggested way, we have only above >>>>> last option and need to have the xml that can be directly used to call >>>>> operation or do some xslt transformation and make the incoming soap body >>>>> to >>>>> have that xml. >>>>> >>>> >>>> When you say using xpath then we need to think against which OMElement? >>>> that can be soapBody, soapHeader or an xml stored in a property. >>>> >>>> yes it is better to have parameter xpath support. I thought Data >>>> Serivice support that at the .dbs level. If not it may be more meaning full >>>> to add that the data service level. >>>> >>>> Can you please send a sample mediator configuration with the .dbs file >>>> for paramter xpath case? >>>> >>>> thanks, >>>> Amila. >>>> >>>> >>>>> >>>>>> The source can be soapBody, soapHeader or a property and we can get a >>>>>> portion of that using xpath. >>>>>> Then again when the result came back it can be saved in any place and >>>>>> a part of the result can be selected using resultXpath and can be stored >>>>>> in >>>>>> a location given by xpath. >>>>>> >>>>> >>>>> >>>>> Regards, >>>>> Dinusha. >>>>> >>>>>> >>>>>> thanks, >>>>>> Amila. >>>>>> >>>>>> >>>>>> On Thu, Jan 19, 2012 at 7:25 PM, Amila Suriarachchi >>>>>> <am...@wso2.com>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jan 18, 2012 at 5:03 PM, Dinusha Senanayaka < >>>>>>> dinu...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> We are going to develop a ESB mediator which can be shipped as a >>>>>>>> feature and once this feature is installed within ESB, the DS mediator >>>>>>>> can >>>>>>>> be used to make data services calls in-line, without making actual SOAP >>>>>>>> requests, but it will use in-memory calls to invoke data service >>>>>>>> operations. >>>>>>>> >>>>>>> >>>>>>> I think first you need to think the features this mediator going >>>>>>> provide for an ESB user and hence what type of interface expect from the >>>>>>> mediator configuration. >>>>>>> For an example I am not seeing much relevance of service/operation >>>>>>> resource here. >>>>>>> Then think about the mediator configuration according to that and >>>>>>> implement. >>>>>>> >>>>>>> For an example Rules also has to support both as a web service and a >>>>>>> mediator. >>>>>>> >>>>>>> The idea of rule mediator is to use it as >>>>>>> >>>>>>> 1. Transformer >>>>>>> 2. Rule based content routing >>>>>>> >>>>>>> If we take the mediation aspect there is not need to have the WS- >>>>>>> aspects. >>>>>>> For an example ws component only shift with BRS server and Mediation >>>>>>> component only shift with ESB. >>>>>>> >>>>>>> For an instance in the transformation case it can either get the >>>>>>> soapBody apply rules and send the result to soapBody (or some part >>>>>>> given as >>>>>>> an Xpath) >>>>>>> >>>>>>> thanks, >>>>>>> Amila. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> So this will add the capability to have .dbs file in registry or >>>>>>>> some other file location and invoke the data-service operations without >>>>>>>> deploying the .dbs as a data-service and process the response within >>>>>>>> the >>>>>>>> ESB. >>>>>>>> >>>>>>>> Possible mediator configuration will look as follows: >>>>>>>> >>>>>>>> <!-- normal request --> >>>>>>>> <dsCall serviceName/servicePath="..."> <!-- >>>>>>>> serviceName is used when calling to a actually deployed data-service >>>>>>>> within >>>>>>>> current service configuration & >>>>>>>> >>>>>>>> servicePath is used to invoke a operation from .dbs file which has not >>>>>>>> deployed --> >>>>>>>> <operation/resource name/path=".." /> <!-- >>>>>>>> operation name or resource path to be invoke --> >>>>>>>> <params expression="xpath"> >>>>>>>> <!-- xpath expression is optional, which can be defined to take all >>>>>>>> input >>>>>>>> parameters. --> >>>>>>>> <param name="name1" value="value1" /> <!-- if >>>>>>>> the xpath expression in "params" is not provided then provide the >>>>>>>> parameters in line --> >>>>>>>> <param name="arrayName1" value="arrayVal1" /> >>>>>>>> <param name="arrayName1" value="arrayVal2" /> >>>>>>>> <param name=".." expression="xpath" /> <!-- >>>>>>>> inline parameter value can be provided through xpath --> >>>>>>>> <params> >>>>>>>> </operation> >>>>>>>> <target expression="xpath" /> >>>>>>>> <!-- If the xpath is not provided, response message after invoking the >>>>>>>> operation will added as fist child element of >>>>>>>> >>>>>>>> the SOAP body. If an xpath expression is provided then it will set in >>>>>>>> the >>>>>>>> given location. >>>>>>>> </dsCall> >>>>>>>> >>>>>>>> <!-- batch request --> >>>>>>>> <dsCall serviceName/servicePath="..."> >>>>>>>> <operation/resource name/path=".."/> >>>>>>>> <params expression="xpath"> >>>>>>>> <batch expression="xpath"> >>>>>>>> <!-- xpath expression can be used to define parameter set for a one >>>>>>>> batch >>>>>>>> --> >>>>>>>> <param name="name1" value="value1" /> >>>>>>>> <param name="arrayName1" value="arrayVal1" /> >>>>>>>> <param name="arrayName1" value="arrayVal2" /> >>>>>>>> <param name=".." expression="xpath" /> >>>>>>>> <batch> >>>>>>>> <batch ..>...</batch> >>>>>>>> <params> >>>>>>>> >>>>>>>> </dsCall> >>>>>>>> >>>>>>>> <!-- boxcarring --> >>>>>>>> <dsCall serviceName/servicePath="..."> >>>>>>>> <boxcarring> >>>>>>>> <request> >>>>>>>> <operation/resource name/path=".." /> >>>>>>>> <params expression="xpath"> >>>>>>>> <param name="name1" value="value1" /> >>>>>>>> <param name="arrayName1" value="arrayVal1" /> >>>>>>>> <param name="arrayName1" value="arrayVal2" /> >>>>>>>> <param name=".." expression="xpath" /> >>>>>>>> <params> >>>>>>>> </operation> >>>>>>>> </request> >>>>>>>> <request ...></request> >>>>>>>> </boxcarring> >>>>>>>> >>>>>>>> <target expression="xpath" /> >>>>>>>> >>>>>>>> </dsCall> >>>>>>>> >>>>>>>> Appreciate any feedback and ideas. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Dinusha. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Carbon-dev mailing list >>>>>>>> Carbon-dev@wso2.org >>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Amila Suriarachchi* >>>>>>> >>>>>>> Software Architect >>>>>>> >>>>>>> WSO2 Inc. ; http://wso2.com >>>>>>> lean . enterprise . middleware >>>>>>> >>>>>>> phone : +94 71 3082805 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Amila Suriarachchi* >>>>>> >>>>>> Software Architect >>>>>> WSO2 Inc. ; http://wso2.com >>>>>> lean . enterprise . middleware >>>>>> >>>>>> phone : +94 71 3082805 >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Carbon-dev mailing list >>>>>> Carbon-dev@wso2.org >>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Carbon-dev mailing list >>>>> Carbon-dev@wso2.org >>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Amila Suriarachchi* >>>> >>>> Software Architect >>>> WSO2 Inc. ; http://wso2.com >>>> lean . enterprise . middleware >>>> >>>> phone : +94 71 3082805 >>>> >>>> >>>> _______________________________________________ >>>> Carbon-dev mailing list >>>> Carbon-dev@wso2.org >>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>> >>>> >>> >>> >>> -- >>> Hiranya Jayathilaka >>> Associate Technical Lead; >>> WSO2 Inc.; http://wso2.org >>> E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 >>> Blog: http://techfeast-hiranya.blogspot.com >>> >>> _______________________________________________ >>> Carbon-dev mailing list >>> Carbon-dev@wso2.org >>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>> >>> >> >> >> -- >> *Anjana Fernando* >> Senior Software Engineer >> WSO2 Inc. | http://wso2.com >> lean . enterprise . middleware >> >> >> _______________________________________________ >> Carbon-dev mailing list >> Carbon-dev@wso2.org >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > *Amila Suriarachchi* > > Software Architect > WSO2 Inc. ; http://wso2.com > lean . enterprise . middleware > > phone : +94 71 3082805 > > > _______________________________________________ > Carbon-dev mailing list > Carbon-dev@wso2.org > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- *Anjana Fernando* Senior Software Engineer WSO2 Inc. | http://wso2.com lean . enterprise . middleware
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
