Hi Hiranya, 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. > IMHO, the JDBC calls may not necessarily be as expensive as waiting for a remote web service call to go to a server and come back. The actual database operations will anyway be happening in a separate server. As I see, the overall latency of a service call to the ESB maybe cut down, if we didn't have a remote data service request. I know, the service based approach is much cleaner, looking from an SOA architecture perspective :) .. as you also concluded, we can just have this as an optional feature. Cheers, Anjana. > > >> 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. > > 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 > > -- *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
