avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [ANTI-VOTE] Lifecycle Extension Tags
Date Mon, 28 Jul 2003 16:20:12 GMT


Peter Royal wrote:

> On Monday, July 28, 2003, at 11:04  AM, Stephen McConnell wrote:
>
>> Do they understand what they are voting for?  My guess is that they 
>> will assume the very simplistic line from Berin that this is about a 
>> namespace.  They will not take into account the ramifications.  They 
>> probably will not appreciate that this is a divisive point in terms 
>> of the avalon component model. They will probably not appreciate that 
>> it introduces a separation at the core of Avalon and from that 
>> separation there will eternally be those that do and those that don't.
>
>
> Can you succinctly list the ramifications? 


I'll try!

There is a social implication complicated by a contractual limitation.

The social implications is:

   * "it's not I the avalon namespace I don't have to worry about it"

This is complicated by a contractual limitations:

  * "the avalon namespace model does not support model extension"

I want to start things off with the social implication, however, let me 
just note that under the @avalon namespace we do not have any notion or 
mechanism to declare expansion of that namespace.  This means that if 
something is not inside Avalon namespace - well - it just does not exist 
in terms of something standard and recognized.  But I'll come back to 
this in more detail.

On social implications:
-----------------------

The @avalon.stage tag declares that a component has a deployment phase 
dependency relative to a container.  This means that a container should 
either fulfill that deployment phase dependency or toss out the 
component.  The @avalon.stage tag does not dictate a mechanisms to a 
container - it simply declares a deployment criteria.

If we retract the @avalon.stage (and the corresponding 
@avalon.extension) tags from the Avalon namespace, we are stating that 
the notions of deployment phase (versus classic runtime phase) notions 
are concepts that can be ignored. There is dilemma here, because the 
vote in question does not address the implications.  If you remove 
@avalon.stage from core Avalon - then any component that leverages 
deployment phase dependencies (i.e. components that fulfill stage 
execution) will no longer be a valid Avalon components.  The implication 
of this is that a container could be asked to deploy such a component, 
and unless the component does its own error checking to validate that in 
fact its lifecycle stages have been executed, we enter the gray zone of 
unpredictable components.  This gray zone is components executing on the 
assumption that they have been fully deployed.  This potential false 
assumption can lead to failures in security, inconsistency in service 
delivery behavior, and potential damage by a component simply because it 
is acting under incorrect assumptions.

The counter argument to this case is that the notion of a lifecycle 
dependency can be moved to @lifecycle.  Socially this will ignored.  As 
soon as we start down the track of multiple compliance levels we will 
have lost.  Containers outside (and quite probably inside) Avalon will 
ignore @lifecycle because its not part of a "core" @avalon contract.  
Those containers will not validate components in the same way.  Those 
components and will be running blind.

If we don't do a complete description of container responsibility - they 
we must do nothing less that revert to container specific solutions 
@phoenix, @fortress and @merlin.

On contractual limitations
--------------------------

As mentioned about - @avalon.stage is not about excalibur-lifecycle.  
Its about the declaration of a deployment phase dependency.  One cannot 
simply retract this tag from the Avalon namespace without providing a 
solution.  The problem concerns many components that use extensions and 
their need/requirement to declare that criteria to a container in a 
consistent fashion. Under an @lifecycle solution - you MUST have a way 
of declaring within the @avalon namespace, that an @lifecycle is to be 
including in the component deployment criteria.  This is non-trivial.

In my own experience the lifecycle stage model has served to address 
some key limitations of the Avalon component contract.  This is based on 
experience with stage extensions that use excalibur-lifecycle and others 
that are totally independent of excalibur-lifecycle.  These advantages 
must not be lost.  To assure this we have a choice .. we either 
recognize the deployment phase dependencies can exist, or we halt this 
process and go back to the drawing board and come up with a revised 
specification that addresses component criteria at a more abstract 
level.  I believe that what we have today is complete and consistent.  I 
believe that we will come up with a small but interesting number of 
different approaches to stage management (including inceptors and event 
based handlers).  I do not believe that this will be contradictory to 
the @avalon.stage tag.  Instead, they will represent different, smatter 
better solutions to handling the criteria expressed by an @avalon.stage.

I also thing that as we move forward, with experience based largely from 
work with extensions, we will figure out what we need in terms of tags 
extension semantics (i.e. how to tell a parser to look beyond @avalon 
and what to do with the result).  Those ideas will have ramifications on 
tag definitions, meta info, meta data, meta models, and containers.  In 
the meantime, a complete solution (i.e. including the deployment phase 
dependencies) will provide more than most people will need and 
everything that Avalon needs.

Summary:
--------

* moving out of core means death to the idea of reliable deployment 
across containers
* an absence of an extension mechanism in @avalon core makes the 
proposal technically invalid

Now is not the time to throw together an extension mechanisms - the 
problem is non-trivial and a solution need to grow from common needs, 
interests and experience.  Now is not the time for another divergent 
split in Avalon - containers that see and contains that don't (i.e. 
containers that recognize the full criteria and containers that claim 
Avalon compliance but ignore the reality of what developers are doing 
using release Avalon product).

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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


Mime
View raw message