gilstrap@aslan.sbc.com (Brian Gilstrap) (07/19/90)
The subject pretty much says it all. Does anyone have any experiences
(or pointers
to papers or whatever) which they would like to share? I'd greatly
appreciate it.
Related thoughts (e.g. integrating TCP with OO systems) are welcome as well.
Thanks,
Brian R. Gilstrap
gilstrap@aslan.sbc.com
gilstrap@aslan.swbt.com
...!{texbell,uunet}!swbatl!aslan!gilstrap
------------------------------------------------------------------------
---------
"You spend your whole life just piling it up there. You got stacks and stacks
and stacks. Then Gabriel comes and taps you on the shoulder, but you don't see
no hearses with luggage racks."
--- Don Henley
------------------------------------------------------------------------
---------
Copyright (c) 1990 by Brian R. Gilstrap. You may redistribute (my portions of)
this material for free if and only if your recipients may also do so.joshua@athertn.Atherton.COM (Flame Bait) (07/20/90)
> = stuff written by gilstrap@aslan.sbc.com (Brian Gilstrap) > The subject [integrating RPC into an Object-oriented system] > pretty much says it all. Does anyone have any experiences > (or pointers to papers or whatever) which they would like to > share? I'd greatly appreciate it. I'm not aware of any papers describing this, so if you do this well, please write a paper for the rest of us. I do have some ideas and thoughts: Ideally OO, which is a design and implementation methodology, should not conflict with (or interact with) RPC, which is a communications service provided by the environment. Unfortunately, both deal with data structures. RPC must know about data structures so that it can translate them from machine to machine, and OO implementations handle data structures differently from other systems. There are two problems making an RPC system work with an object oriented system. First, many OO systems are dynamic; they change at run time, often adding new methods or data types. Second, the describe data differently, often saying this data structure is just like that data structure except for.... The second problem can be solved by changing the language used to describe RPC calls, giving it a more OO feel. This is especially easy to do with Sun RPC, but can be done with other RPCs. The first problem may not exist at all if all of your methods and object types are described at compile time. It they are changed at run time, then there are two possible solutions. If you are using Sun RPC, an autoloader could be used to update the RPC system for each new method or object type, or a general interpreter could be written to handle all cases. I'm not sure if these solutions would work for other RPC systems. I suspect that they could work, but it would be harder. > Related thoughts (e.g. integrating TCP with OO systems) are welcome as well. This is a much simpler question, since TCP does not deal with data typing, it is just a library which can be called from any application, independant of what methodology or language was used to implement the application. Joshua Levy (joshua@atherton.com)
fkittred@bbn.com (Fletcher Kittredge) (07/20/90)
In article <27463@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: >> = stuff written by gilstrap@aslan.sbc.com (Brian Gilstrap) > >> The subject [integrating RPC into an Object-oriented system] >> pretty much says it all. Does anyone have any experiences >> (or pointers to papers or whatever) which they would like to >> share? I'd greatly appreciate it. > >I'm not aware of any papers describing this... > I looked for three minutes, in only one reference, and found all of the following: In 1988 Usenix Conference Proceedings: "Wrappers:" Solving the RPC Problem in GNU C++ Michael D. Tiemann: p. 343 In 1990 Usenix Conference Proceedings: Reliable Distributed Programming in C++ Graham D. Parrington : p. 37 Not really RPC, but interesting if you are not interested in having tunnel vision about possible solutions to distributed programming: In 1990 Usenix Conference Proceedings: Experiences in Writing a Distributed Particle Simulation Code in C++ David W. Forslund et. al. : p. 177 The Conduit: A Communications Abstraction in C++ Jonathan M. Zweig, et. al. : p. 191 >There are two problems making an RPC system work with an object oriented >system. First, many OO systems are dynamic; they change at run time, often >adding new methods or data types. Second, the describe data differently, >often saying this data structure is just like that data structure except >for.... From my experience, C++ is especially suitable for use in this area. A major aspect of C++ is it is not dynamic, so you don't have to worry about problem number one. Fletcher E. Kittredge fkittred@bbn.com Lead Programmer Platforms and Tools Group BBN Software Products Company 10 Fawcett St. Cambridge, MA. 02138
db@witzend.East.Sun.COM (David Brownell) (07/24/90)
In article <27463@joshua.athertn.Atherton.COM> joshua@Atherton.COM (Flame Bait) writes: > Ideally OO, which is a design and implementation methodology, should not > conflict with (or interact with) RPC, which is a communications service > provided by the environment. On the other hand, systems that work via message passing -- even the very restricted request/response paradigm of RPC -- seem to me to fall neatly into the OO category. The methodology of designing a robust distributed system doesn't have many major differences from other OO methodologies, except that issues like security, integrity, and fault handling can't be ignored with arguments like "all the objects are in this one address space, and there are no partial failures". Some people use the O word nowadays to refer to systems with one address space within which implementation inheritance works. If that's your religion, loosely coupled systems (like ones based on RPC) are built of something other than objects. That's not my religion. > There are two problems making an RPC system work with an object oriented > system. First, many OO systems are dynamic; they change at run time, often > adding new methods or data types. Second, the describe data differently, > often saying this data structure is just like that data structure except > for.... Actually, there's no reason an RPC-based system can't be dynamic in this sense. However, it requires particular attention to issues of configuration management that are a bit alien to classic concepts of "what's a protocol". Protocols are static entities; if they weren't, multiple vendors would not be able to support the same protocol very easily or efficiently. Configuration management in distributed systems is not trivial, and most technologies that support "implementation inheritance" can't easily offer it on a network -- where you usually can't upgrade older software that's controlled by some other group, which won't upgrade it quickly (if at all) because their organizational mission depends critically on that software. I've built systems integrating C++ and SunRPC, for example. Servers are objects, which act as "object managers" (in the V system sense, handling naming, methods, and access control) for other objects. An RPC protocol details the methods supported by a class of server; one server process can support multiple classes if desired (though service binding gets fun). The main differences from these RPC-based objects and others I might use is that the class interfaces consist (logically) only of virtual methods, and new kinds of errors can occur during method invocation. David Brownell db@east.sun.com. "What's the network equivalent of 'the rough section of town'?"
janet@ico.isc.com (Janet Ackermann) (07/24/90)
In article <58326@bbn.BBN.COM> fkittred@spca.bbn.com (Fletcher Kittredge) writes: >In 1988 Usenix Conference Proceedings: > "Wrappers:" Solving the RPC Problem in GNU C++ > Michael D. Tiemann: p. 343 > >In 1990 Usenix Conference Proceedings: > Reliable Distributed Programming in C++ > Graham D. Parrington : p. 37 > >Not really RPC, but interesting if you are not interested in having tunnel >vision about possible solutions to distributed programming: > >In 1990 Usenix Conference Proceedings: > Experiences in Writing a Distributed Particle Simulation Code in C++ > David W. Forslund et. al. : p. 177 > > The Conduit: A Communications Abstraction in C++ > Jonathan M. Zweig, et. al. : p. 191 I thought I should mention that the references cited here are from the 1990 USENIX C++ Conference and 1988 USENIX C++ Conference, not the general USENIX Conferences.
mishkin@apollo.HP.COM (Nathaniel Mishkin) (07/25/90)
In article <1990Jul18.210701.2679@swbatl.sbc.com>, gilstrap@aslan.sbc.com (Brian Gilstrap) writes: |> The subject pretty much says it all. Does anyone have any experiences |> (or pointers to papers or whatever) which they would like to share? |> I'd greatly appreciate it. NCS, the RPC system developed by HP (Apollo) is founded on object-oriented ideas. There are three references you might want to look track down: The Network Computing Architecture and Systems: An Environment for Developing Distributed Applications. Dineen, et. al. Summer 1987 Usenix Proceedings. Network Computing Architecture. Zahn, et. al. Prentice-Hall, 1989. Network Computing System Reference Manual. Kong, et. al. Prentice-Hall, 1990. While NCS can be used as a conventional RPC system (which is what we expect people to be doing, at least for now), some of the OO basics are there. [Aside: Since I don't regularly read this group, I'm going to use Smalltalk's terms as the lingua franca.] In particular, we define a 128 bit unique ID format (UUID) for use as an object handle. Objects, types (Smalltalk's "classes"), and interfaces (a collection of Smalltalk "message" names) are all identified by UUID. The system is designed to support multiple "managers" (i.e., implementations of a set of interfaces for a particular type) to coexist within a single server. In fact, the system is really oriented to thinking not of directing calls to servers, but rather directing "operations" (Smalltalk's "messages") to objects, the code which manipulates those objects happening to be loaded in a process (the process being an implementation artifact not visible to the applier of the operation (caller of the remote procedure). NCS includes a "Global Location Broker", which can be used to locate objects by their UUID. Also, above the low-level RPC system, we (the NCS developers) have tried to be careful to define (at least the more important) network interfaces to be generic -- to allow for the possibility of multiple implementations that can interoperate. For example, the network naming system (not yet a product) defines network interfaces for operating on things that are like directories (i.e., symbol tables that map a component of a pathname into object UUIDs, and possibly more directory entry attributes). The idea is that any object type that handles these interfaces can participate in the resolution of network-wide pathnames. Much of this sort of thing has been done before, at least in non-product form. BBN's Chronus system and U. of Washington's Eden system come to mind. -- Nat Mishkin Cooperative Object Computing Operation Hewlett-Packard Company mishkin@apollo.hp.com
macrakis@osf.fr (Stavros Macrakis) (07/30/90)
I know that there will be at least one paper (and probably many more) on this subject at the upcoming Workshop on Object Orientation in Operating Systems, to be held at the ECOOP/OOPSLA joint conference in Ottawa, 22 October 1990 and organized by Marc Shapiro (INRIA) and Vince Russo (Univ. Illinois).
eric@diku.dk (Eric Jul.) (08/02/90)
gilstrap@aslan.sbc.com (Brian Gilstrap) writes: >The subject pretty much says it all. Does anyone have any experiences >(or pointers >to papers or whatever) which they would like to share? I'd greatly >appreciate it. >Related thoughts (e.g. integrating TCP with OO systems) are welcome as well. >Thanks, >Brian R. Gilstrap >gilstrap@aslan.sbc.com >gilstrap@aslan.swbt.com >...!{texbell,uunet}!swbatl!aslan!gilstrap >... >Copyright (c) 1990 by Brian R. Gilstrap. You may redistribute (my portions of) >this material for free if and only if your recipients may also do so. As part of the Emerald project at the University of Washington, I've implemented remote object invocation in the distributed, object-based language Emerald. Here's a few references: * Black et al, "Object Structure in Emerald", OOPSLA '86 * Black et al, "Distribution and Abstract Types in Emerald", IEEE Trans. on Software Engineering, vol. SE-13, no. 1, Jan. 1987. * Jul et al, "Fine-Grained Mobility in the Emerald System", ACM Trans. on Computer Systems, vol. 6, no. 1, Feb. 1988. * Jul, "Object Mobility in a Distributed Object-Oriented System", Ph.D. thesis, available as DIKU technical report 89/1. Also interesting is: Almes et al, "The Eden System: A Technical Review", IEEE Trans. on Software Engineering, vol. SE-11, no. 1, Jan. 1985. -- Eric Jul Univ. of Copenhagen eric@diku.dk
noren@dinl.uucp (Charles Noren) (08/02/90)
In article <1990Aug2.115403.14012@diku.dk> eric@diku.dk (Eric Jul.) writes: >gilstrap@aslan.sbc.com (Brian Gilstrap) writes: > > >>The subject pretty much says it all. Does anyone have any experiences >>(or pointers >>to papers or whatever) which they would like to share? I'd greatly >>appreciate it. > >>Related thoughts (e.g. integrating TCP with OO systems) are welcome as well. > >As part of the Emerald project at the University of Washington, I've >implemented remote object invocation in the distributed, object-based >language Emerald. For C++ people, you may be interested in what the InterViews package from Stanford has for distributed objects. There is no documentation supplied with it for the distributed object support other than the documentation in the code and the man pages (although the man pages refers to some published articles). You can get InterViews by anonymous ftp from at least two sites: [36.22.0.175] and [36.22.0.14]. Does anyone have copies of documentation on the shared object features of InterViews on an ftp machine (or e-mail, etc.)? BTW, InterViews is a C++ class library toolkit for X-Windows. -- Chuck Noren NET: dinl!noren@ncar.ucar.edu US-MAIL: Martin Marietta I&CS, MS XL8058, P.O. Box 1260, Denver, CO 80201-1260 Phone: (303) 971-7930