geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: FW: JMX as a kernel (was: Re: geronimo and avalon?)
Date Fri, 08 Aug 2003 21:01:25 GMT
Noel J. Bergman wrote:

> Might I suggest that Berin and Stephen pop over to geronimo-dev and talk
> about how the Merlin technology supports this vision?
> 
> You might also want to add it to the AvailableTechnologies page under the
> ApacheJ2EE project Wiki.

Ok.

> 
> 	--- Noel
> 
> -----Original Message-----
> From: Jason Dillon [mailto:jason@coredevelopers.net]
> Sent: Friday, August 08, 2003 15:06
> To: geronimo-dev@incubator.apache.org
> Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?)
> 
> 
> I think that it would be best for Geronimo not to use JMX as the
> component bus, but use something else and then adapt JMX to it, as we
> must have JMX support.
> 
> That said there are so many different component containers out there,
> it is hard to find the one which suites our needs and/or requires the
> least amount of hacking to get it to function.

Yep, It all matters what supports the project best.

> 
> I have had a look over several containers, HiveMind being one of them,
> though I have not really spent much time looking at the details.

I am curious as to your feelings on HiveMind.  I haven't had much look
at it beyond its documentation.

> 
> We need something which is small, fast, can plug in any sort of
> component, which will support linking component instances to avoid any
> hard coupling.  It needs to be able to support elba/jboss style
> deployment and class loading semantics.  It needs to be able to be
> adapted to JMX (possibly other protocols like SNMP too).  It would be
> beneficial if it could provide dependency management as well as
> component state management, or at the minimum be easy to provide layers
> on top which can provide this.  It must not impose many restrictions on
> how it can be used, nor should it impose any other application
> functionality short of managing components.

I think almost any of the Avalon containers can satisfy these requirements.

* Small, fast: the Fortress and Merlin containers have a fairly small footprint.
       Fortress also supports asynchronous component initialization so that all
       components are started up using a controlled number of threads.  This
       feature will be soon ported to Merlin which looks like a better fit.

* Loose Coupling: The Avalon project has developed all their
     components/containers to avoid hard coupling.  As long as you code to an
     interface, all is well.  In fact, the actual implementation of a component
     is decided at runtime, not build time.  This allows easy upgrades.

* JMX integration: The Avalon Phoenix container is the only one that currently
     supports this, but the feature will be ported to Merlin in the near future.
     Basically, you can mark a component's interface with some @mx-*** type
     javadoc tags, and the container will dynamically build the JMXBeans and
     publish them.

* Dependency management: Avalon Fortress, Merlin, and Phoenix all handle this
     requirement well.  Merlin goes so far as to allow you to specify a service's
     version.  They each test to make sure all *required* dependencies are
     available before starting up.  It also accounts for *optional* dependencies.
     They also find any *circular* dependencies.  In fact, this is probably one
     of the most mature areas of the containers.

* Additional layers: There are facilities to extend the lifecycle of components,
     and provide runtime features.  More info on the exact requirement would be
     needed before I can provide more info.

> 
> This is just a rough blurb about the requirements for the geronimo
> component container, I will try to write up something more formal and
> drop it into the wiki in the next day or so... along with the system
> loading, configuration and deployment sub-systems.

I think Avalon Merlin has some pretty good features to help in these
areas.

> 
> I believe that the initial geronimo/elba hybrid will probably use JMX,
> as it already works, but we will want to replace this with a more
> robust system as soon as we can sort out how to build it.  Anyways, I
> will put up some wiki docs and then perhaps some of the folks who are
> more knowledgeable about these different containers can comment.  I do
> not want to reinvent the wheel, but if the wheel does not fit the wagon
> then we may just have to make a new one.

If you would like more info, let me know.

> 
> --jason
> 
> PS. Can someone write up something about the current state of the major
> component containers out there with a feature blurb... no soap boxes,
> just the facts jack.

I can add a feature blurb on the WIKI if you point me to the right page.

> 
> 
> On Friday, August 8, 2003, at 10:33  PM, Howard M. Lewis Ship wrote:
> 
> 
>>I'm going to plug HiveMind again here.
>>
>>Looking over what JBoss has done with JMX as a Microkernel, I have a
>>couple of key issues.
>>
>>First off, the code abstraction that requires you to invoke methods on
>>MBeans using an interface
>>like reflection.  Yes, there are workarounds to that (such as using
>>dynamic Proxys) but if a Java
>>object is invoking a method on another Java object within the same JVM
>>why make it look like some
>>low-level RPC call?
>>
>>Second, configuration of MBeans leaves a bit to be desired.  I suppose
>>it works well for simple
>>properties, but once you get to anything complicated, you start seeing
>>more and more ad-hoc
>>ugliness.  Among other things, you end up endlessly rehashing the code
>>to translate an MBean name
>>into an instance that methods can be invoked on.
>>
>>Intrinsic to HiveMind are concepts adapted from Eclipse Plugins:
>>extension points and extensions.
>>Extension points define a point where modules can plug into other
>>modules; an extension point
>>defines a kind of XML schema for contributions.  Extensions are
>>snippets of XML that plug into
>>extension points.
>>
>>The end result is something very flexible, and very supportive of a
>>very complex environment, yet
>>very "lean and mean" at the same time.
>>
>>http://jakarta.apache.org/commons/sandbox/hivemind
>>
>>--
>>Howard M. Lewis Ship
>>Creator, Tapestry: Java Web Components
>>http://jakarta.apache.org/tapestry
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
>>>Sent: Friday, August 08, 2003 8:55 AM
>>>To: geronimo-dev@incubator.apache.org
>>>Subject: Re: JMX as a kernel (was: Re: geronimo and avalon?)
>>>
>>>
>>>
>>>On Friday, Aug 8, 2003, at 13:05 Europe/London, Leo Simons wrote:
>>>
>>>
>>>>Why JMX Is Not A Very Good Kernel
>>>>------------------
>>>
>>>I'd definitely concur with this. Put it better than I could
>>>have done,
>>>too :-)
>>>
>>>Note that just because JMX isn't a kernel, doesn't mean that
>>>some parts
>>>of it can't be configured with JMX on top. It just means that not
>>>everything has to be JMX.
>>>
>>>Building a tighter smaller kernel gives me a gut feeling that it will
>>>run faster, though I've yet to convert that into measurable
>>>figures :-)
>>>But reducing (unnecessary) layers is bound to speed it up...
>>>
>>>One fear I have of using JMX as a kernel is that all the intra-kernel
>>>messages would be sent using JMX. If JMX isn't used in the
>>>kernel, then
>>>they can be made more efficient/optimised; but JMX can be put as a
>>>layer on top of the features (e.g. EJBs) that need
>>>configuring/managing
>>>by JMX.
>>>
>>>Definitely vote +1 for not using JMX 'just because'
>>>
>>>Alex.
>>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
> 
> 
> 


-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


Mime
View raw message