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: [EMAIL PROTECTED]
>>> > >> >> For additional commands, e-mail: tuscany-dev-
>>> [EMAIL PROTECTED]
>>> > >> >>
>>> > >> >
>>> > >> >
>>> > >> >
>>> >
>>> ---------------------------------------------------------------------
>>> > >> > To unsubscribe, e-mail: [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]
