Niclas Hedhman wrote:
On Tuesday 18 May 2004 03:26, you wrote:
<snip content="background" />
Yes, J2EE is a 'transactional system', which fits most so called business applications... 'nuff said.
Avalon, Merlin and IoC all look great as a way to componentize our system w/o limiting ourselves in functionality. I'd like to clarify what you meant by "components are not initiative takers". In our system, that's a big problem. In fact, I suspect most software systems are not solely responding to requests, but are active systems.
:o)
Ok, perhaps a bad assertion by me, too easily misunderstood...
Inversion of Control is a jargong with many meanings, and there is no exact definition around.
An underlying 'principle' is that components should need to worry about its environment. It should be served the 'parts' that it needs to operate, and should be concentrating on one thing and do that thing very well (a.k.a Separation of Concerns, SoC).
So what I meant was that IoC components should NOT know how, when, or why the surrounding container tells it to stop doing whatever it is doing.
From this one can deduce that it is always something "from above" that decidesthe start and stops.
Meaning, in an ideal world, you either would start Merlin from the command-line, in which case the 'surrounding container' of Merlin is the command-line environment, bash for instance, and it is equally stop through the same means.
If you 'embed' Merlin in your own Main class (not too difficult), the Merlin instantiator will have a reference to the Kernel, and the Kernel has a method shutdown(), which terminates MERLIN, nothing more and nothing less.
Ok, I hope I so far have explained the IoC principle for starts and stops. Now, the world is, as we all know, not ideal.
Moreover, the component handling this external request would be a trusted component.
We call components that are 'totally trusted' for Facilities. They are created and instantiated before the rest of the components, and there are some restrictions on dependencies, but basically they are very much like ordinary components, EXCEPT that they have declared a context entry of the composition model (a.k.a the Model).
A couple of small corrections:
1. no restrictions exist (facilities may exploit any classic component
characteristic - dependencies, extensions, may be acted upon by
other facilities, etc., etc.) 2. there is no priority ordering between a facility and component
(instead the intention is to provide a mechanisms for a component
to declare a soft dependency on the existence of a facility - but
that a subject for 3.4)The Model is the linked representation of all the components to build your application. It is not the components themselves, since the Model is created first, before any components are instantiated, and I think even before any of the component classes are loaded (but I could wrong about that).
Some of the component classes are loaded as part of the component model verification (but no instantiation occurs at model level).
After the hierarchy has been determined, Merlin issues the commission() method on the Top Level component, which is a built-in container. That commission() method call will be propogated throughout the Model and all the component's LifeCycle commission methods are called.
Now, if one creates a Facility, one get hold of the Model and can traverse/query it up and down, register itself to model changes, and make changes to it on the fly. Which means, if the Facility gets the Model (the whole tree) and calls decommission(), all sub-components in the Model will have the decommission LifeCycle methods called, and in effect stopped and removed. The application as such will be gone.
Here is the 'gray area', which I am not entirely certain about... After the Facility has called the decommission(), every thing will be removed, including itself and components that may be part of the shutdown cycle. When everything returns, will the Kernel terminate in its entirety? I don't know, but I think so. If not, is that a bug? Perhaps.
Generally speaking you add a facility to a logically root container (although there are exceptions to this rule). If the facility decommissions the container it is within - then yes - its a little bit like suicide on a sunny Sunday afternoon (ie. questionable). But aside from this - decommissioning a container will not trigger a shutdown - that an action reserved for the kernel.
Does it sound complicated? Yes - internally it is fairly sophisticated, but it is piece of cake for you guys to actually do it. It is a matter of, declaring the context entry as an @avalon tag, doing a get() of that context entry, and calling a method.
Now, Stephen will probably wake up and make dozens of corrections and show how little I really understand of the internals :o).
Who me? LOL
Steve.
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
