Hi Hiranya, On Sat, Jan 21, 2012 at 6:37 PM, Hiranya Jayathilaka <hira...@wso2.com>wrote:
> I'm not entirely on board with the idea of running ESB functionality and > DSS functionality on the same box/JVM. From SOA perspective it is best to > keep these components separate as there could be several consumers who are > interested in accessing the data exposed by the data service. Also > performance wise the existing model is better because we can take advantage > of the non-blocking model of the ESB to invoke data services without much > overhead on the ESB. > > What is the exact problem you're trying to solve here? > I guess, maybe we didn't describe this properly :) .. The idea is not to deploy a data service as a web service in the ESB. But it's just a way to have something like extended DBReport/DBLookup functionality. It works in the same way, where the mediator execution comprises simply of in-VM calls, basically calling directly the data services API. The idea was to give more richer functionality, than the DB-* mediators we have now. In the current way, even to do some simple operations such as, reading multiple records from the database, you can't do that with DBLookup, but you'll have to call an external DSS sever to get it done, which may not be the ideal solution all the time, specially, if it makes no sense to have the data related operations as a service. 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
