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 decides 
the 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).

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).

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.

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).


-- 
   +------//-------------------+
  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 
+------//-------------------+


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to