Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
Content-Transfer-Encoding: 7bit
Message-Id: <95927710-5D66-11D9-8400-000D93361CAA@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: dev@geronimo.apache.org
From: David Jencks <david_jencks@yahoo.com>
Subject: Deployment architecture
Date: Mon, 3 Jan 2005 01:05:16 -0800

The current architecture of deployment might be considered to have some 
limitations.  It is not clear how to extend the system to deploy more 
artifacts such as web services and portlets, let alone artifacts we 
don't know about yet.  There is also a growing web of dependencies 
between module builders to take care of ejb references, connection 
factory references, and bits such as security and naming.  I also think 
there may be situations where an incompletely processed artifact does 
not cause a deployment error.  I wonder if there is a simpler more 
extensible architecture.

What I'm thinking of has two main new features:

1. a chain of  builders with only one method, "build"
2. some sort of "deferred work" object that allows one builder to ask 
another one, farther down the chain, to do some work for it.

Lets look at how builders interact with each other:

One type of interaction is for a builder to add extract some 
information from the current deployment plan and cache it in the 
deployment context for use by itself or other builders later.  For 
instance, the connector builder figures out the activation spec 
metadata and puts it in the context for use when deploying message 
driven beans.

This type of interaction can be  handled by a chain of builders by 
simply having two builders: the first one adds the shared info to the 
context, and the second one(s) use it.

Another type of interaction is for a builder to extract some elements 
from the spec and/or vendor plan and immediately ask another builder to 
process it.  For instance, ejb and resource references are immediately 
processed by the naming builder, the vendor security descriptor 
elements are immediately processed by the security builder, and 
dependency and gbean elements are processed by the service builder.

Most of these are used to construct a gbean attribute value which is 
not used further during deployment.  So, perhaps the builder needing 
the work done could construct a "deferred work" object containing the 
element to be processed and the gbean and attribute name, and add this 
to the context.  Then the, e.g., naming builder could look in the 
context for deferred work objects that it understands, process them, 
and set the appropriate gbean attribute values. If any deferred work 
objects were left over unprocessed when it came time to serialize the 
gbean state, we would know there was a deployment problem.

The dependency elements in the plans are used to construct the 
classpath, which is needed during deployment. Each builder could 
extract these elements and put them in deferred work objects: in this 
case the processing would not set a gbean attribute value, but would 
result in adding to the classpath.

The ear deployer might fit well into this scheme.  Instead of calling 
specific module builders for each type of module it recognizes, it 
could bundle up the info for each module into a work object that it 
adds to the context: the current module builders would then look in the 
context for the work objects they understand.

Right now I'd characterize these ideas as speculation and wonder if 
anyone else thinks they are worth pursuing further.  I also wonder if 
limiting the objects in the deployer chain to a single method has too 
little structure and giving them several methods to be called in a 
specified order, as with the current architecture, would provide better 
organization without limiting useful functionality.

Many thanks,
david jencks