[Wsf-general] data services and resources

Wed Apr 4 23:30:06 PDT 2007

On Apr 5, 2007, at 10:52 AM, Sanjiva Weerawarana wrote:

> Hi Sumedha,
>
>> With some changes now data services supports following sql  
>> operations.
>> 1. update
>> 2. insert
>> 3. delete
>> 4. Select (with table joins)
>> 5. create (creating tables, don't know how useful this will be.  
>> But with few changes to code managed to get it working.)
>> Herewith I have attached the configuration files used for testing.
>
> Excellent!
>
>> Sample clients are available in svn (https://wso2.org/repos/wso2/ 
>> trunk/commons/data-services ) under the package  
>> org.wso2.ws.dataservice.samples for all of the scenarios mentioned  
>> above.
>> But as of now, we do not have fully automated examples similar to  
>> ones we find in axis2-samples or wsas. (I think this needs to be  
>> attended before we write a tutorial for others.)
>
> Can we support automatic ?wsdl generation from this? That's  
> critical for success ... All you'd need to do is generate XML  
> Schemas for the messages; the rest should be auto generated anyway  
> from the AxisService we populate out of the dbs files. If you ask  
> Deepal how he generates WSDL for POJOs that'll help figure out how  
> to generate the schemas. Given our structure I think its quite easy.
>
>> I would like to propose few changes to the specification.
>> *1. We do not have a mechanism to specify parameter ordering. *
>> For example ordering is very important in the following query.
>>     <query id="addStudentInfo">
>>        <!-- should appear in the correct order as in insert  
>> statement -->
>>        <param name="id" sqlType="INTEGER"/>
>>        <param name="name" sqlType="STRING"/>
>>        <param name="deptNo" sqlType="INTEGER"/>
>>        <param name="email" sqlType="STRING"/>
>>        <sql>insert into student (id,name,deptNo,email) values  
>> (?,?,?,?)</sql>
>>      </query>
>> Right now in the code, it is assumed that user puts the 'param'  
>> elements in the  correct ordering as how it should go into the  
>> insert statement.
>> We can have it like this or add an additional 'sequence/order'  
>> attribute to 'param' element.

I think we do not need an ordering mechanism. I think the user is  
intelligent enough to have the parameters in the correct order. Since  
both the parameter order and the query are in the same place, we can  
assume that there will be no confusion. Adding another property that  
is not needed will complicate the language un-necessarily.

>
> Hmmm. I think we need to implement the <with-param> stuff to  
> complete the query invocation. At that time IMO its enough for v1.0  
> that we'll be putting out .. we can improve it later. Plus, that's  
> critical for WSDL generation because that's what says how the  
> binding will look.

How much functionality are we adding to with-param? Is it only as a  
renaming mechanism? I personally feel that use of with-param will  
bring confusion when we have a return structure of more that 2  
levels. Way it is implemented now, all the column values of the data  
raw is passed to the next level.

Best Regards,
Chamil Thanthrimudalige

>
>> *2.  For queries returning large result sets,  we need to have  
>> some mechanism to 'chunk' the result.*
>> I am not 100% sure if this will workout, but I think we can use RM  
>> to send chunks of the result set to client.
>
> Yes .. but let's worry about this after getting a working model.
>
> I doubt RM would work for this but HTTP chunking would. However, we  
> probably want to allow users to select the start and end range or  
> something like that too.
>
>> *3. Response format for insert,update, delete*
>> Out of CRUD operations only select statement generates an output  
>> (valuable).
>> As a work-a-round I have used following response format for other  
>> operations.
>> <data:response xmlns:data="http://www.wso2.org/dataservices">
>>     Your query executed successfully. Return code from the  
>> database was 1.
>> </data:response>
>> Along with the message, I have appended the return code (like the  
>> exit code in C) from the database.
>> We need to come to an agreement on the suitability of this  
>> response format.
>
> I don't think that's enough- what I'd like is to have some way to  
> create an arbitrary XML element response. Essentially something  
> like XSLT's xsl:element concept would work I think.
>
>> *New Feature suggestion*
>> (May be this is not the right time to suggest new features, with  
>> many parts of the spec yet to be implemented ;-). But couldn't  
>> resist the temptation. )
>> 1. Functionality to export returned data into various formats (eg.  
>> csv, EDIFACT)
>> In my last company we needed something like this to export some of  
>> our data to third party integration tool (adaptris) & reporting  
>> tool (clickview).
>
> +1 ..
>
>> The example section of the specification is bit outdated.  We need  
>> to reorganize & update that part.
>
> Yes- let's get the code working and then update the document with  
> some real samples. We need to do finish <with-param> and ?wsdl  
> before we can declare closure for an alpha level effort.
>
> Sanjiva.
> -- 
> Sanjiva Weerawarana, Ph.D.
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> email: sanjiva at wso2.com; cell: +94 77 787 6880; fax: +1 509 691 2000
>
> "Oxygenating the Web Service Platform."
>
> _______________________________________________
> Wsf-general mailing list
> Wsf-general at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/wsf-general