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]
>>
>> 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: [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]
