Hi Amila, On Sun, Jan 22, 2012 at 3:19 PM, Amila Suriarachchi <[email protected]> wrote:
> > yes I do understand that. That is why in real case users have to write a > .dbs file which is not shown here. What I am saying is that that may not be > the best way to do that when thinking > in a mediator perspective. > I see, the justification there is, you will get all the features of data services, when you use the existing .dbs file. To mirror all that functionality in-line in the mediator will be a bit tedious. Cheers, Anjana. > > thanks, > Amila. > >> >> 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 >>>>> <[email protected]>wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri, Jan 20, 2012 at 3:00 PM, Dinusha Senanayaka <[email protected] >>>>>> > wrote: >>>>>> >>>>>>> Hi Amila, >>>>>>> >>>>>>> Thanks for the clarifications and feedbacks. >>>>>>> >>>>>>> On Fri, Jan 20, 2012 at 5:16 PM, Amila Suriarachchi >>>>>>> <[email protected]>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 <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jan 18, 2012 at 5:03 PM, Dinusha Senanayaka < >>>>>>>>> [email protected]> 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 >>>>>>>>>> [email protected] >>>>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Carbon-dev mailing list >>>>>>> [email protected] >>>>>>> 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 >>>>>> [email protected] >>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Hiranya Jayathilaka >>>>> Associate Technical Lead; >>>>> WSO2 Inc.; http://wso2.org >>>>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>>>> Blog: http://techfeast-hiranya.blogspot.com >>>>> >>>>> _______________________________________________ >>>>> Carbon-dev mailing list >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
