Hi Peter:
There is a bunch of text below (usual long email) - but look out for the notion of something privileged - it may be a solution to a conflicting set of viewpoints I'm observing.
Peter M. Goldstein wrote:
The component type declares context criteria. This covers two things (a) the context interface that is expected, and (b) the key and class of each context entry. From a container implementation point of view can look at the context interface declaration as statement of a dependency that component has, that needs to be mediated by the container. A container can several different strategies to resolve this:Stephen,It also seems compatible with what seems to me to be the naturalTwo things I want to take issue with:
separation between Contextualizable and Serviceable. Context
involves data and services that are uniquely owned by the container (i.e. for Avalon Phoenix, getBaseDirectory(), requestShutdown() and for James Mailets, getPostmaster(), isLocalServer(String)). The essential distinction as I see it is that services should be user-defined and configured, while context-related items should be container-defined and not require configuration. Also, the services may include a
configurable dependency chain, while Context implementations should be available before any services are loaded and should not have a configurable dependency chain.
Firstly, I think the work "container" in the above context is much too broad - a container deals with a lot of things - one of these things is lifecycle mangement within which one aspect is context - I guess in my head thare is a signifcant difference between "container" (the system), "containement context" (the container side context concern) and "context" (the client side view of all of this). A "containment context" can be declared by interface (e.g. BlockContext) - the container implemetation can use this information to establish the "containerment context" for the component by deploying the appropriate
"containment context provider".
I'm using container here in a very specific sense. A container is a piece of software that implements a particular lifecycle and the set of component/container contracts that go along with that lifecycle. So Phoenix would be an Avalon Framework container. James would be a Mailet API container. So, while I don't quite get all of what your saying in this paragraph (container side context concern?), from what I do understand container == system.Second point - how a container establishes a particular container
context is a container concern - there should no constraints here on how a container resolves the requirement- i.e. I don't agree with the last sentence above.
That's fair. But I do have a couple of questions about this point of view. First, who establishes the dependency chain for the container context? Is this a user configurable feature, machine-configurable, or either in your view?
1. Require static (or dynamic) configuration of a context
provider as part of the container deployment
configuration.
2. Require static (or dynamic) configuration of a context
provider as part of the component deployment
configuration.
3. Separate the concerns of context provisioning from
the concern of context management, and then consider
the context manager or managers as services that are
dynamically wired into a contextaulization service
(where the contextualization service is just one
part of the container architecture).
Option 3 is my favorite because it means that I assembly my container for the containment scope I interested in (Servlet, Avalon, Mailet, ORB Initializer, etc.). We already know that (3) is possible based on the Merlin/Fortress collaboration on extensions - the result of that is the automatic discovery and establishment of lifecycle extension providers for a component. Doing the same thing for context requires similar specification of a standard context manager interface, and corresponding meta in a manager declaring the context class or classes it supports.
It is a necessary requirement - and its not an issue - the client sees some instance in response to a get( key ). The client does not need to be concerned with the resolution process. An implementation of Context could be holding references to a bunch of different context managers and mediating requests.Second, does the dependency chain for the context have to be complete (specifically every element of the context is completely available) by the time the first user defined service is loaded? To me, this seems like a necessary requirement, but I'd like to hear other opinions.
There are two views you can take here:Third, how would you phrase the distinction between Context and ServiceManager? What is the key issue, in your mind, that separates items made available via Context and those made available via ServiceManager? How would you elucidate this to someone new to the Avalon Framework?
* the state/service separation
* the container/peer separation
On state/service view of the world, context entries are little thing like files, timestamps, a meta-data instance, classloaders, etc. These are typically used as arguments to internal operations within your component implementation. On the other hand, service are more heavy weight, you have to declare information about the fact that an component class provides a particular service, you have notion of a service version, to provide the service other component have to declare dependencies. That overhead is the barrier from jumping from "context-driven" to "service-driven". But the other side of the equation is that service driven means that a good container will be able to do an enormous amount of work for you - and the end result is that your code shrinks, you establish well defined blocks of functionality with clear specification of dependencies and good support for loose-coupling.
The container/peer view is complicated by a couple of things. If you consider that context is aligned with a container, and that service is aligned with peers of the component - you introduce a very different idea of the responsibilities that these contract represent to a component. I believe that the distinction between context and service interfaces properly addresses the distinction between state and service, but, I recognize that a strict line is complicated when we look at context as the point of communication between component and its container (as opposed to the notion that the SM interface represent peer communication).
My current thinking on this is that we need a separation notion - *privalided" services and context dependencies. The notion of a privileged service or context simply means "the container is responsible for providing the service" and distinct from "the container is responsible for mediating the service". If we were to provide two FileService instances, one being privileged and other non-privileged - the "non-privileged" notion corresponds to a peer, whereas the privileged notion implies responsibilities on the container.
The notion of *privileged* context entries and services would enable elimination of the association of context with container, and IMHO, that would be a very good thing.
Consider "urn:avalon:work", a java.io.File. This is an example where context is best because you don't want to pollute your component with a particular file service when all you is the state. However, the "component-entry-provider-implementation-component" could well be a service. This is also similar to a context entry containing the key chain of the invoking principal - the context interface lets us get the key chain value without concern for the service hat establishes the value (which may be interceptor, backed by a vault service, backed by a database service, etc).This last point is what most confuses me about loosening the restriction with which you take issue. I find the line grows blurry unless this is held. Do you have any explicit examples of a container-owned item that would require a configurable dependency chain? I haven't been able to come up with one that sounds reasonable.
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]>
