Proposal for the 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

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
microkernel's (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

HiveMind represents a generous donation of code to the ASF by WebCT
( 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

(1.1) Interaction with other packages

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

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.

(2.1) Identify the base name for the package


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

[EMAIL PROTECTED] -- User discussions
[EMAIL PROTECTED] -- Developer discussions and CVS update

(3.2) CVS repositories

The package will use a root branch of the hivemind CVS repository (to be
(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

Howard M. Lewis Ship <[EMAIL PROTECTED]>
Prashant Nayak <[EMAIL PROTECTED]>
Martin Bayly <[EMAIL PROTECTED]>
Christian Essl <[EMAIL PROTECTED]>
Harish Krishnaswamy <[EMAIL PROTECTED]>
Knut Wannheden <[EMAIL PROTECTED]>

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.


Prashant Nayak
Senior Architect, WebCT Inc.

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to