Corey Jewett wrote:
>Trying to follow what's going on here it seems to me that Stephen wants
>an ObjectConfiguration under the name Context.
>
>
Nope!
What Stephen wants is to provide support for any component consitent
with the component model. I'm not concerned with what the component
does with infortantion supplied to it.
I am concerned about a fault in the containerkit architecture which if
not corrected will result in continued non-portability of components.
I'll try and explain. I working on a container - basically an
application that automates the creation, deployment and decommissioning
of one or more components (without concern for an component implementers
idea of what is good, bad, appropriate or otherwise). A container that
has an objective of running any component has to be able to provide the
information that the component declares that it needs. But this
requires synchronizing three different viewpoints - the *component*
model itself (stable and something that represents a fixed point in this
equation), the specifications and implementations of resources through
which a component can declare *constraints* (this is the content of the
containerkit metainfo model), and thirdly - the *criteria* within a
metadata model that is used to describe how information to be passed
between a container and a component is created. Typically, the approach
to metadata creation is container specific - however, container kit
provides some basic structures on which different contains can share
common foundations.
If your look at the component model in Avalon it is defined though a set
of patterns and interfaces. Six of these interface actually declare
state that maybe required by a component - these include the LogEnabled,
Configurable, Parameterizable, Contextulizable and the
Serviceable/Composable interfaces. Of these, the Contextualizable and
Serviceable/Composable interfaces present a significantly higher level
of container/component interaction than the rest. In the case of the
Composable/Serviceable interfaces the metainfo model appears reasonably
complete in both metainfo and metadata. The model provides support for
declaration of the association of types services that are keyed relative
to the container scoped names. The model does not dictate how the
associations are derived (that's a container concern). In general is a
level of abstraction I'm very comfortable with. However, if we look at
the same picture from the point of view of managing Contextualization of
a component - the containerkit framework is either (a) incomplete or (b)
inconsistent. What we have in containerkit is the full definition of
the metainfo (ability to describe the context constraints), but nothing
on the metadata side.
Some suggestions have been put forward stating that validation of
component metadata is impossible. Other information has been provided
that shown that this is possible, already available, and has been in use
for some time. However, much of the discussion on this thread has
focussed on discussing that mechanisms to deal with a broader set of
context requirements based on existing and current cases of context
usage (which is primary reference point). An important consideration
here is that the containerkit framework does not need to include the
mechanisms for context directives, directive validation or even creation
- all of those things can be handled by a container implementation.
The issue is that the current definition of the metadata type that
effectively represents the set of information to be used in establishing
the state of a component does not include an operation to get the
context instance. If you look at the component ComponentMetaData class
in containerkit you will find operations enabling access to instances of
Parameters, Configuration but nothing for Context.
The solution is to add a single method to ComponentMetaData:
/**
* Returns the context object for the component.
* @param parent the parent context
* @return the context object to be supplied
*/
public Context getContext( Context parent )
{
return context;
}
Simple!
But the impact is significant. It means that services that I develop
that extend ComponentMetaData can override this method to provide
complete support for the standard component model and metainfo
constraints. This means I can say to customers that the container I
provide is capable of delivering complete support for the component
contact. Beyond this, we will be able to deliver a validation tool that
checks component integrity - its then the obligation for the container
authors to provide nothing less that 100% compliance with a component
contract or document non-compliance.
One last point - why is this important? If Context is not provided
through the ComponentMetaData class, then the ComponentMetaData clas is
not a reference point for portability (because container developers will
handle the context issue in different ways). This simply means that a
lot of potential for component reusability disappears and the value of
containerkit diminishes.
Hope that clarifies things.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
