avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [RFI] service lookup semantics
Date Wed, 03 Dec 2003 03:23:45 GMT
On Wednesday 03 December 2003 10:47, Niclas Hedhman wrote:

> The whole concept is remarkable, IMHO, in that the foundation of the whole
> system, the Lookup Service, is in fact not really different from any other
> service. I can have one or many running, the implementation can be changed
> (theoretically at least) and so forth.

And to boil down the concepts from Jini that _I_ would like to see appear in 
Merlin are;

1. Service Availability.
2. Runtime Attributes.
3. ServiceProxy.
4. Service Instance Identity

Service Availability
Services should be allowed to come and go in runtime, without having to 
shutdown its dependents. The dependents will be informed about the fact and 
could either try to find another service instance or have a fallback 
strategy, such as "wait until available", or a local implementation, or 
queueing the requests...

Runtime Attributes
See the previous mail. Runtime Attributes can be used for a host of functions, 
and by letting them be part of the core infrastructure, one can do many neat 
tricks, lookup only being one, for instance, service management and browsing 
for services.

Service Proxy
By introducing a implementation layer between the service itself and the 
actual service, great flexibility and future-compatibility is achieved.
Although it doesn't makes so much sense in the "local-only" scenario, it is a 
necessity in the "remote" scenario. I think(! ouch, that hurt !) that the 
concept should be part of the Merlin core.

Service Instance Identity
This comes back to the hilarious (delirious) mail about birth/death/travel a 
couple of weeks ago. I am now even more convinced that this is the way to go, 
and that Merlin should provide such UUID for each service instantiated, and
allow for instances to "travel", i.e. serialized to a passive array of bytes.


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

View raw message