Antti Koivunen wrote:
> Berin Loritsch wrote:
> > Let's take a quick look at both of these.
>
> JNDI is an interface for naming services. It's not meant just for
> component management, but provides a convenient (and popular) way of
> handling it.
And it can be used to resolve CORBA requests (with the right Context)
>
> CORBA is meant primarily for managing and sharing objects (including
> components) in distributed environments.
>
> Now, as both of these are commonly used for managing components, it
> should be made easy to integrate either one in the core Avalon component
> management.
>
> The issue of Component vs. Object really comes down to the following
> question: should an object be required to implement an empty marker
> interface to be regarded as a component (thus making integration with
> other systems more difficult)? I think not.
We agree on this point.
>> That is why I proposed the resolver interfaces, to solicit feedback on
>> that. Is this something that will satisfy everyone's need? I think it
>> will be a much better fit than even the current CM/CS approach we have
>> now.
>
> Is it intended to replace CM/CS?
IMO Yes.
>
>> Please, I am soliciting feedback on the proposal, so we can see if it
>> fits all our needs.
>
> A few ideas...
>
> 1. Resolveable -> Resolvable (to make it more English :)
Ok.
>
> 2. resolver(Resolver) -> setResolver(Resolver), to make it more
> intuitive (consider e.g. iterator()).
Ok.
>
> 3. I would consider string (e.g. URI) lookups in addition to the heavier
> Query structure. Some examples:
>
> uri://domain.com/services/UserManager
>
> uri://domain.com/User?id=42
> uri://domain.com/User[lastName=Doe,firstName=Jane]
>
> Service:type=UserMgmt,country=FI (JMX style)
Sounds reasonable
>
> (All of these could be represented with an object, if necessary. See
> e.g. javax.management.ObjectName)
>
> 4. In Token: Object[] references() -> Iterator references(), not to
> restrict the implementation (e.g. in case there are MANY references).
There shouldn't be *that* many references that you retrieve at one time.
In practice, I have not seen more than 5-6 external components used.
Even then, that is bordering on being too coupled.
>
> 5. What are the benefits of differentiating COMPONENT, SERVICE and OBJECT?
>
> (: A ;)
The main difference is how the key is expected to be resolved. The big thing
is that the Resolver implementation will likely differ lookup to the Container.
This is a good thing. The Container may have different repositories for each
of these. (Although the merging of Component and Service would probably work).
Lastly, it allows a Resolver to lookup Components from the Container, Services
from the Phoenix Kernel, and Objects from whatever is local to the Resolver
implementation.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
