avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: [A5] CM Use Cases from real requirements
Date Tue, 18 Jun 2002 00:03:44 GMT


Berin Loritsch wrote:

>What we need to address is the use cases from several current use cases.
>We *have* to address what the best way to solve each use case:
>
>1) Simple CM lookup and use:
>   This is probably the majority of cases (70%?).  A component looks up
>   another component by interface.  
>

I belive this use case is an abuse of the CM.  The CM is a utility
supporting interaction between the container and the component.  In
this context the inteface information is redundant if the container
provides support for metadata.  If not, the passing of string that is
not opaque is a workaround to support either a container or component
deficiency.  This simple case can be easily support by seperating the
usage of a lookup interface for commonent aquistion as opposed to
component lifecycle servicing.

>   It doesn't care about implementation
>   issues, but it must exist for the component implementation to work.
>   The current (A4) CM interface accomplishes this without problem.
>
>2) Optional CM lookup and use:
>   This is less common, but definitely appropriate.  A component tests
>   for the existence of an optional component--which it will use if it
>   exists.  If the component does not exist, it is not exceptional.
>This
>   is in contrast with use case 1 where the missing component *is*
>   exceptional.  The current (A4) CM interface accomplishes this without
>   problem because of the containsCOmpoennt() method.
>

This is another example of the usage of the CM outside of te scope of 
component lifecycle management.  The real issue here is "should this be 
part of a CM supported behavior".  If it should, then ...

  a) a component dependency declaration must declare what is
     effectively a wildcard constraint
  b) and this constraint could be rejected if it conflict with
     container policy concerning diclosure of components

>
>
>3) Non Avalon component lookup and use:
>   It is easiest to lookup components when you only have one way to
>   access them.  It reduces the complexity of maintaining your system.
>   If the component being used is a CORBA component, or an EJB bean,
>   the component should still be able to be resolved.  The (A4) SM
>   interface accomplishes this without problem because it returns
>   Object instead of Component.
>
>4) Multiple resolutions of an implementation for the same role:
>   The Container is responsible for this logic.  Currently, Phoenix
>   uses meta-information and a mapping file to manage the Component/
>   role mapping.  
>

Merlin also uses meta-information.

>   However this can be difficult to understand.  
>

Disagree on that.  The meta declaration in a .xinfo file is drop dead 
simple.  Its also auto generatable using javadoc tags.  Currently Merlin 
support the complete .xinfo used in Phoenix.  Merlin also includes 
additional information concerning implementation policy and release 
configuration.  This subject (or the convergence of that) are under 
discussion.  Done correctly, this means the ability to fully package a 
deploy at the component level - and transparent from component to 
application via Phoenix.

>   The
>   maintainer of a project that someone inherits has a lot of homework
>   before they can understand how to map roles and components when
>   there are multiple instances and the returned value changes based
>   on the context of the calling component.  
>

The above does not compute.
What context are you referring to?

>   We need a better way to
>   explain this--because while it is powerful, it is too confusing
>   for newbies.
>

When I first came across Avalon (the project) I spent a lot of time 
trying to figure out what was available.  I did a lot of digging into 
ECM but found it to me way more complex than Phoenix (and that included 
all of the pain related to Phoenix assembly stuff).  The core bots we 
are talking about for mewta declaration are tiny - simple - very simple 
- and easy to incorporate into a container. What is really confusing for 
newbies is runable HelloWorld components (or more specifically the 
absence of them).  I've just finished put in place some demod on the 
Merlin CVS that show simple and composite services - for the developer 
is a drop-dead-simple exercise providing they have container solid support.

>
>
>5) Multiple resolutions during runtime for the same request:
>   Nothing really handles this well.  It is hacked together by the
>   component selector/service selector in A4.  
>

Which is basically a workaround pending finalization of a metamodel. I 
have tools I'm using that give me the suite of options available for 
given component dependency.  From this - you will be able to plug in a 
selection policy handler that resolves options down to a single service 
to supply to the component. This seperates the issue of custom policies 
for an overall meta-management framework.

>   The problem is best
>   illustrated by a transformer.  A document or transaction can be
>   processed by several different transformers at runtime before
>   the request is committed.  Two examples include the Cocoon use
>   case, and my data transformation server.  The data transformation
>   server passes a transaction object which multiple transformers
>   may be applied to it before it is serialized to the persistence
>   layer.  Cocoon does the same with SAX events.  This is what the
>   proposed lookup(role,hint) hopes to solve.
>

I think this is a seperate concern - it can be handled by a registry 
interface that can expose lookup( role, hint, whatever) semantics but is 
independent of a CM lookup.

>
>We need to account for every one of these use cases in a straight-
>forward way.  The design constraints we should work within should
>be:
>
>* Do not force the client to do too much work.  The client needs
>  to be easy to implement.  Otherwise A5 is not of any use.
>* We should make it conceptually easy--not conceptually hard.
>  Avalon already suffers from the learning curve necessary between
>  Component-Oriented Programming and Object Oriented Programming.
>* We need to make the containers easy to understand or they will
>  be forced into obscurity because noone wants to have to debug
>  a container just to get their component to work.
>
>I think this will provide the proper conceptual framework to design
>the nextgen ComponentLocator.
>

I think we need to take a good long look at usage versus abusage.  The 
CM/SM interfaces define a utility through which a container can supply 
dependent services to a component during the lifecycle processing phase. 
 As soon as you apply supplimentary scope on CM/SM, the probelm expands 
dramtically and we see the current level of consufion about how the 
interface is used.  

Bottom line - this is easily correctable without modifying the CM/SM 
lookup signature.

Cheers, Steve.

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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