Xref: utzoo comp.object:1504 comp.lang.eiffel:1022 comp.lang.c++:8586
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!east!witzend!db
From: db@witzend.East.Sun.COM (David Brownell)
Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++
Subject: Re: integrating RPC into an Object-oriented system
Message-ID: <2274@east.East.Sun.COM>
Date: 24 Jul 90 12:44:14 GMT
References: <1990Jul18.210701.2679@swbatl.sbc.com> <27463@joshua.athertn.Atherton.COM>
Sender: news@east.East.Sun.COM
Reply-To: db@witzend.East.Sun.COM (David Brownell)
Followup-To: comp.object
Organization: Sun Microsystems, Billerica MA
Lines: 50

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'?"