Niclas Hedhman wrote:
On Wednesday 05 November 2003 08:47, Stephen McConnell wrote:
hammett wrote:
----- Original Message -----From: "Stephen McConnell" <[EMAIL PROTECTED]>
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).
The point is, there are no assurances!!! There can't be no assurances. Trying to pretend that there is, will work in most case, but will fail miserably when things starts to be less reliable. And we want to create a ROBUST environment, not an "Assured" environment, that is plain stupidity.
An assured environment is completely rationale. All one needs to do is define the contract concerning assurance. A assurance contract basically details what happens in the even of failure to assure. I.e. the subject is the protocol of failure - for example - is a failure transient or is it unrecoverable? An assured environment is simply an environment within which assurance is measurable, and understood in terms of success and failure.
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
scenario 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.
Yes, you are right that as much tricky code as possible should be moved to the container, BUT we need to establish a contract between the Container and the client component, so that the container can say;
"Hey, I know you want service A, but sorry, there is none available at the moment. Hang in there, I'll get back to you when I have found one."
Also know as a transient exception containing an expected recovery time.
After which the client component could;
1. Block (for a while) when others are requesting service that depends on the availability of other services.
2. Throw a defined NotCurrentlyAvailableException.
3. Pretend (bad! but have help me in the past)
4. Queue and service later.
5. Mimick.
Whatever it does, it is safe to say that the container have no clue what is the best "Fall-back strategy".
Today we have no specification concerning transient suspension of service availability. We also have no semantic specification of statefull versus stateless services nor qualification of a dependence on a service dependence versus dependence on an identified supplier of a service. If we solve these two issue - we will be cooking on gas!
Cheers, Steve.
(who has traumatic childhood memories concerning the introduction of piped gas involving the destruction of a single seater sorts car by the local gas authority in the winter of '65)
SJM
Cheers Niclas
--------------------------------------------------------------------- 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]
