avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [merlin] new appliance code opinion/ideas dump
Date Fri, 22 Nov 2002 22:57:53 GMT

Gary Shea wrote:

>Hi Steve --
>I'm looking at the excalibur.assembly code now.  This is probably just
>going to be a sort of "opinion dump".  I will try to preface each opinion
>with my interpretation of what's going on, so you can tell what's
>based on fact and what's just lost in space ;)  Since I'm spewing, I'd
>suggest read everything first before responding.
>Since I tend to look at the stuff I don't like and ignore the rest, let
>me preface all this by saying that this is great stuff and I appreciate
>your ongoing efforts to make it architecturally cleaner.  Bravo!
>Here we go...
>    This seems to be the infrastructure for maintaining a collection of
>    Type objects.  I'm guessing that each container will have a single
>    TypeManager object where the Type information is maintained for
>    components handled in that container (but in no parent container).

At this stage the relationship between a container and a TypeManager is 
undefined.  If you follow the structure of the Merlin system - then yes, 
one container, one type manager etc.  However, I envisage the potential 
for a container to manage multiple type managers - maybe one for 
internal services, another for contained compoents, and maybe another 
for published components.  Whatever - the pricipal is that its a manager 
of a set of types (class + metainfo).

>    As I read the code I see a lot of inheritance from Service goodies,
>    some of which show evidence of originally being the  Type stuff,
>    then hacked.  

Yep - cleaning up of docs from cut-and-paste is still pending.


>    Is this inheritance for re-use or inheritance
>    that really 'means something', i.e., IS-A?  I've heard a number of
>    Java folks say something to the effect that one should "never use
>    inheritance unless you will 1) instantiate the inherited object, and
>    2) in some cases use the inheriting object in place of the inherited
>    object".  Inheritance for re-use creates (IMHO) tight webs of
>    dependency and makes code hard to understand.

Have been thinking about the same thing.  Bottom line there is no 
dramtic or fundimental reason to have this as inheritance based.  In 
fact I've been reworking TypeManager locally to turn it into a 
component.  This follows the thinking in my post about bootstrap versus 
pluggable components that provide core services.  If the pluggable 
things are always full components, then there is no reason why one 
should not allow an alternative TypeManager (or XxxxManager) component.

For the moment I suggest maintaining the inheritance approach while I 
turn things into conponents and then look at this again in a few days.

>    DefaultTypeManager.createType() is static but the javadoc refers to
>    it as 'registering' something.  Details... looks like it really just
>    creates a Type object?

Yep - javadoc is incorrect.  This is simply a convinience operation to 
create a new type without having to know about how the type is 
constructed.  The static methods do not register anything.  

>    Is it just me or is it weird that Type, which describes Services (as
>    well as coomponents in general, yes?) also classloads the Class
>    objects for the services?  I would somehow expect that to be part of
>    the _interpretation_ of the Type data, and hence at a different
>    level.

Umm - would it be ok if I answered "it's just you"?


There is a distinct difference between Type and Service.  Imagine for 
example a jar file container the service org.omg.CosTime.TimeService. 
 The TimeService interface is described by a class and a Service is the 
meta info about the service.  This service can exist indepedently of an 
componet implemetation class (i.e. the service interface and meta 
defintion can exist in a seperate jar from a component the provides the 
service).  On the other hand, types can declare that they provide 
services - which basically means that a type manager when registering 
types in its repository needs to be able to access/register services 
from a service manager.

>    This is a somewhat similar critter to Type.  Each component has the
>    ability to declare the service(s?) it provides.  Again we're dealing
>    with a catalog of metadata about the component.

A catalog of services (indepedently of the ability of a system to 
provide solutions or implemetations)

>    This appears to be a subset of Type data?  

No.  Related but not subset.  A Type declares services that it provides 
via 0..n ServiceDescriptors.  A ServiceDescriptor referrences a Service. 
When you get into characterising a service verus characterising "the 
provision of a service", you end up seperating attributes between a 
service defintion and the declarion of service provisioning.

>    Is there some reason for
>    this, for instance is this where Service selection takes place if
>    multiple components provide the same service?

Two main reasons:

1. physical seperation of service defintion from type
2. ability to have multiple service versions that coexist across 
different classloaders

>    If you are wanting Type to present a ServiceManager view, so Type is
>    a kind of facade combining itself with ServiceManager (which is just
>    another view of Type! eek!) wouldn't it be more flexible to delegate
>    to a ServiceManager rather than inherit from it?  Might express the
>    design better too.  The whole construct feels a bit forced, but I
>    think I can see where you're headed...

I have the same feeling ( a liitle "forced").  Inital objective was to 
sketch out interfaces and throw in a default implemetation.  These 
things need to be worked up but I really wanted to put something out 
there for discussion as opposed to comming up with something perfect.

>    DefaultServiceManager.installService(): shouldn't this be
>    addService(String)?  I don't see what it installs?

Fixed - thanks.

>So far we have some facilities for accessing metadata.  In general they
>are isolated from where the metadata is used... yay!
>    In practice the kernel.xml 'profile' aggregates and 'completes'
>    information about a bunch of Types, so as I start reading this code
>    I don't know yet if a Profile will be about one component or a
>    collection of them.  

A profile is about deployment scanario.
name + type + configuration + context + logging setup, etc.

>    What's fairly clear is that, at the individual
>    component level, we start at the 'bottom' with Type meta-information
>    and then compose in more concrete information.
>    It occurs to me that calling the file a 'profile' and calling the
>    result of composing a Type with a 'profile' file a Profile is a
>    possible point of confusion.

A Profile has a 1-1 relationship with a Type.  
A Type may be referenced my many Profiles. For example - take class X 
(the type) and using congiuration A is represented as deployment Profile 
P1.  Taking class x (the type) and using configuration B is represented 
as deployment profile P2.  The profiles simply represent potential 
solutions for establishment of a particular appliance.  Thet do not 
represent deployed solutions - its just the collection of information on 
which deployment (via an appliace) can be made.

>    Ok, with some review I see that a Profile applies to one component.
>    The terminology is definitely confusing.

More javadoc?
Something that makes it clear the a Profile is "the named collection of 
information for the potential deployment of a specific componet type".

>    The Profile seems to be the result of pulling together all meta and
>    concrete data about a component, yes?


>    So by piling the Profile stuff on top of the Type/Service stuff, we
>    are able to ask the same questions as before, but now the answers
>    are in some sense complete, all information known about deploying
>    the component has been assembled into one box, the Profile.


>That's enough for now.  Gimme some feedback and when my brain recovers
>from all this exercise I'll go dig around in .appliance.

Which is not yet complete - what's missing is accessors on the Appliace 
interface for the service the a client needs (and generally speaking the 
client is the implimentation of a framework ServiceManager or 

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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

View raw message