You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jean-Sebastien Delfino <js...@apache.org> on 2007/10/03 02:58:01 UTC

[DISCUSS] Evolving Implementation-data

I'd like to start using the implementation-data extension in the Store 
sample, first to have the contents of the sample Catalog in a database, 
then maybe extend it to the ShoppingCart as well.

In that context, I'm thinking about evolving the implementation-data 
extension a little, along the following lines:

- One component per database so we don't have to repeat the database 
connection info in each component.

- One service per table, named like the table, so we don't have to know 
a fixed service name and also when you look at the service it's obvious 
which table it works with.

- Experiment with using JDBC directly, as we already have 
implementation-das to leverage the DAS/SDO runtime.

- Taking and returning an StAX XMLStreamReader, as it'll be sufficient 
(and really lightweight) if the Tuscany databinding framework can 
convert that XML data to whatever databinding is needed by other 
components in the assembly.

Thoughts?

-- 
Jean-Sebastien


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

Re: [DISCUSS] Evolving Implementation-data

Posted by Jean-Sebastien Delfino <js...@apache.org>.
[snip]
Luciano Resende wrote:
> I'm fine with most of what is said here, one component per database
> and one service per table is fine. In this context, JDBC is probably
> good enough, except for handling OCC as the data or feeds are going to
> work in a disconnected way.
>
> I also see this evolving in the near future, to be more sophisticated,
> providing support for all CRUD operations and pre-defined queries
> where data from multiple table are combined together; 

Yes we could expose stored procedures as service operations for example. 
Is that what you were thinking about?

>
>> - Taking and returning an StAX XMLStreamReader, as it'll be sufficient
>> (and really lightweight) if the Tuscany databinding framework can
>> convert that XML data to whatever databinding is needed by other
>> components in the assembly.
>>
>>     
>
> Could you elaborate more ? Is your proposal to, internally,  use StAX
> XMLStreamReader, but no changes on the client side, is this right ?
> Would it cause too much transformation JDBC -> XMLStreamReader -> Some
> kind of object and vice versa ?  What benefits you see here ?
>   

I see obvious benefits when the data eventually needs to presented in 
XML. I have a few examples in mind... Web Services, Feeds, integration 
with XQuery, BPEL :) In all these cases we'll avoid having to populate a 
throw-away object model and convert it later to XML.

This should help as well when the data needs to be presented to a 
component as an SDO, JAxB object or XMLBean. I'm hoping that the Tuscany 
databinding framework can pull the data out of the XMLStreamReader to 
populate the object model as necessary.

I'm also thinking that we'll avoid buffering or transformation 
performance issues with big volumes of data if XMLStreamReader.next() 
and the various XMLStreamReader.getMethods() can just pull the data out 
of JDBC as needed for example.

What kind of transformation were you thinking about?

> Do we also need a Feed databinding to help expose data as feeds ?
>
>   

I'm not sure yet. It might be simpler to have the Atom and RSS bindings 
just use XML instead of yet again another databinding with Rome (Rome is 
the library that we are currently using for Atom and RSS feeds).

Also Apache Abdera (an open source implementation of Atom in the Apache 
incubator) is just getting their 0.3.0 release out, and it looks like 
they support StAX. It would be interesting to start a discussion with 
them...

-- 
Jean-Sebastien


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

Re: [DISCUSS] Evolving Implementation-data

Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
> As for the delete operation, I think we should only allow deletions of
> a given table record and throw some exception when there is no ID
> provided....
>
> Thoughts ?
>
>   

I found the ability to delete the whole collection in the table useful 
in the Tutorial's ShoppingCart for example. I'm not sure how I'd clear 
the shopping cart without it.

> On 11/5/07, Douglas Leite <do...@gmail.com> wrote:
>   
>> I've already done a first version of the delete operation for
>> implementation.data module, as you can see on:
>> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12381836.
>>
>> What about I said above? Any suggestion?
>>     

Looks good to me, as far as I can understand the diff in a patch :)

--
Jean-Sebastien


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

Re: [DISCUSS] Evolving Implementation-data

Posted by Luciano Resende <lu...@gmail.com>.
As for the delete operation, I think we should only allow deletions of
a given table record and throw some exception when there is no ID
provided....

