avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject Leo's Reservations ( taken from vote recap )
Date Thu, 13 Jun 2002 16:09:38 GMT
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com] 
> 
> A4 was about components, period. They could be pooled, 
> singlethreaded, etc., and they existed inside a container. A5 
> components are all threadsafe (remember, "the thing you get 
> out of the ComponentManager is threadsafe"). They can be 
> pooled, but if you do that then you are getting a "processing 
> artifact" or whatever...

We still haven't come to a full agreement on the interface methods.
The interface for the CM soon to be ComponentLocator or something
along those lines won't have a release() method.  That does not
preclude us from using multiple instances of a component to process
requests.

Keep in mind that we can still have one instance per thread, etc.
I think you are getting ahead of yourself.  All the vote was
concerned with is what is this thing going to be _named_.  The
next phase is deciding on how to use it.

Also, check the post I did on clarifying what it means to be
threadsafe.


> The above does not make any sense whatsoever. Please 
> rearrange and replace words until it does - but here's the point:
> 
> It seems like in A5 we have this, for what in A4 was pooled 
> components:
> 
> Use a [Component/Service][Locator/Directory] to get a 
> ??????????. Do this in compose().
> 
> Use the ?????????? to get the Component (as you knew it).
> 
> The ????????? was called XXXXXManager or "factory" in our previous 
> discussion.

Ok.  Now you have lost me.


> So really, we're not about COP anymore - it is more of a 
> Service-oriented programming style we're going for. You use 
> the ServiceLocator to get a Component factory service, but 
> the Component is only seen as a by-product of it all.

Service oriented programming == component oriented programming
It's a new name for an old concept.

However, the key focus of services is what I prefer -> they *do*
something instead of *represent* something.

Either way, the XXXXLocator does the same thing, it locates the
component we want to use.

SOP uses the same principles as COP, as it is just an extension
of the same paradigm.


> Furthermore, since pooling etc. was handler by the manager in A4 and 
> explicitly by the component in A5, A5 is more about services. 
> We really only focus on service-oriented stuff, and not much 
> on those little black boxes we called components.

No, the pooling, etc. was never supposed to be done by the manager.
It was supposed to be doing it in the container.  This is one of the
reasons why we need to change the name of the manager.

ECM is a hack because it merges container and manager--i.e. it
lacks proper SOC.  Please don't let it taint our discussion
about the relationships.  Let's take it one step at a time.


> ------------------------------------------------------------
> 
> Can we standardize on the ??????????? interface for 
> pooled/singlethreaded components? Then I can say:
> 
> Use the ComponentLocator to get the ComponentManager.

No need.  The ComponentLocator is the ComponentManager with a
new name.

> Use the ComponentManager to get the Component.

Uh, use the ComponentLocator to get the Component.

> Once you are done, put the Component back into the ComponentManager.

This is the step we are trying to avoid.  It is the incorrect
and damaging opinion that a component should be released to the
lookup mechanism.

Read this next equation carefully, and then reread it:

Lookup Mechanism != Container

Separate those concepts in your mind.  No other component
architecture exposes a release() method to the client.
It is about being smart and hiding the fact that something
might happen to be pooled.


> interface ComponentLocator {
>   public Object lookup ();
> }


You are way ahead of yourself.  Let's figure out what it
is called, then how the interface looks.


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


Mime
View raw message