I'm going to start with my current understanding of a ROLE (though perhaps
not everyone will agree):
A ROLE represents a contract between a client and an assembler,
allowing the client to inform the assembler what it needs to
work.
a ROLE is identified by an opaque string and includes a set of
interfaces, possibly some constraints etc... [this stuff can be
included in the components metainfo allowing the container to
enforce the contract].
[I use 'assembler' in a broad sense, including automated assembly and
programmatic assembly, as well as someone writing xml -- basically any
actor involved in stringing together the components]
<thinking-out-loud>
when a client looks up a component, two things occur...
1. the component is resolved from the role provided.
2. the component is fetched from it's component manager.
>From the point of view of the assembler: step 1 is associated with the
client (i.e. different clients may have different resolvers). While
step 2 is associated with the component (i.e. different components may
have different managers).
e.g.
<component id="A" manager="someManager" class="....">
<!-- config for A -->
</component>
<component id="B" resolver="someResolver" class="...">
<!-- config for B -->
</component>
so that when B looks up A-role: 1. the request is passed to
someResolver which determines that A is the component wanted. 2. A is
then fetched from someManager.
What if we forced the client to do these two steps separately?
e.g.
public void compose( ComponentResolver cr, ComponentFetcher cf )
{
String id = cr.resolve( "A-role" );
Object component = cf.fetch( id );
}
The id would be container specific - and hence the component cannot
assume anything about it.
So far none of this is very new -- except now the aim is to separate
things out so that they look the same to the component as they do to
the assembler.
Now, what if we allow the assembler the ability to specify the id of a
component? (e.g. the 'id="A"' bit in the xml fragment above).
We have the situation that the role is a string known to the client
and the assembler (and not the container), the id is a string known to
the container and the assembler (and not the client), and the resolver
is a map between them. i.e. resolver: role -> id
The only actor with the knowledge of what the role->id mapping should
be is the assembler -- which is exactly the way it should be.
[component metainfo may allow the container to guess if the resolver
fails, and to check the result if it succeeds].
more explicitly what I'm suggesting is something like:
interface Composable
{
public void compose( ComponentResolver cr, ComponentFetcher cf );
}
interface ComponentResolver
{
/** @return the id of the component */
public String resolve( String role );
}
interface ComponentFetcher
{
public Object fetch( String id );
}
The reason I'm suggesting this is so that the client's view of the
lookup is the same as the assembler's view of the lookup -- this may
help to avoid confusion, since the client has to communicate to the
assembler what it wants (e.g. via docs, metainfo etc.).
There is also an added benefit: the roles of the locater, manager and
assembler are well defined.
assembler: defines a mapping roles->ids for each client.
locater: applies the mapping.
manager: provides instances of the component when requested.
hints/policy disclaimer: I haven't mentioned anything about runtime
hints/policy here -- they could be added to the above suggestion -- or
could be done outside the framework.
[Note: the assembler doesn't need to be able to specify the id
returned to the client -- I just threw that in to make the concept
clearer]
</thinking-out-loud>
Robert.
P.S. interface/method names used were *not* the ones I would chose if
I were to actually implement this - they were chosen to cause the
least confusion in the current context of this mailing list.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