Thoughts ?


On 11/5/07, Douglas Leite <do...@gmail.com> wrote:
> I've already done a first version of the delete operation for
> implementation.data module, as you can see on:
> https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12381836.
>
> What about I said above? Any suggestion?
>
> On 10/24/07, Douglas Leite <do...@gmail.com> wrote:
> >
> > With the data being manipulated like a XmlStreamReader, I suppose that a
> > good way to implement the update operator is use a stream that contains the
> > modifications. Something like that:
> >
> > int update(XmlStreamReader modifications);
> >
> > Therefore, the 'modifications' stream will cotain all the modifications
> > made in the stream retrieved from the get operator.
> >
> > However, in the scenary where we have a simple java developer, how is he
> > supposed to manipulate the stream reader ?
> >
> > What about a XmlStreamReader that allow some sets methods?
> >
> >
> > On 10/12/07, Douglas Leite <dougsleite@gmail.com > wrote:
> > >
> > > As suggested, I've made some improvements in the sample store. Now the
> > > catalog data is accessed by JDBC instead of a hardcoded table in memory. ( https://issues.apache.org/jira/browse/TUSCANY-1844
> > > )
> > >
> > > After running the sample with the property currencyCode configured as
> > > 'EUR', in the store.composite, I got an float parse error in the
> > > getTotal method in the ShoppingCartImpl. Because of that, I've changed a
> > > little the way of get the price of each product.
> > >
> > > Suggestion?
> > >
> > > On 10/12/07, Raymond Feng < enjoyjava@gmail.com> wrote:
> > > >
> > > > Hi,
> > > >
> > > > To better support the XML streaming from the database and other source
> > > > such
> > > > as SDO or DOM, I added a prototype to create XMLStreamReader from a
> > > > tree
> > > > structure. You can find the code in tuscany-databinding module
> > > > (org.apache.tuscany.sca.databinding.xml.XmlTreeStreamReaderImpl.java).
> > > > I'm
> > > > trying to implement the XMLStreamReader from the DOM tree based on
> > > > this new
> > > > class and will keep you updated.
> > > >
> > > > Luciano, can you take a brief look to see if you can use it to stream
> > > > the
> > > > records?
> > > >
> > > > Thanks,
> > > > Raymond
> > > >
> > > > ----- Original Message -----
> > > > From: "Luciano Resende" < luckbr1975@gmail.com>
> > > > To: < tuscany-dev@ws.apache.org>
> > > > Sent: Thursday, October 11, 2007 6:45 PM
> > > > Subject: Re: [DISCUSS] Evolving Implementation-data
> > > >
> > > >
> > > > >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://people.apache.org/%7Elresende>
> > > > > 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
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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/

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

Re: [DISCUSS] Evolving Implementation-data

Posted by Douglas Leite <do...@gmail.com>.
I've already done a first version of the delete operation for
implementation.data module, as you can see on:
https://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12381836.

What about I said above? Any suggestion?

On 10/24/07, Douglas Leite <do...@gmail.com> wrote:
>
> With the data being manipulated like a XmlStreamReader, I suppose that a
> good way to implement the update operator is use a stream that contains the
> modifications. Something like that:
>
> int update(XmlStreamReader modifications);
>
> Therefore, the 'modifications' stream will cotain all the modifications
> made in the stream retrieved from the get operator.
>
> However, in the scenary where we have a simple java developer, how is he
> supposed to manipulate the stream reader ?
>
> What about a XmlStreamReader that allow some sets methods?
>
>
> On 10/12/07, Douglas Leite <dougsleite@gmail.com > wrote:
> >
> > As suggested, I've made some improvements in the sample store. Now the
> > catalog data is accessed by JDBC instead of a hardcoded table in memory. ( https://issues.apache.org/jira/browse/TUSCANY-1844
> > )
> >
> > After running the sample with the property currencyCode configured as
> > 'EUR', in the store.composite, I got an float parse error in the
> > getTotal method in the ShoppingCartImpl. Because of that, I've changed a
> > little the way of get the price of each product.
> >
> > Suggestion?
> >
> > On 10/12/07, Raymond Feng < enjoyjava@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > To better support the XML streaming from the database and other source
> > > such
> > > as SDO or DOM, I added a prototype to create XMLStreamReader from a
> > > tree
> > > structure. You can find the code in tuscany-databinding module
> > > (org.apache.tuscany.sca.databinding.xml.XmlTreeStreamReaderImpl.java).
> > > I'm
> > > trying to implement the XMLStreamReader from the DOM tree based on
> > > this new
> > > class and will keep you updated.
> > >
> > > Luciano, can you take a brief look to see if you can use it to stream
> > > the
> > > records?
> > >
> > > Thanks,
> > > Raymond
> > >
> > > ----- Original Message -----
> > > From: "Luciano Resende" < luckbr1975@gmail.com>
> > > To: < tuscany-dev@ws.apache.org>
> > > Sent: Thursday, October 11, 2007 6:45 PM
> > > Subject: Re: [DISCUSS] Evolving Implementation-data
> > >
> > >
> > > >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://people.apache.org/%7Elresende>
> > > > 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
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Evolving Implementation-data

