[
Lists Home |
Date Index |
Thread Index
]
Alaric B. Snell wrote:
> People say RPC/DCOM/CORBA/etc try to 'hide the network' and make your remote
> logic appear to be just there. They say this is a bad thing because the
> network is unreliable and loosely coupled in ways that code in an address
> space isn't.
>
> But that argument's not really valid. For a start an in-memory call might be
> to a dynamic library that's not currently paged into memory - in fact, the
> shared library file might have been deleted since it was linked in or the
> stack overflowed! Ok, most current systems will kill the processes if either
> of these events occur, but they could just throw a GruesomeSystemException to
> give the code a chance to apologise to the user. Indeed, the equivalent of a
> 404 in following a loosely linked function pointer in a POSIX execution
> environment is a trappable SEGV signal!
>
I don't think it's that easy. The most feared problem in networking is
the dreaded timeout. On the client side you simply don't have an idea
whether the server got a GruesomeSystemException itself or whether
someone pulled the wrong plug elsewhere. In eiter case you'll might
get an answer later - too late (for CORBA et al.), or perhaps not (MOM).
Another problem is designing stuff for networking. In particular
CORBA and RMI make it easy to do stupid things like defining
interface customer {
attribute string firstname;
attribute string lastname;
attribute string birthdate;
attribute string income;
...
and then fill form fields individually with getAttribute()-methods. This
might even work for the developer, but deploy this to 400 clients, and
the result cannot be distinguished from DDoSing the server. Furthermore
if the attributes have to be written back, everyone will ask for
transactions. Which can be easily avoided. IMO the problem of lack of
standards for transactions in certain networking protocols is the most
overrated problem there.
J.Pietschmann
|
