Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!well!rbp
From: rbp@well.sf.ca.us (Bob Pasker)
Newsgroups: comp.databases
Subject: Re: Why Distributed?
Message-ID: <17154@well.sf.ca.us>
Date: 10 Apr 90 17:08:04 GMT
References: <40078@iuvax.cs.indiana.edu> <8936@sybase.sybase.com> <5180@rtech.rtech.com> <2b56xrv@unify.uucp>
Organization: Bob Pasker, Software & Communications Consultant
Lines: 81

nico@unify.uucp (Nico Nierenberg) writes:

-In article <5180@rtech.rtech.com> davek@rtech.UUCP (Dave Kellogg) writes:
--I couldn't have stated the problems with an RPC-based interface any better.
--However, not all products use RPCs as the basis for distributed processing.
--RPCs are not the same as distributed databases.
-What in the world are you talking about?  RPC stands for remote procedure
-call and is an implementation mechanism for routing requests over a 
-network.  It has nothing to do with a user view of a distributed or
-non-distributed database.

well, you're both right.  dave is right when he says that not all
products use RPCs for distributed databases and nico is right when he
says that it has nothing to do with a users view of anything.  So
what? Your wrong, nico, about RPCs and networking. RPCs have nothing
to do with networking, by the way. RPCs are a model for building
client/server-type applications and have NOTHING to do with routing
requests.  See, RPCs are an Application Layer service element and
routing is a Network Layer thingy (that's networking jargon.)

--Distributed databases do exactly what you need.  Ingres/STAR provides a
--glboal data dictionary that keeps track of what objects live where, so you
--don't need to preface the tablename with SERVER-LOCATION.TABLE-NAME.  
--
--For transparency, all you want to say is 
--
--   select commission from salary, sales where salary.empid = sales.empid;
--
--Ingres/STAR lets you do that, without all the messy non-transparent 
--references to what "server" or what node the database lives on.  That's 
--called location transparency and distributed databases deliver it.
--
-Nice commercial.

But true. dave can't help that he's in marketing. its a shame that
bright people like him wind up there sometimes.

-As a matter of fact I will
-bet you that somewhere deep in your networking layer you have something
-that looks like RPC's.

I'd be very happy to take this bet.  There is no RPC interface, per
se, in INGRES/net or GCA (INGRES' application layer for databases).
The SPECIFIC problem with RPCs is that, as commonly defined and
implemented, there is a set of parameters passed as an RPC invocation
from client to server and a single response returned (i.e. a return
value.)  When you perform a select that returns more than one tuple
you have more than one response.  The model then becomes somewhat
awkward because you have to make reverse child procedure calls back to
return the data:

client	---- SELECT requuest ---> server
	<--- tuple 1 request ----	/* these are child RP calls */
	--- tuple 1 response --->
	<--- tuple 2 request ----	/* these are child RP calls */
	--- tuple 2 response --->
	<--- tuple N request ----	/* these are child RP calls */
	--- tuple N response --->
	<--- SELECT response ----

What is RDA doing with RPCs?  Is ROSE in or out?

--RPCs are probably useful for some things.  However emulating distributed 
--databases isn't one of them.  RPCs are NOT distributed databases and shouldn't
--be sold or interpeted as such. 
-Yes and 'C' compilers aren't distributed databases, good point :-(.

C'mon give him a break. Believe it or not there are people out there
touting RPCs as the 'only way to do distributed database.' Dave was
trying to make a point. Noone claims that a c compiler is a any kind
of a database. MUMPS, however, is a different story :->

-nico@unify

oh, now I understand.  Gee, and I thought that we were going to keep
cross-vendor slander out of comp.databases.
-- 
- bob
;-----------------------------------------------------------------
; Bob Pasker, San Francisco, CA	 	| rbp@well.sf.ca.us
; +1 415-695-8741			| {apple|pacbell}!well!rbp