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
