HiveMind Proposal to Join Apache Jakarta Project


News: HiveMind Proposal to Join Apache Jakarta Project

  1. HiveMind Proposal to Join Apache Jakarta Project (27 messages)

    Howard Lewis Ship (of Tapestry fame) has sent in a proposal to Apache for the HiveMind project, a simple framework for creating pluggable, configurable, reusable services. HiveMind has grown out of a donation to Apache from WebCT. It is a framework in a similar vein to the other lightweight containers out there, such as PicoContainer, Spring, and Avalon.

    HiveMind does overlap with the other Apache project, Avalon, but it does differ too. HiveMind's concept of a distributed configuration is unique among the available service microkernels (Avalon, Keel, Spring, Picocontainer, etc.). Avalon is firmly rooted in a type-1 inversion of control pattern (whereby services must explicitly, in code, resolve dependencies between each other using a lookup pattern similar to JNDI). HiveMind uses a mix of type-2 and type-3 IoC, whereby the framework (acting as container) creates connections between services by setting properties of the services (type-2) or making use of particular constructors for the services (type-3).

    What is HiveMind

    Simple: HiveMind is a way to create a network of services in terms of Java interfaces and classes; it cherry picks the most useful ideas from Service Oriented Architectures such as J2EE, JMX and SOAP, but removes the aspects that are typically overkill for most applications, such as service remoteability and language neutrality. HiveMind creates a natural network of related services and configuration data, all operating within a single JVM.

    Pluggable: HiveMind enforces a complete separation of service definition and implementation. This is manifested by a division of services into an interface definition and a service implementation as well as a split between defining a service (as part of a HiveMind module) and providing the implementation of that service (potentially, in a different module).

    Configurable: HiveMind integrates a service oriented architecture to a sophisticated configuration architecture; the configuration architecture is adapted from the Eclipse plug-in model, wherein modules may define configuration extension points and multiple modules may provide contributions to those extension points.

    Reusable: HiveMind is a framework and container, but not an application. The HiveMind framework and the services it provides may be easily combined with application-specific services and configurations for use in disparate applications.

    This shows the trend towards lightweight containers. I hope we hear from Apache soon.

    Read Howard's Proposal for the HiveMind Project

    TheServerSide will be publishing an article on HiveMind soon. If there are any topics which you would like to see article coverage, please let us know at editor at theserverside dot com.

    Threaded Messages (27)

  2. I was quite shocked to see this article posted here; the proposal has just started circulating around the Jakarta General mailing list and I would expect that it will be a least a couple of weeks before any consensus about HiveMind will form.

    It is important to note that HiveMind contains code that is (for the moment at least), proprietary to WebCT (my former employer). This proposal originated out of WebCT and a software grant, to properly assign the rights for HiveMind to the ASF, will be forthcoming soon. The fact that HiveMind was publically available in the past reflects my personal naivette concerning intellectual property rights --- I have been lucky that both WebCT and the ASF have very positive and cooperative about recovering from my personal errors.

    In the meantime, you'll be dissapointed if you visit the HiveMind home page ( ... the content has been temporarily taken offline until the ASF recieves the software grant from WebCT.

    What's gratifying the amount of attention HiveMind has received, including the spontaneous formation of a development community on the Jakarta Commons developer mailing list. The attention is surprising; outside of my blog, I really haven't courted much HiveMind attention. In any case, I'm anxious to have the unfortunate IP issue resolved so that a wider community can look at what we've put together so far.
  3. Howard,

    I think Tapestry is a great framework. It is quite innovative and has no serious competitors in terms of scope or features, IMHO.

    However, how do you see HiveMind in comparison to several of the recent "light" containers such as Spring, PicoContainer, etc.? What is different about HiveMind verses the others that warrants a new project?

    Don’t get me wrong. This is not some Spring zealot attack (although I do think Spring is quite cool), and I believe that someone's personal desire is reason enough for a new framework (verity is the spice of life).

    Personal interest's aside, I’m assuming you have technical reasons for introducing a new player in the IoC container landscape. I'd love to hear what they are.

  4. What makes HiveMind special?[ Go to top ]

    HiveMind exists to fit some specific needs I had and have, that I could not find solutions for elsewhere.

    My starting point was not J2EE or JMX or Avalon: it was Eclipse plugins. I've been very impressed with the concept and execution of Eclipse plugins; the concept of having a homogeneous repository of all configuration information, and the fact that all plugins could "contribute" to each other, passing configuration data as XML. It allows for a wonderful, data-driven solution, as evidenced by Eclipse itself.

    HiveMind mates that general model to a services model. You define configuration points and service points.

    One thing that Eclipse doesn't do so well is the XML parsing side of things. Eclipse converts the raw plugin XML into a DOM-like intermediate format and the rest is up to your code.

    HiveMind uses a stack based set of directives, derived in spirit from Digester, to convert XML contributions to a configuration-point into Java objects. XML in, Java objects out. That's a pretty huge swath of your code that never gets written and benefits from my personal neurotic error-catching-and-reporting zeal.

    As a side note, HiveMind uses the same "line precise error reporting" adapted from Tapestry. When a runtime error occurs, HiveMind will almost always be able to relate the error to a specific file (module deployment descriptor) and line. The productivity advantages of this are overwhelming!

    An issue in Vista (the WebCT product) was problems related to uwanted dependencies between seperate layers of the product. HiveMind seperates the definition of a service (its <service-point>) from its implementation. Typically, they are combined together, but they don't have to be.

    This allows the service-point and the interface for the service to be defined in one module, and the implementation provided by another module(thus overcoming the dependency issue). You can even have two different modules provide the implementation but only deploy one of them at runtime (i.e., your Oracle DAOs in one module JAR, your DB2 DAOs in another).

    HiveMind writes a lot of boring code for you, on the fly, using Javassist. So you get the advantages of thread-safe singletons, late binding, just-in-time configuration and so forth, without writing any of the code to actually do it.

    HiveMind services are easy to test because, at the root, they are just POJOs. In your unit test environment you can connect one POJO to another (using type-2 style properties, or type-3 style constructors). In this way, you can accurately mimic what the HiveMind framework (acting as service container) will do at runtime.

    HiveMind interceptors are a simple, "poor-man's" Aspects. Because services are defined in terms of interfaces, its very easy to create new implementations of those interfaces and thread them into the execution. HiveMind includes an interceptor for logging method entry and exit, but others will be added (all the classics: transaction demarcation, security checks, and so forth).

    HiveMind accepts the fact that not all configuration details can be known at build time. It allows for symbols, using the Ant ${} syntax, to be used in the HiveMind module deployment descriptor. These symbols are expanded at runtime, and can be used for things that aren't known until after an app is installed, such as e-mail addresses, host names, and database URLs.

    Much of HiveMind is defined in terms of HiveMind itself. For example, there's a HiveMind configuration-point that defines where to look up symbols. You can contribute to that configuration-point to define a new symbol source.

    Another example: In HiveMind, there are "service factories" which are used to create implementations of services. The main service factory is BuilderFactory, which instantiates a POJO and configures its properties. However, an alternate factory, EJBProxyFactory, actually constructs the implementation at runtime, creating a service that encapsulates a stateless session bean (that is, it performs the JNDI lookup and invokes create() on the home interface). I expect to build something similar to "encapsulate" JMX MBeans.

    Over lunch, I was discussing HiveMind with a co-worker. His common complaint is that frameworks take away as much as they give because they limit the expressiveness of your code. I think HiveMind does just the opposite; it makes you code both simple and more expressive, by moving so much of the "plumbing" into high-level descriptors (in the XML deployment files).

    Hopefully the HiveMind home page will be up again soon. In the meantime, a lot of detail about HiveMind is on my blog:
  5. <quote>
    I think Tapestry is a great framework. It is quite innovative and has no serious competitors in terms of scope or features, IMHO.

    Don't be happy too fast ;-) Check out BarracudaMVC ( Barracuda has a very mature component and event-based MVC framework. Thanks to XMLC it supports not only HTML and WML but also VoiceXML, cHTML and many others. The concept of Barracuda is very nice. Check out this doc about a comparison of Barracuda and Struts:

  6. Spring is cool, HiveMind is cooler![ Go to top ]

    I feel lucky to had downloaded HiveMind's code recently, I think it has more features than SpringFramework as an infrastructure. But SpringFramework has more on db and web, so I am planing to use both of them together. HiveMind is better to support "drop a jar in the directory and then restart and see the service is available", and is better to support service-origiented architecture while SpringFramework can only give you "Bean"s. I think SpringFramework is just like a good supporting utility while HiveMind could be an infrastructure of whole software architecture.
  7. Spring is cool, HiveMind is cooler![ Go to top ]

    As I see it, Spring can serve as application infrastructure very well. It's different to HiveMind (and Phoenix) in that it does not define deployment units beyond standard J2EE. Spring assumes that you decide on the actual wiring of your application at WAR/EAR deployment time, bundling your classes into appropriate application deployment jars. There are of course numerous ways to customize property values or whole bean definitions in an installation of an app, e.g. for settings to be touched by administrators.

    HiveMind on the other hand seems to implement a lookup for individual service jars, as opposed to application jars that contain pre-bundled services that form an applications. That's of course a viable goal: If an application is so modular that it can support drop-in replacement of individual service jars in an installation, HiveMind will be a good fit. Most applications are bundled at deployment time, though: Standard J2EE deployment with application-level wiring up of lightweight beans via Spring is a nice fit here.

    I'll definitely check out HiveMind's jar lookup as soon as the legal issues are settled. It should be particularly interesting for implementing lightweight servers; it reminds me a bit of the "sar" model in JBoss and Phoenix. Howard, could you outline what the main distinct features of HiveMind are in your point of view? Are you focussing on deployment of individual services, or is that just "yet another" feature of HiveMind?

    (Spring Framework developer)
  8. Slight mis-information there: HiveMind seems to take a virtually identical path towards J2EE compliance. Ease of use in a J2EE EAR was a critical constraint on the design.

    HiveMind searches for the HiveMind module deployment descriptors on the classpath, as /META-INF/hivemodule.xml. In a J2EE app, you should use the servlet's classloader, since it will have the broadest view (i.e., including EJB jars).

    At startup, HiveMind finds and parses all such descriptors, but doesn't actually instantiate classes until just-in-time.

    HiveMind doesn't have a "hot deployment" model such as you suggest. The concept of HiveMind is to allow you to construct an intricate web of related services, each very small, focused and testable. Hot deployment of just some modules within a repository of modules causes a lot of problems, since the objects defined in any one module are going to be distributed about. Instead, HiveMind relies on hot deployment of the containing EAR, and the repository will be re-built using the available descriptors in the new version of the EAR.

    (I haven't rules out some approach to hot-deployment in the future ... the use of service proxies means it is reasonably possible to change the implementation of a service dynamically. The real problem lies in the distribution of configuration data, which can easily migrate beyond areas that the HiveMind framework can track ... such as when service A reads configuration B and passes data from it to service C, which retains it for later. If module B is redeployed, HiveMind has not idea that service C is "tainted" with data from module B.)

    I think a lot of your comments about HiveMind actually apply to Apache's Avalon, which to me still looks like an "application server construction kit" rather than a "services microkernel".

    HiveMind distinguishing characteristics:
    - Distributed configuration (ala Eclipse plugins)
    - Flexible XML "schema" for configuration contributions
    - XML in/Java out for configuration data
    - Line precise error reporting
    - HiveDoc (JavaDoc like report from HiveMind descriptors)
    - Multiple service models (singleton, deferred, threaded, pooled)
    - Ioc-2 and/or Ioc-3
  9. Howard,

    Thanks for the clarification. I didn't mean to imply that HiveMind supports actual hot deployment; rather I've assumed something pretty close to what you outline: You drop in jar files with individual descriptors in their META-INF and then restart the application. Of course, I've been misled a bit by Avalon's "sar" concept which is really an application server construction kit rather than an application framework, as you say. Unfortunately, I haven't been able to verify HiveMind's actual mechanism as the website is currently not available ;-) Sorry for the confusion, anyway.

    So the central difference between Spring's approach and HiveMind's seems to be Spring's "application context" concept (potentially multiple bean definition XML files, but coarse-grained at the application/layer/module level) vs HiveMind's "service deployment descriptor" concept (one service-level descriptor in the jar file of a service). I believe both are valid approaches: wiring of named components in an application jar (Spring) vs type-based lookup of individual component units in their own jars (HiveMind).

    For further clarification: I guess HiveMind bases its wiring decisions on the component type specified in hivemodule.xml? Is there support for multiple components of the same type, possibly identified by a logical name? Does a HiveMind module just contain one single or multiple components? What's the typical granularity?

    BTW, a Spring bean factory also supports multiple lifecycle models (singleton, lazy-init singleton, prototype; pooled via an AOP pooling interceptor). As of the upcoming release 1.0 M3, it supports both Type 2 IoC (bean properties) and Type 3 IoC (constructor arguments) too.

  10. Spring / HiveMind Comparison[ Go to top ]

    I've put up a temporary copy of the HiveMind documentation on my personal home page: This is a limited version of the real docs, with JavaDoc, clover reports (> 90%, btw) and source xref removed.

    Please check out the "use case #1" which really shows how powerful the distributed configuration are, and the synnergy you get from linking flexible, distributed configuration to a data-driven solution built around the service model.

    Just to be clear (about granularity): A single HiveMind module (deployed as a JAR file) may define any number of service-points and configuration-points and may make any number of contributions to service-points and configuration-points (in the same module, or in different modules).

    I believe Avalon has an individual XML descriptor file for each service.

    Wiring: wiring of services is by service id (not by interface), so many different services may use the same interface but be completely distinct from each other.
  11. Spring / HiveMind Comparison[ Go to top ]


    So it seems that HiveMind is closer to Spring than to Avalon or PicoContainer. I've now clearly learned that, I guess :-) Your introduction with the examples for setting collaborating services and configuration data seems *very* similar to what Spring offers. Of course, you've got some interesting and unique ideas in there, just like Spring on its side - I'm delighted to discuss them with you!

    The remaining main difference seems to be the service descriptor packaging: HiveMind keeps descriptors in a jar's META-INF and auto-discovers them, while Spring usually keeps them in the WEB-INF directory (in the web app case) and loads them by explicit path specification. HiveMind's "Registry" seems to be analogous to the Spring "ApplicationContext".

    Note that you can keep Spring bean definitions anywhere: In a non-web environment like unit tests or standalone applications, ClassPathXmlApplicationContext and FileSystemXmlApplicationContext can load them from any class path or file system location, respectively. You can also do programmatic registration of beans on a Spring bean factory.

    An interesting thought is whether we should support auto-discovering of bean definition files in application jars for Spring. It's easy to merge multiple bean definition files, as already used for splitting a Spring application context into multiple definition files for different layers or modules. Auto-discovery should be straightforward to add if there's demand for it.

  12. no love for Bebop...[ Go to top ]

    I hate to further hijack this thread, but since we're on the subject of alternative component containers... allow me to put a plug in for my own project, Bebop.

    Bebop is a lightweight IoC component container and factory. It supports JavaBean style configuration as well as constructor-based configuration.

    So what makes Bebop different from other offerings:

    * Bebop takes a very pragmatic view of components. You can use JavaBeans, object w/constructors, EJBs, JNDI objects... you name it. Bebop lets you write components without having to worry about the container.

    * Bebop takes a holistic view of components. Components reside in various scopes... so you can easily combine singletons and services with more transient components. And more importantly, you can easily define the relationships between those components.

    Bebop 3.0 is in beta now. Check it out.


    And again, I apologize for the blatant plug... but I gotta get the word out somehow.
  13. no love for Bebop...[ Go to top ]

    ...and I don't want to distract from HiveMind either: It's an interesting project, no debate about that - kudos to Howard for managing it virtually on his own! Generally, it's good to see a strong trend towards lightweight containers, and competition between various projects definitely helps to advance the field.

  14. Competition[ Go to top ]

    Yes, it's not like I'm expecting HiveMind to debut and all competitors to die on the vine. HiveMind will pop up on Jakarta, or as part of Tapestry or Avalon or who knows where ... it will get some mindshare and its best ideas and features will be copied into other frameworks.

    Anyone currently using Spring (or Avalon or Bebop or Pico or ...) shouldn't jump on HiveMind as the New Shiny Thing. If they see features in HiveMind that they can't live without, they can either switch, or work with their framework's team to get equivalent features.

    What I'd like to see in the future is the idea that existing packages (such as, perhaps, commons-pool or Hibernate or XMLBeans) will simply include interfaces and HiveMind module deployment descriptors so that the services provided by these frameworks can be naturally incorporated into a HiveMind-based application. If Spring starts to use a similar "scarf up what's on the classpath" configuration scheme, then package the Spring descriptors as well.

    See where this is headed? Entire frameworks componentized as HiveMind services.

    I often find the hardest part of using a framework to be configuring and initializing it ... the idea that this configuration and initialization could be done for me, by the frameworks developers, and have it Just Simply Work is enticing.
  15. Competition[ Go to top ]

    What I'd like to see in the future is the idea that existing packages (such as, perhaps, commons-pool or Hibernate or XMLBeans) will simply include interfaces and HiveMind module deployment descriptors so that the services provided by these frameworks can be naturally incorporated into a HiveMind-based application. If Spring starts to use a similar "scarf up what's on the classpath" configuration scheme, then package the Spring descriptors as well.

    > See where this is headed? Entire frameworks componentized as HiveMind services.

    I guess what you intend to achieve is to define the services in the provided modules and feed them with application-level configuration via their configuration points. But those configuration points need to be defined separately: So you need service definitions, configuration definitions, and configuration contributions (i.e. values), if I understand correctly.

    The Spring equivalent is plugging in an existing JavaBean that the tool provides (like BasicDataSource), or provide a factory bean for the tool (like LocalSessionFactoryBean). In both cases, you have one central definition for the bean name, bean class, and bean property values. There is no notion of a service or configuration definition: A bean class or factory bean class plus created object is self-describing in terms of service and config options.

    Take for example a JDBC DataSource. In a Spring application context, you define a bean of type DataSource like a Commons DBCP BasicDataSource and parametrize with your connection properties, via the DataSource's existing bean properties. This is then available for bean references to application beans that have a dependency on a DataSource. What should the Commons DBCP team do in terms of a service descriptor to make the task easier for an application developer?

    For another example, take Hibernate. In Spring, you define a LocalSessionFactoryBean and parameterize it with whatever Hibernate mappings and settings you have. This bean will then behave like a singleton Hibernate SessionFactory, available for references to DAOs and the like. Again, what descriptor should be included to make that easier? The LocalSessionFactoryBean class is already self-describing and easy to set up.

    I don't see how that stuff can get any simpler. The Spring bean factory and also PicoContainer offer quite a lot of power with a minimal amount of metadata. Sorry if I might sound ignorant; I just want to understand why you see the need for HiveMind's separate service definition/configuration definition/configuration contribution kinds of metadata. Judging from this, HiveMind sounds closer to Avalon's Phoenix again than to Spring/PicoContainer.

    Finally, Spring beans and PicoContainer components are typically pretty fine-grained, as they represent web controllers, business objects, DAOs, resource factories, etc. I expect HiveMind services to be more coarse-grained, rather at the facade level of typical Avalon services or EJB Session Beans. In the end, both approaches have their merits, but it doesn't really look like they address the exact same needs.

  16. Competition[ Go to top ]

    Soon the code will be available again, and you can see where I'm coming from.

    I feel that the service network for a HiveMind application will be extremely find grained.

    Spring lets you instantiate and configure JavaBeans and I can see that sometime properties of JavaBean A is JavaBean B ... type-2 IoC.

    What if you need to provide a list of objects as a property of the bean? What if, at the location where you define the bean, you don't know all the values in the list.

    The example of startup tasks comes to mind: there are dozens of modules each contributing some number (typically, 0, 1 or 2) tasks to one or the other of the startup and shutdown configuration points.

    All of that Task data is packaged up, regardless of which module contributed it, into a single list, which is provided to the Startup service.

    The startup configuration defines a succinct, readable XML schema for contributions: <task title="..." ...> The Startup service doesn't see the XML, it sees Java objects; the contributions are converted into Task instances.

    The same kind of thing is rampant in Eclipse: there's a configuration point for, say, what goes on a toolbar. There's lots of XML to define the label, the icon, when it is enabled or disabled, and what to do when it is clicked. As you add new plugins, they all get their chance to contribute to the configuration.

    What I've seen in my own coding involving HiveMind is that I'm using more data-centric approaches to solving problems. Rather than hard-code a case statement, I'm defining an object to encapsulate tests and using a collection of them to make decisions. Leads to greater testability and higher code coverage.

    HiveMind provides the expressive power to connect the services and the configurations nice and neat.
  17. Competition[ Go to top ]

    Spring lets you instantiate and configure JavaBeans and I can see that sometime properties of JavaBean A is JavaBean B ... type-2 IoC.

    > What if you need to provide a list of objects as a property of the bean? What if, at the location where you define the bean, you don't know all the values in the list.

    Spring can not just set a simple bean reference to a bean property. It also provides support for bean properties of type array/List/Map, being able to fill them with values, bean references, or even a mixture of both. As of 1.0 M3, it can populate constructor arguments with the same type options. And any property value can contain placeholders to be resolved at runtime. So Spring's bean factory offers a lot of expressive power beyond simple 1-to-1 wiring.

    But I see where the root of your idea is: the plugin model of Eclipse. Configuration points where any plugin can contribute etc. Haven't thought about that yet, so I'll definitely check this out in more detail once the code is available again. It's already pretty obvious that HiveMind's general metaphor and configuration model is significantly different to Spring's and PicoContainer's. As I said, not really targeting the exact same needs.

    After all, there will never be a one-size-fits-all container, so it's good to see different focuses that might be suitable for different needs (of course with some more or less extensive overlaps). And it's always interesting to get insight into other approaches :-)

  18. Why not combine them together?[ Go to top ]

    It is useful to combine them together, though not every people will like this approach because they will say "you are putting two framework mixed together", but I think it should be able to work, and will bring developers more useful features.

    Here's how:

    Write my own ApplicationContext class that can load configurations from all .jars:

    public class ResourcesXmlApplicationContext
    extends AbstractXmlApplicationContext{
    public static final String SPRING_MODULE = "META-INF/springmodule.xml";
    public ResourcesXmlApplicationContext(ClassLoader loader)
    throws BeansException, IOException {
    // get all springmodule.xml as resources from all .jars
    protected void loadBeanDefinitions(XmlBeanFactory beanFactory) throws IOException {
    // for each springmodule.xml, beanFactory.loadBeanDefinitions(...)

    Define an interface of "System":

    public interface ApplicationSystem {
    public void start();
    public boolean isStopped();
    public void stop();
    public ApplicationContext getApplicationContext();
    public Registry getRegistry();
    public Locale getLocale();
    public InputStream getIn();
    public PrintStream getOut();
    public PrintStream getErr();

    Implement the "System" interface:

    public class ApplicationSystemImpl implements ApplicationSystem {
    * &#21551;&#21160;
    public void start() {
    try {
    } catch (Throwable e) {
    private static void doStart() throws Throwable {
    // &#33719;&#24471;HiveMind&#30340;ClassResolver
    ClassResolver resolver = new DefaultClassResolver();

    // &#21021;&#22987;&#21270;Spring Framework&#30340;ApplicationContext
    applicationContext = new ResourcesXmlApplicationContext(resolver.getClassLoader());

    // &#21021;&#22987;&#21270;HiveMind
    RegistryBuilder builder = new RegistryBuilder();
    registry = builder.constructRegistry(locale);

    Adder adder =
    (Adder) registry.getService("edu.ustc.eeis916.zmhu.appfw.test_hivemind_test1_Adder", Adder.class);
    System.out.println("1 + 2 = " + adder.add(1, 2));
    GenericResult testResult = (GenericResult)applicationContext.getBean("testGenericResultBean");
    System.out.println("Code=" + testResult.getCode() + " Message=" + testResult.getMessage());

    // &#35753;ServiceManager&#21551;&#21160;&#25152;&#26377;&#35813;&#21551;&#21160;&#30340;&#26381;&#21153;
    ServiceManager svcMgr =
    (ServiceManager) registry.getService("appfw.ServiceManager", ServiceManager.class);

    And in the Springframework configuration file springmodule.xml:
    <!-- The whole application system -->
    <bean id="applicationSystem" class="edu.ustc.eeis916.zmhu.appfw.impl.ApplicationSystemImpl">
    <property name="out"><ref bean="stdout"/></property>
    <property name="err"><ref bean="stderr"/></property>
    <property name="in"><ref bean="stdin"/></property>

    In the HiveMind configuration file:

    <service-point id="ApplicationSystem" interface="edu.ustc.eeis916.zmhu.appfw.ApplicationSystem">
    <create-instance class="edu.ustc.eeis916.zmhu.appfw.impl.ApplicationSystemImpl"/>

    And the bootstrap code:

    ApplicationSystem appSystem = new ApplicationSystemImpl();
    while (!appSystem.isStopped()) {
    try {
    } catch (InterruptedException e) {
    // do nothing

    Then, both HiveMind services and SrpingFramework beans can get instance of ApplicationSystem, from which, both can get Registry or ApplicationContext.

    Then, we can say, the two framework are connected, you can use the hibernate features and any SpringMind beans inside HiveMind services, and vice versa.

    Is this a dirty hack? ;-)
  19. ... slightly off-topic

    Assumption: We hang out on TSS because we are interested in Server-Side Java applications.

    Hypothesis 1: Success for Server-Side Java applications is achieved when they “go live” and meet SLAs.

    Hypothesis 2: Operations/Production IT Staff (not Software Developers) are responsible for delivering SLAs for the above applications using their favorite tools (e.g. Tivoli, UniCenter, OpenView, OpenNMS, etc).

    Hypothesis 3: The average Server-Side developer would rather work on “architecture, features, enhancements, etc”, than on “manageability”.

    Eclipse is not a Server-Side application. Its microkernel is great for a client/desktop application.

    -- Do any of the available MicroKernels (e.g. Avalon, Pico, HiveMind, Spring, etc) target Server-Side applications?
    -- Do they “auto-magically” provide some minimal level of “Manageability while in Production”?
    -- Based on JMX or another standard?

    The one exception is JBoss, which uses a JMX based Microkernel. I found an article:{583CB44A-AC47-4959-9C01-FA8DF0884EEE}
    However, the JBoss Microkernel is tied to JBoss.

  20. A manageable service framework[ Go to top ]

    As far as I know, an interesting approach is the one that carbon uses ( Note: I haven't ever used carbon, I only read the docs), which seems to expose every component as an MBean. Interestingly enough, both carbon and mc4j, which is a JMX management console (, are sponsored by the same consulting company and are likely to work well together. In my experience, direct manageability of a system is very important, and as such I welcome such kind of integrations and framework functionality.
  21. Again on manageability[ Go to top ]

    Carbon and JMX:

    Mc4j screenshots (on a jboss + carbon system, apparently :) ):
  22. This is a concern of mine. I'm looking to have HiveMind bridge the gap to JMX, to allow JMX MBeans to be exposed as HiveMind services. I want to make it very easy to deploy a HiveMind service as an MBean, and I want to have interceptors that record, using MBeans, performance behavior of services and service methods (at the very least, invocation counts and a rough idea of execution time).

    A key feature of HiveMind that's easy to lose track of is that, in HiveMind, you can create new services by invoking an existing factory service. These service factories can do a lot more than just instantiate an object and configure its properties (as hivemind.BuilderFactory does). For example, EJBProxyBuilder builds an entirely new class that bridges from HiveMind to a stateless session bean, encapsulating the JNDI lookup and invoking the create() method, along with automatic retries on RemoteException.

    Similar proxy-building services will bridge to JMX, but could also be a gateway for interop with Spring, Avalon and beyond.

    Other exciting ideas: imagine defining a pooling interface and creating a service but never providing the implementation of that interface ... a specialized builder could create a custom implementation of the interface just for your needs. Meta-programming in the HiveMind module deployment descriptor ... no different to HiveMind than the BuilderFactory or EJBProxyBuilder.
  23. and I want to have interceptors that record, using MBeans, performance behavior of services and service methods (at the very least, invocation counts and a rough idea of execution time).

    Invocations counts and executing time measurement are easy to implement as AOP interceptors for plain POJOs - at least that's what we do in Spring. So I assume you intend to use MBeans to gather that data and make it available, but not require application services to be implemented as MBeans for this.

    > For example, EJBProxyBuilder builds an entirely new class that bridges from HiveMind to a stateless session bean, encapsulating the JNDI lookup and invoking the create() method, along with automatic retries on RemoteException.

    The EJB proxy factory beans in the org.springframework.ejb.access package provide the same: This way, a local SLSB can be a simple replacement for a local POJO that implements the same business interface. I guess that's similar to what you want to achieve.

    We're just not automatically retrying on RemoteException in case of a remote SLSB, as we consider that the responsibility of the EJB client code (AFAIK, WebLogic supports such automatic retry for idempotent SLSB methods). You can subclass Spring's underlying EJB invocation interceptor to achieve this, though.

    Meta-programming in the HiveMind deployment descriptor... that sounds interesting, although I'm not entirely sure what the typical field of application will be. Anyway, I'm looking forward to seeing this in action.

  24. EJB proxying[ Go to top ]


    > For example, EJBProxyBuilder builds an entirely new class that bridges from HiveMind to a stateless session bean, encapsulating the JNDI lookup and invoking the create() method, along with automatic retries on RemoteException

    Transparent EJB proxying was described in my book over a year ago (although numerous people have arrived at the idea independently), and has always been a popular part of Spring.

    Spring also provides a "FactoryBean" concept which introduces a layer of indirection: for example, to create an AOP proxy for an underlying object; to create a client-side proxy for a web service, etc. It's trivial for users to write their own factory bean implementations.

    Anyway, I don't want this thread to degenerate into a debate between the merits of HiveMind and Spring. I'm more than happy for it just to focus on HiveMind (as it is a HiveMind thread). I just wanted to point out that Spring is far more powerful than you appeared to be implying. It's much more than just something to "instantiate and configure JavaBeans" based only on simple references.

    I hope you find a safe home for HiveMind and look forward to following its progress. I think it's important that frameworks cross-pollinate: it leads to progress and benefits everyone. And one of the great things about this wave of IoC frameworks is that application code may not be tied heavily into a framework, so users won't be locked in as badly as with earlier types of frameworks. I've already had a couple of interesting chats with Paul Hammant (Pico) about encouraging developers to produce components than can run in any IoC framework.

  25. EJB proxying[ Go to top ]


    I think this has been the most civilised debate between competing open source project members on TSS. Ever.

    Informative too.

  26. Qualifty of Discussion[ Go to top ]


    > I think this has been the most civilised debate between competing open source project members on TSS. Ever.
    > Informative too.
    > Sandeep.

    Thanks; I've learned a couple of things about Spring. Cooperation doesn't have to be cut-throat, in OSS, competition is just a way of motivating a kind of symbiotic cooperation.
  27. Since HiveMind will be a Apache project, and is much younger (malleable) than Avalon, will Geronimo use HiveMind as its MicroKernel? I assume Howard would be happy to do whatever is necessary for the Geronimo guys to adopt HiveMind.

    Here is the snippet I found from the Geronimo site:
    Using JMX as a kernel technology has facilitated the manageability of
    the system. A GeronimoMBean has been added, intended to be the basis
    for other services in Geronimo. This MBean provides support for
    multiple managed objects and implements the managed object, state
    manageable and event provider interfaces from the J2EE Management
    specification. Dain Sundstrom will be adding persistence capability,
    allowing the server configuration to be preserved between restarts.
  28. HiveMind and Avalon: collaboration[ Go to top ]

    Since HiveMind will be a Apache project,

    > and is much younger (malleable) than Avalon

    Actually, Avalon is malleable. If you look at many of the discussions over the past week or so, you will find that they are talking about how to incorporate similar ideas from HiveMind. Actually, they would like to discuss collaboration with Howard, and have issued a few invites for him to subscribe to the discussion.