avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nader Aeinehchi" <na...@aeinehchi.com>
Subject Re: [RT] New Lookup mechanism
Date Thu, 15 Apr 2004 20:30:37 GMT
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.

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.

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

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.

Finally, in our project, we a made it easy for the developers to use the
Registrar simply by providing a couple of utility classes.


Best Regards

--
Nader Aeinehchi
Aasenhagen 66 E
2020 Skedsmokorset
NORWAY
Direct and Mobile +47 41 44 29 57
Tel (private): +47 64 83 09 08
Fax +47 64 83 08 07
www.aeinehchi.com

----- Original Message -----
From: "Alex Karasulu" <aok123@bellsouth.net>
To: "'Avalon Developers List'" <dev@avalon.apache.org>
Sent: Thursday, April 15, 2004 9:27 PM
Subject: RE: [RT] New Lookup mechanism


> Nader,
>
> > -----Original Message-----
> > From: Nader Aeinehchi [mailto:nader@aeinehchi.com]
> > Sent: Thursday, April 15, 2004 3:06 PM
> > To: Avalon Developers List
> > Subject: Re: [RT] New Lookup mechanism
>
>
> > 4. A client code looks up for a particular service by sending Template.
> > Template may include a combination of Id, Class(es) and Entry(ies)
> >
> > public class Template implements Serializable {
> >     public Id id;
> >     public Class[] classes;
> >     public Entry[] attributes;
> >     public Template(Id id, Class[] classes, Entry[] attributes)
> > }
>
> Very interesting mechanism Nader!  So these Entry attributes here are used
> as the criteria to query for a specific service?  I like this very much
> because it seems simple yet very expressive.
>
> I wonder what others will think about it.  BTW I need to start
> getting educated on JINI.  Have not really taken a look at it but
> we at Avalon should be looking at other mechanisms before we invent
> our own.
>
> Alex
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org


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


Mime
View raw message