On Sun, Jan 22, 2012 at 11:18 AM, Hiranya Jayathilaka <[email protected]>wrote:
> Hi, > > On Sat, Jan 21, 2012 at 11:54 PM, Anjana Fernando <[email protected]> wrote: > >> Hi Hiranya, >> >> On Sat, Jan 21, 2012 at 6:37 PM, Hiranya Jayathilaka <[email protected]>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. >> > > My argument was from SOA perspective it's better to have data services as > a separate component exposed as 'web services' :) Also from a performance > point of view that relieves the ESB from making expensive JDBC calls. With > the current model server worker threads are released as soon as they invoke > the data services. But with the suggested mediator approach server worker > threads will do lot more work thus adding up to decreased throughput. > > >> 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. >> > > In a way this proposal is good because it provides some middle ground > between using data services and DB mediators. But OTOH it provides a third > option to access databases adding up to the existing confusion with two > options. > > I guess this is one of those things that we can argue forever pointing out > various pros and cons without coming to a conclusion :) So I'm ok with > having this as an optional feature. As Amila pointed out there will always > be some users who find this useful. But lets make this a point to properly > document the 3 approaches pointing out strengths, weaknesses and potential > use cases of each technique. > With the current ESB there are two ways to invoke data services. Using call out mediator or end point. If you use call out mediator then that will block the threads. So we can think of new approach as way of alternative for using call out mediator in terms of reducing system latency. Further the over head ESB have to do for send an XML message I think greater than to do a JDBC call. thanks, Amila. > Thanks, > Hiranya > > >> >> Cheers, >> Anjana. >> >> >>> Thanks, >>> Hiranya >>> >>> >>> On Sat, Jan 21, 2012 at 11:52 AM, Amila Suriarachchi <[email protected]>wrote: >>> >>>> >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> Hiranya Jayathilaka >>> Associate Technical Lead; >>> WSO2 Inc.; http://wso2.org >>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>> Blog: http://techfeast-hiranya.blogspot.com >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Hiranya Jayathilaka > Associate Technical Lead; > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > > _______________________________________________ > 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
