db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: OJB 2.0
Date Sat, 07 Jun 2003 19:56:18 GMT
hi,

Thomas Mahler wrote:

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

imo we should try to split up PersistenceBroker  in some smaller 
components (i do not yet know which :( ).  another  refactoring
could be to use jakarta.commons whereever possible (i'm thinking about 
logging)

>
>
>> 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).
>
we currently have a problem when mixing the two supported mappings :(

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


imo jdo is the most important (after  pb of course) i don't know about odmg.

>
>>
>> 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 !
>>
>>
>
jakob



Mime
View raw message