[PROPOSAL] HiveMind in the sandbox

["Howard M. Lewis Ship" <hl...@attbi.com>]

Proposal for HiveMind Package

(0) rationale

HiveMind is a simple, flexible framework for creating pluggable, configurable, reusable services. By
pluggable, we mean that there
is a complete separation of service definition and service implementation.  By configurable we mean
that modules may contribute
services and configuration data to each other in a well organized way.  It also means that
configuration data is pervasive, supplied
by many individual modules, rather than centralized in a single file.  By reusable we mean that both
HiveMind itself, and modules
created using HiveMind may be easily recombined and reconfigured for use in disparate applications.

HiveMind's basic unit is a module (a single project creating a single module JAR).  At runtime,
HiveMind builds a registry by accessing
a deployment descriptor in each module.  Modules can declare service extension points and
configuration extension points.
Services are expressed in terms of an interface, configurations in terms of a data type.  Modules
may contribute to service
and configuration extension points within themselves or, more frequently, in other modules.

A service contribution may be a factory (which creates a "Plain Old Java Object" (POJO) to implement
the service), or an interceptor,
which provides added functionality to a service implementation by intercepting method invocations.
Interceptors are created by a
particular kind of HiveMind service (to some degree, HiveMind is recursively defined).  Services may
also be called upon to
create acts factories for objects used by other services.

Modules may also contribute configuration extensions; these are objects that are specified and/or
created and plugged into a
configuration extension point.

A signficant portion of HiveMind involves the build time aspects of modules; this includes
specialized Maven plugins for
creating HiveMind modules using the HiveMind deployment descriptor as the basis for module
dependencies.  It also includes
generation of hypertext documentation identifying all of an application modules, extensions and
contributions.

The API for HiveMind allows threadsafe, easy access to services and configurations in a minimal
amount of code.  The
value-add for HiveMind is not just runtime flexibility: it is developer productivity.  HiveMind
systems will entail less code; key
functionality that is frequently an after-thought, such as reading configuration files, is handled
by the HiveMind in a consistent,
robust, well-documented manner.

HiveMind will embrace and adapt the best practices established in the Tapestry project, including
line-precise exception reporting
(a feature of Tapestry in which runtime objects are related back to the XML specifications from
which they were generated, to
assist the developer in diagnosing and fixing problems).


(1) scope of the package

The package shall entail a core library JAR, along with ancilliary artifacts such as Maven plugins
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-digester and commons-logging.

It makes use of OGNL (Object Graph Navigation Library) which is available from http://www.ognl.org.
OGNL is licensed under 
modern BSD.

HiveMind currently has dependencies on Tapestry.  Over time, a goal of HiveMind is to reverse those
dependencies, moving common code
from Tapestry to HiveMind.


(2) identify the initial source for the package

The initial codebase is being developed by Howard M. Lewis Ship. Source code is available for review
upon request (as a buildable Maven  project).

(2.1) identify the base name for the package

org.apache.commons.hivemind

(2.2) identify the coding conventions for this package

Coding conventions match those established in the Tapestry project.

(3) identify any Jakarta-Commons resources to be created

(3.1) mailing list

Until traffic justifies, the package will use the Jakarta-Commons list for communications.

(3.2) CVS repositories

For the time being, the package will use a root branch of the Jakarta-Commons CVS.

(3.3) Bugzilla

The package should be listed as a component of under the Jakarta-Commons Bugzilla entry.

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

Howard M. Lewis Ship


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



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org