Hello
Please allow me to engage myself in the discussion of Lookup mechanism and
make a suggestion based on a customer project we did.
1. Inspired by Jini, we developed a Registrar. Registrar serves the its
service providers and service consumers.
We tried to keep the interface of Registrar as much as possible as Jini
Registrar such that we could switch to Jini in future. However, we did not
develop the leasing mechanism of Jini.
2. The interface of Registrar:
public interface Registrar {
Item register(Item item );
void unregister(Item item );
Object lookup(Template tmpl);
Id getId();
}
3. The item encapsulates a service plus attributes.
Attributes may be for example, group, container etc:
public class Item implements Serializable {
public Id id;
public Object service;
public Entry[] attributes;
public Item(Id id, Object service, Entry[] attributes)
}
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)
}
5. The above model provide us a very flexible Registrar. Furthermore, we
made sure that Registrar was NOT singleton such that a group of components
(say in a particular container) could establish an own Registrar.
6. The implementation was few hundred lines of code.
7. We achieved a reactive self-healing system using three components:
Registrar, Hub and Spoke Event system and an Exception Manager. Our
Exception Manager could run a Repair Command class for a corresponding
Exception. But that is another story...........
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: "Bruno Dumon" <[EMAIL PROTECTED]>
To: "Avalon Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, April 14, 2004 7:44 PM
Subject: Re: [RT] New Lookup mechanism
> On Tue, 2004-04-13 at 18:25, Stephen McConnell wrote:
> > Hi Marcus!
> >
> > I've got some general questions about selection that perhaps you or
> > other could fill me in on. First off - I'm separating out in my head
> > three different things:
> >
> > 1. the interface we use for locating something (lets call
> > it Locator for the purpose of discussion)
> > 2. the interface used to supply and instance of a Locator
> > to a component
> > 3. the sort of information that a component can include
> > in a locate request and the expected behavior of
> > container in resolving such a request
> >
> > Item (3) is the thing that IMO needs to be expanded on. Here is a
> > couple of examples of an invocation followed by a couple of questions.
> > Please not that I'm also not really worried about the argument or
> > signatures just yet - so don't pay any attention to the approach - I'm
> > in information gathering stage!
> >
> > public void someDeliveryMethod( Locator locator )
> > {
> > Map map = new Hashtable();
> > map.put( "color", "red" );
> > Football football = locator.locate( Football.class, map );
> > }
> >
> > In the above the component implementation has to assume that a container
> > has been configured such that "color" is understood - i.e. is
> > translatable to something that will help in the determination of the
> > appropriate instance to be returned.
> >
> > Possible interpretations:
> >
> > 1. color is an attribute of a component type
> > 2. colour is an attribute of a service implemented by a
> > a component type
>
> isn't the service already identified uniquely by the interface?
>
> > 3. color is a feature attributed to a component model
> > (i.e. component model x has configuration y and is
> > tagged with attribute color=red)
>
> yes
>
> I think this also comes closest to what selectors offer, which allow the
> same implementation class with different configurations to be assigned
> different (excuse the word) hints.
>
> > 4. color is an attribute used by a selection handler
> > that knows about the Football class
>
> Maybe, but this requires extra work.
>
> >
> > Some questions:
> >
> > 1. if color is understood by a container, but no solution
> > are resolvable - is that a failure or is the container
> > obliged to return at least some football
>
> failure
>
> >
> > 2. which leads to the question .. should we be describing
> > a Query object instead of a map? E.g.
> >
> > Constraint color = new Constraint( "color" );
> > color.setRequired();
> > color.setValue( "red" );
> > locator.locate( Football.class, new Query[]{ color } );
>
> don't know.
>
> As Carsten pointed out, it might well be that a simple key assigned to a
> component model is all we need. Until know, I haven't encountered the
> need for more complex queries yet (but also hadn't thought about the
> possibility).
>
> --
> Bruno Dumon http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> [EMAIL PROTECTED] [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> 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]
