Re: [DAS] Refactoring DAS to allow multiple implementatons
I've added a strawman in my sandbox... Factory still needs some more work to make it more efficient and use some caching. Still looking into @Annotations as well. -- Luciano Resende http://people.apache.org/~lresende On 2/23/07, Luciano Resende [EMAIL PROTECTED] wrote: Thanks Jim I'll take a look at how SCA and JPA are working with the annotations to handle this scenarios. As for your comments : One final thing is whether the type of data source should be externalized from the client application. For example, I would expect the application should not need to know whether it is dealing with relational or LDAP data and that should instead be a concern of the mapping configuration. For example, the underlying data source could change an that should not necessarily impact business logic. JPA has this abstraction notion in its Persistence Unit concept. This is exactly what we accomplish using an external DAS config file to externalize connection information, command definitions, etc. -- Luciano Resende http://people.apache.org/~lresende http://people.apache.org/%7Elresende On 2/21/07, Jim Marino [EMAIL PROTECTED] wrote: On Feb 21, 2007, at 3:04 PM, Luciano Resende wrote: Current DAS only have one implementation supporting Relational Database (RDB). In order to allow DAS to support multiple implementations (e.g LDAP DAS proposed by Ole Ersoy : http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg13395.html) I would like to propose some changes on the DAS project structure as explained below : 1.Create an das-api project, and move the general interfaces, and maybe part of the config model to this project as well. 2.das-rdb and das-ldap would depend on this common das-api project 3.Enhance the factory pattern to handle multiple das implementations, probably implementing the service locator pattern to handle the multiple implementations. The new programming model would probably look like : DASFactory factory = DASFactory.getInstance(RBD) DAS rdbDAS = factory.creDas(...) Current unresolved issue that I have is regarding the config mode, i think this might be specific to each implementation, and I need to see what's the best approach to handle this on the das-api. I should have something in my sandbox over the weekend. Thoughts ? I'm more focused on JPA and SCA so my comments may be biased :-) I'd suggest moving away from the service locator pattern except in pure J2SE or legacy J2EE 1.4 environments and using dependency injection instead. EJB3/JPA does what you outline using annotations and it may be worth looking at in-depth since it is based on a lot of practical experience from integrating various O/R implementations in managed environments. For Tuscany, DAS could support annotations similar to what we have done with the JPA integration in trunk (i.e. the standard JPA annotations or Tuscany's @Resource) . For other environments such as J2EE 1.5, DAS could probably use the @Resource annotation. In Spring you can also define your own custom annotation type or resuse @Resource. For pure J2SE environments, or where an application wants to manage the DAS factory, you may want to consider just allowing the application to new up the DASFactory or pass some sort of Configuration object or InputStream to an XML source. This will allow you to avoid making assumptions about where configuration is located or provide an extensibility point for various packaging types. It will also allow you to avoid all sorts of nasty problems in environments such as OSGi. One final thing is whether the type of data source should be externalized from the client application. For example, I would expect the application should not need to know whether it is dealing with relational or LDAP data and that should instead be a concern of the mapping configuration. For example, the underlying data source could change an that should not necessarily impact business logic. JPA has this abstraction notion in its Persistence Unit concept. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DAS] Refactoring DAS to allow multiple implementatons
Using something like this : DASFactory.registerFactory(RDB, org.apache.tuscany.das.rdb.impl.DASFactoryImpl); Implies that the user needs to know about the impl, and register it, this was something I was avoiding to do, and was suggesting the Service locator or a different pattern to discover and register the impls. -- Luciano Resende http://people.apache.org/~lresende On 2/21/07, Adriano Crestani [EMAIL PROTECTED] wrote: I suggest: DASFactory.registerFactory(RDB, org.apache.tuscany.das.rdb.impl.DASFactoryImpl); DASFactory factory = DASFactory.getInstance(RBD) DAS rdbDAS = factory.creDas(...) would it work? Than there would be possible to add factories dynamically. Adriano Crestani On 2/21/07, Luciano Resende [EMAIL PROTECTED] wrote: Current DAS only have one implementation supporting Relational Database (RDB). In order to allow DAS to support multiple implementations (e.gLDAP DAS proposed by Ole Ersoy : http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13395.html) I would like to propose some changes on the DAS project structure as explained below : 1.Create an das-api project, and move the general interfaces, and maybe part of the config model to this project as well. 2.das-rdb and das-ldap would depend on this common das-api project 3.Enhance the factory pattern to handle multiple das implementations, probably implementing the service locator pattern to handle the multiple implementations. The new programming model would probably look like : DASFactory factory = DASFactory.getInstance(RBD) DAS rdbDAS = factory.creDas(...) Current unresolved issue that I have is regarding the config mode, i think this might be specific to each implementation, and I need to see what's the best approach to handle this on the das-api. I should have something in my sandbox over the weekend. Thoughts ? -- Luciano Resende http://people.apache.org/~lresende
Re: [DAS] Refactoring DAS to allow multiple implementatons
Thanks Jim I'll take a look at how SCA and JPA are working with the annotations to handle this scenarios. As for your comments : One final thing is whether the type of data source should be externalized from the client application. For example, I would expect the application should not need to know whether it is dealing with relational or LDAP data and that should instead be a concern of the mapping configuration. For example, the underlying data source could change an that should not necessarily impact business logic. JPA has this abstraction notion in its Persistence Unit concept. This is exactly what we accomplish using an external DAS config file to externalize connection information, command definitions, etc. -- Luciano Resende http://people.apache.org/~lresende On 2/21/07, Jim Marino [EMAIL PROTECTED] wrote: On Feb 21, 2007, at 3:04 PM, Luciano Resende wrote: Current DAS only have one implementation supporting Relational Database (RDB). In order to allow DAS to support multiple implementations (e.g LDAP DAS proposed by Ole Ersoy : http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg13395.html) I would like to propose some changes on the DAS project structure as explained below : 1.Create an das-api project, and move the general interfaces, and maybe part of the config model to this project as well. 2.das-rdb and das-ldap would depend on this common das-api project 3.Enhance the factory pattern to handle multiple das implementations, probably implementing the service locator pattern to handle the multiple implementations. The new programming model would probably look like : DASFactory factory = DASFactory.getInstance(RBD) DAS rdbDAS = factory.creDas(...) Current unresolved issue that I have is regarding the config mode, i think this might be specific to each implementation, and I need to see what's the best approach to handle this on the das-api. I should have something in my sandbox over the weekend. Thoughts ? I'm more focused on JPA and SCA so my comments may be biased :-) I'd suggest moving away from the service locator pattern except in pure J2SE or legacy J2EE 1.4 environments and using dependency injection instead. EJB3/JPA does what you outline using annotations and it may be worth looking at in-depth since it is based on a lot of practical experience from integrating various O/R implementations in managed environments. For Tuscany, DAS could support annotations similar to what we have done with the JPA integration in trunk (i.e. the standard JPA annotations or Tuscany's @Resource) . For other environments such as J2EE 1.5, DAS could probably use the @Resource annotation. In Spring you can also define your own custom annotation type or resuse @Resource. For pure J2SE environments, or where an application wants to manage the DAS factory, you may want to consider just allowing the application to new up the DASFactory or pass some sort of Configuration object or InputStream to an XML source. This will allow you to avoid making assumptions about where configuration is located or provide an extensibility point for various packaging types. It will also allow you to avoid all sorts of nasty problems in environments such as OSGi. One final thing is whether the type of data source should be externalized from the client application. For example, I would expect the application should not need to know whether it is dealing with relational or LDAP data and that should instead be a concern of the mapping configuration. For example, the underlying data source could change an that should not necessarily impact business logic. JPA has this abstraction notion in its Persistence Unit concept. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DAS] Refactoring DAS to allow multiple implementatons
Current DAS only have one implementation supporting Relational Database (RDB). In order to allow DAS to support multiple implementations (e.g LDAP DAS proposed by Ole Ersoy : http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13395.html) I would like to propose some changes on the DAS project structure as explained below : 1.Create an das-api project, and move the general interfaces, and maybe part of the config model to this project as well. 2.das-rdb and das-ldap would depend on this common das-api project 3.Enhance the factory pattern to handle multiple das implementations, probably implementing the service locator pattern to handle the multiple implementations. The new programming model would probably look like : DASFactory factory = DASFactory.getInstance(RBD) DAS rdbDAS = factory.creDas(...) Current unresolved issue that I have is regarding the config mode, i think this might be specific to each implementation, and I need to see what's the best approach to handle this on the das-api. I should have something in my sandbox over the weekend. Thoughts ? -- Luciano Resende http://people.apache.org/~lresende
Re: [DAS] Refactoring DAS to allow multiple implementatons
I suggest: DASFactory.registerFactory(RDB, org.apache.tuscany.das.rdb.impl.DASFactoryImpl); DASFactory factory = DASFactory.getInstance(RBD) DAS rdbDAS = factory.creDas(...) would it work? Than there would be possible to add factories dynamically. Adriano Crestani On 2/21/07, Luciano Resende [EMAIL PROTECTED] wrote: Current DAS only have one implementation supporting Relational Database (RDB). In order to allow DAS to support multiple implementations (e.g LDAP DAS proposed by Ole Ersoy : http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg13395.html) I would like to propose some changes on the DAS project structure as explained below : 1.Create an das-api project, and move the general interfaces, and maybe part of the config model to this project as well. 2.das-rdb and das-ldap would depend on this common das-api project 3.Enhance the factory pattern to handle multiple das implementations, probably implementing the service locator pattern to handle the multiple implementations. The new programming model would probably look like : DASFactory factory = DASFactory.getInstance(RBD) DAS rdbDAS = factory.creDas(...) Current unresolved issue that I have is regarding the config mode, i think this might be specific to each implementation, and I need to see what's the best approach to handle this on the das-api. I should have something in my sandbox over the weekend. Thoughts ? -- Luciano Resende http://people.apache.org/~lresende
Re: [DAS] Refactoring DAS to allow multiple implementatons
On Feb 21, 2007, at 3:04 PM, Luciano Resende wrote: Current DAS only have one implementation supporting Relational Database (RDB). In order to allow DAS to support multiple implementations (e.g LDAP DAS proposed by Ole Ersoy : http://www.mail-archive.com/tuscany-dev@ws.apache.org/ msg13395.html) I would like to propose some changes on the DAS project structure as explained below : 1.Create an das-api project, and move the general interfaces, and maybe part of the config model to this project as well. 2.das-rdb and das-ldap would depend on this common das-api project 3.Enhance the factory pattern to handle multiple das implementations, probably implementing the service locator pattern to handle the multiple implementations. The new programming model would probably look like : DASFactory factory = DASFactory.getInstance(RBD) DAS rdbDAS = factory.creDas(...) Current unresolved issue that I have is regarding the config mode, i think this might be specific to each implementation, and I need to see what's the best approach to handle this on the das-api. I should have something in my sandbox over the weekend. Thoughts ? I'm more focused on JPA and SCA so my comments may be biased :-) I'd suggest moving away from the service locator pattern except in pure J2SE or legacy J2EE 1.4 environments and using dependency injection instead. EJB3/JPA does what you outline using annotations and it may be worth looking at in-depth since it is based on a lot of practical experience from integrating various O/R implementations in managed environments. For Tuscany, DAS could support annotations similar to what we have done with the JPA integration in trunk (i.e. the standard JPA annotations or Tuscany's @Resource) . For other environments such as J2EE 1.5, DAS could probably use the @Resource annotation. In Spring you can also define your own custom annotation type or resuse @Resource. For pure J2SE environments, or where an application wants to manage the DAS factory, you may want to consider just allowing the application to new up the DASFactory or pass some sort of Configuration object or InputStream to an XML source. This will allow you to avoid making assumptions about where configuration is located or provide an extensibility point for various packaging types. It will also allow you to avoid all sorts of nasty problems in environments such as OSGi. One final thing is whether the type of data source should be externalized from the client application. For example, I would expect the application should not need to know whether it is dealing with relational or LDAP data and that should instead be a concern of the mapping configuration. For example, the underlying data source could change an that should not necessarily impact business logic. JPA has this abstraction notion in its Persistence Unit concept. Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
