So the context we are discussing is actually the context of the
component? Rather than a context being handed to the component, a la
Contextualizable.contextualize(Context)?
I thought we were discussing the later.
Corey
On Wed, 2002-07-03 at 23:18, Stephen McConnell wrote:
>
>
> 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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
