Jeremy Boynes wrote:
The danger with using too much JMX is that when components start
talking to each other using JMX, then it's very difficult to undo at a
later stage.
Difference between components managing each other (for which JMX may be
good), and invoking each other (for which an alternative may be better).
We need to keep this difference in mind.
We also need to be careful about coupling of implementations and making sure
we keep invocations detached (to allow for redeployment). JMX enforces this,
any other framework needs to support it as well.
Coding to interfaces does a good job of managing these things. As long as
your code *never* does a cast to the interface like this:
((MyImpl)service).doSomethingNotInInterface();
That is REALLY BAD. You will never be able to have loose coupling, or insert
interceptors properly with that approach. When the interface covers the entire
contract, components can use each other and even be completely replaced with
something new and still function.
The MAJOR RED FLAG I saw is the notion of components _managing_ each other.
It is the Container's job to manage components. Period. No component should
manage another component unless it in turn is a container for the managed
component. For example:
BAD
---
+--------------+
..| Container |..
. +------+-------+ .
. | .
v +------+-------+ v
+----+---+ +--------+
| Comp 1 |.....>| Comp 2 |
+--------+ +--------+
(the dotted line is management)
GOOD/ACCEPTIBLE
---------------
+--------------+
| Container |
+------+-------+
. |
. +----+---+
.>| Comp 1 |..
+----+---+ .
| .
+----+---+ .
| Comp 2 |<.
+--------+
In other words, a heirarchy of components is much easier to work with, develop,
and debug than any component usurping the container's job and cause
unpredictable results. Not to mention it complicates the security mechanisms
much more than necessary.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
