Berin Loritsch wrote:
>>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>
>>
>>>>>And the reason is:
>>>>>
>>>>>1. container are not peers when we are looking at them in
>>>>
>>terms of
>>
>>>>>component management frameworks - they a hierarchical and are
>>>>>subject to constraints concerning access to classloaders, kernel
>>>>>resources and so on. However, when we get to the
>>>>
>>management of the
>>
>>>>>services that provide
>>>>>
>>>>>
>>>>
>>>>Not all containers are peers though. I need to throw together some
>>>>real art (PNG or GIF for your preferred format?) to
>>>
>>>demonstrate what I
>>>
>>>>mean.
>>>>
>>>
>>>GIF
>>
>>I will throw something together soon then.
>
>
> The parentChild image shows the relationships of parents/children/peers.
> As you can see, the two parents both have a set of children. The
> children are peers with each other, but the children of one container
> are not peers with the other container. That holds true even when we
> have a root parent that acts as a parent to the two in the illustration.
> The two parents in that case would be peers with each other, but there
> is no change to the relationship of their children.
>
> Using the childChart image, we have a hierarchy of "containers" we can
> refer to. Each container has a unique name so I don't have to refer to
> a whole path when I am describing what I mean.
>
> I have seen some emails to the affect that we want a component from
> the container "sub1" to be able to access another component that is
> hosted in the container "end". With the hierarchy as is, that is an
> impossibility--and it needs to remain so. The Component/ServiceManager
> lookup mechanisms allow us to defer a lookup to a parent XXXManager.
> In affect, it lets us resolve UP the hierarchy of containers, but not
> ACROSS. This is by design.
What your describing above is very much along the lines of what happens
currently (with the exception of the point concerning CM/SM parents -
but that's another topic).
I agree with what you are saying when we take a snapshot of the
component assembly system at given point in time. For example, the
process of resolving dependencies for a component flows up the hierachy
in terms of establishing and binding the service provider. Once this
association between provider component and consumer component is
established for all of the components within a particular container - we
can step back and look at the container in its role as a dynamic
component within it's parent.
Here's the potential conflict-of-viewpoint :-)
The services available from the dynamic component (the container) could
be viewed as the logical sum of the services it has established).
This could be simply a function of wether you are looking at a container
as unit of isolation, or if you are looking at a container as service
publication vehicle. The distinction should be possible through policy
declared within the container (default policy being isolationist).
The side effect of this is that during the assembly process, sub1/ is
limited by the availablity of component types locally and in root/,
however, if you consider sub1/ as a publication vehicle, publishing into
root/, then the services available to sub2/ could potentially include
services established in sub1/ (assuming isolation/publication policies
enabled the necessary escalation).
> If "end" needs to use the same component that "sub1" needs to use, then
> the component needs to live in "root". Both allow the lookup path to
> go through "root/sub1" and "root/sub2/child1/end".
This is what Merlin is doing now - the isolationist viewpoint.
> Another benefit of
> this is to allow a child container to override the provided component
> from the parent container.
Merlin (current status) is not handling inheritiance style selection -
instead Merlin currently applies a selection process to the aggregated
set of matching candidate service providers from the immediate and
parent, parent's parent ..., etc. containers (actually the immediate
type manager and the manager's parent manager, etc.).
> That way, if "sub2" defined the "foo"
> component to be implemented with "Default-foo", "child2" can override
> the supplied implementation with "My-foo". Here is how it would look:
>
> Root: foo = undefinded
> Root/sub1: foo = undefinded
> Root/sub2: foo = Default-foo
> Root/sub2/child1: foo = Default-foo
> Root/sub2/child1/end: foo = Default-foo
> Root/sub2/child2: foo = My-foo
> Root/sub3: foo = undefinded
>
> If "end" or "child1" asked for a "foo" component they would get
> "Default-foo". If anything from "child2" asks for a "foo" component
> they would get "My-foo". If a component from any of the other
> containers in the hierarchy higher up than "sub2" asks for a "foo"
> component, they would not be able to find it.
This is achievable. All that is needed is a little recrafting of the
profile assembly and selection logic (which is little understated but
not too much).
> Renaming these things to make sense in your need to use JAMES directly,
> here is the problem you are facing:
>
> Phoenix/: mailServer = undefined
> Phoenix/JAMES: mailServer = JAMES
> Phoenix/OSM.planet: mailServer = undefined
>
> Each application is hosted in its own separate container. Your
> solutions include using the JavaMail API (connecting through SMTP),
> or to promote the mailServer interface to the Phoenix level.
>
> So components that expose a management interface need a way of being
> hosted, or at least proxied into the root container level. I think
> that Proxy is the best solution in this case, but the two
> applications are loaded with different classloaders. The proxy
> would expose the interface in the root container space, and allow
> you to use the application specific classloader to invoke the
> management interfaces.
Or we create the proxy implicitly for any service interface when
creating the service reference and we publish the reference in
accordance with component/comtainer policy. Eitherway, (I think) we are
talking about something similar.
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]>
