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