FlowBasedProgramming | RecentChanges | Preferences

This page is in OpinionMode.

RPC might be a special case of FBP. If true, then it should be possible to provide the convenience and transparency of RPC-like mechanisms in a properly architected FBP environment, along with FBP's other benefits. For reference and counterpoint, also see http://www.jpaulmorrison.com/fbp/oops.htm and the RPC discussion near the bottom of ErlangLanguage.

Here's why this might be true:

Here's why this might *not* be true:

While putting together [rpc822], I became aware of a nagging feeling that RPC calls are actually a special case of FlowBasedProgramming; hence this page. I'd be highly interested in hearing what other people think about this.

I think there's a way to map RPC remote objects and methods onto FBP's ports and IPs, but the details escape me so far -- I can't tell if "amethod" is an FBP port, or if the port is "aremoteobj". If the latter, then "amethod" is likely the "out" or "in" which Paul's discussing below. This might be right, as it opens up the ability to do other calls on the port, such as close(). In XML-RPC, the remote object is created from the server URL using a library call; in FBP maybe that means "aremoteobj" is the object created from the port name using a library call. Or maybe "aremoteobj" is an FBP controller/router/scheduler (Paul, is there a name for such a thing?). If "aremoteobj" is a router, then it was probably passed to the process at startup, and would have to support a standard API. If "aremoteobj" is a router, then perhaps the library call mentioned above is instead a router method, and so on. (Most of this paragraph suffers from CodeSmell, but I can't tell where. Probably because I'm neglecting the return path.)

Maybe an RPC call is a case of dynamic configuration of the FBP network -- if so, http://www.jpaulmorrison.com/fbp/compos.htm might be a good place to start.

If I had to, right now, come up with a better definition of what RPC vs. FBP really are, I'd say "RPC is a special case of FBP, and bad RPC design is a special case of bad FBP design". The definition of "good" vs. "bad" design seems to be in whether the RPC client hardcodes direct references to objects or methods on the RPC server, or whether the references are instead like FBP port names and can be reconfigured at runtime. Hardcoding gives you "bad" RPC, while ConfigurableModularity gives you "good" RPC. Maybe this page should instead be titled MostRpcIsBadFbp?... ;-)

-- SteveTraugott

This seems to be similar to what DavidGelernter and NicholasCarriero say in their article called "Linda in Context", Communications of the ACM, Vol. 32, No. 4, April 1989 (see LindaLanguage):

"In our experience, processes in a parallel program usually don't care what happens to their data, and when they don't, it is more efficient and conceptually more apt to use an asynchronous operation like Linda's "out" than a synchronous procedure call.... It's trivial, in Linda, [or FBP] to implement a synchronous remote-procedure-call-like operation in terms of "out" and "in" [FBP "send" and "receive"]. There is no reason we know of, however, to base an entire parallel language on this one easily programmed but not crucially important special case."


FlowBasedProgramming | RecentChanges | Preferences
This page is read-only - contact owner for a password | View other revisions
Last edited August 6, 2005 4:32 am by SteveTraugott (diff)