On Sun, May 2, 2010 at 8:15 PM, Amila Suriarachchi <am...@wso2.com> wrote: > > > On Sun, May 2, 2010 at 4:23 PM, Anjana Fernando <anj...@wso2.com> wrote: >> >> Hi, >> >> > The current implementation has written as an above layer to data >> > services >> > which generates the .dbs file. >> >> Actually this tool, as u mentioned, is intended to be working on a >> higher layer. Because, the simple purpose of this tool is to quickly >> create a data service with the basic functionality given a RDBMS data >> source. Where it is actually expected that the user will customize the >> generated data service by adding new queries/operations and removing >> existing ones. > > yes. If the idea of this tool is to generate a scratch dbs file then even we > don't have to think > much about operation names etc ... Then you can think of what I have > suggested as a new feature. >
Yeah. >> >> And also to notice is, relational database based data >> sources is only one of the possibilities that data services can >> handle, where others are excel, csv, gspread etc.. and also can be >> easily extended to support other data sources. > > I am not clear about what you try to point out. I assume the tool already > written is rational db specific. > Here I was actually meaning to refer to the idea of introducing special syntax for the RDBMS based data services, i.e. <tableService tableName="..">, where it is not a generic function common to all type of data sources. >> >> > But instead if we can improve the dbs file (hence data services) to add >> > some thing as follows to have this feature. >> > <tableService tableName="table" serviceName="tableService"> >> > </tableService> >> >> If we give such special syntax in the dbs for RDBMS, in my opinion, it >> will basically undermine the data sources abstraction we have. And >> also, by adding such an option, the user will not be able to control >> the operations automatically created by the data services deployer, >> and also it will make the current dbs syntax complex, where we now >> have a very simple syntax and easy to manage. Also about having many >> services in one dbs file, it may create some subtle problems like, how >> to manage hot-deployment, because the dbs file was changed, so even if >> only a single service is actually changed, all the services will be >> re-deployed. And as I see, having one dbs file per service seems >> logical. > > Letting users to define multiple services in one file is an addition hence > it is always advantages. > Here it is not a must to have more than one service. They can still deploy > one per dbs. They can > define multiple services in one file only if it is useful to their scenario. > Same as axis2 services.xml. > Yeah, true .. I was thinking along the lines of, if it would be worth the trouble of implementing such a thing, considering that, this was not part of the initial design of data-services, to expose multiple services in a single dbs file .. anyways . I agree with your point :) .. > Having different types of services has its pros and corns. > > As you have mentioned it won't allow to have a data-source abstraction and > can lead to different configuration format for different type services. On > the other hand it may make simple thing complex. > Yeah. > for an example if a user wants to expose a table as a service with default > operations still he has to write all the queries by hand. ( this is why you > need to provide the tool) If I understand what you meant here correctly, yeah that is the objective of the tool. It just creates a basic data service for the user to start with, this option will most probably be integrated in the DS Wizard, where a user is selecting a RDBMS data source, and he will be presented with the option to immediately create a data service with the default operations (that is without going through the rest of the steps in the wizard). > > thanks, > Amila. > >> >> On the topic of having whttp location details for a service, in data >> services, we have a separate section on creating "resources" for a >> data service, where we can give the resource name and the HTTP method >> of accessing those resources. >> >> Cheers, >> Anjana. >> >> On Sun, May 2, 2010 at 11:08 AM, Amila Suriarachchi <am...@wso2.com> >> wrote: >> > Let me say some thing I was thinking about this. >> > >> > Actually I got a similar idea after reading this article[1]. Here Keith >> > keeps some Student data >> > in memory which should have kept in a data base table. So if we write a >> > data >> > service which generates >> > a service as he has given by looking at a database table that would >> > given a >> > practical example to Axis2 restful services. Of cause this can be >> > accessed >> > with soap as well. >> > >> > The current implementation has written as an above layer to data >> > services >> > which generates the .dbs file. >> > >> > But instead if we can improve the dbs file (hence data services) to add >> > some >> > thing as follows to have this feature. >> > >> > <tableService tableName="table" serviceName="tableService"> >> > >> > </tableService> >> > >> > I assume dbs deployer can generate the service with whttp location >> > details >> > for this kind of service. >> > >> > And also this solves the problem samisa has mentined. Now DBA don't have >> > to >> > copy the generated dbs files but just have to put an entry for the >> > tables he >> > need to generates the services. >> > >> > thanks, >> > Amila. >> > >> > [1] http://wso2.org/library/3726 >> > >> > On Sun, May 2, 2010 at 10:29 AM, Amila Suriarachchi <am...@wso2.com> >> > wrote: >> >> >> >> >> >> On Sun, May 2, 2010 at 9:26 AM, Samisa Abeysinghe <sam...@wso2.com> >> >> wrote: >> >>> >> >>> >> >>> On Sun, May 2, 2010 at 9:20 AM, Amila Suriarachchi <am...@wso2.com> >> >>> wrote: >> >>>> >> >>>> >> >>>> On Sun, May 2, 2010 at 7:28 AM, Samisa Abeysinghe <sam...@wso2.com> >> >>>> wrote: >> >>>>> >> >>>>> Some comments on generated DBS file: >> >>>>> 1. Query IDs: Are we using camel case? e.g. >> >>>>> selectAll_jk_test_table_1Query. I understand the table name >> >>>>> is jk_test_table_1 (and yes we can have anything here, as it comes >> >>>>> from the >> >>>>> DB). But why do we have "selectAll_" as prefix and "Query" as suffix >> >>>>> and not >> >>>>> "_Query". Same applied to other query types as well. >> >>>>> 2. Should we have "select_all_" as prefix and "_query" as suffix? >> >>>>> Basically, all lower case. Same applied to other query types as >> >>>>> well. >> >>>>> 3. "selectAll" vs "selectFrom". I do not think "selectFrom" is the >> >>>>> correct prefix. Because, even "selectAll" uses "SELECT * FROM" in >> >>>>> the query. >> >>>>> The main difference between them is "WHERE". So why not use >> >>>>> "selectWhere", >> >>>>> (or "select_where" as per 2) here? "selectFrom" confused me when I >> >>>>> had a >> >>>>> first look at the dbs, and I had to look back at select all, to >> >>>>> understand >> >>>>> the difference. We should also consider something like >> >>>>> "select_with_key" as >> >>>>> prefix for this, as that makes it more readable >> >>>>> 4. Why use "add_" for INSERT and not "insert_" as the prefix. That >> >>>>> looks out of the bunch as all other operations use the same SQL >> >>>>> keyword as >> >>>>> operation prefix >> >>>>> 5. The same concerns raised from 1 to 4 above apply to operation IDs >> >>>>> as >> >>>>> well, except for the operation name suffix >> >>>>> 6. Why not use "_operation" or at least "_op" as suffix for >> >>>>> operation >> >>>>> name? >> >>>> >> >>>> First I think no need to use the table name either in dbs/query or >> >>>> wsd/operation since these operations under the service which has the >> >>>> table >> >>>> name. >> >>> >> >>> But the point is, that we can have the user first generate this and >> >>> then >> >>> customize it to suite their needs. What if the DB had only 5 tables, >> >>> and the >> >>> user generated the DBS files and copied all those into one to make one >> >>> service? >> >> >> >> For this problem my suggestion is to improve the data services dbs file >> >> to >> >> have many services like in services xml. >> >> >> >> My point is we should not think a service as an arbitrary collection of >> >> operations. Operations of a service should be related. I think that >> >> improve >> >> the readability of the both wsdl and dbs. >> >> Anyway this depends on the scope we going to define for a service. >> >> table >> >> or a whole database. >> >>> >> >>> I think it is not a good idea to assume that the generated file would >> >>> be >> >>> used as it is... and it is good to have the table name in that case. >> >>> >> >>>> >> >>>> What we have is a standard five queries/operations. This can either >> >>>> be >> >>>> select/selectAll/insert/delete/update or get/getAll/put/delete/post >> >>>> if >> >>>> thinking in REST way. >> >>>> All operation names can be suffixed as Query in dbs and Operation in >> >>>> wsdl. >> >>>> >> >>>> For select operation I think it is enogh to say select becuse both in >> >>>> dbs and wsdl it implies this opeation takes an input parameter. >> >>> >> >>> Well, we are assuming Web services knowhow in this case I guess - it >> >>> is >> >>> good to have that info in there for the sake of folks who do not >> >>> understand >> >>> Web services like DBAs. >> >> >> >> Anyway there is no harm adding some suffix for select operation. >> >> >> >> What I think of in the web service consumers point of view. The only >> >> thing >> >> the see is the wsdl. Therefore the generated wsdl should be self >> >> descriptive >> >> and better to follow the common patterns. >> >> >> >> For DBAs they kind of know what type of service they generate and what >> >> type of operations they should expect. (May be reading the >> >> documentation :) >> >> ) >> >> >> >> thanks, >> >> Amila. >> >> >> >>>> >> >>>> eg. when there is a method select(int i) or get(int i) it implies >> >>>> that >> >>>> the parameter passing is some thing unique to return object. >> >>>> >> >>>> >> >>>>> >> >>>>> 7. Why not use "_data_service" or at least "_ds" as suffix for >> >>>>> service >> >>>>> name rather than just the table name? For e.g. if table name was >> >>>>> "wes_client" make the service name "wes_client_data_service" >> >>>> >> >>>> >> >>>> For this we can have an option to let users to define the service >> >>>> name >> >>>> as well. >> >>> >> >>> +1 >> >>> >> >>>> >> >>>> For default case I think it is enogh to have the Service suffix. What >> >>>> web service consumer sees is the wsdl, for him no need to show how >> >>>> the >> >>>> service is generated. >> >>> >> >>> However, if you look at the service manager's service linsting page, >> >>> it >> >>> would be easy to have it say it is "data_service" so that it tells you >> >>> at a >> >>> glance that it is a DS. >> >>> >> >>> Thanks, >> >>> Samisa... >> >>> >> >>>> >> >>>> thanks, >> >>>> Amila. >> >>>>> >> >>>>> In summary, we need consistency and also focus on readability, for >> >>>>> the >> >>>>> sake of maintainability, of the DBS. We cannot rule our someone >> >>>>> trying to >> >>>>> read this and understand what it is all about. I presume users will >> >>>>> use this >> >>>>> as the first step and then customize this manually to suite their >> >>>>> needs. >> >>>>> May be we should define some best practices to be followed when >> >>>>> implementing DBS files, in general, and follow those guidelines in >> >>>>> the >> >>>>> generated file as well. >> >>>>> Not sure if we already have guidelines on how to write a good DBS - >> >>>>> if >> >>>>> not we can make that part of this effort. >> >>>>> Thanks, >> >>>>> Samisa... >> >>>>> >> >>>>> On Sat, May 1, 2010 at 10:16 PM, Jasintha Dasanayaka >> >>>>> <jasin...@wso2.com> wrote: >> >>>>>> >> >>>>>> Hi >> >>>>>> Here I attached both wsdl and dbs which generated for one table >> >>>>>> service. >> >>>>>> Thanks >> >>>>>> Jasintha >> >>>>>> >> >>>>>> On Sat, May 1, 2010 at 1:49 PM, Amila Suriarachchi <am...@wso2.com> >> >>>>>> wrote: >> >>>>>>> >> >>>>>>> hi, >> >>>>>>> >> >>>>>>> Can you please send the generated wsdl for one table service? >> >>>>>>> >> >>>>>>> I am not sure how you have done it. Here you can nicely map >> >>>>>>> insert, >> >>>>>>> delete, update, select to four operations called put, delete, post >> >>>>>>> and get. >> >>>>>>> Then expose it as restful service[1]. >> >>>>>>> >> >>>>>>> [1] http://wso2.org/library/3726 >> >>>>>>> >> >>>>>>> thanks, >> >>>>>>> Amila. >> >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> On Fri, Apr 30, 2010 at 2:48 PM, Jasintha Dasanayaka >> >>>>>>> <jasin...@wso2.com> wrote: >> >>>>>>>> >> >>>>>>>> Hi All >> >>>>>>>> >> >>>>>>>> I have finished the development of all the basic functionality >> >>>>>>>> of >> >>>>>>>> the UI wizard. Some screen shots are attached. >> >>>>>>>> Thanks >> >>>>>>>> Jasintha >> >>>>>>>> On Fri, Apr 23, 2010 at 2:50 PM, Jasintha Dasanayaka >> >>>>>>>> <jasin...@wso2.com> wrote: >> >>>>>>>>> >> >>>>>>>>> It's a wizard. Following are the usage scenarios. >> >>>>>>>>> Create >> >>>>>>>>> 1. Select a data source >> >>>>>>>>> 2. Select set of database objects of this data source >> >>>>>>>>> 3. Generate data services for selected objects >> >>>>>>>>> View/Edit >> >>>>>>>>> 1. Select a data source & view existing data services created >> >>>>>>>>> for >> >>>>>>>>> it's objects. >> >>>>>>>>> thanks >> >>>>>>>>> Jasintha >> >>>>>>>>> >> >>>>>>>>> On Fri, Apr 23, 2010 at 2:33 PM, Samisa Abeysinghe >> >>>>>>>>> <sam...@wso2.com> wrote: >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On Fri, Apr 23, 2010 at 2:20 PM, Jasintha Dasanayaka >> >>>>>>>>>> <jasin...@wso2.com> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> Hi All >> >>>>>>>>>>> >> >>>>>>>>>>> I am developing a new feature for data-service .It can uses >> >>>>>>>>>>> to generate data services for given database. It >> >>>>>>>>>>> generates data services >> >>>>>>>>>>> for whole database. >> >>>>>>>>>>> >> >>>>>>>>>>> It generates one service per one table that service has basic >> >>>>>>>>>>> database operations(Insert, Delete, Update, Select by key and >> >>>>>>>>>>> Select all). >> >>>>>>>>>>> >> >>>>>>>>>>> This feature basically has two parts ,UI part and the back >> >>>>>>>>>>> end >> >>>>>>>>>>> part.The back end part of the feature I have already developed >> >>>>>>>>>>> now i am >> >>>>>>>>>>> developing the UI part of the feature. >> >>>>>>>>>>> I expect to complete this UI part with in the next week >> >>>>>>>>>> >> >>>>>>>>>> What does the UI do? I mean does it allow configuring, or >> >>>>>>>>>> viewing, >> >>>>>>>>>> or is it a Wizard?? >> >>>>>>>>>> Samisa... >> >>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> thanks >> >>>>>>>>>>> Jasintha >> >>>>>>>>>>> -- >> >>>>>>>>>>> Jasintha Dasanayaka >> >>>>>>>>>>> email: jasin...@wso2.com >> >>>>>>>>>>> cell: +94 772 916 596 >> >>>>>>>>>>> blog: http://jasintha.org >> >>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>> Carbon-dev mailing list >> >>>>>>>>>>> Carbon-dev@wso2.org >> >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>>>>>>> >> >>>>>>>>>> -- >> >>>>>>>>>> Samisa Abeysinghe >> >>>>>>>>>> Director, Engineering - WSO2 Inc. >> >>>>>>>>>> >> >>>>>>>>>> http://wso2.com/ - "lean . enterprise . middleware" >> >>>>>>>>>> >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> Carbon-dev mailing list >> >>>>>>>>>> Carbon-dev@wso2.org >> >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> -- >> >>>>>>>>> Jasintha Dasanayaka >> >>>>>>>>> email: jasin...@wso2.com cell: +94 772 916 596 >> >>>>>>>>> blog: http://jasintha.org >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Jasintha Dasanayaka >> >>>>>>>> email: jasin...@wso2.com cell: +94 772 916 596 >> >>>>>>>> blog: http://jasintha.org >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> _______________________________________________ >> >>>>>>>> Carbon-dev mailing list >> >>>>>>>> Carbon-dev@wso2.org >> >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Carbon-dev mailing list >> >>>>>>> Carbon-dev@wso2.org >> >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Jasintha Dasanayaka >> >>>>>> email: jasin...@wso2.com cell: +94 772 916 596 >> >>>>>> blog: http://jasintha.org >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Carbon-dev mailing list >> >>>>>> Carbon-dev@wso2.org >> >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>> >> >>>>> -- >> >>>>> Samisa Abeysinghe >> >>>>> Director, Engineering - WSO2 Inc. >> >>>>> >> >>>>> http://wso2.com/ - "lean . enterprise . middleware" >> >>>> >> >>> -- >> >>> Samisa Abeysinghe >> >>> Director, Engineering - WSO2 Inc. >> >>> >> >>> http://wso2.com/ - "lean . enterprise . middleware" >> >> >> > >> > >> > _______________________________________________ >> > Carbon-dev mailing list >> > Carbon-dev@wso2.org >> > https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > >> > >> >> >> >> -- >> Anjana Fernando >> Software Engineer >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware > > -- Anjana Fernando Software Engineer WSO2, Inc.; http://wso2.com lean.enterprise.middleware _______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
