Hey
marc fleury wrote:
> > On the other side I think the MBeans should be as independent from each
> > other as possible because this allows the user (administrator) of such
> > a system (like jBoss) to define the system how he likes. When a MBean
> > is able to detect MBean dynamically (MBean Interface) then the
> > administrator
> > can dynamically load or unload MBeans to the actual needs instead of
> > changing the jboss.conf file, shut down and start up the server.
> >
>
> You know it sort of makes sense, I have a natural dislike for graphs anyway
> :)
>
> So you would define the initialization that depends on other services in a
> method called only when the set of services that it needs have been
> initialized. Of course that means that you would want to register interest
> with all the services you are looking for, and deal with multiple callbacks
> to be sure to trigger that operation only and only when ALL the services
> have been offered.
FWIW, I had exactly this back in the XS days :-) Way cool: I could start
"server control" (the top node), which caused logging to start, which
caused.., and so on.. kablam, everything is started :-)
> At the same time I would see for a nice service where you provide a set of
> services that are needed for a particular configuration. You would be
> notified immediately through a boolean return that all the services you
> requested are already on line. And what you register is a callback
> interface with methods such as "public void allOnline()", equivalent of
> "dinner is served" for the service, but also maybe a "public boolean
> serviceGoingDown(Service orSomething)" as soon as one of the services in the
> required set is going down. This way you don't have to code the
> notifications yourself, it is a JMXBean of sorts.
Nah, could be even simpler. When the requirements are set the nice
service could dynamically invoke "start" on the service. No need for the
actual service to be involved at all. And that's the neat thing: the
service that has the dependencies does not have to be changed *at all*.
I think this is how the relationship service in JMX is supposed to work;
if it doesn't, we'll make one like that.
> If this type of interface takes care of most scenarios, it might be helpful
> to give this "Set" approach a try at beating the "graph" approach. As you
> point out Andy it's main advantages is increased simplicity and robustness
> in defining depencies (a Set with all required services as opposed to a
> "parent-child" graph), and also that these operations can be done
> programmaticaly at run-time and not through the conf file. Can somebody
> submit a case to me when a graph dependency cannot be implemented by a nice
> and simple Set approach as pointed out above?
Well, as above I have already tried this in XS, and although the
implementation is set-based, the behaviour "looks" graph-based. It's
very cool, and simple to do as well.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
