avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Mouat <rob...@mouat.net>
Subject Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Date Tue, 25 Jun 2002 21:59:11 GMT
Stephen McConnell wrote:


> ><rant subject="Assembler as God">
> >
> >[by assembler I'm referring to the person who puts the final application
> >together - including things like writing the code for a programatically
> >assembled container (like fortress), and writing a cocoon sitemap].
> >
> >The framework describes a contract between a component and a container -
> >this is good for both component writers and container writers... but
> >components and containers are both subject to the whims of the assembler.
> >
> Yep.
> >
> >The assembler gets the last say.  The assembler puts everything together
> >to form the final application - choosing components and the container to
> >suit their needs. [though perhaps not always with a choice of container]
> >
> >If a component/container isn't flexible enough then the assembler can
> >choose another (or potentially write one).
> >
> That's the idea I have in mind - different containers doing different 
> things but a particular cointainer does its particular thing right. 
>  Eliminate the issue of onoe container for all - instead - leverage the 
> right tool for the job.
> >I think that this should be recognised in how a component is looked up -
> >i.e. when a client asks for a particular role, the assembler should be
> >able to specify exactly what component it gets.
> Where an assembler is assemberling the content of an application and the 
> ingridients are classes and profiles - then yes. I agree.  When the 
> ingridients are services from somewhere else - then the assembler has to 
> live with the service requested based on the quality of the container in 
> support of a particular idea of service defintion and fitne4ss-for-purpose.

I disagree that the assembler *has* to live with anything -- and think
they should be able to override any fitness-for-purpose decisions... see

> >In that respect components only get to demand what they need in terms of
> >interfaces -- anything else they have to humbly request from the
> >assembler, and not complain when denied.
> >  
> >
> Yep.
> >
> >e.g.
> >
> >If a component asks for a tcp connection, then suggests that it should be
> >SSL - I, as assembler should be able to say "denied: your connection will
> >be tunnelled via ssh instead" -- of course if the component had requested
> >a 'secure' connection, the request would have been approved (or not if it
> >is in a development/testing environment).
> Not ready to agree on that just yet.  Personally I hate the notion of 
> "suggestions"and "hints" - these notions don't exist in the framework 
> and it has not been formalized anywere else - and until that happens ... 
> don't expect way cool solutions.

hmmm, 'suggests' was a bad choice of words, I wasn't necessarily thinking
about 'hints', but rather metadata constraints.

> >Now suppose that the component and the container are conspiring against
> >me, the assembler - and the component tells the container (via metadata)
> >that it insists that the connection be SSL, and the container decides to
> >enforce that... well I could write a small wrapper component that lied to
> >the container saying that it provided an SSL connection, but instead
> >simply used another component that provided an unencrypted tcp connection
> >that happened to go through a VPN tunnel.
> >
> >I am the assembler, I always win :)
> >  
> >
> I'm not really following the above too well.
> The guy doing the assembnly is simply working with the 
> constraints/limitations of the language used by a particular container. 
>  You wind to the extent that you (a) choose the appropriate container as 
> a deployment vehicle, and (b) leverage the container to the best of its 
> ability.

let me reword it a little:  if the client specifies (via metadata) that
the connection it is requesting *must* be SSL, and the container is going
to enforce the constraint - then the assembler can circumvent it by
creating another component that tells the container it provides an SSL
connection (and instead passes all method calls onto a tunnelling

What is the point in a container telling an assembler that they *can't*
give a particular component to a client? The assembler can easily
circumvent this -- the only constraint that cannot be bypassed is the
interfaces the client requires of the component (since these will cause
runtime errors when the client does a cast).

[a warning might be appropiate, as long as the assembler can supress it]

> >
> >Anyway, the point is that the framework should recognise the role that the
> >assembler plays and not try to limit the assemblers ability to chose what
> >components client get for particular roles -- the assembler is the only
> >one who can see the 'big picture'.
> A container brings God down to earth because the container knows about 
> reality.
> God's just speculating :-)

If the assembler knows enough about the components they are using, they
don't need a reality check -- if they don't know enough (poor
documentation, or failing to read the documentation) then a recalcitrant
container isn't going to prevent problems :)


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