[RT] IoC Type Who Cares?

[Berin Loritsch <bl...@apache.org>]

It seems that the more we talk about the different IoC types, it *can* be an
emotional subject.  I chose the subject of this message to capture attention.
The arguments are always "its easier for the developer to do XYZ", with the
counter argument that "no it is still easier to do "PDQ".

In the end it boils down to the way developers like to work.  Facilitating the
way different developers think can be as wide varied as all the developers out
there.  Some folks will like one style of doing things, and other folks like
a different way.

The question I have is can we make a container that doesn't care what the
lifecycle of a component is or not.  Can we make a container that can combine
Type 1, Type 2, and Type Z components all working together?

It really isn't that hard.  We are most of the way there already.

We currently have a set of requirements for components:

* Component Construction
* Component Destruction
* Component Access
* Component Deployment

So using a ComponentFactory style approach, we can use any number of factories
to get the component up and running.  That is already there in Fortress, and
to some degree in Merlin (I need to check but it may be integrated with the
Appliance features).

The same ComponentFactory can be used to handle destroying the component.  Not
a problem.

Each IoC "type" that folks have invented has a different way of addressing how
to obtain components.  What works best is different for every system, but for
now, let us say that we may have some contracts with component access and
release.

Lastly, we also have contracts to support with component deployment.  We have
been calling the deployment logic Lifestyle, and it seems in some cases that
the deployment can be tied to the access mechanism.

We can accommodate all of these with a fairly simple modular system:

interface ComponentFactory
{
     Object createComponent();
     void destroyComponent( Object component );
     // possibly some other methods for accessing meta-info
}

The Lifecycle Extensions setup is most of the way there for handling
modifications to the component at runtime.  Essentially a "poor man's
interceptor".  For now, let's assume the Creator is taken care of with
the ComponentFactory completely, and we can make the Accessor obsolete
as well with a DeploymentManager:

interface DeploymentManager
{
     Object access();
     void release(Object component);
}

Behind the scenes, the call to "access()" will call the "createComponent()" from
the ComponentFactory as necessary.

What we could do to the interface right away would be to allow for
"parameterized" access.  For instance a container that scopes the deployment
of component instances to a Request object.  Anyhow, with these two very
simple interfaces the simple mechanics of working with any component designed
for any environment can be used within the same system.

What they don't address is how to obtain the configuration, meta-info, or
context entries for the system.  We would need different contracts for that,
and I would almost lean toward a "registry" type of approach to manage it.

That way, if someone prefers the PicoContainer approach, hey we have it covered.
If someone prefers the NanoContainer or HiveMind approach, well no sweat.
If we prefer the Avalon 4 semantics, most excellent (I have been told that I
look like Ted in Bill & Ted's Excelent Adventure).

The bottom line is that I think the more boundaries we can obliterate the
better.  There is an advantage to becoming less dogmatic, and more inclusive.
Then all we need to do is manage how we obtain the meta info to determine what
ComponentFactory and DeploymentManager we need.  We can mix and match and have
fun doing it.  I think that the work that Leo (Sutic or Simmons I can't
remember) did with the generic Attribute enabeld classes would be the best
to support that.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

Re: [RT] IoC Type Who Cares?

[Leo Simons <le...@apache.org>]

Berin Loritsch wrote:
> The question I have is can we make a container that doesn't care what the
> lifecycle of a component is or not.  Can we make a container that can 
> combine Type 1, Type 2, and Type Z components all working together?

should be possible! :D

<snip implementation details/>

> We can mix and match and have fun doing it.

Yes, its possible.
Yes, its feasible.
Yes, its a good idea.
Yes, there's valid use cases.

with fortress, I can even see a vague picture of how to get there. With 
merlin, I can't. I've discussed such implementation a bit with Steve, 
and at that point we decided it might be a good idea to focus on 
finishing up some other things first.

Steve, Jira is taking a bit longer than expected...perhaps you should 
draw up the roadmap you have in your head for us now :D

- LSD



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org