Berin Loritsch wrote:
> 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)
Yes, of course.
>> 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.
Nice to hear :)
>>> 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.
Ah, good, this clears things up. Something like the Resolver is
definitely needed, thanks for introducing the idea.
AIU, this also means that the system must be capable of handling the
lifecycle states, as well. I wonder if it would make sense to make this
more generic, i.e. to allow some custom handling for certain types of
objects (might be FS).
>> 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
Good. At some stage, we should probably specify a common syntax.
>> 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.
True, if only individual references are returned (as currently implied
by the Query interface). If we don't (ever) intend allow something like
"services/*", this shouldn't be an issue.
In that case, it might be more of a 'NameSet' than a Query, as we only
retrieve 'identifiable' objects (see javax.management.ObjectName and
javax.management.Query). Or even better, we could have something like:
ObjectName name = new ObjectName("query"); // checks the syntax
name.setAttribute("name", "value"); // customize
And have Resolver provide the methods:
Token lookup(ObjectName name);
Token lookup(ObjectName[] names);
Token lookup(String query); // implicit new ObjectName()
Token lookup(String[] queries); // implicit new ObjectName[]
This would also allow attributes to be set on an object level, which I
think is necessary (see the example URIs in question 3. above).
ObjectName would naturally provide efficient implementations for
hashCode() and equals(), so that
name.equals(new ObjectName(name.toString())) == true
>> 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.
I see. It's a good idea, but I can't help thinking that this should
perhaps be a bit more generic, i.e. subject to Resolver configuration.
Especially since the division between objects, components and services
tends to be a little vague (everything returned by Resolver is an
object). The idea could also be combined with the query syntax, e.g. by
using certain prefixes. The JMX approach
[domainName]:property=value[,property=value]*
might work quite nicely here, with the following contracts:
ObjectName : Check the syntax and 'compile' the 'query'.
Resolver : Delegate to the correct 'DomainManager'.
DomainManager : Provide the object (defined by the ObjectName).
This would basically just add the following operation:
DomainManager dm = (DomainManager) managers.get(objName.getDomain());
and allow e.g. "Service:", "Phoenix:", "MySecretPlace:", or whatever...
Thoughts?
(: A ;)
--
Antti Koivunen | "Anrie" [un-ree] <[EMAIL PROTECTED]>
---------------------------------------------------------
The song of life might not be a simple one,
but there's plenty of room for improvisation.
---------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
