You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Christian Essl <ch...@yahoo.de> on 2003/09/23 12:29:05 UTC
[HiveMind] the uber Registry
Sorry if I fleed you with (useless?) ideas, but you know they just come up
when I look in the code and compare it to other apis (especially JBoss JMX)
.
As I see HiveMind is a cool combination of a very good configuration api
and a good but improveable service-manager, which allows to split up your
app in small components avoiding the uber-objects. My problem is that the
Registry with all its impl helper classes is - while it is also currently
well designed - just such a uber-object. It does everything from registring
components, managing configuration, managing services ... and more to come.
And this leads of course to all the disadvantes of uber-objects especially
hard to understand, maintain and improve.
So I would suggest to do some refactoring. I suggest to make the Registry
realy just a map of service-ids to ServicesExtendsionPoints and factor
everything else out in a set of core services (an idea taken from JMX).
This would look like this:
1.) Registry: ServiceExtensionPoints can be registerd and retrieved by id -
except of some convinience-methods nothing else. It also builds up in the
constructor the following core-services. For backward compatibility it also
holds a map of Modules.
2.) ConfigurationService: is a map of ConfigurationPoints (like the
registry again by id)
3.) DependencyService: keeps information about dependencies between
services. It only holds the service ids. It does not 'manage' the services.
It only gives information about dependencies.
4.) XMLParserService: takes a Location or a ClassResolver and produces a
set of ModuleDescriptors
5.) ModuleLoaderService: Does generally what the RegistryBuilder does now.
It takes a set of ModuleDescriptors and checks if everything is ok
(references etc). Than adds ConfigurationPoints to the
ConfigurationService, ServiceExtensionPoints to the Registry and
dependencies to the Denpendency service.
6.) (may be: ShutdownService): manages a clean shut-down using the
DependencyService (However I am not so sure how to implement this).
7.) (may be: EventService): fires core events (starting, adding modules,
adding Configurations, shutdown etc).
In bootstrap the user first constructs a new Registry and than uses the
XMLParserService and the ModuleLoaderService to add her modules. (Of course
there should be static convinience methods).
As you can see I also suggest to remove this Module one to one mapping in
the registry. That's because I think the module (contrary to eclipse) is
more or less a convinient namespace declaration in the descriptor with an
attached ClassLoader. When the system is running the modules-mapping is not
realy needed anymore. If someone needs the module (Location in exceptions,
the Classloader) the module can always be retrieved from the
ExtensionPoint. This makes (first and most important) the code less
complex, is more efficient (no double lookup for a service) and is less
memory intensive. (If someone needs to lookup services or config-points by
module I would suggest to add a search core-service, which could provide
many more lookup possibilities - ie by Service interface, meta-information
etc).
I also think this refactoring is not to hard to do. Most of the real taff
stuff like XMLParsing, Rule processing, ServiceExtensionPointImpl etc can
be reused straight away (As said HiveMind is also currently very well
designed). Regarding backward compatibility for current Services and the
bootstrapp process nothing realy changes . The BuilderFactory can be easily
rebuild to be a helper which builds a Registry and just calls in the core-
Services. The same also applies to the registry and the Module
implementation. I love HiveMind it is realy cool and clever. It is
also well designed and this is just a bit of a design-improvent (it does
not add any functionlity). However I think this change is worth doing to
make it easier for newbies (maybe comming from the JMX side) to understand
and improve HiveMind. Therefore I want to do the changes if no one vetos.
I just want to you to ask if you think it is worth doing and if I can start
coding or should wait a bit.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] the uber Registry
Posted by Christian Essl <ch...@yahoo.de>.
> Hold off for a bit until I get a grasp of where you're headed.
Thank you for your answer and sorry that I did not realy make so clear what
it is good for. My suggestion may look big but is rather small.
>
> I'm concerned about some lifecycle issues; especially maintaining good
> support for contributions and
> substitution symbols.
Sorry that I did not make clear that I did not suggest any additional
functionality like late(r) loading of modules. I just wanted to suggest
some refactoring which makes the addition of new functionalities to the
core easier - like late loading of mudules. Ie for now the
ModuleLoaderService would just allow to be called once and later this might
be changed. I think the current enforcment of a closed Registry through the
api just hinders furhter evolution of the Service management. Currently it
is also not so clean to add ie a DependencyService - needed for clean shut-
down - or as you suggest a service which manages transformers.
When I say core services, I do not mean services which are loaded like
'normal' services through an xml description. I mean simple Singletons
which are directly constructed by the Registry and which are registered in
the Registry just to be accesible like normal Services. Core-services are
also not meant to be independent normal services. They are part of the
core, are dependent on each other and are integrated with the core. In my
view they are just a standard mean of extending the core in a HiveMinded
fashion. I think that fits better in the overall HiveMind way.
>
> You add module A and module B and build some services; then add module C
> which makes contributions
> that affect the services in A and B ... the current "lock down" design
> ensures consistency.
>
As said I have not realy thought of late loading of modules. However as I
see regarding services its not realy a problem. Concerning contirbutions
its a bit more complicated. I would say that the new ConfigurationService
just fires events when new contirubtions are added to an extension point.
(But that's certainly not the whole story.)
> I was thinking in the shower about some issues; that it would be nice to
> build even more of HiveMind
> in HiveMind; for example, be able to make a <contribution> to define new
> rules and translators,
> rather than making them (basically) statically defined. I kept treading
> down some chicken-or-the-egg
> bootstrap problems.
That's an excellent idea and also a good example for me. Make a core-
service (RuleTranslatorService) and change ModuleLoaderService that it does
as first thing give the ModuleDescriptors to the RuleTranslatorService. The
RuleTranslatorService than scans all the Contributions for well defined ids
(nameing the rules and translators), removes them from the description and
adds to itself the translators. The ConfigurationPointImpl will than use
the RuleTranslatorService.
>
> At the same time, I'd like to know about the use cases you feel could be
> addressed better,
> especially from the point-of-view of a HiveMind user.
>
I don't suggest additional functionality so also no new use-cases for the
user. The main additional functionality I want to build on top of this is a
clean shut-down process (without it no ConnectionPools -> no DAOs -> no
need for TransactionInterceptors; also security checking will need some
Resource-Service to identify users and their permissions). For doing that I
looked at JBoss-JMX which inspired this. I looked at JBoss because as I see
it is currently the functionally most advanced open Service-Manager and JMX
is a good specification - but just not thought as a ServiceManager.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [HiveMind] the uber Registry
Posted by Christian Essl <ch...@yahoo.de>.
> Hold off for a bit until I get a grasp of where you're headed.
Thank you for your answer and sorry that I did not realy make so clear what
it is good for. My suggestion may look big but is rather small.
>
> I'm concerned about some lifecycle issues; especially maintaining good
> support for contributions and
> substitution symbols.
Sorry that I did not make clear that I did not suggest any additional
functionality like late(r) loading of modules. I just wanted to suggest
some refactoring which makes the addition of new functionalities to the
core easier - like late loading of mudules. Ie for now the
ModuleLoaderService would just allow to be called once and later this might
be changed. I think the current enforcment of a closed Registry through the
api just hinders furhter evolution of the Service management. Currently it
is also not so clean to add ie a DependencyService - needed for clean shut-
down - or as you suggest a service which manages transformers.
When I say core services, I do not mean services which are loaded like
'normal' services through an xml description. I mean simple Singletons
which are directly constructed by the Registry and which are registered in
the Registry just to be accesible like normal Services. Core-services are
also not meant to be independent normal services. They are part of the
core, are dependent on each other and are integrated with the core. In my
view they are just a standard mean of extending the core in a HiveMinded
fashion. I think that fits better in the overall HiveMind way.
>
> You add module A and module B and build some services; then add module C
> which makes contributions
> that affect the services in A and B ... the current "lock down" design
> ensures consistency.
>
As said I have not realy thought of late loading of modules. However as I
see regarding services its not realy a problem. Concerning contirbutions
its a bit more complicated. I would say that the new ConfigurationService
just fires events when new contirubtions are added to an extension point.
(But that's certainly not the whole story.)
> I was thinking in the shower about some issues; that it would be nice to
> build even more of HiveMind
> in HiveMind; for example, be able to make a <contribution> to define new
> rules and translators,
> rather than making them (basically) statically defined. I kept treading
> down some chicken-or-the-egg
> bootstrap problems.
That's an excellent idea and also a good example for me. Make a core-
service (RuleTranslatorService) and change ModuleLoaderService that it does
as first thing give the ModuleDescriptors to the RuleTranslatorService. The
RuleTranslatorService than scans all the Contributions for well defined ids
(nameing the rules and translators), removes them from the description and
adds to itself the translators. The ConfigurationPointImpl will than use
the RuleTranslatorService.
>
> At the same time, I'd like to know about the use cases you feel could be
> addressed better,
> especially from the point-of-view of a HiveMind user.
>
I don't suggest additional functionality so also no new use-cases for the
user. The main additional functionality I want to build on top of this is a
clean shut-down process (without it no ConnectionPools -> no DAOs -> no
need for TransactionInterceptors; also security checking will need some
Resource-Service to identify users and their permissions). For doing that I
looked at JBoss-JMX which inspired this. I looked at JBoss because as I see
it is currently the functionally most advanced open Service-Manager and JMX
is a good specification - but just not thought as a ServiceManager.
RE: [HiveMind] the uber Registry
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Hold off for a bit until I get a grasp of where you're headed.
I'm concerned about some lifecycle issues; especially maintaining good support for contributions and
substitution symbols.
You add module A and module B and build some services; then add module C which makes contributions
that affect the services in A and B ... the current "lock down" design ensures consistency.
I was thinking in the shower about some issues; that it would be nice to build even more of HiveMind
in HiveMind; for example, be able to make a <contribution> to define new rules and translators,
rather than making them (basically) statically defined. I kept treading down some chicken-or-the-egg
bootstrap problems.
At the same time, I'd like to know about the use cases you feel could be addressed better,
especially from the point-of-view of a HiveMind user.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Christian Essl [mailto:christianessl@yahoo.de]
> Sent: Tuesday, September 23, 2003 6:29 AM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] the uber Registry
>
>
> Sorry if I fleed you with (useless?) ideas, but you know they
> just come up
> when I look in the code and compare it to other apis
> (especially JBoss JMX)
> .
>
> As I see HiveMind is a cool combination of a very good
> configuration api
> and a good but improveable service-manager, which allows to
> split up your
> app in small components avoiding the uber-objects. My problem
> is that the
> Registry with all its impl helper classes is - while it is
> also currently
> well designed - just such a uber-object. It does everything
> from registring
> components, managing configuration, managing services ... and
> more to come.
> And this leads of course to all the disadvantes of
> uber-objects especially
> hard to understand, maintain and improve.
>
> So I would suggest to do some refactoring. I suggest to make
> the Registry
> realy just a map of service-ids to ServicesExtendsionPoints
> and factor
> everything else out in a set of core services (an idea taken
> from JMX).
> This would look like this:
>
> 1.) Registry: ServiceExtensionPoints can be registerd and
> retrieved by id -
> except of some convinience-methods nothing else. It also
> builds up in the
> constructor the following core-services. For backward
> compatibility it also
> holds a map of Modules.
>
> 2.) ConfigurationService: is a map of ConfigurationPoints (like the
> registry again by id)
>
> 3.) DependencyService: keeps information about dependencies between
> services. It only holds the service ids. It does not 'manage'
> the services.
> It only gives information about dependencies.
>
> 4.) XMLParserService: takes a Location or a ClassResolver and
> produces a
> set of ModuleDescriptors
>
> 5.) ModuleLoaderService: Does generally what the
> RegistryBuilder does now.
> It takes a set of ModuleDescriptors and checks if everything is ok
> (references etc). Than adds ConfigurationPoints to the
> ConfigurationService, ServiceExtensionPoints to the Registry and
> dependencies to the Denpendency service.
>
> 6.) (may be: ShutdownService): manages a clean shut-down using the
> DependencyService (However I am not so sure how to implement this).
>
> 7.) (may be: EventService): fires core events (starting,
> adding modules,
> adding Configurations, shutdown etc).
>
> In bootstrap the user first constructs a new Registry and
> than uses the
> XMLParserService and the ModuleLoaderService to add her
> modules. (Of course
> there should be static convinience methods).
>
> As you can see I also suggest to remove this Module one to
> one mapping in
> the registry. That's because I think the module (contrary to
> eclipse) is
> more or less a convinient namespace declaration in the
> descriptor with an
> attached ClassLoader. When the system is running the
> modules-mapping is not
> realy needed anymore. If someone needs the module (Location
> in exceptions,
> the Classloader) the module can always be retrieved from the
> ExtensionPoint. This makes (first and most important) the code less
> complex, is more efficient (no double lookup for a service)
> and is less
> memory intensive. (If someone needs to lookup services or
> config-points by
> module I would suggest to add a search core-service, which
> could provide
> many more lookup possibilities - ie by Service interface,
> meta-information
> etc).
>
> I also think this refactoring is not to hard to do. Most of
> the real taff
> stuff like XMLParsing, Rule processing,
> ServiceExtensionPointImpl etc can
> be reused straight away (As said HiveMind is also currently very well
> designed). Regarding backward compatibility for current
> Services and the
> bootstrapp process nothing realy changes . The BuilderFactory
> can be easily
> rebuild to be a helper which builds a Registry and just calls
> in the core-
> Services. The same also applies to the registry and the Module
> implementation. I love HiveMind it is realy cool and
> clever. It is
> also well designed and this is just a bit of a
> design-improvent (it does
> not add any functionlity). However I think this change is
> worth doing to
> make it easier for newbies (maybe comming from the JMX side)
> to understand
> and improve HiveMind. Therefore I want to do the changes if
> no one vetos.
>
> I just want to you to ask if you think it is worth doing and
> if I can start
> coding or should wait a bit.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [HiveMind] the uber Registry
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Hold off for a bit until I get a grasp of where you're headed.
I'm concerned about some lifecycle issues; especially maintaining good support for contributions and
substitution symbols.
You add module A and module B and build some services; then add module C which makes contributions
that affect the services in A and B ... the current "lock down" design ensures consistency.
I was thinking in the shower about some issues; that it would be nice to build even more of HiveMind
in HiveMind; for example, be able to make a <contribution> to define new rules and translators,
rather than making them (basically) statically defined. I kept treading down some chicken-or-the-egg
bootstrap problems.
At the same time, I'd like to know about the use cases you feel could be addressed better,
especially from the point-of-view of a HiveMind user.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Christian Essl [mailto:christianessl@yahoo.de]
> Sent: Tuesday, September 23, 2003 6:29 AM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] the uber Registry
>
>
> Sorry if I fleed you with (useless?) ideas, but you know they
> just come up
> when I look in the code and compare it to other apis
> (especially JBoss JMX)
> .
>
> As I see HiveMind is a cool combination of a very good
> configuration api
> and a good but improveable service-manager, which allows to
> split up your
> app in small components avoiding the uber-objects. My problem
> is that the
> Registry with all its impl helper classes is - while it is
> also currently
> well designed - just such a uber-object. It does everything
> from registring
> components, managing configuration, managing services ... and
> more to come.
> And this leads of course to all the disadvantes of
> uber-objects especially
> hard to understand, maintain and improve.
>
> So I would suggest to do some refactoring. I suggest to make
> the Registry
> realy just a map of service-ids to ServicesExtendsionPoints
> and factor
> everything else out in a set of core services (an idea taken
> from JMX).
> This would look like this:
>
> 1.) Registry: ServiceExtensionPoints can be registerd and
> retrieved by id -
> except of some convinience-methods nothing else. It also
> builds up in the
> constructor the following core-services. For backward
> compatibility it also
> holds a map of Modules.
>
> 2.) ConfigurationService: is a map of ConfigurationPoints (like the
> registry again by id)
>
> 3.) DependencyService: keeps information about dependencies between
> services. It only holds the service ids. It does not 'manage'
> the services.
> It only gives information about dependencies.
>
> 4.) XMLParserService: takes a Location or a ClassResolver and
> produces a
> set of ModuleDescriptors
>
> 5.) ModuleLoaderService: Does generally what the
> RegistryBuilder does now.
> It takes a set of ModuleDescriptors and checks if everything is ok
> (references etc). Than adds ConfigurationPoints to the
> ConfigurationService, ServiceExtensionPoints to the Registry and
> dependencies to the Denpendency service.
>
> 6.) (may be: ShutdownService): manages a clean shut-down using the
> DependencyService (However I am not so sure how to implement this).
>
> 7.) (may be: EventService): fires core events (starting,
> adding modules,
> adding Configurations, shutdown etc).
>
> In bootstrap the user first constructs a new Registry and
> than uses the
> XMLParserService and the ModuleLoaderService to add her
> modules. (Of course
> there should be static convinience methods).
>
> As you can see I also suggest to remove this Module one to
> one mapping in
> the registry. That's because I think the module (contrary to
> eclipse) is
> more or less a convinient namespace declaration in the
> descriptor with an
> attached ClassLoader. When the system is running the
> modules-mapping is not
> realy needed anymore. If someone needs the module (Location
> in exceptions,
> the Classloader) the module can always be retrieved from the
> ExtensionPoint. This makes (first and most important) the code less
> complex, is more efficient (no double lookup for a service)
> and is less
> memory intensive. (If someone needs to lookup services or
> config-points by
> module I would suggest to add a search core-service, which
> could provide
> many more lookup possibilities - ie by Service interface,
> meta-information
> etc).
>
> I also think this refactoring is not to hard to do. Most of
> the real taff
> stuff like XMLParsing, Rule processing,
> ServiceExtensionPointImpl etc can
> be reused straight away (As said HiveMind is also currently very well
> designed). Regarding backward compatibility for current
> Services and the
> bootstrapp process nothing realy changes . The BuilderFactory
> can be easily
> rebuild to be a helper which builds a Registry and just calls
> in the core-
> Services. The same also applies to the registry and the Module
> implementation. I love HiveMind it is realy cool and
> clever. It is
> also well designed and this is just a bit of a
> design-improvent (it does
> not add any functionlity). However I think this change is
> worth doing to
> make it easier for newbies (maybe comming from the JMX side)
> to understand
> and improve HiveMind. Therefore I want to do the changes if
> no one vetos.
>
> I just want to you to ask if you think it is worth doing and
> if I can start
> coding or should wait a bit.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>