> -----Original Message-----
> From: Nader Aeinehchi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 15, 2004 4:31 PM
> To: Avalon Developers List
> Subject: Re: [RT] New Lookup mechanism
> 
> Hi Alex
> 
> > So these Entry attributes here are used
> > as the criteria to query for a specific service?
> 
> Basically, an entry could be a String.  However, making it an interface
> allows it to grow to cover the ever growing ways of defining attributes.

Makes sense it's like a JNDI context.

> In a static world, the client code knows exactly what to ask and thus
> knowing a key, say an ID, suffices.
> 
> In a dynamic world, as in Web Services / Jini, the client is interested in
> a
> give Service based on given criteria.  Just the way you would lookup in
> Yello Pages to find a Plumber, a client code could lookup for one or
> several
> interesting services based on certain criteria.  The criteria could be
> very
> different for different clients.

Oh I agree with you here whole heartedly.

> Some interesting criteria in a binary world (like Java/Jini) as opposed to
> a
> textual world (like XML/Web services)
> 1. ID: ID is always an interesting key.  If you knew exactly which plumber
> to lookup for, it would make it very easy

Yep makes sense and this is what we do with the ServiceManager today.  
We look up by id.  Some seem to confuse the situation a bit by using 
the name of the interface as the key (ROLE).  Ideas seemed to be mixed
up all over the place.  The concept of just calling it a darn id, a 
primary key if you will is just simple and the case.  Don't know why
we just have not done that.

> 2. Class(es): The client is probably most interested in Interface(s) a
> certain service implements.  In few cases, the client could be interested
> in
> the implementation classes, but this would be rare.  When you lookup in
> Yellow Pages, you are probably interested in looking up for plumbers, also
> Plumber interface.

I think this is the portion that explains to Hammet what you're 
referring to: a reference to the service interface and not a 
implementation class.  Unfortunately that gets mixed up in terminology 
because an Interface is a class in Java but I understand what you mean.  
I think Hammet thought you were referring to the actual implementation 
Class.  

Referring to the service interface is just fine by me - how else would 
you loosely express the characteristics of the service in Java?

> 3. Entry: Attributes are very interesting when the client code needs to
> filter the results of a lookup.  You would probably like to lookup for
> plumbers in your neighbourhood that are cheap!
> 
> Under controlled environments, like a business application, the client
> code
> knows exactly what to lookup.  Therefore, the result of a query is a
> single
> service.  However, in dynamic systems, say an agent system, the result
> would
> probably be several services.  In such situations, the client code needs
> to
> handle the result and peak the most appropriate result, also the burden is
> on the client code.

Yes this is the most interesting.  Actually because of my efforts on 
the directory side I've been thinking a lot about this.  The lookup of 
services fit hand in hand with directories.  I think that a UDDI 
scheme exists for LDAP already so people are seeing LDAP as a read 
optimized backend for looking up these Web service.  We could do the 
same and use the search capabilities of the directory and its hierarchy 
to nicely model components and their relationships.  

> In a large system, there could be several Registrars.  Registrars could
> announce their services to each other and create a network of registrars.
> This could be very interesting in Merlin, as each underlying container
> could
> own its own registrar.  Further, the underlying registrar could ask the
> registrar in the parent or neigbouring container if it needs to.

Ahh LDAP referrals work very nicely in enabling such a system of 
registrars.

Alex



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to