commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hls...@attbi.com>
Subject RE: [PROPOSAL] HiveMind in the sandbox
Date Wed, 28 May 2003 02:30:01 GMT
I'm not an expert on Avalon, so this will be a learning experience for everyone involved :-)

HiveMind is targetted at a layer below Avalon; you would use its concept of services and
configurations to build a container like system, though it isn't a container per-se.  The
interceptor concept (which, of course, is an integral part of servers like JBoss and, in a
more
general sense, all J2EE app servers) can provide container like services; you can transparently
wrap
a service with a logger, a performance monitor, a JMX monitor, or a transactional wrapper,
whatever.
Perhaps part of HiveMind will be interceptor factory services for those type of operations.

Avalon has a more explicit assembly stage, where (this may be more Phoenix related) you assemble
Blocks, identify roles and so forth.  HiveMind is more dynamic, where the various HiveModule
descriptors are located, parsed, assembled, verified and applied at runtime ... this allows
dynamic
changes to the application for testing purposes, and the ability to provide difference versions
of
the application for different purposes.  In addition, HiveMind is specifically targeted at
a real
separation of interface and implementation ... where one module defines an interface (and
a service
extension point), a second module provides the implementation of the interface, and other
modules
provide interceptors to enhance the implementation.

For instance, for my at-work project (which I hope to use both Tapestry and HiveMind on),
there's
some database dependencies in our current code.  Using HiveMind to refactor, those dependencies
go
into one or more HiveMind modules.  Code that currently does a JNDI lookup to get a
DatabaseConnection will, instead, work through a new API that abstracts out those details;
we'll
have different implementation modules for Oracle, SQLServer, etc. ... and, of course, an embedded
server for local developer testinging.

In addition, we something that can be easily compatible with a number of J2EE application
servers; I
haven't been able to uncover the deployment story for Phoenix yet, but I don't see that Phoenix
SARs
will be compatible with J2EE EARs.  HiveMind modules will be packaged as llbrary and EJB jars
within
an EAR and will still be operational as such (just a matter of convincing Maven to produce
the right
Manifest Class-Path headers).

Again, I see HiveMind also operating at a lower level, as a gateway to the kind of code available
in
Avalon, or in JMX, or as EJBs.

I'm not trying to boil the ocean; what I see in HiveMind is a solution to some general problems
at
my work; HiveMind is a solution to those problems, but (like a lot of my solutions) it's very
general purpose.  I see it as having a lot of synnergy with existing Apache projects such
as Avalon
and Turbine.  I think a home in commons-sandbox is simply more appropriate than
yet-another-SourceForge project.

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



> -----Original Message-----
> From: EPugh@upstate.com [mailto:EPugh@upstate.com] 
> Sent: Tuesday, May 27, 2003 8:27 PM
> To: commons-dev@jakarta.apache.org
> Subject: RE: [PROPOSAL] HiveMind in the sandbox
> 
> 
> Can you elaborate on the differences between HiveMind and 
> Avalon?  After a first read, it seems like they both share 
> similar aims...?
> 
> Eric Pugh
> 
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@attbi.com]
> Sent: Tuesday, May 27, 2003 8:23 PM
> To: commons-dev@jakarta.apache.org
> Subject: [PROPOSAL] HiveMind in the sandbox
> 
> 
> 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
> 


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


Mime
View raw message