You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2007/02/22 00:04:13 UTC
[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
Posted by Luciano Resende <lu...@gmail.com>.
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 <ad...@gmail.com> 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 <lu...@gmail.com> 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
Posted by Adriano Crestani <ad...@gmail.com>.
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 <lu...@gmail.com> 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
Posted by Luciano Resende <lu...@gmail.com>.
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 <lu...@gmail.com> 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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
>
>
Re: [DAS] Refactoring DAS to allow multiple implementatons
Posted by Luciano Resende <lu...@gmail.com>.
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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: [DAS] Refactoring DAS to allow multiple implementatons
Posted by Jim Marino <jm...@myromatours.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org