On Wednesday 05 November 2003 12:39, Stephen McConnell wrote: > Niclas Hedhman wrote: > >On Wednesday 05 November 2003 08:02, Stephen McConnell wrote: > >>In this model the client component is totally unaware that the service > >>it is provided with is remote. > > > >And I somehow doubt that is feasible. > >Software is either written to handle "service availability" < 100% or it > > is not. > > I agree - *but* - service avalability is not a subject particular to a > 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. 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. > Steve invoking decommissioning of a component via some new fangled > editor he invented last weekend. Can you send me a copy ;o) > >And since I have shown that it is almost a necessity for the Service > >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. > > [steve take a deep breath] > > 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'm just saying that transparent support of making a service remote, may not be feasible (I hate bytecode manipulations, because it hides too much). > >Exactly how an Availability contract is to be defined is down to > > semantics, and we can start that later, once we agree that "transparent > > distribution" is probably not feasible. > > I can do this today if the object model is CORBA. The issue is - can we > 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? Bottom-line; I think we can agree that this is not a distributed-only issue, but we are touching on distribution-requirement land. So, shall we bring it to a discussion about "Availability Contract", and using rmi/corba/soap/local as use-cases? Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
