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