> Thanks
>
> - Venkat
>
> On 10/25/06, Kevin Williams <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >>
>> >>>
>> >>> Hi ,
>> >>> I am also following up another thread
>> >>> http://www.mail-archive.com/[email protected]/
>> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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/[EMAIL PROTECTED] %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/[email protected]/
>> msg08833.html
>> >>> > >> >>>
>> >>> > http://www.mail-archive.com/[email protected]/
>> 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
>> >>> > >> >>> ([EMAIL PROTECTED] 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.g first
>> >>> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] >
>> 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-
>> >>> [EMAIL PROTECTED]
>> >>> > >> >>>> >> For additional commands, e-mail:
>> >>> > [EMAIL PROTECTED]
>> >>> > >> >>>> >>
>> >>> > >> >>>> >>
>> >>> > >> >>>> >
>> >>> > >> >>>>
>> >>> > >> >>>>
>> >>> > >> >>>>
>> >>> > >> >>>>
>> >>> > >>
>> >>>
>> --------------------------------------------------------------------
>> >>> > >> -
>> >>> > >> >>>> To unsubscribe, e-mail: tuscany-dev-
>> >>> [EMAIL PROTECTED]
>> >>> > >> >>>> For additional commands, e-mail: tuscany-dev-
>> >>> [EMAIL PROTECTED]
>> >>> > >> >>>>
>> >>> > >> >>>>
>> >>> > >> >>>
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >> >>
>> >>> > >> >>
>> >>> >
>> >>>
>> ---------------------------------------------------------------------
>> >>> > >> >> To unsubscribe, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >>> > >> >> For additional commands, e-mail: tuscany-dev-
>> >>> [EMAIL PROTECTED]
>> >>> > >> >>
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> >
>> >>>
>> ---------------------------------------------------------------------
>> >>> > >> > To unsubscribe, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >>> > >> > For additional commands, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >> >
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>> > >>
>> >>>
>> ---------------------------------------------------------------------
>> >>> > >> To unsubscribe, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >>> > >> For additional commands, e-mail: tuscany-dev-
>> [EMAIL PROTECTED]
>> >>> > >>
>> >>> > >>
>> >>> > >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >>> >
>> >>> >
>> >>>
>> >>>
>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> >>> For additional commands, e-mail: [EMAIL PROTECTED]
>> >>>
>> >>>
>> >>>
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> >
>> >
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
