Proposal for HiveMind Project

(0) Rationale

HiveMind is a simple framework for creating pluggable, configurable, reusable services.

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.

The API for HiveMind allows thread-safe, easy access to services and configurations with a minimal amount of code. The value-add for HiveMind is not just runtime flexibility: it is overall developer productivity. HiveMind systems will entail less code; key functionality that is frequently an after-thought, such as parsing of XML configuration files, logging of method invocations, and lazy creation of services, is handled by the HiveMind framework in a consistent, robust, and well-documented manner.

HiveMind fits into an area that partially overlaps the Apache Avalon project, with significant differences. 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).

HiveMind represents a generous donation of code to the ASF by WebCT (http://www.webct.com). HiveMind originated from internal requirements for a flexible, loosely-coupled configuration management and services framework for WebCT's industry-leading flagship enterprise e-learning product, Vista. Several individuals in WebCT's research and development team in addition to Mr. Howard Lewis Ship contributed to the requirements and concepts behind HiveMind's current set of functionality including Martin Bayly, Diane Bennett, Bill Bilic, Michael Kerr, Prashant Nayak, Bill Richard and Ajay Sharda. HiveMind is already in use as a significant part of Vista.

(1) Scope of the package

The package shall entail a core framework JAR (containing essential classes and services), a standard library JAR (containing generically useful services), along with ancillary artifacts such as Maven plug-ins and, of course, documentation, all distributed under the Apache Software License.

(1.1) Interaction with other packages

HiveMind has dependencies on several standard commons packages, including: commons-lang, commons-beanutils, commons-collections and commons-logging.

HiveMind makes use of the Javassist bytecode generation library, which is available under the MPL (Mozilla public license).

(2) Identify the initial source for the package

The initial code base has been developed by Howard M. Lewis Ship within the Jakarta Commons incubator.

http://jakarta.apache.org/commons/sandbox/hivemind

(2.1) Identify the base name for the package

org.apache.hivemind

Note: the current code base reflects an alternate package name, org.apache.commons.hivemind. Subsequent research has shown that HiveMind is not a suitable candidate for the Jakarta Commons. The existing code base will be migrated to the new package during the transition out of the sandbox.

(2.2) Identify the coding conventions for this package

The code follows a modified version of Sun's standard coding conventions, with the following stylistic changes:

• instance variables are prefixed with an underscore
• a newline is inserted before all braces

(3) Identify any Jakarta resources to be created

(3.1) mailing lists

hivemind-user@jakarta.apache.org -- User discussions
hivemind-dev@jakarta.apache.org -- Developer discussions and CVS update notifications

(3.2) CVS repositories

The package will use a root branch of the hivemind CVS repository (to be created).

(3.3) Bugzilla

The package should be listed as top level component, "HiveMind".

(4) Identify the initial set of committers to be listed in the Status File.

Howard M. Lewis Ship <hlship@apache.org>
Prashant Nayak <prashant.nayak@webct.com>
Martin Bayly <martin.bayly@webct.com>
Christian Essl <christianessl@yahoo.de>
Harish Krishnaswamy <hkrishnaswamy@comcast.net>
Knut Wannheden <knut.wannheden@paranor.ch>

This list represents the most active HiveMind participants within WebCT and on the Jakarta Commons Developer mailing list. Notably, Mr.s Essl, Krishnaswamy and Wannheden, among others, have already been actively mentoring other interested users on the mailing list in how to use HiveMind as well as contributing design ideas and patches to the framework itself.