avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Sat, 12 Jan 2002 17:08:54 GMT
Hi Leo,

It is a very interesting proposal and raises less confusion
around the use of the Composable interface.

As a generic structure it makes all the sense to consider the
CM as a service.

I am still ruminating pros and cons but, at the 1st sight, I
like it.
=:o)


Thank you for your time and attention. It ended up being a
fruitful discussion and I learned a lot.

I hope this goes on.

Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Saturday, January 12, 2002 2:52 PM
> To: Avalon Developers List; paulo.gaspar@krankikom.de
> Subject: RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
> 
> 
> 
> 
> > -----Original Message-----
> > From: Paulo Gaspar [mailto:paulo.gaspar@krankikom.de]
> > Sent: den 11 januari 2002 21:49
> > To: Avalon Developers List
> > Cc: leo.sutic@inspireinfrastructure.com
> > Subject: RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
> > 
> > 
> > Hi Leo,
> > 
> > > -----Original Message-----
> > > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > > Sent: Friday, January 11, 2002 8:46 PM
> > > 
> > > ...
> > >   
> > > > > > I also mentioned having a replaceable "indexing" strategy that

> > > > > you might 
> > > > > > change for specific Domains. Go back a bit on this thread 
> > (or in the
> > > > > > [RT] Is Poolable Harmful?) and you will find it.
> > > > > 
> > > > > Yes, but if I understood you correctly (and looking below, I 
> > > > > did), you had 
> > > > > an indexing strategy that was CM-wide.
> > > > 
> > > > YES!
> > > > 
> > > > 
> > > > See this paragraph that follows?
> > > > 
> > > > > > However, I just want a CM wide "indexing" strategy, 
> which on some 
> > > > > > implementations might even delegate some cases to... 
> (tadaaaaaaa) 
> > > > > > ComponentSelectors.
> > > > > 
> > > > > By delegating this responsibility to CS, you allow components from
> > > > > different domains to exist in the same CM. If the whole CM has one
> > > > > strategy, then you can not do this.
> > > > 
> > > > Ok, I REPEAT:
> > > >   "...which on some implementations might even delegate some cases 
> > > >   to... (tadaaaaaaa) ComponentSelectors."
> > > 
> > > Which is a non-statement, since the component does not know anything
> > > about the component manager implementation.
> > 
> > Why not?
> > Why does putting a String and a Context instead of an Object transmit
> > more knowledge. 
> > 
> > It is all in what you do with it.
> > 
> > I could call lookup like this:
> >   c = cm.lookup("$#@))(sdjhfkjh");
> > 
> > Makes no sense and compiles with the 
> >    lookup(String role)
> > format.
> > 
> >  
> > > > > With two lookup methods: lookup(role) and 
> > > lookup(role,context), you can
> > > > > be certain that no matter what strategy is used, you will 
> > get back an
> > > > > interface of type role. 
> > > > 
> > > > WHY will you be so certain of that?
> > > 
> > > Because it is specified in the ComponentManager contract. If I 
> > lookup "X"
> > > I know I will get
> > > 
> > >  a) an object that is cast-able to X
> > >  or
> > >  b) a ComponentException
> > > 
> > > Tell me, Paulo, what would your contract for the ComponentManager 
> > > interface
> > > be? Assume that there is a component Aimpl that needs to 
> lookup another 
> > > component implementing interface B.
> > > 
> > > We get:
> > > 
> > > class Aimpl {
> > >   void doStuff () {
> > >     ...
> > >     B b = (B) manager.lookup ( ???? What do I put here ???? );
> > >     ...
> > >   }
> > > }
> > > 
> > > Avalon contracts state that the role name == interface name, so 
> > > now I would
> > > look up (String) "B". What is your contract? What do I send to 
> > > the lookup method to
> > > get a B component *irrespective of the CM implementation*?
> > > 
> > > This is the "predictability" I talk about.
> > 
> 
> > You can have exactly the same contract with the implementation I 
> > proposed. And you can even have others too, as I have.
> 
> Paulo,
> 
> since it was one of the major things that caused confusion, from now on
> I'll refer to a ServiceManager when I mean something that does what
> Avalon 4 ComponentManager does, and ComponentManager when talking
> about, well, the other thing.
> 
> As for the ServiceManager interface, I think each interface must come with
> its own contract. That is the strength of Avalon - since each 
> interface has 
> a contract, we can switch implementations dynamically. We can not have 
> something as fundamental as a SM interface without specifying a contract 
> for it that all implementations must obey.
> 
> However, services obtained via the SM may have their own contracts.
> And I would say that the CM is now a Service that should be obtained via 
> a SM.
> 
> So, what I would propose is to use the ECM implementation as you 
> described 
> below:
> 
> interface ServiceManager {
>   Object lookup (String role);
>   Object lookup (String role, Context ctx);
> }
> 
> interface Serviceable {
>   void serve(ServiceManager sm);
> }
> 
> interface Composable {
>   void compose(ComponentManager cm);
> }
> 
> class ExcaliburComponentManager 
>   implements ComponentManager
> {
> ... 
> };
>  
> class ExcaliburServiceManager 
>   implements ServiceManager
>   extends    ExcaliburComponentManager 
> {
> ...
> }
> 
> But with the following changes:
> 
> Remove:
> interface Serviceable {
>   void serve(ServiceManager sm);
> }
> 
> Remove:
> interface ComponentManager {
>   Object lookup (Object key);
> }
> 
> Modify:
> interface Composable {
>   void compose(ServiceManager sm);
> }
> 
> Then, your code, which needs a ComponentManager would be Composable
> and use the SM to lookup a CM that supports *your* domain via:
> 
>  sm.lookup (PaulosComponentManager.ROLE);
> 
> and I could get a CM for my indexing strategy via:
> 
>  sm.lookup (LeosComponentManager.ROLE);
> 
> where (for example):
> 
> interface LeosComponentManager {
>   public Object lookup (String uri, Date time);
> }
> 
> interface PaulosComponentManager {
>   public Object lookup (Node node);
> }
> 
> class LeosComponentManagerImpl extends ExcaliburComponentManager 
>   implements LeosComponentManager {
>   ...
> }
> 
> class PaulosComponentManagerImpl extends ExcaliburComponentManager 
>   implements PaulosComponentManager {
>   ...
> }
> 
> Thus,
>   - all contracts are specified properly, and several indexing
>     strategies can coexist in the same SM.
>   - each interface has its own well defined contract.
>   - you can implement any indexing strategy you choose.
> 
> /LS
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-dev-help@jakarta.apache.org>
> 


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