Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!elroy.jpl.nasa.gov!ames!amdcad!sun!stpeter.Eng.Sun.COM!cmcmanis From: cmcmanis@stpeter.Eng.Sun.COM (Chuck McManis) Newsgroups: comp.protocols.misc Subject: Re: RPC Technologies Message-ID: <139763@sun.Eng.Sun.COM> Date: 27 Jul 90 20:40:15 GMT References: <1990Jul20.032431.7497@athena.mit.edu> Sender: news@sun.Eng.Sun.COM Organization: Sun Microsystems, Mt. View, Ca. Lines: 69 This discussion is great fun guys, keep it up. I'd like you to consider a paradigm for a moment and see if both of you are talking about the same thing. It goes something like this : There are two distinct ways in which Remote Procedure Call technologies are used. The first (and currently most common) is in the development of network services. The second is in the development of distributed applications. Distinguishing between what type of program you are writing can make a whole bunch of issues clear. First, lets look at network services. A network service is an application that usually runs on a single machine. The application exports to the world "functions" (procedures for you PASCAL types) which can be called by client applications when they want to use the service. From the user's perspective there is a well documented protocol and a bunch of "stubs" that they can call to access the various exported procedures of the service. These services are generally things like name servers or remote file servers. In this environment developing applications is fairly straight forward. The programmer looks at the "man" page for the functions they need to call (let's say our name service exports the function "Lookup") and writes in the code to call that function. The application programmer doesn't care about "semantics" or "data encoding styles" or whatever. They just want to call the function and get a result. Once the application is written the code is linked with the "stubs" and the programmers work is done. From the network service developer's perspective, he (forgive the sexist language) wants to be able to create a service make it available but doesn't want to become some wizard sockets programmer. Here an environment such as ONC/RPC or NCS helps out because they present a paradigm that looks like procedure calls as opposed to networking calls and the grunt work is handled by a bunch of library routines. (Compared to something like 'sendmail' which is very difficult to maintain and the protocol somewhat difficult to document) Here the service designer can decide "how close to the metal" he wants to write his code because only he knows the true requirements being made of the underlying network. So to summarize network services, they are easy to use by application programmers because they just link to the service's library of client stubs. The service developers want to develop services that are reliable and easy to maintain and the tools provided help them do that. A distributed application on the other hand is a whole different beast. Here we have a process (single execution context) which has pieces of itself operating on different machines (discontiguous address spaces). Here the requirements of the underlying distribution technology become very strict since ideally the system works identically whether or not any piece of it is distributed. This is where such overly marketed things like "at most once" semantics (or more commonly "exactly once") semantics are required. The key differences between these sorts of applications and network services are that while several clients may access the functions of a network service, exactly one client accesses a piece of itself across the network.[ As an aside, I haven't found any research yet that suggests distributing an application has any positive effect on that application, much like the parallel processor challenge. ] It is still unclear what the ideal environment for developing distributing applications is, much like it is unclear about how to write parallel applications in a general way. (I know, lots of great work but no clear conclusions yet) Bottom line, you decide. I'm always a bit suspicious when the snowmobile salesman says "But this is clearly the superior snowmobile! Not very many people own one so it's distinctive and it is the only one with air conditioning!" -- --Chuck McManis Sun Microsystems uucp: {anywhere}!sun!cmcmanis BIX: Internet: cmcmanis@Eng.Sun.COM These opinions are my own and no one elses, but you knew that didn't you. "I tell you this parrot is bleeding deceased!"