avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Krieg" <dkr...@kc.rr.com>
Subject Re: reduction ad unum
Date Mon, 25 Nov 2002 12:20:42 GMT
Following this discussion regarding Context/Serviceable/Configuration, some
thoughts occurred to me that may provide a different point of view.

It seems to me that one aspect of each these is a Naming
service?/facility?/capability?
(don't know what word best expresses it).  Each interface allows me to find
something
given a name.  Lets examine how J2EE uses JNDI.  From the perspective of an
EJB,
the JNDI InitialContext allows a component to find environmental settings
("java:comp/env"),
equivalent to Configuration,  and access to resources (("java:comp/env/jdbc,
java:comp/env/jms,
etc"), equivalent to ServiceManger.  Within EJB the equivalent to the
Context interface is
SessionContext and EntityContext, which allow "container-provided runtime
context".  These
are essentially hooks to allow the component to query the container for
container-specific
read-only things.  These things could be simple (primitive/primary data
types) or services?/
facilities? (UserTransaction)

> ...there are two side to component-oriented-development (a) the component,
and (b)
> the container - and its really import to appreciate the potential of
> isolating these two concerns - because it enables the delivery of
> portable components, by leveraging a containment solution.
>
> Specalizing a container does not mean lost of Avalon container - its
> about having a container side programming model that makes the above a
> drop-dead simple proposition.
This is a very important point, I think.  If I write an Avalon-based
component,
I must choose a container for that component to execute within.  Certain
components may be so generic that all container-implementations should be
able
host it, while other components are dependent on a specific container.  This
is not
undesireable.  Take for instance the differences between J2EE Servlet vs.
EJB.
Both are components that are hosted within a Container, yet address entirely
different needs.  We could have Avalon containers of similar scope.

I think that when defining heirarchical containers, there is a need to
also define heirarchical Context objects.  The Uber-container may only
provide simple-objects, where as the TimeStampContainer might provide
the TimeStamp, not as a service, but as an object accessible from
TimeStampContext, since the TimeStamp is so closely aligned with
aspects addressed by the TimeStampContainer.

The TimeStampContext could be implemented, as in Phoenix, by
being passed into the contextualize( ) method, or as in Merlin, by
defining Lifecycle extension.

> One more note for the dedicate that are following this thread
>
>   Context - ADVANTAGES
>
>     * your providing state, not service and that keeps component
>       implememntation simpler and more reusable bacause it does
>       not need to know about service semantics
>
>     * is more more efficient because there is no assemably, lifestyle
>       or lifecycle overhead
>
>   Context - DISAVANTAGES
>
>     * no structure for automated logging assignment
>     * no framework for cofiguration on context values
>     * no framework for paramaterization of context vlaues
>     * no framework for assembly of context values
>     * no lifestyle semantics
>     * no notion of decommissioning of context entries
>
> And the inverse:
>
>    Service - ADVANTAGES
>
>     * container handles component provider assembly automatically
>     * container handles lifestyle management for you
>     * container handles lifecycle processing for you
>     * container handles service decommissioning
>     * container can provide seperation between implemetation and
>       service automatically
>
>    Service - DISAVANTAGES
>
>     * if its data you after then more lines of code are needed
>
>     * component implememtation becomes tightly coupled
>       to the service interface reducing potential reuse
>       and potential to use alternative service solutions
>
>     * less efficient due to assembly, lifestyle and lifecycle
>       overhead
IMHO, good summary!


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