Peter Lacey
Thu, 14 Jun 2007 09:56:19 -0700
I think the distinction might be between a network protocol and distributed computing. A large number of network protocols can make certain assumptions about the network and the client environment that aren't valid for distributed computing. For instance, if I made a database server and the corresponding network library, I can assume a fast, reliable network with persistent connections and the ability to send lots of small messages over short distances. More importantly, I _know_ that the client on the other end is either something I wrote or adheres to a stringent protocol I designed to work with my system. That is, the client and server are very tightly bound. Think Oracle and OCI, or LDAP, or X Windows. In a distributed computing environment, however, where components of a system are running on multiple computers of differing design and differing capabilities at unknown distances, then most of these assumptions have to be dropped. For large scale distributed computing it is best to design a system that is fully aware of the network and the fact that it is unreliable, has non-zero latency, etc. (http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing). It's here where the RPC style falls down. By making remote calls appear local, you engineer in a programming model that pretends the network doesn't exist and that the remote service is designed similarly to your client (e.g., a shared type system and programming model). And this is going to lead to an inappropriate architecture for a system that is not likely to have these properties. - Pete > > Ummmm I disagree there (and it was going so well on this thread :) ), > because fundamentally all calls are remote at some level. I remember > being told that C led to bad software as it hid from you the registers > that were being used, it was also bad because it hid what instructions > where actually being used and made it difficult to optimise things to > be stored within the same blocks of memory to reduce seek times. I > remember being told the same thing about Java because Java was a > virtual machine and therefore made programming independent of the > operating system which could only lead to disaster... > > There is nothing inherent in having interface consistency that leads > to bad architectures, paticularly when you combine highly skilled > people with more average developers as it represents a clear > separation of concerns. More skilled people focus on what should be > where, average people just code as if someone else is making the > decision. That works. Exposing the complexity of remote invocation > to all developers leads to failed projects no matter how > architecturally pure the solution. > > I've seen more projects fail because they _didn't_ provide that > abstraction than I have because they _did_. > > Steve > > > On 14/06/07, *Stefan Tilkov * <[EMAIL PROTECTED] > <[EMAIL PROTECTED]>> wrote: On Jun 13, 2007, at 7:38 PM, > Mark Baker wrote: > > > Furthermore, I suppose we should stop even talking about RPC in the > > context of software architecture because whether a system uses it or > > not, matters not to the architecture of that system. > > With the definition we sort of agree on, yes - although indirectly, > the use of a programming model that tries to make a remote invocation > appear like a local call will often lead to a bad architecture. > > Stefan > -- > Stefan Tilkov, http://www.innoq.com/blog/st/ > <http://www.innoq.com/blog/st/>