HiveMind

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

I'll be adding some concrete examples from Vista shortly.

It's a lot like Tapestry; it makes doing things the right way also the easy way. It allows you to
break up your application into many small, individually testable components. It writes the boring
code for you:
- Logging method invocations
- Looking up EJBs in JNDI and invoking methods on them
- Parsing XML configuration data into Java objects
- Instantiating services only as needed

Here's one use of it, from Vista.  Vista is a huge application and we had many little services going
on that had special application-startup issues.  For example, the Help tool, at startup, would read
and cache the index of help data.  The Mail tool (my responsibility) would schedule a periodic
garbage-collection task, to delete unreachable data. In all, there were about 40 startup tasks
within you giant (6000+ source files) code base.

Before HiveMind, we had a single startup class invoke a method on a startup EJB.  Each startup task
was (generally) a static method on a public class.  The EJB would methodically invoke the static
method (with a try ... catch for any exceptions).

This was not very pretty ... we had this EJB that imported stuff from the whole world, which not
only got in the way of our refactoring, but made it very difficult to modularize our build process,
since this EJB had dependencies that branched out in every direction.

With HiveMind, we instead have a number of HiveMind deployment descriptors, and a single
extension-point, "Startup".

Each module can contribute any number of tasks to the Startup extension-point.  For example:

<extension point-id="vista.coreservice.initshut.Startup">
  <task order="4000" title="Mail" class="com.webct.vista.coreservice.mail.startup.MailStartup"/>
</extension>

or

<extension point-id="vista.coreservice.initshut.Startup">
  <task order="5000" title="Help">
    <invoke-static class="com.webct.vista.coreservice.help.HelpStartup"/>
  </task>
</extension>

At runtime, a service, also called Startup, reads the extension-point.  It doesn't get XML, because
the extension-point includes rules to convert the contributions (the <task> elements) into Java
objects: instances of com.webct.platform.coreservice.initshut.Task, which implement the Runnable
interface.  It just runs through the list, invoke run() on each instance.

Example #2

We're belated modularizing our code base, breaking it apart into individual modules that compile
seperately (don't ask ... I wasn't around when the current system was put in place). Currently, we
have an ugly mess of dependencies to unravel.  In theory, all the frameworks build first, then all
the coreservices, then all the tools ... but we keep finding backwards dependencies. There's been an
awful amount of code shuffling, to move code from tools to coreservice, or even to framework, to
satisfy the dependencies.

My tools, Mail, was a coreservice, but had a dependency on some utility classes that were only
available in tools (and couldn't be moved because the classes had dependencies on other tools ... it
would have escalated into a massive reorg). With HiveMind I don't care so much about where
implementations come from ... that's figured out at runtime.

I created a service interface that would satisify my needs and placed in in coreservice, where it
was legal for the Mail tool codebase to access it.  I defined the service in a coreservice HiveMind
deployment descriptor, but did not specify an implementation for the service, just the service id
and interface name.

I then created an implementation inside tools; the service implementation just turns around an
invokes the right methods on the utility class. I created a HiveMind dd there to supply the
implementation of the service.

Lastly, I changed a tiny amount of code to not invoke the methods of the utility class but instead
lookup the service in HiveMind and invoke methods there.

Voila! No more dependency problem.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry



> -----Original Message-----
> From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] 
> Sent: Wednesday, August 13, 2003 11:05 PM
> To: Tapestry development
> Subject: Re: Blog RSS feed
> 
> 
> I am curious about Hivemind. I read the docs, downloaded the 
> source, got 
> it compiled, now what...? I kinda understand it from the conceptual 
> standpoint, but have no idea where to start. Any suggestions/pointers?
> 
> Thanks
> Harish
> 
> Howard M. Lewis Ship wrote:
> 
> >Thanks to the great folks at blogger.com, my 
> Tapestry/HiveMind blog is 
> >back up and running and now has an RSS feed.
> >
> >http://javatapestry.blogspot.com/rss/javatapestry.xml
> >
> >--
> >Howard M. Lewis Ship
> >Creator, Tapestry: Java Web Components 
> >http://jakarta.apache.org/tapestry
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
> >  
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 

Re: HiveMind

[Harish Krishnaswamy <hk...@comcast.net>]

Thanks for sharing, this adds a little more context to my understanding. 
Looking forward to the examples.

Thanks
Harish

Howard M. Lewis Ship wrote:

