hammett wrote:
----- Original Message ----- From: "Stephen McConnell" <[EMAIL PROTECTED]>
Not really. :-)
Hmmm ...
:-)
In a distributed solution the container that is establishing a service
is responsible
for santiy checking.
Exactly, but on demand, when a component/service is requested. I think in a distributed environment the container should start up with few - or none - information about the services it should expose or consume. These will be discovered in the right time, when one feels like requesting/exposing them. It is totally different from what we have now, as Niclas already stated.
What we have now is "assurance of service availablility" before deployment. This is not service aquisition - its simply validation that a deployment scenario is viable. In a distributed scenario this means that the container is still responsible for delegating that assurance responsibility towards one or more candidate providers (and by provider I mean some remote system that can provide a stateemment of assurance).
But there is a piece missing - a protocol dealing
with inter-container communi[c]actions 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.
Easy man! :-) That is a possible strategy, but is not the one.
If the remote is taking down the component that
is providing the service, it can notify client containers.
On my head the Client/Server should not create any kind of link. The client just can't rely on any notification of the server is taking down. In fact the client doesnt know any server; if it needs a service, it shout and obtain someone to help it. After a while, if it needs the same service again, it should shout again.
My turn .... ummmm!
There are a bunch of models that can be applied concerning service aquisition
but at the end of that day, you have a link between a client and a server and
you choose to manage that link or to leave it up to the component. Leaving it
up to the component just results in more code in the component dealing with
remoteness considerations. We want to eliminate that - which means shifting
monitoring and availablity management down into the container. That means
that a container is dealing with distribution specifics - e.g. in an IIOP
sceanrio this means handling transient exception, establishing and maintaining
event channels, populating value type, establishing pricipals, etc. I.e. the
container is the client and has reasonably imnport role to play in properly
isolating the component from the distribution strategy.
In this model the client component is totally unaware that the service it is provided with is remote.
If we can do that, it would be very very nice.... :-)
Technically it is dooable. But there are a few prereqs we need to put in place inside Merlin concerning custom appliance establishment. Once that is done, we will have the framework for experimentation.
CHeers, Steve.
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]
