avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: Fresh Perspective
Date Wed, 19 Jun 2002 16:51:55 GMT
> From: Leo Simons [mailto:leosimons@apache.org] 
> 
> an example program flow could be:
> 
> ----------------   -------------   -----------------     -------------
> | ClientObject |   |   Locator |   | DependencyMap |     | Container |
> ----------------   -------------   -----------------     -------------


Snipping everything else.  Architecturally speaking, all component
architectures have Four major entities:

1) Client -- the user of the components
2) Component -- the reusable logic used in COP
3) Lookup Mechanism -- our ComponentLocator, can also be JNDI for some
                       containers.
4) Container -- the entity responsible for mapping names to components,
                loading components, and managing all aspects of the
                component.

So, while I appreciate what you are drawing here, I think it is
important to reflect the fact that the DependencyMap or whatever
other *implementation* is enclosed *inside* the Container.  The
ComponentRegistry from another thread and the DependencyMap in
this thread would be ways of implementing a container--but
architecturally speaking they are *part* of the container.

I want to make sure we are on the same page with this vision.
If we complicate the picture too much, then the rallying cry
would be "Why use Avalon?"  We should leverage the understanding
of generic component oriented programming, and focus our discussions
on those four entities.

What I am interested in doing is narrowing down the who and what more
than the how.  The _contracts_ between the four entities are what is
most important.

Now, let's look at some non-Avalon component architectures to leverage
the generalities.

EJB
---
EJBs use a descriptor to map components to JNDI.  This descriptor
represents all the components, as opposed to one descriptor per
component.  The amount of info in the descriptor is amazing.  You
have everything from security access (what role can access what
method on which component) to configuration information.

Everything is bound to JNDI in some manner.  The components are
generated (i.e. EJB 2.0).  Configuration information is fairly
minimal.

Servlets
--------
Servlets are similar to EJBs, but the security information is
handled differently.  With servlets, there is one descriptor
per webapp as opposed to one per component.



In J2EE environments, there are four roles in the app server.
1) Developer -- creates the components, and writes the portion
                of the descriptor that maps what the component
                looks up to what it expects.
2) Integrator (can't remember the term in the docs) -- matches
                component implementations to business need
                (i.e. descriptor manager)
3) Administrator -- The guy who manages permissions and the server.
4) Container Provider -- the guy who writes the containers.

As you can imagine, IBM and BEA have very different implementations
under the hood.  The important thing is that the contracts of the
specifications are essentially the same.

We do need meta information, which I will not negate in any way.
Currently the meta info we need (that I can see) are:

1) Dependencies
   - required: component will fail if the required components do
               not exist.
   - requested: component will *not* fail if the requested
                components do not exist, but would prefer to have
                them.
   - Lookup names: the names that the component will use to ask
                   for the component in question.
   - Constraint: Does it support a certain contract?  How do we
                 represent that information?

2) Lifestyle
   - Threadsafe or PerThread.  We are still weeding through the
     pooled concepts so I don't want to confuse things here.

3) Security
   - It would be nice to provide the level of security as EJBs,
     however it is not critical to the definition of Avalon
     components at this time.  It will be if we intend to write
     business oriented components.

4) Lifecycle
   - Does this component require an extended lifecycle (i.e.
     Marcus Crafter's proposal).  If so, what are the handlers
     for the extended lifecycle?

Are there any more?

Now, because this thread is focusing on the component lookup and
resolution, I will focus my attention to the Dependancies related
metadata.

Let's say I have an InformationSource component that pulls
information from an arbitrary resource.  The component
implementation that will pull information from a database will
need the DataSourceComponent.  So as I define the metadata for
my DatabaseInformationSource component, I supply the following
information:

/**
 * This is the class javadoc
 *
 * @requires datasource =
 *     org.apache.avalon.excalibur.datasource.DataSourceComponent
 */
public class DatabaseInformationSource
    implements InformationSource, Composable
{
    DataSourceComponent m_datasource;

    //.... skip everything else

    public void compose(ComponentLocator locator)
    {
        m_datasource = (DataSourceComponent)
            locator.lookup("datasource");
    }
}

This sounds pretty straight forward.  It is fairly elegant, and
it removes the need for long string names.

Now, when it comes time to lookup a component with a certain
constraint, it is theorhetically easy to map whatever constraint
to a name in the database.  However, let's use an example of a
hard constraint and a soft constraint.  One example of a hard
constraint is the SSL connection manager vs. non SSL connection
manager.

I can imagine a way of declaring constraints in the meta info,
but I have a hard time envisioning how it is applied programatically.
How does a container know that the SSL constraint applies to one
of several classes of components?

Imagine if you will that the TLSConnectionManager in cornerstone
is not the only SSL enabled connection manager.  Let's say the
UberCompany has their own implementation of the same interface.
With the meta information we can specify that the required
constraint is "SSL", but how does the container know that
UberCompany's connection manager satisfies the constraint when
it says it satisfies the "TLS" constraint (by extension SSL)?
The only thing I can think of is that the constraint meta info
is merely a hint to the assembler, so that they can choose the
proper component to map--much like the J2EE integrator.  The
container has no real alternative but to implicitly trust the
assembler.

An example of a soft constraint is one that is both defined and
resolved at runtime.  The Sitemap is one way of describing that
dynamic binding.  In short this is an application specific
exercise.  The soft binding is described by a common descriptor,
perhaps a "job" descriptor or some other application specific
thing (like sitemap).

Therefore, in order to provide soft bindings, the application
has to define their own container--or extend one (which is what
Fortress is supposed to solve).  We have to be careful that the
minimalist container is not too dificult to design, but we do
need to provide real functionality.

Now in any of these cases, we haven't addressed the concept of
external clients.  That would include remote clients, clients
that call components from a main() method, or clients that are
servlets or EJBs using an Avalon component.  I think it is
reasonable to provide a default mapping of the interface name
for these external clients because there is no sane way of
guaranteeing reusability if there is no descriptor for them.


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