From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,TO_NO_BRKTS_PCNT
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 8 Apr 93 02:05:07 GMT
From: emery@mitre-bedford.arpa  (David Emery)
Subject: Re: Looking for experience with Ada/RPCs
Message-ID: <EMERY.93Apr7210508@dr_no.mitre.org>
List-Id: <comp.lang.ada>

We recently implemented a client-server application in Ada using the
Sun/ONC RPC mechanism, along with other Open Systems components.  We
needed 5 lines of C to work around a compiler bug; otherwise the
entire application (26k semicolons) was written in Ada, including Ada
bindings to ONC RPC and XVT.  The entire application was developed in
8 weeks by 5 software engineers plus a human factors person working
half-time. 

No "gyrations" were required at all.  There are some standard issues
in doing interfaces to C (see my Tri-Ada 90 paper for a discussion of
Ada to C interface techniques), which were required to pass data to
the RPC and XDR C Libraries.  For instance, we used xdr_wrapstring()
to pass Ada strings by copying the string into a local, appending null
to the end, and passing the address of the first element of this
string and the length of the string to the C routine.  For arrays, our
interface provides a COUNT routine and a routine that returns the
actual array.  We use TCP connection protocol (rather than UDP
connectionless protocol) to pass the arrays.  On the client side, the
client calls COUNT, declares/allocates an array object of length
COUNT, and then calls the RPC routine that returns the complete array.

The biggest shortcoming was that we were unable to use any of the
commercial RPC generators as they interpret and produce C.  Today we
talked to a company with an RPC generator tool that might be "fooled"
in such a way that we could generate much (but not all) of the client
and server stubs and XDR routines.   (The generated code would be C,
but the data would be Ada.  Part of the hand-coding would be calls to
the C stubs generated by the tool.)

We wrote a lot of code (about 20% more than we would have if we used C
and an RPC generator), but Ada was a major contributor in keeping
things consistent.  We understand that coding more than 20 RPCs is
considered to be 'hard', yet we had one person generate about 25 RPCs,
using all 'hand-generated' code in about 6 weeks.  And, this was a
person with no prior background in RPC programming.  After we worked
out a few bugs in our protocol, it got boring.  One of the things we
worked out was how to trap exceptions on the server side, transmit
them across the RPC, and then reraise them on the client side.  

We plan to get public release on a technical report describing our
application, including our techniques for coding RPC's.  We have also
submitted a "experience" session (or half-day tutorial) for Tri-Ada 93
where we will go over the entire application in detail, including the
client-server architecture of our system, and why we chose to split
the application as we did, our use of the XVT product and the Ada
Binding we developed to XVT, our binding and coding techniques for ONC
RPC, and our use of Embedded SQL from Ada.  We are starting a port of
the client to a 386 PC running DOS, which should be finished by
Tri-Ada (in time to discuss the portability of our software, including
the RPC interface.)

				dave