You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Leo Simons <le...@apache.org> on 2003/09/13 16:20:49 UTC
[HiveMind] hivemind and avalon, revisited
Henri Yandell wrote:
>>So how is Hivemind different to Avalon?
Here we go again :D. I'll join in here to help get a sensible answer.
Lets see if we can document it somewhere this time....
http://nagoya.apache.org/wiki/apachewiki.cgi?HiveMind/HiveMindAndAvalon
(same content as this e-mail posted to the wiki)
....it's a more involved question than it seems...
The problem domain for HiveMind and "core" Avalon is nearly the same;
the general role of HiveMind in any application will be fairly similar
to that of something like Avalon-Fortress or Avalon-Excalibur: providing
configuration management, dependency setup, component instantiation, etc
etc.
= Design differences =
Avalon takes that problem domain, then adds a strong "containment"
concept (Avalon-Phoenix / Avalon-Merlin) in places, which comes with
additional security, various kinds of "standalone" features, and
corresponding extra setup.
What avalon also adds everywhere is a strong emphasis on several
patterns, like Inversion of Control, and a very rigid lifecycle (rules
that boil down to "set up logging then dependencies then create worker
threads" that are encoded in interfaces and enforced by containers) on
every component. All this makes avalon rather heavy to apply a system.
That's a disadvantage (lot of work, very much nonoptional dependency,
some flexibility lost) and an advantage (rigid, clean, structured,
common setup).
----
HiveMind simply makes a few different choices, with its own set of
advantages and disadvantages. There's no IoC, and various bits are /way/
more dynamic than is desireable in an IoC environment. Looking past all
the "features" and "history" of both frameworks, this, IMO, is the
actual big difference.
Which answers the implicit question "So why not combine HiveMind and
Avalon into a single project?": there are a few core design choices that
are different between HiveMind and Avalon that make the two distinctly
incompatible.
----
I might summarize that as "Avalon is a very rigid kind of component
framework, HiveMind acts a lot more like component 'glue'".
= Concrete differences =
For component writers and application assemblers (people who take a set
of components and wire them together to make them actually "do"
something), the differences are actually rather small. To
show how small, I wrote
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonAndOtherShinyContainers
which shows you how your component can be portable across avalon, pico,
spring, webwork/xwork, and I've now added HiveMind as well. Probably not
too accurate, though.
= Other frameworks =
Howard M. Lewis Ship wrote:
> So there's definiately some overlap with Avalon. If I didn't have my day job, and the remaining
> work on "Tapestry in Action", I'd love to survey all the current microkernels, including Avalon,
> Spring, Pico and so forth.
I'm trying to maintain a wiki page to that effect:
http://lsd.student.utwente.nl/jicarilla/RelatedProjects
but its been difficult for me placing HiveMind in any kind of "box",
especially as its moving rather fast.
hope this helps,
cheers!
- Leo
Re: [HiveMind] hivemind and avalon, revisited
Posted by Leo Simons <le...@apache.org>.
Noel J. Bergman wrote:
>>http://nagoya.apache.org/wiki/apachewiki.cgi?HiveMind/HiveMindAndAvalon
>
> Overly simplistic question, perhaps, but based upon what you said, it would
> almost sound like Hivemind could live under an Avalon container. I don't
> know what, if any, benefits would acrue from such an approach.
Sure thing. In, above, under, next, around, through. You can probably
spend a week coding and be able to run spring in hivemind in jetty in
merlin in merlin in geronimo in eclipse.
Consider:
+--Geronimo-----------------------------------------------------------+
|+--Loom-------------------------------------------------------------+|
||+-----+ ||
|||James| ||
||+-----+ +-------------------------------------------------------+||
|| |Jetty +--Tapestry-+----------+ +--Tapestry----------+|||
|| | | | HiveMind | | | Spring ||||
|| | | | | | | ||||
|| | +-----------+----------+ +--------------------+|||
|| +-------------------------------------------------------+||
||-------------------------------------------------------------------||
|| PicoContainer | HiveMind ||
|+-------------------------------------------------------------------+|
| |
|+--Merlin-----------------------------------------------------------+|
||+--OpenORB-----------++--EOB-----------------++--Persistor--------+||
||| ||+--BusinessObj+ ||+-----------------+|||
|||+------------------+||| | ||| Hybernate ||||
|||| |||| | ||+-----------------+|||
|||| JNDI Registry ||||-------------| ||+-----------------+|||
|||| |||| HiveMind | ||| HypersonicSQL ||||
|||+------------------+||+-------------+ ||+-----------------+|||
||| || ||+-----------------+|||
||| ||----------------------||| Prevayler ||||
||| || PicoContainer ||+-----------------+|||
||+--------------------++----------------------++-------------------+||
|+-------------------------------------------------------------------+|
|---------------------------------------------------------------------|
| PicoContainer | HiveMind | JMX |
+---------------------------------------------------------------------+
its possible and probably feasible. Add some smart mixins using some AOP
framework that export all the contents of any particular framework over
JMX, add a asynchronous mapping from JMX into JNDI, use some smart
aggregrate containers to obtain subsets of some of all hosted components
to do dynamic relayering.
It is all possible. The problem is that with every layer or box,
conceptual, code- or projectwise, everything starts becoming less clear.
Until you end up with what feels like:
+---------------------------------------------------------------------+
| <<some container / framework / glue>> |
|---------------------------------------------------------------------|
| _.--------------. |
| ,---'' `----. |
| ,,-' `-.. |
| ,,-' `-.. |
| ,;' `:. |
| ,;' `:. |
| ,' `. |
| ,/ \. |
| ;; GIANT COMPONENT CLOUD GOES HERE :: |
| ;;,-------. :: |
| ;,'Imported `. :: |
| (| over SOAP ) || |
| ::. ,' FRAMEWORK THERE ;; |
| ::`-------' ;; |
| :: CONTAINER HERE,---------. ;; |
| `\ ,-' `-. /' |
| `. / \ ,' |
| `:. / BYTECODE- \ ,;' |
| `:. ( MODIFIED ) ,;' |
| ``-. \ / ,-'' |
| ``-. \ / ,-'' |
| `-`-.. ,-' _.---' |
| `---------'-----'' |
| |
| |
| |
+---------------------------------------------------------------------+
IMO It makes more sense to focus on component reuse and container
interoperability than on container reuse. The former is a common goal
while the latter brings us many barriers to conquer and battles to fight.
Lets focus on sharing ideas and specifications first. Any sharing of
code can come later.
cheers and goodnight!
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [HiveMind] hivemind and avalon, revisited
Posted by Vic Cekvenich <ce...@baseBeans.com>.
Re: IOC, it is worth looking for ideas at "picocontainer" from
http://codehaus.org.
If a standard and simple container "appeared", that would be awesome.
( I think even Hive is heavy). Something simple, that might
work/implement this:
http://cvs.apache.org/viewcvs/jakarta-struts/contrib/struts-chain/
.V
Howard M. Lewis Ship wrote:
> Thanks; that's a cool comparison.
>
> --
> 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: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>>Sent: Saturday, September 13, 2003 10:21 AM
>>To: commons-dev@jakarta.apache.org
>>Cc: dev@avalon.apache.org
>>Subject: [HiveMind] hivemind and avalon, revisited
>>
>>
>>Henri Yandell wrote:
>>
>>>>So how is Hivemind different to Avalon?
>>
>>Here we go again :D. I'll join in here to help get a sensible
>>answer. Lets see if we can document it somewhere this time....
>>
>>http://nagoya.apache.org/wiki/apachewiki.cgi?HiveMind/HiveMind
>>AndAvalon
>>(same content as this e-mail posted to the wiki)
>>
>>....it's a more involved question than it seems...
>>
>>The problem domain for HiveMind and "core" Avalon is nearly
>>the same; the general role of HiveMind in any application
>>will be fairly similar to that of something like
>>Avalon-Fortress or Avalon-Excalibur: providing configuration
>>management, dependency setup, component instantiation, etc etc.
>>
>>
>>= Design differences =
>>
>>Avalon takes that problem domain, then adds a strong
>>"containment" concept (Avalon-Phoenix / Avalon-Merlin) in
>>places, which comes with additional security, various kinds
>>of "standalone" features, and corresponding extra setup.
>>
>>What avalon also adds everywhere is a strong emphasis on
>>several patterns, like Inversion of Control, and a very rigid
>>lifecycle (rules that boil down to "set up logging then
>>dependencies then create worker threads" that are encoded in
>>interfaces and enforced by containers) on every component.
>>All this makes avalon rather heavy to apply a system. That's
>>a disadvantage (lot of work, very much nonoptional
>>dependency, some flexibility lost) and an advantage (rigid,
>>clean, structured, common setup).
>>
>>----
>>
>>HiveMind simply makes a few different choices, with its own
>>set of advantages and disadvantages. There's no IoC, and
>>various bits are /way/ more dynamic than is desireable in an
>>IoC environment. Looking past all the "features" and
>>"history" of both frameworks, this, IMO, is the actual big difference.
>
>
> We need an industry standard definition of IoC then. As I understand it, IoC
> means that a container is responsible for instantiating services, managing them,
> configuring them, connecting them together, and providing some amount of lifecycle support.
>
> Outside of lifecycle support, HiveMind has all of that, mostly via the BuilderFactory.
>
>
>
>>Which answers the implicit question "So why not combine
>>HiveMind and Avalon into a single project?": there are a few
>>core design choices that are different between HiveMind and
>>Avalon that make the two distinctly incompatible.
>>
>>----
>>
>>I might summarize that as "Avalon is a very rigid kind of
>>component framework, HiveMind acts a lot more like component 'glue'".
>
>
> I always like glue. Smells funny!
>
>
>>
>>= Concrete differences =
>>
>>For component writers and application assemblers (people who
>>take a set
>>of components and wire them together to make them actually "do"
>>something), the differences are actually rather small. To
>>show how small, I wrote
>>
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonAndOtherShinyContainers
>
> which shows you how your component can be portable across avalon, pico, spring, webwork/xwork, and
> I've now added HiveMind as well. Probably not
> too accurate, though.
>
> Close enough; added a few changes (large documenats are a pain in a Wiki, however, perhaps this
> should be split into multiple pages?)
>
> = Other frameworks =
>
> Howard M. Lewis Ship wrote:
>
>>So there's definiately some overlap with Avalon. If I didn't have my
>>day job, and the remaining work on "Tapestry in Action", I'd love to
>>survey all the current microkernels, including Avalon, Spring, Pico
>>and so forth.
>
>
>>I'm trying to maintain a wiki page to that effect:
>
>
>>http://lsd.student.utwente.nl/jicarilla/RelatedProjects
>
>
> SoC IoC SAI DecP and AOP-lite HiveMind's geek code!
>
>
>
>>but its been difficult for me placing HiveMind in any kind of "box",
>>especially as its moving rather fast.
>
>
> Think its slowing down now.
>
>
> --
> Howard M. Lewis Ship
> Creator, Tapestry: Java Web Components
> http://jakarta.apache.org/tapestry
Re: [HiveMind] hivemind and avalon, revisited
Posted by Leo Simons <le...@apache.org>.
Howard M. Lewis Ship wrote:
>> HiveMind simply makes a few different choices, with its own set of
>> advantages and disadvantages. There's no IoC, and various bits are
>> /way/ more dynamic than is desireable in an IoC environment.
>> Looking past all the "features" and "history" of both frameworks,
>> this, IMO, is the actual big difference.
>
> We need an industry standard definition of IoC then.
indeed! I'll babble a bit more, see if we can converge on some common
ground....
> As I understand it, IoC means that a container is responsible for
> instantiating services, managing them, configuring them, connecting
> them together, and providing some amount of lifecycle support.
Here's the terminology as avalon pioneered it (much narrower scope):
Inversion of Control -- means exactly what it says: that your components
are all set up completely from the top down (or from the outside in in
the container-component view).
This has farreaching consequences when universally applied. A component
is only allowed to do what it is told. It is not normally allowed to do
anything else, like look things up on its own (through JNDI for example,
or any other kind of registry).
That's it. IoC is not about lifecycle management, instantiation
management, configuration, or anything like that. It's a concept.
Okay, but what do you tell a component to do? That is where
instantiation, management, composition, configuration, logging and
similar aspects can come into play. All of those are concerns (among
others) that /can/ exist in the relationship between container and
component.
Avalon makes the choice to draw big black lines between each of those
concerns, and encode those choice rather bluntly and intrusively into
interfaces, and hence, into all "avalon components". This leads to a
distinct component lifecycle. Avalon also makes the choice to enforce
seperation of API and implementation (components can only access other
components through interfaces), and several others.
But all that doesn't /have/ to exist to call it IoC, nor is anything
said about the complexity of the container-component contract, nor is
anything said about which concerns that the container manages for a
component. For example, PicoContainer is definately all about IoC, but
it doesn't support any of the management, configuration, or logging
concerns that avalon and hivemind do try to address, therefore it
doesn't need any kind of lifecycle either.
The only two things pico supports is composition (providing a component
with its dependencies) and configuration (providing a component with
user-designated runtime state). To achieve that, it does have to handle
component instantiation as well, but tries to offload as much of that as
possible to adaptors. You might see Pico as "pure"/"minimal" IoC with
everything else stripped out.
----
Now, you can /use/ HiveMind for an IoC setup. The big difference with
avalon is that you can just as easily use HiveMind for a non-IoC setup.
HiveMind itself (disclaimer: gathered from just a few quick glances at
the sourcecode) also isn't totally saturated with IoC. Thus, HiveMind is
more like "component glue" (much like Spring framework, which is
remarkably similar on the surface).
To IoC or not to IoC is left up to the HiveMind user. Right?
OTOH, If you don't buy into IoC, you won't buy into Avalon.
----
> Outside of lifecycle support, HiveMind has all of that, mostly via
> the BuilderFactory.
And this is something where we perhaps should attempt to foster some
interoperability. Avalon-Fortress has a component factory concept; so
does Pico (though they call it adapter now), so does hivemind. Figure
out a way to share these factories cross-container and we might be
halfway there.
Of course, interoperability is not a sexy job; it is much more fun to
code from scratch. I have been known to start from scratch several times
a week.
----
>> I might summarize that as "Avalon is a very rigid kind of component
>> framework, HiveMind acts a lot more like component 'glue'".
>
> I always like glue. Smells funny!
<marketing-hat>s/HiveMind/DuckTape/</marketing-hat>
> Close enough; added a few changes (large documenats are a pain in a
> Wiki, however, perhaps this should be split into multiple pages?)
volunteering? ;)
>> http://lsd.student.utwente.nl/jicarilla/RelatedProjects
>
> SoC IoC SAI DecP and AOP-lite HiveMind's geek code!
hey, that's a wiki too! Meaning you're free (actually obliged according
to
http://lsd.student.utwente.nl/jicarilla/Welcome_20to_20the_20documentation_20team)
improve on its contents :D
cheers!
- Leo
RE: [HiveMind] hivemind and avalon, revisited
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Thanks; that's a cool comparison.
--
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: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
> Sent: Saturday, September 13, 2003 10:21 AM
> To: commons-dev@jakarta.apache.org
> Cc: dev@avalon.apache.org
> Subject: [HiveMind] hivemind and avalon, revisited
>
>
> Henri Yandell wrote:
> >>So how is Hivemind different to Avalon?
>
> Here we go again :D. I'll join in here to help get a sensible
> answer. Lets see if we can document it somewhere this time....
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?HiveMind/HiveMind
> AndAvalon
> (same content as this e-mail posted to the wiki)
>
> ....it's a more involved question than it seems...
>
> The problem domain for HiveMind and "core" Avalon is nearly
> the same; the general role of HiveMind in any application
> will be fairly similar to that of something like
> Avalon-Fortress or Avalon-Excalibur: providing configuration
> management, dependency setup, component instantiation, etc etc.
>
>
> = Design differences =
>
> Avalon takes that problem domain, then adds a strong
> "containment" concept (Avalon-Phoenix / Avalon-Merlin) in
> places, which comes with additional security, various kinds
> of "standalone" features, and corresponding extra setup.
>
> What avalon also adds everywhere is a strong emphasis on
> several patterns, like Inversion of Control, and a very rigid
> lifecycle (rules that boil down to "set up logging then
> dependencies then create worker threads" that are encoded in
> interfaces and enforced by containers) on every component.
> All this makes avalon rather heavy to apply a system. That's
> a disadvantage (lot of work, very much nonoptional
> dependency, some flexibility lost) and an advantage (rigid,
> clean, structured, common setup).
>
> ----
>
> HiveMind simply makes a few different choices, with its own
> set of advantages and disadvantages. There's no IoC, and
> various bits are /way/ more dynamic than is desireable in an
> IoC environment. Looking past all the "features" and
> "history" of both frameworks, this, IMO, is the actual big difference.
We need an industry standard definition of IoC then. As I understand it, IoC
means that a container is responsible for instantiating services, managing them,
configuring them, connecting them together, and providing some amount of lifecycle support.
Outside of lifecycle support, HiveMind has all of that, mostly via the BuilderFactory.
>
> Which answers the implicit question "So why not combine
> HiveMind and Avalon into a single project?": there are a few
> core design choices that are different between HiveMind and
> Avalon that make the two distinctly incompatible.
>
> ----
>
> I might summarize that as "Avalon is a very rigid kind of
> component framework, HiveMind acts a lot more like component 'glue'".
I always like glue. Smells funny!
>
>
> = Concrete differences =
>
> For component writers and application assemblers (people who
> take a set
> of components and wire them together to make them actually "do"
> something), the differences are actually rather small. To
> show how small, I wrote
>
http://nagoya.apache.org/wiki/apachewiki.cgi?AvalonAndOtherShinyContainers
which shows you how your component can be portable across avalon, pico, spring, webwork/xwork, and
I've now added HiveMind as well. Probably not
too accurate, though.
Close enough; added a few changes (large documenats are a pain in a Wiki, however, perhaps this
should be split into multiple pages?)
= Other frameworks =
Howard M. Lewis Ship wrote:
> So there's definiately some overlap with Avalon. If I didn't have my
> day job, and the remaining work on "Tapestry in Action", I'd love to
> survey all the current microkernels, including Avalon, Spring, Pico
> and so forth.
> I'm trying to maintain a wiki page to that effect:
> http://lsd.student.utwente.nl/jicarilla/RelatedProjects
SoC IoC SAI DecP and AOP-lite HiveMind's geek code!
> but its been difficult for me placing HiveMind in any kind of "box",
> especially as its moving rather fast.
Think its slowing down now.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
RE: [HiveMind] hivemind and avalon, revisited
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
> http://nagoya.apache.org/wiki/apachewiki.cgi?HiveMind/HiveMindAndAvalon
Overly simplistic question, perhaps, but based upon what you said, it would
almost sound like Hivemind could live under an Avalon container. I don't
know what, if any, benefits would acrue from such an approach.
--- Noel
RE: [HiveMind] hivemind and avalon, revisited
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
> http://nagoya.apache.org/wiki/apachewiki.cgi?HiveMind/HiveMindAndAvalon
Overly simplistic question, perhaps, but based upon what you said, it would
almost sound like Hivemind could live under an Avalon container. I don't
know what, if any, benefits would acrue from such an approach.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org