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]