On Fri, 22 Nov 2002 18:22, Stefano Mazzocchi wrote:
> Peter Donald wrote:
> > Sure - one container would be nice. It is not like it has not been
> > attempted before in the past. Maybe some history is in order.
>
> [snip]
>
> I'm sorry but in what you write I really fail to see any technical
> reasons why there couldn't be one Avalon Framework implementation that
> serves everybody's needs.
We have tried and failures have not been due to egos - nor have they been to
lack of effort. It is just a hard problem to satisfy all or even provide a
platform capable of doing what people need and want (or even just need).
I actually think it is closer now than at any time before because we have
found which approaches don't work - also we have MS who introduced some of us
to attribute driven development. Combine that with compiled interceptor
chains and we have a viable container IMO that satisfies all our needs.
However - in no way shape or form do I intend to bet the farm on my belief.
Incremental controlled changes are much better in this particular situation
because the changes do not require a revolution - just evolution.
> The only reason I see is human: people even *disagree* on *what* an
> avalon framework implementation (aka container) is.
>
> I suggest that we start from there.
an Avalon container host Avalon components in an environment and provides
resources to such components. Thats about where the absolute commonalities
end.
Most containers have the notion of a partition or scope. In some cases (ie
Phoenix) they are flat while in others they can be hierarchial (all the
others?). Some declare metadata in descriptors, some by introspection and
some by assembly directives (and some have not notion of metadata).
The general pattern in most newer containers is to separate info out data
different layers;
1. information about component type (aka ComponentInfo)
2. information about how to a assemble a component instance (aka
ComponentMetaData)
3. information about runtime state of component (or components in case of
pooled components) (aka ComponentEntry)
Now (1) can be cross container relatively easy. (2) is likely to be about 70%
portable between containers and (3) will most likely be completely container
dependent.
If (2) is partially specified it may termed a "template".
(1) + (2) when combined form a Profile. Merlin is capable of reading profiles
that sit side by side components while no other containers can do this atm.
Phoenix creates Profiles but only by manually merging (1) and (2) durin
assembly process.
When a bunch of profiles are taken together they form an assembly (aka
Application) which may have more than one partition.
Components may be stored in a jar as part of a library - lets call these
"ReusableUnits". Sometimes the jars are ready to run and include information
to build an assembly - lets call them "DeployableUnits" (think .war files).
Sometimes when we create an assembly we will not fully specify the assembly
directives because it is a PITA to do so. So we try to auto-assemble an
assembly. ECM/Fortress does this by implicitly mapping container components
into local components namespace using 1-to-1. Merlin will use mappings
defined by user and try to use huieristics to map in other components.
Phoenix currently requires that a user fully specify the assembly but there
is a patch that will make it behave similar to Merlin.
Some containers also have the notion of "layers" (not sure if we have ever
created a term for this). ie In Phoenix first we "activate" all listeners and
then all the components. In the future interceptors will also have to be
created prior to other components.
Related to staging is the notion of hierarchial partitions. We need this
because certain "layers" may require services from parent partition. ie
Interceptors may require access ot parent partitions services.
In the future I would also like to have factorys/locators to indicate how
components are created. We used to have it in Phoenix and there has been work
to re-add it again (mainly as because we are now JDK1.3 compatible and thus
we can use Proxys).
Theres a few really open questions that haven't been answered even vaguely
enough and wont be until we experiment (ie how to expose components in child
partition to this partition dynamically).
The above is the basic concepts required to achieve any sort of complete
service kernel. Or even any degree of commonality between containers. However
I believe pushing any concepts now or trying to do a revolution is a bad
idea.
I think we need more in the way of evolution. The first step would be to
define (1). We should also define a set of javadoc attributes to declare this
information in the source file. The second step - give (1) time to settle and
then we can define the format of "ReusableUnits".
At this stage we have have components that are portable across containers and
librarys of components (and resources) that can be shared across containers.
After that stage I think we just let time & darwin do it's job. It may be
possible to attempt to define (2) (or common model and transform via XFC) or
other container features - however I think that is much much much harder
thing to tackle. However I would put this sort of an approach off for at
least a year to see where different experiments lead.
In the meantime it would be nice if functionality was gradually migrated from
containers into toolkits (along with documentation and unit tests) - much
like Phoenix is doing. That way each bit of functionality can be reused by
other containers where they want.
--
Cheers,
Peter Donald
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
