Hi Srinath, On Thu, Jan 19, 2012 at 9:01 AM, Srinath Perera <[email protected]> wrote:
> > 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. > Well .. the idea was to strictly not to use it in a manner to do remote calls, and do in-memory calls to data service operations. Anyways, if for some reason, a person would switch between the two, yeah, we can certainly just add that feature too. Cheers, Anjana. > > --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 > -- *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
