On Sun, Jan 22, 2012 at 8:59 AM, Amila Suriarachchi <am...@wso2.com> wrote:
> > > On Sat, Jan 21, 2012 at 11:54 PM, Anjana Fernando <anj...@wso2.com> wrote: > >> 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. >> > > I think this is not a problem of data related operations. But for a > mediator there is non concept of service and operations. It just take an > xml and output an xml. So it is like invoking an operation directly. If you > look at the rules service and mediator configuration this service and > operations are there only with web service part. Rule mediator does not > have them (Event architecturly there is no relationship with web service > and mediator). > > But I also see some use case here as you have mentioned. Where users do > need to enrich some xml messages with additional data. (for an example if > ESB receives a customer Id this can be used to add all the customer > formation with his last orders etc.. which will be send to another > service). In this example[1] instead of using a data service we should have > used the data service mediator to do that. > I prefer data services in this scenario for 2 reasons: 1. Batch operations are really expensive - Better to offload that overhead from the ESB 2. There could be other applications pumping orders into the same DB Thanks, Hiranya > > thanks, > Amila. > > [1] > http://wso2.org/library/articles/2012/01/integrating-different-systems-with-wso2-esb > > >> 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 >> >> > > > -- > *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
