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" <[EMAIL PROTECTED]> To: "'Avalon Developers List'" <[EMAIL PROTECTED]> Sent: Thursday, April 15, 2004 9:27 PM Subject: RE: [RT] New Lookup mechanism > Nader, > > > -----Original Message----- > > From: Nader Aeinehchi [mailto:[EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
