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]
