avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Sat, 12 Jan 2002 13:51:44 GMT


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


Mime
View raw message