Hi Anjana, > 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.
I disagree as that forces the user to write two sets of codes when DS and ESB are in two nodes. In generally, we try most of our constructs work such a way that moving parts to a different node is a configuration change rather than code change (e.g. Registry, IS etc). IMO we should handle this case in the same manner. --Srinath > > Cheers, > Anjana. >> >> thanks, >> waruna >> >> sent from my mobile. >> >> On Jan 18, 2012 5:04 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. >>> >>> 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 >>> >> >> _______________________________________________ >> 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 > -- ============================ Srinath Perera, Ph.D. Senior Software Architect, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902 _______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
