Hamilton Verissimo de Oliveira (Engenharia - SPO) wrote:
-----Mensagem original----- De: Stephen McConnell [mailto:[EMAIL PROTECTED]
This is what Merlin can do today (without any extension).
Can we plug a different service discovery strategy?
There isn't support for this today - but its perfectly reasonable. An apliance is created and supplied with an Engine instance [1]. The Engine is the thing that handles the resolution of appliance instances relative to dependency requests.
[1] http://avalon.apache.org/merlin/api/org/apache/avalon/activation/appliance/Engine.html
What would be needed is a way to declare in meta-data that a custom engine is to be used.
In my concept, the current container implementations correctly deals with sanity check, and I don't know if it is valid in a distributed container. Do you know what I mean?
Not really. :-)
In a distributed solution the container that is establishing a service is responsible
for santiy checking. But there is a piece missing - a protocol dealing with inter-
container communityactions concerning service availablity. For example, the client
container would aquire a service from a remote container and probably register a
listerner on the remote container. If the remote is taking down the component that
is providing the service, it can notify client containers. The client container can
then perform the usual santity management relative to the components that are consuming
the remote service. The is completely feasible providing we have a local client that
is subscribing as opposed to providing remote services directory to component
implementations.
I.e.:
RemoteComponent ^ | establishes | RemoteContainer
RemoteComponent |
| RemoteContainer <--- subscribes ---------- LocalContainer
RemoteComponent LocalComponent | ^ | | applies | | RemoteContainer ---- exports ------------> LocalContainer
So basically you have a model whereby a client and server collaborate with respect to the service product/consumption relationship. Leading to:
RemoteContainer <------------------------> LocalContainer
In this model the client component is totally unaware that the service it is provided with is remote.
Stephen.
Regards,
hammett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
