Hi Waruna, On Thu, Jan 19, 2012 at 8:47 AM, Waruna Ranasinghe <war...@wso2.com> wrote:
> Now we have two methods to consume data services. What is the best > practice? > This is still not yet implemented/finalized btw :) .. > Won't this affect the non-blocking manner of Synspse, given that the > thread get blocked until response received from dataservice? > This is suppose to be a possible replacement for DB-* mediators. Those mediators also basically worked in the same way. The proposed data services mediator is only suppose to work in in-memory calls. It won't make any remote calls, basically it will not do any SOAP calls. What we do is, internally create the data service representation and call it directly, same in the case if the data service is already deployed as an Axis2 service, we can get the required data service object from that service and invoke our operations directly. Also as for the question made by Srinath, whether if till do a SOAP call if the data service is in another node, no it won't. It won't make sense to use this, then you can simply make an usual SOAP call, using "send" or "callout" mediators. Cheers, Anjana. > thanks, > waruna > > sent from my mobile. > On Jan 18, 2012 5:04 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. >> >> 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 >> >> > _______________________________________________ > 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
