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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
