You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/09/01 17:33:17 UTC

Re: Service Discovery


J Aaron Farr wrote:

>Nice to see some good discussion happening about this.  I'm going to try
>to split this out into another threads.
>
>As for discovery methods:
>
>On Mon, 2003-09-01 at 02:54, Stephen McConnell wrote:
>  
>
>>Frankly I don't think the current ServiceManager interface is a good 
>>candidate for dynamic service discovery. It does not provide support for 
>>the supply of a selection policy and its exception suite needs to be 
>>beefed up a lot.
>>
>>    
>>
>
>Not the current ServiceManager interface, no.  My point was, given the
>two roles of the ServiceManager (dependency, discovery), I tended to use
>it more for discovery.
>
>The ServiceLocator example you gave was along the lines of what I was
>thinking.  Another option is to first get jndi exporting of services and
>then do all service discovery via the jndi bindings.  The discovery
>service itself could then also be a JNDI Context or at least provide
>one.  Then you get both JNDI exporting and internal service discovery.
>

This sounds good.

>
>
>Any downsides to that?
>

Not that I can see.  One thing we need to be careful about is avoiding 
the addition of features as opposed to declaring a component (in root or 
child container) that is a recognized as a "facility" (as distinct from 
component).

>
>
>Speaking of Contexts, what about the Avalon Context?  Is it providing
>dependencies or is it a discovery service?  
>

No discovery. Simply containment context established relative to the 
contextual dependencies declared by a component.

>I like what Merlin now
>allows us to do in the Context, but I think it's always been confusing
>have two lookup objects (Context and ServiceManager).  Currently I tend
>to think of the Context as a Container wide configuration object.
>

Umm, you have me thinking.  In Merlin today a component can import 
standard context entries or you can construct context values within the 
component deployment directive.  Your comment above about 
"container-wide" get me to thinking about the possibility for the 
declaration of context keys and bindings at a container level.  This 
would allow me (assembler) to override the value assigned to something 
like "urn:avalon:home" within the scope of a particular container.

Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org