remote procedure (Z.100)

Concrete graphical grammar

A client process may call a procedure defined in another process, by a request to the server process through a remote procedure call of a procedure in the server process.

<remote procedure call area> ::=
<procedure call symbol> contains <remote procedure call body>

<remote procedure input area>::=
<input symbol> contains
{ [ <virtuality> ] procedure; <remote procedure identifier list> }
is followed by { [<enabling condition area>] <transition area> }

<remote procedure save area> ::=
<save symbol> contains
{[ <virtuality> ]
procedure <remote procedure identifier list> <end> }

<remote procedure call body> ::=
<remote procedure identifier> [<actual parameters>]
[ to <destination> ]

<imported procedure specification> ::=
imported procedure <remote procedure identifier> <end>
[<procedure signature> <end>]

<remote procedure identifier list> ::=
<remote procedure identifier> {,<remote procedure identifier>}*

The signature of <imported procedure specification> must be the same signature as the signature in the <remote procedure definition> identified by <remote procedure identifier>.

The <remote procedure identifier> following as in an exported procedure definition must denote a <remote procedure definition> with the same signature as the exported procedure. In an exported procedure definition with no as clause, the name of the exported procedure is implied and the <remote procedure definition> in the nearest surrounding scope with same name is implied.

For each <remote procedure call> there must exist an <imported procedure specification> of the remote procedure identifier in an enclosing process type, process definition, service type or service definition having the same <remote procedure name>.

For each imported procedure specification in a process there must exist at least one exported procedure in some process.

Semantics

A <remote procedure definition> introduces the name and signature for imported and exported procedures.

An exported procedure is a procedure with the keyword exported.

The association between an <imported procedure specification> and an exported procedure is established by both referring to the same <remote procedure definition>.

A remote procedure call by a requesting process causes the requesting process to wait until the server process has executed the procedure. Signals sent to the requesting process while waiting are saved. The server process will execute the requested procedure in the next state where save of the procedure is not specified, subject to the normal ordering of reception of signals. If neither <remote procedure save> nor <remote procedure input transition> is specified for a state, an implicit transition consisting of the procedure call only and leading back to the same state is added. If a <remote procedure input transition> is specified for a state, an implicit transition consisting of the procedure call followed by <transition> is added. If a <remote procedure save> is specified for a state, an implicit save of the signal for the requested procedure is added.

Model

Remote procedure call is modelled by an exchange of signals. These signals are implicit and are conveyed on implicit channels and signal routes. The requesting process sends a signal containing the actual parameters of the procedure call, to the server process and waits for the reply. In response to this signal, the server process executes the corresponding remote procedure, sends a signal back to the requesting process with the value of all in/out-parameters, and then executes the transition.

There are two implicit <signal definition>s for each <remote procedure definition>s in a <system definition>. The <signal name>s in these <signal definition>s are denoted by pCALL and pREPLY respectively, where p is uniquely determined. The signals are defined in the same scope unit as the <remote procedure definition>.

a) Requesting process

The <remote procedure call> 'call; Proc(apar) to; destination' where apar is the list of actual parameters, is transformed to the following, where the to clause is omitted, if destination is not given:

output pCALL(apar) to destination;
Wait in state pWAITe, saving all other signals;
input pREPLY (aINOUTpar);

where aINOUTpar is the modified list of actual in;/out; -parameters.

In all other states, pREPLY is saved.

b) Server process

There is a declaration of an implicit variable, called ivar of sort PId.

To all <state>s with a remote procedure input transition the following <input part> is added:

input pCALL(fpar);
ivar := sender;
call Proc(fpar);
output pREPLY (fINOUTpar) to ivar;

<transition>

where fpar and fINOUTpar are analogous to apar and aINOUT above.

To all <state>s, with a remote procedure save, the following <save part> is added:

save pCALL;

To all other <state>s including implicit states, the following <input part> is added:

input pCALL(fpar);
ivar := sender;
call Proc(fpar);
output pREPLY (fINOUTpar) to ivar;
/* next state the same */

A <remote procedure input transition> or <remote procedure input area> which contains <virtuality> is called a virtual remote procedure input transition. A <remote procedure save> or <remote procedure save area> which contains <virtuality> is called a virtual remote procedure save.

NOTE - there is a possibility of deadlock using the remote procedure construct, especially if no <destination> is given, or if <destination> does not denote a <PId expression> of a process which is guarantied by the specification to exist at the time of receiving the pCALL signal.