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. 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. > 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. 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 _______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
