You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/08/27 17:16:01 UTC
Merlin Container
I began trying to use Meta and Container in Fortress, and started to
look
at Merlin 2 on how to best do this. The Container interface exposes
methods
to the implementing container so that the kernel can do its magic.
There
are some things that look suspiciously like subversion of control that I
am curious about. First, the simplified interface that I would be happy
with is:
interface Container
{
void install( Profile[] profiles );
}
The reason is simple: information should flow inward, not outward.
Container
hierarchies should not be determined based on the kernel's viewpoint,
but
on the way that the developer sets it up. Granted, the current approach
allows
the kernel to set everything up, but let me illustrate why Fortress and
Merlin
have very different viewpoints on setting up the container hierarchy.
* Querying the state of the child
- Merlin's kernel queries the state of the child container, as opposed
to
knowing it.
- Fortress knows the state of the child container because the parent
container
set it. Information flows from the parent to the child (inward),
but no
information flows from the child to the parent (outward).
* True hierarchy vs. Flat hierarchy
- Merlin asks a container to create an instance of a child container,
presumably
so that it can directly manage it--or pass in the profiles.
- Fortress allows the containers to create whatever child containers
it needs.
It provides the framework that does not bind the container writer
into one
way of doing things. You don't even *have* to use the provided
Container
interface or the provided ServiceManager/ComponentManagers.
* Architecture specific constants
- Both Merlin and Fortress have architecture specific constants that
are passed
in (presumably by the context object). These constants are
container specific.
- Fortress deals with this by separating out the constants into
separate
interfaces instead of merging them.
Both Merlin and Fortress do work, but Merlin side-steps IOC by making
all containers
in a system as peers--at least that is how it looks. I would like to
understand
the thought processes behind the decisions.
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merlin Container
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Berin Loritsch wrote:
>>
>>
>>>Outward flows of information include:
>>>
>>>* getName() (not setName())
>>>
>>
>>This was a convinience operation only used in logging messages by a
>>parent container. Its easily removed.
Removed.
>>
>>>* Container createContainer(...)
>>>
>>
>>Can be removed from the interface.
>
>
> :) That would make me happy.
Be happy - it's done!
>
>>>* getState()
>>>
>>
>>This one is more complicated. Invoking suspend on a
>>container results in the invocation of supend on all
>>subsidiary containers and the parent basically waits for
>>all subcontainers to achieve suspension before
>>considering itself suspended. This was not in the interface
>>before but the introduction of the ability to plug-in a
>>foreign container in a heirachy complicated things. I've got
>>some ideas but I need to think some more first.
>
>
> Right. This stems from the decision to have each and every container
> run in its own thread. The simple solution would be to have the
> suspend() and resume() methods to block until they are completed.
> It is perfectly reasonable to do that, and manage the number of threads
> you want to use for the purpose of simultaneously suspending and
> resuming the containers within the parent container.
As part of looking at refactoring this I've been digging into the
excalibur/event package. One problem I'm comming up against is a lack
of examples or cookbook style documentation - are their sources of
examples of the usage of the event.command utilities hidden away anywhere?
>
>>>* getResources()
>>>
>>
>>This is part of the service functionalityb of a container.
>>Keep in mind that a container acts as a factory of services
>>derived from the component implemetation it is managing. The
>>getResources() method isolates managed compoents from the
>>services they provide. There is an alternative - namely the
>>publishing of the established service back to the component
>>manager (classloader) which may be more consitent however
>>- I think this operation will still be needed in management
>>applications (but that could be split out to a different
>>interface).
>
>
> In my mind service == component, so could you help me understand
> your distinction between the two?
component == implementation
service(s) == work interface(s) declared by component
> Also understand that not all containers will want to expose
> any "resources" (is that supposed to be the same as management
> interfaces?) so it should be moved into a separate interface.
The management interface is another topic - seperate interfaces will be
needed for that. I referring only to the work interface when I use the
term service. Normally this will be proxied - but proxies are not in
place today (a matter of prioritising the list).
>
>
>
>>>>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.
I'm working through the other emails now.
>
>>There is some enhancements that need to be applied to the
>>thread model - basically moving thread establishment from
>>the container to its parent.
>
>
> Right.
>
>
>> That's going to have some impact on the control mechanisms
>>and should enable some simplification of the interfaces (and
>>implementation inside DefaultContainer).
>
>
> correct.
>
>
>>>However, there are many ways to publish a component, and to
>>>mark a component as publishable.
>>>Keep in mind that the container does not have to respect the
>>>publishable attribute. It is perfectly valid to be more
>>>restrictive, but it is definitely not valid to be more lenient.
>>>
>>>
>>
>>Absolutely - the intention concerning the getResource() operation
>>is that a container is always in control of the resources it
>>exposes. I'm also working on a URL based container access
>>mechanism - its working with remote containers at the moment and I
>>have in mind a generalization of this that could replace the
>>getResources() operation. It would basically provide similar
>>functionality to the ECM lookup semantics - but service instances
>>would be packaged under a java.net.URL. Different URL handler then
>>take care of the interaction with a local or remote containers
>>during service resolution.
>
>
> It sounds interesting to say the least. I still don't have the "big
> picture" of exposing the resources that you describing. Some of the
> clouds have moved out of the way, but it seems we have some heavy
> cloud cover on this one.
I would be kidding if I said that everything was clear-skies over here
(but I wouldn't call it overcast either).
;-)
I'll try to fill in some of the gaps as answers to the other emails you
have sent through this evening. There is perhaps one area where I'm
looking at things differently. We share the same ideas concerning
component management and the restrictions that apply when building the
component system. However, when that system is built, services and
established, etc. I think we have take a step back, place the component
hierachy on its side and look at it from the edge. What we see is a set
of services. If we tilt the page back just a little, you will notice
that these services are popping up from identifiable containers (i.e.
the container hierachy provides an addressable set of established
services). This is where the URL principals come in - a URL declares
the path to the service and can be used to activate the service. All
this is doing is saying there are two distinct viewpoints to a container
- one is the type/component management infrastructure viewpoint, the
other is the service network viewpoint. While a container is component,
I consider it a special type of component in that it is exposing a
dynamic service content (qualified and controlled by policies etc.).
But keep in mind that the export side is relatively uncharted territory
at this time - still experimenting.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merlin Container
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>
>>>>>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:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merlin Container
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>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.
>>
>
>
> You have it pretty much spot-on what I want.
>
> Would the subcontainers inform the root container what components they
> allow to be proxied, or does the root container tell the subcontainers
> what components they should proxy? What about sub-sub-containers?
>
My take on this is that service visibility needs to pushed by the
publishing container. The parent container then applies its publishing
policies relative to its own services and the services publised by child
containers. This isn't strict IOC - its more a parent/child container
collaboration.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merlin Container
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>>
>>
>>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>>
>>>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.
>>>
>>
>>You have it pretty much spot-on what I want.
>>
>>Would the subcontainers inform the root container what components they
>>allow to be proxied, or does the root container tell the subcontainers
>>what components they should proxy? What about sub-sub-containers?
>>
>>Unless we get one big über-container, Nicola's view of containers-
>>as-adapters require this to work.
>
>
>
> For things like this to work, it has to be an attribute to the Service
> definition that lets the container know that it is meant to be exposed
> as a management interface. The Container would then either do nothing
> because all children are trusted at the container's level, or proxy the
> service into its namespace.
>
> Keep in mind that you would not host an App as a child of an App in
> most cases, so the reason for this to happen is really only under
> special circumstances.
My experience shows that a conflict of interest assises here. Take the
James example taking the approch of class isolation - putting common
resources higher in the container hierachy, depedent resource lower in
the hierachy. You end nicely isolating the james package which is good
from a class management perspective but problamatic if you apply the
same principals to service publication.
/cornerstone <-- cornerstone classes
- datasource selector
- repository manager
- time scheduler
- sockets
/james <-- james classes
-- dns
-- nns
-- nntp
-- nntp-auth
-- nntp-server
-- users
-- mailstore
-- james
-- spool
-- smtp-server
-- remote
What is desirable in the above scenario is to consider the complete
picture as a complex system in which only a few specific services are
actually published by the root container.
The conceptually desirable solution is to take the above container
graph, put in a block box, expose the service interfaces of interest,
and asset the result as a dynamic component. This gives you benefit of
good internal structure combined with the benefits of encapsulation.
However, as things stand today, the notion of encapsulation does not
exist within the container defintion.
Cheers, Steve.
> The contract with the exposure has to do with
> the service interface and the the container. It cannot and should
> not propogate endlessly up the hierarchy chain.
>
> Using this solution, and the images I supplied, if "child2" was exposed
> as a management interface then it can be accessed by "sub2", "child1",
> and "end". However, none of the other "sub"s would be able to see it.
> It forces you to be smart about what you expose and where.
>
> In the example hierarchy I sent in the previous mail, if "root" isolates
> all its children, then you can only see what is exposed as a management
> interface. On the other token, if "root" has all of its children in the
> same namespace, then "sub3" can access "sub2" and "sub1", but none of
> their children. Either case is good.
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merlin Container
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > >
> > > Using this solution, and the images I supplied, if "child2" was
> > > exposed as a management interface then it can be accessed
> by "sub2",
> > > "child1", and "end". However, none of the other "sub"s would be
> > > able to see it. It forces you to be smart about what you
> expose and
> > > where.
> >
> > Sounds OK. Use case: Using Merlin as root, but wanting to use a
> > Phoenix-only component. Would like to put Phoenix in as a
> > sub-container, but still be able to access the component I
> put in it:
> >
> > Root (Merlin)
> > |
> > +--- Phoenix Embedded
> > | |
> > | +--- Component A
> > |
> > +--- Component B
> >
> > Component B should be able to see/use the service provided by
> > Component
> > A, and vice versa.
>
>
> :/
>
> I would say either make Component B hosted inside Phoenix as well,
> or make Merlin able to handle the additional contracts with
> Component A.
>
> With this arrangement, Component B would be able to see Phoenix and
> Phoenix would be able to see Component B. So indirectly, if Phoenix
> did not isolate itself (because it was not designed for embedded use)
> Component A could access Component B--but not vice versa.
>
> There are two reasons for this:
>
> 1) Mutual dependencies of components on the other is generally a sign
> that you need to merge the components into one. I.e. there is a
> design problem with the components.
Berin,
I never said they are dependent on each other. What I meant was that
I should be able to make it so that Component A can access Component B,
or vice versa. That is, I should be able to handle Component A
dependent on
Component B ***OR*** Component B dependent on Component A.
> For both of those reasons you would have a hard time
> convincing me that
> what you outlined is a ligitimate need.
Legitimate need is this:
+ Merlin and Phoenix are currently not completely compatible due to
various reasons well documented in the ML archives.
+ I do not think it is impossible for them to become compatible, but
I'm not about to bet anything on them doing so or, more importantly,
*staying* that way.
+ So, if I want to use a container I have to pick Merlin or Phoenix.
+ I want some way to create adapters for containers so that the
compatibility layer in Phoenix or Merlin is as small as possible.
+ A general "please expose this and this" for every container would
do the trick.
> I would say either make Component B hosted inside Phoenix as well,
> or make Merlin able to handle the additional contracts with Component
A.
That is a technically correct (and difficult) and politically impossible
solution.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merlin Container
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > Using this solution, and the images I supplied, if "child2"
> > was exposed as a management interface then it can be accessed
> > by "sub2", "child1", and "end". However, none of the other
> > "sub"s would be able to see it. It forces you to be smart
> > about what you expose and where.
>
> Sounds OK. Use case: Using Merlin as root, but wanting to use a
> Phoenix-only component. Would like to put Phoenix in as a
> sub-container, but still be able to access the component I put in it:
>
> Root (Merlin)
> |
> +--- Phoenix Embedded
> | |
> | +--- Component A
> |
> +--- Component B
>
> Component B should be able to see/use the service provided by
> Component
> A, and vice versa.
:/
I would say either make Component B hosted inside Phoenix as well,
or make Merlin able to handle the additional contracts with Component A.
With this arrangement, Component B would be able to see Phoenix and
Phoenix would be able to see Component B. So indirectly, if Phoenix
did not isolate itself (because it was not designed for embedded use)
Component A could access Component B--but not vice versa.
There are two reasons for this:
1) Mutual dependencies of components on the other is generally a sign
that you need to merge the components into one. I.e. there is a
design problem with the components.
2) You need to plan your container hierarchy up front. Be deliberate
about anything you expose. Make sure you have a use case for the
container hierarchy you have.
For both of those reasons you would have a hard time convincing me that
what you outlined is a ligitimate need.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merlin Container
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Using this solution, and the images I supplied, if "child2"
> was exposed as a management interface then it can be accessed
> by "sub2", "child1", and "end". However, none of the other
> "sub"s would be able to see it. It forces you to be smart
> about what you expose and where.
Sounds OK. Use case: Using Merlin as root, but wanting to use a
Phoenix-only component. Would like to put Phoenix in as a
sub-container, but still be able to access the component I put in it:
Root (Merlin)
|
+--- Phoenix Embedded
| |
| +--- Component A
|
+--- Component B
Component B should be able to see/use the service provided by Component
A, and vice versa.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merlin Container
Posted by Berin Loritsch <bl...@apache.org>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > 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.
> >
>
> You have it pretty much spot-on what I want.
>
> Would the subcontainers inform the root container what components they
> allow to be proxied, or does the root container tell the subcontainers
> what components they should proxy? What about sub-sub-containers?
>
> Unless we get one big über-container, Nicola's view of containers-
> as-adapters require this to work.
For things like this to work, it has to be an attribute to the Service
definition that lets the container know that it is meant to be exposed
as a management interface. The Container would then either do nothing
because all children are trusted at the container's level, or proxy the
service into its namespace.
Keep in mind that you would not host an App as a child of an App in
most cases, so the reason for this to happen is really only under
special circumstances. The contract with the exposure has to do with
the service interface and the the container. It cannot and should
not propogate endlessly up the hierarchy chain.
Using this solution, and the images I supplied, if "child2" was exposed
as a management interface then it can be accessed by "sub2", "child1",
and "end". However, none of the other "sub"s would be able to see it.
It forces you to be smart about what you expose and where.
In the example hierarchy I sent in the previous mail, if "root" isolates
all its children, then you can only see what is exposed as a management
interface. On the other token, if "root" has all of its children in the
same namespace, then "sub3" can access "sub2" and "sub1", but none of
their children. Either case is good.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merlin Container
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> 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.
>
You have it pretty much spot-on what I want.
Would the subcontainers inform the root container what components they
allow to be proxied, or does the root container tell the subcontainers
what components they should proxy? What about sub-sub-containers?
Unless we get one big über-container, Nicola's view of containers-
as-adapters require this to work.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merlin Container
Posted by Berin Loritsch <bl...@apache.org>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > >>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.
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". Another benefit of
this is to allow a child container to override the provided component
from the parent container. 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.
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.
RE: Merlin Container
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >Outward flows of information include:
> >
> >* getName() (not setName())
> >
>
> This was a convinience operation only used in logging messages by a
> parent container. Its easily removed.
>
> >* Container createContainer(...)
> >
>
> Can be removed from the interface.
:) That would make me happy.
> >* getState()
> >
>
> This one is more complicated. Invoking suspend on a
> container results
> in the invocation of supend on all subsidiary containers and
> the parent
> basically waits for all subcontainers to achieve suspension before
> considering itself suspended. This was not in the interface
> before but
> the introduction of the ability to plug-in a foreign container in a
> heirachy complicated things. I've got some ideas but I need to think
> some more first.
Right. This stems from the decision to have each and every container
run in its own thread. The simple solution would be to have the
suspend() and resume() methods to block until they are completed.
It is perfectly reasonable to do that, and manage the number of threads
you want to use for the purpose of simultaneously suspending and
resuming the containers within the parent container.
>
> >* getResources()
> >
>
> This is part of the service functionalityb of a container.
> Keep in mind
> that a container acts as a factory of services derived from the
> component implemetation it is managing. The getResources() method
> isolates managed compoents from the services they provide.
> There is an
> alternative - namely the publishing of the established
> service back to
> the component manager (classloader) which may be more
> consitent however
> - I think this operation will still be needed in management
> applications
> (but that could be split out to a different interface).
In my mind service == component, so could you help me understand
your distinction between the two?
Also understand that not all containers will want to expose
any "resources" (is that supposed to be the same as management
interfaces?) so it should be moved into a separate interface.
> >>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.
> There is some enhancements that need to be applied to the
> thread model -
> basically moving thread establishment from the container to
> its parent.
Right.
> That's going to have some impact on the control mechanisms
> and should
> enable some simplification of the interfaces (and
> implementation indise
> DefaultContainer).
correct.
> >However, there are many ways to publish a component, and to mark a
> >component as publishable.
> >Keep in mind that the container does not have to respect the
> publishable
> >attribute. It is perfectly valid to be more restrictive, but it is
> >definitely not valid to be more lenient.
> >
> >
>
> Absolutely - the intention concerning the getResource() operation is
> that a container is always in control of the resources it
> exposes. I'm
> also working on a URL based container access mechanism - its working
> with remote containers at the moment and I have in mind a
> generalization
> of this that could replace the getResources() operation. It would
> basically provide similar functionality to the ECM lookup semantics -
> but service instances would be packaged under a java.net.URL.
> Different
> URL handler then take care of the interaction with a local or remote
> containers during service resolution.
It sounds interesting to say the least. I still don't have the "big
picture" of exposing the resources that you describing. Some of the
clouds have moved out of the way, but it seems we have some heavy
cloud cover on this one.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merlin Container
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>Berin Loritsch wrote:
>>
>>
>>
>>>There are some things that look suspiciously like subversion of
>>>control that I am curious about. First, the simplified interface
>>>that I would be happy with is:
>>>
>>>interface Container
>>>{
>>> void install( Profile[] profiles );
>>>}
>>>
>>>
>>>
>>Probably possible - the addContainer operations could be
>>resolved under
>>an install where the installed component is a profile of a container.
>>
>>
>
>I think that would be preferable.
>
>
>
>
>>>The reason is simple: information should flow inward, not outward.
>>>Container hierarchies should not be determined based on the kernel's
>>>viewpoint, but on the way that the developer sets it up.
>>>
>>>
>>>
>>>
>>The kernel is basically handling the information it is
>>provided with - a set of component profiles it has to
>>establish and - in the special case of a root kernel -
>>establishment of a set of kerenel level services. In
>>effect this is what the developer/assembler is asking
>>for, ... but let me
>>read on ;-)
>>
>>
>
>Ok.
>
>
>
>
>>>Granted, the current approach allows the kernel to set
>>>everything up, but let me illustrate why Fortress and
>>>Merlin have very different viewpoints on setting up the
>>>container hierarchy.
>>>
>>>* Querying the state of the child
>>> - Merlin's kernel queries the state of the child container, as
>>> opposed to knowing it.
>>>
>>>
>>>
>>The only queries applied by the kernel to the container relates to
>>container verification. There was a higher level of kerenl container
>>interaction before but this has eliminated (see current CVS version).
>> There is still container-to-container interaction related to
>>synchronzation across multiple threads suring deployment
>>processes that I'm not 100% happy with - so in that respect I agree
>>about intaction levels and the interest in reducing this.
>>
>>
>
>It should be doable. I think that one thing simplifying the Fortress
>approach is that the containers are largely passive. In other words,
>anything that happens in threads is relegated to the CommandManager,
>and when a container recieves a suspend() or related signal, it can
>directly propogate it to the children.
>
>This is distinct from having a separate thread for each container.
>
>
>
>
>>> - Fortress knows the state of the child container because the
>>> parent container set it. Information flows from the parent
>>> to the child (inward), but no information flows from the
>>> child to the parent (outward).
>>>
>>>
>>>
>>Aside from thread synchronization (i.e. a parent container considers
>>itself initializated when all of its subsidiary containers are
>>initialized), what specifically are the outward flows you
>>thinking of?
>> Based on the current implemetation the outward flows re available
>>services based on what the container can achieve relative to its
>>supplied deployment criteria. It can also provide state in
>>that it can be suspended, redeployed, etc. and in that respect it
>>may be obliged to notifiy a parent of that state change. This
>>isolation of deployment status is really useful - you can limit the
>>impact of system modifications (reconfiguration, etc.) to the
>>container level without interupting the entire hierachy.
>>
>>
>
>Outward flows of information include:
>
>* getName() (not setName())
>
This was a convinience operation only used in logging messages by a
parent container. Its easily removed.
>* Container createContainer(...)
>
Can be removed from the interface.
>* getState()
>
This one is more complicated. Invoking suspend on a container results
in the invocation of supend on all subsidiary containers and the parent
basically waits for all subcontainers to achieve suspension before
considering itself suspended. This was not in the interface before but
the introduction of the ability to plug-in a foreign container in a
heirachy complicated things. I've got some ideas but I need to think
some more first.
>* getResources()
>
This is part of the service functionalityb of a container. Keep in mind
that a container acts as a factory of services derived from the
component implemetation it is managing. The getResources() method
isolates managed compoents from the services they provide. There is an
alternative - namely the publishing of the established service back to
the component manager (classloader) which may be more consitent however
- I think this operation will still be needed in management applications
(but that could be split out to a different interface).
>
>Basically anything where the parent would query the child
>
>
>
>
>>>* True hierarchy vs. Flat hierarchy
>>> - Merlin asks a container to create an instance of a child
>>> container, presumably so that it can directly manage it--or pass
>>> in the profiles.
>>>
>>>
>>>
>>Merlin contains provide two levels of interaction:
>>
>>1. the assembly stage - this is where the container is
>>provided with its
>>profile, and the profile includes information about all of the
>>subsidiary containers and immediate components
>>
>>
>
>Ok.
>
>
>
>
>>2. the progammatic entry point - Merlin containers enable dynciamic
>>addition of container and componets to a container at run
>>time - so you programmatically build things is a dyanmic
>>environment
>>
>>
>
>It can be done via Fortress as well. Provided your container
>implementation knows how to do it.
>
>
>
>
>>> - Fortress allows the containers to create whatever child
>>> containers it needs.
>>> It provides the framework that does not bind the container writer
>>> into one way of doing things. You don't even *have* to use the
>>> provided Container interface or the provided ServiceManager/
>>> ComponentManagers.
>>>
>>>
>>>
>>>
>>A container in Merlin must implement the Meerlin Container interface.
>>With respect to SM/CM, a container can declare its own
>>implementation of
>>a deployment manger which allows different CM/SM solutions.
>>
>>
>
>Right. But you must implement the Container interface. I think that
>is part of the communication you designed into Merlin.
>
>
>
>
>>>* Architecture specific constants
>>> - Both Merlin and Fortress have architecture specific constants
>>> that are passed in (presumably by the context object). These
>>> constants are container specific.
>>> - Fortress deals with this by separating out the constants into
>>> separate interfaces instead of merging them.
>>>
>>>Both Merlin and Fortress do work, but Merlin side-steps IOC by
>>>making all containers in a system as peers--at least that is how
>>>it looks.
>>>
>>>
>>>
>>I think that's a reasonably statement.
>>
>>
>>
>>>I would like to understand the thought processes behind the
>>>decisions.
>>>
>>>
>>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
>
>
>
>>- we are into a different spectrum or viewpoint. A container is a
>>functional unity - it provides a service - namely the
>>assembly of a set of components with the objective of establishing
>>a set of services. It does this using a shared type manager (well,
>>sort of shared - each container gets it own type manger and it can
>>see up the hierarchy but not across). The question of exposure of
>>the resources it manages is what I think your getting at. In the
>>Phoenix world you can deploy a James application - but you cannot
>>access the James service from another application - this was a real
>>limitation to things I was dealing with
>>
>>
>
>The assembly and management of the instances of those components.
>Now, as to exposing services from one application to another, that
>is a container specific thing.
>
>Keep in mind that in some cases the added security of refusing inter-
>application communication is necessary. A different container might
>allow authenticated access (i.e. public key authentication or
>something).
>Still another container provides a "trusted system" in which all
>applications can request services one of another without the need
>for authentication--which is where I think Merlin is.
>
>
Correct.
There is work I'm doing on remotely accessible container (a
specialization of DefaultContainer) that will handle invocation context
and client authentication on a per requerst basis.
>When you have two applications on the same server like in J2EE and
>Phoenix environments, they are for all intents and purposes isolated
>from each other. The only exposure you have to their internals is
>done through the wire protocols that are exposed like SOAP, or the
>web application.
>
>We do need to be careful with inter-application communication. As
>you pointed out one size does not fit all.
>
>
>
>>-
>>I wanted pluggable components - and I wanted a framework where the
>>services derived from those components could be easily managed
>>across a distributed environments. This means I needed to be able
>>to deploy a set of components (implementations) and arrive at a
>>situation where I had a set of available services. Some of these
>>services may be private to a container (privacy policy not
>>implemented yet) and others may be public - ie. published by a
>>container. Of the published (public) services, some of these may
>>be remotely accessible and may be provides solutions to component
>>composition in other containers in different organizations. Given
>>this ability, you can chain together services (and the service
>>activation semantics across different organizations). Throw
>>into this some smart business, collaboration and security context
>>management and your looking at some really interesting mechanisms for
>>collaborative peer-to-peer business solutions.
>>
>>
>
>Right.
>
>However it is the responsibility of the container, or root container
>to determine how it implements those privacy policies. In the InfoMover
>application, I want to be able to publish access to a management server
>to the JobManager. I also want to publish the control of the individual
>jobs.
>
>Perhaps the interaces as they are need to change.
>
There is some enhancements that need to be applied to the thread model -
basically moving thread establishment from the container to its parent.
That's going to have some impact on the control mechanisms and should
enable some simplification of the interfaces (and implementation indise
DefaultContainer).
>However, there are many ways to publish a component, and to mark a
>component as publishable.
>Keep in mind that the container does not have to respect the publishable
>attribute. It is perfectly valid to be more restrictive, but it is
>definitely not valid to be more lenient.
>
>
Absolutely - the intention concerning the getResource() operation is
that a container is always in control of the resources it exposes. I'm
also working on a URL based container access mechanism - its working
with remote containers at the moment and I have in mind a generalization
of this that could replace the getResources() operation. It would
basically provide similar functionality to the ECM lookup semantics -
but service instances would be packaged under a java.net.URL. Different
URL handler then take care of the interaction with a local or remote
containers during service resolution.
Cheers, Steve.
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Merlin Container
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> Berin Loritsch wrote:
>
> >There are some things that look suspiciously like subversion of
> >control that I am curious about. First, the simplified interface
> >that I would be happy with is:
> >
> >interface Container
> >{
> > void install( Profile[] profiles );
> >}
> >
>
> Probably possible - the addContainer operations could be
> resolved under
> an install where the installed component is a profile of a container.
I think that would be preferable.
> >The reason is simple: information should flow inward, not outward.
> >Container hierarchies should not be determined based on the kernel's
> >viewpoint, but on the way that the developer sets it up.
> >
> >
>
> The kernel is basically handling the information it is
> provided with - a
> set of component profiles it has to establish and - in the
> special case
> of a root kernel - establishment of a set of kerenel level
> services. In
> effect this is what the developer/assembler is asking for,
> ... bu let me
> read on ;-)
Ok.
> >Granted, the current approach allows the kernel to set
> >everything up, but let me illustrate why Fortress and
> >Merlin have very different viewpoints on setting up the
> >container hierarchy.
> >
> >* Querying the state of the child
> > - Merlin's kernel queries the state of the child container, as
> > opposed to knowing it.
> >
>
> The only queries applied by the kernel to the container relates to
> container verification. There was a higher level of kerenl container
> interaction before but this has eliminated (see current CVS version).
> There is still container-to-container interaction related to
> synchronzation across multiple threads suring deployment
> processes that
> I'm not 100% happy with - so in that respect I agree about intaction
> levels and the interest in reducing this.
It should be doable. I think that one thing simplifying the Fortress
approach is that the containers are largely passive. In other words,
anything that happens in threads is relegated to the CommandManager,
and when a container recieves a suspend() or related signal, it can
directly propogate it to the children.
This is distinct from having a separate thread for each container.
> > - Fortress knows the state of the child container because the
> > parent container set it. Information flows from the parent
> > to the child (inward), but no information flows from the
> > child to the parent (outward).
> >
>
> Aside from thread synchronization (i.e. a parent container considers
> itself initializated when all of its subsidiary containers are
> initialized), what specifically are the outward flows you
> thinking of?
> Based on the current implemetation the outward flows re available
> services based on what the container can achieve relative to its
> supplied deployment criteria. It can also provide state in
> that it can
> be suspended, redeployed, etc. and in that respect it may be
> obliged to
> notifiy a parent of that state change. This isolation of deployment
> status is really useful - you can limit the impact of system
> modifications (reconfiguration, etc.) to the container level without
> interupting the entire hierachy.
Outward flows of information include:
* getName() (not setName())
* Container createContainer(...)
* getState()
* getResources()
Basically anything where the parent would query the child
> >* True hierarchy vs. Flat hierarchy
> > - Merlin asks a container to create an instance of a child
> > container, presumably so that it can directly manage it--or pass
> > in the profiles.
> >
>
> Merlin contains provide two levels of interaction:
>
> 1. the assembly stage - this is where the container is
> provided with its
> profile, and the profile sincludes information about all of the
> subsidiary containers and immediate components
Ok.
> 2. the progammatic entry point - Merlin containers enable dynciamic
> addition of container and componets to a container at run
> time - so you
> programmatically build things is a dyanmic environment
It can be done via Fortress as well. Provided your container
implementation
knows how to do it.
> > - Fortress allows the containers to create whatever child
> > containers it needs.
> > It provides the framework that does not bind the container writer
> > into one way of doing things. You don't even *have* to use the
> > provided Container interface or the provided ServiceManager/
> > ComponentManagers.
> >
> >
>
> A container in Merlin must implement the Meerlin Container interface.
> With respect to SM/CM, a container can declare its own
> implementation of
> a deployment manger which allows different CM/SM solutions.
Right. But you must implement the Container interface. I think that
is part of the communication you designed into Merlin.
> >* Architecture specific constants
> > - Both Merlin and Fortress have architecture specific constants
> > that are passed in (presumably by the context object). These
> > constants are container specific.
> > - Fortress deals with this by separating out the constants into
> > separate interfaces instead of merging them.
> >
> >Both Merlin and Fortress do work, but Merlin side-steps IOC
> by making
> >all containers in a system as peers--at least that is how it looks.
> >
>
> I think that's a reasonably statement.
>
> >I would like to understand the thought processes behind the
> decisions.
> >
> >
>
> 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.
> - we are into a different spectrum or viewpoint. A container is a
> functional unity - it provides a service - namely the
> assembly of a set
> of components with the objective of establishing a set of
> services. It
> does this using a shared type manager (well, sort of shared - each
> container gets it own type manger and it can see up the hierarchy but
> not across). The question of exposure of the resources it manages is
> what I think your getting at. In the Phoenix world you can deploy a
> James application - but you cannot access the James service
> from another
> application - this was a real limitation to things I was
> dealing with
The assembly and management of the instances of those components.
Now, as to exposing services from one application to another, that
is a container specific thing.
Keep in mind that in some cases the added security of refusing inter-
application communication is necessary. A different container might
allow authenticated access (i.e. public key authentication or
something).
Still another container provides a "trusted system" in which all
applications can request services one of another without the need
for authentication--which is where I think Merlin is.
When you have two applications on the same server like in J2EE and
Phoenix environments, they are for all intents and purposes isolated
from each other. The only exposure you have to their internals is
done through the wire protocols that are exposed like SOAP, or the
web application.
We do need to be careful with inter-application communication. As
you pointed out one size does not fit all.
> -
> I wanted pluggable components - and I wanted a framework where the
> services derived from those components could be easily
> managed across a
> distributed environments. This means I needed to be able to deploy a
> set of components (implementations) and arrive at a situation where I
> had a set of available services. Some of these services may
> me private
> to a container (privacy policy not implemented yet) and others may be
> public - ie. published by a container. Of the published (public)
> services, some of these may be remotely accessible and may be
> provides
> solutions to component composition in other containers in different
> organizations. Given this ability, you can chain together
> services (and
> the service activation semantics across different
> organizations). Throw
> into this some smart business, collaboration and security context
> management and your looking at some really interesting mechanisms for
> collaborative peer-to-peer business solutions.
Right.
However it is the responsibility of the container, or root container
to determine how it implements those privacy policies. In the InfoMover
application, I want to be able to publish access to a management server
to the JobManager. I also want to publish the control of the individual
jobs.
Perhaps the interaces as they are need to change. However, there are
many ways to publish a component, and to mark a component as
publishable.
Keep in mind that the container does not have to respect the publishable
attribute. It is perfectly valid to be more restrictive, but it is
definitely not valid to be more lenient.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Merlin Container
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
>I began trying to use Meta and Container in Fortress, and started to
>look at Merlin 2 on how to best do this. The Container interface
>exposes methods to the implementing container so that the kernel can
>do its magic.
>
>There are some things that look suspiciously like subversion of
>control that I am curious about. First, the simplified interface
>that I would be happy with is:
>
>interface Container
>{
> void install( Profile[] profiles );
>}
>
Probably possible - the addContainer operations could be resolved under
an install where the installed component is a profile of a container.
>The reason is simple: information should flow inward, not outward.
>Container hierarchies should not be determined based on the kernel's
>viewpoint, but on the way that the developer sets it up.
>
>
The kernel is basically handling the information it is provided with - a
set of component profiles it has to establish and - in the special case
of a root kernel - establishment of a set of kerenel level services. In
effect this is what the developer/assembler is asking for, ... bu let me
read on ;-)
>Granted, the current approach allows the kernel to set
>everything up, but let me illustrate why Fortress and
>Merlin have very different viewpoints on setting up the
>container hierarchy.
>
>* Querying the state of the child
> - Merlin's kernel queries the state of the child container, as
> opposed to knowing it.
>
The only queries applied by the kernel to the container relates to
container verification. There was a higher level of kerenl container
interaction before but this has eliminated (see current CVS version).
There is still container-to-container interaction related to
synchronzation across multiple threads suring deployment processes that
I'm not 100% happy with - so in that respect I agree about intaction
levels and the interest in reducing this.
> - Fortress knows the state of the child container because the
> parent container set it. Information flows from the parent
> to the child (inward), but no information flows from the
> child to the parent (outward).
>
Aside from thread synchronization (i.e. a parent container considers
itself initializated when all of its subsidiary containers are
initialized), what specifically are the outward flows you thinking of?
Based on the current implemetation the outward flows re available
services based on what the container can achieve relative to its
supplied deployment criteria. It can also provide state in that it can
be suspended, redeployed, etc. and in that respect it may be obliged to
notifiy a parent of that state change. This isolation of deployment
status is really useful - you can limit the impact of system
modifications (reconfiguration, etc.) to the container level without
interupting the entire hierachy.
>
>* True hierarchy vs. Flat hierarchy
> - Merlin asks a container to create an instance of a child
> container, presumably so that it can directly manage it--or pass
> in the profiles.
>
Merlin contains provide two levels of interaction:
1. the assembly stage - this is where the container is provided with its
profile, and the profile sincludes information about all of the
subsidiary containers and immediate components
2. the progammatic entry point - Merlin containers enable dynciamic
addition of container and componets to a container at run time - so you
programmatically build things is a dyanmic environment
> - Fortress allows the containers to create whatever child
> containers it needs.
> It provides the framework that does not bind the container writer
> into one way of doing things. You don't even *have* to use the
> provided Container interface or the provided ServiceManager/
> ComponentManagers.
>
>
A container in Merlin must implement the Meerlin Container interface.
With respect to SM/CM, a container can declare its own implementation of
a deployment manger which allows different CM/SM solutions.
>* Architecture specific constants
> - Both Merlin and Fortress have architecture specific constants
> that are passed in (presumably by the context object). These
> constants are container specific.
> - Fortress deals with this by separating out the constants into
> separate interfaces instead of merging them.
>
>Both Merlin and Fortress do work, but Merlin side-steps IOC by making
>all containers in a system as peers--at least that is how it looks.
>
I think that's a reasonably statement.
>I would like to understand the thought processes behind the decisions.
>
>
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
- we are into a different spectrum or viewpoint. A container is a
functional unity - it provides a service - namely the assembly of a set
of components with the objective of establishing a set of services. It
does this using a shared type manager (well, sort of shared - each
container gets it own type manger and it can see up the hierarchy but
not across). The question of exposure of the resources it manages is
what I think your getting at. In the Phoenix world you can deploy a
James application - but you cannot access the James service from another
application - this was a real limitation to things I was dealing with -
I wanted pluggable components - and I wanted a framework where the
services derived from those components could be easily managed across a
distributed environments. This means I needed to be able to deploy a
set of components (implementations) and arrive at a situation where I
had a set of available services. Some of these services may me private
to a container (privacy policy not implemented yet) and others may be
public - ie. published by a container. Of the published (public)
services, some of these may be remotely accessible and may be provides
solutions to component composition in other containers in different
organizations. Given this ability, you can chain together services (and
the service activation semantics across different organizations). Throw
into this some smart business, collaboration and security context
management and your looking at some really interesting mechanisms for
collaborative peer-to-peer business solutions.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>