The diagram #fn78#1575> shows the sequence of events that form a
ROS exchange between two hosts A and B:
#figure1576#
Figure: Remote Operations Exchange
-
ROS exchanges must go through a connection phase, but
this is not defined in terms of OPDU. instead
appropriate mappings are made into the underlying
services connection events to pass the application
specific information that identifies the communicating
processes. -Each application must define this itself
but X/400 shows two such mappings into Session and RTS
services.
-
During Execution phase remote requests are made in the
Invoke OPDU, each being marked by a unique Invoke-ID
which identifies that specific invokation from all
others outstanding. -Although many processes are fully
synchronous and cannot support multipl outstanding
requests ROS allows for asynchronous operation.
-
Valid returns are replied in the ReturnResult OPDU,
recognized errors detected in the remote process return
in ReturnError OPDU.
-
ROS-level problems are flagged by the Reject OPDU which
encodes the ROS level failure. -recovery is not defined
in the ROS protocol.
-
There is no need for ROS requests to be one-
directional. suitable token management can be used in
the underlying layer to control direction in
synchronous mode, asynchronous processes can in theory
be written to handle requests in either direction: in
other words, the initiator of the connection does not
have to be the only process issuing Invoke requests.
-
ROS requests do not have to generate responses. -It is
possible to make valid invokations and ignore the
result of the request if your ROS definition permits
-
At the end of the exchange a disconnection phase is
used, which again does not map into OPDU, but uses
underlying facilities.