Hi Hammet A service consumer shouldn't know who is implementing a > service, otherwise the benefits of using Avalon (loose-coupling) will > disappear.
Please see my other posting where I explained the benfit of using Interface(s) for lookup mechanism. 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: "Hamilton Verissimo de Oliveira (Engenharia - SPO)" <[EMAIL PROTECTED]> To: "Avalon Developers List" <[EMAIL PROTECTED]> Sent: Thursday, April 15, 2004 9:42 PM Subject: Re: [RT] New Lookup mechanism > > -----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) > > } > > I think using classes to describe real implementation requests is wrong in > Avalon land. A service consumer shouldn't know who is implementing a > service, otherwise the benefits of using Avalon (loose-coupling) will > disappear. > > I know a little about Jini (read a book but never got my hands in it for a > project), and I think the semantics for lookups (among other things) is > something that should inspire us when chasing for a evolution. > > > Regards, > hammett > > --------------------------------------------------------------------- > 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]
