geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <dblev...@gluecode.com>
Subject Re: Deployment architecture
Date Mon, 03 Jan 2005 17:28:12 GMT
Just a couple curiosities.

Would moving the coupling between module builders to be coupling on 
work objects achieve much as far as actually decoupling the deployment 
system, or would it just introduce another brittle layer in the 
existing coupling?

Any ideas on how we would dictate the order of the deployment chain?

-David

On Jan 3, 2005, at 3:05 AM, David Jencks wrote:

> 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


Mime
View raw message