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. Heck - if I suspend a component using JMX I'm distrupting the availabilty level. If you think about availability and assurance of continuatity - it isnt the subject of distribution - insteat it's the subject of the assurances provided by the local container to the local component. That contract of service assurance and assurance of service delivery has to abstract out distributed problems in much the same way that it has to abstract out the problem of Steve invoking decommissioning of a component via some new fangled editor he invented last weekend.
RMI was under heavy fire initially because RemoteException was not a RuntimeException and people want the "remoteness" to be hidden/transparent, BUT the argument was (and is), if the application is not explicitly designed to handle network failures, it won't do well in real world situations.
And the more I think about it, the stronger I feel we are at the same position here.
Simpliar position - but much better knowledge.
To proceed with distributed containers, I'm now convinced that an Availabilty contract must be established between container and client component.
+1
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.
;-)
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.
The "up-side" is that it will also allow containers to easily upgrade services, just announce to clients that the service is not availble, chuck out the classloader and classes, and reload, et cetera... And moving agents, and self-configuring systems, and...., and...
Umm, ouch, zut, gosh, but .....
Problem is that all of the interesting services maintain state. I.e. its not just a service that your interested in - in effect your interested in changing the state of a process somewhere in the world. Its not just the service - it who the provides the service and the impact of change that matters.
Cheers, Stephen.
--------------------------------------------------------------------- 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]
