Hi Peter,
sorry for my delay, but I am in a little hurry right now ...
btw:
saw a "Peter Donald" as a member of the Isolation API JSR expert group -
Is it you?
I like the current version, and am very curious about the impact on
large server installments.
Also want to play with it on the jikes rvm (which is a lovely vm for
testing purposes). Especially class caching could be a very hot
topic.... although sometimes tricky to implement.
Am Son, 2003-01-19 um 10.27 schrieb Peter Donald:
> On Fri, 17 Jan 2003 20:52, Peter Donald wrote:
> > In most cases I consider JMX great for coarser grained components. In the
> > end JMX is just the naming/plumbing part of "application server". I think
> > it is great from a management perspective and for starting up coarse
> > grained components but I don't think it works for fine grained components.
> > In coarse grain components the slight overhead causes no worrys.
>
> A few people have asked me to describe what the difference is between coarse
> and fine grained components. However I don't think there is any hard and fast
> rules for that.
I think so too. I see coarse grained components as subsystems, that
appear a kind of closed to their environment and other systems. Although
they can depend on another.
>
> I guess I see things that are mostly "standalone" components as things that
> would be candidates for JMX deployment/management. ie
> * web server
> * mail server
> * directory server
> * database server
>
> Most of them are relatively independent from each other. Interesting scenarios
> happen when you incorporate components such as a web interface to directory
> server. This "component" depends upon both the web server and directory
> server components. I would still make it controllable by JMX but it would be
> the deployer or the unit itself that would have to manage dependencies.
nice definition - agree with you.
Coarse grained for instance could mean then
- very few data is shared (better no data)
- few well defined dependencies
- highly plugable support
- communicate solely via public interfaces (no internal short cuts)
[ some of the above points come from an ibm team @ javaone 2000, which I
didn't attend but downloaded their slides ;-) ]
The problem with definitions like the one I made above is that they tend
to be recursive with no anchor - like "highly pluggable" is that the
requirement for or the result of being coarse grained ?!
You mentioned that you have been working on a jmx "micro kernel" tuned
avalon container - that sounds interesting to me.
Don't know that much about the ongoing blocks discussion (especially
from cocoon-committers), but perhaps blocks (which appear to me as a
kind of subsystem) could be hot deployed via such a construct - as
inter-block communication is rather scarce compared to inner-block
communication - but as I said : don't know that much about the
requirements here.
bye
-- Jakob
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
