Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA

[Amita Vadhavkar <am...@gmail.com>]

Hi,
I am trying to create a container for DAS-SCA too (not just for stored
procedure) and will be able to send a working code in ML over the weekend.

Below is summary of what I got so far from the previous mail discussions and
some questions.


The integration between DAS and SCA can happen at application level as
service or at container level.



2 different possible approaches –

static – e.g. getAllCustomers

dynamic – e.g. execute("all customers");



For application level service – it is the sample *
sample-StoredProcedureService.jar*  or what Luciano is providing in more
details, is an example.  In *sample-StoredProcedureService.jar* example
dynamic approach is followed



For container approach – again static or dynamic approach can be followed.
For static – it's like providing service for getAllCompanies(),
getAllCustomers() etc. whereas for dynamic its like execute(command) where
command can be "getAllCompanies", "getAllCustomers". Etc.



            I am working on a container implementation where dynamic
approach is followed.



There are 2 places where extensibility is required –

1)      for providing different data access mechanisms. i.e. today there is
RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the scdl will
be same, but the exampleconfig.xml will change.

In the container I am working on - Scdl has a new tag

Scdl has a new tag
  <da:implementation.da script="customersOrders/CustomersOrders.xml"
dataAccessType="rdb"/>



Here, dataAccessType – is the key which tells whether it's RDB or something
else. And the xml script provides the connection and data store details.



2)      for RDB-DAS – providing support for different databases (this
portion should be part of DAS and  not SCA.) In the current container I am
working on it is provided as a package -
org.apache.tuscany.container.dataaccessshelper package  - which should
finally go into DAS codeline(?).





For static approach we may need some code generation tooling. Also could not
understand how this can be merged into RESTful interfaces. (this was
mentioned in some mail conversation)



Regards,

Amita


On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Luciano Resende wrote:
>
> > Comments in-line...
> >
> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> >
> >>
> >>
> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> >>
> >> > Hi,
> >> >
> >> > I would also like to understand this a little better ... here I am
> >> > thinking
> >> > aloud and hope the others will help in getting my persceptions
> >> > right...
> >> >
> >> > I guess firstly it is a question of how or where we want to
> >> > position 'DAS
> >> > Integration' in SCA.  Is is something we want to integrate as the
> >> > Application Layer, which I understand is what Amita is trying
> >> > presently and
> >> > which Jim refers to as component implementation.   In this option
> >> > we get to
> >> > do some sort of a service wrapper to DAS and then it becomes a
> >> > demonstration
> >> > of two Tuscany subprojects integrating at application level.
> >> >
> >
> >
> >
> > Yes, I think we have space to position DAS both ways, and integrating
> > in the
> > application layer by exposing DAS as a service would be a very easy and
> > quick, this could be exposed as a sample app, and could show we are
> > working
> > on getting a better integration between DAS and SCA
> >
> >
> >> Or do we want to position DAS at the infrastructure layer as another
> >> > extension type (either container or binding).  I guess this is
> >> > where Ant
> >> > started this - proposing a JDBC container / binding for component
> >> > implementation in StoredProcedures.
> >> I was thinking a DAS was a way to declaratively model heterogeneous
> >> data as a service and offer a mechanism for remoting that data. In
> >> other words, it provided the ability for an application to perform
> >> CRUD using a high-level contract (interface) and having those
> >> operations take place across a service network.  How this is hooked
> >> into the SCA container is probably best done as an extension type,
> >> i.e. someone could specify:
> >>
> >> <component name="Foo">
> >>         <implementation.das>
> >>                 <interface.java ....>
> >>         </implementation.das>
> >> </component>
> >
> >
> >
> >
> > Yes, this goes back to the way I was thinking on my original proposal.
> >
> >
> >> If this is the path we should take
> >> > then we probably have to think beyond DAS - to something more
> >> > general - of
> >> > which DAS is just a special case.  I suppose this is what Jim has
> also
> >> > suggested in trying to explore other persistence mechanisms.
> >> >
> >> This may be the crux of the confusion. I was thinking DAS provides a
> >> general mechanism for accessing heterogeneous data and is only right
> >> now tied to SQL because of resource constraints (i.e. we have to
> >> start somewhere). Ultimately, DAS should provide the infrastructure
> >> for dealing with multiple, varied data stores and mechanisms for
> >> querying across them. In other words, I guess I am saying DAS should
> >> be the general solution (declarative and heterogeneous) since if it
> >> is only a programmatic way to access relational data then its value
> >> is less clear in comparison to things such as JDBC 4 or JPA.
> >
> >
> >
> >
> > Yes, the current status of DAS implementation is RDB only. I would say
> > that,
> > in the future, I'd like to see a heterogeneous DAS that would give you
> > access to different data stores, and probably support non-SDO types as
> > well.
> >
> >> I too feel that this is something that must be done as an extension
> >> > type -
> >> > but yet to get my hands on the general scheme of things that DAS
> >> > can slip
> >> > into. Infact the other thread where Jeremy has taken forward a
> >> > proposal to
> >> > the specs group on resources tempts me to think that there is going
> >> > to be
> >> > something in that which we can leverage from.
> >> >
> >> I think resources are orthogonal as they are about a component
> >> implementation's contract with its container. Declarative data
> >> services on the other hand are about application constructs that can
> >> be wired to.
> >>
> >> > I hope to get a better understanding this as we go along in this
> >> > thread :)
> >> >
> >> Me too :-) As soon as I have trouble explaining technologies to .NET
> >> people and they say "you Unix/Java people are at it again with a
> >> thousand ways to do the same exact thing" it causes me to think that
> >> maybe we need to clarify our message.
> >
> >
> >
> >
> > If we all think it would be useful, I could try to summarize the
> > thread on
> > the wiki with a more clean proposal incorporating all your feedback ,
> > what
> > you guys think ?
>
> Yes.  Great idea.
>
> >
> >
> > Jim
> >
> >> > Thanks
> >> >
> >> > - Venkat
> >> >
> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >>
> >> >> Jim Marino wrote:
> >> >>
> >> >> > When I first read the thread on this, I thought the DAS service
> >> >> would
> >> >> > be a component extension type (e.g. analogous to a
> >> >> > implementation.java or implementation.ejb) and not a component
> >> >> > implementation type, which would allow for dynamic and eventually
> >> >> > declarative configuration styles.
> >> >>
> >> >> I have not very familiar with the terminology so I am not sure what
> a
> >> >> "component extension type" is.  But, I do think we eventually want
> >> >> "implementation.rdbdas".  Wouldn't this be a new implementation
> type?
> >> >>
> >> >> It looks like Amita chose to start with a POJO.  I notice the use
> >> >> of "
> >> >> implementation.java".
> >> >>
> >> >> > Either way, though, I am curious as  to why
> >> >> >
> >> >> > public DAS configureService(String configFile);
> >> >> >
> >> >> > exists as part of the service definition? If the DAS service was a
> >> >> > component extension type, it could be handled as part of the
> >> >> > application bootstrap. If the DAS service was a component
> >> >> > implementation type, the configuration file URI could be passed
> >> >> in as
> >> >> > a property and then processed in an initializer method decorated
> by
> >> >> > the SCA @Init annotation. In the latter case, if the
> implementation
> >> >> > of DASService thread-safe (hopefully it is since configuration
> >> >> would
> >> >> > seem to be a heavyweight operation), then I would make the
> >> >> component
> >> >> > module scoped to avoid initialization overhead on every
> resolution.
> >> >>
> >> >> >
> >> >> > In both approaches (extension vs. implementation type), having
> >> >> > configuration exposed to the application doesn't quite feel right,
> >> >> > since that is what DI tries to externalize.
> >> >>
> >> >> I agree.  The configuration should be part of the initialization and
> >> >> should use SCA patterns to do this.  I think that Amita meant to use
> >> >> eventually use a component property for the DAS config info but
> >> >> started
> >> >> with a method.
> >> >>
> >> >> >
> >> >> > Also, I was thinking that in having this a component extension
> >> >> type,
> >> >> > the service interfaces returned from a resolution could include
> the
> >> >> > dynamic one described below or static ones people have mentioned.
> I
> >> >> > guess it is best to start with the easier-to-implement part
> >> >> first and
> >> >> > support the dynamic interface.
> >> >> >
> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
> >> >> > understand what DAS provides in relation to other persistence
> >> >> > technologies. Outside of the Java world, Microsoft is promoting
> >> >> LINQ
> >> >> > which is really interesting, and it would be informative to
> compare
> >> >> > the goals of DAS with that approach (there are obvious differences
> >> >> > such as having the query language a strongly-typed part of the
> >> >> > programming language, e.g. C#, and LINQ's use of closures).
> >> >> >
> >> >> > In contrasting DAS to O-R technologies, I see the primary use
> cases
> >> >> > for the former being a quick way to issue a query that may be
> >> >> > executed against *heterogeneous* data stores and have that data
> >> >> flow
> >> >> > remotely or to a client that is not necessarily Java-based. One
> key
> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> >> >> (Hibernate
> >> >> > and JPA are about as easy):
> >> >> >
> >> >> IMO the primary use case for DAS is an application that is SDO-
> >> >> centric
> >> >> and is taking advantage of its disconnected capabilities.  The RDB
> >> >> DAS
> >> >> is built to work with SDO and uses the change summary to drive
> >> >> changes
> >> >> made to a disconnected data graph back to some store.  This is not
> to
> >> >> say that a relational DAS could not be built on top of JPA, in fact,
> >> >> this might be a very useful thing to do.  The implementation we
> >> >> currently have provides a very straightforward implicit mapping from
> >> >> DataObjects to Tables.  If more capable mapping is needed then it
> >> >> makes
> >> >> sense to use the JPA-defined technology and artifacts.  A modified
> >> >> Entity manager might be needed to take advantage of SDO's change
> >> >> summary.
> >> >>
> >> >> >
> >> >> > public interface CustomerDao extends BaseQuery {
> >> >> >     @Select("select * from customers where city = ?1")
> >> >> >     DataSet<Customer> findCustomersFrom(String city);
> >> >> > }
> >> >> >
> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> >> >> > (CustomerDao.class, datasource);
> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >> >> >
> >> >> >
> >> >> > The other key is remote data and change lists.  I think there are
> >> >> > (literally) about a thousand ways that already exist to handle the
> >> >> > "local" data case. For change lists, interop with ADO.NET's change
> >> >> > summary facilities would be interesting.
> >> >>
> >> >> I agree.  Also, it looks like Xcalia may have a similar thought:
> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> >> >>
> >> >> >
> >> >> > I'm playing devil's advocate a bit with DAS, but I think it is
> >> >> > important we have a clear statement as to when it is appropriate
> >> >> and
> >> >> > not appropriate to use. One place to start would be to compare
> >> >> it to
> >> >> > JDBC 4 and JPA.
> >> >>
> >> >> We can get started with JPA:
> >> >>
> >> >>     * JPA is java-specific, container-based, built around a
> connected
> >> >>       data model and offers a complete O/R mapping for POJOs
> >> >>
> >> >>     * The RDB DAS is a java implementation of a language - neutral
> >> >>       concept (hopefully specified some day) that is containerless,
> >> >>       assumes a disconnected data model and provides a simple,
> >> >> implicit
> >> >>       mapping for SDO DataObjects (Dynamic or Static) to relational
> >> >> tables.
> >> >>
> >> >> Anything else?
> >> >>
> >> >> >
> >> >> > Jim
> >> >> >
> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >> >> >
> >> >> >> Hi Amita
> >> >> >>
> >> >> >> I think we were both going on the same way, with the DAS Service
> >> >> >> sample,
> >> >> >> altough i had the interface more like this, to be more flexible :
> >> >> >>
> >> >> >> public interface DASService {
> >> >> >>
> >> >> >>    public DAS configureService(String configFile);
> >> >> >
> >> >> >
> >> >> >>    public DataObject executeCommand(String commandName);
> >> >> >>    public DataObject execute(String newCommand);
> >> >> >>    public void applyChanges(DataObject graphRoot);
> >> >> >> }
> >> >> >>
> >> >> >>
> >> >> >> As for having it as a sample, maybe we could defined the
> >> >> DASService
> >> >> >> as one
> >> >> >> sample itself, and have a second version of companyWeb that would
> >> >> >> consume
> >> >> >> the service, something like :
> >> >> >>
> >> >> >> das\samples\companyWeb
> >> >> >> das\samples\dasService
> >> >> >> das\samples.companyWeb.service
> >> >> >>
> >> >> >> or, more like BigBank
> >> >> >>
> >> >> >> das\samples\companyweb.Service\dasService
> >> >> >> das\samples\companyweb.Service\webClient
> >> >> >>
> >> >> >> Or even in sampleApps...
> >> >> >>
> >> >> >> Toughts ?
> >> >> >>
> >> >> >>
> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
> >> >> >>
> >> >> >>>
> >> >> >>> Hi ,
> >> >> >>> I am also following up another thread
> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> msg09944.html
> >> >> >>> on the
> >> >> >>> similar issue (JDBC stored procedure container
> >> >> >>> using DAS)
> >> >> >>> Besides the fact that I am actively working on the container
> >> >> work,
> >> >> >>> I also
> >> >> >>> have tried to
> >> >> >>> develop a sample based on the below discussion, following
> dynamic
> >> >> >>> approach.
> >> >> >>>
> >> >> >>> I am attaching the same here. Please take a look and give your
> >> >> >>> suggestions.
> >> >> >>> In this, StoredProcedureService implementation has
> >> >> setConfigInfo (DAS
> >> >> >>> Config) and
> >> >> >>> execute(Any SQL). This can be made more complete with
> >> >> executeSQL(),
> >> >> >>> applyChanges()
> >> >> >>> etc.
> >> >> >>>
> >> >> >>> Can this be added to the existing set of samples?
> >> >> >>>
> >> >> >>> Regards,
> >> >> >>> Amita
> >> >> >>>
> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >>> >
> >> >> >>> > Luciano Resende wrote:
> >> >> >>> >
> >> >> >>> > > Kevin, from what I understood from your suggestion, it was
> >> >> >>> looking to
> >> >> >>> > me
> >> >> >>> > > more like exposing DAS as a service :
> >> >> >>> > >
> >> >> >>> > >>>   public interface RDBDASService
> >> >> >>> > >>>        DataObject execute(String commandName);
> >> >> >>> > >>>        DataObject executeSQL(String abitrarySQL);
> >> >> >>> > >>>        void applyChanges(DataObject graphRoot);
> >> >> >>> > >>>    }
> >> >> >>> > >>
> >> >> >>> > Yes, I am talking about exposing a DAS Service configured
> >> >> with a
> >> >> >>> > specific set of capabilities/commands defined in the DAS
> config
> >> >> >>> file.
> >> >> >>> > So, if the implementation of the service interface above was
> >> >> >>> configured
> >> >> >>> > to work with Customers they would use the service like this:
> >> >> >>> >
> >> >> >>> >    List customers = myRDBDASService.execute
> ("getAllCustomers");
> >> >> >>> >    String name = customers.get(0).getString("name");
> >> >> >>> >
> >> >> >>> > This is not much different than the static interface you
> >> >> proposed,
> >> >> >>> > right?
> >> >> >>> >
> >> >> >>> > > And then, when a service developer defines the
> >> >> AccountService,
> >> >> >>> he will
> >> >> >>> >
> >> >> >>> > > have
> >> >> >>> > > to know about yet another service, about how DAS works,
> >> >> how it is
> >> >> >>> > > configured, etc, etc... is that right ?
> >> >> >>> > >
> >> >> >>> > The abilities of the service are defined by the DAS config
> >> >> file.
> >> >> >>> So,
> >> >> >>> > the person or tool that provides the config file must
> >> >> understand
> >> >> >>> how the
> >> >> >>> >
> >> >> >>> > RDB DAS APIs work.  There is no getting around this.
> >> >> >>> >
> >> >> >>> > > My proposal was going more towards allowing the service
> >> >> >>> developer to
> >> >> >>> > > focus
> >> >> >>> > > on defining the service, and let the "declarative das" to
> >> >> >>> handle the
> >> >> >>> > > persistent layer....
> >> >> >>> > >
> >> >> >>> > The DAS config file is the declaration of an instance of the
> >> >> >>> DAS.  That
> >> >> >>> > instance can be exposed as a dynamic or typed service/
> >> >> interface.
> >> >> >>> That
> >> >> >>> > seems to be the main discussion we are having. Although, I
> >> >> may be
> >> >> >>> > missing something.
> >> >> >>> >
> >> >> >>> > > Also, by defining some conventions over configuration
> >> >> and/or  using
> >> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
> >> >> >>> procedure),
> >> >> >>> > the
> >> >> >>> > > service developer could really define a service that
> >> >> interacts
> >> >> >>> with a
> >> >> >>> > > RDB,
> >> >> >>> > > without having to code the service persistence layer.
> >> >> >>> > >
> >> >> >>> > There is a lot of potential for the use of annotations.
> >> >> >>> >
> >> >> >>> > >
> >> >> >>> > > - Luciano
> >> >> >>> > >
> >> >> >>> > >
> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
> >> >> >>> > >
> >> >> >>> > >>
> >> >> >>> > >> The real difference between the two approaches is that
> >> >> one is
> >> >> >>> "Typed"
> >> >> >>> > or
> >> >> >>> > >> static and the other is dynamic.  I think both are needed
> >> >> but  was
> >> >> >>> > >> suggesting that we start with dynamic since it is the most
> >> >> >>> flexible
> >> >> >>> > and
> >> >> >>> > >> seems to be a reasonable stepping stone towards a static
> >> >> >>> capability.
> >> >> >>> > >>
> >> >> >>> > >> With either, the user does not need to know about
> >> >> traditional
> >> >> >>> > >> persistence frameworks.  With the dynamic approach,
> however,
> >> >> >>> the user
> >> >> >>> > >> does need to know about the dynamic SDO API.
> >> >> >>> > >>
> >> >> >>> > >> So, with the static interface the user might write:
> >> >> >>> > >>
> >> >> >>> > >>     List customers = accountService.getAllCustomers();
> >> >> >>> > >>     String name = ((Customer)customers.get(0)).getName();
> >> >> >>> > >>
> >> >> >>> > >> The equivalent dynamic API might be:
> >> >> >>> > >>
> >> >> >>> > >>     List customers = dasService.execute("getAllCustomers");
> >> >> >>> > >>     String name = ((DataObject)customers.get(0)).getString
> >> >> >>> ("name");
> >> >> >>> > >>
> >> >> >>> > >> The first is probably a little easier for the application
> >> >> >>> developer
> >> >> >>> > but
> >> >> >>> > >> the second is much easier for the service developer. IMO,
> >> >> the
> >> >> >>> dynamic
> >> >> >>> > >> case is the best place to start and, again, we
> >> >> definitely  will
> >> >> >>> want
> >> >> >>> > >> support for both.
> >> >> >>> > >>
> >> >> >>> > >> Thanks.
> >> >> >>> > >> --
> >> >> >>> > >> Kevin
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >> Jeremy Boynes wrote:
> >> >> >>> > >>
> >> >> >>> > >> > I think this would be useful but it seems more like a
> >> >> >>> traditional
> >> >> >>> > >> > persistence API than what Luciano was suggesting. With
> >> >> this
> >> >> >>> one a
> >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
> >> >> strings
> >> >> >>> etc.
> >> >> >>> > >> > just like they would if they were using raw JDBC or JPA.
> >> >> >>> > >> >
> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more about
> >> >> >>> expressing
> >> >> >>> > >> > high-level CRUD operations as operations on a service
> >> >> >>> interface:
> >> >> >>> > >> >
> >> >> >>> > >> >>> public interface AccountService {
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>    public List getAllCustomers();
> >> >> >>> > >> >>>    public Object getCustomerAccount(String
> >> >> accountNumber);
> >> >> >>> > >> >>> }
> >> >> >>> > >> >>
> >> >> >>> > >> >
> >> >> >>> > >> > which is all application level concepts rather
> >> >> than  persistence
> >> >> >>> > level
> >> >> >>> > >> > concepts. I'd actually go a little further and put that
> >> >> >>> right into
> >> >> >>> > >> > the service contract:
> >> >> >>> > >> >
> >> >> >>> > >> >   public interface AccountService {
> >> >> >>> > >> >     List<Customer> getAllCustomers();
> >> >> >>> > >> >     Account getCustomerAccount(String accountNumber);
> >> >> >>> > >> >   }
> >> >> >>> > >> >
> >> >> >>> > >> > In a ideal world, if the user was able to accept
> >> >> standardized
> >> >> >>> > >> > mappings (a la Rails et al) then no further configuration
> >> >> >>> would be
> >> >> >>> > >> > needed except to add this to the logical assembly:
> >> >> >>> > >> >
> >> >> >>> > >> >   <component name="AccountStore">
> >> >> >>> > >> >     <implementation.das resource="MySQLDatabase"/>
> >> >> >>> > >> >   </component>
> >> >> >>> > >> >
> >> >> >>> > >> > With SCA's ability to translate service contracts, this
> >> >> >>> should be
> >> >> >>> > >> > callable from and deployable to any SCA runtime
> >> >> regardless of
> >> >> >>> > whether
> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
> >> >> running  on
> >> >> a
> >> >> >>> > Java,
> >> >> >>> > >> > C++ or PHP platform.
> >> >> >>> > >> >
> >> >> >>> > >> > The important thing here is that the client is
> >> >> isolated  from
> >> >> >>> how
> >> >> >>> > the
> >> >> >>> > >> > DAS component is provided. We could have multiple
> >> >> declarative
> >> >> >>> > >> > implementations, say one based on RDB-DAS and one that
> did
> >> >> >>> stuff
> >> >> >>> > with
> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
> >> >> altering
> >> >> >>> the
> >> >> >>> > >> > client at all/ they could switch to a custom coded
> version
> >> >> >>> written
> >> >> >>> > in
> >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
> >> >> >>> > >> >
> >> >> >>> > >> > --
> >> >> >>> > >> > Jeremy
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> >> >> >>> > >> >
> >> >> >>> > >> >> I would suggest that we start right away with a RDBDAS-
> >> >> based
> >> >> >>> > >> >> solution.  I also think that the best place to start
> >> >> would
> >> >> >>> be with
> >> >> >>> > >> >> an interface that is "weakly" typed.  That is, a service
> >> >> >>> interface
> >> >> >>> >
> >> >> >>> > >> >> in terms of dynamic SDO's.  If we go this route we can
> >> >> >>> avoid the
> >> >> >>> > >> >> generation (by hand or otherwise) of code specific to
> >> >> a new
> >> >> >>> > >> >> service.  Instead, the service will be "instantiated"
> >> >> based
> >> >> >>> on the
> >> >> >>> >
> >> >> >>> > >> >> provided DAS config file.  The service interface
> >> >> might  look
> >> >> >>> like
> >> >> >>> > >> this:
> >> >> >>> > >> >>
> >> >> >>> > >> >>    public interface RDBDASService
> >> >> >>> > >> >>        DataObject execute(String commandName);
> >> >> >>> > >> >>        DataObject executeSQL(String abitrarySQL);
> >> >> >>> > >> >>        void applyChanges(DataObject graphRoot);
> >> >> >>> > >> >>    }
> >> >> >>> > >> >>
> >> >> >>> > >> >> So, depending on the config file used to instantiate the
> >> >> >>> service,
> >> >> >>> > >> >> this interface could be used to return Customers/
> >> >> Accounts or
> >> >> >>> > >> >> Toasters.  In fact, a lot could be achieved with no
> >> >> >>> > configuration  at
> >> >> >>> > >> >> all by restricting use to:  DataObject executeSQL(String
> >> >> >>> > >> abitrarySQL);
> >> >> >>> > >> >>
> >> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
> >> >> >>> mod_mbox/ws-
> >> >> >>> > >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> >> >> >>> > >> >>
> >> >> >>> > >> >> Once this was working it should be straightforward to
> >> >> build
> >> >> >>> more
> >> >> >>> > >> >> strongly typed services and possible put together some
> >> >> >>> generation
> >> >> >>> > >> >> tooling.  We could also start looking at support for a
> >> >> more
> >> >> >>> > RESTFul
> >> >> >>> > >> >> interface.
> >> >> >>> > >> >> --
> >> >> >>> > >> >> Kevin
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >> Luciano Resende wrote:
> >> >> >>> > >> >>
> >> >> >>> > >> >>> Recently, people have been starting to talk about
> >> >> better DAS
> >> >> >>> > >> >>> integration
> >> >> >>> > >> >>> with DAS, and below are some threads on the subject :
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> msg08833.html
> >> >> >>> > >> >>>
> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> msg08923.html
> >> >> >>> > >> >>>
> >> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >> >> >>> msg09715.html
> >> >> >>> >
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
> >> >> what  I'm
> >> >> >>> > >> >>> saying is not
> >> >> >>> > >> >>> yet available on SCA today.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Today, defining a service to work with a relational
> >> >> >>> database, you
> >> >> >>> > >> >>> will need
> >> >> >>> > >> >>> to code the persistence side of the service where CRUD
> >> >> >>> operations
> >> >> >>> > >> >>> to the
> >> >> >>> > >> >>> database will be done.
> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where coding
> >> >> the
> >> >> >>> CRUD
> >> >> >>> > >> >>> operations on
> >> >> >>> > >> >>> the persistence layer would be avoided as much as
> >> >> possible.
> >> >> >>> > >> >>> The idea would be to have a more "declarative DAS" when
> >> >> >>> defining
> >> >> >>> > SCA
> >> >> >>> > >> >>> Services, so you would either use some Annotations
> >> >> or  SCDL
> >> >> to
> >> >> >>> > >> have  the
> >> >> >>> > >> >>> "declarative DAS"  configuration inside it.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> I was thinking on something like....
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> SCDL Definition would look something like this :
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> <component name="AccountDataService">
> >> >> >>> > >> >>>   <interface.java
> >> >> >>> > >> >>>
> >> >> class="bigbank.account.services.account.AccountService"/>
> >> >> >>> > >> >>>   <implementation.das="dasConfig.properties"
> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >> >> >>> > >> >>> </component>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> The AccountService Interface would look like this
> >> >> (missing
> >> >> >>> any
> >> >> >>> > SCA
> >> >> >>> > >> >>> annotations):
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> public interface AccountService {
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>    public List getAllCustomers();
> >> >> >>> > >> >>>    public Object getCustomerAccount(String
> >> >> accountNumber);
> >> >> >>> > >> >>> }
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> The DAS config would look like this, and would have the
> >> >> >>> > definition
> >> >> >>> > >> >>> for the
> >> >> >>> > >> >>> "all companies" command.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> <Config ...>
> >> >> >>> > >> >>>    ...
> >> >> >>> > >> >>>   <ConnectionInfo dataSource="java:comp/env/jdbc/
> >> >> bigbank"/>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>   <Command name="getAllCustomers" SQL="select * from
> >> >> >>> CUSTOMERS"
> >> >> >>> > >> >>> kind="Select"/>
> >> >> >>> > >> >>>   <Command name="getCustomerAccount" SQL="SELECT
> >> >> >>> accountNumber,
> >> >> >>> > >> >>> accountType, balance FROM accounts where
> >> >> accountNumber = ?"
> >> >> >>> > >> >>> kind="Select" />
> >> >> >>> > >> >>>   ...
> >> >> >>> > >> >>> </Config>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
> >> >> >>> > >> >>>   - If a DAS config file is provided, based on the
> >> >> >>> > SCDL  definition,
> >> >> >>> > >> we
> >> >> >>> > >> >>> would look for "DAS command" based on the name of the
> >> >> getter
> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
> >> >> command)
> >> >> >>> > >> >>>   - Otherwise, we would try to do a map directly to a
> >> >> >>> > >> stored  procedure
> >> >> >>> > >> >>>   - We could also have a way to force the mapping by
> >> >> using
> >> >> >>> > >> annotation
> >> >> >>> > >> >>> (e.g@Procedure on the method level)
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Mapping between method parameter and command parameter
> >> >> >>> > >> >>>   - We would need to define a method for mapping the
> >> >> method
> >> >> >>> > >> >>> parameters to
> >> >> >>> > >> >>> the query paramters either based on position ( e.gfirst
> >> >> >>> method
> >> >> >>> > >> >>> parameter
> >> >> >>> > >> >>> maps to the first command paramter), or we would do
> some
> >> >> >>> > mapping  by
> >> >> >>> > >> >>> name
> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Note:
> >> >> >>> > >> >>>   - A SCDL connection information would override the
> DAS
> >> >> >>> Config
> >> >> >>> > file
> >> >> >>> > >> >>> connection information.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Benefits
> >> >> >>> > >> >>>   - It's All about simplicity and easy of use
> >> >> >>> > >> >>>   - This would allow a user to define a service without
> >> >> >>> having to
> >> >> >>> >
> >> >> >>> > >> >>> explicitly having to code any Data Access related code.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Implementation approaches
> >> >> >>> > >> >>>   - Utilizing DAS : This approach would start from the
> >> >> >>> current
> >> >> >>> > >> >>> Tuscany DAS
> >> >> >>> > >> >>> implementation, where functionality would be already
> >> >> >>> > available,  but
> >> >> >>> > >> >>> the
> >> >> >>> > >> >>> service implementation would be tied to SDO and RDB
> >> >> as this
> >> >> >>> > is  what
> >> >> >>> > >> >>> DAS
> >> >> >>> > >> >>> supports today.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>   - Start simple and grow : We could start simple, by
> >> >> >>> having a
> >> >> >>> > >> simple
> >> >> >>> > >> >>> implementation based on JDBC and would return some
> >> >> simple
> >> >> >>> > >> >>> collection as a
> >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
> could
> >> >> >>> give us
> >> >> >>> > a
> >> >> >>> > >> >>> quick
> >> >> >>> > >> >>> start to flush implementation details and get a proven
> >> >> >>> design,
> >> >> >>> > and
> >> >> >>> > >> >>> this
> >> >> >>> > >> >>> could get evolved to use a DAS that would support
> >> >> multiple
> >> >> >>> > backends
> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
> >> >> non- SDO
> >> >> >>> types
> >> >> >>> > >> as a
> >> >> >>> > >> >>> command
> >> >> >>> > >> >>> result.
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> Toughts ?
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> - Luciano
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >>> > >> >>>
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> Great.  I would like to help with this.  I have been
> >> >> >>> thinking
> >> >> >>> > for
> >> >> >>> > >> >>>> awhile
> >> >> >>> > >> >>>> about how to best integrate the RDB DAS within SCA.
> >> >> For
> >> >> >>> > >> example,  the
> >> >> >>> > >> >>>> current BBank scenario uses the RDB DAS as a utility
> >> >> but it
> >> >> >>> > >> would be
> >> >> >>> > >> >>>> nice if it could "wire in" a RDB DAS service or be
> >> >> >>> injected with
> >> >> >>> > a
> >> >> >>> > >> >>>> configured DAS.  Another thing we want to eventually
> >> >> >>> explore is
> >> >> >>> > >> >>>> exposing
> >> >> >>> > >> >>>> a DAS as REST-oriented services.  As we have seen
> >> >> from the
> >> >> >>> > parent
> >> >> >>> > >> >>>> thread
> >> >> >>> > >> >>>> there are almost too many possible approaches.
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> My first thought is to model the DAS as a service and
> >> >> >>> create a
> >> >> >>> > new
> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas).  The main
> >> >> >>> reason
> >> >> >>> > has
> >> >> >>> > >> >>>> to do
> >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
> >> >> >>> > Jeremy  mentioned
> >> >> >>> > >> >>>> which
> >> >> >>> > >> >>>> is all about creating data access services
> >> >> >>> declaratively.  A new
> >> >> >>> > >> >>>> component type and a service that we build by hand
> >> >> would be
> >> >> >>> > a  good
> >> >> >>> > >> >>>> step
> >> >> >>> > >> >>>> in this direction.
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> We might want to expose a DAS service with an
> >> >> interface  like
> >> >> >>> > this:
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>>     public interface RDBDASService
> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
> >> >> >>> > >> >>>>         DataObject execute(String commandName);
> >> >> >>> > >> >>>>         DataObject executeSQL(String abitrarySQL);
> >> >> >>> > >> >>>>     }
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> The service would be initialized with an optional
> >> >> RDB DAS
> >> >> >>> > >> config  file
> >> >> >>> > >> >>>> that defines connection properties, a set of commands,
> >> >> >>> etc.  So,
> >> >> >>> > >> >>>> different services implementing the same interface
> >> >> could be
> >> >> >>> > >> >>>> initialized
> >> >> >>> > >> >>>> from separate config files.
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> Eventually, we might want to build services like this:
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>>     public interface Customers_RDBDASService
> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
> >> >> >>> > >> >>>>         DataObject getAllCustomersWithLastName (String
> >> >> >>> > lastName);
> >> >> >>> > >> >>>>         DataObject getAll CustomersAndOrdersForID (int
> >> >> >>> > customerId);
> >> >> >>> > >> >>>>     }
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> But, for this to be very useful would probably require
> >> >> >>> some code
> >> >> >>> > >> >>>> generation tooling.
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> Thoughts?
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> --Kevin
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> Luciano Resende wrote:
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
> >> >> declarative
> >> >> >>> > DAS  and
> >> >> >>> > >> >>>> will be
> >> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
> >> >> >>> > >> >>>> >
> >> >> >>> > >> >>>> > - Luciano
> >> >> >>> > >> >>>> >
> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
> >> >> wrote:
> >> >> >>> > >> >>>> >
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >> On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
> >> >> >>> > >> >>>> >> >> This sounds like having cake, eating it, and
> also
> >> >> >>> > being  able
> >> >> >>> > >> to
> >> >> >>> > >> >>>> >> >> give it to a friend :-) We provide the
> >> >> flexibility  for
> >> >> >>> > users:
> >> >> >>> > >> >>>> >> >> 1) to access infrastructure services through
> >> >> >>> properties
> >> >> >>> > >> >>>> >> > Yes for things like JPA, JDBC, etc.
> >> >> >>> > >> >>>> >> >> 2) to reference infrastructure services through
> >> >> >>> > inclusion  in
> >> >> >>> > >> >>>> their
> >> >> >>> > >> >>>> >> >> assembly
> >> >> >>> > >> >>>> >> > If we do 1 I don't think we should do 2 (that
> >> >> >>> doesn't stop
> >> >> >>> > >> >>>> someone
> >> >> >>> > >> >>>> >> > from extending Tuscany to do it though). See my
> >> >> >>> comments
> >> >> >>> > >> below.
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
> >> >> >>> > should  welcome
> >> >> >>> > >> it
> >> >> >>> > >> >>>> >> like we would any other contribution.
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >> >> 3) to access data through an application
> >> >> service with
> >> >> >>> > >> >>>> declarative
> >> >> >>> > >> >>>> >> >> implementation by DAS
> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
> >> >> >>> > >> >>>> >> --
> >> >> >>> > >> >>>> >> Jeremy
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>> >>
> >> >> >>> > >> >>>>
> >> >> >>> > >>
> >> >> >>>
> >> >> --------------------------------------------------------------------
> >> >> >>> > >> -
> >> >> >>> > >> >>>> >> 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
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>>
> >> >> >>> > >> >>>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> > >> >>
> >> >> >>> >
> >> >> >>>
> >> >>
> ---------------------------------------------------------------------
> >> >> >>> > >> >> 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
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> > >> >
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>> > >>
> >> >> >>>
> >> >>
> ---------------------------------------------------------------------
> >> >> >>> > >> 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
> >> >> >>> >
> >> >> >>> >
> >> >> >>>
> >> >> >>>
> >> >>
> ---------------------------------------------------------------------
> >> >> >>> 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
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> 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
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA

[Amita Vadhavkar <am...@gmail.com>]

Hi Luciano,
I have attached code jar and doc today to
https://issues.apache.org/jira/browse/TUSCANY-898
Here I am trying to follow the approach of implementing SCA container for DAS.

Will you please go through the same and let me know if there is some
overlap in what you are developing with this?  Also please let me know
if we can have an IRC chat to discuss this in more details and see how
we can work together on this by splitting the work items etc.

Regards,
Amita

On 11/3/06, Amita Vadhavkar <am...@gmail.com> wrote:
> Hi,
> I am trying to create a container for DAS-SCA too (not just for stored
> procedure) and will be able to send a working code in ML over the weekend.
>
> Below is summary of what I got so far from the previous mail discussions
> and
> some questions.
>
>
> The integration between DAS and SCA can happen at application level as
> service or at container level.
>
>
>
> 2 different possible approaches –
>
> static – e.g. getAllCustomers
>
> dynamic – e.g. execute("all customers");
>
>
>
> For application level service – it is the sample *
> sample-StoredProcedureService.jar*  or what Luciano is providing in more
> details, is an example.  In *sample-StoredProcedureService.jar* example
> dynamic approach is followed
>
>
>
> For container approach – again static or dynamic approach can be followed.
> For static – it's like providing service for getAllCompanies(),
> getAllCustomers() etc. whereas for dynamic its like execute(command) where
> command can be "getAllCompanies", "getAllCustomers". Etc.
>
>
>
>             I am working on a container implementation where dynamic
> approach is followed.
>
>
>
> There are 2 places where extensibility is required –
>
> 1)      for providing different data access mechanisms. i.e. today there is
> RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the scdl
> will
> be same, but the exampleconfig.xml will change.
>
> In the container I am working on - Scdl has a new tag
>
> Scdl has a new tag
>   <da:implementation.da script="customersOrders/CustomersOrders.xml"
> dataAccessType="rdb"/>
>
>
>
> Here, dataAccessType – is the key which tells whether it's RDB or something
> else. And the xml script provides the connection and data store details.
>
>
>
> 2)      for RDB-DAS – providing support for different databases (this
> portion should be part of DAS and  not SCA.) In the current container I am
> working on it is provided as a package -
> org.apache.tuscany.container.dataaccessshelper package  - which should
> finally go into DAS codeline(?).
>
>
>
>
>
> For static approach we may need some code generation tooling. Also could
> not
> understand how this can be merged into RESTful interfaces. (this was
> mentioned in some mail conversation)
>
>
>
> Regards,
>
> Amita
>
>
> On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> > Luciano Resende wrote:
> >
> > > Comments in-line...
> > >
> > > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> > >
> > >>
> > >>
> > >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> > >>
> > >> > Hi,
> > >> >
> > >> > I would also like to understand this a little better ... here I am
> > >> > thinking
> > >> > aloud and hope the others will help in getting my persceptions
> > >> > right...
> > >> >
> > >> > I guess firstly it is a question of how or where we want to
> > >> > position 'DAS
> > >> > Integration' in SCA.  Is is something we want to integrate as the
> > >> > Application Layer, which I understand is what Amita is trying
> > >> > presently and
> > >> > which Jim refers to as component implementation.   In this option
> > >> > we get to
> > >> > do some sort of a service wrapper to DAS and then it becomes a
> > >> > demonstration
> > >> > of two Tuscany subprojects integrating at application level.
> > >> >
> > >
> > >
> > >
> > > Yes, I think we have space to position DAS both ways, and integrating
> > > in the
> > > application layer by exposing DAS as a service would be a very easy and
> > > quick, this could be exposed as a sample app, and could show we are
> > > working
> > > on getting a better integration between DAS and SCA
> > >
> > >
> > >> Or do we want to position DAS at the infrastructure layer as another
> > >> > extension type (either container or binding).  I guess this is
> > >> > where Ant
> > >> > started this - proposing a JDBC container / binding for component
> > >> > implementation in StoredProcedures.
> > >> I was thinking a DAS was a way to declaratively model heterogeneous
> > >> data as a service and offer a mechanism for remoting that data. In
> > >> other words, it provided the ability for an application to perform
> > >> CRUD using a high-level contract (interface) and having those
> > >> operations take place across a service network.  How this is hooked
> > >> into the SCA container is probably best done as an extension type,
> > >> i.e. someone could specify:
> > >>
> > >> <component name="Foo">
> > >>         <implementation.das>
> > >>                 <interface.java ....>
> > >>         </implementation.das>
> > >> </component>
> > >
> > >
> > >
> > >
> > > Yes, this goes back to the way I was thinking on my original proposal.
> > >
> > >
> > >> If this is the path we should take
> > >> > then we probably have to think beyond DAS - to something more
> > >> > general - of
> > >> > which DAS is just a special case.  I suppose this is what Jim has
> > also
> > >> > suggested in trying to explore other persistence mechanisms.
> > >> >
> > >> This may be the crux of the confusion. I was thinking DAS provides a
> > >> general mechanism for accessing heterogeneous data and is only right
> > >> now tied to SQL because of resource constraints (i.e. we have to
> > >> start somewhere). Ultimately, DAS should provide the infrastructure
> > >> for dealing with multiple, varied data stores and mechanisms for
> > >> querying across them. In other words, I guess I am saying DAS should
> > >> be the general solution (declarative and heterogeneous) since if it
> > >> is only a programmatic way to access relational data then its value
> > >> is less clear in comparison to things such as JDBC 4 or JPA.
> > >
> > >
> > >
> > >
> > > Yes, the current status of DAS implementation is RDB only. I would say
> > > that,
> > > in the future, I'd like to see a heterogeneous DAS that would give you
> > > access to different data stores, and probably support non-SDO types as
> > > well.
> > >
> > >> I too feel that this is something that must be done as an extension
> > >> > type -
> > >> > but yet to get my hands on the general scheme of things that DAS
> > >> > can slip
> > >> > into. Infact the other thread where Jeremy has taken forward a
> > >> > proposal to
> > >> > the specs group on resources tempts me to think that there is going
> > >> > to be
> > >> > something in that which we can leverage from.
> > >> >
> > >> I think resources are orthogonal as they are about a component
> > >> implementation's contract with its container. Declarative data
> > >> services on the other hand are about application constructs that can
> > >> be wired to.
> > >>
> > >> > I hope to get a better understanding this as we go along in this
> > >> > thread :)
> > >> >
> > >> Me too :-) As soon as I have trouble explaining technologies to .NET
> > >> people and they say "you Unix/Java people are at it again with a
> > >> thousand ways to do the same exact thing" it causes me to think that
> > >> maybe we need to clarify our message.
> > >
> > >
> > >
> > >
> > > If we all think it would be useful, I could try to summarize the
> > > thread on
> > > the wiki with a more clean proposal incorporating all your feedback ,
> > > what
> > > you guys think ?
> >
> > Yes.  Great idea.
> >
> > >
> > >
> > > Jim
> > >
> > >> > Thanks
> > >> >
> > >> > - Venkat
> > >> >
> > >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> > >> >>
> > >> >> Jim Marino wrote:
> > >> >>
> > >> >> > When I first read the thread on this, I thought the DAS service
> > >> >> would
> > >> >> > be a component extension type (e.g. analogous to a
> > >> >> > implementation.java or implementation.ejb) and not a component
> > >> >> > implementation type, which would allow for dynamic and eventually
> > >> >> > declarative configuration styles.
> > >> >>
> > >> >> I have not very familiar with the terminology so I am not sure what
> > a
> > >> >> "component extension type" is.  But, I do think we eventually want
> > >> >> "implementation.rdbdas".  Wouldn't this be a new implementation
> > type?
> > >> >>
> > >> >> It looks like Amita chose to start with a POJO.  I notice the use
> > >> >> of "
> > >> >> implementation.java".
> > >> >>
> > >> >> > Either way, though, I am curious as  to why
> > >> >> >
> > >> >> > public DAS configureService(String configFile);
> > >> >> >
> > >> >> > exists as part of the service definition? If the DAS service was
> a
> > >> >> > component extension type, it could be handled as part of the
> > >> >> > application bootstrap. If the DAS service was a component
> > >> >> > implementation type, the configuration file URI could be passed
> > >> >> in as
> > >> >> > a property and then processed in an initializer method decorated
> > by
> > >> >> > the SCA @Init annotation. In the latter case, if the
> > implementation
> > >> >> > of DASService thread-safe (hopefully it is since configuration
> > >> >> would
> > >> >> > seem to be a heavyweight operation), then I would make the
> > >> >> component
> > >> >> > module scoped to avoid initialization overhead on every
> > resolution.
> > >> >>
> > >> >> >
> > >> >> > In both approaches (extension vs. implementation type), having
> > >> >> > configuration exposed to the application doesn't quite feel
> right,
> > >> >> > since that is what DI tries to externalize.
> > >> >>
> > >> >> I agree.  The configuration should be part of the initialization
> and
> > >> >> should use SCA patterns to do this.  I think that Amita meant to
> use
> > >> >> eventually use a component property for the DAS config info but
> > >> >> started
> > >> >> with a method.
> > >> >>
> > >> >> >
> > >> >> > Also, I was thinking that in having this a component extension
> > >> >> type,
> > >> >> > the service interfaces returned from a resolution could include
> > the
> > >> >> > dynamic one described below or static ones people have mentioned.
> > I
> > >> >> > guess it is best to start with the easier-to-implement part
> > >> >> first and
> > >> >> > support the dynamic interface.
> > >> >> >
> > >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
> > >> >> > understand what DAS provides in relation to other persistence
> > >> >> > technologies. Outside of the Java world, Microsoft is promoting
> > >> >> LINQ
> > >> >> > which is really interesting, and it would be informative to
> > compare
> > >> >> > the goals of DAS with that approach (there are obvious
> differences
> > >> >> > such as having the query language a strongly-typed part of the
> > >> >> > programming language, e.g. C#, and LINQ's use of closures).
> > >> >> >
> > >> >> > In contrasting DAS to O-R technologies, I see the primary use
> > cases
> > >> >> > for the former being a quick way to issue a query that may be
> > >> >> > executed against *heterogeneous* data stores and have that data
> > >> >> flow
> > >> >> > remotely or to a client that is not necessarily Java-based. One
> > key
> > >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> > >> >> (Hibernate
> > >> >> > and JPA are about as easy):
> > >> >> >
> > >> >> IMO the primary use case for DAS is an application that is SDO-
> > >> >> centric
> > >> >> and is taking advantage of its disconnected capabilities.  The RDB
> > >> >> DAS
> > >> >> is built to work with SDO and uses the change summary to drive
> > >> >> changes
> > >> >> made to a disconnected data graph back to some store.  This is not
> > to
> > >> >> say that a relational DAS could not be built on top of JPA, in
> fact,
> > >> >> this might be a very useful thing to do.  The implementation we
> > >> >> currently have provides a very straightforward implicit mapping
> from
> > >> >> DataObjects to Tables.  If more capable mapping is needed then it
> > >> >> makes
> > >> >> sense to use the JPA-defined technology and artifacts.  A modified
> > >> >> Entity manager might be needed to take advantage of SDO's change
> > >> >> summary.
> > >> >>
> > >> >> >
> > >> >> > public interface CustomerDao extends BaseQuery {
> > >> >> >     @Select("select * from customers where city = ?1")
> > >> >> >     DataSet<Customer> findCustomersFrom(String city);
> > >> >> > }
> > >> >> >
> > >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> > >> >> > (CustomerDao.class, datasource);
> > >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> > >> >> >
> > >> >> >
> > >> >> > The other key is remote data and change lists.  I think there are
> > >> >> > (literally) about a thousand ways that already exist to handle
> the
> > >> >> > "local" data case. For change lists, interop with ADO.NET's
> change
> > >> >> > summary facilities would be interesting.
> > >> >>
> > >> >> I agree.  Also, it looks like Xcalia may have a similar thought:
> > >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> > >> >>
> > >> >> >
> > >> >> > I'm playing devil's advocate a bit with DAS, but I think it is
> > >> >> > important we have a clear statement as to when it is appropriate
> > >> >> and
> > >> >> > not appropriate to use. One place to start would be to compare
> > >> >> it to
> > >> >> > JDBC 4 and JPA.
> > >> >>
> > >> >> We can get started with JPA:
> > >> >>
> > >> >>     * JPA is java-specific, container-based, built around a
> > connected
> > >> >>       data model and offers a complete O/R mapping for POJOs
> > >> >>
> > >> >>     * The RDB DAS is a java implementation of a language - neutral
> > >> >>       concept (hopefully specified some day) that is containerless,
> > >> >>       assumes a disconnected data model and provides a simple,
> > >> >> implicit
> > >> >>       mapping for SDO DataObjects (Dynamic or Static) to relational
> > >> >> tables.
> > >> >>
> > >> >> Anything else?
> > >> >>
> > >> >> >
> > >> >> > Jim
> > >> >> >
> > >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> > >> >> >
> > >> >> >> Hi Amita
> > >> >> >>
> > >> >> >> I think we were both going on the same way, with the DAS Service
> > >> >> >> sample,
> > >> >> >> altough i had the interface more like this, to be more flexible
> :
> > >> >> >>
> > >> >> >> public interface DASService {
> > >> >> >>
> > >> >> >>    public DAS configureService(String configFile);
> > >> >> >
> > >> >> >
> > >> >> >>    public DataObject executeCommand(String commandName);
> > >> >> >>    public DataObject execute(String newCommand);
> > >> >> >>    public void applyChanges(DataObject graphRoot);
> > >> >> >> }
> > >> >> >>
> > >> >> >>
> > >> >> >> As for having it as a sample, maybe we could defined the
> > >> >> DASService
> > >> >> >> as one
> > >> >> >> sample itself, and have a second version of companyWeb that
> would
> > >> >> >> consume
> > >> >> >> the service, something like :
> > >> >> >>
> > >> >> >> das\samples\companyWeb
> > >> >> >> das\samples\dasService
> > >> >> >> das\samples.companyWeb.service
> > >> >> >>
> > >> >> >> or, more like BigBank
> > >> >> >>
> > >> >> >> das\samples\companyweb.Service\dasService
> > >> >> >> das\samples\companyweb.Service\webClient
> > >> >> >>
> > >> >> >> Or even in sampleApps...
> > >> >> >>
> > >> >> >> Toughts ?
> > >> >> >>
> > >> >> >>
> > >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
> > >> >> >>
> > >> >> >>>
> > >> >> >>> Hi ,
> > >> >> >>> I am also following up another thread
> > >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> > >> >> msg09944.html
> > >> >> >>> on the
> > >> >> >>> similar issue (JDBC stored procedure container
> > >> >> >>> using DAS)
> > >> >> >>> Besides the fact that I am actively working on the container
> > >> >> work,
> > >> >> >>> I also
> > >> >> >>> have tried to
> > >> >> >>> develop a sample based on the below discussion, following
> > dynamic
> > >> >> >>> approach.
> > >> >> >>>
> > >> >> >>> I am attaching the same here. Please take a look and give your
> > >> >> >>> suggestions.
> > >> >> >>> In this, StoredProcedureService implementation has
> > >> >> setConfigInfo (DAS
> > >> >> >>> Config) and
> > >> >> >>> execute(Any SQL). This can be made more complete with
> > >> >> executeSQL(),
> > >> >> >>> applyChanges()
> > >> >> >>> etc.
> > >> >> >>>
> > >> >> >>> Can this be added to the existing set of samples?
> > >> >> >>>
> > >> >> >>> Regards,
> > >> >> >>> Amita
> > >> >> >>>
> > >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> > >> >> >>> >
> > >> >> >>> > Luciano Resende wrote:
> > >> >> >>> >
> > >> >> >>> > > Kevin, from what I understood from your suggestion, it was
> > >> >> >>> looking to
> > >> >> >>> > me
> > >> >> >>> > > more like exposing DAS as a service :
> > >> >> >>> > >
> > >> >> >>> > >>>   public interface RDBDASService
> > >> >> >>> > >>>        DataObject execute(String commandName);
> > >> >> >>> > >>>        DataObject executeSQL(String abitrarySQL);
> > >> >> >>> > >>>        void applyChanges(DataObject graphRoot);
> > >> >> >>> > >>>    }
> > >> >> >>> > >>
> > >> >> >>> > Yes, I am talking about exposing a DAS Service configured
> > >> >> with a
> > >> >> >>> > specific set of capabilities/commands defined in the DAS
> > config
> > >> >> >>> file.
> > >> >> >>> > So, if the implementation of the service interface above was
> > >> >> >>> configured
> > >> >> >>> > to work with Customers they would use the service like this:
> > >> >> >>> >
> > >> >> >>> >    List customers = myRDBDASService.execute
> > ("getAllCustomers");
> > >> >> >>> >    String name = customers.get(0).getString("name");
> > >> >> >>> >
> > >> >> >>> > This is not much different than the static interface you
> > >> >> proposed,
> > >> >> >>> > right?
> > >> >> >>> >
> > >> >> >>> > > And then, when a service developer defines the
> > >> >> AccountService,
> > >> >> >>> he will
> > >> >> >>> >
> > >> >> >>> > > have
> > >> >> >>> > > to know about yet another service, about how DAS works,
> > >> >> how it is
> > >> >> >>> > > configured, etc, etc... is that right ?
> > >> >> >>> > >
> > >> >> >>> > The abilities of the service are defined by the DAS config
> > >> >> file.
> > >> >> >>> So,
> > >> >> >>> > the person or tool that provides the config file must
> > >> >> understand
> > >> >> >>> how the
> > >> >> >>> >
> > >> >> >>> > RDB DAS APIs work.  There is no getting around this.
> > >> >> >>> >
> > >> >> >>> > > My proposal was going more towards allowing the service
> > >> >> >>> developer to
> > >> >> >>> > > focus
> > >> >> >>> > > on defining the service, and let the "declarative das" to
> > >> >> >>> handle the
> > >> >> >>> > > persistent layer....
> > >> >> >>> > >
> > >> >> >>> > The DAS config file is the declaration of an instance of the
> > >> >> >>> DAS.  That
> > >> >> >>> > instance can be exposed as a dynamic or typed service/
> > >> >> interface.
> > >> >> >>> That
> > >> >> >>> > seems to be the main discussion we are having. Although, I
> > >> >> may be
> > >> >> >>> > missing something.
> > >> >> >>> >
> > >> >> >>> > > Also, by defining some conventions over configuration
> > >> >> and/or  using
> > >> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
> > >> >> >>> procedure),
> > >> >> >>> > the
> > >> >> >>> > > service developer could really define a service that
> > >> >> interacts
> > >> >> >>> with a
> > >> >> >>> > > RDB,
> > >> >> >>> > > without having to code the service persistence layer.
> > >> >> >>> > >
> > >> >> >>> > There is a lot of potential for the use of annotations.
> > >> >> >>> >
> > >> >> >>> > >
> > >> >> >>> > > - Luciano
> > >> >> >>> > >
> > >> >> >>> > >
> > >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
> > >> >> >>> > >
> > >> >> >>> > >>
> > >> >> >>> > >> The real difference between the two approaches is that
> > >> >> one is
> > >> >> >>> "Typed"
> > >> >> >>> > or
> > >> >> >>> > >> static and the other is dynamic.  I think both are needed
> > >> >> but  was
> > >> >> >>> > >> suggesting that we start with dynamic since it is the most
> > >> >> >>> flexible
> > >> >> >>> > and
> > >> >> >>> > >> seems to be a reasonable stepping stone towards a static
> > >> >> >>> capability.
> > >> >> >>> > >>
> > >> >> >>> > >> With either, the user does not need to know about
> > >> >> traditional
> > >> >> >>> > >> persistence frameworks.  With the dynamic approach,
> > however,
> > >> >> >>> the user
> > >> >> >>> > >> does need to know about the dynamic SDO API.
> > >> >> >>> > >>
> > >> >> >>> > >> So, with the static interface the user might write:
> > >> >> >>> > >>
> > >> >> >>> > >>     List customers = accountService.getAllCustomers();
> > >> >> >>> > >>     String name = ((Customer)customers.get(0)).getName();
> > >> >> >>> > >>
> > >> >> >>> > >> The equivalent dynamic API might be:
> > >> >> >>> > >>
> > >> >> >>> > >>     List customers =
> dasService.execute("getAllCustomers");
> > >> >> >>> > >>     String name = ((DataObject)customers.get(0)).getString
> > >> >> >>> ("name");
> > >> >> >>> > >>
> > >> >> >>> > >> The first is probably a little easier for the application
> > >> >> >>> developer
> > >> >> >>> > but
> > >> >> >>> > >> the second is much easier for the service developer. IMO,
> > >> >> the
> > >> >> >>> dynamic
> > >> >> >>> > >> case is the best place to start and, again, we
> > >> >> definitely  will
> > >> >> >>> want
> > >> >> >>> > >> support for both.
> > >> >> >>> > >>
> > >> >> >>> > >> Thanks.
> > >> >> >>> > >> --
> > >> >> >>> > >> Kevin
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >> Jeremy Boynes wrote:
> > >> >> >>> > >>
> > >> >> >>> > >> > I think this would be useful but it seems more like a
> > >> >> >>> traditional
> > >> >> >>> > >> > persistence API than what Luciano was suggesting. With
> > >> >> this
> > >> >> >>> one a
> > >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
> > >> >> strings
> > >> >> >>> etc.
> > >> >> >>> > >> > just like they would if they were using raw JDBC or JPA.
> > >> >> >>> > >> >
> > >> >> >>> > >> > On the other hand, Luciano's proposal seemed more about
> > >> >> >>> expressing
> > >> >> >>> > >> > high-level CRUD operations as operations on a service
> > >> >> >>> interface:
> > >> >> >>> > >> >
> > >> >> >>> > >> >>> public interface AccountService {
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>    public List getAllCustomers();
> > >> >> >>> > >> >>>    public Object getCustomerAccount(String
> > >> >> accountNumber);
> > >> >> >>> > >> >>> }
> > >> >> >>> > >> >>
> > >> >> >>> > >> >
> > >> >> >>> > >> > which is all application level concepts rather
> > >> >> than  persistence
> > >> >> >>> > level
> > >> >> >>> > >> > concepts. I'd actually go a little further and put that
> > >> >> >>> right into
> > >> >> >>> > >> > the service contract:
> > >> >> >>> > >> >
> > >> >> >>> > >> >   public interface AccountService {
> > >> >> >>> > >> >     List<Customer> getAllCustomers();
> > >> >> >>> > >> >     Account getCustomerAccount(String accountNumber);
> > >> >> >>> > >> >   }
> > >> >> >>> > >> >
> > >> >> >>> > >> > In a ideal world, if the user was able to accept
> > >> >> standardized
> > >> >> >>> > >> > mappings (a la Rails et al) then no further
> configuration
> > >> >> >>> would be
> > >> >> >>> > >> > needed except to add this to the logical assembly:
> > >> >> >>> > >> >
> > >> >> >>> > >> >   <component name="AccountStore">
> > >> >> >>> > >> >     <implementation.das resource="MySQLDatabase"/>
> > >> >> >>> > >> >   </component>
> > >> >> >>> > >> >
> > >> >> >>> > >> > With SCA's ability to translate service contracts, this
> > >> >> >>> should be
> > >> >> >>> > >> > callable from and deployable to any SCA runtime
> > >> >> regardless of
> > >> >> >>> > whether
> > >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
> > >> >> running  on
> > >> >> a
> > >> >> >>> > Java,
> > >> >> >>> > >> > C++ or PHP platform.
> > >> >> >>> > >> >
> > >> >> >>> > >> > The important thing here is that the client is
> > >> >> isolated  from
> > >> >> >>> how
> > >> >> >>> > the
> > >> >> >>> > >> > DAS component is provided. We could have multiple
> > >> >> declarative
> > >> >> >>> > >> > implementations, say one based on RDB-DAS and one that
> > did
> > >> >> >>> stuff
> > >> >> >>> > with
> > >> >> >>> > >> > XML databases like Xindice; alternatively, /without
> > >> >> altering
> > >> >> >>> the
> > >> >> >>> > >> > client at all/ they could switch to a custom coded
> > version
> > >> >> >>> written
> > >> >> >>> > in
> > >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
> > >> >> >>> > >> >
> > >> >> >>> > >> > --
> > >> >> >>> > >> > Jeremy
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> > >> >> >>> > >> >
> > >> >> >>> > >> >> I would suggest that we start right away with a RDBDAS-
> > >> >> based
> > >> >> >>> > >> >> solution.  I also think that the best place to start
> > >> >> would
> > >> >> >>> be with
> > >> >> >>> > >> >> an interface that is "weakly" typed.  That is, a
> service
> > >> >> >>> interface
> > >> >> >>> >
> > >> >> >>> > >> >> in terms of dynamic SDO's.  If we go this route we can
> > >> >> >>> avoid the
> > >> >> >>> > >> >> generation (by hand or otherwise) of code specific to
> > >> >> a new
> > >> >> >>> > >> >> service.  Instead, the service will be "instantiated"
> > >> >> based
> > >> >> >>> on the
> > >> >> >>> >
> > >> >> >>> > >> >> provided DAS config file.  The service interface
> > >> >> might  look
> > >> >> >>> like
> > >> >> >>> > >> this:
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>    public interface RDBDASService
> > >> >> >>> > >> >>        DataObject execute(String commandName);
> > >> >> >>> > >> >>        DataObject executeSQL(String abitrarySQL);
> > >> >> >>> > >> >>        void applyChanges(DataObject graphRoot);
> > >> >> >>> > >> >>    }
> > >> >> >>> > >> >>
> > >> >> >>> > >> >> So, depending on the config file used to instantiate
> the
> > >> >> >>> service,
> > >> >> >>> > >> >> this interface could be used to return Customers/
> > >> >> Accounts or
> > >> >> >>> > >> >> Toasters.  In fact, a lot could be achieved with no
> > >> >> >>> > configuration  at
> > >> >> >>> > >> >> all by restricting use to:  DataObject
> executeSQL(String
> > >> >> >>> > >> abitrarySQL);
> > >> >> >>> > >> >>
> > >> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
> > >> >> >>> mod_mbox/ws-
> > >> >> >>> > >> >>
> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> > >> >> >>> > >> >>
> > >> >> >>> > >> >> Once this was working it should be straightforward to
> > >> >> build
> > >> >> >>> more
> > >> >> >>> > >> >> strongly typed services and possible put together some
> > >> >> >>> generation
> > >> >> >>> > >> >> tooling.  We could also start looking at support for a
> > >> >> more
> > >> >> >>> > RESTFul
> > >> >> >>> > >> >> interface.
> > >> >> >>> > >> >> --
> > >> >> >>> > >> >> Kevin
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >> Luciano Resende wrote:
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>> Recently, people have been starting to talk about
> > >> >> better DAS
> > >> >> >>> > >> >>> integration
> > >> >> >>> > >> >>> with DAS, and below are some threads on the subject :
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> > >> >> msg08833.html
> > >> >> >>> > >> >>>
> > >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> > >> >> msg08923.html
> > >> >> >>> > >> >>>
> > >> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> > >> >> >>> msg09715.html
> > >> >> >>> >
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
> > >> >> what  I'm
> > >> >> >>> > >> >>> saying is not
> > >> >> >>> > >> >>> yet available on SCA today.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Today, defining a service to work with a relational
> > >> >> >>> database, you
> > >> >> >>> > >> >>> will need
> > >> >> >>> > >> >>> to code the persistence side of the service where CRUD
> > >> >> >>> operations
> > >> >> >>> > >> >>> to the
> > >> >> >>> > >> >>> database will be done.
> > >> >> >>> > >> >>> I was thinking on a simpler, easier way, where coding
> > >> >> the
> > >> >> >>> CRUD
> > >> >> >>> > >> >>> operations on
> > >> >> >>> > >> >>> the persistence layer would be avoided as much as
> > >> >> possible.
> > >> >> >>> > >> >>> The idea would be to have a more "declarative DAS"
> when
> > >> >> >>> defining
> > >> >> >>> > SCA
> > >> >> >>> > >> >>> Services, so you would either use some Annotations
> > >> >> or  SCDL
> > >> >> to
> > >> >> >>> > >> have  the
> > >> >> >>> > >> >>> "declarative DAS"  configuration inside it.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> I was thinking on something like....
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> SCDL Definition would look something like this :
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> <component name="AccountDataService">
> > >> >> >>> > >> >>>   <interface.java
> > >> >> >>> > >> >>>
> > >> >> class="bigbank.account.services.account.AccountService"/>
> > >> >> >>> > >> >>>   <implementation.das="dasConfig.properties"
> > >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> > >> >> >>> > >> >>> </component>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> The AccountService Interface would look like this
> > >> >> (missing
> > >> >> >>> any
> > >> >> >>> > SCA
> > >> >> >>> > >> >>> annotations):
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> public interface AccountService {
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>    public List getAllCustomers();
> > >> >> >>> > >> >>>    public Object getCustomerAccount(String
> > >> >> accountNumber);
> > >> >> >>> > >> >>> }
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> The DAS config would look like this, and would have
> the
> > >> >> >>> > definition
> > >> >> >>> > >> >>> for the
> > >> >> >>> > >> >>> "all companies" command.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> <Config ...>
> > >> >> >>> > >> >>>    ...
> > >> >> >>> > >> >>>   <ConnectionInfo dataSource="java:comp/env/jdbc/
> > >> >> bigbank"/>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>   <Command name="getAllCustomers" SQL="select * from
> > >> >> >>> CUSTOMERS"
> > >> >> >>> > >> >>> kind="Select"/>
> > >> >> >>> > >> >>>   <Command name="getCustomerAccount" SQL="SELECT
> > >> >> >>> accountNumber,
> > >> >> >>> > >> >>> accountType, balance FROM accounts where
> > >> >> accountNumber = ?"
> > >> >> >>> > >> >>> kind="Select" />
> > >> >> >>> > >> >>>   ...
> > >> >> >>> > >> >>> </Config>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
> > >> >> >>> > >> >>>   - If a DAS config file is provided, based on the
> > >> >> >>> > SCDL  definition,
> > >> >> >>> > >> we
> > >> >> >>> > >> >>> would look for "DAS command" based on the name of the
> > >> >> getter
> > >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
> > >> >> command)
> > >> >> >>> > >> >>>   - Otherwise, we would try to do a map directly to a
> > >> >> >>> > >> stored  procedure
> > >> >> >>> > >> >>>   - We could also have a way to force the mapping by
> > >> >> using
> > >> >> >>> > >> annotation
> > >> >> >>> > >> >>> (e.g@Procedure on the method level)
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Mapping between method parameter and command parameter
> > >> >> >>> > >> >>>   - We would need to define a method for mapping the
> > >> >> method
> > >> >> >>> > >> >>> parameters to
> > >> >> >>> > >> >>> the query paramters either based on position (
> e.gfirst
> > >> >> >>> method
> > >> >> >>> > >> >>> parameter
> > >> >> >>> > >> >>> maps to the first command paramter), or we would do
> > some
> > >> >> >>> > mapping  by
> > >> >> >>> > >> >>> name
> > >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Note:
> > >> >> >>> > >> >>>   - A SCDL connection information would override the
> > DAS
> > >> >> >>> Config
> > >> >> >>> > file
> > >> >> >>> > >> >>> connection information.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Benefits
> > >> >> >>> > >> >>>   - It's All about simplicity and easy of use
> > >> >> >>> > >> >>>   - This would allow a user to define a service
> without
> > >> >> >>> having to
> > >> >> >>> >
> > >> >> >>> > >> >>> explicitly having to code any Data Access related
> code.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Implementation approaches
> > >> >> >>> > >> >>>   - Utilizing DAS : This approach would start from the
> > >> >> >>> current
> > >> >> >>> > >> >>> Tuscany DAS
> > >> >> >>> > >> >>> implementation, where functionality would be already
> > >> >> >>> > available,  but
> > >> >> >>> > >> >>> the
> > >> >> >>> > >> >>> service implementation would be tied to SDO and RDB
> > >> >> as this
> > >> >> >>> > is  what
> > >> >> >>> > >> >>> DAS
> > >> >> >>> > >> >>> supports today.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>   - Start simple and grow : We could start simple, by
> > >> >> >>> having a
> > >> >> >>> > >> simple
> > >> >> >>> > >> >>> implementation based on JDBC and would return some
> > >> >> simple
> > >> >> >>> > >> >>> collection as a
> > >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
> > could
> > >> >> >>> give us
> > >> >> >>> > a
> > >> >> >>> > >> >>> quick
> > >> >> >>> > >> >>> start to flush implementation details and get a proven
> > >> >> >>> design,
> > >> >> >>> > and
> > >> >> >>> > >> >>> this
> > >> >> >>> > >> >>> could get evolved to use a DAS that would support
> > >> >> multiple
> > >> >> >>> > backends
> > >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
> > >> >> non- SDO
> > >> >> >>> types
> > >> >> >>> > >> as a
> > >> >> >>> > >> >>> command
> > >> >> >>> > >> >>> result.
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> Toughts ?
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> - Luciano
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> wrote:
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> Great.  I would like to help with this.  I have been
> > >> >> >>> thinking
> > >> >> >>> > for
> > >> >> >>> > >> >>>> awhile
> > >> >> >>> > >> >>>> about how to best integrate the RDB DAS within SCA.
> > >> >> For
> > >> >> >>> > >> example,  the
> > >> >> >>> > >> >>>> current BBank scenario uses the RDB DAS as a utility
> > >> >> but it
> > >> >> >>> > >> would be
> > >> >> >>> > >> >>>> nice if it could "wire in" a RDB DAS service or be
> > >> >> >>> injected with
> > >> >> >>> > a
> > >> >> >>> > >> >>>> configured DAS.  Another thing we want to eventually
> > >> >> >>> explore is
> > >> >> >>> > >> >>>> exposing
> > >> >> >>> > >> >>>> a DAS as REST-oriented services.  As we have seen
> > >> >> from the
> > >> >> >>> > parent
> > >> >> >>> > >> >>>> thread
> > >> >> >>> > >> >>>> there are almost too many possible approaches.
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> My first thought is to model the DAS as a service and
> > >> >> >>> create a
> > >> >> >>> > new
> > >> >> >>> > >> >>>> implementation kind (implementation.rdbdas).  The
> main
> > >> >> >>> reason
> > >> >> >>> > has
> > >> >> >>> > >> >>>> to do
> > >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
> > >> >> >>> > Jeremy  mentioned
> > >> >> >>> > >> >>>> which
> > >> >> >>> > >> >>>> is all about creating data access services
> > >> >> >>> declaratively.  A new
> > >> >> >>> > >> >>>> component type and a service that we build by hand
> > >> >> would be
> > >> >> >>> > a  good
> > >> >> >>> > >> >>>> step
> > >> >> >>> > >> >>>> in this direction.
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> We might want to expose a DAS service with an
> > >> >> interface  like
> > >> >> >>> > this:
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>>     public interface RDBDASService
> > >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
> > >> >> >>> > >> >>>>         DataObject execute(String commandName);
> > >> >> >>> > >> >>>>         DataObject executeSQL(String abitrarySQL);
> > >> >> >>> > >> >>>>     }
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> The service would be initialized with an optional
> > >> >> RDB DAS
> > >> >> >>> > >> config  file
> > >> >> >>> > >> >>>> that defines connection properties, a set of
> commands,
> > >> >> >>> etc.  So,
> > >> >> >>> > >> >>>> different services implementing the same interface
> > >> >> could be
> > >> >> >>> > >> >>>> initialized
> > >> >> >>> > >> >>>> from separate config files.
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> Eventually, we might want to build services like
> this:
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>>     public interface Customers_RDBDASService
> > >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
> > >> >> >>> > >> >>>>         DataObject getAllCustomersWithLastName
> (String
> > >> >> >>> > lastName);
> > >> >> >>> > >> >>>>         DataObject getAll CustomersAndOrdersForID
> (int
> > >> >> >>> > customerId);
> > >> >> >>> > >> >>>>     }
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> But, for this to be very useful would probably
> require
> > >> >> >>> some code
> > >> >> >>> > >> >>>> generation tooling.
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> Thoughts?
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> --Kevin
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> Luciano Resende wrote:
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
> > >> >> declarative
> > >> >> >>> > DAS  and
> > >> >> >>> > >> >>>> will be
> > >> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
> > >> >> >>> > >> >>>> >
> > >> >> >>> > >> >>>> > - Luciano
> > >> >> >>> > >> >>>> >
> > >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
> > >> >> wrote:
> > >> >> >>> > >> >>>> >
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >> On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
> > >> >> >>> > >> >>>> >> >> This sounds like having cake, eating it, and
> > also
> > >> >> >>> > being  able
> > >> >> >>> > >> to
> > >> >> >>> > >> >>>> >> >> give it to a friend :-) We provide the
> > >> >> flexibility  for
> > >> >> >>> > users:
> > >> >> >>> > >> >>>> >> >> 1) to access infrastructure services through
> > >> >> >>> properties
> > >> >> >>> > >> >>>> >> > Yes for things like JPA, JDBC, etc.
> > >> >> >>> > >> >>>> >> >> 2) to reference infrastructure services through
> > >> >> >>> > inclusion  in
> > >> >> >>> > >> >>>> their
> > >> >> >>> > >> >>>> >> >> assembly
> > >> >> >>> > >> >>>> >> > If we do 1 I don't think we should do 2 (that
> > >> >> >>> doesn't stop
> > >> >> >>> > >> >>>> someone
> > >> >> >>> > >> >>>> >> > from extending Tuscany to do it though). See my
> > >> >> >>> comments
> > >> >> >>> > >> below.
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> > >> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
> > >> >> >>> > should  welcome
> > >> >> >>> > >> it
> > >> >> >>> > >> >>>> >> like we would any other contribution.
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >> >> 3) to access data through an application
> > >> >> service with
> > >> >> >>> > >> >>>> declarative
> > >> >> >>> > >> >>>> >> >> implementation by DAS
> > >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
> > >> >> >>> > >> >>>> >> --
> > >> >> >>> > >> >>>> >> Jeremy
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>> >>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >>
> > >> >> >>>
> > >> >>
> --------------------------------------------------------------------
> > >> >> >>> > >> -
> > >> >> >>> > >> >>>> >> 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
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>>
> > >> >> >>> > >> >>>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> > >> >>
> > >> >> >>> >
> > >> >> >>>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> >>> > >> >> 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
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> > >> >
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>> > >>
> > >> >> >>>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> >>> > >> 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
> > >> >> >>> >
> > >> >> >>> >
> > >> >> >>>
> > >> >> >>>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> >>> 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
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > ---------------------------------------------------------------------
> > >> >> 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
> > >>
> > >>
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: Declarative DAS, was Re: Modeling the RDB DAS in SCA

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

+1 I'll be available on IRC for chatting...

On 11/8/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Hi Amita,
> This sounds good.  Thanks for getting up so early!
> --
> Kevin
>
>
> Amita Vadhavkar wrote:
>
> > Hello Kevin , Luciano,
> > Thanks a lot for all your suggestions and looking forward to have a
> > IRC chat
> > with you.
> > I am proposing 9th Nov 5.30 a.m. IST (8th Nov 4.00 p.m. PST) for
> > approx. 1
> > hr.
> > Please join the chat and we all can discuss -
> > 1) what we are trying to provide - service, container
> > 2) what all features can be provided
> > 3) any high level design suggestions ( sim. to Kevin's latest reply )
> > 4) any other suggestions
> > 5) we can try to come up with a list of work items
> > This will be very helpful in getting a clear picture of what all can
> > be done
> >
> > in SCA (as well as DAS) domain for our current work.
> >
> > Regards,
> > Amita
> >
> > On 11/8/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >>
> >> Hello Amita,
> >>
> >> This looks promising.  I notice your test case uses explicit updates
> and
> >> inserts.  While this is supported by the DAS it is not the preferred
> >> usage which is to allow the RDB DAS to generate the CUD statements from
> >> the SDO change history.  Could you modify the example to read a data
> >> graph and then post the changes back via "applyChanges"?  Maybe the
> >> equivalent of this simple test from the DAS test suite:
> >>
> >>    public void testReadModifyApply4() throws Exception {
> >>
> >>        DAS das = DAS.FACTORY.createDAS(getConfig("CustomerConfig.xml"),
> >> getConnection());
> >>        // Read customer with particular ID
> >>        Command select = das.getCommand("getCustomer");
> >>        select.setParameter(1, 1);
> >>        DataObject root = select.executeQuery();
> >>
> >>        DataObject customer = (DataObject) root.get("CUSTOMER[1]");
> >>
> >>        // Modify customer
> >>        customer.set("LASTNAME", "Pavick");
> >>
> >>        das.applyChanges(root);
> >>
> >>        // Verify the change
> >>        root = select.executeQuery();
> >>        assertEquals("Pavick",
> >> root.getDataObject("CUSTOMER[1]").getString("LASTNAME"));
> >>
> >>    }
> >>
> >> Also, this service interface seems difficult to work with since command
> >> identifiers and argument values are encoded in the params Vector
> >>
> >>    public interface CustomersOrdersService {
> >>
> >>        void execute(Vector params);
> >>        DataObject executeQuery(Vector params);
> >>        void applyChanges(Vector params);
> >>        DataObject executeAdhoc(Vector params);//adhoc query
> >> implementation
> >>
> >>        DataObject getAllCustomers(Vector paramsList);
> >>
> >>    }
> >>
> >> Do you think it possible to implement something like the following
> >> interface:
> >>
> >>    public interface DynamicRDBDASService {
> >>
> >>        DataObject execute(String commandName, List params);
> >>        DataObject executeAdHoc(String queryString, List params);
> >>        void applyChanges();
> >>    }
> >>
> >> The name is kind of long (suggestions welcome) but, I think this
> >> interface could be generic and set of available commands is driven by
> >> the provided DAS config file.  I am not sure how we might support SP
> OUT
> >> parameters but we can think about that later.
> >>
> >> I does seem like you and Luciano should team up on this.
> >>
> >> Thanks!
> >> --
> >> Kevin
> >>
> >>
> >>
> >>
> >> Amita Vadhavkar wrote:
> >>
> >> > Hi Kevin,
> >> > Thanks a lot for the comments. I have posted the code and doc on
> >> JIRA-904
> >> > for the container work. Also, am most likely missing something in the
> >> > database
> >> > connection portion. Would like to discuss with you.
> >> >
> >> > Will you please provide feedback on JIRA-904 attachments?
> >> >
> >> > I am checking with Luciano for a convenient date/time when we can
> >> chat,
> >> > would
> >> > be great if you can also join. I am in IST timezone.
> >> >
> >> > Regards,
> >> > Amita
> >> >
> >> > On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >
> >> >>
> >> >> Hi Amita,
> >> >> This is looking good.  Some comments inline:
> >> >>
> >> >> Amita Vadhavkar wrote:
> >> >>
> >> >> > Hi,
> >> >> > I am trying to create a container for DAS-SCA too (not just for
> >> stored
> >> >> > procedure) and will be able to send a working code in ML over the
> >> >> > weekend.
> >> >> >
> >> >> > Below is summary of what I got so far from the previous mail
> >> >> > discussions and
> >> >> > some questions.
> >> >> >
> >> >> >
> >> >> > The integration between DAS and SCA can happen at application
> level
> >> as
> >> >> > service or at container level.
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2 different possible approaches –
> >> >> >
> >> >> > static – e.g. getAllCustomers
> >> >> >
> >> >> > dynamic – e.g. execute("all customers");
> >> >> >
> >> >> >
> >> >> >
> >> >> > For application level service – it is the sample *
> >> >> > sample-StoredProcedureService.jar*  or what Luciano is providing
> in
> >> >> more
> >> >> > details, is an example.  In *sample-StoredProcedureService.jar*
> >> >> example
> >> >> > dynamic approach is followed
> >> >> >
> >> >> >
> >> >> >
> >> >> > For container approach – again static or dynamic approach can be
> >> >> > followed.
> >> >> > For static – it's like providing service for getAllCompanies(),
> >> >> > getAllCustomers() etc. whereas for dynamic its like
> >> execute(command)
> >> >> > where
> >> >> > command can be "getAllCompanies", "getAllCustomers". Etc.
> >> >> >
> >> >> >
> >> >> >
> >> >> >            I am working on a container implementation where
> dynamic
> >> >> > approach is followed.
> >> >> >
> >> >> If I understand correctly, the container approach will provide the
> >> >> tightest integration with SCA and make things easier for
> >> end-users.  Do
> >> >> you agree?
> >> >>
> >> >> >
> >> >> >
> >> >> > There are 2 places where extensibility is required –
> >> >> >
> >> >> > 1)      for providing different data access mechanisms. i.e. today
> >> >> > there is
> >> >> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
> >> >> > scdl will
> >> >> > be same, but the exampleconfig.xml will change.
> >> >> >
> >> >> > In the container I am working on - Scdl has a new tag
> >> >> >
> >> >> > Scdl has a new tag
> >> >> >  <da:implementation.dascript="customersOrders/CustomersOrders.xml"
> >> >> > dataAccessType="rdb"/>
> >> >> >
> >> >> >
> >> >> >
> >> >> > Here, dataAccessType – is the key which tells whether it's RDB or
> >> >> > something
> >> >> > else. And the xml script provides the connection and data store
> >> >> details.
> >> >> >
> >> >> >
> >> >> >
> >> >> > 2)      for RDB-DAS – providing support for different databases
> >> (this
> >> >> > portion should be part of DAS and  not SCA.) In the current
> >> container
> >> >> > I am
> >> >> > working on it is provided as a package -
> >> >> > org.apache.tuscany.container.dataaccessshelper package  - which
> >> should
> >> >> > finally go into DAS codeline(?).
> >> >> >
> >> >> >
> >> >> Currently, there are two ways to specify a particular database:
> >> first,
> >> >> the user can pass a JDBC Connection to the DAS Factory when
> >> creating a
> >> >> DAS instance.  The second is that a DataSource can be specified in
> >> the
> >> >> DAS Config xml file in which case the DAS is responsible for getting
> >> the
> >> >> connection.
> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > For static approach we may need some code generation tooling.
> >> >>
> >> >> Right.  That is why I think it best to start with dynamic.  But, we
> >> will
> >> >> want static support as well.
> >> >>
> >> >> > Also could not
> >> >> > understand how this can be merged into RESTful interfaces. (this
> >> was
> >> >> > mentioned in some mail conversation)
> >> >> >
> >> >> >
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Amita
> >> >> >
> >> >> >
> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >
> >> >> >>
> >> >> >> Luciano Resende wrote:
> >> >> >>
> >> >> >> > Comments in-line...
> >> >> >> >
> >> >> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> >> >> >> >>
> >> >> >> >> > Hi,
> >> >> >> >> >
> >> >> >> >> > I would also like to understand this a little better ...
> here
> >> >> I am
> >> >> >> >> > thinking
> >> >> >> >> > aloud and hope the others will help in getting my
> >> persceptions
> >> >> >> >> > right...
> >> >> >> >> >
> >> >> >> >> > I guess firstly it is a question of how or where we want to
> >> >> >> >> > position 'DAS
> >> >> >> >> > Integration' in SCA.  Is is something we want to integrate
> as
> >> >> the
> >> >> >> >> > Application Layer, which I understand is what Amita is
> trying
> >> >> >> >> > presently and
> >> >> >> >> > which Jim refers to as component implementation.   In this
> >> >> option
> >> >> >> >> > we get to
> >> >> >> >> > do some sort of a service wrapper to DAS and then it
> >> becomes a
> >> >> >> >> > demonstration
> >> >> >> >> > of two Tuscany subprojects integrating at application level.
> >> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Yes, I think we have space to position DAS both ways, and
> >> >> integrating
> >> >> >> > in the
> >> >> >> > application layer by exposing DAS as a service would be a very
> >> easy
> >> >> >> and
> >> >> >> > quick, this could be exposed as a sample app, and could show we
> >> are
> >> >> >> > working
> >> >> >> > on getting a better integration between DAS and SCA
> >> >> >> >
> >> >> >> >
> >> >> >> >> Or do we want to position DAS at the infrastructure layer as
> >> >> another
> >> >> >> >> > extension type (either container or binding).  I guess
> >> this is
> >> >> >> >> > where Ant
> >> >> >> >> > started this - proposing a JDBC container / binding for
> >> >> component
> >> >> >> >> > implementation in StoredProcedures.
> >> >> >> >> I was thinking a DAS was a way to declaratively model
> >> >> heterogeneous
> >> >> >> >> data as a service and offer a mechanism for remoting that
> data.
> >> In
> >> >> >> >> other words, it provided the ability for an application to
> >> perform
> >> >> >> >> CRUD using a high-level contract (interface) and having those
> >> >> >> >> operations take place across a service network.  How this is
> >> >> hooked
> >> >> >> >> into the SCA container is probably best done as an extension
> >> type,
> >> >> >> >> i.e. someone could specify:
> >> >> >> >>
> >> >> >> >> <component name="Foo">
> >> >> >> >>         <implementation.das>
> >> >> >> >>                 <interface.java ....>
> >> >> >> >>         </implementation.das>
> >> >> >> >> </component>
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Yes, this goes back to the way I was thinking on my original
> >> >> proposal.
> >> >> >> >
> >> >> >> >
> >> >> >> >> If this is the path we should take
> >> >> >> >> > then we probably have to think beyond DAS - to something
> more
> >> >> >> >> > general - of
> >> >> >> >> > which DAS is just a special case.  I suppose this is what
> Jim
> >> >> has
> >> >> >> also
> >> >> >> >> > suggested in trying to explore other persistence mechanisms.
> >> >> >> >> >
> >> >> >> >> This may be the crux of the confusion. I was thinking DAS
> >> >> provides a
> >> >> >> >> general mechanism for accessing heterogeneous data and is only
> >> >> right
> >> >> >> >> now tied to SQL because of resource constraints (i.e. we
> >> have to
> >> >> >> >> start somewhere). Ultimately, DAS should provide the
> >> >> infrastructure
> >> >> >> >> for dealing with multiple, varied data stores and mechanisms
> >> for
> >> >> >> >> querying across them. In other words, I guess I am saying DAS
> >> >> should
> >> >> >> >> be the general solution (declarative and heterogeneous) since
> >> >> if it
> >> >> >> >> is only a programmatic way to access relational data then its
> >> >> value
> >> >> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > Yes, the current status of DAS implementation is RDB only. I
> >> would
> >> >> say
> >> >> >> > that,
> >> >> >> > in the future, I'd like to see a heterogeneous DAS that would
> >> give
> >> >> you
> >> >> >> > access to different data stores, and probably support non-SDO
> >> types
> >> >> as
> >> >> >> > well.
> >> >> >> >
> >> >> >> >> I too feel that this is something that must be done as an
> >> >> extension
> >> >> >> >> > type -
> >> >> >> >> > but yet to get my hands on the general scheme of things that
> >> DAS
> >> >> >> >> > can slip
> >> >> >> >> > into. Infact the other thread where Jeremy has taken
> >> forward a
> >> >> >> >> > proposal to
> >> >> >> >> > the specs group on resources tempts me to think that there
> is
> >> >> going
> >> >> >> >> > to be
> >> >> >> >> > something in that which we can leverage from.
> >> >> >> >> >
> >> >> >> >> I think resources are orthogonal as they are about a component
> >> >> >> >> implementation's contract with its container. Declarative data
> >> >> >> >> services on the other hand are about application constructs
> >> >> that can
> >> >> >> >> be wired to.
> >> >> >> >>
> >> >> >> >> > I hope to get a better understanding this as we go along in
> >> this
> >> >> >> >> > thread :)
> >> >> >> >> >
> >> >> >> >> Me too :-) As soon as I have trouble explaining technologies
> to
> >> >> .NET
> >> >> >> >> people and they say "you Unix/Java people are at it again
> >> with a
> >> >> >> >> thousand ways to do the same exact thing" it causes me to
> think
> >> >> that
> >> >> >> >> maybe we need to clarify our message.
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > If we all think it would be useful, I could try to summarize
> the
> >> >> >> > thread on
> >> >> >> > the wiki with a more clean proposal incorporating all your
> >> >> feedback ,
> >> >> >> > what
> >> >> >> > you guys think ?
> >> >> >>
> >> >> >> Yes.  Great idea.
> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > Jim
> >> >> >> >
> >> >> >> >> > Thanks
> >> >> >> >> >
> >> >> >> >> > - Venkat
> >> >> >> >> >
> >> >> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >> >>
> >> >> >> >> >> Jim Marino wrote:
> >> >> >> >> >>
> >> >> >> >> >> > When I first read the thread on this, I thought the DAS
> >> >> service
> >> >> >> >> >> would
> >> >> >> >> >> > be a component extension type (e.g. analogous to a
> >> >> >> >> >> > implementation.java or implementation.ejb) and not a
> >> >> component
> >> >> >> >> >> > implementation type, which would allow for dynamic and
> >> >> >> eventually
> >> >> >> >> >> > declarative configuration styles.
> >> >> >> >> >>
> >> >> >> >> >> I have not very familiar with the terminology so I am not
> >> sure
> >> >> >> what
> >> >> >> a
> >> >> >> >> >> "component extension type" is.  But, I do think we
> >> eventually
> >> >> want
> >> >> >> >> >> "implementation.rdbdas".  Wouldn't this be a new
> >> implementation
> >> >> >> type?
> >> >> >> >> >>
> >> >> >> >> >> It looks like Amita chose to start with a POJO.  I notice
> >> >> the use
> >> >> >> >> >> of "
> >> >> >> >> >> implementation.java".
> >> >> >> >> >>
> >> >> >> >> >> > Either way, though, I am curious as  to why
> >> >> >> >> >> >
> >> >> >> >> >> > public DAS configureService(String configFile);
> >> >> >> >> >> >
> >> >> >> >> >> > exists as part of the service definition? If the DAS
> >> service
> >> >> >> was a
> >> >> >> >> >> > component extension type, it could be handled as part
> >> of the
> >> >> >> >> >> > application bootstrap. If the DAS service was a component
> >> >> >> >> >> > implementation type, the configuration file URI could be
> >> >> passed
> >> >> >> >> >> in as
> >> >> >> >> >> > a property and then processed in an initializer method
> >> >> decorated
> >> >> >> by
> >> >> >> >> >> > the SCA @Init annotation. In the latter case, if the
> >> >> >> implementation
> >> >> >> >> >> > of DASService thread-safe (hopefully it is since
> >> >> configuration
> >> >> >> >> >> would
> >> >> >> >> >> > seem to be a heavyweight operation), then I would make
> the
> >> >> >> >> >> component
> >> >> >> >> >> > module scoped to avoid initialization overhead on every
> >> >> >> resolution.
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > In both approaches (extension vs. implementation type),
> >> >> having
> >> >> >> >> >> > configuration exposed to the application doesn't quite
> >> feel
> >> >> >> right,
> >> >> >> >> >> > since that is what DI tries to externalize.
> >> >> >> >> >>
> >> >> >> >> >> I agree.  The configuration should be part of the
> >> >> >> initialization and
> >> >> >> >> >> should use SCA patterns to do this.  I think that Amita
> >> meant
> >> >> >> to use
> >> >> >> >> >> eventually use a component property for the DAS config info
> >> but
> >> >> >> >> >> started
> >> >> >> >> >> with a method.
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > Also, I was thinking that in having this a component
> >> >> extension
> >> >> >> >> >> type,
> >> >> >> >> >> > the service interfaces returned from a resolution could
> >> >> include
> >> >> >> the
> >> >> >> >> >> > dynamic one described below or static ones people have
> >> >> >> mentioned.
> >> >> >> I
> >> >> >> >> >> > guess it is best to start with the easier-to-implement
> >> part
> >> >> >> >> >> first and
> >> >> >> >> >> > support the dynamic interface.
> >> >> >> >> >> >
> >> >> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be
> >> >> nice to
> >> >> >> >> >> > understand what DAS provides in relation to other
> >> persistence
> >> >> >> >> >> > technologies. Outside of the Java world, Microsoft is
> >> >> promoting
> >> >> >> >> >> LINQ
> >> >> >> >> >> > which is really interesting, and it would be
> >> informative to
> >> >> >> compare
> >> >> >> >> >> > the goals of DAS with that approach (there are obvious
> >> >> >> differences
> >> >> >> >> >> > such as having the query language a strongly-typed part
> of
> >> >> the
> >> >> >> >> >> > programming language, e.g. C#, and LINQ's use of
> >> closures).
> >> >> >> >> >> >
> >> >> >> >> >> > In contrasting DAS to O-R technologies, I see the primary
> >> use
> >> >> >> cases
> >> >> >> >> >> > for the former being a quick way to issue a query that
> may
> >> be
> >> >> >> >> >> > executed against *heterogeneous* data stores and have
> that
> >> >> data
> >> >> >> >> >> flow
> >> >> >> >> >> > remotely or to a client that is not necessarily
> >> >> Java-based. One
> >> >> >> key
> >> >> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> >> >> >> >> >> (Hibernate
> >> >> >> >> >> > and JPA are about as easy):
> >> >> >> >> >> >
> >> >> >> >> >> IMO the primary use case for DAS is an application that is
> >> SDO-
> >> >> >> >> >> centric
> >> >> >> >> >> and is taking advantage of its disconnected
> >> capabilities.  The
> >> >> RDB
> >> >> >> >> >> DAS
> >> >> >> >> >> is built to work with SDO and uses the change summary to
> >> drive
> >> >> >> >> >> changes
> >> >> >> >> >> made to a disconnected data graph back to some store.
> >> This is
> >> >> not
> >> >> >> to
> >> >> >> >> >> say that a relational DAS could not be built on top of
> >> JPA, in
> >> >> >> fact,
> >> >> >> >> >> this might be a very useful thing to do.  The
> implementation
> >> we
> >> >> >> >> >> currently have provides a very straightforward implicit
> >> mapping
> >> >> >> from
> >> >> >> >> >> DataObjects to Tables.  If more capable mapping is needed
> >> >> then it
> >> >> >> >> >> makes
> >> >> >> >> >> sense to use the JPA-defined technology and artifacts.  A
> >> >> modified
> >> >> >> >> >> Entity manager might be needed to take advantage of SDO's
> >> >> change
> >> >> >> >> >> summary.
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > public interface CustomerDao extends BaseQuery {
> >> >> >> >> >> >     @Select("select * from customers where city = ?1")
> >> >> >> >> >> >     DataSet<Customer> findCustomersFrom(String city);
> >> >> >> >> >> > }
> >> >> >> >> >> >
> >> >> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> >> >> >> >> >> > (CustomerDao.class, datasource);
> >> >> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> > The other key is remote data and change lists.  I think
> >> there
> >> >> >> are
> >> >> >> >> >> > (literally) about a thousand ways that already exist to
> >> >> >> handle the
> >> >> >> >> >> > "local" data case. For change lists, interop with
> >> ADO.NET's
> >> >> >> change
> >> >> >> >> >> > summary facilities would be interesting.
> >> >> >> >> >>
> >> >> >> >> >> I agree.  Also, it looks like Xcalia may have a similar
> >> >> thought:
> >> >> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think
> >> >> it is
> >> >> >> >> >> > important we have a clear statement as to when it is
> >> >> appropriate
> >> >> >> >> >> and
> >> >> >> >> >> > not appropriate to use. One place to start would be to
> >> >> compare
> >> >> >> >> >> it to
> >> >> >> >> >> > JDBC 4 and JPA.
> >> >> >> >> >>
> >> >> >> >> >> We can get started with JPA:
> >> >> >> >> >>
> >> >> >> >> >>     * JPA is java-specific, container-based, built around a
> >> >> >> connected
> >> >> >> >> >>       data model and offers a complete O/R mapping for
> POJOs
> >> >> >> >> >>
> >> >> >> >> >>     * The RDB DAS is a java implementation of a language -
> >> >> neutral
> >> >> >> >> >>       concept (hopefully specified some day) that is
> >> >> >> containerless,
> >> >> >> >> >>       assumes a disconnected data model and provides a
> >> simple,
> >> >> >> >> >> implicit
> >> >> >> >> >>       mapping for SDO DataObjects (Dynamic or Static) to
> >> >> >> relational
> >> >> >> >> >> tables.
> >> >> >> >> >>
> >> >> >> >> >> Anything else?
> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > Jim
> >> >> >> >> >> >
> >> >> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >> >> >> >> >> >
> >> >> >> >> >> >> Hi Amita
> >> >> >> >> >> >>
> >> >> >> >> >> >> I think we were both going on the same way, with the DAS
> >> >> >> Service
> >> >> >> >> >> >> sample,
> >> >> >> >> >> >> altough i had the interface more like this, to be more
> >> >> >> flexible :
> >> >> >> >> >> >>
> >> >> >> >> >> >> public interface DASService {
> >> >> >> >> >> >>
> >> >> >> >> >> >>    public DAS configureService(String configFile);
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >>    public DataObject executeCommand(String commandName);
> >> >> >> >> >> >>    public DataObject execute(String newCommand);
> >> >> >> >> >> >>    public void applyChanges(DataObject graphRoot);
> >> >> >> >> >> >> }
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> As for having it as a sample, maybe we could defined the
> >> >> >> >> >> DASService
> >> >> >> >> >> >> as one
> >> >> >> >> >> >> sample itself, and have a second version of companyWeb
> >> that
> >> >> >> would
> >> >> >> >> >> >> consume
> >> >> >> >> >> >> the service, something like :
> >> >> >> >> >> >>
> >> >> >> >> >> >> das\samples\companyWeb
> >> >> >> >> >> >> das\samples\dasService
> >> >> >> >> >> >> das\samples.companyWeb.service
> >> >> >> >> >> >>
> >> >> >> >> >> >> or, more like BigBank
> >> >> >> >> >> >>
> >> >> >> >> >> >> das\samples\companyweb.Service\dasService
> >> >> >> >> >> >> das\samples\companyweb.Service\webClient
> >> >> >> >> >> >>
> >> >> >> >> >> >> Or even in sampleApps...
> >> >> >> >> >> >>
> >> >> >> >> >> >> Toughts ?
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
> >> >> wrote:
> >> >> >> >> >> >>
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> Hi ,
> >> >> >> >> >> >>> I am also following up another thread
> >> >> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> >> msg09944.html
> >> >> >> >> >> >>> on the
> >> >> >> >> >> >>> similar issue (JDBC stored procedure container
> >> >> >> >> >> >>> using DAS)
> >> >> >> >> >> >>> Besides the fact that I am actively working on the
> >> >> container
> >> >> >> >> >> work,
> >> >> >> >> >> >>> I also
> >> >> >> >> >> >>> have tried to
> >> >> >> >> >> >>> develop a sample based on the below discussion,
> >> following
> >> >> >> dynamic
> >> >> >> >> >> >>> approach.
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> I am attaching the same here. Please take a look and
> >> give
> >> >> your
> >> >> >> >> >> >>> suggestions.
> >> >> >> >> >> >>> In this, StoredProcedureService implementation has
> >> >> >> >> >> setConfigInfo (DAS
> >> >> >> >> >> >>> Config) and
> >> >> >> >> >> >>> execute(Any SQL). This can be made more complete with
> >> >> >> >> >> executeSQL(),
> >> >> >> >> >> >>> applyChanges()
> >> >> >> >> >> >>> etc.
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> Can this be added to the existing set of samples?
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> Regards,
> >> >> >> >> >> >>> Amita
> >> >> >> >> >> >>>
> >> >> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > Luciano Resende wrote:
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > Kevin, from what I understood from your
> >> suggestion, it
> >> >> was
> >> >> >> >> >> >>> looking to
> >> >> >> >> >> >>> > me
> >> >> >> >> >> >>> > > more like exposing DAS as a service :
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > >>>   public interface RDBDASService
> >> >> >> >> >> >>> > >>>        DataObject execute(String commandName);
> >> >> >> >> >> >>> > >>>        DataObject executeSQL(String abitrarySQL);
> >> >> >> >> >> >>> > >>>        void applyChanges(DataObject graphRoot);
> >> >> >> >> >> >>> > >>>    }
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > Yes, I am talking about exposing a DAS Service
> >> configured
> >> >> >> >> >> with a
> >> >> >> >> >> >>> > specific set of capabilities/commands defined in
> >> the DAS
> >> >> >> config
> >> >> >> >> >> >>> file.
> >> >> >> >> >> >>> > So, if the implementation of the service interface
> >> above
> >> >> was
> >> >> >> >> >> >>> configured
> >> >> >> >> >> >>> > to work with Customers they would use the service
> like
> >> >> this:
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> >    List customers = myRDBDASService.execute
> >> >> >> ("getAllCustomers");
> >> >> >> >> >> >>> >    String name = customers.get(0).getString("name");
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > This is not much different than the static
> >> interface you
> >> >> >> >> >> proposed,
> >> >> >> >> >> >>> > right?
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > And then, when a service developer defines the
> >> >> >> >> >> AccountService,
> >> >> >> >> >> >>> he will
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > have
> >> >> >> >> >> >>> > > to know about yet another service, about how DAS
> >> works,
> >> >> >> >> >> how it is
> >> >> >> >> >> >>> > > configured, etc, etc... is that right ?
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > The abilities of the service are defined by the DAS
> >> >> config
> >> >> >> >> >> file.
> >> >> >> >> >> >>> So,
> >> >> >> >> >> >>> > the person or tool that provides the config file must
> >> >> >> >> >> understand
> >> >> >> >> >> >>> how the
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > RDB DAS APIs work.  There is no getting around this.
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > My proposal was going more towards allowing the
> >> service
> >> >> >> >> >> >>> developer to
> >> >> >> >> >> >>> > > focus
> >> >> >> >> >> >>> > > on defining the service, and let the "declarative
> >> >> das" to
> >> >> >> >> >> >>> handle the
> >> >> >> >> >> >>> > > persistent layer....
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > The DAS config file is the declaration of an
> >> instance of
> >> >> the
> >> >> >> >> >> >>> DAS.  That
> >> >> >> >> >> >>> > instance can be exposed as a dynamic or typed
> service/
> >> >> >> >> >> interface.
> >> >> >> >> >> >>> That
> >> >> >> >> >> >>> > seems to be the main discussion we are having.
> >> >> Although, I
> >> >> >> >> >> may be
> >> >> >> >> >> >>> > missing something.
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > > Also, by defining some conventions over
> >> configuration
> >> >> >> >> >> and/or  using
> >> >> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a
> >> >> stored
> >> >> >> >> >> >>> procedure),
> >> >> >> >> >> >>> > the
> >> >> >> >> >> >>> > > service developer could really define a service
> that
> >> >> >> >> >> interacts
> >> >> >> >> >> >>> with a
> >> >> >> >> >> >>> > > RDB,
> >> >> >> >> >> >>> > > without having to code the service persistence
> >> layer.
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > There is a lot of potential for the use of
> >> annotations.
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > > - Luciano
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net>
> >> >> wrote:
> >> >> >> >> >> >>> > >
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> The real difference between the two approaches is
> >> that
> >> >> >> >> >> one is
> >> >> >> >> >> >>> "Typed"
> >> >> >> >> >> >>> > or
> >> >> >> >> >> >>> > >> static and the other is dynamic.  I think both are
> >> >> needed
> >> >> >> >> >> but  was
> >> >> >> >> >> >>> > >> suggesting that we start with dynamic since it
> >> is the
> >> >> >> most
> >> >> >> >> >> >>> flexible
> >> >> >> >> >> >>> > and
> >> >> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a
> >> >> static
> >> >> >> >> >> >>> capability.
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> With either, the user does not need to know about
> >> >> >> >> >> traditional
> >> >> >> >> >> >>> > >> persistence frameworks.  With the dynamic
> approach,
> >> >> >> however,
> >> >> >> >> >> >>> the user
> >> >> >> >> >> >>> > >> does need to know about the dynamic SDO API.
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> So, with the static interface the user might
> write:
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>     List customers =
> accountService.getAllCustomers
> >> ();
> >> >> >> >> >> >>> > >>     String name =
> >> >> ((Customer)customers.get(0)).getName();
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> The equivalent dynamic API might be:
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>     List customers =
> >> >> >> dasService.execute("getAllCustomers");
> >> >> >> >> >> >>> > >>     String name =
> >> >> >> ((DataObject)customers.get(0)).getString
> >> >> >> >> >> >>> ("name");
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> The first is probably a little easier for the
> >> >> application
> >> >> >> >> >> >>> developer
> >> >> >> >> >> >>> > but
> >> >> >> >> >> >>> > >> the second is much easier for the service
> >> developer.
> >> >> IMO,
> >> >> >> >> >> the
> >> >> >> >> >> >>> dynamic
> >> >> >> >> >> >>> > >> case is the best place to start and, again, we
> >> >> >> >> >> definitely  will
> >> >> >> >> >> >>> want
> >> >> >> >> >> >>> > >> support for both.
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> Thanks.
> >> >> >> >> >> >>> > >> --
> >> >> >> >> >> >>> > >> Kevin
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> Jeremy Boynes wrote:
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >> > I think this would be useful but it seems more
> >> >> like a
> >> >> >> >> >> >>> traditional
> >> >> >> >> >> >>> > >> > persistence API than what Luciano was
> suggesting.
> >> >> With
> >> >> >> >> >> this
> >> >> >> >> >> >>> one a
> >> >> >> >> >> >>> > >> > user needs to know about DataObject's, commands,
> >> SQL
> >> >> >> >> >> strings
> >> >> >> >> >> >>> etc.
> >> >> >> >> >> >>> > >> > just like they would if they were using raw
> >> JDBC or
> >> >> >> JPA.
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed
> more
> >> >> about
> >> >> >> >> >> >>> expressing
> >> >> >> >> >> >>> > >> > high-level CRUD operations as operations on a
> >> >> service
> >> >> >> >> >> >>> interface:
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>    public List getAllCustomers();
> >> >> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
> >> >> >> >> >> accountNumber);
> >> >> >> >> >> >>> > >> >>> }
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > which is all application level concepts rather
> >> >> >> >> >> than  persistence
> >> >> >> >> >> >>> > level
> >> >> >> >> >> >>> > >> > concepts. I'd actually go a little further and
> >> put
> >> >> that
> >> >> >> >> >> >>> right into
> >> >> >> >> >> >>> > >> > the service contract:
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >   public interface AccountService {
> >> >> >> >> >> >>> > >> >     List<Customer> getAllCustomers();
> >> >> >> >> >> >>> > >> >     Account getCustomerAccount(String
> >> >> accountNumber);
> >> >> >> >> >> >>> > >> >   }
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
> >> >> >> >> >> standardized
> >> >> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
> >> >> >> configuration
> >> >> >> >> >> >>> would be
> >> >> >> >> >> >>> > >> > needed except to add this to the logical
> >> assembly:
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >   <component name="AccountStore">
> >> >> >> >> >> >>> > >> >     <implementation.das
> >> resource="MySQLDatabase"/>
> >> >> >> >> >> >>> > >> >   </component>
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > With SCA's ability to translate service
> >> contracts,
> >> >> this
> >> >> >> >> >> >>> should be
> >> >> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
> >> >> >> >> >> regardless of
> >> >> >> >> >> >>> > whether
> >> >> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by
> >> IIOP or
> >> >> >> >> >> running  on
> >> >> >> >> >> a
> >> >> >> >> >> >>> > Java,
> >> >> >> >> >> >>> > >> > C++ or PHP platform.
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > The important thing here is that the client is
> >> >> >> >> >> isolated  from
> >> >> >> >> >> >>> how
> >> >> >> >> >> >>> > the
> >> >> >> >> >> >>> > >> > DAS component is provided. We could have
> multiple
> >> >> >> >> >> declarative
> >> >> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and
> one
> >> >> that
> >> >> >> did
> >> >> >> >> >> >>> stuff
> >> >> >> >> >> >>> > with
> >> >> >> >> >> >>> > >> > XML databases like Xindice; alternatively,
> >> /without
> >> >> >> >> >> altering
> >> >> >> >> >> >>> the
> >> >> >> >> >> >>> > >> > client at all/ they could switch to a custom
> >> coded
> >> >> >> version
> >> >> >> >> >> >>> written
> >> >> >> >> >> >>> > in
> >> >> >> >> >> >>> > >> > Java, C++ or a store procedure language like
> >> PL/SQL.
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > --
> >> >> >> >> >> >>> > >> > Jeremy
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams
> >> wrote:
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >> I would suggest that we start right away with a
> >> >> >> RDBDAS-
> >> >> >> >> >> based
> >> >> >> >> >> >>> > >> >> solution.  I also think that the best place to
> >> >> start
> >> >> >> >> >> would
> >> >> >> >> >> >>> be with
> >> >> >> >> >> >>> > >> >> an interface that is "weakly" typed.  That is,
> a
> >> >> >> service
> >> >> >> >> >> >>> interface
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > >> >> in terms of dynamic SDO's.  If we go this
> >> route we
> >> >> can
> >> >> >> >> >> >>> avoid the
> >> >> >> >> >> >>> > >> >> generation (by hand or otherwise) of code
> >> >> specific to
> >> >> >> >> >> a new
> >> >> >> >> >> >>> > >> >> service.  Instead, the service will be
> >> >> "instantiated"
> >> >> >> >> >> based
> >> >> >> >> >> >>> on the
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > >> >> provided DAS config file.  The service
> interface
> >> >> >> >> >> might  look
> >> >> >> >> >> >>> like
> >> >> >> >> >> >>> > >> this:
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>    public interface RDBDASService
> >> >> >> >> >> >>> > >> >>        DataObject execute(String commandName);
> >> >> >> >> >> >>> > >> >>        DataObject executeSQL(String
> >> abitrarySQL);
> >> >> >> >> >> >>> > >> >>        void applyChanges(DataObject graphRoot);
> >> >> >> >> >> >>> > >> >>    }
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >> So, depending on the config file used to
> >> >> >> instantiate the
> >> >> >> >> >> >>> service,
> >> >> >> >> >> >>> > >> >> this interface could be used to return
> >> Customers/
> >> >> >> >> >> Accounts or
> >> >> >> >> >> >>> > >> >> Toasters.  In fact, a lot could be achieved
> with
> >> no
> >> >> >> >> >> >>> > configuration  at
> >> >> >> >> >> >>> > >> >> all by restricting use to:  DataObject
> >> >> >> executeSQL(String
> >> >> >> >> >> >>> > >> abitrarySQL);
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >> I expand a bit here:
> >> >> http://mail-archives.apache.org/
> >> >> >> >> >> >>> mod_mbox/ws-
> >> >> >> >> >> >>> > >> >>
> >> >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >> Once this was working it should be
> >> >> straightforward to
> >> >> >> >> >> build
> >> >> >> >> >> >>> more
> >> >> >> >> >> >>> > >> >> strongly typed services and possible put
> >> together
> >> >> some
> >> >> >> >> >> >>> generation
> >> >> >> >> >> >>> > >> >> tooling.  We could also start looking at
> support
> >> >> for
> >> >> a
> >> >> >> >> >> more
> >> >> >> >> >> >>> > RESTFul
> >> >> >> >> >> >>> > >> >> interface.
> >> >> >> >> >> >>> > >> >> --
> >> >> >> >> >> >>> > >> >> Kevin
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >> Luciano Resende wrote:
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>> Recently, people have been starting to talk
> >> about
> >> >> >> >> >> better DAS
> >> >> >> >> >> >>> > >> >>> integration
> >> >> >> >> >> >>> > >> >>> with DAS, and below are some threads on the
> >> >> subject
> >> >> :
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> >> msg08833.html
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> >
> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> >> msg08923.html
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >>
> >> >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >> >> >> >> >> >>> msg09715.html
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me
> make
> >> >> sure
> >> >> >> >> >> what  I'm
> >> >> >> >> >> >>> > >> >>> saying is not
> >> >> >> >> >> >>> > >> >>> yet available on SCA today.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Today, defining a service to work with a
> >> >> relational
> >> >> >> >> >> >>> database, you
> >> >> >> >> >> >>> > >> >>> will need
> >> >> >> >> >> >>> > >> >>> to code the persistence side of the service
> >> where
> >> >> >> CRUD
> >> >> >> >> >> >>> operations
> >> >> >> >> >> >>> > >> >>> to the
> >> >> >> >> >> >>> > >> >>> database will be done.
> >> >> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
> >> >> coding
> >> >> >> >> >> the
> >> >> >> >> >> >>> CRUD
> >> >> >> >> >> >>> > >> >>> operations on
> >> >> >> >> >> >>> > >> >>> the persistence layer would be avoided as
> >> much as
> >> >> >> >> >> possible.
> >> >> >> >> >> >>> > >> >>> The idea would be to have a more "declarative
> >> DAS"
> >> >> >> when
> >> >> >> >> >> >>> defining
> >> >> >> >> >> >>> > SCA
> >> >> >> >> >> >>> > >> >>> Services, so you would either use some
> >> Annotations
> >> >> >> >> >> or  SCDL
> >> >> >> >> >> to
> >> >> >> >> >> >>> > >> have  the
> >> >> >> >> >> >>> > >> >>> "declarative DAS"  configuration inside it.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> I was thinking on something like....
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> SCDL Definition would look something like
> >> this :
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> <component name="AccountDataService">
> >> >> >> >> >> >>> > >> >>>   <interface.java
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> class="bigbank.account.services.account.AccountService"/>
> >> >> >> >> >> >>> > >> >>>   <implementation.das="dasConfig.properties"
> >> >> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >> >> >> >> >> >>> > >> >>> </component>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> The AccountService Interface would look like
> >> this
> >> >> >> >> >> (missing
> >> >> >> >> >> >>> any
> >> >> >> >> >> >>> > SCA
> >> >> >> >> >> >>> > >> >>> annotations):
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>    public List getAllCustomers();
> >> >> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
> >> >> >> >> >> accountNumber);
> >> >> >> >> >> >>> > >> >>> }
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> The DAS config would look like this, and would
> >> >> >> have the
> >> >> >> >> >> >>> > definition
> >> >> >> >> >> >>> > >> >>> for the
> >> >> >> >> >> >>> > >> >>> "all companies" command.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> <Config ...>
> >> >> >> >> >> >>> > >> >>>    ...
> >> >> >> >> >> >>> > >> >>>   <ConnectionInfo
> >> dataSource="java:comp/env/jdbc/
> >> >> >> >> >> bigbank"/>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>   <Command name="getAllCustomers" SQL="select
> *
> >> >> from
> >> >> >> >> >> >>> CUSTOMERS"
> >> >> >> >> >> >>> > >> >>> kind="Select"/>
> >> >> >> >> >> >>> > >> >>>   <Command name="getCustomerAccount"
> >> SQL="SELECT
> >> >> >> >> >> >>> accountNumber,
> >> >> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
> >> >> >> >> >> accountNumber = ?"
> >> >> >> >> >> >>> > >> >>> kind="Select" />
> >> >> >> >> >> >>> > >> >>>   ...
> >> >> >> >> >> >>> > >> >>> </Config>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Mapping between interface methods and DAS
> >> Commands
> >> >> >> >> >> >>> > >> >>>   - If a DAS config file is provided, based on
> >> the
> >> >> >> >> >> >>> > SCDL  definition,
> >> >> >> >> >> >>> > >> we
> >> >> >> >> >> >>> > >> >>> would look for "DAS command" based on the
> >> name of
> >> >> the
> >> >> >> >> >> getter
> >> >> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to
> >> getAllCustomers
> >> >> >> >> >> command)
> >> >> >> >> >> >>> > >> >>>   - Otherwise, we would try to do a map
> >> >> directly to
> >> >> a
> >> >> >> >> >> >>> > >> stored  procedure
> >> >> >> >> >> >>> > >> >>>   - We could also have a way to force the
> >> >> mapping by
> >> >> >> >> >> using
> >> >> >> >> >> >>> > >> annotation
> >> >> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Mapping between method parameter and command
> >> >> >> parameter
> >> >> >> >> >> >>> > >> >>>   - We would need to define a method for
> >> >> mapping the
> >> >> >> >> >> method
> >> >> >> >> >> >>> > >> >>> parameters to
> >> >> >> >> >> >>> > >> >>> the query paramters either based on position (
> >> >> >> e.gfirst
> >> >> >> >> >> >>> method
> >> >> >> >> >> >>> > >> >>> parameter
> >> >> >> >> >> >>> > >> >>> maps to the first command paramter), or we
> >> >> would do
> >> >> >> some
> >> >> >> >> >> >>> > mapping  by
> >> >> >> >> >> >>> > >> >>> name
> >> >> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Note:
> >> >> >> >> >> >>> > >> >>>   - A SCDL connection information would
> >> >> override the
> >> >> >> DAS
> >> >> >> >> >> >>> Config
> >> >> >> >> >> >>> > file
> >> >> >> >> >> >>> > >> >>> connection information.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Benefits
> >> >> >> >> >> >>> > >> >>>   - It's All about simplicity and easy of use
> >> >> >> >> >> >>> > >> >>>   - This would allow a user to define a
> service
> >> >> >> without
> >> >> >> >> >> >>> having to
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> > >> >>> explicitly having to code any Data Access
> >> related
> >> >> >> code.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Implementation approaches
> >> >> >> >> >> >>> > >> >>>   - Utilizing DAS : This approach would start
> >> from
> >> >> >> the
> >> >> >> >> >> >>> current
> >> >> >> >> >> >>> > >> >>> Tuscany DAS
> >> >> >> >> >> >>> > >> >>> implementation, where functionality would be
> >> >> already
> >> >> >> >> >> >>> > available,  but
> >> >> >> >> >> >>> > >> >>> the
> >> >> >> >> >> >>> > >> >>> service implementation would be tied to SDO
> and
> >> >> RDB
> >> >> >> >> >> as this
> >> >> >> >> >> >>> > is  what
> >> >> >> >> >> >>> > >> >>> DAS
> >> >> >> >> >> >>> > >> >>> supports today.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>   - Start simple and grow : We could start
> >> simple,
> >> >> by
> >> >> >> >> >> >>> having a
> >> >> >> >> >> >>> > >> simple
> >> >> >> >> >> >>> > >> >>> implementation based on JDBC and would return
> >> some
> >> >> >> >> >> simple
> >> >> >> >> >> >>> > >> >>> collection as a
> >> >> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset),
> >> this
> >> >> >> could
> >> >> >> >> >> >>> give us
> >> >> >> >> >> >>> > a
> >> >> >> >> >> >>> > >> >>> quick
> >> >> >> >> >> >>> > >> >>> start to flush implementation details and get
> a
> >> >> >> proven
> >> >> >> >> >> >>> design,
> >> >> >> >> >> >>> > and
> >> >> >> >> >> >>> > >> >>> this
> >> >> >> >> >> >>> > >> >>> could get evolved to use a DAS that would
> >> support
> >> >> >> >> >> multiple
> >> >> >> >> >> >>> > backends
> >> >> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as
> well
> >> as
> >> >> >> >> >> non- SDO
> >> >> >> >> >> >>> types
> >> >> >> >> >> >>> > >> as a
> >> >> >> >> >> >>> > >> >>> command
> >> >> >> >> >> >>> > >> >>> result.
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> Toughts ?
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> - Luciano
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <kevincbw@qwest.net
> >
> >> >> >> wrote:
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> Great.  I would like to help with this.  I
> >> have
> >> >> been
> >> >> >> >> >> >>> thinking
> >> >> >> >> >> >>> > for
> >> >> >> >> >> >>> > >> >>>> awhile
> >> >> >> >> >> >>> > >> >>>> about how to best integrate the RDB DAS
> within
> >> >> SCA.
> >> >> >> >> >> For
> >> >> >> >> >> >>> > >> example,  the
> >> >> >> >> >> >>> > >> >>>> current BBank scenario uses the RDB DAS as a
> >> >> utility
> >> >> >> >> >> but it
> >> >> >> >> >> >>> > >> would be
> >> >> >> >> >> >>> > >> >>>> nice if it could "wire in" a RDB DAS service
> >> >> or be
> >> >> >> >> >> >>> injected with
> >> >> >> >> >> >>> > a
> >> >> >> >> >> >>> > >> >>>> configured DAS.  Another thing we want to
> >> >> eventually
> >> >> >> >> >> >>> explore is
> >> >> >> >> >> >>> > >> >>>> exposing
> >> >> >> >> >> >>> > >> >>>> a DAS as REST-oriented services.  As we have
> >> seen
> >> >> >> >> >> from the
> >> >> >> >> >> >>> > parent
> >> >> >> >> >> >>> > >> >>>> thread
> >> >> >> >> >> >>> > >> >>>> there are almost too many possible
> approaches.
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a
> >> service
> >> >> >> and
> >> >> >> >> >> >>> create a
> >> >> >> >> >> >>> > new
> >> >> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas
> >> ).  The
> >> >> >> main
> >> >> >> >> >> >>> reason
> >> >> >> >> >> >>> > has
> >> >> >> >> >> >>> > >> >>>> to do
> >> >> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS
> >> that
> >> >> >> >> >> >>> > Jeremy  mentioned
> >> >> >> >> >> >>> > >> >>>> which
> >> >> >> >> >> >>> > >> >>>> is all about creating data access services
> >> >> >> >> >> >>> declaratively.  A new
> >> >> >> >> >> >>> > >> >>>> component type and a service that we build by
> >> >> hand
> >> >> >> >> >> would be
> >> >> >> >> >> >>> > a  good
> >> >> >> >> >> >>> > >> >>>> step
> >> >> >> >> >> >>> > >> >>>> in this direction.
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
> >> >> >> >> >> interface  like
> >> >> >> >> >> >>> > this:
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>>     public interface RDBDASService
> >> >> >> >> >> >>> > >> >>>>         void applyChanges(DataObject
> >> graphRoot);
> >> >> >> >> >> >>> > >> >>>>         DataObject execute(String
> >> commandName);
> >> >> >> >> >> >>> > >> >>>>         DataObject executeSQL(String
> >> >> abitrarySQL);
> >> >> >> >> >> >>> > >> >>>>     }
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> The service would be initialized with an
> >> optional
> >> >> >> >> >> RDB DAS
> >> >> >> >> >> >>> > >> config  file
> >> >> >> >> >> >>> > >> >>>> that defines connection properties, a set of
> >> >> >> commands,
> >> >> >> >> >> >>> etc.  So,
> >> >> >> >> >> >>> > >> >>>> different services implementing the same
> >> >> interface
> >> >> >> >> >> could be
> >> >> >> >> >> >>> > >> >>>> initialized
> >> >> >> >> >> >>> > >> >>>> from separate config files.
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> Eventually, we might want to build services
> >> like
> >> >> >> this:
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>>     public interface Customers_RDBDASService
> >> >> >> >> >> >>> > >> >>>>         void applyChanges(DataObject
> >> graphRoot);
> >> >> >> >> >> >>> > >> >>>>         DataObject
> getAllCustomersWithLastName
> >> >> >> (String
> >> >> >> >> >> >>> > lastName);
> >> >> >> >> >> >>> > >> >>>>         DataObject getAll
> >> CustomersAndOrdersForID
> >> >> >> (int
> >> >> >> >> >> >>> > customerId);
> >> >> >> >> >> >>> > >> >>>>     }
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> But, for this to be very useful would
> probably
> >> >> >> require
> >> >> >> >> >> >>> some code
> >> >> >> >> >> >>> > >> >>>> generation tooling.
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> Thoughts?
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> --Kevin
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> Luciano Resende wrote:
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have
> a
> >> >> >> >> >> declarative
> >> >> >> >> >> >>> > DAS  and
> >> >> >> >> >> >>> > >> >>>> will be
> >> >> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki
> >> >> soon...
> >> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >> >>> > >> >>>> > - Luciano
> >> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes
> >> <jb...@apache.org>
> >> >> >> >> >> wrote:
> >> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >> On Oct 3, 2006, at 5:26 PM, Jim Marino
> >> wrote:
> >> >> >> >> >> >>> > >> >>>> >> >> This sounds like having cake, eating
> it,
> >> >> and
> >> >> >> also
> >> >> >> >> >> >>> > being  able
> >> >> >> >> >> >>> > >> to
> >> >> >> >> >> >>> > >> >>>> >> >> give it to a friend :-) We provide the
> >> >> >> >> >> flexibility  for
> >> >> >> >> >> >>> > users:
> >> >> >> >> >> >>> > >> >>>> >> >> 1) to access infrastructure services
> >> >> through
> >> >> >> >> >> >>> properties
> >> >> >> >> >> >>> > >> >>>> >> > Yes for things like JPA, JDBC, etc.
> >> >> >> >> >> >>> > >> >>>> >> >> 2) to reference infrastructure services
> >> >> >> through
> >> >> >> >> >> >>> > inclusion  in
> >> >> >> >> >> >>> > >> >>>> their
> >> >> >> >> >> >>> > >> >>>> >> >> assembly
> >> >> >> >> >> >>> > >> >>>> >> > If we do 1 I don't think we should do 2
> >> >> (that
> >> >> >> >> >> >>> doesn't stop
> >> >> >> >> >> >>> > >> >>>> someone
> >> >> >> >> >> >>> > >> >>>> >> > from extending Tuscany to do it though).
> >> See
> >> >> my
> >> >> >> >> >> >>> comments
> >> >> >> >> >> >>> > >> below.
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >> >> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I
> >> >> think we
> >> >> >> >> >> >>> > should  welcome
> >> >> >> >> >> >>> > >> it
> >> >> >> >> >> >>> > >> >>>> >> like we would any other contribution.
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >> >> 3) to access data through an
> application
> >> >> >> >> >> service with
> >> >> >> >> >> >>> > >> >>>> declarative
> >> >> >> >> >> >>> > >> >>>> >> >> implementation by DAS
> >> >> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks
> >> >> radar.
> >> >> >> >> >> >>> > >> >>>> >> --
> >> >> >> >> >> >>> > >> >>>> >> Jeremy
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> --------------------------------------------------------------------
> >> >> >> >> >> >>> > >> -
> >> >> >> >> >> >>> > >> >>>> >> 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
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >> >>> > >> >>>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> > >> >>
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >>> > >> >> 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
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >> >
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>> > >>
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >>> > >> 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
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>> >
> >> >> >> >> >> >>>
> >> >> >> >> >> >>>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> >>> 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
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >> >> 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
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> 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
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: Declarative DAS, was Re: Modeling the RDB DAS in SCA

[Kevin Williams <ke...@qwest.net>]

Hi Amita,
This sounds good.  Thanks for getting up so early!
--
Kevin


Amita Vadhavkar wrote:

> Hello Kevin , Luciano,
> Thanks a lot for all your suggestions and looking forward to have a 
> IRC chat
> with you.
> I am proposing 9th Nov 5.30 a.m. IST (8th Nov 4.00 p.m. PST) for 
> approx. 1
> hr.
> Please join the chat and we all can discuss -
> 1) what we are trying to provide - service, container
> 2) what all features can be provided
> 3) any high level design suggestions ( sim. to Kevin's latest reply )
> 4) any other suggestions
> 5) we can try to come up with a list of work items
> This will be very helpful in getting a clear picture of what all can 
> be done
>
> in SCA (as well as DAS) domain for our current work.
>
> Regards,
> Amita
>
> On 11/8/06, Kevin Williams <ke...@qwest.net> wrote:
>
>>
>> Hello Amita,
>>
>> This looks promising.  I notice your test case uses explicit updates and
>> inserts.  While this is supported by the DAS it is not the preferred
>> usage which is to allow the RDB DAS to generate the CUD statements from
>> the SDO change history.  Could you modify the example to read a data
>> graph and then post the changes back via "applyChanges"?  Maybe the
>> equivalent of this simple test from the DAS test suite:
>>
>>    public void testReadModifyApply4() throws Exception {
>>
>>        DAS das = DAS.FACTORY.createDAS(getConfig("CustomerConfig.xml"),
>> getConnection());
>>        // Read customer with particular ID
>>        Command select = das.getCommand("getCustomer");
>>        select.setParameter(1, 1);
>>        DataObject root = select.executeQuery();
>>
>>        DataObject customer = (DataObject) root.get("CUSTOMER[1]");
>>
>>        // Modify customer
>>        customer.set("LASTNAME", "Pavick");
>>
>>        das.applyChanges(root);
>>
>>        // Verify the change
>>        root = select.executeQuery();
>>        assertEquals("Pavick",
>> root.getDataObject("CUSTOMER[1]").getString("LASTNAME"));
>>
>>    }
>>
>> Also, this service interface seems difficult to work with since command
>> identifiers and argument values are encoded in the params Vector
>>
>>    public interface CustomersOrdersService {
>>
>>        void execute(Vector params);
>>        DataObject executeQuery(Vector params);
>>        void applyChanges(Vector params);
>>        DataObject executeAdhoc(Vector params);//adhoc query 
>> implementation
>>
>>        DataObject getAllCustomers(Vector paramsList);
>>
>>    }
>>
>> Do you think it possible to implement something like the following
>> interface:
>>
>>    public interface DynamicRDBDASService {
>>
>>        DataObject execute(String commandName, List params);
>>        DataObject executeAdHoc(String queryString, List params);
>>        void applyChanges();
>>    }
>>
>> The name is kind of long (suggestions welcome) but, I think this
>> interface could be generic and set of available commands is driven by
>> the provided DAS config file.  I am not sure how we might support SP OUT
>> parameters but we can think about that later.
>>
>> I does seem like you and Luciano should team up on this.
>>
>> Thanks!
>> -- 
>> Kevin
>>
>>
>>
>>
>> Amita Vadhavkar wrote:
>>
>> > Hi Kevin,
>> > Thanks a lot for the comments. I have posted the code and doc on
>> JIRA-904
>> > for the container work. Also, am most likely missing something in the
>> > database
>> > connection portion. Would like to discuss with you.
>> >
>> > Will you please provide feedback on JIRA-904 attachments?
>> >
>> > I am checking with Luciano for a convenient date/time when we can 
>> chat,
>> > would
>> > be great if you can also join. I am in IST timezone.
>> >
>> > Regards,
>> > Amita
>> >
>> > On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
>> >
>> >>
>> >> Hi Amita,
>> >> This is looking good.  Some comments inline:
>> >>
>> >> Amita Vadhavkar wrote:
>> >>
>> >> > Hi,
>> >> > I am trying to create a container for DAS-SCA too (not just for
>> stored
>> >> > procedure) and will be able to send a working code in ML over the
>> >> > weekend.
>> >> >
>> >> > Below is summary of what I got so far from the previous mail
>> >> > discussions and
>> >> > some questions.
>> >> >
>> >> >
>> >> > The integration between DAS and SCA can happen at application level
>> as
>> >> > service or at container level.
>> >> >
>> >> >
>> >> >
>> >> > 2 different possible approaches –
>> >> >
>> >> > static – e.g. getAllCustomers
>> >> >
>> >> > dynamic – e.g. execute("all customers");
>> >> >
>> >> >
>> >> >
>> >> > For application level service – it is the sample *
>> >> > sample-StoredProcedureService.jar*  or what Luciano is providing in
>> >> more
>> >> > details, is an example.  In *sample-StoredProcedureService.jar*
>> >> example
>> >> > dynamic approach is followed
>> >> >
>> >> >
>> >> >
>> >> > For container approach – again static or dynamic approach can be
>> >> > followed.
>> >> > For static – it's like providing service for getAllCompanies(),
>> >> > getAllCustomers() etc. whereas for dynamic its like 
>> execute(command)
>> >> > where
>> >> > command can be "getAllCompanies", "getAllCustomers". Etc.
>> >> >
>> >> >
>> >> >
>> >> >            I am working on a container implementation where dynamic
>> >> > approach is followed.
>> >> >
>> >> If I understand correctly, the container approach will provide the
>> >> tightest integration with SCA and make things easier for 
>> end-users.  Do
>> >> you agree?
>> >>
>> >> >
>> >> >
>> >> > There are 2 places where extensibility is required –
>> >> >
>> >> > 1)      for providing different data access mechanisms. i.e. today
>> >> > there is
>> >> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
>> >> > scdl will
>> >> > be same, but the exampleconfig.xml will change.
>> >> >
>> >> > In the container I am working on - Scdl has a new tag
>> >> >
>> >> > Scdl has a new tag
>> >> >  <da:implementation.da script="customersOrders/CustomersOrders.xml"
>> >> > dataAccessType="rdb"/>
>> >> >
>> >> >
>> >> >
>> >> > Here, dataAccessType – is the key which tells whether it's RDB or
>> >> > something
>> >> > else. And the xml script provides the connection and data store
>> >> details.
>> >> >
>> >> >
>> >> >
>> >> > 2)      for RDB-DAS – providing support for different databases 
>> (this
>> >> > portion should be part of DAS and  not SCA.) In the current 
>> container
>> >> > I am
>> >> > working on it is provided as a package -
>> >> > org.apache.tuscany.container.dataaccessshelper package  - which
>> should
>> >> > finally go into DAS codeline(?).
>> >> >
>> >> >
>> >> Currently, there are two ways to specify a particular database:  
>> first,
>> >> the user can pass a JDBC Connection to the DAS Factory when 
>> creating a
>> >> DAS instance.  The second is that a DataSource can be specified in 
>> the
>> >> DAS Config xml file in which case the DAS is responsible for getting
>> the
>> >> connection.
>> >>
>> >> >
>> >> >
>> >> >
>> >> > For static approach we may need some code generation tooling.
>> >>
>> >> Right.  That is why I think it best to start with dynamic.  But, we
>> will
>> >> want static support as well.
>> >>
>> >> > Also could not
>> >> > understand how this can be merged into RESTful interfaces. (this 
>> was
>> >> > mentioned in some mail conversation)
>> >> >
>> >> >
>> >> >
>> >> > Regards,
>> >> >
>> >> > Amita
>> >> >
>> >> >
>> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >
>> >> >>
>> >> >> Luciano Resende wrote:
>> >> >>
>> >> >> > Comments in-line...
>> >> >> >
>> >> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
>> >> >> >>
>> >> >> >> > Hi,
>> >> >> >> >
>> >> >> >> > I would also like to understand this a little better ... here
>> >> I am
>> >> >> >> > thinking
>> >> >> >> > aloud and hope the others will help in getting my 
>> persceptions
>> >> >> >> > right...
>> >> >> >> >
>> >> >> >> > I guess firstly it is a question of how or where we want to
>> >> >> >> > position 'DAS
>> >> >> >> > Integration' in SCA.  Is is something we want to integrate as
>> >> the
>> >> >> >> > Application Layer, which I understand is what Amita is trying
>> >> >> >> > presently and
>> >> >> >> > which Jim refers to as component implementation.   In this
>> >> option
>> >> >> >> > we get to
>> >> >> >> > do some sort of a service wrapper to DAS and then it 
>> becomes a
>> >> >> >> > demonstration
>> >> >> >> > of two Tuscany subprojects integrating at application level.
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Yes, I think we have space to position DAS both ways, and
>> >> integrating
>> >> >> > in the
>> >> >> > application layer by exposing DAS as a service would be a very
>> easy
>> >> >> and
>> >> >> > quick, this could be exposed as a sample app, and could show we
>> are
>> >> >> > working
>> >> >> > on getting a better integration between DAS and SCA
>> >> >> >
>> >> >> >
>> >> >> >> Or do we want to position DAS at the infrastructure layer as
>> >> another
>> >> >> >> > extension type (either container or binding).  I guess 
>> this is
>> >> >> >> > where Ant
>> >> >> >> > started this - proposing a JDBC container / binding for
>> >> component
>> >> >> >> > implementation in StoredProcedures.
>> >> >> >> I was thinking a DAS was a way to declaratively model
>> >> heterogeneous
>> >> >> >> data as a service and offer a mechanism for remoting that data.
>> In
>> >> >> >> other words, it provided the ability for an application to
>> perform
>> >> >> >> CRUD using a high-level contract (interface) and having those
>> >> >> >> operations take place across a service network.  How this is
>> >> hooked
>> >> >> >> into the SCA container is probably best done as an extension
>> type,
>> >> >> >> i.e. someone could specify:
>> >> >> >>
>> >> >> >> <component name="Foo">
>> >> >> >>         <implementation.das>
>> >> >> >>                 <interface.java ....>
>> >> >> >>         </implementation.das>
>> >> >> >> </component>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Yes, this goes back to the way I was thinking on my original
>> >> proposal.
>> >> >> >
>> >> >> >
>> >> >> >> If this is the path we should take
>> >> >> >> > then we probably have to think beyond DAS - to something more
>> >> >> >> > general - of
>> >> >> >> > which DAS is just a special case.  I suppose this is what Jim
>> >> has
>> >> >> also
>> >> >> >> > suggested in trying to explore other persistence mechanisms.
>> >> >> >> >
>> >> >> >> This may be the crux of the confusion. I was thinking DAS
>> >> provides a
>> >> >> >> general mechanism for accessing heterogeneous data and is only
>> >> right
>> >> >> >> now tied to SQL because of resource constraints (i.e. we 
>> have to
>> >> >> >> start somewhere). Ultimately, DAS should provide the
>> >> infrastructure
>> >> >> >> for dealing with multiple, varied data stores and mechanisms 
>> for
>> >> >> >> querying across them. In other words, I guess I am saying DAS
>> >> should
>> >> >> >> be the general solution (declarative and heterogeneous) since
>> >> if it
>> >> >> >> is only a programmatic way to access relational data then its
>> >> value
>> >> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > Yes, the current status of DAS implementation is RDB only. I 
>> would
>> >> say
>> >> >> > that,
>> >> >> > in the future, I'd like to see a heterogeneous DAS that would 
>> give
>> >> you
>> >> >> > access to different data stores, and probably support non-SDO
>> types
>> >> as
>> >> >> > well.
>> >> >> >
>> >> >> >> I too feel that this is something that must be done as an
>> >> extension
>> >> >> >> > type -
>> >> >> >> > but yet to get my hands on the general scheme of things that
>> DAS
>> >> >> >> > can slip
>> >> >> >> > into. Infact the other thread where Jeremy has taken 
>> forward a
>> >> >> >> > proposal to
>> >> >> >> > the specs group on resources tempts me to think that there is
>> >> going
>> >> >> >> > to be
>> >> >> >> > something in that which we can leverage from.
>> >> >> >> >
>> >> >> >> I think resources are orthogonal as they are about a component
>> >> >> >> implementation's contract with its container. Declarative data
>> >> >> >> services on the other hand are about application constructs
>> >> that can
>> >> >> >> be wired to.
>> >> >> >>
>> >> >> >> > I hope to get a better understanding this as we go along in
>> this
>> >> >> >> > thread :)
>> >> >> >> >
>> >> >> >> Me too :-) As soon as I have trouble explaining technologies to
>> >> .NET
>> >> >> >> people and they say "you Unix/Java people are at it again 
>> with a
>> >> >> >> thousand ways to do the same exact thing" it causes me to think
>> >> that
>> >> >> >> maybe we need to clarify our message.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > If we all think it would be useful, I could try to summarize the
>> >> >> > thread on
>> >> >> > the wiki with a more clean proposal incorporating all your
>> >> feedback ,
>> >> >> > what
>> >> >> > you guys think ?
>> >> >>
>> >> >> Yes.  Great idea.
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > Jim
>> >> >> >
>> >> >> >> > Thanks
>> >> >> >> >
>> >> >> >> > - Venkat
>> >> >> >> >
>> >> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >> >>
>> >> >> >> >> Jim Marino wrote:
>> >> >> >> >>
>> >> >> >> >> > When I first read the thread on this, I thought the DAS
>> >> service
>> >> >> >> >> would
>> >> >> >> >> > be a component extension type (e.g. analogous to a
>> >> >> >> >> > implementation.java or implementation.ejb) and not a
>> >> component
>> >> >> >> >> > implementation type, which would allow for dynamic and
>> >> >> eventually
>> >> >> >> >> > declarative configuration styles.
>> >> >> >> >>
>> >> >> >> >> I have not very familiar with the terminology so I am not 
>> sure
>> >> >> what
>> >> >> a
>> >> >> >> >> "component extension type" is.  But, I do think we 
>> eventually
>> >> want
>> >> >> >> >> "implementation.rdbdas".  Wouldn't this be a new
>> implementation
>> >> >> type?
>> >> >> >> >>
>> >> >> >> >> It looks like Amita chose to start with a POJO.  I notice
>> >> the use
>> >> >> >> >> of "
>> >> >> >> >> implementation.java".
>> >> >> >> >>
>> >> >> >> >> > Either way, though, I am curious as  to why
>> >> >> >> >> >
>> >> >> >> >> > public DAS configureService(String configFile);
>> >> >> >> >> >
>> >> >> >> >> > exists as part of the service definition? If the DAS 
>> service
>> >> >> was a
>> >> >> >> >> > component extension type, it could be handled as part 
>> of the
>> >> >> >> >> > application bootstrap. If the DAS service was a component
>> >> >> >> >> > implementation type, the configuration file URI could be
>> >> passed
>> >> >> >> >> in as
>> >> >> >> >> > a property and then processed in an initializer method
>> >> decorated
>> >> >> by
>> >> >> >> >> > the SCA @Init annotation. In the latter case, if the
>> >> >> implementation
>> >> >> >> >> > of DASService thread-safe (hopefully it is since
>> >> configuration
>> >> >> >> >> would
>> >> >> >> >> > seem to be a heavyweight operation), then I would make the
>> >> >> >> >> component
>> >> >> >> >> > module scoped to avoid initialization overhead on every
>> >> >> resolution.
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > In both approaches (extension vs. implementation type),
>> >> having
>> >> >> >> >> > configuration exposed to the application doesn't quite 
>> feel
>> >> >> right,
>> >> >> >> >> > since that is what DI tries to externalize.
>> >> >> >> >>
>> >> >> >> >> I agree.  The configuration should be part of the
>> >> >> initialization and
>> >> >> >> >> should use SCA patterns to do this.  I think that Amita 
>> meant
>> >> >> to use
>> >> >> >> >> eventually use a component property for the DAS config info
>> but
>> >> >> >> >> started
>> >> >> >> >> with a method.
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > Also, I was thinking that in having this a component
>> >> extension
>> >> >> >> >> type,
>> >> >> >> >> > the service interfaces returned from a resolution could
>> >> include
>> >> >> the
>> >> >> >> >> > dynamic one described below or static ones people have
>> >> >> mentioned.
>> >> >> I
>> >> >> >> >> > guess it is best to start with the easier-to-implement 
>> part
>> >> >> >> >> first and
>> >> >> >> >> > support the dynamic interface.
>> >> >> >> >> >
>> >> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be
>> >> nice to
>> >> >> >> >> > understand what DAS provides in relation to other
>> persistence
>> >> >> >> >> > technologies. Outside of the Java world, Microsoft is
>> >> promoting
>> >> >> >> >> LINQ
>> >> >> >> >> > which is really interesting, and it would be 
>> informative to
>> >> >> compare
>> >> >> >> >> > the goals of DAS with that approach (there are obvious
>> >> >> differences
>> >> >> >> >> > such as having the query language a strongly-typed part of
>> >> the
>> >> >> >> >> > programming language, e.g. C#, and LINQ's use of 
>> closures).
>> >> >> >> >> >
>> >> >> >> >> > In contrasting DAS to O-R technologies, I see the primary
>> use
>> >> >> cases
>> >> >> >> >> > for the former being a quick way to issue a query that may
>> be
>> >> >> >> >> > executed against *heterogeneous* data stores and have that
>> >> data
>> >> >> >> >> flow
>> >> >> >> >> > remotely or to a client that is not necessarily
>> >> Java-based. One
>> >> >> key
>> >> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
>> >> >> >> >> (Hibernate
>> >> >> >> >> > and JPA are about as easy):
>> >> >> >> >> >
>> >> >> >> >> IMO the primary use case for DAS is an application that is
>> SDO-
>> >> >> >> >> centric
>> >> >> >> >> and is taking advantage of its disconnected 
>> capabilities.  The
>> >> RDB
>> >> >> >> >> DAS
>> >> >> >> >> is built to work with SDO and uses the change summary to 
>> drive
>> >> >> >> >> changes
>> >> >> >> >> made to a disconnected data graph back to some store.  
>> This is
>> >> not
>> >> >> to
>> >> >> >> >> say that a relational DAS could not be built on top of 
>> JPA, in
>> >> >> fact,
>> >> >> >> >> this might be a very useful thing to do.  The implementation
>> we
>> >> >> >> >> currently have provides a very straightforward implicit
>> mapping
>> >> >> from
>> >> >> >> >> DataObjects to Tables.  If more capable mapping is needed
>> >> then it
>> >> >> >> >> makes
>> >> >> >> >> sense to use the JPA-defined technology and artifacts.  A
>> >> modified
>> >> >> >> >> Entity manager might be needed to take advantage of SDO's
>> >> change
>> >> >> >> >> summary.
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > public interface CustomerDao extends BaseQuery {
>> >> >> >> >> >     @Select("select * from customers where city = ?1")
>> >> >> >> >> >     DataSet<Customer> findCustomersFrom(String city);
>> >> >> >> >> > }
>> >> >> >> >> >
>> >> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
>> >> >> >> >> > (CustomerDao.class, datasource);
>> >> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > The other key is remote data and change lists.  I think
>> there
>> >> >> are
>> >> >> >> >> > (literally) about a thousand ways that already exist to
>> >> >> handle the
>> >> >> >> >> > "local" data case. For change lists, interop with 
>> ADO.NET's
>> >> >> change
>> >> >> >> >> > summary facilities would be interesting.
>> >> >> >> >>
>> >> >> >> >> I agree.  Also, it looks like Xcalia may have a similar
>> >> thought:
>> >> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think
>> >> it is
>> >> >> >> >> > important we have a clear statement as to when it is
>> >> appropriate
>> >> >> >> >> and
>> >> >> >> >> > not appropriate to use. One place to start would be to
>> >> compare
>> >> >> >> >> it to
>> >> >> >> >> > JDBC 4 and JPA.
>> >> >> >> >>
>> >> >> >> >> We can get started with JPA:
>> >> >> >> >>
>> >> >> >> >>     * JPA is java-specific, container-based, built around a
>> >> >> connected
>> >> >> >> >>       data model and offers a complete O/R mapping for POJOs
>> >> >> >> >>
>> >> >> >> >>     * The RDB DAS is a java implementation of a language -
>> >> neutral
>> >> >> >> >>       concept (hopefully specified some day) that is
>> >> >> containerless,
>> >> >> >> >>       assumes a disconnected data model and provides a 
>> simple,
>> >> >> >> >> implicit
>> >> >> >> >>       mapping for SDO DataObjects (Dynamic or Static) to
>> >> >> relational
>> >> >> >> >> tables.
>> >> >> >> >>
>> >> >> >> >> Anything else?
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > Jim
>> >> >> >> >> >
>> >> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
>> >> >> >> >> >
>> >> >> >> >> >> Hi Amita
>> >> >> >> >> >>
>> >> >> >> >> >> I think we were both going on the same way, with the DAS
>> >> >> Service
>> >> >> >> >> >> sample,
>> >> >> >> >> >> altough i had the interface more like this, to be more
>> >> >> flexible :
>> >> >> >> >> >>
>> >> >> >> >> >> public interface DASService {
>> >> >> >> >> >>
>> >> >> >> >> >>    public DAS configureService(String configFile);
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >>    public DataObject executeCommand(String commandName);
>> >> >> >> >> >>    public DataObject execute(String newCommand);
>> >> >> >> >> >>    public void applyChanges(DataObject graphRoot);
>> >> >> >> >> >> }
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> As for having it as a sample, maybe we could defined the
>> >> >> >> >> DASService
>> >> >> >> >> >> as one
>> >> >> >> >> >> sample itself, and have a second version of companyWeb 
>> that
>> >> >> would
>> >> >> >> >> >> consume
>> >> >> >> >> >> the service, something like :
>> >> >> >> >> >>
>> >> >> >> >> >> das\samples\companyWeb
>> >> >> >> >> >> das\samples\dasService
>> >> >> >> >> >> das\samples.companyWeb.service
>> >> >> >> >> >>
>> >> >> >> >> >> or, more like BigBank
>> >> >> >> >> >>
>> >> >> >> >> >> das\samples\companyweb.Service\dasService
>> >> >> >> >> >> das\samples\companyweb.Service\webClient
>> >> >> >> >> >>
>> >> >> >> >> >> Or even in sampleApps...
>> >> >> >> >> >>
>> >> >> >> >> >> Toughts ?
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
>> >> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >>>
>> >> >> >> >> >>> Hi ,
>> >> >> >> >> >>> I am also following up another thread
>> >> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> >> msg09944.html
>> >> >> >> >> >>> on the
>> >> >> >> >> >>> similar issue (JDBC stored procedure container
>> >> >> >> >> >>> using DAS)
>> >> >> >> >> >>> Besides the fact that I am actively working on the
>> >> container
>> >> >> >> >> work,
>> >> >> >> >> >>> I also
>> >> >> >> >> >>> have tried to
>> >> >> >> >> >>> develop a sample based on the below discussion, 
>> following
>> >> >> dynamic
>> >> >> >> >> >>> approach.
>> >> >> >> >> >>>
>> >> >> >> >> >>> I am attaching the same here. Please take a look and 
>> give
>> >> your
>> >> >> >> >> >>> suggestions.
>> >> >> >> >> >>> In this, StoredProcedureService implementation has
>> >> >> >> >> setConfigInfo (DAS
>> >> >> >> >> >>> Config) and
>> >> >> >> >> >>> execute(Any SQL). This can be made more complete with
>> >> >> >> >> executeSQL(),
>> >> >> >> >> >>> applyChanges()
>> >> >> >> >> >>> etc.
>> >> >> >> >> >>>
>> >> >> >> >> >>> Can this be added to the existing set of samples?
>> >> >> >> >> >>>
>> >> >> >> >> >>> Regards,
>> >> >> >> >> >>> Amita
>> >> >> >> >> >>>
>> >> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > Luciano Resende wrote:
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > Kevin, from what I understood from your 
>> suggestion, it
>> >> was
>> >> >> >> >> >>> looking to
>> >> >> >> >> >>> > me
>> >> >> >> >> >>> > > more like exposing DAS as a service :
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > >>>   public interface RDBDASService
>> >> >> >> >> >>> > >>>        DataObject execute(String commandName);
>> >> >> >> >> >>> > >>>        DataObject executeSQL(String abitrarySQL);
>> >> >> >> >> >>> > >>>        void applyChanges(DataObject graphRoot);
>> >> >> >> >> >>> > >>>    }
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > Yes, I am talking about exposing a DAS Service
>> configured
>> >> >> >> >> with a
>> >> >> >> >> >>> > specific set of capabilities/commands defined in 
>> the DAS
>> >> >> config
>> >> >> >> >> >>> file.
>> >> >> >> >> >>> > So, if the implementation of the service interface 
>> above
>> >> was
>> >> >> >> >> >>> configured
>> >> >> >> >> >>> > to work with Customers they would use the service like
>> >> this:
>> >> >> >> >> >>> >
>> >> >> >> >> >>> >    List customers = myRDBDASService.execute
>> >> >> ("getAllCustomers");
>> >> >> >> >> >>> >    String name = customers.get(0).getString("name");
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > This is not much different than the static 
>> interface you
>> >> >> >> >> proposed,
>> >> >> >> >> >>> > right?
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > And then, when a service developer defines the
>> >> >> >> >> AccountService,
>> >> >> >> >> >>> he will
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > have
>> >> >> >> >> >>> > > to know about yet another service, about how DAS
>> works,
>> >> >> >> >> how it is
>> >> >> >> >> >>> > > configured, etc, etc... is that right ?
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > The abilities of the service are defined by the DAS
>> >> config
>> >> >> >> >> file.
>> >> >> >> >> >>> So,
>> >> >> >> >> >>> > the person or tool that provides the config file must
>> >> >> >> >> understand
>> >> >> >> >> >>> how the
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > RDB DAS APIs work.  There is no getting around this.
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > My proposal was going more towards allowing the
>> service
>> >> >> >> >> >>> developer to
>> >> >> >> >> >>> > > focus
>> >> >> >> >> >>> > > on defining the service, and let the "declarative
>> >> das" to
>> >> >> >> >> >>> handle the
>> >> >> >> >> >>> > > persistent layer....
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > The DAS config file is the declaration of an 
>> instance of
>> >> the
>> >> >> >> >> >>> DAS.  That
>> >> >> >> >> >>> > instance can be exposed as a dynamic or typed service/
>> >> >> >> >> interface.
>> >> >> >> >> >>> That
>> >> >> >> >> >>> > seems to be the main discussion we are having.
>> >> Although, I
>> >> >> >> >> may be
>> >> >> >> >> >>> > missing something.
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > > Also, by defining some conventions over 
>> configuration
>> >> >> >> >> and/or  using
>> >> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a
>> >> stored
>> >> >> >> >> >>> procedure),
>> >> >> >> >> >>> > the
>> >> >> >> >> >>> > > service developer could really define a service that
>> >> >> >> >> interacts
>> >> >> >> >> >>> with a
>> >> >> >> >> >>> > > RDB,
>> >> >> >> >> >>> > > without having to code the service persistence 
>> layer.
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > There is a lot of potential for the use of 
>> annotations.
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > > - Luciano
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net>
>> >> wrote:
>> >> >> >> >> >>> > >
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> The real difference between the two approaches is
>> that
>> >> >> >> >> one is
>> >> >> >> >> >>> "Typed"
>> >> >> >> >> >>> > or
>> >> >> >> >> >>> > >> static and the other is dynamic.  I think both are
>> >> needed
>> >> >> >> >> but  was
>> >> >> >> >> >>> > >> suggesting that we start with dynamic since it 
>> is the
>> >> >> most
>> >> >> >> >> >>> flexible
>> >> >> >> >> >>> > and
>> >> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a
>> >> static
>> >> >> >> >> >>> capability.
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> With either, the user does not need to know about
>> >> >> >> >> traditional
>> >> >> >> >> >>> > >> persistence frameworks.  With the dynamic approach,
>> >> >> however,
>> >> >> >> >> >>> the user
>> >> >> >> >> >>> > >> does need to know about the dynamic SDO API.
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> So, with the static interface the user might write:
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>     List customers = accountService.getAllCustomers
>> ();
>> >> >> >> >> >>> > >>     String name =
>> >> ((Customer)customers.get(0)).getName();
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> The equivalent dynamic API might be:
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>     List customers =
>> >> >> dasService.execute("getAllCustomers");
>> >> >> >> >> >>> > >>     String name =
>> >> >> ((DataObject)customers.get(0)).getString
>> >> >> >> >> >>> ("name");
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> The first is probably a little easier for the
>> >> application
>> >> >> >> >> >>> developer
>> >> >> >> >> >>> > but
>> >> >> >> >> >>> > >> the second is much easier for the service 
>> developer.
>> >> IMO,
>> >> >> >> >> the
>> >> >> >> >> >>> dynamic
>> >> >> >> >> >>> > >> case is the best place to start and, again, we
>> >> >> >> >> definitely  will
>> >> >> >> >> >>> want
>> >> >> >> >> >>> > >> support for both.
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> Thanks.
>> >> >> >> >> >>> > >> --
>> >> >> >> >> >>> > >> Kevin
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> Jeremy Boynes wrote:
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >> > I think this would be useful but it seems more
>> >> like a
>> >> >> >> >> >>> traditional
>> >> >> >> >> >>> > >> > persistence API than what Luciano was suggesting.
>> >> With
>> >> >> >> >> this
>> >> >> >> >> >>> one a
>> >> >> >> >> >>> > >> > user needs to know about DataObject's, commands,
>> SQL
>> >> >> >> >> strings
>> >> >> >> >> >>> etc.
>> >> >> >> >> >>> > >> > just like they would if they were using raw 
>> JDBC or
>> >> >> JPA.
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more
>> >> about
>> >> >> >> >> >>> expressing
>> >> >> >> >> >>> > >> > high-level CRUD operations as operations on a
>> >> service
>> >> >> >> >> >>> interface:
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>    public List getAllCustomers();
>> >> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
>> >> >> >> >> accountNumber);
>> >> >> >> >> >>> > >> >>> }
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > which is all application level concepts rather
>> >> >> >> >> than  persistence
>> >> >> >> >> >>> > level
>> >> >> >> >> >>> > >> > concepts. I'd actually go a little further and 
>> put
>> >> that
>> >> >> >> >> >>> right into
>> >> >> >> >> >>> > >> > the service contract:
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >   public interface AccountService {
>> >> >> >> >> >>> > >> >     List<Customer> getAllCustomers();
>> >> >> >> >> >>> > >> >     Account getCustomerAccount(String
>> >> accountNumber);
>> >> >> >> >> >>> > >> >   }
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
>> >> >> >> >> standardized
>> >> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
>> >> >> configuration
>> >> >> >> >> >>> would be
>> >> >> >> >> >>> > >> > needed except to add this to the logical 
>> assembly:
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >   <component name="AccountStore">
>> >> >> >> >> >>> > >> >     <implementation.das 
>> resource="MySQLDatabase"/>
>> >> >> >> >> >>> > >> >   </component>
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > With SCA's ability to translate service 
>> contracts,
>> >> this
>> >> >> >> >> >>> should be
>> >> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
>> >> >> >> >> regardless of
>> >> >> >> >> >>> > whether
>> >> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by 
>> IIOP or
>> >> >> >> >> running  on
>> >> >> >> >> a
>> >> >> >> >> >>> > Java,
>> >> >> >> >> >>> > >> > C++ or PHP platform.
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > The important thing here is that the client is
>> >> >> >> >> isolated  from
>> >> >> >> >> >>> how
>> >> >> >> >> >>> > the
>> >> >> >> >> >>> > >> > DAS component is provided. We could have multiple
>> >> >> >> >> declarative
>> >> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and one
>> >> that
>> >> >> did
>> >> >> >> >> >>> stuff
>> >> >> >> >> >>> > with
>> >> >> >> >> >>> > >> > XML databases like Xindice; alternatively, 
>> /without
>> >> >> >> >> altering
>> >> >> >> >> >>> the
>> >> >> >> >> >>> > >> > client at all/ they could switch to a custom 
>> coded
>> >> >> version
>> >> >> >> >> >>> written
>> >> >> >> >> >>> > in
>> >> >> >> >> >>> > >> > Java, C++ or a store procedure language like
>> PL/SQL.
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > --
>> >> >> >> >> >>> > >> > Jeremy
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams 
>> wrote:
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >> I would suggest that we start right away with a
>> >> >> RDBDAS-
>> >> >> >> >> based
>> >> >> >> >> >>> > >> >> solution.  I also think that the best place to
>> >> start
>> >> >> >> >> would
>> >> >> >> >> >>> be with
>> >> >> >> >> >>> > >> >> an interface that is "weakly" typed.  That is, a
>> >> >> service
>> >> >> >> >> >>> interface
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > >> >> in terms of dynamic SDO's.  If we go this 
>> route we
>> >> can
>> >> >> >> >> >>> avoid the
>> >> >> >> >> >>> > >> >> generation (by hand or otherwise) of code
>> >> specific to
>> >> >> >> >> a new
>> >> >> >> >> >>> > >> >> service.  Instead, the service will be
>> >> "instantiated"
>> >> >> >> >> based
>> >> >> >> >> >>> on the
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > >> >> provided DAS config file.  The service interface
>> >> >> >> >> might  look
>> >> >> >> >> >>> like
>> >> >> >> >> >>> > >> this:
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>    public interface RDBDASService
>> >> >> >> >> >>> > >> >>        DataObject execute(String commandName);
>> >> >> >> >> >>> > >> >>        DataObject executeSQL(String 
>> abitrarySQL);
>> >> >> >> >> >>> > >> >>        void applyChanges(DataObject graphRoot);
>> >> >> >> >> >>> > >> >>    }
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >> So, depending on the config file used to
>> >> >> instantiate the
>> >> >> >> >> >>> service,
>> >> >> >> >> >>> > >> >> this interface could be used to return 
>> Customers/
>> >> >> >> >> Accounts or
>> >> >> >> >> >>> > >> >> Toasters.  In fact, a lot could be achieved with
>> no
>> >> >> >> >> >>> > configuration  at
>> >> >> >> >> >>> > >> >> all by restricting use to:  DataObject
>> >> >> executeSQL(String
>> >> >> >> >> >>> > >> abitrarySQL);
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >> I expand a bit here:
>> >> http://mail-archives.apache.org/
>> >> >> >> >> >>> mod_mbox/ws-
>> >> >> >> >> >>> > >> >>
>> >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >> Once this was working it should be
>> >> straightforward to
>> >> >> >> >> build
>> >> >> >> >> >>> more
>> >> >> >> >> >>> > >> >> strongly typed services and possible put 
>> together
>> >> some
>> >> >> >> >> >>> generation
>> >> >> >> >> >>> > >> >> tooling.  We could also start looking at support
>> >> for
>> >> a
>> >> >> >> >> more
>> >> >> >> >> >>> > RESTFul
>> >> >> >> >> >>> > >> >> interface.
>> >> >> >> >> >>> > >> >> --
>> >> >> >> >> >>> > >> >> Kevin
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >> Luciano Resende wrote:
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>> Recently, people have been starting to talk 
>> about
>> >> >> >> >> better DAS
>> >> >> >> >> >>> > >> >>> integration
>> >> >> >> >> >>> > >> >>> with DAS, and below are some threads on the
>> >> subject
>> >> :
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> >> msg08833.html
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> >> msg08923.html
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >>
>> >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>> >> >> >> >> >>> msg09715.html
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make
>> >> sure
>> >> >> >> >> what  I'm
>> >> >> >> >> >>> > >> >>> saying is not
>> >> >> >> >> >>> > >> >>> yet available on SCA today.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Today, defining a service to work with a
>> >> relational
>> >> >> >> >> >>> database, you
>> >> >> >> >> >>> > >> >>> will need
>> >> >> >> >> >>> > >> >>> to code the persistence side of the service 
>> where
>> >> >> CRUD
>> >> >> >> >> >>> operations
>> >> >> >> >> >>> > >> >>> to the
>> >> >> >> >> >>> > >> >>> database will be done.
>> >> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
>> >> coding
>> >> >> >> >> the
>> >> >> >> >> >>> CRUD
>> >> >> >> >> >>> > >> >>> operations on
>> >> >> >> >> >>> > >> >>> the persistence layer would be avoided as 
>> much as
>> >> >> >> >> possible.
>> >> >> >> >> >>> > >> >>> The idea would be to have a more "declarative
>> DAS"
>> >> >> when
>> >> >> >> >> >>> defining
>> >> >> >> >> >>> > SCA
>> >> >> >> >> >>> > >> >>> Services, so you would either use some
>> Annotations
>> >> >> >> >> or  SCDL
>> >> >> >> >> to
>> >> >> >> >> >>> > >> have  the
>> >> >> >> >> >>> > >> >>> "declarative DAS"  configuration inside it.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> I was thinking on something like....
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> SCDL Definition would look something like 
>> this :
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> <component name="AccountDataService">
>> >> >> >> >> >>> > >> >>>   <interface.java
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> class="bigbank.account.services.account.AccountService"/>
>> >> >> >> >> >>> > >> >>>   <implementation.das="dasConfig.properties"
>> >> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>> >> >> >> >> >>> > >> >>> </component>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> The AccountService Interface would look like 
>> this
>> >> >> >> >> (missing
>> >> >> >> >> >>> any
>> >> >> >> >> >>> > SCA
>> >> >> >> >> >>> > >> >>> annotations):
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>    public List getAllCustomers();
>> >> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
>> >> >> >> >> accountNumber);
>> >> >> >> >> >>> > >> >>> }
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> The DAS config would look like this, and would
>> >> >> have the
>> >> >> >> >> >>> > definition
>> >> >> >> >> >>> > >> >>> for the
>> >> >> >> >> >>> > >> >>> "all companies" command.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> <Config ...>
>> >> >> >> >> >>> > >> >>>    ...
>> >> >> >> >> >>> > >> >>>   <ConnectionInfo 
>> dataSource="java:comp/env/jdbc/
>> >> >> >> >> bigbank"/>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>   <Command name="getAllCustomers" SQL="select *
>> >> from
>> >> >> >> >> >>> CUSTOMERS"
>> >> >> >> >> >>> > >> >>> kind="Select"/>
>> >> >> >> >> >>> > >> >>>   <Command name="getCustomerAccount" 
>> SQL="SELECT
>> >> >> >> >> >>> accountNumber,
>> >> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
>> >> >> >> >> accountNumber = ?"
>> >> >> >> >> >>> > >> >>> kind="Select" />
>> >> >> >> >> >>> > >> >>>   ...
>> >> >> >> >> >>> > >> >>> </Config>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Mapping between interface methods and DAS
>> Commands
>> >> >> >> >> >>> > >> >>>   - If a DAS config file is provided, based on
>> the
>> >> >> >> >> >>> > SCDL  definition,
>> >> >> >> >> >>> > >> we
>> >> >> >> >> >>> > >> >>> would look for "DAS command" based on the 
>> name of
>> >> the
>> >> >> >> >> getter
>> >> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to 
>> getAllCustomers
>> >> >> >> >> command)
>> >> >> >> >> >>> > >> >>>   - Otherwise, we would try to do a map
>> >> directly to
>> >> a
>> >> >> >> >> >>> > >> stored  procedure
>> >> >> >> >> >>> > >> >>>   - We could also have a way to force the
>> >> mapping by
>> >> >> >> >> using
>> >> >> >> >> >>> > >> annotation
>> >> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Mapping between method parameter and command
>> >> >> parameter
>> >> >> >> >> >>> > >> >>>   - We would need to define a method for
>> >> mapping the
>> >> >> >> >> method
>> >> >> >> >> >>> > >> >>> parameters to
>> >> >> >> >> >>> > >> >>> the query paramters either based on position (
>> >> >> e.gfirst
>> >> >> >> >> >>> method
>> >> >> >> >> >>> > >> >>> parameter
>> >> >> >> >> >>> > >> >>> maps to the first command paramter), or we
>> >> would do
>> >> >> some
>> >> >> >> >> >>> > mapping  by
>> >> >> >> >> >>> > >> >>> name
>> >> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Note:
>> >> >> >> >> >>> > >> >>>   - A SCDL connection information would
>> >> override the
>> >> >> DAS
>> >> >> >> >> >>> Config
>> >> >> >> >> >>> > file
>> >> >> >> >> >>> > >> >>> connection information.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Benefits
>> >> >> >> >> >>> > >> >>>   - It's All about simplicity and easy of use
>> >> >> >> >> >>> > >> >>>   - This would allow a user to define a service
>> >> >> without
>> >> >> >> >> >>> having to
>> >> >> >> >> >>> >
>> >> >> >> >> >>> > >> >>> explicitly having to code any Data Access 
>> related
>> >> >> code.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Implementation approaches
>> >> >> >> >> >>> > >> >>>   - Utilizing DAS : This approach would start
>> from
>> >> >> the
>> >> >> >> >> >>> current
>> >> >> >> >> >>> > >> >>> Tuscany DAS
>> >> >> >> >> >>> > >> >>> implementation, where functionality would be
>> >> already
>> >> >> >> >> >>> > available,  but
>> >> >> >> >> >>> > >> >>> the
>> >> >> >> >> >>> > >> >>> service implementation would be tied to SDO and
>> >> RDB
>> >> >> >> >> as this
>> >> >> >> >> >>> > is  what
>> >> >> >> >> >>> > >> >>> DAS
>> >> >> >> >> >>> > >> >>> supports today.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>   - Start simple and grow : We could start
>> simple,
>> >> by
>> >> >> >> >> >>> having a
>> >> >> >> >> >>> > >> simple
>> >> >> >> >> >>> > >> >>> implementation based on JDBC and would return
>> some
>> >> >> >> >> simple
>> >> >> >> >> >>> > >> >>> collection as a
>> >> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset),
>> this
>> >> >> could
>> >> >> >> >> >>> give us
>> >> >> >> >> >>> > a
>> >> >> >> >> >>> > >> >>> quick
>> >> >> >> >> >>> > >> >>> start to flush implementation details and get a
>> >> >> proven
>> >> >> >> >> >>> design,
>> >> >> >> >> >>> > and
>> >> >> >> >> >>> > >> >>> this
>> >> >> >> >> >>> > >> >>> could get evolved to use a DAS that would 
>> support
>> >> >> >> >> multiple
>> >> >> >> >> >>> > backends
>> >> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well
>> as
>> >> >> >> >> non- SDO
>> >> >> >> >> >>> types
>> >> >> >> >> >>> > >> as a
>> >> >> >> >> >>> > >> >>> command
>> >> >> >> >> >>> > >> >>> result.
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> Toughts ?
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> - Luciano
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net>
>> >> >> wrote:
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> Great.  I would like to help with this.  I 
>> have
>> >> been
>> >> >> >> >> >>> thinking
>> >> >> >> >> >>> > for
>> >> >> >> >> >>> > >> >>>> awhile
>> >> >> >> >> >>> > >> >>>> about how to best integrate the RDB DAS within
>> >> SCA.
>> >> >> >> >> For
>> >> >> >> >> >>> > >> example,  the
>> >> >> >> >> >>> > >> >>>> current BBank scenario uses the RDB DAS as a
>> >> utility
>> >> >> >> >> but it
>> >> >> >> >> >>> > >> would be
>> >> >> >> >> >>> > >> >>>> nice if it could "wire in" a RDB DAS service
>> >> or be
>> >> >> >> >> >>> injected with
>> >> >> >> >> >>> > a
>> >> >> >> >> >>> > >> >>>> configured DAS.  Another thing we want to
>> >> eventually
>> >> >> >> >> >>> explore is
>> >> >> >> >> >>> > >> >>>> exposing
>> >> >> >> >> >>> > >> >>>> a DAS as REST-oriented services.  As we have
>> seen
>> >> >> >> >> from the
>> >> >> >> >> >>> > parent
>> >> >> >> >> >>> > >> >>>> thread
>> >> >> >> >> >>> > >> >>>> there are almost too many possible approaches.
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a
>> service
>> >> >> and
>> >> >> >> >> >>> create a
>> >> >> >> >> >>> > new
>> >> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas
>> ).  The
>> >> >> main
>> >> >> >> >> >>> reason
>> >> >> >> >> >>> > has
>> >> >> >> >> >>> > >> >>>> to do
>> >> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS
>> that
>> >> >> >> >> >>> > Jeremy  mentioned
>> >> >> >> >> >>> > >> >>>> which
>> >> >> >> >> >>> > >> >>>> is all about creating data access services
>> >> >> >> >> >>> declaratively.  A new
>> >> >> >> >> >>> > >> >>>> component type and a service that we build by
>> >> hand
>> >> >> >> >> would be
>> >> >> >> >> >>> > a  good
>> >> >> >> >> >>> > >> >>>> step
>> >> >> >> >> >>> > >> >>>> in this direction.
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
>> >> >> >> >> interface  like
>> >> >> >> >> >>> > this:
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>>     public interface RDBDASService
>> >> >> >> >> >>> > >> >>>>         void applyChanges(DataObject 
>> graphRoot);
>> >> >> >> >> >>> > >> >>>>         DataObject execute(String 
>> commandName);
>> >> >> >> >> >>> > >> >>>>         DataObject executeSQL(String
>> >> abitrarySQL);
>> >> >> >> >> >>> > >> >>>>     }
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> The service would be initialized with an
>> optional
>> >> >> >> >> RDB DAS
>> >> >> >> >> >>> > >> config  file
>> >> >> >> >> >>> > >> >>>> that defines connection properties, a set of
>> >> >> commands,
>> >> >> >> >> >>> etc.  So,
>> >> >> >> >> >>> > >> >>>> different services implementing the same
>> >> interface
>> >> >> >> >> could be
>> >> >> >> >> >>> > >> >>>> initialized
>> >> >> >> >> >>> > >> >>>> from separate config files.
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> Eventually, we might want to build services 
>> like
>> >> >> this:
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>>     public interface Customers_RDBDASService
>> >> >> >> >> >>> > >> >>>>         void applyChanges(DataObject 
>> graphRoot);
>> >> >> >> >> >>> > >> >>>>         DataObject getAllCustomersWithLastName
>> >> >> (String
>> >> >> >> >> >>> > lastName);
>> >> >> >> >> >>> > >> >>>>         DataObject getAll
>> CustomersAndOrdersForID
>> >> >> (int
>> >> >> >> >> >>> > customerId);
>> >> >> >> >> >>> > >> >>>>     }
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> But, for this to be very useful would probably
>> >> >> require
>> >> >> >> >> >>> some code
>> >> >> >> >> >>> > >> >>>> generation tooling.
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> Thoughts?
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> --Kevin
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> Luciano Resende wrote:
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
>> >> >> >> >> declarative
>> >> >> >> >> >>> > DAS  and
>> >> >> >> >> >>> > >> >>>> will be
>> >> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki
>> >> soon...
>> >> >> >> >> >>> > >> >>>> >
>> >> >> >> >> >>> > >> >>>> > - Luciano
>> >> >> >> >> >>> > >> >>>> >
>> >> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes 
>> <jb...@apache.org>
>> >> >> >> >> wrote:
>> >> >> >> >> >>> > >> >>>> >
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >> On Oct 3, 2006, at 5:26 PM, Jim Marino 
>> wrote:
>> >> >> >> >> >>> > >> >>>> >> >> This sounds like having cake, eating it,
>> >> and
>> >> >> also
>> >> >> >> >> >>> > being  able
>> >> >> >> >> >>> > >> to
>> >> >> >> >> >>> > >> >>>> >> >> give it to a friend :-) We provide the
>> >> >> >> >> flexibility  for
>> >> >> >> >> >>> > users:
>> >> >> >> >> >>> > >> >>>> >> >> 1) to access infrastructure services
>> >> through
>> >> >> >> >> >>> properties
>> >> >> >> >> >>> > >> >>>> >> > Yes for things like JPA, JDBC, etc.
>> >> >> >> >> >>> > >> >>>> >> >> 2) to reference infrastructure services
>> >> >> through
>> >> >> >> >> >>> > inclusion  in
>> >> >> >> >> >>> > >> >>>> their
>> >> >> >> >> >>> > >> >>>> >> >> assembly
>> >> >> >> >> >>> > >> >>>> >> > If we do 1 I don't think we should do 2
>> >> (that
>> >> >> >> >> >>> doesn't stop
>> >> >> >> >> >>> > >> >>>> someone
>> >> >> >> >> >>> > >> >>>> >> > from extending Tuscany to do it though).
>> See
>> >> my
>> >> >> >> >> >>> comments
>> >> >> >> >> >>> > >> below.
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
>> >> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I
>> >> think we
>> >> >> >> >> >>> > should  welcome
>> >> >> >> >> >>> > >> it
>> >> >> >> >> >>> > >> >>>> >> like we would any other contribution.
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >> >> 3) to access data through an application
>> >> >> >> >> service with
>> >> >> >> >> >>> > >> >>>> declarative
>> >> >> >> >> >>> > >> >>>> >> >> implementation by DAS
>> >> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks
>> >> radar.
>> >> >> >> >> >>> > >> >>>> >> --
>> >> >> >> >> >>> > >> >>>> >> Jeremy
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>> >>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >> 
>> --------------------------------------------------------------------
>> >> >> >> >> >>> > >> -
>> >> >> >> >> >>> > >> >>>> >> 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
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>>
>> >> >> >> >> >>> > >> >>>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> > >> >>
>> >> >> >> >> >>> >
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >>> > >> >> 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
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >> >
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>> > >>
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >>> > >> 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
>> >> >> >> >> >>> >
>> >> >> >> >> >>> >
>> >> >> >> >> >>>
>> >> >> >> >> >>>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> >>> 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
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >> >> 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
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> 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
>> >>
>> >>
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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: Declarative DAS, was Re: Modeling the RDB DAS in SCA

[Amita Vadhavkar <am...@gmail.com>]

Hello Kevin , Luciano,
Thanks a lot for all your suggestions and looking forward to have a IRC chat
with you.
I am proposing 9th Nov 5.30 a.m. IST (8th Nov 4.00 p.m. PST) for approx. 1
hr.
Please join the chat and we all can discuss -
1) what we are trying to provide - service, container
2) what all features can be provided
3) any high level design suggestions ( sim. to Kevin's latest reply )
4) any other suggestions
5) we can try to come up with a list of work items
This will be very helpful in getting a clear picture of what all can be done

in SCA (as well as DAS) domain for our current work.

Regards,
Amita

On 11/8/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Hello Amita,
>
> This looks promising.  I notice your test case uses explicit updates and
> inserts.  While this is supported by the DAS it is not the preferred
> usage which is to allow the RDB DAS to generate the CUD statements from
> the SDO change history.  Could you modify the example to read a data
> graph and then post the changes back via "applyChanges"?  Maybe the
> equivalent of this simple test from the DAS test suite:
>
>    public void testReadModifyApply4() throws Exception {
>
>        DAS das = DAS.FACTORY.createDAS(getConfig("CustomerConfig.xml"),
> getConnection());
>        // Read customer with particular ID
>        Command select = das.getCommand("getCustomer");
>        select.setParameter(1, 1);
>        DataObject root = select.executeQuery();
>
>        DataObject customer = (DataObject) root.get("CUSTOMER[1]");
>
>        // Modify customer
>        customer.set("LASTNAME", "Pavick");
>
>        das.applyChanges(root);
>
>        // Verify the change
>        root = select.executeQuery();
>        assertEquals("Pavick",
> root.getDataObject("CUSTOMER[1]").getString("LASTNAME"));
>
>    }
>
> Also, this service interface seems difficult to work with since command
> identifiers and argument values are encoded in the params Vector
>
>    public interface CustomersOrdersService {
>
>        void execute(Vector params);
>        DataObject executeQuery(Vector params);
>        void applyChanges(Vector params);
>        DataObject executeAdhoc(Vector params);//adhoc query implementation
>
>        DataObject getAllCustomers(Vector paramsList);
>
>    }
>
> Do you think it possible to implement something like the following
> interface:
>
>    public interface DynamicRDBDASService {
>
>        DataObject execute(String commandName, List params);
>        DataObject executeAdHoc(String queryString, List params);
>        void applyChanges();
>    }
>
> The name is kind of long (suggestions welcome) but, I think this
> interface could be generic and set of available commands is driven by
> the provided DAS config file.  I am not sure how we might support SP OUT
> parameters but we can think about that later.
>
> I does seem like you and Luciano should team up on this.
>
> Thanks!
> --
> Kevin
>
>
>
>
> Amita Vadhavkar wrote:
>
> > Hi Kevin,
> > Thanks a lot for the comments. I have posted the code and doc on
> JIRA-904
> > for the container work. Also, am most likely missing something in the
> > database
> > connection portion. Would like to discuss with you.
> >
> > Will you please provide feedback on JIRA-904 attachments?
> >
> > I am checking with Luciano for a convenient date/time when we can chat,
> > would
> > be great if you can also join. I am in IST timezone.
> >
> > Regards,
> > Amita
> >
> > On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >>
> >> Hi Amita,
> >> This is looking good.  Some comments inline:
> >>
> >> Amita Vadhavkar wrote:
> >>
> >> > Hi,
> >> > I am trying to create a container for DAS-SCA too (not just for
> stored
> >> > procedure) and will be able to send a working code in ML over the
> >> > weekend.
> >> >
> >> > Below is summary of what I got so far from the previous mail
> >> > discussions and
> >> > some questions.
> >> >
> >> >
> >> > The integration between DAS and SCA can happen at application level
> as
> >> > service or at container level.
> >> >
> >> >
> >> >
> >> > 2 different possible approaches –
> >> >
> >> > static – e.g. getAllCustomers
> >> >
> >> > dynamic – e.g. execute("all customers");
> >> >
> >> >
> >> >
> >> > For application level service – it is the sample *
> >> > sample-StoredProcedureService.jar*  or what Luciano is providing in
> >> more
> >> > details, is an example.  In *sample-StoredProcedureService.jar*
> >> example
> >> > dynamic approach is followed
> >> >
> >> >
> >> >
> >> > For container approach – again static or dynamic approach can be
> >> > followed.
> >> > For static – it's like providing service for getAllCompanies(),
> >> > getAllCustomers() etc. whereas for dynamic its like execute(command)
> >> > where
> >> > command can be "getAllCompanies", "getAllCustomers". Etc.
> >> >
> >> >
> >> >
> >> >            I am working on a container implementation where dynamic
> >> > approach is followed.
> >> >
> >> If I understand correctly, the container approach will provide the
> >> tightest integration with SCA and make things easier for end-users.  Do
> >> you agree?
> >>
> >> >
> >> >
> >> > There are 2 places where extensibility is required –
> >> >
> >> > 1)      for providing different data access mechanisms. i.e. today
> >> > there is
> >> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
> >> > scdl will
> >> > be same, but the exampleconfig.xml will change.
> >> >
> >> > In the container I am working on - Scdl has a new tag
> >> >
> >> > Scdl has a new tag
> >> >  <da:implementation.da script="customersOrders/CustomersOrders.xml"
> >> > dataAccessType="rdb"/>
> >> >
> >> >
> >> >
> >> > Here, dataAccessType – is the key which tells whether it's RDB or
> >> > something
> >> > else. And the xml script provides the connection and data store
> >> details.
> >> >
> >> >
> >> >
> >> > 2)      for RDB-DAS – providing support for different databases (this
> >> > portion should be part of DAS and  not SCA.) In the current container
> >> > I am
> >> > working on it is provided as a package -
> >> > org.apache.tuscany.container.dataaccessshelper package  - which
> should
> >> > finally go into DAS codeline(?).
> >> >
> >> >
> >> Currently, there are two ways to specify a particular database:  first,
> >> the user can pass a JDBC Connection to the DAS Factory when creating a
> >> DAS instance.  The second is that a DataSource can be specified in the
> >> DAS Config xml file in which case the DAS is responsible for getting
> the
> >> connection.
> >>
> >> >
> >> >
> >> >
> >> > For static approach we may need some code generation tooling.
> >>
> >> Right.  That is why I think it best to start with dynamic.  But, we
> will
> >> want static support as well.
> >>
> >> > Also could not
> >> > understand how this can be merged into RESTful interfaces. (this was
> >> > mentioned in some mail conversation)
> >> >
> >> >
> >> >
> >> > Regards,
> >> >
> >> > Amita
> >> >
> >> >
> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >
> >> >>
> >> >> Luciano Resende wrote:
> >> >>
> >> >> > Comments in-line...
> >> >> >
> >> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> >> >> >>
> >> >> >> > Hi,
> >> >> >> >
> >> >> >> > I would also like to understand this a little better ... here
> >> I am
> >> >> >> > thinking
> >> >> >> > aloud and hope the others will help in getting my persceptions
> >> >> >> > right...
> >> >> >> >
> >> >> >> > I guess firstly it is a question of how or where we want to
> >> >> >> > position 'DAS
> >> >> >> > Integration' in SCA.  Is is something we want to integrate as
> >> the
> >> >> >> > Application Layer, which I understand is what Amita is trying
> >> >> >> > presently and
> >> >> >> > which Jim refers to as component implementation.   In this
> >> option
> >> >> >> > we get to
> >> >> >> > do some sort of a service wrapper to DAS and then it becomes a
> >> >> >> > demonstration
> >> >> >> > of two Tuscany subprojects integrating at application level.
> >> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > Yes, I think we have space to position DAS both ways, and
> >> integrating
> >> >> > in the
> >> >> > application layer by exposing DAS as a service would be a very
> easy
> >> >> and
> >> >> > quick, this could be exposed as a sample app, and could show we
> are
> >> >> > working
> >> >> > on getting a better integration between DAS and SCA
> >> >> >
> >> >> >
> >> >> >> Or do we want to position DAS at the infrastructure layer as
> >> another
> >> >> >> > extension type (either container or binding).  I guess this is
> >> >> >> > where Ant
> >> >> >> > started this - proposing a JDBC container / binding for
> >> component
> >> >> >> > implementation in StoredProcedures.
> >> >> >> I was thinking a DAS was a way to declaratively model
> >> heterogeneous
> >> >> >> data as a service and offer a mechanism for remoting that data.
> In
> >> >> >> other words, it provided the ability for an application to
> perform
> >> >> >> CRUD using a high-level contract (interface) and having those
> >> >> >> operations take place across a service network.  How this is
> >> hooked
> >> >> >> into the SCA container is probably best done as an extension
> type,
> >> >> >> i.e. someone could specify:
> >> >> >>
> >> >> >> <component name="Foo">
> >> >> >>         <implementation.das>
> >> >> >>                 <interface.java ....>
> >> >> >>         </implementation.das>
> >> >> >> </component>
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > Yes, this goes back to the way I was thinking on my original
> >> proposal.
> >> >> >
> >> >> >
> >> >> >> If this is the path we should take
> >> >> >> > then we probably have to think beyond DAS - to something more
> >> >> >> > general - of
> >> >> >> > which DAS is just a special case.  I suppose this is what Jim
> >> has
> >> >> also
> >> >> >> > suggested in trying to explore other persistence mechanisms.
> >> >> >> >
> >> >> >> This may be the crux of the confusion. I was thinking DAS
> >> provides a
> >> >> >> general mechanism for accessing heterogeneous data and is only
> >> right
> >> >> >> now tied to SQL because of resource constraints (i.e. we have to
> >> >> >> start somewhere). Ultimately, DAS should provide the
> >> infrastructure
> >> >> >> for dealing with multiple, varied data stores and mechanisms for
> >> >> >> querying across them. In other words, I guess I am saying DAS
> >> should
> >> >> >> be the general solution (declarative and heterogeneous) since
> >> if it
> >> >> >> is only a programmatic way to access relational data then its
> >> value
> >> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > Yes, the current status of DAS implementation is RDB only. I would
> >> say
> >> >> > that,
> >> >> > in the future, I'd like to see a heterogeneous DAS that would give
> >> you
> >> >> > access to different data stores, and probably support non-SDO
> types
> >> as
> >> >> > well.
> >> >> >
> >> >> >> I too feel that this is something that must be done as an
> >> extension
> >> >> >> > type -
> >> >> >> > but yet to get my hands on the general scheme of things that
> DAS
> >> >> >> > can slip
> >> >> >> > into. Infact the other thread where Jeremy has taken forward a
> >> >> >> > proposal to
> >> >> >> > the specs group on resources tempts me to think that there is
> >> going
> >> >> >> > to be
> >> >> >> > something in that which we can leverage from.
> >> >> >> >
> >> >> >> I think resources are orthogonal as they are about a component
> >> >> >> implementation's contract with its container. Declarative data
> >> >> >> services on the other hand are about application constructs
> >> that can
> >> >> >> be wired to.
> >> >> >>
> >> >> >> > I hope to get a better understanding this as we go along in
> this
> >> >> >> > thread :)
> >> >> >> >
> >> >> >> Me too :-) As soon as I have trouble explaining technologies to
> >> .NET
> >> >> >> people and they say "you Unix/Java people are at it again with a
> >> >> >> thousand ways to do the same exact thing" it causes me to think
> >> that
> >> >> >> maybe we need to clarify our message.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > If we all think it would be useful, I could try to summarize the
> >> >> > thread on
> >> >> > the wiki with a more clean proposal incorporating all your
> >> feedback ,
> >> >> > what
> >> >> > you guys think ?
> >> >>
> >> >> Yes.  Great idea.
> >> >>
> >> >> >
> >> >> >
> >> >> > Jim
> >> >> >
> >> >> >> > Thanks
> >> >> >> >
> >> >> >> > - Venkat
> >> >> >> >
> >> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >>
> >> >> >> >> Jim Marino wrote:
> >> >> >> >>
> >> >> >> >> > When I first read the thread on this, I thought the DAS
> >> service
> >> >> >> >> would
> >> >> >> >> > be a component extension type (e.g. analogous to a
> >> >> >> >> > implementation.java or implementation.ejb) and not a
> >> component
> >> >> >> >> > implementation type, which would allow for dynamic and
> >> >> eventually
> >> >> >> >> > declarative configuration styles.
> >> >> >> >>
> >> >> >> >> I have not very familiar with the terminology so I am not sure
> >> >> what
> >> >> a
> >> >> >> >> "component extension type" is.  But, I do think we eventually
> >> want
> >> >> >> >> "implementation.rdbdas".  Wouldn't this be a new
> implementation
> >> >> type?
> >> >> >> >>
> >> >> >> >> It looks like Amita chose to start with a POJO.  I notice
> >> the use
> >> >> >> >> of "
> >> >> >> >> implementation.java".
> >> >> >> >>
> >> >> >> >> > Either way, though, I am curious as  to why
> >> >> >> >> >
> >> >> >> >> > public DAS configureService(String configFile);
> >> >> >> >> >
> >> >> >> >> > exists as part of the service definition? If the DAS service
> >> >> was a
> >> >> >> >> > component extension type, it could be handled as part of the
> >> >> >> >> > application bootstrap. If the DAS service was a component
> >> >> >> >> > implementation type, the configuration file URI could be
> >> passed
> >> >> >> >> in as
> >> >> >> >> > a property and then processed in an initializer method
> >> decorated
> >> >> by
> >> >> >> >> > the SCA @Init annotation. In the latter case, if the
> >> >> implementation
> >> >> >> >> > of DASService thread-safe (hopefully it is since
> >> configuration
> >> >> >> >> would
> >> >> >> >> > seem to be a heavyweight operation), then I would make the
> >> >> >> >> component
> >> >> >> >> > module scoped to avoid initialization overhead on every
> >> >> resolution.
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > In both approaches (extension vs. implementation type),
> >> having
> >> >> >> >> > configuration exposed to the application doesn't quite feel
> >> >> right,
> >> >> >> >> > since that is what DI tries to externalize.
> >> >> >> >>
> >> >> >> >> I agree.  The configuration should be part of the
> >> >> initialization and
> >> >> >> >> should use SCA patterns to do this.  I think that Amita meant
> >> >> to use
> >> >> >> >> eventually use a component property for the DAS config info
> but
> >> >> >> >> started
> >> >> >> >> with a method.
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > Also, I was thinking that in having this a component
> >> extension
> >> >> >> >> type,
> >> >> >> >> > the service interfaces returned from a resolution could
> >> include
> >> >> the
> >> >> >> >> > dynamic one described below or static ones people have
> >> >> mentioned.
> >> >> I
> >> >> >> >> > guess it is best to start with the easier-to-implement part
> >> >> >> >> first and
> >> >> >> >> > support the dynamic interface.
> >> >> >> >> >
> >> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be
> >> nice to
> >> >> >> >> > understand what DAS provides in relation to other
> persistence
> >> >> >> >> > technologies. Outside of the Java world, Microsoft is
> >> promoting
> >> >> >> >> LINQ
> >> >> >> >> > which is really interesting, and it would be informative to
> >> >> compare
> >> >> >> >> > the goals of DAS with that approach (there are obvious
> >> >> differences
> >> >> >> >> > such as having the query language a strongly-typed part of
> >> the
> >> >> >> >> > programming language, e.g. C#, and LINQ's use of closures).
> >> >> >> >> >
> >> >> >> >> > In contrasting DAS to O-R technologies, I see the primary
> use
> >> >> cases
> >> >> >> >> > for the former being a quick way to issue a query that may
> be
> >> >> >> >> > executed against *heterogeneous* data stores and have that
> >> data
> >> >> >> >> flow
> >> >> >> >> > remotely or to a client that is not necessarily
> >> Java-based. One
> >> >> key
> >> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> >> >> >> >> (Hibernate
> >> >> >> >> > and JPA are about as easy):
> >> >> >> >> >
> >> >> >> >> IMO the primary use case for DAS is an application that is
> SDO-
> >> >> >> >> centric
> >> >> >> >> and is taking advantage of its disconnected capabilities.  The
> >> RDB
> >> >> >> >> DAS
> >> >> >> >> is built to work with SDO and uses the change summary to drive
> >> >> >> >> changes
> >> >> >> >> made to a disconnected data graph back to some store.  This is
> >> not
> >> >> to
> >> >> >> >> say that a relational DAS could not be built on top of JPA, in
> >> >> fact,
> >> >> >> >> this might be a very useful thing to do.  The implementation
> we
> >> >> >> >> currently have provides a very straightforward implicit
> mapping
> >> >> from
> >> >> >> >> DataObjects to Tables.  If more capable mapping is needed
> >> then it
> >> >> >> >> makes
> >> >> >> >> sense to use the JPA-defined technology and artifacts.  A
> >> modified
> >> >> >> >> Entity manager might be needed to take advantage of SDO's
> >> change
> >> >> >> >> summary.
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > public interface CustomerDao extends BaseQuery {
> >> >> >> >> >     @Select("select * from customers where city = ?1")
> >> >> >> >> >     DataSet<Customer> findCustomersFrom(String city);
> >> >> >> >> > }
> >> >> >> >> >
> >> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> >> >> >> >> > (CustomerDao.class, datasource);
> >> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > The other key is remote data and change lists.  I think
> there
> >> >> are
> >> >> >> >> > (literally) about a thousand ways that already exist to
> >> >> handle the
> >> >> >> >> > "local" data case. For change lists, interop with ADO.NET's
> >> >> change
> >> >> >> >> > summary facilities would be interesting.
> >> >> >> >>
> >> >> >> >> I agree.  Also, it looks like Xcalia may have a similar
> >> thought:
> >> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think
> >> it is
> >> >> >> >> > important we have a clear statement as to when it is
> >> appropriate
> >> >> >> >> and
> >> >> >> >> > not appropriate to use. One place to start would be to
> >> compare
> >> >> >> >> it to
> >> >> >> >> > JDBC 4 and JPA.
> >> >> >> >>
> >> >> >> >> We can get started with JPA:
> >> >> >> >>
> >> >> >> >>     * JPA is java-specific, container-based, built around a
> >> >> connected
> >> >> >> >>       data model and offers a complete O/R mapping for POJOs
> >> >> >> >>
> >> >> >> >>     * The RDB DAS is a java implementation of a language -
> >> neutral
> >> >> >> >>       concept (hopefully specified some day) that is
> >> >> containerless,
> >> >> >> >>       assumes a disconnected data model and provides a simple,
> >> >> >> >> implicit
> >> >> >> >>       mapping for SDO DataObjects (Dynamic or Static) to
> >> >> relational
> >> >> >> >> tables.
> >> >> >> >>
> >> >> >> >> Anything else?
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > Jim
> >> >> >> >> >
> >> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >> >> >> >> >
> >> >> >> >> >> Hi Amita
> >> >> >> >> >>
> >> >> >> >> >> I think we were both going on the same way, with the DAS
> >> >> Service
> >> >> >> >> >> sample,
> >> >> >> >> >> altough i had the interface more like this, to be more
> >> >> flexible :
> >> >> >> >> >>
> >> >> >> >> >> public interface DASService {
> >> >> >> >> >>
> >> >> >> >> >>    public DAS configureService(String configFile);
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >>    public DataObject executeCommand(String commandName);
> >> >> >> >> >>    public DataObject execute(String newCommand);
> >> >> >> >> >>    public void applyChanges(DataObject graphRoot);
> >> >> >> >> >> }
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> As for having it as a sample, maybe we could defined the
> >> >> >> >> DASService
> >> >> >> >> >> as one
> >> >> >> >> >> sample itself, and have a second version of companyWeb that
> >> >> would
> >> >> >> >> >> consume
> >> >> >> >> >> the service, something like :
> >> >> >> >> >>
> >> >> >> >> >> das\samples\companyWeb
> >> >> >> >> >> das\samples\dasService
> >> >> >> >> >> das\samples.companyWeb.service
> >> >> >> >> >>
> >> >> >> >> >> or, more like BigBank
> >> >> >> >> >>
> >> >> >> >> >> das\samples\companyweb.Service\dasService
> >> >> >> >> >> das\samples\companyweb.Service\webClient
> >> >> >> >> >>
> >> >> >> >> >> Or even in sampleApps...
> >> >> >> >> >>
> >> >> >> >> >> Toughts ?
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
> >> wrote:
> >> >> >> >> >>
> >> >> >> >> >>>
> >> >> >> >> >>> Hi ,
> >> >> >> >> >>> I am also following up another thread
> >> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> msg09944.html
> >> >> >> >> >>> on the
> >> >> >> >> >>> similar issue (JDBC stored procedure container
> >> >> >> >> >>> using DAS)
> >> >> >> >> >>> Besides the fact that I am actively working on the
> >> container
> >> >> >> >> work,
> >> >> >> >> >>> I also
> >> >> >> >> >>> have tried to
> >> >> >> >> >>> develop a sample based on the below discussion, following
> >> >> dynamic
> >> >> >> >> >>> approach.
> >> >> >> >> >>>
> >> >> >> >> >>> I am attaching the same here. Please take a look and give
> >> your
> >> >> >> >> >>> suggestions.
> >> >> >> >> >>> In this, StoredProcedureService implementation has
> >> >> >> >> setConfigInfo (DAS
> >> >> >> >> >>> Config) and
> >> >> >> >> >>> execute(Any SQL). This can be made more complete with
> >> >> >> >> executeSQL(),
> >> >> >> >> >>> applyChanges()
> >> >> >> >> >>> etc.
> >> >> >> >> >>>
> >> >> >> >> >>> Can this be added to the existing set of samples?
> >> >> >> >> >>>
> >> >> >> >> >>> Regards,
> >> >> >> >> >>> Amita
> >> >> >> >> >>>
> >> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >> >>> >
> >> >> >> >> >>> > Luciano Resende wrote:
> >> >> >> >> >>> >
> >> >> >> >> >>> > > Kevin, from what I understood from your suggestion, it
> >> was
> >> >> >> >> >>> looking to
> >> >> >> >> >>> > me
> >> >> >> >> >>> > > more like exposing DAS as a service :
> >> >> >> >> >>> > >
> >> >> >> >> >>> > >>>   public interface RDBDASService
> >> >> >> >> >>> > >>>        DataObject execute(String commandName);
> >> >> >> >> >>> > >>>        DataObject executeSQL(String abitrarySQL);
> >> >> >> >> >>> > >>>        void applyChanges(DataObject graphRoot);
> >> >> >> >> >>> > >>>    }
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > Yes, I am talking about exposing a DAS Service
> configured
> >> >> >> >> with a
> >> >> >> >> >>> > specific set of capabilities/commands defined in the DAS
> >> >> config
> >> >> >> >> >>> file.
> >> >> >> >> >>> > So, if the implementation of the service interface above
> >> was
> >> >> >> >> >>> configured
> >> >> >> >> >>> > to work with Customers they would use the service like
> >> this:
> >> >> >> >> >>> >
> >> >> >> >> >>> >    List customers = myRDBDASService.execute
> >> >> ("getAllCustomers");
> >> >> >> >> >>> >    String name = customers.get(0).getString("name");
> >> >> >> >> >>> >
> >> >> >> >> >>> > This is not much different than the static interface you
> >> >> >> >> proposed,
> >> >> >> >> >>> > right?
> >> >> >> >> >>> >
> >> >> >> >> >>> > > And then, when a service developer defines the
> >> >> >> >> AccountService,
> >> >> >> >> >>> he will
> >> >> >> >> >>> >
> >> >> >> >> >>> > > have
> >> >> >> >> >>> > > to know about yet another service, about how DAS
> works,
> >> >> >> >> how it is
> >> >> >> >> >>> > > configured, etc, etc... is that right ?
> >> >> >> >> >>> > >
> >> >> >> >> >>> > The abilities of the service are defined by the DAS
> >> config
> >> >> >> >> file.
> >> >> >> >> >>> So,
> >> >> >> >> >>> > the person or tool that provides the config file must
> >> >> >> >> understand
> >> >> >> >> >>> how the
> >> >> >> >> >>> >
> >> >> >> >> >>> > RDB DAS APIs work.  There is no getting around this.
> >> >> >> >> >>> >
> >> >> >> >> >>> > > My proposal was going more towards allowing the
> service
> >> >> >> >> >>> developer to
> >> >> >> >> >>> > > focus
> >> >> >> >> >>> > > on defining the service, and let the "declarative
> >> das" to
> >> >> >> >> >>> handle the
> >> >> >> >> >>> > > persistent layer....
> >> >> >> >> >>> > >
> >> >> >> >> >>> > The DAS config file is the declaration of an instance of
> >> the
> >> >> >> >> >>> DAS.  That
> >> >> >> >> >>> > instance can be exposed as a dynamic or typed service/
> >> >> >> >> interface.
> >> >> >> >> >>> That
> >> >> >> >> >>> > seems to be the main discussion we are having.
> >> Although, I
> >> >> >> >> may be
> >> >> >> >> >>> > missing something.
> >> >> >> >> >>> >
> >> >> >> >> >>> > > Also, by defining some conventions over configuration
> >> >> >> >> and/or  using
> >> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a
> >> stored
> >> >> >> >> >>> procedure),
> >> >> >> >> >>> > the
> >> >> >> >> >>> > > service developer could really define a service that
> >> >> >> >> interacts
> >> >> >> >> >>> with a
> >> >> >> >> >>> > > RDB,
> >> >> >> >> >>> > > without having to code the service persistence layer.
> >> >> >> >> >>> > >
> >> >> >> >> >>> > There is a lot of potential for the use of annotations.
> >> >> >> >> >>> >
> >> >> >> >> >>> > >
> >> >> >> >> >>> > > - Luciano
> >> >> >> >> >>> > >
> >> >> >> >> >>> > >
> >> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net>
> >> wrote:
> >> >> >> >> >>> > >
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> The real difference between the two approaches is
> that
> >> >> >> >> one is
> >> >> >> >> >>> "Typed"
> >> >> >> >> >>> > or
> >> >> >> >> >>> > >> static and the other is dynamic.  I think both are
> >> needed
> >> >> >> >> but  was
> >> >> >> >> >>> > >> suggesting that we start with dynamic since it is the
> >> >> most
> >> >> >> >> >>> flexible
> >> >> >> >> >>> > and
> >> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a
> >> static
> >> >> >> >> >>> capability.
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> With either, the user does not need to know about
> >> >> >> >> traditional
> >> >> >> >> >>> > >> persistence frameworks.  With the dynamic approach,
> >> >> however,
> >> >> >> >> >>> the user
> >> >> >> >> >>> > >> does need to know about the dynamic SDO API.
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> So, with the static interface the user might write:
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>     List customers = accountService.getAllCustomers
> ();
> >> >> >> >> >>> > >>     String name =
> >> ((Customer)customers.get(0)).getName();
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> The equivalent dynamic API might be:
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>     List customers =
> >> >> dasService.execute("getAllCustomers");
> >> >> >> >> >>> > >>     String name =
> >> >> ((DataObject)customers.get(0)).getString
> >> >> >> >> >>> ("name");
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> The first is probably a little easier for the
> >> application
> >> >> >> >> >>> developer
> >> >> >> >> >>> > but
> >> >> >> >> >>> > >> the second is much easier for the service developer.
> >> IMO,
> >> >> >> >> the
> >> >> >> >> >>> dynamic
> >> >> >> >> >>> > >> case is the best place to start and, again, we
> >> >> >> >> definitely  will
> >> >> >> >> >>> want
> >> >> >> >> >>> > >> support for both.
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> Thanks.
> >> >> >> >> >>> > >> --
> >> >> >> >> >>> > >> Kevin
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> Jeremy Boynes wrote:
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >> > I think this would be useful but it seems more
> >> like a
> >> >> >> >> >>> traditional
> >> >> >> >> >>> > >> > persistence API than what Luciano was suggesting.
> >> With
> >> >> >> >> this
> >> >> >> >> >>> one a
> >> >> >> >> >>> > >> > user needs to know about DataObject's, commands,
> SQL
> >> >> >> >> strings
> >> >> >> >> >>> etc.
> >> >> >> >> >>> > >> > just like they would if they were using raw JDBC or
> >> >> JPA.
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more
> >> about
> >> >> >> >> >>> expressing
> >> >> >> >> >>> > >> > high-level CRUD operations as operations on a
> >> service
> >> >> >> >> >>> interface:
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>    public List getAllCustomers();
> >> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
> >> >> >> >> accountNumber);
> >> >> >> >> >>> > >> >>> }
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > which is all application level concepts rather
> >> >> >> >> than  persistence
> >> >> >> >> >>> > level
> >> >> >> >> >>> > >> > concepts. I'd actually go a little further and put
> >> that
> >> >> >> >> >>> right into
> >> >> >> >> >>> > >> > the service contract:
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >   public interface AccountService {
> >> >> >> >> >>> > >> >     List<Customer> getAllCustomers();
> >> >> >> >> >>> > >> >     Account getCustomerAccount(String
> >> accountNumber);
> >> >> >> >> >>> > >> >   }
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
> >> >> >> >> standardized
> >> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
> >> >> configuration
> >> >> >> >> >>> would be
> >> >> >> >> >>> > >> > needed except to add this to the logical assembly:
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >   <component name="AccountStore">
> >> >> >> >> >>> > >> >     <implementation.das resource="MySQLDatabase"/>
> >> >> >> >> >>> > >> >   </component>
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > With SCA's ability to translate service contracts,
> >> this
> >> >> >> >> >>> should be
> >> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
> >> >> >> >> regardless of
> >> >> >> >> >>> > whether
> >> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
> >> >> >> >> running  on
> >> >> >> >> a
> >> >> >> >> >>> > Java,
> >> >> >> >> >>> > >> > C++ or PHP platform.
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > The important thing here is that the client is
> >> >> >> >> isolated  from
> >> >> >> >> >>> how
> >> >> >> >> >>> > the
> >> >> >> >> >>> > >> > DAS component is provided. We could have multiple
> >> >> >> >> declarative
> >> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and one
> >> that
> >> >> did
> >> >> >> >> >>> stuff
> >> >> >> >> >>> > with
> >> >> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
> >> >> >> >> altering
> >> >> >> >> >>> the
> >> >> >> >> >>> > >> > client at all/ they could switch to a custom coded
> >> >> version
> >> >> >> >> >>> written
> >> >> >> >> >>> > in
> >> >> >> >> >>> > >> > Java, C++ or a store procedure language like
> PL/SQL.
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > --
> >> >> >> >> >>> > >> > Jeremy
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >> I would suggest that we start right away with a
> >> >> RDBDAS-
> >> >> >> >> based
> >> >> >> >> >>> > >> >> solution.  I also think that the best place to
> >> start
> >> >> >> >> would
> >> >> >> >> >>> be with
> >> >> >> >> >>> > >> >> an interface that is "weakly" typed.  That is, a
> >> >> service
> >> >> >> >> >>> interface
> >> >> >> >> >>> >
> >> >> >> >> >>> > >> >> in terms of dynamic SDO's.  If we go this route we
> >> can
> >> >> >> >> >>> avoid the
> >> >> >> >> >>> > >> >> generation (by hand or otherwise) of code
> >> specific to
> >> >> >> >> a new
> >> >> >> >> >>> > >> >> service.  Instead, the service will be
> >> "instantiated"
> >> >> >> >> based
> >> >> >> >> >>> on the
> >> >> >> >> >>> >
> >> >> >> >> >>> > >> >> provided DAS config file.  The service interface
> >> >> >> >> might  look
> >> >> >> >> >>> like
> >> >> >> >> >>> > >> this:
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>    public interface RDBDASService
> >> >> >> >> >>> > >> >>        DataObject execute(String commandName);
> >> >> >> >> >>> > >> >>        DataObject executeSQL(String abitrarySQL);
> >> >> >> >> >>> > >> >>        void applyChanges(DataObject graphRoot);
> >> >> >> >> >>> > >> >>    }
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >> So, depending on the config file used to
> >> >> instantiate the
> >> >> >> >> >>> service,
> >> >> >> >> >>> > >> >> this interface could be used to return Customers/
> >> >> >> >> Accounts or
> >> >> >> >> >>> > >> >> Toasters.  In fact, a lot could be achieved with
> no
> >> >> >> >> >>> > configuration  at
> >> >> >> >> >>> > >> >> all by restricting use to:  DataObject
> >> >> executeSQL(String
> >> >> >> >> >>> > >> abitrarySQL);
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >> I expand a bit here:
> >> http://mail-archives.apache.org/
> >> >> >> >> >>> mod_mbox/ws-
> >> >> >> >> >>> > >> >>
> >> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >> Once this was working it should be
> >> straightforward to
> >> >> >> >> build
> >> >> >> >> >>> more
> >> >> >> >> >>> > >> >> strongly typed services and possible put together
> >> some
> >> >> >> >> >>> generation
> >> >> >> >> >>> > >> >> tooling.  We could also start looking at support
> >> for
> >> a
> >> >> >> >> more
> >> >> >> >> >>> > RESTFul
> >> >> >> >> >>> > >> >> interface.
> >> >> >> >> >>> > >> >> --
> >> >> >> >> >>> > >> >> Kevin
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >> Luciano Resende wrote:
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>> Recently, people have been starting to talk about
> >> >> >> >> better DAS
> >> >> >> >> >>> > >> >>> integration
> >> >> >> >> >>> > >> >>> with DAS, and below are some threads on the
> >> subject
> >> :
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> msg08833.html
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> >> msg08923.html
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >>
> >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >> >> >> >> >>> msg09715.html
> >> >> >> >> >>> >
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make
> >> sure
> >> >> >> >> what  I'm
> >> >> >> >> >>> > >> >>> saying is not
> >> >> >> >> >>> > >> >>> yet available on SCA today.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Today, defining a service to work with a
> >> relational
> >> >> >> >> >>> database, you
> >> >> >> >> >>> > >> >>> will need
> >> >> >> >> >>> > >> >>> to code the persistence side of the service where
> >> >> CRUD
> >> >> >> >> >>> operations
> >> >> >> >> >>> > >> >>> to the
> >> >> >> >> >>> > >> >>> database will be done.
> >> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
> >> coding
> >> >> >> >> the
> >> >> >> >> >>> CRUD
> >> >> >> >> >>> > >> >>> operations on
> >> >> >> >> >>> > >> >>> the persistence layer would be avoided as much as
> >> >> >> >> possible.
> >> >> >> >> >>> > >> >>> The idea would be to have a more "declarative
> DAS"
> >> >> when
> >> >> >> >> >>> defining
> >> >> >> >> >>> > SCA
> >> >> >> >> >>> > >> >>> Services, so you would either use some
> Annotations
> >> >> >> >> or  SCDL
> >> >> >> >> to
> >> >> >> >> >>> > >> have  the
> >> >> >> >> >>> > >> >>> "declarative DAS"  configuration inside it.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> I was thinking on something like....
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> SCDL Definition would look something like this :
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> <component name="AccountDataService">
> >> >> >> >> >>> > >> >>>   <interface.java
> >> >> >> >> >>> > >> >>>
> >> >> >> >> class="bigbank.account.services.account.AccountService"/>
> >> >> >> >> >>> > >> >>>   <implementation.das="dasConfig.properties"
> >> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >> >> >> >> >>> > >> >>> </component>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> The AccountService Interface would look like this
> >> >> >> >> (missing
> >> >> >> >> >>> any
> >> >> >> >> >>> > SCA
> >> >> >> >> >>> > >> >>> annotations):
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>    public List getAllCustomers();
> >> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
> >> >> >> >> accountNumber);
> >> >> >> >> >>> > >> >>> }
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> The DAS config would look like this, and would
> >> >> have the
> >> >> >> >> >>> > definition
> >> >> >> >> >>> > >> >>> for the
> >> >> >> >> >>> > >> >>> "all companies" command.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> <Config ...>
> >> >> >> >> >>> > >> >>>    ...
> >> >> >> >> >>> > >> >>>   <ConnectionInfo dataSource="java:comp/env/jdbc/
> >> >> >> >> bigbank"/>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>   <Command name="getAllCustomers" SQL="select *
> >> from
> >> >> >> >> >>> CUSTOMERS"
> >> >> >> >> >>> > >> >>> kind="Select"/>
> >> >> >> >> >>> > >> >>>   <Command name="getCustomerAccount" SQL="SELECT
> >> >> >> >> >>> accountNumber,
> >> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
> >> >> >> >> accountNumber = ?"
> >> >> >> >> >>> > >> >>> kind="Select" />
> >> >> >> >> >>> > >> >>>   ...
> >> >> >> >> >>> > >> >>> </Config>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Mapping between interface methods and DAS
> Commands
> >> >> >> >> >>> > >> >>>   - If a DAS config file is provided, based on
> the
> >> >> >> >> >>> > SCDL  definition,
> >> >> >> >> >>> > >> we
> >> >> >> >> >>> > >> >>> would look for "DAS command" based on the name of
> >> the
> >> >> >> >> getter
> >> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
> >> >> >> >> command)
> >> >> >> >> >>> > >> >>>   - Otherwise, we would try to do a map
> >> directly to
> >> a
> >> >> >> >> >>> > >> stored  procedure
> >> >> >> >> >>> > >> >>>   - We could also have a way to force the
> >> mapping by
> >> >> >> >> using
> >> >> >> >> >>> > >> annotation
> >> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Mapping between method parameter and command
> >> >> parameter
> >> >> >> >> >>> > >> >>>   - We would need to define a method for
> >> mapping the
> >> >> >> >> method
> >> >> >> >> >>> > >> >>> parameters to
> >> >> >> >> >>> > >> >>> the query paramters either based on position (
> >> >> e.gfirst
> >> >> >> >> >>> method
> >> >> >> >> >>> > >> >>> parameter
> >> >> >> >> >>> > >> >>> maps to the first command paramter), or we
> >> would do
> >> >> some
> >> >> >> >> >>> > mapping  by
> >> >> >> >> >>> > >> >>> name
> >> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Note:
> >> >> >> >> >>> > >> >>>   - A SCDL connection information would
> >> override the
> >> >> DAS
> >> >> >> >> >>> Config
> >> >> >> >> >>> > file
> >> >> >> >> >>> > >> >>> connection information.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Benefits
> >> >> >> >> >>> > >> >>>   - It's All about simplicity and easy of use
> >> >> >> >> >>> > >> >>>   - This would allow a user to define a service
> >> >> without
> >> >> >> >> >>> having to
> >> >> >> >> >>> >
> >> >> >> >> >>> > >> >>> explicitly having to code any Data Access related
> >> >> code.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Implementation approaches
> >> >> >> >> >>> > >> >>>   - Utilizing DAS : This approach would start
> from
> >> >> the
> >> >> >> >> >>> current
> >> >> >> >> >>> > >> >>> Tuscany DAS
> >> >> >> >> >>> > >> >>> implementation, where functionality would be
> >> already
> >> >> >> >> >>> > available,  but
> >> >> >> >> >>> > >> >>> the
> >> >> >> >> >>> > >> >>> service implementation would be tied to SDO and
> >> RDB
> >> >> >> >> as this
> >> >> >> >> >>> > is  what
> >> >> >> >> >>> > >> >>> DAS
> >> >> >> >> >>> > >> >>> supports today.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>   - Start simple and grow : We could start
> simple,
> >> by
> >> >> >> >> >>> having a
> >> >> >> >> >>> > >> simple
> >> >> >> >> >>> > >> >>> implementation based on JDBC and would return
> some
> >> >> >> >> simple
> >> >> >> >> >>> > >> >>> collection as a
> >> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset),
> this
> >> >> could
> >> >> >> >> >>> give us
> >> >> >> >> >>> > a
> >> >> >> >> >>> > >> >>> quick
> >> >> >> >> >>> > >> >>> start to flush implementation details and get a
> >> >> proven
> >> >> >> >> >>> design,
> >> >> >> >> >>> > and
> >> >> >> >> >>> > >> >>> this
> >> >> >> >> >>> > >> >>> could get evolved to use a DAS that would support
> >> >> >> >> multiple
> >> >> >> >> >>> > backends
> >> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well
> as
> >> >> >> >> non- SDO
> >> >> >> >> >>> types
> >> >> >> >> >>> > >> as a
> >> >> >> >> >>> > >> >>> command
> >> >> >> >> >>> > >> >>> result.
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> Toughts ?
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> - Luciano
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net>
> >> >> wrote:
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> Great.  I would like to help with this.  I have
> >> been
> >> >> >> >> >>> thinking
> >> >> >> >> >>> > for
> >> >> >> >> >>> > >> >>>> awhile
> >> >> >> >> >>> > >> >>>> about how to best integrate the RDB DAS within
> >> SCA.
> >> >> >> >> For
> >> >> >> >> >>> > >> example,  the
> >> >> >> >> >>> > >> >>>> current BBank scenario uses the RDB DAS as a
> >> utility
> >> >> >> >> but it
> >> >> >> >> >>> > >> would be
> >> >> >> >> >>> > >> >>>> nice if it could "wire in" a RDB DAS service
> >> or be
> >> >> >> >> >>> injected with
> >> >> >> >> >>> > a
> >> >> >> >> >>> > >> >>>> configured DAS.  Another thing we want to
> >> eventually
> >> >> >> >> >>> explore is
> >> >> >> >> >>> > >> >>>> exposing
> >> >> >> >> >>> > >> >>>> a DAS as REST-oriented services.  As we have
> seen
> >> >> >> >> from the
> >> >> >> >> >>> > parent
> >> >> >> >> >>> > >> >>>> thread
> >> >> >> >> >>> > >> >>>> there are almost too many possible approaches.
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a
> service
> >> >> and
> >> >> >> >> >>> create a
> >> >> >> >> >>> > new
> >> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas
> ).  The
> >> >> main
> >> >> >> >> >>> reason
> >> >> >> >> >>> > has
> >> >> >> >> >>> > >> >>>> to do
> >> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS
> that
> >> >> >> >> >>> > Jeremy  mentioned
> >> >> >> >> >>> > >> >>>> which
> >> >> >> >> >>> > >> >>>> is all about creating data access services
> >> >> >> >> >>> declaratively.  A new
> >> >> >> >> >>> > >> >>>> component type and a service that we build by
> >> hand
> >> >> >> >> would be
> >> >> >> >> >>> > a  good
> >> >> >> >> >>> > >> >>>> step
> >> >> >> >> >>> > >> >>>> in this direction.
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
> >> >> >> >> interface  like
> >> >> >> >> >>> > this:
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>>     public interface RDBDASService
> >> >> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
> >> >> >> >> >>> > >> >>>>         DataObject execute(String commandName);
> >> >> >> >> >>> > >> >>>>         DataObject executeSQL(String
> >> abitrarySQL);
> >> >> >> >> >>> > >> >>>>     }
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> The service would be initialized with an
> optional
> >> >> >> >> RDB DAS
> >> >> >> >> >>> > >> config  file
> >> >> >> >> >>> > >> >>>> that defines connection properties, a set of
> >> >> commands,
> >> >> >> >> >>> etc.  So,
> >> >> >> >> >>> > >> >>>> different services implementing the same
> >> interface
> >> >> >> >> could be
> >> >> >> >> >>> > >> >>>> initialized
> >> >> >> >> >>> > >> >>>> from separate config files.
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> Eventually, we might want to build services like
> >> >> this:
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>>     public interface Customers_RDBDASService
> >> >> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
> >> >> >> >> >>> > >> >>>>         DataObject getAllCustomersWithLastName
> >> >> (String
> >> >> >> >> >>> > lastName);
> >> >> >> >> >>> > >> >>>>         DataObject getAll
> CustomersAndOrdersForID
> >> >> (int
> >> >> >> >> >>> > customerId);
> >> >> >> >> >>> > >> >>>>     }
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> But, for this to be very useful would probably
> >> >> require
> >> >> >> >> >>> some code
> >> >> >> >> >>> > >> >>>> generation tooling.
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> Thoughts?
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> --Kevin
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> Luciano Resende wrote:
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
> >> >> >> >> declarative
> >> >> >> >> >>> > DAS  and
> >> >> >> >> >>> > >> >>>> will be
> >> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki
> >> soon...
> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >>> > >> >>>> > - Luciano
> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jb...@apache.org>
> >> >> >> >> wrote:
> >> >> >> >> >>> > >> >>>> >
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >> On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
> >> >> >> >> >>> > >> >>>> >> >> This sounds like having cake, eating it,
> >> and
> >> >> also
> >> >> >> >> >>> > being  able
> >> >> >> >> >>> > >> to
> >> >> >> >> >>> > >> >>>> >> >> give it to a friend :-) We provide the
> >> >> >> >> flexibility  for
> >> >> >> >> >>> > users:
> >> >> >> >> >>> > >> >>>> >> >> 1) to access infrastructure services
> >> through
> >> >> >> >> >>> properties
> >> >> >> >> >>> > >> >>>> >> > Yes for things like JPA, JDBC, etc.
> >> >> >> >> >>> > >> >>>> >> >> 2) to reference infrastructure services
> >> >> through
> >> >> >> >> >>> > inclusion  in
> >> >> >> >> >>> > >> >>>> their
> >> >> >> >> >>> > >> >>>> >> >> assembly
> >> >> >> >> >>> > >> >>>> >> > If we do 1 I don't think we should do 2
> >> (that
> >> >> >> >> >>> doesn't stop
> >> >> >> >> >>> > >> >>>> someone
> >> >> >> >> >>> > >> >>>> >> > from extending Tuscany to do it though).
> See
> >> my
> >> >> >> >> >>> comments
> >> >> >> >> >>> > >> below.
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I
> >> think we
> >> >> >> >> >>> > should  welcome
> >> >> >> >> >>> > >> it
> >> >> >> >> >>> > >> >>>> >> like we would any other contribution.
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >> >> 3) to access data through an application
> >> >> >> >> service with
> >> >> >> >> >>> > >> >>>> declarative
> >> >> >> >> >>> > >> >>>> >> >> implementation by DAS
> >> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks
> >> radar.
> >> >> >> >> >>> > >> >>>> >> --
> >> >> >> >> >>> > >> >>>> >> Jeremy
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>> >>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >>
> >> >> >> >> >>>
> >> >> >> >>
> >> >> --------------------------------------------------------------------
> >> >> >> >> >>> > >> -
> >> >> >> >> >>> > >> >>>> >> 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
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>>
> >> >> >> >> >>> > >> >>>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> > >> >>
> >> >> >> >> >>> >
> >> >> >> >> >>>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >>> > >> >> 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
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >> >
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>> > >>
> >> >> >> >> >>>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >>> > >> 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
> >> >> >> >> >>> >
> >> >> >> >> >>> >
> >> >> >> >> >>>
> >> >> >> >> >>>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> >>> 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
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> >> >> 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
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> 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
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA

[Kevin Williams <ke...@qwest.net>]

Hello Amita,

This looks promising.  I notice your test case uses explicit updates and 
inserts.  While this is supported by the DAS it is not the preferred 
usage which is to allow the RDB DAS to generate the CUD statements from 
the SDO change history.  Could you modify the example to read a data 
graph and then post the changes back via "applyChanges"?  Maybe the 
equivalent of this simple test from the DAS test suite:

    public void testReadModifyApply4() throws Exception {

        DAS das = DAS.FACTORY.createDAS(getConfig("CustomerConfig.xml"), 
getConnection());
        // Read customer with particular ID
        Command select = das.getCommand("getCustomer");
        select.setParameter(1, 1);
        DataObject root = select.executeQuery();

        DataObject customer = (DataObject) root.get("CUSTOMER[1]");

        // Modify customer
        customer.set("LASTNAME", "Pavick");

        das.applyChanges(root);

        // Verify the change
        root = select.executeQuery();
        assertEquals("Pavick", 
root.getDataObject("CUSTOMER[1]").getString("LASTNAME"));

    }

Also, this service interface seems difficult to work with since command 
identifiers and argument values are encoded in the params Vector

    public interface CustomersOrdersService {

        void execute(Vector params);
        DataObject executeQuery(Vector params);
        void applyChanges(Vector params);
        DataObject executeAdhoc(Vector params);//adhoc query implementation
       
        DataObject getAllCustomers(Vector paramsList);
       
    }

Do you think it possible to implement something like the following 
interface:

    public interface DynamicRDBDASService {

        DataObject execute(String commandName, List params);
        DataObject executeAdHoc(String queryString, List params);
        void applyChanges();
    }

The name is kind of long (suggestions welcome) but, I think this 
interface could be generic and set of available commands is driven by 
the provided DAS config file.  I am not sure how we might support SP OUT 
parameters but we can think about that later.

I does seem like you and Luciano should team up on this.

Thanks!
--
Kevin




Amita Vadhavkar wrote:

> Hi Kevin,
> Thanks a lot for the comments. I have posted the code and doc on JIRA-904
> for the container work. Also, am most likely missing something in the
> database
> connection portion. Would like to discuss with you.
>
> Will you please provide feedback on JIRA-904 attachments?
>
> I am checking with Luciano for a convenient date/time when we can chat,
> would
> be great if you can also join. I am in IST timezone.
>
> Regards,
> Amita
>
> On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
>
>>
>> Hi Amita,
>> This is looking good.  Some comments inline:
>>
>> Amita Vadhavkar wrote:
>>
>> > Hi,
>> > I am trying to create a container for DAS-SCA too (not just for stored
>> > procedure) and will be able to send a working code in ML over the
>> > weekend.
>> >
>> > Below is summary of what I got so far from the previous mail
>> > discussions and
>> > some questions.
>> >
>> >
>> > The integration between DAS and SCA can happen at application level as
>> > service or at container level.
>> >
>> >
>> >
>> > 2 different possible approaches –
>> >
>> > static – e.g. getAllCustomers
>> >
>> > dynamic – e.g. execute("all customers");
>> >
>> >
>> >
>> > For application level service – it is the sample *
>> > sample-StoredProcedureService.jar*  or what Luciano is providing in 
>> more
>> > details, is an example.  In *sample-StoredProcedureService.jar* 
>> example
>> > dynamic approach is followed
>> >
>> >
>> >
>> > For container approach – again static or dynamic approach can be
>> > followed.
>> > For static – it's like providing service for getAllCompanies(),
>> > getAllCustomers() etc. whereas for dynamic its like execute(command)
>> > where
>> > command can be "getAllCompanies", "getAllCustomers". Etc.
>> >
>> >
>> >
>> >            I am working on a container implementation where dynamic
>> > approach is followed.
>> >
>> If I understand correctly, the container approach will provide the
>> tightest integration with SCA and make things easier for end-users.  Do
>> you agree?
>>
>> >
>> >
>> > There are 2 places where extensibility is required –
>> >
>> > 1)      for providing different data access mechanisms. i.e. today
>> > there is
>> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
>> > scdl will
>> > be same, but the exampleconfig.xml will change.
>> >
>> > In the container I am working on - Scdl has a new tag
>> >
>> > Scdl has a new tag
>> >  <da:implementation.da script="customersOrders/CustomersOrders.xml"
>> > dataAccessType="rdb"/>
>> >
>> >
>> >
>> > Here, dataAccessType – is the key which tells whether it's RDB or
>> > something
>> > else. And the xml script provides the connection and data store 
>> details.
>> >
>> >
>> >
>> > 2)      for RDB-DAS – providing support for different databases (this
>> > portion should be part of DAS and  not SCA.) In the current container
>> > I am
>> > working on it is provided as a package -
>> > org.apache.tuscany.container.dataaccessshelper package  - which should
>> > finally go into DAS codeline(?).
>> >
>> >
>> Currently, there are two ways to specify a particular database:  first,
>> the user can pass a JDBC Connection to the DAS Factory when creating a
>> DAS instance.  The second is that a DataSource can be specified in the
>> DAS Config xml file in which case the DAS is responsible for getting the
>> connection.
>>
>> >
>> >
>> >
>> > For static approach we may need some code generation tooling.
>>
>> Right.  That is why I think it best to start with dynamic.  But, we will
>> want static support as well.
>>
>> > Also could not
>> > understand how this can be merged into RESTful interfaces. (this was
>> > mentioned in some mail conversation)
>> >
>> >
>> >
>> > Regards,
>> >
>> > Amita
>> >
>> >
>> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >
>> >>
>> >> Luciano Resende wrote:
>> >>
>> >> > Comments in-line...
>> >> >
>> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
>> >> >>
>> >> >> > Hi,
>> >> >> >
>> >> >> > I would also like to understand this a little better ... here 
>> I am
>> >> >> > thinking
>> >> >> > aloud and hope the others will help in getting my persceptions
>> >> >> > right...
>> >> >> >
>> >> >> > I guess firstly it is a question of how or where we want to
>> >> >> > position 'DAS
>> >> >> > Integration' in SCA.  Is is something we want to integrate as 
>> the
>> >> >> > Application Layer, which I understand is what Amita is trying
>> >> >> > presently and
>> >> >> > which Jim refers to as component implementation.   In this 
>> option
>> >> >> > we get to
>> >> >> > do some sort of a service wrapper to DAS and then it becomes a
>> >> >> > demonstration
>> >> >> > of two Tuscany subprojects integrating at application level.
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> > Yes, I think we have space to position DAS both ways, and 
>> integrating
>> >> > in the
>> >> > application layer by exposing DAS as a service would be a very easy
>> >> and
>> >> > quick, this could be exposed as a sample app, and could show we are
>> >> > working
>> >> > on getting a better integration between DAS and SCA
>> >> >
>> >> >
>> >> >> Or do we want to position DAS at the infrastructure layer as 
>> another
>> >> >> > extension type (either container or binding).  I guess this is
>> >> >> > where Ant
>> >> >> > started this - proposing a JDBC container / binding for 
>> component
>> >> >> > implementation in StoredProcedures.
>> >> >> I was thinking a DAS was a way to declaratively model 
>> heterogeneous
>> >> >> data as a service and offer a mechanism for remoting that data. In
>> >> >> other words, it provided the ability for an application to perform
>> >> >> CRUD using a high-level contract (interface) and having those
>> >> >> operations take place across a service network.  How this is 
>> hooked
>> >> >> into the SCA container is probably best done as an extension type,
>> >> >> i.e. someone could specify:
>> >> >>
>> >> >> <component name="Foo">
>> >> >>         <implementation.das>
>> >> >>                 <interface.java ....>
>> >> >>         </implementation.das>
>> >> >> </component>
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Yes, this goes back to the way I was thinking on my original
>> proposal.
>> >> >
>> >> >
>> >> >> If this is the path we should take
>> >> >> > then we probably have to think beyond DAS - to something more
>> >> >> > general - of
>> >> >> > which DAS is just a special case.  I suppose this is what Jim 
>> has
>> >> also
>> >> >> > suggested in trying to explore other persistence mechanisms.
>> >> >> >
>> >> >> This may be the crux of the confusion. I was thinking DAS 
>> provides a
>> >> >> general mechanism for accessing heterogeneous data and is only 
>> right
>> >> >> now tied to SQL because of resource constraints (i.e. we have to
>> >> >> start somewhere). Ultimately, DAS should provide the 
>> infrastructure
>> >> >> for dealing with multiple, varied data stores and mechanisms for
>> >> >> querying across them. In other words, I guess I am saying DAS 
>> should
>> >> >> be the general solution (declarative and heterogeneous) since 
>> if it
>> >> >> is only a programmatic way to access relational data then its 
>> value
>> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Yes, the current status of DAS implementation is RDB only. I would
>> say
>> >> > that,
>> >> > in the future, I'd like to see a heterogeneous DAS that would give
>> you
>> >> > access to different data stores, and probably support non-SDO types
>> as
>> >> > well.
>> >> >
>> >> >> I too feel that this is something that must be done as an 
>> extension
>> >> >> > type -
>> >> >> > but yet to get my hands on the general scheme of things that DAS
>> >> >> > can slip
>> >> >> > into. Infact the other thread where Jeremy has taken forward a
>> >> >> > proposal to
>> >> >> > the specs group on resources tempts me to think that there is
>> going
>> >> >> > to be
>> >> >> > something in that which we can leverage from.
>> >> >> >
>> >> >> I think resources are orthogonal as they are about a component
>> >> >> implementation's contract with its container. Declarative data
>> >> >> services on the other hand are about application constructs 
>> that can
>> >> >> be wired to.
>> >> >>
>> >> >> > I hope to get a better understanding this as we go along in this
>> >> >> > thread :)
>> >> >> >
>> >> >> Me too :-) As soon as I have trouble explaining technologies to 
>> .NET
>> >> >> people and they say "you Unix/Java people are at it again with a
>> >> >> thousand ways to do the same exact thing" it causes me to think 
>> that
>> >> >> maybe we need to clarify our message.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > If we all think it would be useful, I could try to summarize the
>> >> > thread on
>> >> > the wiki with a more clean proposal incorporating all your 
>> feedback ,
>> >> > what
>> >> > you guys think ?
>> >>
>> >> Yes.  Great idea.
>> >>
>> >> >
>> >> >
>> >> > Jim
>> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >> > - Venkat
>> >> >> >
>> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >>
>> >> >> >> Jim Marino wrote:
>> >> >> >>
>> >> >> >> > When I first read the thread on this, I thought the DAS 
>> service
>> >> >> >> would
>> >> >> >> > be a component extension type (e.g. analogous to a
>> >> >> >> > implementation.java or implementation.ejb) and not a 
>> component
>> >> >> >> > implementation type, which would allow for dynamic and
>> >> eventually
>> >> >> >> > declarative configuration styles.
>> >> >> >>
>> >> >> >> I have not very familiar with the terminology so I am not sure
>> >> what
>> >> a
>> >> >> >> "component extension type" is.  But, I do think we eventually
>> want
>> >> >> >> "implementation.rdbdas".  Wouldn't this be a new implementation
>> >> type?
>> >> >> >>
>> >> >> >> It looks like Amita chose to start with a POJO.  I notice 
>> the use
>> >> >> >> of "
>> >> >> >> implementation.java".
>> >> >> >>
>> >> >> >> > Either way, though, I am curious as  to why
>> >> >> >> >
>> >> >> >> > public DAS configureService(String configFile);
>> >> >> >> >
>> >> >> >> > exists as part of the service definition? If the DAS service
>> >> was a
>> >> >> >> > component extension type, it could be handled as part of the
>> >> >> >> > application bootstrap. If the DAS service was a component
>> >> >> >> > implementation type, the configuration file URI could be 
>> passed
>> >> >> >> in as
>> >> >> >> > a property and then processed in an initializer method
>> decorated
>> >> by
>> >> >> >> > the SCA @Init annotation. In the latter case, if the
>> >> implementation
>> >> >> >> > of DASService thread-safe (hopefully it is since 
>> configuration
>> >> >> >> would
>> >> >> >> > seem to be a heavyweight operation), then I would make the
>> >> >> >> component
>> >> >> >> > module scoped to avoid initialization overhead on every
>> >> resolution.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > In both approaches (extension vs. implementation type), 
>> having
>> >> >> >> > configuration exposed to the application doesn't quite feel
>> >> right,
>> >> >> >> > since that is what DI tries to externalize.
>> >> >> >>
>> >> >> >> I agree.  The configuration should be part of the
>> >> initialization and
>> >> >> >> should use SCA patterns to do this.  I think that Amita meant
>> >> to use
>> >> >> >> eventually use a component property for the DAS config info but
>> >> >> >> started
>> >> >> >> with a method.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Also, I was thinking that in having this a component 
>> extension
>> >> >> >> type,
>> >> >> >> > the service interfaces returned from a resolution could 
>> include
>> >> the
>> >> >> >> > dynamic one described below or static ones people have
>> >> mentioned.
>> >> I
>> >> >> >> > guess it is best to start with the easier-to-implement part
>> >> >> >> first and
>> >> >> >> > support the dynamic interface.
>> >> >> >> >
>> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be 
>> nice to
>> >> >> >> > understand what DAS provides in relation to other persistence
>> >> >> >> > technologies. Outside of the Java world, Microsoft is 
>> promoting
>> >> >> >> LINQ
>> >> >> >> > which is really interesting, and it would be informative to
>> >> compare
>> >> >> >> > the goals of DAS with that approach (there are obvious
>> >> differences
>> >> >> >> > such as having the query language a strongly-typed part of 
>> the
>> >> >> >> > programming language, e.g. C#, and LINQ's use of closures).
>> >> >> >> >
>> >> >> >> > In contrasting DAS to O-R technologies, I see the primary use
>> >> cases
>> >> >> >> > for the former being a quick way to issue a query that may be
>> >> >> >> > executed against *heterogeneous* data stores and have that 
>> data
>> >> >> >> flow
>> >> >> >> > remotely or to a client that is not necessarily 
>> Java-based. One
>> >> key
>> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
>> >> >> >> (Hibernate
>> >> >> >> > and JPA are about as easy):
>> >> >> >> >
>> >> >> >> IMO the primary use case for DAS is an application that is SDO-
>> >> >> >> centric
>> >> >> >> and is taking advantage of its disconnected capabilities.  The
>> RDB
>> >> >> >> DAS
>> >> >> >> is built to work with SDO and uses the change summary to drive
>> >> >> >> changes
>> >> >> >> made to a disconnected data graph back to some store.  This is
>> not
>> >> to
>> >> >> >> say that a relational DAS could not be built on top of JPA, in
>> >> fact,
>> >> >> >> this might be a very useful thing to do.  The implementation we
>> >> >> >> currently have provides a very straightforward implicit mapping
>> >> from
>> >> >> >> DataObjects to Tables.  If more capable mapping is needed 
>> then it
>> >> >> >> makes
>> >> >> >> sense to use the JPA-defined technology and artifacts.  A
>> modified
>> >> >> >> Entity manager might be needed to take advantage of SDO's 
>> change
>> >> >> >> summary.
>> >> >> >>
>> >> >> >> >
>> >> >> >> > public interface CustomerDao extends BaseQuery {
>> >> >> >> >     @Select("select * from customers where city = ?1")
>> >> >> >> >     DataSet<Customer> findCustomersFrom(String city);
>> >> >> >> > }
>> >> >> >> >
>> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
>> >> >> >> > (CustomerDao.class, datasource);
>> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > The other key is remote data and change lists.  I think there
>> >> are
>> >> >> >> > (literally) about a thousand ways that already exist to
>> >> handle the
>> >> >> >> > "local" data case. For change lists, interop with ADO.NET's
>> >> change
>> >> >> >> > summary facilities would be interesting.
>> >> >> >>
>> >> >> >> I agree.  Also, it looks like Xcalia may have a similar 
>> thought:
>> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
>> >> >> >>
>> >> >> >> >
>> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think 
>> it is
>> >> >> >> > important we have a clear statement as to when it is
>> appropriate
>> >> >> >> and
>> >> >> >> > not appropriate to use. One place to start would be to 
>> compare
>> >> >> >> it to
>> >> >> >> > JDBC 4 and JPA.
>> >> >> >>
>> >> >> >> We can get started with JPA:
>> >> >> >>
>> >> >> >>     * JPA is java-specific, container-based, built around a
>> >> connected
>> >> >> >>       data model and offers a complete O/R mapping for POJOs
>> >> >> >>
>> >> >> >>     * The RDB DAS is a java implementation of a language -
>> neutral
>> >> >> >>       concept (hopefully specified some day) that is
>> >> containerless,
>> >> >> >>       assumes a disconnected data model and provides a simple,
>> >> >> >> implicit
>> >> >> >>       mapping for SDO DataObjects (Dynamic or Static) to
>> >> relational
>> >> >> >> tables.
>> >> >> >>
>> >> >> >> Anything else?
>> >> >> >>
>> >> >> >> >
>> >> >> >> > Jim
>> >> >> >> >
>> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
>> >> >> >> >
>> >> >> >> >> Hi Amita
>> >> >> >> >>
>> >> >> >> >> I think we were both going on the same way, with the DAS
>> >> Service
>> >> >> >> >> sample,
>> >> >> >> >> altough i had the interface more like this, to be more
>> >> flexible :
>> >> >> >> >>
>> >> >> >> >> public interface DASService {
>> >> >> >> >>
>> >> >> >> >>    public DAS configureService(String configFile);
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >>    public DataObject executeCommand(String commandName);
>> >> >> >> >>    public DataObject execute(String newCommand);
>> >> >> >> >>    public void applyChanges(DataObject graphRoot);
>> >> >> >> >> }
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> As for having it as a sample, maybe we could defined the
>> >> >> >> DASService
>> >> >> >> >> as one
>> >> >> >> >> sample itself, and have a second version of companyWeb that
>> >> would
>> >> >> >> >> consume
>> >> >> >> >> the service, something like :
>> >> >> >> >>
>> >> >> >> >> das\samples\companyWeb
>> >> >> >> >> das\samples\dasService
>> >> >> >> >> das\samples.companyWeb.service
>> >> >> >> >>
>> >> >> >> >> or, more like BigBank
>> >> >> >> >>
>> >> >> >> >> das\samples\companyweb.Service\dasService
>> >> >> >> >> das\samples\companyweb.Service\webClient
>> >> >> >> >>
>> >> >> >> >> Or even in sampleApps...
>> >> >> >> >>
>> >> >> >> >> Toughts ?
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
>> wrote:
>> >> >> >> >>
>> >> >> >> >>>
>> >> >> >> >>> Hi ,
>> >> >> >> >>> I am also following up another thread
>> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> msg09944.html
>> >> >> >> >>> on the
>> >> >> >> >>> similar issue (JDBC stored procedure container
>> >> >> >> >>> using DAS)
>> >> >> >> >>> Besides the fact that I am actively working on the 
>> container
>> >> >> >> work,
>> >> >> >> >>> I also
>> >> >> >> >>> have tried to
>> >> >> >> >>> develop a sample based on the below discussion, following
>> >> dynamic
>> >> >> >> >>> approach.
>> >> >> >> >>>
>> >> >> >> >>> I am attaching the same here. Please take a look and give
>> your
>> >> >> >> >>> suggestions.
>> >> >> >> >>> In this, StoredProcedureService implementation has
>> >> >> >> setConfigInfo (DAS
>> >> >> >> >>> Config) and
>> >> >> >> >>> execute(Any SQL). This can be made more complete with
>> >> >> >> executeSQL(),
>> >> >> >> >>> applyChanges()
>> >> >> >> >>> etc.
>> >> >> >> >>>
>> >> >> >> >>> Can this be added to the existing set of samples?
>> >> >> >> >>>
>> >> >> >> >>> Regards,
>> >> >> >> >>> Amita
>> >> >> >> >>>
>> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >> >>> >
>> >> >> >> >>> > Luciano Resende wrote:
>> >> >> >> >>> >
>> >> >> >> >>> > > Kevin, from what I understood from your suggestion, it
>> was
>> >> >> >> >>> looking to
>> >> >> >> >>> > me
>> >> >> >> >>> > > more like exposing DAS as a service :
>> >> >> >> >>> > >
>> >> >> >> >>> > >>>   public interface RDBDASService
>> >> >> >> >>> > >>>        DataObject execute(String commandName);
>> >> >> >> >>> > >>>        DataObject executeSQL(String abitrarySQL);
>> >> >> >> >>> > >>>        void applyChanges(DataObject graphRoot);
>> >> >> >> >>> > >>>    }
>> >> >> >> >>> > >>
>> >> >> >> >>> > Yes, I am talking about exposing a DAS Service configured
>> >> >> >> with a
>> >> >> >> >>> > specific set of capabilities/commands defined in the DAS
>> >> config
>> >> >> >> >>> file.
>> >> >> >> >>> > So, if the implementation of the service interface above
>> was
>> >> >> >> >>> configured
>> >> >> >> >>> > to work with Customers they would use the service like
>> this:
>> >> >> >> >>> >
>> >> >> >> >>> >    List customers = myRDBDASService.execute
>> >> ("getAllCustomers");
>> >> >> >> >>> >    String name = customers.get(0).getString("name");
>> >> >> >> >>> >
>> >> >> >> >>> > This is not much different than the static interface you
>> >> >> >> proposed,
>> >> >> >> >>> > right?
>> >> >> >> >>> >
>> >> >> >> >>> > > And then, when a service developer defines the
>> >> >> >> AccountService,
>> >> >> >> >>> he will
>> >> >> >> >>> >
>> >> >> >> >>> > > have
>> >> >> >> >>> > > to know about yet another service, about how DAS works,
>> >> >> >> how it is
>> >> >> >> >>> > > configured, etc, etc... is that right ?
>> >> >> >> >>> > >
>> >> >> >> >>> > The abilities of the service are defined by the DAS 
>> config
>> >> >> >> file.
>> >> >> >> >>> So,
>> >> >> >> >>> > the person or tool that provides the config file must
>> >> >> >> understand
>> >> >> >> >>> how the
>> >> >> >> >>> >
>> >> >> >> >>> > RDB DAS APIs work.  There is no getting around this.
>> >> >> >> >>> >
>> >> >> >> >>> > > My proposal was going more towards allowing the service
>> >> >> >> >>> developer to
>> >> >> >> >>> > > focus
>> >> >> >> >>> > > on defining the service, and let the "declarative 
>> das" to
>> >> >> >> >>> handle the
>> >> >> >> >>> > > persistent layer....
>> >> >> >> >>> > >
>> >> >> >> >>> > The DAS config file is the declaration of an instance of
>> the
>> >> >> >> >>> DAS.  That
>> >> >> >> >>> > instance can be exposed as a dynamic or typed service/
>> >> >> >> interface.
>> >> >> >> >>> That
>> >> >> >> >>> > seems to be the main discussion we are having. 
>> Although, I
>> >> >> >> may be
>> >> >> >> >>> > missing something.
>> >> >> >> >>> >
>> >> >> >> >>> > > Also, by defining some conventions over configuration
>> >> >> >> and/or  using
>> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a 
>> stored
>> >> >> >> >>> procedure),
>> >> >> >> >>> > the
>> >> >> >> >>> > > service developer could really define a service that
>> >> >> >> interacts
>> >> >> >> >>> with a
>> >> >> >> >>> > > RDB,
>> >> >> >> >>> > > without having to code the service persistence layer.
>> >> >> >> >>> > >
>> >> >> >> >>> > There is a lot of potential for the use of annotations.
>> >> >> >> >>> >
>> >> >> >> >>> > >
>> >> >> >> >>> > > - Luciano
>> >> >> >> >>> > >
>> >> >> >> >>> > >
>> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> 
>> wrote:
>> >> >> >> >>> > >
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> The real difference between the two approaches is that
>> >> >> >> one is
>> >> >> >> >>> "Typed"
>> >> >> >> >>> > or
>> >> >> >> >>> > >> static and the other is dynamic.  I think both are
>> needed
>> >> >> >> but  was
>> >> >> >> >>> > >> suggesting that we start with dynamic since it is the
>> >> most
>> >> >> >> >>> flexible
>> >> >> >> >>> > and
>> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a 
>> static
>> >> >> >> >>> capability.
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> With either, the user does not need to know about
>> >> >> >> traditional
>> >> >> >> >>> > >> persistence frameworks.  With the dynamic approach,
>> >> however,
>> >> >> >> >>> the user
>> >> >> >> >>> > >> does need to know about the dynamic SDO API.
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> So, with the static interface the user might write:
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>     List customers = accountService.getAllCustomers();
>> >> >> >> >>> > >>     String name =
>> ((Customer)customers.get(0)).getName();
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> The equivalent dynamic API might be:
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>     List customers =
>> >> dasService.execute("getAllCustomers");
>> >> >> >> >>> > >>     String name =
>> >> ((DataObject)customers.get(0)).getString
>> >> >> >> >>> ("name");
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> The first is probably a little easier for the
>> application
>> >> >> >> >>> developer
>> >> >> >> >>> > but
>> >> >> >> >>> > >> the second is much easier for the service developer.
>> IMO,
>> >> >> >> the
>> >> >> >> >>> dynamic
>> >> >> >> >>> > >> case is the best place to start and, again, we
>> >> >> >> definitely  will
>> >> >> >> >>> want
>> >> >> >> >>> > >> support for both.
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> Thanks.
>> >> >> >> >>> > >> --
>> >> >> >> >>> > >> Kevin
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> Jeremy Boynes wrote:
>> >> >> >> >>> > >>
>> >> >> >> >>> > >> > I think this would be useful but it seems more 
>> like a
>> >> >> >> >>> traditional
>> >> >> >> >>> > >> > persistence API than what Luciano was suggesting. 
>> With
>> >> >> >> this
>> >> >> >> >>> one a
>> >> >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
>> >> >> >> strings
>> >> >> >> >>> etc.
>> >> >> >> >>> > >> > just like they would if they were using raw JDBC or
>> >> JPA.
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more
>> about
>> >> >> >> >>> expressing
>> >> >> >> >>> > >> > high-level CRUD operations as operations on a 
>> service
>> >> >> >> >>> interface:
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>    public List getAllCustomers();
>> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
>> >> >> >> accountNumber);
>> >> >> >> >>> > >> >>> }
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > which is all application level concepts rather
>> >> >> >> than  persistence
>> >> >> >> >>> > level
>> >> >> >> >>> > >> > concepts. I'd actually go a little further and put
>> that
>> >> >> >> >>> right into
>> >> >> >> >>> > >> > the service contract:
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >   public interface AccountService {
>> >> >> >> >>> > >> >     List<Customer> getAllCustomers();
>> >> >> >> >>> > >> >     Account getCustomerAccount(String 
>> accountNumber);
>> >> >> >> >>> > >> >   }
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
>> >> >> >> standardized
>> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
>> >> configuration
>> >> >> >> >>> would be
>> >> >> >> >>> > >> > needed except to add this to the logical assembly:
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >   <component name="AccountStore">
>> >> >> >> >>> > >> >     <implementation.das resource="MySQLDatabase"/>
>> >> >> >> >>> > >> >   </component>
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > With SCA's ability to translate service contracts,
>> this
>> >> >> >> >>> should be
>> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
>> >> >> >> regardless of
>> >> >> >> >>> > whether
>> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
>> >> >> >> running  on
>> >> >> >> a
>> >> >> >> >>> > Java,
>> >> >> >> >>> > >> > C++ or PHP platform.
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > The important thing here is that the client is
>> >> >> >> isolated  from
>> >> >> >> >>> how
>> >> >> >> >>> > the
>> >> >> >> >>> > >> > DAS component is provided. We could have multiple
>> >> >> >> declarative
>> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and one 
>> that
>> >> did
>> >> >> >> >>> stuff
>> >> >> >> >>> > with
>> >> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
>> >> >> >> altering
>> >> >> >> >>> the
>> >> >> >> >>> > >> > client at all/ they could switch to a custom coded
>> >> version
>> >> >> >> >>> written
>> >> >> >> >>> > in
>> >> >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > --
>> >> >> >> >>> > >> > Jeremy
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >> I would suggest that we start right away with a
>> >> RDBDAS-
>> >> >> >> based
>> >> >> >> >>> > >> >> solution.  I also think that the best place to 
>> start
>> >> >> >> would
>> >> >> >> >>> be with
>> >> >> >> >>> > >> >> an interface that is "weakly" typed.  That is, a
>> >> service
>> >> >> >> >>> interface
>> >> >> >> >>> >
>> >> >> >> >>> > >> >> in terms of dynamic SDO's.  If we go this route we
>> can
>> >> >> >> >>> avoid the
>> >> >> >> >>> > >> >> generation (by hand or otherwise) of code 
>> specific to
>> >> >> >> a new
>> >> >> >> >>> > >> >> service.  Instead, the service will be 
>> "instantiated"
>> >> >> >> based
>> >> >> >> >>> on the
>> >> >> >> >>> >
>> >> >> >> >>> > >> >> provided DAS config file.  The service interface
>> >> >> >> might  look
>> >> >> >> >>> like
>> >> >> >> >>> > >> this:
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>    public interface RDBDASService
>> >> >> >> >>> > >> >>        DataObject execute(String commandName);
>> >> >> >> >>> > >> >>        DataObject executeSQL(String abitrarySQL);
>> >> >> >> >>> > >> >>        void applyChanges(DataObject graphRoot);
>> >> >> >> >>> > >> >>    }
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >> So, depending on the config file used to
>> >> instantiate the
>> >> >> >> >>> service,
>> >> >> >> >>> > >> >> this interface could be used to return Customers/
>> >> >> >> Accounts or
>> >> >> >> >>> > >> >> Toasters.  In fact, a lot could be achieved with no
>> >> >> >> >>> > configuration  at
>> >> >> >> >>> > >> >> all by restricting use to:  DataObject
>> >> executeSQL(String
>> >> >> >> >>> > >> abitrarySQL);
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >> I expand a bit here: 
>> http://mail-archives.apache.org/
>> >> >> >> >>> mod_mbox/ws-
>> >> >> >> >>> > >> >>
>> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >> Once this was working it should be 
>> straightforward to
>> >> >> >> build
>> >> >> >> >>> more
>> >> >> >> >>> > >> >> strongly typed services and possible put together
>> some
>> >> >> >> >>> generation
>> >> >> >> >>> > >> >> tooling.  We could also start looking at support 
>> for
>> a
>> >> >> >> more
>> >> >> >> >>> > RESTFul
>> >> >> >> >>> > >> >> interface.
>> >> >> >> >>> > >> >> --
>> >> >> >> >>> > >> >> Kevin
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >> Luciano Resende wrote:
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>> Recently, people have been starting to talk about
>> >> >> >> better DAS
>> >> >> >> >>> > >> >>> integration
>> >> >> >> >>> > >> >>> with DAS, and below are some threads on the 
>> subject
>> :
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> msg08833.html
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> >> msg08923.html
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> 
>> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>> >> >> >> >>> msg09715.html
>> >> >> >> >>> >
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make 
>> sure
>> >> >> >> what  I'm
>> >> >> >> >>> > >> >>> saying is not
>> >> >> >> >>> > >> >>> yet available on SCA today.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Today, defining a service to work with a 
>> relational
>> >> >> >> >>> database, you
>> >> >> >> >>> > >> >>> will need
>> >> >> >> >>> > >> >>> to code the persistence side of the service where
>> >> CRUD
>> >> >> >> >>> operations
>> >> >> >> >>> > >> >>> to the
>> >> >> >> >>> > >> >>> database will be done.
>> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
>> coding
>> >> >> >> the
>> >> >> >> >>> CRUD
>> >> >> >> >>> > >> >>> operations on
>> >> >> >> >>> > >> >>> the persistence layer would be avoided as much as
>> >> >> >> possible.
>> >> >> >> >>> > >> >>> The idea would be to have a more "declarative DAS"
>> >> when
>> >> >> >> >>> defining
>> >> >> >> >>> > SCA
>> >> >> >> >>> > >> >>> Services, so you would either use some Annotations
>> >> >> >> or  SCDL
>> >> >> >> to
>> >> >> >> >>> > >> have  the
>> >> >> >> >>> > >> >>> "declarative DAS"  configuration inside it.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> I was thinking on something like....
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> SCDL Definition would look something like this :
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> <component name="AccountDataService">
>> >> >> >> >>> > >> >>>   <interface.java
>> >> >> >> >>> > >> >>>
>> >> >> >> class="bigbank.account.services.account.AccountService"/>
>> >> >> >> >>> > >> >>>   <implementation.das="dasConfig.properties"
>> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>> >> >> >> >>> > >> >>> </component>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> The AccountService Interface would look like this
>> >> >> >> (missing
>> >> >> >> >>> any
>> >> >> >> >>> > SCA
>> >> >> >> >>> > >> >>> annotations):
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>    public List getAllCustomers();
>> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
>> >> >> >> accountNumber);
>> >> >> >> >>> > >> >>> }
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> The DAS config would look like this, and would
>> >> have the
>> >> >> >> >>> > definition
>> >> >> >> >>> > >> >>> for the
>> >> >> >> >>> > >> >>> "all companies" command.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> <Config ...>
>> >> >> >> >>> > >> >>>    ...
>> >> >> >> >>> > >> >>>   <ConnectionInfo dataSource="java:comp/env/jdbc/
>> >> >> >> bigbank"/>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>   <Command name="getAllCustomers" SQL="select * 
>> from
>> >> >> >> >>> CUSTOMERS"
>> >> >> >> >>> > >> >>> kind="Select"/>
>> >> >> >> >>> > >> >>>   <Command name="getCustomerAccount" SQL="SELECT
>> >> >> >> >>> accountNumber,
>> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
>> >> >> >> accountNumber = ?"
>> >> >> >> >>> > >> >>> kind="Select" />
>> >> >> >> >>> > >> >>>   ...
>> >> >> >> >>> > >> >>> </Config>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
>> >> >> >> >>> > >> >>>   - If a DAS config file is provided, based on the
>> >> >> >> >>> > SCDL  definition,
>> >> >> >> >>> > >> we
>> >> >> >> >>> > >> >>> would look for "DAS command" based on the name of
>> the
>> >> >> >> getter
>> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
>> >> >> >> command)
>> >> >> >> >>> > >> >>>   - Otherwise, we would try to do a map 
>> directly to
>> a
>> >> >> >> >>> > >> stored  procedure
>> >> >> >> >>> > >> >>>   - We could also have a way to force the 
>> mapping by
>> >> >> >> using
>> >> >> >> >>> > >> annotation
>> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Mapping between method parameter and command
>> >> parameter
>> >> >> >> >>> > >> >>>   - We would need to define a method for 
>> mapping the
>> >> >> >> method
>> >> >> >> >>> > >> >>> parameters to
>> >> >> >> >>> > >> >>> the query paramters either based on position (
>> >> e.gfirst
>> >> >> >> >>> method
>> >> >> >> >>> > >> >>> parameter
>> >> >> >> >>> > >> >>> maps to the first command paramter), or we 
>> would do
>> >> some
>> >> >> >> >>> > mapping  by
>> >> >> >> >>> > >> >>> name
>> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Note:
>> >> >> >> >>> > >> >>>   - A SCDL connection information would 
>> override the
>> >> DAS
>> >> >> >> >>> Config
>> >> >> >> >>> > file
>> >> >> >> >>> > >> >>> connection information.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Benefits
>> >> >> >> >>> > >> >>>   - It's All about simplicity and easy of use
>> >> >> >> >>> > >> >>>   - This would allow a user to define a service
>> >> without
>> >> >> >> >>> having to
>> >> >> >> >>> >
>> >> >> >> >>> > >> >>> explicitly having to code any Data Access related
>> >> code.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Implementation approaches
>> >> >> >> >>> > >> >>>   - Utilizing DAS : This approach would start from
>> >> the
>> >> >> >> >>> current
>> >> >> >> >>> > >> >>> Tuscany DAS
>> >> >> >> >>> > >> >>> implementation, where functionality would be 
>> already
>> >> >> >> >>> > available,  but
>> >> >> >> >>> > >> >>> the
>> >> >> >> >>> > >> >>> service implementation would be tied to SDO and 
>> RDB
>> >> >> >> as this
>> >> >> >> >>> > is  what
>> >> >> >> >>> > >> >>> DAS
>> >> >> >> >>> > >> >>> supports today.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>   - Start simple and grow : We could start simple,
>> by
>> >> >> >> >>> having a
>> >> >> >> >>> > >> simple
>> >> >> >> >>> > >> >>> implementation based on JDBC and would return some
>> >> >> >> simple
>> >> >> >> >>> > >> >>> collection as a
>> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
>> >> could
>> >> >> >> >>> give us
>> >> >> >> >>> > a
>> >> >> >> >>> > >> >>> quick
>> >> >> >> >>> > >> >>> start to flush implementation details and get a
>> >> proven
>> >> >> >> >>> design,
>> >> >> >> >>> > and
>> >> >> >> >>> > >> >>> this
>> >> >> >> >>> > >> >>> could get evolved to use a DAS that would support
>> >> >> >> multiple
>> >> >> >> >>> > backends
>> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
>> >> >> >> non- SDO
>> >> >> >> >>> types
>> >> >> >> >>> > >> as a
>> >> >> >> >>> > >> >>> command
>> >> >> >> >>> > >> >>> result.
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> Toughts ?
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> - Luciano
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net>
>> >> wrote:
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> Great.  I would like to help with this.  I have
>> been
>> >> >> >> >>> thinking
>> >> >> >> >>> > for
>> >> >> >> >>> > >> >>>> awhile
>> >> >> >> >>> > >> >>>> about how to best integrate the RDB DAS within 
>> SCA.
>> >> >> >> For
>> >> >> >> >>> > >> example,  the
>> >> >> >> >>> > >> >>>> current BBank scenario uses the RDB DAS as a
>> utility
>> >> >> >> but it
>> >> >> >> >>> > >> would be
>> >> >> >> >>> > >> >>>> nice if it could "wire in" a RDB DAS service 
>> or be
>> >> >> >> >>> injected with
>> >> >> >> >>> > a
>> >> >> >> >>> > >> >>>> configured DAS.  Another thing we want to
>> eventually
>> >> >> >> >>> explore is
>> >> >> >> >>> > >> >>>> exposing
>> >> >> >> >>> > >> >>>> a DAS as REST-oriented services.  As we have seen
>> >> >> >> from the
>> >> >> >> >>> > parent
>> >> >> >> >>> > >> >>>> thread
>> >> >> >> >>> > >> >>>> there are almost too many possible approaches.
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a service
>> >> and
>> >> >> >> >>> create a
>> >> >> >> >>> > new
>> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas).  The
>> >> main
>> >> >> >> >>> reason
>> >> >> >> >>> > has
>> >> >> >> >>> > >> >>>> to do
>> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
>> >> >> >> >>> > Jeremy  mentioned
>> >> >> >> >>> > >> >>>> which
>> >> >> >> >>> > >> >>>> is all about creating data access services
>> >> >> >> >>> declaratively.  A new
>> >> >> >> >>> > >> >>>> component type and a service that we build by 
>> hand
>> >> >> >> would be
>> >> >> >> >>> > a  good
>> >> >> >> >>> > >> >>>> step
>> >> >> >> >>> > >> >>>> in this direction.
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
>> >> >> >> interface  like
>> >> >> >> >>> > this:
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>>     public interface RDBDASService
>> >> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
>> >> >> >> >>> > >> >>>>         DataObject execute(String commandName);
>> >> >> >> >>> > >> >>>>         DataObject executeSQL(String 
>> abitrarySQL);
>> >> >> >> >>> > >> >>>>     }
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> The service would be initialized with an optional
>> >> >> >> RDB DAS
>> >> >> >> >>> > >> config  file
>> >> >> >> >>> > >> >>>> that defines connection properties, a set of
>> >> commands,
>> >> >> >> >>> etc.  So,
>> >> >> >> >>> > >> >>>> different services implementing the same 
>> interface
>> >> >> >> could be
>> >> >> >> >>> > >> >>>> initialized
>> >> >> >> >>> > >> >>>> from separate config files.
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> Eventually, we might want to build services like
>> >> this:
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>>     public interface Customers_RDBDASService
>> >> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
>> >> >> >> >>> > >> >>>>         DataObject getAllCustomersWithLastName
>> >> (String
>> >> >> >> >>> > lastName);
>> >> >> >> >>> > >> >>>>         DataObject getAll CustomersAndOrdersForID
>> >> (int
>> >> >> >> >>> > customerId);
>> >> >> >> >>> > >> >>>>     }
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> But, for this to be very useful would probably
>> >> require
>> >> >> >> >>> some code
>> >> >> >> >>> > >> >>>> generation tooling.
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> Thoughts?
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> --Kevin
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> Luciano Resende wrote:
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
>> >> >> >> declarative
>> >> >> >> >>> > DAS  and
>> >> >> >> >>> > >> >>>> will be
>> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki 
>> soon...
>> >> >> >> >>> > >> >>>> >
>> >> >> >> >>> > >> >>>> > - Luciano
>> >> >> >> >>> > >> >>>> >
>> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
>> >> >> >> wrote:
>> >> >> >> >>> > >> >>>> >
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >> On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
>> >> >> >> >>> > >> >>>> >> >> This sounds like having cake, eating it, 
>> and
>> >> also
>> >> >> >> >>> > being  able
>> >> >> >> >>> > >> to
>> >> >> >> >>> > >> >>>> >> >> give it to a friend :-) We provide the
>> >> >> >> flexibility  for
>> >> >> >> >>> > users:
>> >> >> >> >>> > >> >>>> >> >> 1) to access infrastructure services 
>> through
>> >> >> >> >>> properties
>> >> >> >> >>> > >> >>>> >> > Yes for things like JPA, JDBC, etc.
>> >> >> >> >>> > >> >>>> >> >> 2) to reference infrastructure services
>> >> through
>> >> >> >> >>> > inclusion  in
>> >> >> >> >>> > >> >>>> their
>> >> >> >> >>> > >> >>>> >> >> assembly
>> >> >> >> >>> > >> >>>> >> > If we do 1 I don't think we should do 2 
>> (that
>> >> >> >> >>> doesn't stop
>> >> >> >> >>> > >> >>>> someone
>> >> >> >> >>> > >> >>>> >> > from extending Tuscany to do it though). See
>> my
>> >> >> >> >>> comments
>> >> >> >> >>> > >> below.
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
>> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I 
>> think we
>> >> >> >> >>> > should  welcome
>> >> >> >> >>> > >> it
>> >> >> >> >>> > >> >>>> >> like we would any other contribution.
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >> >> 3) to access data through an application
>> >> >> >> service with
>> >> >> >> >>> > >> >>>> declarative
>> >> >> >> >>> > >> >>>> >> >> implementation by DAS
>> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks 
>> radar.
>> >> >> >> >>> > >> >>>> >> --
>> >> >> >> >>> > >> >>>> >> Jeremy
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>> >>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >>
>> >> >> >> >>>
>> >> >> >>
>> >> --------------------------------------------------------------------
>> >> >> >> >>> > >> -
>> >> >> >> >>> > >> >>>> >> 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
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>>
>> >> >> >> >>> > >> >>>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> > >> >>
>> >> >> >> >>> >
>> >> >> >> >>>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >>> > >> >> 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
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >> >
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>> > >>
>> >> >> >> >>>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >>> > >> 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
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>>
>> >> >> >> >>>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> >>> 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
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> ---------------------------------------------------------------------
>> >> >> >> 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
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>



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

Re: Declarative DAS, was Re: Modeling the RDB DAS in SCA

[Amita Vadhavkar <am...@gmail.com>]

Hi Kevin,
Thanks a lot for the comments. I have posted the code and doc on JIRA-904
for the container work. Also, am most likely missing something in the
database
connection portion. Would like to discuss with you.

Will you please provide feedback on JIRA-904 attachments?

I am checking with Luciano for a convenient date/time when we can chat,
would
be great if you can also join. I am in IST timezone.

Regards,
Amita

On 11/6/06, Kevin Williams <ke...@qwest.net> wrote:
>
> Hi Amita,
> This is looking good.  Some comments inline:
>
> Amita Vadhavkar wrote:
>
> > Hi,
> > I am trying to create a container for DAS-SCA too (not just for stored
> > procedure) and will be able to send a working code in ML over the
> > weekend.
> >
> > Below is summary of what I got so far from the previous mail
> > discussions and
> > some questions.
> >
> >
> > The integration between DAS and SCA can happen at application level as
> > service or at container level.
> >
> >
> >
> > 2 different possible approaches –
> >
> > static – e.g. getAllCustomers
> >
> > dynamic – e.g. execute("all customers");
> >
> >
> >
> > For application level service – it is the sample *
> > sample-StoredProcedureService.jar*  or what Luciano is providing in more
> > details, is an example.  In *sample-StoredProcedureService.jar* example
> > dynamic approach is followed
> >
> >
> >
> > For container approach – again static or dynamic approach can be
> > followed.
> > For static – it's like providing service for getAllCompanies(),
> > getAllCustomers() etc. whereas for dynamic its like execute(command)
> > where
> > command can be "getAllCompanies", "getAllCustomers". Etc.
> >
> >
> >
> >            I am working on a container implementation where dynamic
> > approach is followed.
> >
> If I understand correctly, the container approach will provide the
> tightest integration with SCA and make things easier for end-users.  Do
> you agree?
>
> >
> >
> > There are 2 places where extensibility is required –
> >
> > 1)      for providing different data access mechanisms. i.e. today
> > there is
> > RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the
> > scdl will
> > be same, but the exampleconfig.xml will change.
> >
> > In the container I am working on - Scdl has a new tag
> >
> > Scdl has a new tag
> >  <da:implementation.da script="customersOrders/CustomersOrders.xml"
> > dataAccessType="rdb"/>
> >
> >
> >
> > Here, dataAccessType – is the key which tells whether it's RDB or
> > something
> > else. And the xml script provides the connection and data store details.
> >
> >
> >
> > 2)      for RDB-DAS – providing support for different databases (this
> > portion should be part of DAS and  not SCA.) In the current container
> > I am
> > working on it is provided as a package -
> > org.apache.tuscany.container.dataaccessshelper package  - which should
> > finally go into DAS codeline(?).
> >
> >
> Currently, there are two ways to specify a particular database:  first,
> the user can pass a JDBC Connection to the DAS Factory when creating a
> DAS instance.  The second is that a DataSource can be specified in the
> DAS Config xml file in which case the DAS is responsible for getting the
> connection.
>
> >
> >
> >
> > For static approach we may need some code generation tooling.
>
> Right.  That is why I think it best to start with dynamic.  But, we will
> want static support as well.
>
> > Also could not
> > understand how this can be merged into RESTful interfaces. (this was
> > mentioned in some mail conversation)
> >
> >
> >
> > Regards,
> >
> > Amita
> >
> >
> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >>
> >> Luciano Resende wrote:
> >>
> >> > Comments in-line...
> >> >
> >> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
> >> >
> >> >>
> >> >>
> >> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
> >> >>
> >> >> > Hi,
> >> >> >
> >> >> > I would also like to understand this a little better ... here I am
> >> >> > thinking
> >> >> > aloud and hope the others will help in getting my persceptions
> >> >> > right...
> >> >> >
> >> >> > I guess firstly it is a question of how or where we want to
> >> >> > position 'DAS
> >> >> > Integration' in SCA.  Is is something we want to integrate as the
> >> >> > Application Layer, which I understand is what Amita is trying
> >> >> > presently and
> >> >> > which Jim refers to as component implementation.   In this option
> >> >> > we get to
> >> >> > do some sort of a service wrapper to DAS and then it becomes a
> >> >> > demonstration
> >> >> > of two Tuscany subprojects integrating at application level.
> >> >> >
> >> >
> >> >
> >> >
> >> > Yes, I think we have space to position DAS both ways, and integrating
> >> > in the
> >> > application layer by exposing DAS as a service would be a very easy
> >> and
> >> > quick, this could be exposed as a sample app, and could show we are
> >> > working
> >> > on getting a better integration between DAS and SCA
> >> >
> >> >
> >> >> Or do we want to position DAS at the infrastructure layer as another
> >> >> > extension type (either container or binding).  I guess this is
> >> >> > where Ant
> >> >> > started this - proposing a JDBC container / binding for component
> >> >> > implementation in StoredProcedures.
> >> >> I was thinking a DAS was a way to declaratively model heterogeneous
> >> >> data as a service and offer a mechanism for remoting that data. In
> >> >> other words, it provided the ability for an application to perform
> >> >> CRUD using a high-level contract (interface) and having those
> >> >> operations take place across a service network.  How this is hooked
> >> >> into the SCA container is probably best done as an extension type,
> >> >> i.e. someone could specify:
> >> >>
> >> >> <component name="Foo">
> >> >>         <implementation.das>
> >> >>                 <interface.java ....>
> >> >>         </implementation.das>
> >> >> </component>
> >> >
> >> >
> >> >
> >> >
> >> > Yes, this goes back to the way I was thinking on my original
> proposal.
> >> >
> >> >
> >> >> If this is the path we should take
> >> >> > then we probably have to think beyond DAS - to something more
> >> >> > general - of
> >> >> > which DAS is just a special case.  I suppose this is what Jim has
> >> also
> >> >> > suggested in trying to explore other persistence mechanisms.
> >> >> >
> >> >> This may be the crux of the confusion. I was thinking DAS provides a
> >> >> general mechanism for accessing heterogeneous data and is only right
> >> >> now tied to SQL because of resource constraints (i.e. we have to
> >> >> start somewhere). Ultimately, DAS should provide the infrastructure
> >> >> for dealing with multiple, varied data stores and mechanisms for
> >> >> querying across them. In other words, I guess I am saying DAS should
> >> >> be the general solution (declarative and heterogeneous) since if it
> >> >> is only a programmatic way to access relational data then its value
> >> >> is less clear in comparison to things such as JDBC 4 or JPA.
> >> >
> >> >
> >> >
> >> >
> >> > Yes, the current status of DAS implementation is RDB only. I would
> say
> >> > that,
> >> > in the future, I'd like to see a heterogeneous DAS that would give
> you
> >> > access to different data stores, and probably support non-SDO types
> as
> >> > well.
> >> >
> >> >> I too feel that this is something that must be done as an extension
> >> >> > type -
> >> >> > but yet to get my hands on the general scheme of things that DAS
> >> >> > can slip
> >> >> > into. Infact the other thread where Jeremy has taken forward a
> >> >> > proposal to
> >> >> > the specs group on resources tempts me to think that there is
> going
> >> >> > to be
> >> >> > something in that which we can leverage from.
> >> >> >
> >> >> I think resources are orthogonal as they are about a component
> >> >> implementation's contract with its container. Declarative data
> >> >> services on the other hand are about application constructs that can
> >> >> be wired to.
> >> >>
> >> >> > I hope to get a better understanding this as we go along in this
> >> >> > thread :)
> >> >> >
> >> >> Me too :-) As soon as I have trouble explaining technologies to .NET
> >> >> people and they say "you Unix/Java people are at it again with a
> >> >> thousand ways to do the same exact thing" it causes me to think that
> >> >> maybe we need to clarify our message.
> >> >
> >> >
> >> >
> >> >
> >> > If we all think it would be useful, I could try to summarize the
> >> > thread on
> >> > the wiki with a more clean proposal incorporating all your feedback ,
> >> > what
> >> > you guys think ?
> >>
> >> Yes.  Great idea.
> >>
> >> >
> >> >
> >> > Jim
> >> >
> >> >> > Thanks
> >> >> >
> >> >> > - Venkat
> >> >> >
> >> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >>
> >> >> >> Jim Marino wrote:
> >> >> >>
> >> >> >> > When I first read the thread on this, I thought the DAS service
> >> >> >> would
> >> >> >> > be a component extension type (e.g. analogous to a
> >> >> >> > implementation.java or implementation.ejb) and not a component
> >> >> >> > implementation type, which would allow for dynamic and
> >> eventually
> >> >> >> > declarative configuration styles.
> >> >> >>
> >> >> >> I have not very familiar with the terminology so I am not sure
> >> what
> >> a
> >> >> >> "component extension type" is.  But, I do think we eventually
> want
> >> >> >> "implementation.rdbdas".  Wouldn't this be a new implementation
> >> type?
> >> >> >>
> >> >> >> It looks like Amita chose to start with a POJO.  I notice the use
> >> >> >> of "
> >> >> >> implementation.java".
> >> >> >>
> >> >> >> > Either way, though, I am curious as  to why
> >> >> >> >
> >> >> >> > public DAS configureService(String configFile);
> >> >> >> >
> >> >> >> > exists as part of the service definition? If the DAS service
> >> was a
> >> >> >> > component extension type, it could be handled as part of the
> >> >> >> > application bootstrap. If the DAS service was a component
> >> >> >> > implementation type, the configuration file URI could be passed
> >> >> >> in as
> >> >> >> > a property and then processed in an initializer method
> decorated
> >> by
> >> >> >> > the SCA @Init annotation. In the latter case, if the
> >> implementation
> >> >> >> > of DASService thread-safe (hopefully it is since configuration
> >> >> >> would
> >> >> >> > seem to be a heavyweight operation), then I would make the
> >> >> >> component
> >> >> >> > module scoped to avoid initialization overhead on every
> >> resolution.
> >> >> >>
> >> >> >> >
> >> >> >> > In both approaches (extension vs. implementation type), having
> >> >> >> > configuration exposed to the application doesn't quite feel
> >> right,
> >> >> >> > since that is what DI tries to externalize.
> >> >> >>
> >> >> >> I agree.  The configuration should be part of the
> >> initialization and
> >> >> >> should use SCA patterns to do this.  I think that Amita meant
> >> to use
> >> >> >> eventually use a component property for the DAS config info but
> >> >> >> started
> >> >> >> with a method.
> >> >> >>
> >> >> >> >
> >> >> >> > Also, I was thinking that in having this a component extension
> >> >> >> type,
> >> >> >> > the service interfaces returned from a resolution could include
> >> the
> >> >> >> > dynamic one described below or static ones people have
> >> mentioned.
> >> I
> >> >> >> > guess it is best to start with the easier-to-implement part
> >> >> >> first and
> >> >> >> > support the dynamic interface.
> >> >> >> >
> >> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
> >> >> >> > understand what DAS provides in relation to other persistence
> >> >> >> > technologies. Outside of the Java world, Microsoft is promoting
> >> >> >> LINQ
> >> >> >> > which is really interesting, and it would be informative to
> >> compare
> >> >> >> > the goals of DAS with that approach (there are obvious
> >> differences
> >> >> >> > such as having the query language a strongly-typed part of the
> >> >> >> > programming language, e.g. C#, and LINQ's use of closures).
> >> >> >> >
> >> >> >> > In contrasting DAS to O-R technologies, I see the primary use
> >> cases
> >> >> >> > for the former being a quick way to issue a query that may be
> >> >> >> > executed against *heterogeneous* data stores and have that data
> >> >> >> flow
> >> >> >> > remotely or to a client that is not necessarily Java-based. One
> >> key
> >> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
> >> >> >> (Hibernate
> >> >> >> > and JPA are about as easy):
> >> >> >> >
> >> >> >> IMO the primary use case for DAS is an application that is SDO-
> >> >> >> centric
> >> >> >> and is taking advantage of its disconnected capabilities.  The
> RDB
> >> >> >> DAS
> >> >> >> is built to work with SDO and uses the change summary to drive
> >> >> >> changes
> >> >> >> made to a disconnected data graph back to some store.  This is
> not
> >> to
> >> >> >> say that a relational DAS could not be built on top of JPA, in
> >> fact,
> >> >> >> this might be a very useful thing to do.  The implementation we
> >> >> >> currently have provides a very straightforward implicit mapping
> >> from
> >> >> >> DataObjects to Tables.  If more capable mapping is needed then it
> >> >> >> makes
> >> >> >> sense to use the JPA-defined technology and artifacts.  A
> modified
> >> >> >> Entity manager might be needed to take advantage of SDO's change
> >> >> >> summary.
> >> >> >>
> >> >> >> >
> >> >> >> > public interface CustomerDao extends BaseQuery {
> >> >> >> >     @Select("select * from customers where city = ?1")
> >> >> >> >     DataSet<Customer> findCustomersFrom(String city);
> >> >> >> > }
> >> >> >> >
> >> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
> >> >> >> > (CustomerDao.class, datasource);
> >> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
> >> >> >> >
> >> >> >> >
> >> >> >> > The other key is remote data and change lists.  I think there
> >> are
> >> >> >> > (literally) about a thousand ways that already exist to
> >> handle the
> >> >> >> > "local" data case. For change lists, interop with ADO.NET's
> >> change
> >> >> >> > summary facilities would be interesting.
> >> >> >>
> >> >> >> I agree.  Also, it looks like Xcalia may have a similar thought:
> >> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
> >> >> >>
> >> >> >> >
> >> >> >> > I'm playing devil's advocate a bit with DAS, but I think it is
> >> >> >> > important we have a clear statement as to when it is
> appropriate
> >> >> >> and
> >> >> >> > not appropriate to use. One place to start would be to compare
> >> >> >> it to
> >> >> >> > JDBC 4 and JPA.
> >> >> >>
> >> >> >> We can get started with JPA:
> >> >> >>
> >> >> >>     * JPA is java-specific, container-based, built around a
> >> connected
> >> >> >>       data model and offers a complete O/R mapping for POJOs
> >> >> >>
> >> >> >>     * The RDB DAS is a java implementation of a language -
> neutral
> >> >> >>       concept (hopefully specified some day) that is
> >> containerless,
> >> >> >>       assumes a disconnected data model and provides a simple,
> >> >> >> implicit
> >> >> >>       mapping for SDO DataObjects (Dynamic or Static) to
> >> relational
> >> >> >> tables.
> >> >> >>
> >> >> >> Anything else?
> >> >> >>
> >> >> >> >
> >> >> >> > Jim
> >> >> >> >
> >> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
> >> >> >> >
> >> >> >> >> Hi Amita
> >> >> >> >>
> >> >> >> >> I think we were both going on the same way, with the DAS
> >> Service
> >> >> >> >> sample,
> >> >> >> >> altough i had the interface more like this, to be more
> >> flexible :
> >> >> >> >>
> >> >> >> >> public interface DASService {
> >> >> >> >>
> >> >> >> >>    public DAS configureService(String configFile);
> >> >> >> >
> >> >> >> >
> >> >> >> >>    public DataObject executeCommand(String commandName);
> >> >> >> >>    public DataObject execute(String newCommand);
> >> >> >> >>    public void applyChanges(DataObject graphRoot);
> >> >> >> >> }
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> As for having it as a sample, maybe we could defined the
> >> >> >> DASService
> >> >> >> >> as one
> >> >> >> >> sample itself, and have a second version of companyWeb that
> >> would
> >> >> >> >> consume
> >> >> >> >> the service, something like :
> >> >> >> >>
> >> >> >> >> das\samples\companyWeb
> >> >> >> >> das\samples\dasService
> >> >> >> >> das\samples.companyWeb.service
> >> >> >> >>
> >> >> >> >> or, more like BigBank
> >> >> >> >>
> >> >> >> >> das\samples\companyweb.Service\dasService
> >> >> >> >> das\samples\companyweb.Service\webClient
> >> >> >> >>
> >> >> >> >> Or even in sampleApps...
> >> >> >> >>
> >> >> >> >> Toughts ?
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com>
> wrote:
> >> >> >> >>
> >> >> >> >>>
> >> >> >> >>> Hi ,
> >> >> >> >>> I am also following up another thread
> >> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> msg09944.html
> >> >> >> >>> on the
> >> >> >> >>> similar issue (JDBC stored procedure container
> >> >> >> >>> using DAS)
> >> >> >> >>> Besides the fact that I am actively working on the container
> >> >> >> work,
> >> >> >> >>> I also
> >> >> >> >>> have tried to
> >> >> >> >>> develop a sample based on the below discussion, following
> >> dynamic
> >> >> >> >>> approach.
> >> >> >> >>>
> >> >> >> >>> I am attaching the same here. Please take a look and give
> your
> >> >> >> >>> suggestions.
> >> >> >> >>> In this, StoredProcedureService implementation has
> >> >> >> setConfigInfo (DAS
> >> >> >> >>> Config) and
> >> >> >> >>> execute(Any SQL). This can be made more complete with
> >> >> >> executeSQL(),
> >> >> >> >>> applyChanges()
> >> >> >> >>> etc.
> >> >> >> >>>
> >> >> >> >>> Can this be added to the existing set of samples?
> >> >> >> >>>
> >> >> >> >>> Regards,
> >> >> >> >>> Amita
> >> >> >> >>>
> >> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
> >> >> >> >>> >
> >> >> >> >>> > Luciano Resende wrote:
> >> >> >> >>> >
> >> >> >> >>> > > Kevin, from what I understood from your suggestion, it
> was
> >> >> >> >>> looking to
> >> >> >> >>> > me
> >> >> >> >>> > > more like exposing DAS as a service :
> >> >> >> >>> > >
> >> >> >> >>> > >>>   public interface RDBDASService
> >> >> >> >>> > >>>        DataObject execute(String commandName);
> >> >> >> >>> > >>>        DataObject executeSQL(String abitrarySQL);
> >> >> >> >>> > >>>        void applyChanges(DataObject graphRoot);
> >> >> >> >>> > >>>    }
> >> >> >> >>> > >>
> >> >> >> >>> > Yes, I am talking about exposing a DAS Service configured
> >> >> >> with a
> >> >> >> >>> > specific set of capabilities/commands defined in the DAS
> >> config
> >> >> >> >>> file.
> >> >> >> >>> > So, if the implementation of the service interface above
> was
> >> >> >> >>> configured
> >> >> >> >>> > to work with Customers they would use the service like
> this:
> >> >> >> >>> >
> >> >> >> >>> >    List customers = myRDBDASService.execute
> >> ("getAllCustomers");
> >> >> >> >>> >    String name = customers.get(0).getString("name");
> >> >> >> >>> >
> >> >> >> >>> > This is not much different than the static interface you
> >> >> >> proposed,
> >> >> >> >>> > right?
> >> >> >> >>> >
> >> >> >> >>> > > And then, when a service developer defines the
> >> >> >> AccountService,
> >> >> >> >>> he will
> >> >> >> >>> >
> >> >> >> >>> > > have
> >> >> >> >>> > > to know about yet another service, about how DAS works,
> >> >> >> how it is
> >> >> >> >>> > > configured, etc, etc... is that right ?
> >> >> >> >>> > >
> >> >> >> >>> > The abilities of the service are defined by the DAS config
> >> >> >> file.
> >> >> >> >>> So,
> >> >> >> >>> > the person or tool that provides the config file must
> >> >> >> understand
> >> >> >> >>> how the
> >> >> >> >>> >
> >> >> >> >>> > RDB DAS APIs work.  There is no getting around this.
> >> >> >> >>> >
> >> >> >> >>> > > My proposal was going more towards allowing the service
> >> >> >> >>> developer to
> >> >> >> >>> > > focus
> >> >> >> >>> > > on defining the service, and let the "declarative das" to
> >> >> >> >>> handle the
> >> >> >> >>> > > persistent layer....
> >> >> >> >>> > >
> >> >> >> >>> > The DAS config file is the declaration of an instance of
> the
> >> >> >> >>> DAS.  That
> >> >> >> >>> > instance can be exposed as a dynamic or typed service/
> >> >> >> interface.
> >> >> >> >>> That
> >> >> >> >>> > seems to be the main discussion we are having. Although, I
> >> >> >> may be
> >> >> >> >>> > missing something.
> >> >> >> >>> >
> >> >> >> >>> > > Also, by defining some conventions over configuration
> >> >> >> and/or  using
> >> >> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
> >> >> >> >>> procedure),
> >> >> >> >>> > the
> >> >> >> >>> > > service developer could really define a service that
> >> >> >> interacts
> >> >> >> >>> with a
> >> >> >> >>> > > RDB,
> >> >> >> >>> > > without having to code the service persistence layer.
> >> >> >> >>> > >
> >> >> >> >>> > There is a lot of potential for the use of annotations.
> >> >> >> >>> >
> >> >> >> >>> > >
> >> >> >> >>> > > - Luciano
> >> >> >> >>> > >
> >> >> >> >>> > >
> >> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
> >> >> >> >>> > >
> >> >> >> >>> > >>
> >> >> >> >>> > >> The real difference between the two approaches is that
> >> >> >> one is
> >> >> >> >>> "Typed"
> >> >> >> >>> > or
> >> >> >> >>> > >> static and the other is dynamic.  I think both are
> needed
> >> >> >> but  was
> >> >> >> >>> > >> suggesting that we start with dynamic since it is the
> >> most
> >> >> >> >>> flexible
> >> >> >> >>> > and
> >> >> >> >>> > >> seems to be a reasonable stepping stone towards a static
> >> >> >> >>> capability.
> >> >> >> >>> > >>
> >> >> >> >>> > >> With either, the user does not need to know about
> >> >> >> traditional
> >> >> >> >>> > >> persistence frameworks.  With the dynamic approach,
> >> however,
> >> >> >> >>> the user
> >> >> >> >>> > >> does need to know about the dynamic SDO API.
> >> >> >> >>> > >>
> >> >> >> >>> > >> So, with the static interface the user might write:
> >> >> >> >>> > >>
> >> >> >> >>> > >>     List customers = accountService.getAllCustomers();
> >> >> >> >>> > >>     String name =
> ((Customer)customers.get(0)).getName();
> >> >> >> >>> > >>
> >> >> >> >>> > >> The equivalent dynamic API might be:
> >> >> >> >>> > >>
> >> >> >> >>> > >>     List customers =
> >> dasService.execute("getAllCustomers");
> >> >> >> >>> > >>     String name =
> >> ((DataObject)customers.get(0)).getString
> >> >> >> >>> ("name");
> >> >> >> >>> > >>
> >> >> >> >>> > >> The first is probably a little easier for the
> application
> >> >> >> >>> developer
> >> >> >> >>> > but
> >> >> >> >>> > >> the second is much easier for the service developer.
> IMO,
> >> >> >> the
> >> >> >> >>> dynamic
> >> >> >> >>> > >> case is the best place to start and, again, we
> >> >> >> definitely  will
> >> >> >> >>> want
> >> >> >> >>> > >> support for both.
> >> >> >> >>> > >>
> >> >> >> >>> > >> Thanks.
> >> >> >> >>> > >> --
> >> >> >> >>> > >> Kevin
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >> Jeremy Boynes wrote:
> >> >> >> >>> > >>
> >> >> >> >>> > >> > I think this would be useful but it seems more like a
> >> >> >> >>> traditional
> >> >> >> >>> > >> > persistence API than what Luciano was suggesting. With
> >> >> >> this
> >> >> >> >>> one a
> >> >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
> >> >> >> strings
> >> >> >> >>> etc.
> >> >> >> >>> > >> > just like they would if they were using raw JDBC or
> >> JPA.
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more
> about
> >> >> >> >>> expressing
> >> >> >> >>> > >> > high-level CRUD operations as operations on a service
> >> >> >> >>> interface:
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>    public List getAllCustomers();
> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
> >> >> >> accountNumber);
> >> >> >> >>> > >> >>> }
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > which is all application level concepts rather
> >> >> >> than  persistence
> >> >> >> >>> > level
> >> >> >> >>> > >> > concepts. I'd actually go a little further and put
> that
> >> >> >> >>> right into
> >> >> >> >>> > >> > the service contract:
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >   public interface AccountService {
> >> >> >> >>> > >> >     List<Customer> getAllCustomers();
> >> >> >> >>> > >> >     Account getCustomerAccount(String accountNumber);
> >> >> >> >>> > >> >   }
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > In a ideal world, if the user was able to accept
> >> >> >> standardized
> >> >> >> >>> > >> > mappings (a la Rails et al) then no further
> >> configuration
> >> >> >> >>> would be
> >> >> >> >>> > >> > needed except to add this to the logical assembly:
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >   <component name="AccountStore">
> >> >> >> >>> > >> >     <implementation.das resource="MySQLDatabase"/>
> >> >> >> >>> > >> >   </component>
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > With SCA's ability to translate service contracts,
> this
> >> >> >> >>> should be
> >> >> >> >>> > >> > callable from and deployable to any SCA runtime
> >> >> >> regardless of
> >> >> >> >>> > whether
> >> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
> >> >> >> running  on
> >> >> >> a
> >> >> >> >>> > Java,
> >> >> >> >>> > >> > C++ or PHP platform.
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > The important thing here is that the client is
> >> >> >> isolated  from
> >> >> >> >>> how
> >> >> >> >>> > the
> >> >> >> >>> > >> > DAS component is provided. We could have multiple
> >> >> >> declarative
> >> >> >> >>> > >> > implementations, say one based on RDB-DAS and one that
> >> did
> >> >> >> >>> stuff
> >> >> >> >>> > with
> >> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
> >> >> >> altering
> >> >> >> >>> the
> >> >> >> >>> > >> > client at all/ they could switch to a custom coded
> >> version
> >> >> >> >>> written
> >> >> >> >>> > in
> >> >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > --
> >> >> >> >>> > >> > Jeremy
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >> I would suggest that we start right away with a
> >> RDBDAS-
> >> >> >> based
> >> >> >> >>> > >> >> solution.  I also think that the best place to start
> >> >> >> would
> >> >> >> >>> be with
> >> >> >> >>> > >> >> an interface that is "weakly" typed.  That is, a
> >> service
> >> >> >> >>> interface
> >> >> >> >>> >
> >> >> >> >>> > >> >> in terms of dynamic SDO's.  If we go this route we
> can
> >> >> >> >>> avoid the
> >> >> >> >>> > >> >> generation (by hand or otherwise) of code specific to
> >> >> >> a new
> >> >> >> >>> > >> >> service.  Instead, the service will be "instantiated"
> >> >> >> based
> >> >> >> >>> on the
> >> >> >> >>> >
> >> >> >> >>> > >> >> provided DAS config file.  The service interface
> >> >> >> might  look
> >> >> >> >>> like
> >> >> >> >>> > >> this:
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>    public interface RDBDASService
> >> >> >> >>> > >> >>        DataObject execute(String commandName);
> >> >> >> >>> > >> >>        DataObject executeSQL(String abitrarySQL);
> >> >> >> >>> > >> >>        void applyChanges(DataObject graphRoot);
> >> >> >> >>> > >> >>    }
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >> So, depending on the config file used to
> >> instantiate the
> >> >> >> >>> service,
> >> >> >> >>> > >> >> this interface could be used to return Customers/
> >> >> >> Accounts or
> >> >> >> >>> > >> >> Toasters.  In fact, a lot could be achieved with no
> >> >> >> >>> > configuration  at
> >> >> >> >>> > >> >> all by restricting use to:  DataObject
> >> executeSQL(String
> >> >> >> >>> > >> abitrarySQL);
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
> >> >> >> >>> mod_mbox/ws-
> >> >> >> >>> > >> >>
> >> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >> Once this was working it should be straightforward to
> >> >> >> build
> >> >> >> >>> more
> >> >> >> >>> > >> >> strongly typed services and possible put together
> some
> >> >> >> >>> generation
> >> >> >> >>> > >> >> tooling.  We could also start looking at support for
> a
> >> >> >> more
> >> >> >> >>> > RESTFul
> >> >> >> >>> > >> >> interface.
> >> >> >> >>> > >> >> --
> >> >> >> >>> > >> >> Kevin
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >> Luciano Resende wrote:
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>> Recently, people have been starting to talk about
> >> >> >> better DAS
> >> >> >> >>> > >> >>> integration
> >> >> >> >>> > >> >>> with DAS, and below are some threads on the subject
> :
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> msg08833.html
> >> >> >> >>> > >> >>>
> >> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
> >> >> >> msg08923.html
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
> >> >> >> >>> msg09715.html
> >> >> >> >>> >
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
> >> >> >> what  I'm
> >> >> >> >>> > >> >>> saying is not
> >> >> >> >>> > >> >>> yet available on SCA today.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Today, defining a service to work with a relational
> >> >> >> >>> database, you
> >> >> >> >>> > >> >>> will need
> >> >> >> >>> > >> >>> to code the persistence side of the service where
> >> CRUD
> >> >> >> >>> operations
> >> >> >> >>> > >> >>> to the
> >> >> >> >>> > >> >>> database will be done.
> >> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where
> coding
> >> >> >> the
> >> >> >> >>> CRUD
> >> >> >> >>> > >> >>> operations on
> >> >> >> >>> > >> >>> the persistence layer would be avoided as much as
> >> >> >> possible.
> >> >> >> >>> > >> >>> The idea would be to have a more "declarative DAS"
> >> when
> >> >> >> >>> defining
> >> >> >> >>> > SCA
> >> >> >> >>> > >> >>> Services, so you would either use some Annotations
> >> >> >> or  SCDL
> >> >> >> to
> >> >> >> >>> > >> have  the
> >> >> >> >>> > >> >>> "declarative DAS"  configuration inside it.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> I was thinking on something like....
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> SCDL Definition would look something like this :
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> <component name="AccountDataService">
> >> >> >> >>> > >> >>>   <interface.java
> >> >> >> >>> > >> >>>
> >> >> >> class="bigbank.account.services.account.AccountService"/>
> >> >> >> >>> > >> >>>   <implementation.das="dasConfig.properties"
> >> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
> >> >> >> >>> > >> >>> </component>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> The AccountService Interface would look like this
> >> >> >> (missing
> >> >> >> >>> any
> >> >> >> >>> > SCA
> >> >> >> >>> > >> >>> annotations):
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> public interface AccountService {
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>    public List getAllCustomers();
> >> >> >> >>> > >> >>>    public Object getCustomerAccount(String
> >> >> >> accountNumber);
> >> >> >> >>> > >> >>> }
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> The DAS config would look like this, and would
> >> have the
> >> >> >> >>> > definition
> >> >> >> >>> > >> >>> for the
> >> >> >> >>> > >> >>> "all companies" command.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> <Config ...>
> >> >> >> >>> > >> >>>    ...
> >> >> >> >>> > >> >>>   <ConnectionInfo dataSource="java:comp/env/jdbc/
> >> >> >> bigbank"/>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>   <Command name="getAllCustomers" SQL="select * from
> >> >> >> >>> CUSTOMERS"
> >> >> >> >>> > >> >>> kind="Select"/>
> >> >> >> >>> > >> >>>   <Command name="getCustomerAccount" SQL="SELECT
> >> >> >> >>> accountNumber,
> >> >> >> >>> > >> >>> accountType, balance FROM accounts where
> >> >> >> accountNumber = ?"
> >> >> >> >>> > >> >>> kind="Select" />
> >> >> >> >>> > >> >>>   ...
> >> >> >> >>> > >> >>> </Config>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
> >> >> >> >>> > >> >>>   - If a DAS config file is provided, based on the
> >> >> >> >>> > SCDL  definition,
> >> >> >> >>> > >> we
> >> >> >> >>> > >> >>> would look for "DAS command" based on the name of
> the
> >> >> >> getter
> >> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
> >> >> >> command)
> >> >> >> >>> > >> >>>   - Otherwise, we would try to do a map directly to
> a
> >> >> >> >>> > >> stored  procedure
> >> >> >> >>> > >> >>>   - We could also have a way to force the mapping by
> >> >> >> using
> >> >> >> >>> > >> annotation
> >> >> >> >>> > >> >>> (e.g@Procedure on the method level)
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Mapping between method parameter and command
> >> parameter
> >> >> >> >>> > >> >>>   - We would need to define a method for mapping the
> >> >> >> method
> >> >> >> >>> > >> >>> parameters to
> >> >> >> >>> > >> >>> the query paramters either based on position (
> >> e.gfirst
> >> >> >> >>> method
> >> >> >> >>> > >> >>> parameter
> >> >> >> >>> > >> >>> maps to the first command paramter), or we would do
> >> some
> >> >> >> >>> > mapping  by
> >> >> >> >>> > >> >>> name
> >> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Note:
> >> >> >> >>> > >> >>>   - A SCDL connection information would override the
> >> DAS
> >> >> >> >>> Config
> >> >> >> >>> > file
> >> >> >> >>> > >> >>> connection information.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Benefits
> >> >> >> >>> > >> >>>   - It's All about simplicity and easy of use
> >> >> >> >>> > >> >>>   - This would allow a user to define a service
> >> without
> >> >> >> >>> having to
> >> >> >> >>> >
> >> >> >> >>> > >> >>> explicitly having to code any Data Access related
> >> code.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Implementation approaches
> >> >> >> >>> > >> >>>   - Utilizing DAS : This approach would start from
> >> the
> >> >> >> >>> current
> >> >> >> >>> > >> >>> Tuscany DAS
> >> >> >> >>> > >> >>> implementation, where functionality would be already
> >> >> >> >>> > available,  but
> >> >> >> >>> > >> >>> the
> >> >> >> >>> > >> >>> service implementation would be tied to SDO and RDB
> >> >> >> as this
> >> >> >> >>> > is  what
> >> >> >> >>> > >> >>> DAS
> >> >> >> >>> > >> >>> supports today.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>   - Start simple and grow : We could start simple,
> by
> >> >> >> >>> having a
> >> >> >> >>> > >> simple
> >> >> >> >>> > >> >>> implementation based on JDBC and would return some
> >> >> >> simple
> >> >> >> >>> > >> >>> collection as a
> >> >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
> >> could
> >> >> >> >>> give us
> >> >> >> >>> > a
> >> >> >> >>> > >> >>> quick
> >> >> >> >>> > >> >>> start to flush implementation details and get a
> >> proven
> >> >> >> >>> design,
> >> >> >> >>> > and
> >> >> >> >>> > >> >>> this
> >> >> >> >>> > >> >>> could get evolved to use a DAS that would support
> >> >> >> multiple
> >> >> >> >>> > backends
> >> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
> >> >> >> non- SDO
> >> >> >> >>> types
> >> >> >> >>> > >> as a
> >> >> >> >>> > >> >>> command
> >> >> >> >>> > >> >>> result.
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> Toughts ?
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> - Luciano
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net>
> >> wrote:
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> Great.  I would like to help with this.  I have
> been
> >> >> >> >>> thinking
> >> >> >> >>> > for
> >> >> >> >>> > >> >>>> awhile
> >> >> >> >>> > >> >>>> about how to best integrate the RDB DAS within SCA.
> >> >> >> For
> >> >> >> >>> > >> example,  the
> >> >> >> >>> > >> >>>> current BBank scenario uses the RDB DAS as a
> utility
> >> >> >> but it
> >> >> >> >>> > >> would be
> >> >> >> >>> > >> >>>> nice if it could "wire in" a RDB DAS service or be
> >> >> >> >>> injected with
> >> >> >> >>> > a
> >> >> >> >>> > >> >>>> configured DAS.  Another thing we want to
> eventually
> >> >> >> >>> explore is
> >> >> >> >>> > >> >>>> exposing
> >> >> >> >>> > >> >>>> a DAS as REST-oriented services.  As we have seen
> >> >> >> from the
> >> >> >> >>> > parent
> >> >> >> >>> > >> >>>> thread
> >> >> >> >>> > >> >>>> there are almost too many possible approaches.
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> My first thought is to model the DAS as a service
> >> and
> >> >> >> >>> create a
> >> >> >> >>> > new
> >> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas).  The
> >> main
> >> >> >> >>> reason
> >> >> >> >>> > has
> >> >> >> >>> > >> >>>> to do
> >> >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
> >> >> >> >>> > Jeremy  mentioned
> >> >> >> >>> > >> >>>> which
> >> >> >> >>> > >> >>>> is all about creating data access services
> >> >> >> >>> declaratively.  A new
> >> >> >> >>> > >> >>>> component type and a service that we build by hand
> >> >> >> would be
> >> >> >> >>> > a  good
> >> >> >> >>> > >> >>>> step
> >> >> >> >>> > >> >>>> in this direction.
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> We might want to expose a DAS service with an
> >> >> >> interface  like
> >> >> >> >>> > this:
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>>     public interface RDBDASService
> >> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
> >> >> >> >>> > >> >>>>         DataObject execute(String commandName);
> >> >> >> >>> > >> >>>>         DataObject executeSQL(String abitrarySQL);
> >> >> >> >>> > >> >>>>     }
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> The service would be initialized with an optional
> >> >> >> RDB DAS
> >> >> >> >>> > >> config  file
> >> >> >> >>> > >> >>>> that defines connection properties, a set of
> >> commands,
> >> >> >> >>> etc.  So,
> >> >> >> >>> > >> >>>> different services implementing the same interface
> >> >> >> could be
> >> >> >> >>> > >> >>>> initialized
> >> >> >> >>> > >> >>>> from separate config files.
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> Eventually, we might want to build services like
> >> this:
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>>     public interface Customers_RDBDASService
> >> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
> >> >> >> >>> > >> >>>>         DataObject getAllCustomersWithLastName
> >> (String
> >> >> >> >>> > lastName);
> >> >> >> >>> > >> >>>>         DataObject getAll CustomersAndOrdersForID
> >> (int
> >> >> >> >>> > customerId);
> >> >> >> >>> > >> >>>>     }
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> But, for this to be very useful would probably
> >> require
> >> >> >> >>> some code
> >> >> >> >>> > >> >>>> generation tooling.
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> Thoughts?
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> --Kevin
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> Luciano Resende wrote:
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
> >> >> >> declarative
> >> >> >> >>> > DAS  and
> >> >> >> >>> > >> >>>> will be
> >> >> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
> >> >> >> >>> > >> >>>> >
> >> >> >> >>> > >> >>>> > - Luciano
> >> >> >> >>> > >> >>>> >
> >> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
> >> >> >> wrote:
> >> >> >> >>> > >> >>>> >
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >> On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
> >> >> >> >>> > >> >>>> >> >> This sounds like having cake, eating it, and
> >> also
> >> >> >> >>> > being  able
> >> >> >> >>> > >> to
> >> >> >> >>> > >> >>>> >> >> give it to a friend :-) We provide the
> >> >> >> flexibility  for
> >> >> >> >>> > users:
> >> >> >> >>> > >> >>>> >> >> 1) to access infrastructure services through
> >> >> >> >>> properties
> >> >> >> >>> > >> >>>> >> > Yes for things like JPA, JDBC, etc.
> >> >> >> >>> > >> >>>> >> >> 2) to reference infrastructure services
> >> through
> >> >> >> >>> > inclusion  in
> >> >> >> >>> > >> >>>> their
> >> >> >> >>> > >> >>>> >> >> assembly
> >> >> >> >>> > >> >>>> >> > If we do 1 I don't think we should do 2 (that
> >> >> >> >>> doesn't stop
> >> >> >> >>> > >> >>>> someone
> >> >> >> >>> > >> >>>> >> > from extending Tuscany to do it though). See
> my
> >> >> >> >>> comments
> >> >> >> >>> > >> below.
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
> >> >> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
> >> >> >> >>> > should  welcome
> >> >> >> >>> > >> it
> >> >> >> >>> > >> >>>> >> like we would any other contribution.
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >> >> 3) to access data through an application
> >> >> >> service with
> >> >> >> >>> > >> >>>> declarative
> >> >> >> >>> > >> >>>> >> >> implementation by DAS
> >> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
> >> >> >> >>> > >> >>>> >> --
> >> >> >> >>> > >> >>>> >> Jeremy
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>> >>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >>
> >> >> >> >>>
> >> >> >>
> >> --------------------------------------------------------------------
> >> >> >> >>> > >> -
> >> >> >> >>> > >> >>>> >> 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
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>>
> >> >> >> >>> > >> >>>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> > >> >>
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >>> > >> >> 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
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> > >> >
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>> > >>
> >> >> >> >>>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >>> > >> 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
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>>
> >> >> >> >>>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> >>> 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
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> ---------------------------------------------------------------------
> >> >> >> 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
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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: Declarative DAS, was Re: Modeling the RDB DAS in SCA

[Kevin Williams <ke...@qwest.net>]

Hi Amita,
This is looking good.  Some comments inline:

Amita Vadhavkar wrote:

> Hi,
> I am trying to create a container for DAS-SCA too (not just for stored
> procedure) and will be able to send a working code in ML over the 
> weekend.
>
> Below is summary of what I got so far from the previous mail 
> discussions and
> some questions.
>
>
> The integration between DAS and SCA can happen at application level as
> service or at container level.
>
>
>
> 2 different possible approaches –
>
> static – e.g. getAllCustomers
>
> dynamic – e.g. execute("all customers");
>
>
>
> For application level service – it is the sample *
> sample-StoredProcedureService.jar*  or what Luciano is providing in more
> details, is an example.  In *sample-StoredProcedureService.jar* example
> dynamic approach is followed
>
>
>
> For container approach – again static or dynamic approach can be 
> followed.
> For static – it's like providing service for getAllCompanies(),
> getAllCustomers() etc. whereas for dynamic its like execute(command) 
> where
> command can be "getAllCompanies", "getAllCustomers". Etc.
>
>
>
>            I am working on a container implementation where dynamic
> approach is followed.
>
If I understand correctly, the container approach will provide the 
tightest integration with SCA and make things easier for end-users.  Do 
you agree?

>
>
> There are 2 places where extensibility is required –
>
> 1)      for providing different data access mechanisms. i.e. today 
> there is
> RDB-DAS, tomorrow there will be XQUery-DAS etc. In this case – the 
> scdl will
> be same, but the exampleconfig.xml will change.
>
> In the container I am working on - Scdl has a new tag
>
> Scdl has a new tag
>  <da:implementation.da script="customersOrders/CustomersOrders.xml"
> dataAccessType="rdb"/>
>
>
>
> Here, dataAccessType – is the key which tells whether it's RDB or 
> something
> else. And the xml script provides the connection and data store details.
>
>
>
> 2)      for RDB-DAS – providing support for different databases (this
> portion should be part of DAS and  not SCA.) In the current container 
> I am
> working on it is provided as a package -
> org.apache.tuscany.container.dataaccessshelper package  - which should
> finally go into DAS codeline(?).
>
>
Currently, there are two ways to specify a particular database:  first, 
the user can pass a JDBC Connection to the DAS Factory when creating a 
DAS instance.  The second is that a DataSource can be specified in the 
DAS Config xml file in which case the DAS is responsible for getting the 
connection.

>
>
>
> For static approach we may need some code generation tooling. 

Right.  That is why I think it best to start with dynamic.  But, we will 
want static support as well.

> Also could not
> understand how this can be merged into RESTful interfaces. (this was
> mentioned in some mail conversation)
>
>
>
> Regards,
>
> Amita
>
>
> On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>
>>
>> Luciano Resende wrote:
>>
>> > Comments in-line...
>> >
>> > On 10/25/06, Jim Marino <jm...@myromatours.com> wrote:
>> >
>> >>
>> >>
>> >> On Oct 25, 2006, at 3:54 AM, Venkata Krishnan wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > I would also like to understand this a little better ... here I am
>> >> > thinking
>> >> > aloud and hope the others will help in getting my persceptions
>> >> > right...
>> >> >
>> >> > I guess firstly it is a question of how or where we want to
>> >> > position 'DAS
>> >> > Integration' in SCA.  Is is something we want to integrate as the
>> >> > Application Layer, which I understand is what Amita is trying
>> >> > presently and
>> >> > which Jim refers to as component implementation.   In this option
>> >> > we get to
>> >> > do some sort of a service wrapper to DAS and then it becomes a
>> >> > demonstration
>> >> > of two Tuscany subprojects integrating at application level.
>> >> >
>> >
>> >
>> >
>> > Yes, I think we have space to position DAS both ways, and integrating
>> > in the
>> > application layer by exposing DAS as a service would be a very easy 
>> and
>> > quick, this could be exposed as a sample app, and could show we are
>> > working
>> > on getting a better integration between DAS and SCA
>> >
>> >
>> >> Or do we want to position DAS at the infrastructure layer as another
>> >> > extension type (either container or binding).  I guess this is
>> >> > where Ant
>> >> > started this - proposing a JDBC container / binding for component
>> >> > implementation in StoredProcedures.
>> >> I was thinking a DAS was a way to declaratively model heterogeneous
>> >> data as a service and offer a mechanism for remoting that data. In
>> >> other words, it provided the ability for an application to perform
>> >> CRUD using a high-level contract (interface) and having those
>> >> operations take place across a service network.  How this is hooked
>> >> into the SCA container is probably best done as an extension type,
>> >> i.e. someone could specify:
>> >>
>> >> <component name="Foo">
>> >>         <implementation.das>
>> >>                 <interface.java ....>
>> >>         </implementation.das>
>> >> </component>
>> >
>> >
>> >
>> >
>> > Yes, this goes back to the way I was thinking on my original proposal.
>> >
>> >
>> >> If this is the path we should take
>> >> > then we probably have to think beyond DAS - to something more
>> >> > general - of
>> >> > which DAS is just a special case.  I suppose this is what Jim has
>> also
>> >> > suggested in trying to explore other persistence mechanisms.
>> >> >
>> >> This may be the crux of the confusion. I was thinking DAS provides a
>> >> general mechanism for accessing heterogeneous data and is only right
>> >> now tied to SQL because of resource constraints (i.e. we have to
>> >> start somewhere). Ultimately, DAS should provide the infrastructure
>> >> for dealing with multiple, varied data stores and mechanisms for
>> >> querying across them. In other words, I guess I am saying DAS should
>> >> be the general solution (declarative and heterogeneous) since if it
>> >> is only a programmatic way to access relational data then its value
>> >> is less clear in comparison to things such as JDBC 4 or JPA.
>> >
>> >
>> >
>> >
>> > Yes, the current status of DAS implementation is RDB only. I would say
>> > that,
>> > in the future, I'd like to see a heterogeneous DAS that would give you
>> > access to different data stores, and probably support non-SDO types as
>> > well.
>> >
>> >> I too feel that this is something that must be done as an extension
>> >> > type -
>> >> > but yet to get my hands on the general scheme of things that DAS
>> >> > can slip
>> >> > into. Infact the other thread where Jeremy has taken forward a
>> >> > proposal to
>> >> > the specs group on resources tempts me to think that there is going
>> >> > to be
>> >> > something in that which we can leverage from.
>> >> >
>> >> I think resources are orthogonal as they are about a component
>> >> implementation's contract with its container. Declarative data
>> >> services on the other hand are about application constructs that can
>> >> be wired to.
>> >>
>> >> > I hope to get a better understanding this as we go along in this
>> >> > thread :)
>> >> >
>> >> Me too :-) As soon as I have trouble explaining technologies to .NET
>> >> people and they say "you Unix/Java people are at it again with a
>> >> thousand ways to do the same exact thing" it causes me to think that
>> >> maybe we need to clarify our message.
>> >
>> >
>> >
>> >
>> > If we all think it would be useful, I could try to summarize the
>> > thread on
>> > the wiki with a more clean proposal incorporating all your feedback ,
>> > what
>> > you guys think ?
>>
>> Yes.  Great idea.
>>
>> >
>> >
>> > Jim
>> >
>> >> > Thanks
>> >> >
>> >> > - Venkat
>> >> >
>> >> > On 10/25/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >>
>> >> >> Jim Marino wrote:
>> >> >>
>> >> >> > When I first read the thread on this, I thought the DAS service
>> >> >> would
>> >> >> > be a component extension type (e.g. analogous to a
>> >> >> > implementation.java or implementation.ejb) and not a component
>> >> >> > implementation type, which would allow for dynamic and 
>> eventually
>> >> >> > declarative configuration styles.
>> >> >>
>> >> >> I have not very familiar with the terminology so I am not sure 
>> what
>> a
>> >> >> "component extension type" is.  But, I do think we eventually want
>> >> >> "implementation.rdbdas".  Wouldn't this be a new implementation
>> type?
>> >> >>
>> >> >> It looks like Amita chose to start with a POJO.  I notice the use
>> >> >> of "
>> >> >> implementation.java".
>> >> >>
>> >> >> > Either way, though, I am curious as  to why
>> >> >> >
>> >> >> > public DAS configureService(String configFile);
>> >> >> >
>> >> >> > exists as part of the service definition? If the DAS service 
>> was a
>> >> >> > component extension type, it could be handled as part of the
>> >> >> > application bootstrap. If the DAS service was a component
>> >> >> > implementation type, the configuration file URI could be passed
>> >> >> in as
>> >> >> > a property and then processed in an initializer method decorated
>> by
>> >> >> > the SCA @Init annotation. In the latter case, if the
>> implementation
>> >> >> > of DASService thread-safe (hopefully it is since configuration
>> >> >> would
>> >> >> > seem to be a heavyweight operation), then I would make the
>> >> >> component
>> >> >> > module scoped to avoid initialization overhead on every
>> resolution.
>> >> >>
>> >> >> >
>> >> >> > In both approaches (extension vs. implementation type), having
>> >> >> > configuration exposed to the application doesn't quite feel 
>> right,
>> >> >> > since that is what DI tries to externalize.
>> >> >>
>> >> >> I agree.  The configuration should be part of the 
>> initialization and
>> >> >> should use SCA patterns to do this.  I think that Amita meant 
>> to use
>> >> >> eventually use a component property for the DAS config info but
>> >> >> started
>> >> >> with a method.
>> >> >>
>> >> >> >
>> >> >> > Also, I was thinking that in having this a component extension
>> >> >> type,
>> >> >> > the service interfaces returned from a resolution could include
>> the
>> >> >> > dynamic one described below or static ones people have 
>> mentioned.
>> I
>> >> >> > guess it is best to start with the easier-to-implement part
>> >> >> first and
>> >> >> > support the dynamic interface.
>> >> >> >
>> >> >> > FWIW, as a JPA/Hibernate/general O-R bigot, it would be nice to
>> >> >> > understand what DAS provides in relation to other persistence
>> >> >> > technologies. Outside of the Java world, Microsoft is promoting
>> >> >> LINQ
>> >> >> > which is really interesting, and it would be informative to
>> compare
>> >> >> > the goals of DAS with that approach (there are obvious 
>> differences
>> >> >> > such as having the query language a strongly-typed part of the
>> >> >> > programming language, e.g. C#, and LINQ's use of closures).
>> >> >> >
>> >> >> > In contrasting DAS to O-R technologies, I see the primary use
>> cases
>> >> >> > for the former being a quick way to issue a query that may be
>> >> >> > executed against *heterogeneous* data stores and have that data
>> >> >> flow
>> >> >> > remotely or to a client that is not necessarily Java-based. One
>> key
>> >> >> > for me is heterogeneous data since JDBC 4 lets me do this
>> >> >> (Hibernate
>> >> >> > and JPA are about as easy):
>> >> >> >
>> >> >> IMO the primary use case for DAS is an application that is SDO-
>> >> >> centric
>> >> >> and is taking advantage of its disconnected capabilities.  The RDB
>> >> >> DAS
>> >> >> is built to work with SDO and uses the change summary to drive
>> >> >> changes
>> >> >> made to a disconnected data graph back to some store.  This is not
>> to
>> >> >> say that a relational DAS could not be built on top of JPA, in 
>> fact,
>> >> >> this might be a very useful thing to do.  The implementation we
>> >> >> currently have provides a very straightforward implicit mapping 
>> from
>> >> >> DataObjects to Tables.  If more capable mapping is needed then it
>> >> >> makes
>> >> >> sense to use the JPA-defined technology and artifacts.  A modified
>> >> >> Entity manager might be needed to take advantage of SDO's change
>> >> >> summary.
>> >> >>
>> >> >> >
>> >> >> > public interface CustomerDao extends BaseQuery {
>> >> >> >     @Select("select * from customers where city = ?1")
>> >> >> >     DataSet<Customer> findCustomersFrom(String city);
>> >> >> > }
>> >> >> >
>> >> >> > CustomerDao cd = QueryObjectFactory.createQueryObject
>> >> >> > (CustomerDao.class, datasource);
>> >> >> > DataSet<Customer> r = cd.findCustomersFrom(city);
>> >> >> >
>> >> >> >
>> >> >> > The other key is remote data and change lists.  I think there 
>> are
>> >> >> > (literally) about a thousand ways that already exist to 
>> handle the
>> >> >> > "local" data case. For change lists, interop with ADO.NET's 
>> change
>> >> >> > summary facilities would be interesting.
>> >> >>
>> >> >> I agree.  Also, it looks like Xcalia may have a similar thought:
>> >> >> http://www.xcalia.com/news/PR_2006-10-23.jsp
>> >> >>
>> >> >> >
>> >> >> > I'm playing devil's advocate a bit with DAS, but I think it is
>> >> >> > important we have a clear statement as to when it is appropriate
>> >> >> and
>> >> >> > not appropriate to use. One place to start would be to compare
>> >> >> it to
>> >> >> > JDBC 4 and JPA.
>> >> >>
>> >> >> We can get started with JPA:
>> >> >>
>> >> >>     * JPA is java-specific, container-based, built around a
>> connected
>> >> >>       data model and offers a complete O/R mapping for POJOs
>> >> >>
>> >> >>     * The RDB DAS is a java implementation of a language - neutral
>> >> >>       concept (hopefully specified some day) that is 
>> containerless,
>> >> >>       assumes a disconnected data model and provides a simple,
>> >> >> implicit
>> >> >>       mapping for SDO DataObjects (Dynamic or Static) to 
>> relational
>> >> >> tables.
>> >> >>
>> >> >> Anything else?
>> >> >>
>> >> >> >
>> >> >> > Jim
>> >> >> >
>> >> >> > On Oct 23, 2006, at 8:18 AM, Luciano Resende wrote:
>> >> >> >
>> >> >> >> Hi Amita
>> >> >> >>
>> >> >> >> I think we were both going on the same way, with the DAS 
>> Service
>> >> >> >> sample,
>> >> >> >> altough i had the interface more like this, to be more 
>> flexible :
>> >> >> >>
>> >> >> >> public interface DASService {
>> >> >> >>
>> >> >> >>    public DAS configureService(String configFile);
>> >> >> >
>> >> >> >
>> >> >> >>    public DataObject executeCommand(String commandName);
>> >> >> >>    public DataObject execute(String newCommand);
>> >> >> >>    public void applyChanges(DataObject graphRoot);
>> >> >> >> }
>> >> >> >>
>> >> >> >>
>> >> >> >> As for having it as a sample, maybe we could defined the
>> >> >> DASService
>> >> >> >> as one
>> >> >> >> sample itself, and have a second version of companyWeb that 
>> would
>> >> >> >> consume
>> >> >> >> the service, something like :
>> >> >> >>
>> >> >> >> das\samples\companyWeb
>> >> >> >> das\samples\dasService
>> >> >> >> das\samples.companyWeb.service
>> >> >> >>
>> >> >> >> or, more like BigBank
>> >> >> >>
>> >> >> >> das\samples\companyweb.Service\dasService
>> >> >> >> das\samples\companyweb.Service\webClient
>> >> >> >>
>> >> >> >> Or even in sampleApps...
>> >> >> >>
>> >> >> >> Toughts ?
>> >> >> >>
>> >> >> >>
>> >> >> >> On 10/21/06, Amita Vadhavkar <am...@gmail.com> wrote:
>> >> >> >>
>> >> >> >>>
>> >> >> >>> Hi ,
>> >> >> >>> I am also following up another thread
>> >> >> >>> http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> msg09944.html
>> >> >> >>> on the
>> >> >> >>> similar issue (JDBC stored procedure container
>> >> >> >>> using DAS)
>> >> >> >>> Besides the fact that I am actively working on the container
>> >> >> work,
>> >> >> >>> I also
>> >> >> >>> have tried to
>> >> >> >>> develop a sample based on the below discussion, following
>> dynamic
>> >> >> >>> approach.
>> >> >> >>>
>> >> >> >>> I am attaching the same here. Please take a look and give your
>> >> >> >>> suggestions.
>> >> >> >>> In this, StoredProcedureService implementation has
>> >> >> setConfigInfo (DAS
>> >> >> >>> Config) and
>> >> >> >>> execute(Any SQL). This can be made more complete with
>> >> >> executeSQL(),
>> >> >> >>> applyChanges()
>> >> >> >>> etc.
>> >> >> >>>
>> >> >> >>> Can this be added to the existing set of samples?
>> >> >> >>>
>> >> >> >>> Regards,
>> >> >> >>> Amita
>> >> >> >>>
>> >> >> >>> On 10/21/06, Kevin Williams <ke...@qwest.net> wrote:
>> >> >> >>> >
>> >> >> >>> > Luciano Resende wrote:
>> >> >> >>> >
>> >> >> >>> > > Kevin, from what I understood from your suggestion, it was
>> >> >> >>> looking to
>> >> >> >>> > me
>> >> >> >>> > > more like exposing DAS as a service :
>> >> >> >>> > >
>> >> >> >>> > >>>   public interface RDBDASService
>> >> >> >>> > >>>        DataObject execute(String commandName);
>> >> >> >>> > >>>        DataObject executeSQL(String abitrarySQL);
>> >> >> >>> > >>>        void applyChanges(DataObject graphRoot);
>> >> >> >>> > >>>    }
>> >> >> >>> > >>
>> >> >> >>> > Yes, I am talking about exposing a DAS Service configured
>> >> >> with a
>> >> >> >>> > specific set of capabilities/commands defined in the DAS
>> config
>> >> >> >>> file.
>> >> >> >>> > So, if the implementation of the service interface above was
>> >> >> >>> configured
>> >> >> >>> > to work with Customers they would use the service like this:
>> >> >> >>> >
>> >> >> >>> >    List customers = myRDBDASService.execute
>> ("getAllCustomers");
>> >> >> >>> >    String name = customers.get(0).getString("name");
>> >> >> >>> >
>> >> >> >>> > This is not much different than the static interface you
>> >> >> proposed,
>> >> >> >>> > right?
>> >> >> >>> >
>> >> >> >>> > > And then, when a service developer defines the
>> >> >> AccountService,
>> >> >> >>> he will
>> >> >> >>> >
>> >> >> >>> > > have
>> >> >> >>> > > to know about yet another service, about how DAS works,
>> >> >> how it is
>> >> >> >>> > > configured, etc, etc... is that right ?
>> >> >> >>> > >
>> >> >> >>> > The abilities of the service are defined by the DAS config
>> >> >> file.
>> >> >> >>> So,
>> >> >> >>> > the person or tool that provides the config file must
>> >> >> understand
>> >> >> >>> how the
>> >> >> >>> >
>> >> >> >>> > RDB DAS APIs work.  There is no getting around this.
>> >> >> >>> >
>> >> >> >>> > > My proposal was going more towards allowing the service
>> >> >> >>> developer to
>> >> >> >>> > > focus
>> >> >> >>> > > on defining the service, and let the "declarative das" to
>> >> >> >>> handle the
>> >> >> >>> > > persistent layer....
>> >> >> >>> > >
>> >> >> >>> > The DAS config file is the declaration of an instance of the
>> >> >> >>> DAS.  That
>> >> >> >>> > instance can be exposed as a dynamic or typed service/
>> >> >> interface.
>> >> >> >>> That
>> >> >> >>> > seems to be the main discussion we are having. Although, I
>> >> >> may be
>> >> >> >>> > missing something.
>> >> >> >>> >
>> >> >> >>> > > Also, by defining some conventions over configuration
>> >> >> and/or  using
>> >> >> >>> > > annotations (e.g @Procedure to force mapping to a stored
>> >> >> >>> procedure),
>> >> >> >>> > the
>> >> >> >>> > > service developer could really define a service that
>> >> >> interacts
>> >> >> >>> with a
>> >> >> >>> > > RDB,
>> >> >> >>> > > without having to code the service persistence layer.
>> >> >> >>> > >
>> >> >> >>> > There is a lot of potential for the use of annotations.
>> >> >> >>> >
>> >> >> >>> > >
>> >> >> >>> > > - Luciano
>> >> >> >>> > >
>> >> >> >>> > >
>> >> >> >>> > > On 10/19/06, Kevin Williams < kevincbw@qwest.net> wrote:
>> >> >> >>> > >
>> >> >> >>> > >>
>> >> >> >>> > >> The real difference between the two approaches is that
>> >> >> one is
>> >> >> >>> "Typed"
>> >> >> >>> > or
>> >> >> >>> > >> static and the other is dynamic.  I think both are needed
>> >> >> but  was
>> >> >> >>> > >> suggesting that we start with dynamic since it is the 
>> most
>> >> >> >>> flexible
>> >> >> >>> > and
>> >> >> >>> > >> seems to be a reasonable stepping stone towards a static
>> >> >> >>> capability.
>> >> >> >>> > >>
>> >> >> >>> > >> With either, the user does not need to know about
>> >> >> traditional
>> >> >> >>> > >> persistence frameworks.  With the dynamic approach,
>> however,
>> >> >> >>> the user
>> >> >> >>> > >> does need to know about the dynamic SDO API.
>> >> >> >>> > >>
>> >> >> >>> > >> So, with the static interface the user might write:
>> >> >> >>> > >>
>> >> >> >>> > >>     List customers = accountService.getAllCustomers();
>> >> >> >>> > >>     String name = ((Customer)customers.get(0)).getName();
>> >> >> >>> > >>
>> >> >> >>> > >> The equivalent dynamic API might be:
>> >> >> >>> > >>
>> >> >> >>> > >>     List customers = 
>> dasService.execute("getAllCustomers");
>> >> >> >>> > >>     String name = 
>> ((DataObject)customers.get(0)).getString
>> >> >> >>> ("name");
>> >> >> >>> > >>
>> >> >> >>> > >> The first is probably a little easier for the application
>> >> >> >>> developer
>> >> >> >>> > but
>> >> >> >>> > >> the second is much easier for the service developer. IMO,
>> >> >> the
>> >> >> >>> dynamic
>> >> >> >>> > >> case is the best place to start and, again, we
>> >> >> definitely  will
>> >> >> >>> want
>> >> >> >>> > >> support for both.
>> >> >> >>> > >>
>> >> >> >>> > >> Thanks.
>> >> >> >>> > >> --
>> >> >> >>> > >> Kevin
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >> Jeremy Boynes wrote:
>> >> >> >>> > >>
>> >> >> >>> > >> > I think this would be useful but it seems more like a
>> >> >> >>> traditional
>> >> >> >>> > >> > persistence API than what Luciano was suggesting. With
>> >> >> this
>> >> >> >>> one a
>> >> >> >>> > >> > user needs to know about DataObject's, commands, SQL
>> >> >> strings
>> >> >> >>> etc.
>> >> >> >>> > >> > just like they would if they were using raw JDBC or 
>> JPA.
>> >> >> >>> > >> >
>> >> >> >>> > >> > On the other hand, Luciano's proposal seemed more about
>> >> >> >>> expressing
>> >> >> >>> > >> > high-level CRUD operations as operations on a service
>> >> >> >>> interface:
>> >> >> >>> > >> >
>> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>    public List getAllCustomers();
>> >> >> >>> > >> >>>    public Object getCustomerAccount(String
>> >> >> accountNumber);
>> >> >> >>> > >> >>> }
>> >> >> >>> > >> >>
>> >> >> >>> > >> >
>> >> >> >>> > >> > which is all application level concepts rather
>> >> >> than  persistence
>> >> >> >>> > level
>> >> >> >>> > >> > concepts. I'd actually go a little further and put that
>> >> >> >>> right into
>> >> >> >>> > >> > the service contract:
>> >> >> >>> > >> >
>> >> >> >>> > >> >   public interface AccountService {
>> >> >> >>> > >> >     List<Customer> getAllCustomers();
>> >> >> >>> > >> >     Account getCustomerAccount(String accountNumber);
>> >> >> >>> > >> >   }
>> >> >> >>> > >> >
>> >> >> >>> > >> > In a ideal world, if the user was able to accept
>> >> >> standardized
>> >> >> >>> > >> > mappings (a la Rails et al) then no further 
>> configuration
>> >> >> >>> would be
>> >> >> >>> > >> > needed except to add this to the logical assembly:
>> >> >> >>> > >> >
>> >> >> >>> > >> >   <component name="AccountStore">
>> >> >> >>> > >> >     <implementation.das resource="MySQLDatabase"/>
>> >> >> >>> > >> >   </component>
>> >> >> >>> > >> >
>> >> >> >>> > >> > With SCA's ability to translate service contracts, this
>> >> >> >>> should be
>> >> >> >>> > >> > callable from and deployable to any SCA runtime
>> >> >> regardless of
>> >> >> >>> > whether
>> >> >> >>> > >> > it was being accessed locally, by WS-*, by IIOP or
>> >> >> running  on
>> >> >> a
>> >> >> >>> > Java,
>> >> >> >>> > >> > C++ or PHP platform.
>> >> >> >>> > >> >
>> >> >> >>> > >> > The important thing here is that the client is
>> >> >> isolated  from
>> >> >> >>> how
>> >> >> >>> > the
>> >> >> >>> > >> > DAS component is provided. We could have multiple
>> >> >> declarative
>> >> >> >>> > >> > implementations, say one based on RDB-DAS and one that
>> did
>> >> >> >>> stuff
>> >> >> >>> > with
>> >> >> >>> > >> > XML databases like Xindice; alternatively, /without
>> >> >> altering
>> >> >> >>> the
>> >> >> >>> > >> > client at all/ they could switch to a custom coded
>> version
>> >> >> >>> written
>> >> >> >>> > in
>> >> >> >>> > >> > Java, C++ or a store procedure language like PL/SQL.
>> >> >> >>> > >> >
>> >> >> >>> > >> > --
>> >> >> >>> > >> > Jeremy
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> > >> > On Oct 19, 2006, at 2:05 PM, Kevin Williams wrote:
>> >> >> >>> > >> >
>> >> >> >>> > >> >> I would suggest that we start right away with a 
>> RDBDAS-
>> >> >> based
>> >> >> >>> > >> >> solution.  I also think that the best place to start
>> >> >> would
>> >> >> >>> be with
>> >> >> >>> > >> >> an interface that is "weakly" typed.  That is, a 
>> service
>> >> >> >>> interface
>> >> >> >>> >
>> >> >> >>> > >> >> in terms of dynamic SDO's.  If we go this route we can
>> >> >> >>> avoid the
>> >> >> >>> > >> >> generation (by hand or otherwise) of code specific to
>> >> >> a new
>> >> >> >>> > >> >> service.  Instead, the service will be "instantiated"
>> >> >> based
>> >> >> >>> on the
>> >> >> >>> >
>> >> >> >>> > >> >> provided DAS config file.  The service interface
>> >> >> might  look
>> >> >> >>> like
>> >> >> >>> > >> this:
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>    public interface RDBDASService
>> >> >> >>> > >> >>        DataObject execute(String commandName);
>> >> >> >>> > >> >>        DataObject executeSQL(String abitrarySQL);
>> >> >> >>> > >> >>        void applyChanges(DataObject graphRoot);
>> >> >> >>> > >> >>    }
>> >> >> >>> > >> >>
>> >> >> >>> > >> >> So, depending on the config file used to 
>> instantiate the
>> >> >> >>> service,
>> >> >> >>> > >> >> this interface could be used to return Customers/
>> >> >> Accounts or
>> >> >> >>> > >> >> Toasters.  In fact, a lot could be achieved with no
>> >> >> >>> > configuration  at
>> >> >> >>> > >> >> all by restricting use to:  DataObject 
>> executeSQL(String
>> >> >> >>> > >> abitrarySQL);
>> >> >> >>> > >> >>
>> >> >> >>> > >> >> I expand a bit here: http://mail-archives.apache.org/
>> >> >> >>> mod_mbox/ws-
>> >> >> >>> > >> >> 
>> tuscany-dev/200610.mbox/%3c452418BD.8010406@qwest.net%3e
>> >> >> >>> > >> >>
>> >> >> >>> > >> >> Once this was working it should be straightforward to
>> >> >> build
>> >> >> >>> more
>> >> >> >>> > >> >> strongly typed services and possible put together some
>> >> >> >>> generation
>> >> >> >>> > >> >> tooling.  We could also start looking at support for a
>> >> >> more
>> >> >> >>> > RESTFul
>> >> >> >>> > >> >> interface.
>> >> >> >>> > >> >> --
>> >> >> >>> > >> >> Kevin
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >> Luciano Resende wrote:
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>> Recently, people have been starting to talk about
>> >> >> better DAS
>> >> >> >>> > >> >>> integration
>> >> >> >>> > >> >>> with DAS, and below are some threads on the subject :
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> msg08833.html
>> >> >> >>> > >> >>>
>> >> >> >>> > http://www.mail-archive.com/tuscany-dev@ws.apache.org/
>> >> >> msg08923.html
>> >> >> >>> > >> >>>
>> >> >> >>> > >> http://www.mail-archive.com/tuscany-dev%40ws.apache.org/
>> >> >> >>> msg09715.html
>> >> >> >>> >
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> I'm new on the SCA side, so please help me make sure
>> >> >> what  I'm
>> >> >> >>> > >> >>> saying is not
>> >> >> >>> > >> >>> yet available on SCA today.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Today, defining a service to work with a relational
>> >> >> >>> database, you
>> >> >> >>> > >> >>> will need
>> >> >> >>> > >> >>> to code the persistence side of the service where 
>> CRUD
>> >> >> >>> operations
>> >> >> >>> > >> >>> to the
>> >> >> >>> > >> >>> database will be done.
>> >> >> >>> > >> >>> I was thinking on a simpler, easier way, where coding
>> >> >> the
>> >> >> >>> CRUD
>> >> >> >>> > >> >>> operations on
>> >> >> >>> > >> >>> the persistence layer would be avoided as much as
>> >> >> possible.
>> >> >> >>> > >> >>> The idea would be to have a more "declarative DAS" 
>> when
>> >> >> >>> defining
>> >> >> >>> > SCA
>> >> >> >>> > >> >>> Services, so you would either use some Annotations
>> >> >> or  SCDL
>> >> >> to
>> >> >> >>> > >> have  the
>> >> >> >>> > >> >>> "declarative DAS"  configuration inside it.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> I was thinking on something like....
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> SCDL Definition would look something like this :
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> <component name="AccountDataService">
>> >> >> >>> > >> >>>   <interface.java
>> >> >> >>> > >> >>>
>> >> >> class="bigbank.account.services.account.AccountService"/>
>> >> >> >>> > >> >>>   <implementation.das="dasConfig.properties"
>> >> >> >>> > >> >>> connection="java:comp/env/jdbc/bigbank"/>
>> >> >> >>> > >> >>> </component>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> The AccountService Interface would look like this
>> >> >> (missing
>> >> >> >>> any
>> >> >> >>> > SCA
>> >> >> >>> > >> >>> annotations):
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> public interface AccountService {
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>    public List getAllCustomers();
>> >> >> >>> > >> >>>    public Object getCustomerAccount(String
>> >> >> accountNumber);
>> >> >> >>> > >> >>> }
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> The DAS config would look like this, and would 
>> have the
>> >> >> >>> > definition
>> >> >> >>> > >> >>> for the
>> >> >> >>> > >> >>> "all companies" command.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> <Config ...>
>> >> >> >>> > >> >>>    ...
>> >> >> >>> > >> >>>   <ConnectionInfo dataSource="java:comp/env/jdbc/
>> >> >> bigbank"/>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>   <Command name="getAllCustomers" SQL="select * from
>> >> >> >>> CUSTOMERS"
>> >> >> >>> > >> >>> kind="Select"/>
>> >> >> >>> > >> >>>   <Command name="getCustomerAccount" SQL="SELECT
>> >> >> >>> accountNumber,
>> >> >> >>> > >> >>> accountType, balance FROM accounts where
>> >> >> accountNumber = ?"
>> >> >> >>> > >> >>> kind="Select" />
>> >> >> >>> > >> >>>   ...
>> >> >> >>> > >> >>> </Config>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Mapping between interface methods and DAS Commands
>> >> >> >>> > >> >>>   - If a DAS config file is provided, based on the
>> >> >> >>> > SCDL  definition,
>> >> >> >>> > >> we
>> >> >> >>> > >> >>> would look for "DAS command" based on the name of the
>> >> >> getter
>> >> >> >>> > >> >>> (e.ggetAllCustomers would map to getAllCustomers
>> >> >> command)
>> >> >> >>> > >> >>>   - Otherwise, we would try to do a map directly to a
>> >> >> >>> > >> stored  procedure
>> >> >> >>> > >> >>>   - We could also have a way to force the mapping by
>> >> >> using
>> >> >> >>> > >> annotation
>> >> >> >>> > >> >>> (e.g@Procedure on the method level)
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Mapping between method parameter and command 
>> parameter
>> >> >> >>> > >> >>>   - We would need to define a method for mapping the
>> >> >> method
>> >> >> >>> > >> >>> parameters to
>> >> >> >>> > >> >>> the query paramters either based on position ( 
>> e.gfirst
>> >> >> >>> method
>> >> >> >>> > >> >>> parameter
>> >> >> >>> > >> >>> maps to the first command paramter), or we would do
>> some
>> >> >> >>> > mapping  by
>> >> >> >>> > >> >>> name
>> >> >> >>> > >> >>> (currently not available in Tuscany DAS)
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Note:
>> >> >> >>> > >> >>>   - A SCDL connection information would override the
>> DAS
>> >> >> >>> Config
>> >> >> >>> > file
>> >> >> >>> > >> >>> connection information.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Benefits
>> >> >> >>> > >> >>>   - It's All about simplicity and easy of use
>> >> >> >>> > >> >>>   - This would allow a user to define a service 
>> without
>> >> >> >>> having to
>> >> >> >>> >
>> >> >> >>> > >> >>> explicitly having to code any Data Access related 
>> code.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Implementation approaches
>> >> >> >>> > >> >>>   - Utilizing DAS : This approach would start from 
>> the
>> >> >> >>> current
>> >> >> >>> > >> >>> Tuscany DAS
>> >> >> >>> > >> >>> implementation, where functionality would be already
>> >> >> >>> > available,  but
>> >> >> >>> > >> >>> the
>> >> >> >>> > >> >>> service implementation would be tied to SDO and RDB
>> >> >> as this
>> >> >> >>> > is  what
>> >> >> >>> > >> >>> DAS
>> >> >> >>> > >> >>> supports today.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>   - Start simple and grow : We could start simple, by
>> >> >> >>> having a
>> >> >> >>> > >> simple
>> >> >> >>> > >> >>> implementation based on JDBC and would return some
>> >> >> simple
>> >> >> >>> > >> >>> collection as a
>> >> >> >>> > >> >>> return type (e.g List or a even a Recordset), this
>> could
>> >> >> >>> give us
>> >> >> >>> > a
>> >> >> >>> > >> >>> quick
>> >> >> >>> > >> >>> start to flush implementation details and get a 
>> proven
>> >> >> >>> design,
>> >> >> >>> > and
>> >> >> >>> > >> >>> this
>> >> >> >>> > >> >>> could get evolved to use a DAS that would support
>> >> >> multiple
>> >> >> >>> > backends
>> >> >> >>> > >> >>> (e.gRDB, XML, etc) and would create SDO as well as
>> >> >> non- SDO
>> >> >> >>> types
>> >> >> >>> > >> as a
>> >> >> >>> > >> >>> command
>> >> >> >>> > >> >>> result.
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> Toughts ?
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> - Luciano
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>> On 10/4/06, Kevin Williams <ke...@qwest.net> 
>> wrote:
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> Great.  I would like to help with this.  I have been
>> >> >> >>> thinking
>> >> >> >>> > for
>> >> >> >>> > >> >>>> awhile
>> >> >> >>> > >> >>>> about how to best integrate the RDB DAS within SCA.
>> >> >> For
>> >> >> >>> > >> example,  the
>> >> >> >>> > >> >>>> current BBank scenario uses the RDB DAS as a utility
>> >> >> but it
>> >> >> >>> > >> would be
>> >> >> >>> > >> >>>> nice if it could "wire in" a RDB DAS service or be
>> >> >> >>> injected with
>> >> >> >>> > a
>> >> >> >>> > >> >>>> configured DAS.  Another thing we want to eventually
>> >> >> >>> explore is
>> >> >> >>> > >> >>>> exposing
>> >> >> >>> > >> >>>> a DAS as REST-oriented services.  As we have seen
>> >> >> from the
>> >> >> >>> > parent
>> >> >> >>> > >> >>>> thread
>> >> >> >>> > >> >>>> there are almost too many possible approaches.
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> My first thought is to model the DAS as a service 
>> and
>> >> >> >>> create a
>> >> >> >>> > new
>> >> >> >>> > >> >>>> implementation kind (implementation.rdbdas).  The 
>> main
>> >> >> >>> reason
>> >> >> >>> > has
>> >> >> >>> > >> >>>> to do
>> >> >> >>> > >> >>>> with the potential declarative aspect of DAS that
>> >> >> >>> > Jeremy  mentioned
>> >> >> >>> > >> >>>> which
>> >> >> >>> > >> >>>> is all about creating data access services
>> >> >> >>> declaratively.  A new
>> >> >> >>> > >> >>>> component type and a service that we build by hand
>> >> >> would be
>> >> >> >>> > a  good
>> >> >> >>> > >> >>>> step
>> >> >> >>> > >> >>>> in this direction.
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> We might want to expose a DAS service with an
>> >> >> interface  like
>> >> >> >>> > this:
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>>     public interface RDBDASService
>> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
>> >> >> >>> > >> >>>>         DataObject execute(String commandName);
>> >> >> >>> > >> >>>>         DataObject executeSQL(String abitrarySQL);
>> >> >> >>> > >> >>>>     }
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> The service would be initialized with an optional
>> >> >> RDB DAS
>> >> >> >>> > >> config  file
>> >> >> >>> > >> >>>> that defines connection properties, a set of 
>> commands,
>> >> >> >>> etc.  So,
>> >> >> >>> > >> >>>> different services implementing the same interface
>> >> >> could be
>> >> >> >>> > >> >>>> initialized
>> >> >> >>> > >> >>>> from separate config files.
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> Eventually, we might want to build services like 
>> this:
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>>     public interface Customers_RDBDASService
>> >> >> >>> > >> >>>>         void applyChanges(DataObject graphRoot);
>> >> >> >>> > >> >>>>         DataObject getAllCustomersWithLastName 
>> (String
>> >> >> >>> > lastName);
>> >> >> >>> > >> >>>>         DataObject getAll CustomersAndOrdersForID 
>> (int
>> >> >> >>> > customerId);
>> >> >> >>> > >> >>>>     }
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> But, for this to be very useful would probably 
>> require
>> >> >> >>> some code
>> >> >> >>> > >> >>>> generation tooling.
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> Thoughts?
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> --Kevin
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> Luciano Resende wrote:
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>> > I'm starting to look in ways we could have a
>> >> >> declarative
>> >> >> >>> > DAS  and
>> >> >> >>> > >> >>>> will be
>> >> >> >>> > >> >>>> > posting my progress into the list / wiki soon...
>> >> >> >>> > >> >>>> >
>> >> >> >>> > >> >>>> > - Luciano
>> >> >> >>> > >> >>>> >
>> >> >> >>> > >> >>>> > On 10/3/06, Jeremy Boynes <jboynes@apache.org >
>> >> >> wrote:
>> >> >> >>> > >> >>>> >
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >> On Oct 3, 2006, at 5:26 PM, Jim Marino wrote:
>> >> >> >>> > >> >>>> >> >> This sounds like having cake, eating it, and
>> also
>> >> >> >>> > being  able
>> >> >> >>> > >> to
>> >> >> >>> > >> >>>> >> >> give it to a friend :-) We provide the
>> >> >> flexibility  for
>> >> >> >>> > users:
>> >> >> >>> > >> >>>> >> >> 1) to access infrastructure services through
>> >> >> >>> properties
>> >> >> >>> > >> >>>> >> > Yes for things like JPA, JDBC, etc.
>> >> >> >>> > >> >>>> >> >> 2) to reference infrastructure services 
>> through
>> >> >> >>> > inclusion  in
>> >> >> >>> > >> >>>> their
>> >> >> >>> > >> >>>> >> >> assembly
>> >> >> >>> > >> >>>> >> > If we do 1 I don't think we should do 2 (that
>> >> >> >>> doesn't stop
>> >> >> >>> > >> >>>> someone
>> >> >> >>> > >> >>>> >> > from extending Tuscany to do it though). See my
>> >> >> >>> comments
>> >> >> >>> > >> below.
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >> "Thanks for volunteering" :-)
>> >> >> >>> > >> >>>> >> If someone wants to contribute these, I think we
>> >> >> >>> > should  welcome
>> >> >> >>> > >> it
>> >> >> >>> > >> >>>> >> like we would any other contribution.
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >> >> 3) to access data through an application
>> >> >> service with
>> >> >> >>> > >> >>>> declarative
>> >> >> >>> > >> >>>> >> >> implementation by DAS
>> >> >> >>> > >> >>>> >> > Yes, that's the value I see in DAS
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >> I think this is already on the DAS folks radar.
>> >> >> >>> > >> >>>> >> --
>> >> >> >>> > >> >>>> >> Jeremy
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>> >>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >>
>> >> >> >>>
>> >> >> 
>> --------------------------------------------------------------------
>> >> >> >>> > >> -
>> >> >> >>> > >> >>>> >> 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
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>>
>> >> >> >>> > >> >>>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> > >> >>
>> >> >> >>> >
>> >> >> >>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> > >> >> 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
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> > >> >
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>> > >>
>> >> >> >>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> > >> 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
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>>
>> >> >> >>>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> >>> 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
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> ---------------------------------------------------------------------
>> >> >> 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
>> >>
>> >>
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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