Leandro Rodrigo Saad Cruz wrote:
>Hi all. I proposed to avalonize OJB ( http://jakarta.apache.org/ojb )
>but I need some help to decompose OJB into components. ** I'm not asking
>you to help me do that ** I just want some advice on how to do it !
>
>OJB has 3 main APIs
> - ODMG ( uses PB )
> - JDO ( uses PB )
> - PB
>
>I know I should create a interface for every api and treat them as
>components. But what about the other components this SPIs use ?
>(ObjectFactory, Cache, etc )
>can I create/hold a ComponentManager for every API ?
>
>What if I wan't to embed OJB apis as components into another app that is
>using avalon and has it's own ComponentManager ?
>
>
I don't know anything about OJB other than a 15 second look at the
web-site you referenced above. However, for what its worth - here are
some suggstions concerning a generic approach (more about components
that anyting to do with OJB):
1. from you knowlege of the specifications, try to
identify what the services are (i.e. those interfaces
that will be exposed to client code)
2. try to seperate these services out so that you have
logical collections of services that are associated
due to some computation reason
3. these collections will largely define the the cause
grain component model - for each group the services
reflect the service interfaces that the component will
provide
4. using IOC principals figure out what the depedencies
are for each of the components (i.e. make the assumption
that the component is a managed object and its manager
is going to supply it with everything it needs - but to do
this, the manager is going to need a declaration of this)
5. on completion of point 4 you starting to get a picture of
the finer grain components youg going to need to put in
place to properly support the primary components - you
keep going until you have a complete set of components
with a clear set of service interfaces and depedency
relationships
6. when you building the system and you should think about
what part of the system is actually a container (i.e. the
the overall manager) - in some systems a generic container
is not sufficient and you may want to roll your own or
extend something like the Merlin DefaultContainer - if you
use something like Merlin you can take advantage of the
fact that components are not instantiated until needed,
but when you do actually invoke lookup, this will
automatically trigger formal establishment of the component
and all of the depedencies that need to established - so
in that sort of a scenario its a good idea to hold a
reference to the supplied manager and only invoke lookup
when its actually needed
One last point - don't use the ComponentManager stuff - user
the ServiceManager package instead. Its basically the same except
that you don't have the constraint of being limited to something
implemeting Component.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
