Niclas Hedhman wrote:
On Wednesday 05 November 2003 12:39, Stephen McConnell wrote:
Niclas Hedhman wrote:
On Wednesday 05 November 2003 08:02, Stephen McConnell wrote:I agree - *but* - service avalability is not a subject particular to a
In this model the client component is totally unaware that the serviceAnd I somehow doubt that is feasible.
it is provided with is remote.
Software is either written to handle "service availability" < 100% or it
is not.
distributed scenario.
I think I haven't argued the opposite. I just point out that the distributed case makes it more needed, and we don't have it all today.
We agree.
A side note; You can't remove the reference to a service implementation from a client in the local scenario, it can only be put into a "non-operational" state, and you can do it after "release()", but in the remote case, the reference can just cease to exist.
But we can proxy a remote service and abstract out the different distribution strategies - providing we have a well definined availability/assurance contract.
Steve invoking decommissioning of a component via some new fangled
editor he invented last weekend.
Can you send me a copy ;o)
No.
I've got more that a couple of issue to work though and committing broken code sucks!!
And since I have shown that it is almost a necessity for the Service[steve take a deep breath]
specification to declare its intention of being Remote by throwing
RemoteException on all methods in the interface, there will be at least in
implicit way to determine a remote capable service implementation.
I'm not ready to agree with you on this one. I'm not saying your wrong
- but I figure that you could be wrong.
I don't think you can say I am wrong, since I don't really assert anything useful (I'm not right either).
I think we are agreeing on this. I would throw RemoteException into a strategy specific anomaly. But it's an important anomaly and one that needs to be dealt with under a container distribution assurance abstraction layer.
I'm just saying that transparent support of making a service remote, may not be feasible (I hate bytecode manipulations, because it hides too much).
Transparent support for distribution is feasible providing we abstract to a level where we provide support for interuption and disruption.
Exactly how an Availability contract is to be defined is down toI can do this today if the object model is CORBA. The issue is - can we
semantics, and we can start that later, once we agree that "transparent
distribution" is probably not feasible.
do this across multiple distribution strategies.
Really? So what happens to the client when the network fails half way through the call (incomplete call (and I'm not going into the swamp of call/state consistency)), that doesn't throw any exceptions? Runtime exception?
Yes.
But a set of rutime exceptions with well defined semantics.
Bottom-line; I think we can agree that this is not a distributed-only issue, but we are touching on distribution-requirement land.
Yep.
So, shall we bring it to a discussion about "Availability Contract", and using rmi/corba/soap/local as use-cases?
Yes - but I would prefer to think of this in terms of a deployment "Assurance Contract".
:-)
Stephen.
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]
