Databinding Integration, was Re: [DISCUSS] Evolving Implementation-data

[Luciano Resende <lu...@gmail.com>]

Thinking about data binding integration... In the case of
transformations like JDBCStreamReader -> JSON -> JDBCStreamReader,
will the Data Binding Framework maintain the same structure we are
using for the data, as described below ?

> I've took the following conventions to produce the Table XML Elements :
>
> Root :               <[table_name]_table> element
> Records :          <[table_name]> element
> Columns :         <column name>
> Column values:  column value as element text


On 10/11/07, Luciano Resende <lu...@gmail.com> wrote:
> I have finished a strawman for implementation.data going in the
> directions discussed here (revision #584019) :
>
>    - One component per database
>    - One service per table
>       - Tables are introspected from database metadata
>       -  Fixed service interface, right now supporting get and get(id) only
>    - Implemented using JDBC
>    - The results are now streamed directly from the database using a
> JDBCResultSetStreamReader
>
> I've took the following conventions to produce the Table XML Elements :
>
> Root :               <[table_name]_table> element
> Records :          <[table_name]> element
> Columns :         <column name>
> Column values:  column value as element text
>
> Next todos...
>
>    - Expand the interface to support all CRUD Operations
>    - Enhance JDBCResultSetStreamReader as needed
>    - Filter system tables from available services (or not ???)
>    - Integrate and test with databinding
>    - Integrate with samples (store, xmlquery)
>
> Please, take a look and provide your comments...
>
> Thinking a little bit in the future, and how they data services would
> be exposed as web-services, what do you guys think about integrating
> it with wsdl-less webservices feature we have, to allow wsdl
> generation by introspecting the database schema ? Thoughts ?
>
>
> On 10/8/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > Luciano Resende wrote:
> > > Hey Douglas
> > >
> > >    Thanks for volunteering, maybe you could start by prototyping the
> > > JDBC version of implementation-data that would return a
> > > XMLStreamReader. Once we flush out the design details, then we could
> > > think about the other CUD operations.
> > >
> > > Sebastien, and others... Thoughts ?
> > >
> > >
> >
> > It might be even better to start from a sample, without even using
> > implementation-data at the beginning.
> >
> > I'd suggest the Online Store sample under samples/store, try to change
> > CatalogImpl.java component to get the Catalog from a database using JDBC
> > (instead of a hardcoded table in memory), and return either an
> > XMLStreamReader or the current Item objects.
> >
> > Then try the same thing with the ShoppingCartImpl component, this will
> > help us understand what to do for updates, deletes etc.
> >
> > Then once we've been through that sample we'll probably have a clearer
> > idea of what implementation-data needs to do... basically automate what
> > we wrote by hand in the sample.
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
> --
> Luciano Resende
> Apache Tuscany Committer
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
>


-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org