RE: HiveMind and Avalon

["Howard M. Lewis Ship" <hl...@comcast.net>]

I may be wrong but ...

in Avalon, it appeared that the ServiceManager would allow you to look up other services, but the
exact implementation of those services was specified in the assembly descriptor.  So, if service A
needed to send mail, the assembly descrptor would link service A to a particular Mail service (there
may be many different implementations of the Mail service).

Service A then can do a lookup, somewhat patterned after a JNDI lookup for an EJB, to get the Mail
service. Avalon structures things so that service A can only "see" the correct Mail service
implementation as described in the assembly descriptor.

HiveMind is more open (for better and for worse ... mostly better in my opinion); service A can be
configured to use service B; a property of service A is set to an instance of service B.  There's no
"negotiation", there's one less layer of abstraction; service A is connected to exactly service B.
Service B (or, likely, a proxy for service B) is assigned to a property of service A ... there's no
code wasted in service A to lookup service B.

I think the IoC in HiveMind is more flexible and more transparent that then IoC in Avalon.
ms.
The other part of HiveMind, the part I'm still working on "the message" for is data-driven
development.

However, the comparison to Avalon is largely moot because the service aspect of HiveMind is just
part of the picture.

HiveMind gives you the tools, configuration-points and contributions, to easily create complex data
to drive your services.

Take the case study on the web site; the actual implementation of the Startup task was really slim,
little more than a loop and some exception catching.  Very easy to test this, just one or two test
cases!

The original solution, a central EJB, was code heavy; it had to perform 40 operations as 40 chunks
of code, and was a choke point for development.

The data-driven HiveMind solution is fully distributed; each module that has a startup task simply
contributes it into the configuration-point. Startup tasks can come, go or change and the service
implementation can stay the same.

Perhaps the "information bus" metaphor is useful here as well; different modules plug into a
configuration-point "bus" to 

To me, HiveMind is really fulfilling the promise of OO that I remember when first learning it ... a
swarm of small objects, each well defined, that work together to solve problems / implement the
application. That promise hasn't worked in real life because of a lack of structure ... the plumbing
details of creating, initializing and connecting those objects causes too many problems, too many
code paths, too hard to test.

HiveMind subsumes all of that plumbing; it creates a new platform for describing and implementing
your application and takes care of the initialization and configuration details for you. For my
needs, it leapfrogs Avalon because of the power of <schema> and <rules>; the ability to put complex
data into the module deployment descriptors and see it as Java objects within your service
implementations.

I always believe a proper framework should help you when dealing with difficult choices; the correct
choice should be the easiest choice. Tapestry goes along way towards this, HiveMind is even better.
For example, the correct choice when using services is to deferr creation of a service until just as
it is needed.  In normal coding, including Avalon, this looks like:

public void myMethod()
{ 
  if (_serviceB == null)
    _serviceB = . . .;

  _serviceB.helpMe();
}

And that code can be replicated in each place, within service A's impl, that service B is needed.
Oh, and that code is broken, its not synchronized properly.  So, maybe:

public void myMethod()
{
  getServiceB().helpMe();
}

private synchronized ServiceB getServiceB()
{
  if (_serviceB == null)
    _serviceB = . . .;

  return _serviceB;
}

In HiveMind, that plumbing is the responsiblity of the framework, so your code is simple:

public void myMethod()
{
  _serviceB.helpMe();
}

No code branches; the dynamic lookup / construction of service B is moved inside the proxy created
by HiveMind for service B, and it's properly synchronized.




--
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: Petri Wessman [mailto:orava@iki.fi] 
> Sent: Friday, September 19, 2003 9:24 AM
> To: hlship@apache.org
> Subject: HiveMind and Avalon
> 
> 
> Hi, I've played around a bit with Avalon previously (wrote a 
> simple container 
> for it because I didn't like the stock ones, and used it in a 
> small project). 
> It's very nice, but since I've come to the point where I want 
> to refactor my 
> code a bit I started looking around at what else is out 
> there, and ran into 
> mention of HiveMind. Looks very interesting, but I'm still 
> browsing through 
> the website docs and trying to figure out how it works and 
> how it relates to 
> Avalon - which I understand at least up to a point :).
> 
> Anyway, a comment on the website caught my eye, 
http://jakarta.apache.org/ commons/sandbox/hivemind/ioc.html says "Avalon uses detailed assembly 
descriptions to tie services together ... there's no way an Avalon component 
can "look up" another component; in Avalon you explicitly connect services 
together."

Maybe I've misunderstood everything and subverted Avalon in my own project :), 
but in my understanding the above claim is not true. Avalon has the interface 
org.apache.avalon.framework.service.Serviceable, and a component which needs 
to look up another component - a common need - just implements that and gets 
automatically passed a ServiceManager by the container (which is then used to 
do the lookup)... so you do have a lot of flexibility there, it's just a 
different way of doing it than in HiveMind - still working out what the 
HiveMind way actually is, but that's a matter of reading some more docs :).

It's nice to see microkernels/microframeworks start to get attention nowadays, 
I've found the whole area pretty interesting ever since I figured out what 
Avalon actually was and how it worked - which took a fair bit of time.

//Petri Wessman