>I'll be adding some concrete examples from Vista shortly.
>
>It's a lot like Tapestry; it makes doing things the right way also the easy way. It allows you to
>break up your application into many small, individually testable components. It writes the boring
>code for you:
>- Logging method invocations
>- Looking up EJBs in JNDI and invoking methods on them
>- Parsing XML configuration data into Java objects
>- Instantiating services only as needed
>
>Here's one use of it, from Vista.  Vista is a huge application and we had many little services going
>on that had special application-startup issues.  For example, the Help tool, at startup, would read
>and cache the index of help data.  The Mail tool (my responsibility) would schedule a periodic
>garbage-collection task, to delete unreachable data. In all, there were about 40 startup tasks
>within you giant (6000+ source files) code base.
>
>Before HiveMind, we had a single startup class invoke a method on a startup EJB.  Each startup task
>was (generally) a static method on a public class.  The EJB would methodically invoke the static
>method (with a try ... catch for any exceptions).
>
>This was not very pretty ... we had this EJB that imported stuff from the whole world, which not
>only got in the way of our refactoring, but made it very difficult to modularize our build process,
>since this EJB had dependencies that branched out in every direction.
>
>With HiveMind, we instead have a number of HiveMind deployment descriptors, and a single
>extension-point, "Startup".
>
>Each module can contribute any number of tasks to the Startup extension-point.  For example:
>
><extension point-id="vista.coreservice.initshut.Startup">
>  <task order="4000" title="Mail" class="com.webct.vista.coreservice.mail.startup.MailStartup"/>
></extension>
>
>or
>
><extension point-id="vista.coreservice.initshut.Startup">
>  <task order="5000" title="Help">
>    <invoke-static class="com.webct.vista.coreservice.help.HelpStartup"/>
>  </task>
></extension>
>
>At runtime, a service, also called Startup, reads the extension-point.  It doesn't get XML, because
>the extension-point includes rules to convert the contributions (the <task> elements) into Java
>objects: instances of com.webct.platform.coreservice.initshut.Task, which implement the Runnable
>interface.  It just runs through the list, invoke run() on each instance.
>
>Example #2
>
>We're belated modularizing our code base, breaking it apart into individual modules that compile
>seperately (don't ask ... I wasn't around when the current system was put in place). Currently, we
>have an ugly mess of dependencies to unravel.  In theory, all the frameworks build first, then all
>the coreservices, then all the tools ... but we keep finding backwards dependencies. There's been an
>awful amount of code shuffling, to move code from tools to coreservice, or even to framework, to
>satisfy the dependencies.
>
>My tools, Mail, was a coreservice, but had a dependency on some utility classes that were only
>available in tools (and couldn't be moved because the classes had dependencies on other tools ... it
>would have escalated into a massive reorg). With HiveMind I don't care so much about where
>implementations come from ... that's figured out at runtime.
>
>I created a service interface that would satisify my needs and placed in in coreservice, where it
>was legal for the Mail tool codebase to access it.  I defined the service in a coreservice HiveMind
>deployment descriptor, but did not specify an implementation for the service, just the service id
>and interface name.
>
>I then created an implementation inside tools; the service implementation just turns around an
>invokes the right methods on the utility class. I created a HiveMind dd there to supply the
>implementation of the service.
>
>Lastly, I changed a tiny amount of code to not invoke the methods of the utility class but instead
>lookup the service in HiveMind and invoke methods there.
>
>Voila! No more dependency problem.
>
>--
>Howard M. Lewis Ship
>Creator, Tapestry: Java Web Components
>http://jakarta.apache.org/tapestry
>
>
>
>  
>
>>-----Original Message-----
>>From: Harish Krishnaswamy [mailto:hkrishnaswamy@comcast.net] 
>>Sent: Wednesday, August 13, 2003 11:05 PM
>>To: Tapestry development
>>Subject: Re: Blog RSS feed
>>
>>
>>I am curious about Hivemind. I read the docs, downloaded the 
>>source, got 
>>it compiled, now what...? I kinda understand it from the conceptual 
>>standpoint, but have no idea where to start. Any suggestions/pointers?
>>
>>Thanks
>>Harish
>>
>>Howard M. Lewis Ship wrote:
>>
>>    
>>
>>>Thanks to the great folks at blogger.com, my 
>>>      
>>>
>>Tapestry/HiveMind blog is 
>>    
>>
>>>back up and running and now has an RSS feed.
>>>
>>>http://javatapestry.blogspot.com/rss/javatapestry.xml
>>>
>>>--
>>>Howard M. Lewis Ship
>>>Creator, Tapestry: Java Web Components 
>>>http://jakarta.apache.org/tapestry
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>>
>>>
>>> 
>>>
>>>      
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>  
>