Berin Loritsch wrote:
>>From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>>
>>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: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
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]>
