> 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, > ... 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
