On Sun, Jan 22, 2012 at 1:52 PM, Anjana Fernando <anj...@wso2.com> wrote:
> 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. > 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. 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 <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 > > -- *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