Posted by Douglas Leite <do...@gmail.com>.
I've just done a first version of the insert and update CRUD operations to
impl.data module. Both are working with a XMLStreamReader stream, and have
some limitations that need to be enhanced.

(JIRA: https://issues.apache.org/jira/browse/TUSCANY-1917)

For the update operation, the limitations are:
-The XMLStreamReader has only columns that were modificated;
-The update is done based on the ID primary key attribute;
-The ID must be the first column, and musn't be null;
-The columns updated should be char or varchar type;

In other words, the update operation is doing something like this:

    <result_set>
        <record>
            <column name="ID">51</column>
            <column name="NAME">ACME Publishing</column>
        </record>
    </result_set>

    UPDATE table
    SET name = 'ACME Publishing'
    WHERE ID = 51

The insert operation, on the other hand, has the following limitations:
-Must exist an ID primary key attribute auto increment on the table;
-The table must only have column which type is char or varchar;

The insert operation is doing something like this:

    <result_set>
        <record>
            <column name="NAME">ACME Publishing II</column>
        </record>
    </result_set>

    INSERT INTO table ( column ) VALUES ( 'ACME Publishing II' )

I'm using a insert.xml and a update.xml in the tests. I think that the next
steps is create a good way to modify the xmlstreamreader retrivied by the
get method, and improve the CRUD operations.

Suggestions?

On Nov 6, 2007 2:54 PM, Douglas Leite <do...@gmail.com> wrote:

> What could be better? Should the "modifications" stream contain only the
> modifications, or should it be the stream retrieved by the get method (DATA
> interface) with the updates?
>
> Other comments inline.
>
> On 11/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> >
> > A few comments inline.
> >
> > [snip]
> > Douglas Leite wrote:
> > > With the data being manipulated like a XmlStreamReader, I suppose that
> > a
> > > good way to implement the update operator is use a stream that
> > contains the
> > > modifications. Something like that:
> > >
> > > int update(XmlStreamReader modifications);
> > >
> > > Therefore, the 'modifications' stream will cotain all the
> > modifications made
> > > in the stream retrieved from the get operator.
> > >
> >
> > What's the "int" for? can't that method just be void?
> >
> > > However, in the scenary where we have a simple java developer, how is
> > he
> > > supposed to manipulate the stream reader ?
> > >
> >
> > A Java developer developing a client component talking to your Data
> > component will probably want to do:
> > update(Customer customer)
> > with customer being a Java Object representation of the Customer
> > business object / resource to update.
> >
> > So IMO implementation-data should support both modes:
> > - good integration with XML, useful for local and remote XML enabled
> > clients
> > - good integration with Java business objects for local Java clients,
> > and Java-friendly remote clients (e.g. Json clients)
> >
> > > What about a XmlStreamReader that allow some sets methods?
> > >
> >
> > I think that a set can be represented as an update. Also, a set of
> > related sets can be batched in a single update.
> >
> > >
> > > On 10/12/07, Douglas Leite <do...@gmail.com> wrote:
> > >
> > >> As suggested, I've made some improvements in the sample store. Now
> > the
> > >> catalog data is accessed by JDBC instead of a hardcoded table in
> > memory. (https://issues.apache.org/jira/browse/TUSCANY-1844
> > >> )
> > >>
> > >> After running the sample with the property currencyCode configured as
> > >> 'EUR', in the store.composite, I got an float parse error in the
> > getTotal
> > >> method in the ShoppingCartImpl. Because of that, I've changed a
> > little the
> > >> way of get the price of each product.
> > >>
> >
> > This looks like a work around, do you know what the problem with the
> > Euro symbol is? is it a problem with the Atom binding not
> > reading/writing that symbol properly?
>
>
> I'm not sure, but I think that it can be possible.
>
> In the ShoppingCartImpl:
>
> private String getTotal() {
> [...]
> String item =
> ((Content)cart.values().iterator().next().getContents().get(0)).getValue();
> [...]
> }
>
> The String "item" contains the wrong symbol, and the cart map is filled
> with the catalog data using the atom binding.
>
> --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>

Re: [DISCUSS] Evolving Implementation-data

Posted by Douglas Leite <do...@gmail.com>.
What could be better? Should the "modifications" stream contain only the
modifications, or should it be the stream retrieved by the get method (DATA
interface) with the updates?

Other comments inline.

On 11/5/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
>
> A few comments inline.
>
> [snip]
> Douglas Leite wrote:
> > With the data being manipulated like a XmlStreamReader, I suppose that a
> > good way to implement the update operator is use a stream that contains
> the
> > modifications. Something like that:
> >
> > int update(XmlStreamReader modifications);
> >
> > Therefore, the 'modifications' stream will cotain all the modifications
> made
> > in the stream retrieved from the get operator.
> >
>
> What's the "int" for? can't that method just be void?
>
> > However, in the scenary where we have a simple java developer, how is he
> > supposed to manipulate the stream reader ?
> >
>
> A Java developer developing a client component talking to your Data
> component will probably want to do:
> update(Customer customer)
> with customer being a Java Object representation of the Customer
> business object / resource to update.
>
> So IMO implementation-data should support both modes:
> - good integration with XML, useful for local and remote XML enabled
> clients
> - good integration with Java business objects for local Java clients,
> and Java-friendly remote clients (e.g. Json clients)
>
> > What about a XmlStreamReader that allow some sets methods?
> >
>
> I think that a set can be represented as an update. Also, a set of
> related sets can be batched in a single update.
>
> >
> > On 10/12/07, Douglas Leite <do...@gmail.com> wrote:
> >
> >> As suggested, I've made some improvements in the sample store. Now the
> >> catalog data is accessed by JDBC instead of a hardcoded table in
> memory. (https://issues.apache.org/jira/browse/TUSCANY-1844
> >> )
> >>
> >> After running the sample with the property currencyCode configured as
> >> 'EUR', in the store.composite, I got an float parse error in the
> getTotal
> >> method in the ShoppingCartImpl. Because of that, I've changed a little
> the
> >> way of get the price of each product.
> >>
>
> This looks like a work around, do you know what the problem with the
> Euro symbol is? is it a problem with the Atom binding not
> reading/writing that symbol properly?


I'm not sure, but I think that it can be possible.

In the ShoppingCartImpl:

private String getTotal() {
[...]
String item =
((Content)cart.values().iterator().next().getContents().get(0)).getValue();
[...]
}

The String "item" contains the wrong symbol, and the cart map is filled with
the catalog data using the atom binding.

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

Re: [DISCUSS] Evolving Implementation-data

Posted by Jean-Sebastien Delfino <js...@apache.org>.
A few comments inline.

[snip]
Douglas Leite wrote:
> With the data being manipulated like a XmlStreamReader, I suppose that a
> good way to implement the update operator is use a stream that contains the
> modifications. Something like that:
>
> int update(XmlStreamReader modifications);
>
> Therefore, the 'modifications' stream will cotain all the modifications made
> in the stream retrieved from the get operator.
>   

What's the "int" for? can't that method just be void?

> However, in the scenary where we have a simple java developer, how is he
> supposed to manipulate the stream reader ?
>   

A Java developer developing a client component talking to your Data 
component will probably want to do:
update(Customer customer)
with customer being a Java Object representation of the Customer 
business object / resource to update.

So IMO implementation-data should support both modes:
- good integration with XML, useful for local and remote XML enabled clients
- good integration with Java business objects for local Java clients, 
and Java-friendly remote clients (e.g. Json clients)

> What about a XmlStreamReader that allow some sets methods?
>   

I think that a set can be represented as an update. Also, a set of 
related sets can be batched in a single update.

>
> On 10/12/07, Douglas Leite <do...@gmail.com> wrote:
>   
>> As suggested, I've made some improvements in the sample store. Now the
>> catalog data is accessed by JDBC instead of a hardcoded table in memory. (https://issues.apache.org/jira/browse/TUSCANY-1844
>> )
>>
>> After running the sample with the property currencyCode configured as
>> 'EUR', in the store.composite, I got an float parse error in the getTotal
>> method in the ShoppingCartImpl. Because of that, I've changed a little the
>> way of get the price of each product.
>>     

This looks like a work around, do you know what the problem with the 
Euro symbol is? is it a problem with the Atom binding not 
reading/writing that symbol properly?

-- 
Jean-Sebastien


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

Re: [DISCUSS] Evolving Implementation-data

Posted by Douglas Leite <do...@gmail.com>.
With the data being manipulated like a XmlStreamReader, I suppose that a
good way to implement the update operator is use a stream that contains the
modifications. Something like that:

int update(XmlStreamReader modifications);

Therefore, the 'modifications' stream will cotain all the modifications made
in the stream retrieved from the get operator.

However, in the scenary where we have a simple java developer, how is he
supposed to manipulate the stream reader ?

What about a XmlStreamReader that allow some sets methods?


On 10/12/07, Douglas Leite <do...@gmail.com> wrote:
>
> As suggested, I've made some improvements in the sample store. Now the
> catalog data is accessed by JDBC instead of a hardcoded table in memory. (https://issues.apache.org/jira/browse/TUSCANY-1844
> )
>
> After running the sample with the property currencyCode configured as
> 'EUR', in the store.composite, I got an float parse error in the getTotal
> method in the ShoppingCartImpl. Because of that, I've changed a little the
> way of get the price of each product.
>
> Suggestion?
>
> On 10/12/07, Raymond Feng <en...@gmail.com> wrote:
> >
> > Hi,
> >
> > To better support the XML streaming from the database and other source
> > such
> > as SDO or DOM, I added a prototype to create XMLStreamReader from a tree
> > structure. You can find the code in tuscany-databinding module
> > (org.apache.tuscany.sca.databinding.xml.XmlTreeStreamReaderImpl.java).
> > I'm
> > trying to implement the XMLStreamReader from the DOM tree based on this
> > new
> > class and will keep you updated.
> >
> > Luciano, can you take a brief look to see if you can use it to stream
> > the
> > records?
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message -----
> > From: "Luciano Resende" <lu...@gmail.com>
> > To: < tuscany-dev@ws.apache.org>
> > Sent: Thursday, October 11, 2007 6:45 PM
> > Subject: Re: [DISCUSS] Evolving Implementation-data
> >
> >
> > >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://people.apache.org/%7Elresende>
> > > 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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>

Re: [DISCUSS] Evolving Implementation-data

Posted by Douglas Leite <do...@gmail.com>.
As suggested, I've made some improvements in the sample store. Now the
catalog data is accessed by JDBC instead of a hardcoded table in memory. (
https://issues.apache.org/jira/browse/TUSCANY-1844)

After running the sample with the property currencyCode configured as 'EUR',
in the store.composite, I got an float parse error in the getTotal method in
the ShoppingCartImpl. Because of that, I've changed a little the way of get
the price of each product.

Suggestion?

On 10/12/07, Raymond Feng <en...@gmail.com> wrote:
>
> Hi,
>
> To better support the XML streaming from the database and other source
> such
> as SDO or DOM, I added a prototype to create XMLStreamReader from a tree
> structure. You can find the code in tuscany-databinding module
> (org.apache.tuscany.sca.databinding.xml.XmlTreeStreamReaderImpl.java). I'm
> trying to implement the XMLStreamReader from the DOM tree based on this
> new
> class and will keep you updated.
>
> Luciano, can you take a brief look to see if you can use it to stream the
> records?
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Luciano Resende" <lu...@gmail.com>
> To: <tu...@ws.apache.org>
> Sent: Thursday, October 11, 2007 6:45 PM
> Subject: Re: [DISCUSS] Evolving Implementation-data
>
>
> >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/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: [DISCUSS] Evolving Implementation-data

Posted by Raymond Feng <en...@gmail.com>.
Hi,

To better support the XML streaming from the database and other source such 
as SDO or DOM, I added a prototype to create XMLStreamReader from a tree 
structure. You can find the code in tuscany-databinding module 
(org.apache.tuscany.sca.databinding.xml.XmlTreeStreamReaderImpl.java). I'm 
trying to implement the XMLStreamReader from the DOM tree based on this new 
class and will keep you updated.

Luciano, can you take a brief look to see if you can use it to stream the 
records?

Thanks,
Raymond

----- Original Message ----- 
From: "Luciano Resende" <lu...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Thursday, October 11, 2007 6:45 PM
Subject: Re: [DISCUSS] Evolving Implementation-data


>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/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> 


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

Re: [DISCUSS] Evolving Implementation-data

Posted by Luciano Resende <lu...@gmail.com>.
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/

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

Re: [DISCUSS] Evolving Implementation-data

Posted by Jean-Sebastien Delfino <js...@apache.org>.
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

Re: [DISCUSS] Evolving Implementation-data

Posted by Luciano Resende <lu...@gmail.com>.
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 ?

On 10/3/07, Douglas Leite <do...@gmail.com> wrote:
> Although I'm a novice in the Tuscany project, I'm interested in help to
> improve the implementation-data module. So, do you have some suggestion to
> give me about how I can start?
>
> Thanks,
>
> Douglas Leite
>
> On 10/3/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > I'm fine with most of what is said here, one component per database
> > and one service per table is fine. In this context, JDBC is probably
> > good enough, except for handling OCC as the data or feeds are going to
> > work in a disconnected way.
> >
> > I also see this evolving in the near future, to be more sophisticated,
> > providing support for all CRUD operations and pre-defined queries
> > where data from multiple table are combined together; you will
> > probably want some OCC support, and support for managed versus
> > un-managed environments, then I think we should use some kind of
> > framework that already handles some of these complexity for us.
> >
> > Some more thoughts/comments inline :
> >
> >
> > On 10/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > > I'd like to start using the implementation-data extension in the Store
> > > sample, first to have the contents of the sample Catalog in a database,
> > > then maybe extend it to the ShoppingCart as well.
> > >
> > +1, but be aware that right now there is only support for read,
> > expanding the support of CRUD operations
> >
> > > In that context, I'm thinking about evolving the implementation-data
> > > extension a little, along the following lines:
> > >
> > > - One component per database so we don't have to repeat the database
> > > connection info in each component.
> > >
> >
> > +1
> >
> > > - One service per table, named like the table, so we don't have to know
> > > a fixed service name and also when you look at the service it's obvious
> > > which table it works with.
> > >
> >
> > +1
> >
> > > - Experiment with using JDBC directly, as we already have
> > > implementation-das to leverage the DAS/SDO runtime.
> > >
> > > - Taking and returning an StAX XMLStreamReader, as it'll be sufficient
> > > (and really lightweight) if the Tuscany databinding framework can
> > > convert that XML data to whatever databinding is needed by other
> > > components in the assembly.
> > >
> >
> > Could you elaborate more ? Is your proposal to, internally,  use StAX
> > XMLStreamReader, but no changes on the client side, is this right ?
> > Would it cause too much transformation JDBC -> XMLStreamReader -> Some
> > kind of object and vice versa ?  What benefits you see here ?
> >
> > Do we also need a Feed databinding to help expose data as feeds ?
> >
> > > Thoughts?
> > >
> > > --
> > > 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/
> >
> > ---------------------------------------------------------------------
> > 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/

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

Re: [DISCUSS] Evolving Implementation-data

Posted by Douglas Leite <do...@gmail.com>.
Although I'm a novice in the Tuscany project, I'm interested in help to
improve the implementation-data module. So, do you have some suggestion to
give me about how I can start?

Thanks,

Douglas Leite

On 10/3/07, Luciano Resende <lu...@gmail.com> wrote:
>
> I'm fine with most of what is said here, one component per database
> and one service per table is fine. In this context, JDBC is probably
> good enough, except for handling OCC as the data or feeds are going to
> work in a disconnected way.
>
> I also see this evolving in the near future, to be more sophisticated,
> providing support for all CRUD operations and pre-defined queries
> where data from multiple table are combined together; you will
> probably want some OCC support, and support for managed versus
> un-managed environments, then I think we should use some kind of
> framework that already handles some of these complexity for us.
>
> Some more thoughts/comments inline :
>
>
> On 10/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> > I'd like to start using the implementation-data extension in the Store
> > sample, first to have the contents of the sample Catalog in a database,
> > then maybe extend it to the ShoppingCart as well.
> >
> +1, but be aware that right now there is only support for read,
> expanding the support of CRUD operations
>
> > In that context, I'm thinking about evolving the implementation-data
> > extension a little, along the following lines:
> >
> > - One component per database so we don't have to repeat the database
> > connection info in each component.
> >
>
> +1
>
> > - One service per table, named like the table, so we don't have to know
> > a fixed service name and also when you look at the service it's obvious
> > which table it works with.
> >
>
> +1
>
> > - Experiment with using JDBC directly, as we already have
> > implementation-das to leverage the DAS/SDO runtime.
> >
> > - Taking and returning an StAX XMLStreamReader, as it'll be sufficient
> > (and really lightweight) if the Tuscany databinding framework can
> > convert that XML data to whatever databinding is needed by other
> > components in the assembly.
> >
>
> Could you elaborate more ? Is your proposal to, internally,  use StAX
> XMLStreamReader, but no changes on the client side, is this right ?
> Would it cause too much transformation JDBC -> XMLStreamReader -> Some
> kind of object and vice versa ?  What benefits you see here ?
>
> Do we also need a Feed databinding to help expose data as feeds ?
>
> > Thoughts?
> >
> > --
> > 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/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: [DISCUSS] Evolving Implementation-data

Posted by Luciano Resende <lu...@gmail.com>.
I'm fine with most of what is said here, one component per database
and one service per table is fine. In this context, JDBC is probably
good enough, except for handling OCC as the data or feeds are going to
work in a disconnected way.

I also see this evolving in the near future, to be more sophisticated,
providing support for all CRUD operations and pre-defined queries
where data from multiple table are combined together; you will
probably want some OCC support, and support for managed versus
un-managed environments, then I think we should use some kind of
framework that already handles some of these complexity for us.

Some more thoughts/comments inline :


On 10/2/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> I'd like to start using the implementation-data extension in the Store
> sample, first to have the contents of the sample Catalog in a database,
> then maybe extend it to the ShoppingCart as well.
>
+1, but be aware that right now there is only support for read,
expanding the support of CRUD operations

> In that context, I'm thinking about evolving the implementation-data
> extension a little, along the following lines:
>
> - One component per database so we don't have to repeat the database
> connection info in each component.
>

+1

> - One service per table, named like the table, so we don't have to know
> a fixed service name and also when you look at the service it's obvious
> which table it works with.
>

+1

> - Experiment with using JDBC directly, as we already have
> implementation-das to leverage the DAS/SDO runtime.
>
> - Taking and returning an StAX XMLStreamReader, as it'll be sufficient
> (and really lightweight) if the Tuscany databinding framework can
> convert that XML data to whatever databinding is needed by other
> components in the assembly.
>

Could you elaborate more ? Is your proposal to, internally,  use StAX
XMLStreamReader, but no changes on the client side, is this right ?
Would it cause too much transformation JDBC -> XMLStreamReader -> Some
kind of object and vice versa ?  What benefits you see here ?

Do we also need a Feed databinding to help expose data as feeds ?

> Thoughts?
>
> --
> 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/

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