db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mahler <thm...@web.de>
Subject Re: OJB 2.0
Date Wed, 28 May 2003 06:38:30 GMT
Hi Leandro,

Leandro Rodrigo Saad Cruz wrote:
> Hi all. I'd like to start a discussion about ojb 2.0
> features/architecture needed for OJB evolution and acceptance by users
> and other developers. 

That's a good idea!

> 1 - Component model
> 
> One of the things I *really* think OJB should use is a component model
> (see http://avalon.apache.org). OJB should be assembled from components
> developed and tested individuality. The main components are already
> defined in OJB.properties, like SequenceManager and
> PersistenceBrokerImpl. This approach enables a a higher level of reuse, 
> maintainability and quality. 

 From the user input I see I doubt that we need a finer granularity of 
components. Many users are already having troubles with selecting the 
right combination of components (e.g. in AppServer environments)

I like the idea of having "kits" that assemble meaningful combinations 
of components.

I'm also in doubt that replacing the existing component/configuration 
model by Avalon components add any real value. But I'm not against such 
a refactoring.

> 2 - Object-to-Table mappings.
> 
> AFAIK, as it's written today, OJB doesn't support some types of mapping
> that should be considered depending on the application type
> (please see http://citeseer.nj.nec.com/keller97mapping.html )
> 
> Coupled with the use of components, OJB could provide different
> strategies for Object-to-Table mapping !

We are supporting
"One Inheritance Tree One Table", "One Inheritance Path One Table" and 
for a long time now (see 
http://www.objectarchitects.de/ObjectArchitects/orpatterns/)

By using the new anonymous fields feature it's now also possible to map 
"One Class One Table".
I don't see how using components could help here.
(Of course it's alsways possible to factor some behaviour out as a 
component, but where is the benefit).


> 
> 3 - API implementations
> 
> ODMG, JDO, etc, etc. You decide ! I use only PB.

+1

> 
> 4 - JMX
> 
> If OJB components were managed externally using JMX they could be used
> OTS into applications using JMX. There is no point in using another
> management infrastructure or not beeing part of one !

+1 JMX is a must these days.

> 
> Please add more features/architecture modifications !
> 
> 


Mime
View raw message