ISO/IEC 9072-1:1989

INTERNATIONAL lSO/lEC
9072-I
STANDARD
First edition
1989-l l-15
Information processing systems - Text
communication - Remote Operations -
Part 1 :
Model, notation and service definition
S yst&mes de traitemen t de l’information - Communication de texte - Opbrations
;i distance -
Partie I : Modkle, notation et d6 finition du service
Reference number
ISO/IEC 9072-l : 1989 (E)
ISOAEC 9072-l: 1989 (E)
Page
Contents
...
ill
Foreword .
iv
Introduction .
1 Scope .
. . . . .*.*.*.
9 Y Normative references
3 Definitions .
4 Abbreviations .
5 Conventions .
.....................................
6 Remote Operations Model
..............................
7 Overview of notation and service
........ 9
8 Relationship with other ASEs and lower layer services
..................................
9 Remote Operations notation
............................................
10 Service definition
Mapping of notation on service .
12 Sequencing information .
Annexes
A Notation supporting the specification of
. . . . . . . . 26
Application-service-elemnts and application-contexts
Guidelines for application protocol designers
B
on the use of ROSE . . . . . . . . . . . . . . . . . .*.
0 ISO/IEC 1989
All rights reserved.- No part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in
writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
lSO/IEC 90724 : 1989 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) together form a system for worldwide standardization as
a whole. National bodies that are members of IS0 or IEC participate in the develop-
ment of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. IS0 and IEC
technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with IS0 and IEC, also
take part in the work.
In the field of information technology, IS0 and IEC have established a joint technical
committee, ISO/IEC JTC 1. Draft International Standards adopted by the joint
technical committee are circulated to national bodies for approval before their accep-
tance as International Standards. They are approved in accordance with procedures re-
quiring at least 75 % approval by the national bodies voting.
International Standard ISO/IEC 9072-l was prepared by Joint Technical
Committee ISO/IEC JTC 1, information technology.
. . .
III
ISOAEC 9072-l : 1989 (E)
Introduction
This part of ISO/IEC 9072 defines a notation and the services provided by an
application-service-element - the Remote Operations Service Element (ROSE)
- to support interactive applications in a distributed open systems
environment. This part of IS0 9072 is one of a set of International Standards
defining sets of application-service-elements commonly used by a number of
applications.
Interactions between entities of a distributed application are modeled as
Remote Operations, and defined using a Remote Operations notation. A
Remote Operation is requested by one entity; the other entity attempts to
perform the Remote Operation and then reports the outcome of the attempt.
Remote Operations are supported by the ROSE.
This part of ISO/IEC 9072 is technically aligned with CCITT
Recommendation X.219.
ISO/IEC9072-1: 1989(E)
INTERNATIONAL STANDARD
Information processing systems -Text communication -
Remote Operations - Part 1:
Model, notation and service definition
IS0 8650: 1988, Information processing systems -
1 scope
Open Systems Interconnection - Protocol
specification for the Association Control Service
This part of ISO/IEC 9072 defines a Remote
Element.
Operation (RO-) notation for defining the services
provided to interactive applications. This part of
IS0 8822: 1988, rnformation processing systems -
ISO/IEC 9072 also defines the services provided
Open Systems interconnection - Connection
by the Remote Operation Service Element (ROSE)
oriented presentation service definition.
services. The ROSE services are provided by the
IS0 8824: 1987, Information processing systems -
use of the ROSE protocol (part 2 of ISO/IEC 9072)
Open Systems Interconnection - Specification of
in conjunction with the Association Control
Abstract Syntax Notation One (ASN.1).
Service Element (ACSE) services (IS0 8649) and
the ACSE protocol (IS0 8650), optionally the
IS0 8825: 1987, Information processing systems -
Reliable Transfer Service Element (RTSE)
Open Systems Interconnection - Specification of
services (ISO/IEC 9066-l) and the RTSE protocol
basic encoding rules for Abstract Syntax Notation
(ISO/IEC 9066-2), and the presentation-service
One (ASN.1).
(IS0 8822).
ISO/IEC 9066-l: 1989, Information processing
systems - Text communication - Reliable Transfer
No requirement is made for conformance to this
- Part 1: Model and service definition.
part of ISO/IEC 9072.
ISO/IEC 9066-2: 1989, Information processing
Normative references
systems - Text communica.tion - Reliable Transfer
- Part 2: Protocol specificatton.
The following standards contain provisions which,
through reference in this text, constitute ISO/IEC 9072-2: 1989, Information processing
provisions of this part of ISO/IEC 9072. At the systems - Text communication - Remote
time of publication, the editions were valid. All Operations -Part 2: Protocol specification.
Standards are subject to revision, and parties to
agreement based on this part of ISO/IEC 9072 are 3 Definitions
encouraged to investigate the possibility of
applying the most recent editions of the standards 31 . Reference Model definitions
listed below. Members of IS0 and IEC maintain
This part of ISO/IEC 9072 is based on the concepts
Registers of currently valid International
developed in IS0 7498 and makes use of the
Standards.
following terms defined in it:
IS0 7498: 1984, Information processing systems -
Application Layer;
a)
Open Systems Interconnection - Basic Reference
b) application-process;
Model.
application-entity;
ISO/TR 8509: 1987, Information processing 4
systems - Open Systems interconnection - Service
d) application-service-element;
Conventions.
application-protocol-data-unit;
e>
IS0 8649: 1988, Information processing systems -
application-protocol-control-information;
Open Systems Interconnection - Service definition f)
for the Association Control Service Element.
Presentation Layer;
g)
ISOAEC 9072-l : 1989 (E)
presentation-service; 35 . Reliable Transfer definitions
h)
presentation-connection; This part of ISO/IEC 9072 makes use of the
i>
. following terms defined in ISO/IEC 9066-l:
session-service;
J)
Reliable Transfer Service Element
a)
k) session-connection
transfer syntax; and 36 . ROSE definitions
1)
user-element.
m)
For the purpose of this part of ISO/IEC 9072 the
following definitions apply:
3.2 Service conventions definitions
3.6.1 association-initiating-application-
This part of ISO/IEC 9072 makes use of the
entity; association-initiator: The application-
following terms defined in ISO/TR 8509:
entity that initiates the application-association.
service-provider;
a)
service-user; 3.6.2 association-responding-application-
b)
entity; association-responder: The application-
confirmed service;
entity that responds to the initiation of an
non-confirmed service; application-association by another AE.
d)
provider-initiated service;
3.6.3 invoking-application-entity; invoker:
service-primitive; primitive; The application-entity that invokes the Remote
fl
Operation.
request (primitive);
g)
indication (primitive); 3.6.4 performing-application-entity;
h)
performer: The application-entity that performs
response (primitive); and
i)
a Remote Operation invoked by the other
.
confirm (primitive). application-entity.
J)
Presentation service definitions 3.6.5 requestor: The part of an application-
33 .
entity that issues a request primitive for a
This part of ISO/IEC 9072 makes use of the
particular ROSE service.
following terms defined in IS0 8822:
3.6.6 acceptor: The part of an application-
a) abstract syntax;
entity that receives the indication primitive for a
abstract syntax name;
b)
particular ROSE service.
transfer syntax name;
C)
3.6.7 linked-operations: A set of operat’ions
presentation context.
d)
formed by one parent-operation and one or more
child-operations.
. Association control definitions
This part of ISO/IEC 9072 makes use of the 3.6.8 parent-operation: An operation during
following terms defined in IS0 8649: the execution of which the performer may invoke
linked child-operations to be performed by the
application-associ .ation; association;
a)
invoker of the parent-operation.
application context;
b)
3.6.9 child-operation: An operation which
Association Control Service Element.
c)
might be invoked by the performer of the linked
parent-operation during the execution of the
parent-operation, and which is performed by the
invoker of the parent-operation.

ISO/lEC 90724 : 1989 (E)
3.6.10 Remote Operations: services (Remote Operations) available to the user
element in RO-notation.
(1) A concept and notation supporting the
specification of interactive communication 4 Abbreviations
between application-entities. This includes the
Remote Operation Service Element and the AE application-entity
mapping of the notation onto the service
ACSE Association Control Service
primitives of used application-service-elements.
Element
(2) The set of b’ in d -operations, unbind-operations ASE application-service-element
and operations.
APDU application-protocol-data-unit
3.6.11 RO-notation: The notation used for the OS1 Open Systems Interconnection
specification of Remote Operations, defined in this
RO (or ROS) Remote Operations
part of ISO/IEC 90’72.
ROSE Remote Operations Service
3.6.12 ACSE-user: The application-specific Element
function that performs the mapping of the bind-
RT (or RTS) Reliable Transfer
operation and unbind-operation of the RO-
Reliable Transfer Service Element
notation onto ACSE. RTSE
A l
3.6.13 Remote Operation Service Element: 5 Conventions
The application-service-element defined in this
part of ISO/IEC 9072. This part of ISO/IEC 9072 defines services for the
ROSE following the descriptive conventions
3.6.14 ROSE-provider: The provider of the defined in ISO/TR 8509. In clause 10, the
Remote Operations Service Element set-vices. definition of each ROSE service includes a table
that lists the parameters of its primitives. For a
3.6.15 ROSE-user: The application-specific given primitive, the presence of each parameter is
function that performs the mapping of the described by one of the following values.
operations and errors of the RO-notation onto
blank not applicable
ROSE.
NI mandatory
3.6.16 RTSE-user: The application-specific
U user option
function that performs the mapping of the bind-
operation and unbind-operation of the RO- C conditional
notation onto RTSE.
presence is an ROSE service-provider
option
3.6.1’7 operation-interface: The interface
within an application entity between the user
In addition, the notation (=) indicates that a
element and the application service elements,
parameter value is semantically equal to the
defined as a set of application service element
value to its left in the table.
ISOAEC 9072-l : 1989 (E)
6 Remote Operations Model reply is returned if the operation is
unsuccessful);
In the OS1 environment, communication between
- or not at all (neither a result nor an error
application processes is represented in terms of
reply is returned, whether the operation
communication between a pair of application
was successful or not).
entities (AEs) using the presentation service.
Communication between some application-
Operations may also be classified according to two
entities are inherently interactive. Typically, one
possible operation modes: synchronous, in which
entity requests that a particular operation be
the invoker requires a reply from the performer
performed; the other entity attempts to perform
before invoking another operation; and
the operation and then reports the outcome of the
asynchronous, in which the invoker may continue
attempt. This clause introduces the concept of
to invoke further operations without awaiting a
Remote Operations as a vehicle for supporting
reply.
interactive applications.
The following Operation Classes are defined:
The generic structure of an operation is an
elementary request/reply interaction. Operations Operation Class 1: Synchronous, reporting
are carried out within the context of an success or failure (result or error).
application-association.
Operation Class 2: Asynchronous, reporting
success or failure (result or error).
Figure 1 models this view.
Operation Class 3: Asynchronous, reporting
Operations invoked by one AE (the invoker) are failure (error) only, if any.
performed by the other AE (the performer).
Operation Class 4: Asynchronous, reporting
Operations may be classified according to whether
success (result) only.
the performer of an operation is expected to report
its outcome: Operation Class 5: Asynchronous, outcome
not reported.
- in case of success or failure (a result reply
is returned if the operation is successful,
The Operation Class of each operation has to be
an error reply is returned if the operation
agreed between application entities (e.g. in an
is unsuccessful);
Application Protocol International Standard).
- in case of failure only (no reply is returned
if the operation is successful, an error In some cases it is useful to group operations into
reply is returned if the operation is a set of linked-operations which is formed by one
unsuccessful); parent-operation and one or more child-
operations. The performer of the parent-operation
- in case of success only (a result reply is
may invoke none, one, or more child-operations
returned if the operation is successful, no
I
application-association
I
request
I
I
AE AE
I
I
I
i
I
I
reply
I
Figure 1 - Remote Operations Model

ISO/IEC 9072-l : 1989 (E)
during the execution of the parent-operation. The
Linked-operations require Association Class 3.
invoker of the parent-operation is the performer of
the child-operations. A child-operation may be a
The Association Class has to be agreed between
parent-operation of another set of linked-
application-entities (e.g. in an Application
operations in a recursive manner. Figure 2 models
Protocol International Standard).
this concept.
The functionality of an AE is factored into one
An application-association defines the
user-element and a set of application-service-
relationship between a pair of AEs, and is formed elements (ASEs). Each ASE may itself be factored
by the exchange of application-protocol-control- into a set of (more primitive) ASEs. The
information through the use of presentation-
interaction between AEs is described in terms of
services. The AE that initiates an application- their use of ASEs.
association is called the association-initiating AE,
or the association-initiator, while the AE that
The specific combination of a user-element and
responds to the initiation of an application- the set of ASEs which comprise an AE defines the
association by another AE is called the applicat,ion-context.
association-responding AE, or the association-
responder. Only the association-initiating AE Figure 3 illustrates an example of an
may release an established application- application-context involving the Remote
association. Operations Service Element (ROSE). Note that
this figure is not meant to imply that the
Application-associations are classified by which
application is symmetric. Interactive applications
application-entity is allowed to invoke operations: are often inherently asymmetric, that is, either
one or both AEs may be permitted to invoke
Association Class 1: Only the association-
operations, and the operations that either AE may
initiating application entity can invoke
invoke may be different. The rules governing
operations.
which AE may invoke operations, and which
Association Class 2:
Onlv the association- operations an AE may invoke, is defined using the
responding application e*ntity can invoke
RO-notation in an Application Protocol
operations. International Standard, and determines the
application-context.
Association Class 3: Both the association-
initiating and the association-responding
The set of ASEs available to the user element of
application entities can invoke operations.
the AE at the operation-interface is defined using
r----------------I---------------l
I
application-association
I
invocation of
I
- parent-operation
I
AE
I
II
I
invocation of
-
I
execution of
child-operation
I
‘i
0 I
parent-
I
I
operation
l
I
I
invocation of
I
I
child-operation
JJ
I
performer of linked
performer of
I
child-operations
parent-operation
I
I I
Figure 2 - Linked-operations
ISOAEC 9072-I : 1989 (E)
the Remote Operations (RO-) notation. The RO-
Remote Operations Service Element (ROSE)
notation is based on the macro concept defined in
defined in this part of ISO/IEC 9072.
IS0 8824. The complexity of a particular set of
ASEs is dependent upon the needs of the
An application-specific function performs the
application, and is not limited by the Remote
mapping of the operations available to the
Operations concept.
user-element onto either the ACSE services, or
the RTSE services; and the ROSE services. The
An important characteristic of Remote Operations
mapping is defined in this part of ISO/IEC 9072.
is that they provide applications with
The function that performs the mapping of the
independence from OS1 communication services. t\
operations onto the ACSE services, or the RTSE
Since the notation is based on established object-
services, and the ROSE services is said to be the
oriented programming principles, automatic tools
user of ACSE, RTSE and ROSE, or the ACSE-
can be developed to bind Remote Operations into
user, the RTSE-user, and the ROSE-user.
the execution environment of applications.
in the
If the RTSE is included
The ASEs available to the user-element require
application-context, the mapping function is an
communication over an application-association.
RTSE-user and a ROSE-user, the ROSE is an
The control of that application-association
RTSE-user, the RTSE is an ACSE-user and a
(establishment, release, abort) is performed either
presentation service-user, and the ACSE is a
by the Association Control Service Element
presentation service-user.
(ACSE) defined in IS0 8649, or the Reliable
Transfer Service Element defined in ISO/IEC
If the RTSE is excluded from the
9066-l and the Association Control Service
application-context, the mapping function is an
Element (ACSE). Communication over the
ACSE-user and a ROSE-user, the ROSE is a
application-association is performed by the
presentation service-user, and the ACSE is a
presentation service-user.
Application
Layer
application-entity application-entity
operation-interface user-element user-element
(defined as a set of
i
I
ASEs using the
application-service-element application-service-element
RO-notation)
and mapping onto ROSE, Application Protocol and mapping onto ROSE,
and eventually onto over and eventually onto
ACSE or RTSE application-association ACSE or RTSE
-~~~~~
------------------------------------.,--- --------------------- ------w---w- ----------‘----------~-----------------
Presentation
presentation-connection
Layer
Figure 3 - Model of an application context involving Remote Operations

lSO/IEC 9072-I : 1989 (E)
7 Overview of notation and service The type notation of the OPERATION macro
enables the specification of an operation and user
Notation Overview data types to be exchanged for a request and a
71 .
positive reply. In addition , the type notation
This part of ISO/IEC 9072 defines the RO-notation
enables the specification of a list of valid negative
for the specification of an application-context and
reply situations. If the operation is a parent-
the related abstract syntax component of the
operation, the type notation enables the
presentation context.
specification of the list of linked child-operations.
The value notation of the OPERATION macro
The functionality of an application-context is
enables the specification of the identifier of an
provided to the user-element by means of Remote
operation.
Operations and errors which form the
operation-interface.
The type notation of the ERROR macro enables
the specification of user data types to be
The following types of Remote Operations form an
exchanged in a negative reply situation. The
operation interface:
value notation of the ERROR macro enables the
- a bind-operation to establish an specification of the identifier of an error.
application-association;
Additional macros supporting the notation for the
- a set of operations and, for each
specification of application-service-elements and
operation, a list of error (negative
application contexts are defined in annex A.
reply) situations;
- an unbind-operation to release an 7.2 Service overview
lication-association
aPP
This part of ISO/IEC 9072 defines the following
ROSE services:
The abstract syntax notation of IS0 8824 is used
for the definition of the following macros: a) RO-INVOKE
a) BIND; b) RO-RESULT
b) UNBIND; c) RO-ERROR
c) OPER,4TIOX; and d) RO-REJECT-U
d) ERROR. e) RO-REJECT-P
These macros vide bot h a type notation and a The RO-INVOKE service enables an invoking AE
Pro
value notation for Remote Operations and errors. to request an operation to be performed by the
performing AE.
The type notation of the BIND macro enables the
specification of a bind-operation type and the The RO-RESULT service enables the performing
types for user data values (if any) to be exchanged AE to return the positive reply of a successfully
in the establishment phase of an application- performed operation to the invoking AE.
association. The value notation of the BIXD
macro enables the specification of user data The RO-ERROR service enables the performing
values (if any) to be exchanged in the AE to return the negative reply of an
establishment phase of an application-association. unsuccessfully performed operation to the
The type notation of the UNBIND macro enables invoking AE.
the specification of an unbind-operation type and
types for user data values (if any) to be exchanged The RO-REJECT-U service enables one AE to
in the release phase of an application-association. reject the request or reply of the other AE if the
The value notation of the UNBIND macro enables ROSE-user has detected a problem.
the specification of user data values (if any) to be
exchanged in the release phase of an application- The RO-REJECT-P service enables the ROSE-
association. user to be informed about a problem detected by
the ROSE-provider.
ISO/IEC 90724 : 1989 (E)
73 . Mapping of notation on to services syntax. If multiple named abstract syntaxes are
defined for operations and errors, the ROSE
Note that the function that performs the mapping
APDUs are included in each named abstract
of the OPERATION macros and ERROR macros of
syntax.
the RO-notation onto ROSE services is said to be
the ROSE-user. While the function that performs
If a named abstract syntax specifies a bind-
the mapping of the BIND and UNBIND macros of
operation, the APDUs specified by the value
the RO-notation onto ACSE services or RTSE
notation of the BIND macro are included in that
services respectively is said to be the ACSE-user
named abstract syntax. If the RTSE is included in
or RTSE-user respectively.
the application context, the APDUs for the bind-
operation share a single named abstract syntax
The specification of the mapping of the RO-
with the RTSE APDUs defined in ISOfIEC 9066-2.
notation onto the used services of ACSE, RTSE,
and ROSE is given in clause 11. Therefore
If a named abstract syntax specifies an unbind-
International Standards using the RO-notation
operation, the APDUs specified by the value
for the protocol specification need not to specify
notation of the UNBIND macro are included in
the mapping onto these used services.
that named abstract svntax.
e
8 Relationship with other ASEs
The APDUs resulting from the specification of a
and lower layer services
bind-operation, an unbind-operation, operations
and errors and the RTSE APDUs may share a
81 . Other application-service-elements
single named abstract syntax.
The ROSE is intended to be used with other ASEs
in order to support specific interactive Presentation-service
82 .
information processing tasks. Therefore it is
If an application context including RTSE and
expected that the ROSE will be included in a large
ROSE is defined, ROSE services do not use the
number of application-context specifications.
presentation-service.
The collection of the ROSE and other ASEs
If an application context including ROSE but
included in an application context are required t,o
excluding RTSE is defined, the ROSE services
use t,he facilities of the presentation-service in a
require access to the P-DATA service and require
co-ordinated manner among themselves.
the use of the duplex functional unit of the
presentation-service. The ROSE services neither
The ROSE requires an existing application-
use, nor constrain the use of, any other
association controlled by ACSE.
presentation service.
For some application cont,ext specifications a
A named abstract syntax associated with a
Reliable Transfer Service Element (RTSE) is
compatible transfer syntax (negotiated by the
included.
Presentation Layer) constitutes a presentation
context.
An ROSE-user protocol specification uses the RO-
notation. It defines one or more abstract syntaxes
The object identifier value Cjoint-iso-ccitt asnl(l) basic-
and provides unique abstract syntax names of
encoding(l)} specified in IS0 8825 may be used as a
type object identifier for each abstract syntax.
transfer syntax name. In this case the ROSE-user
protocol specification need not to name and specify
If a named abstract syntax specifies operations
a transfer syntax.
and errors, the ROSE APDUs defined in ISO/IEC
9072-2 are included in that named abstract
ISOAEC 90724 : 1989 (E)
9 Remote Operations notation
to it are specified. If the bind-operation reports
failure, the keyword BIND-ERROR and the type of the
91 . General
error-information it reports and the reference
name optionally assigned to it are specified.
The notation used in this part of ISO/IEC 9072 is
defined as follows:
The value notation for a bind-operation is either
- the data syntax notation and macro
an argument value, or a result value or an error
notation are defined in IS0 8824;
value. The value notation for an argument value
(if any) is the key word ARGUMENT followed by a
- the Remote Operation macros are defined
value of the argument type. The value notation for
in 9.2 of this part of ISO/IEC 9072.
a result value (if any) is the key work RESULT
followed by a value of the result type. The value
A bind-operation defines where an object binding
notation for an error value (if any) is the key word
(establishment of an application-association)
ERROR followed by a value of the error type.
begins. If such a binding is established, operations
-
may be invoked. An unbind-operation defines
9.3 Specification of unbind-operations
where an object binding is released.
A single data value, the argument of the unbind-
An interactive protocol is specified using the
operation, may accompany the request to release
Remote Operation and error data types. This
the application-association. Some unbind-
clause defines those types. It also explains the
operations report their outcome, whether success
notational definitions of a particular Remote
(i-e the normal outcome) or failure (i.e. the
Operation, and of the particular errors it can
exceptional outcome). Other unbind-operations
report. The notation is defined by means of the
report their outcome only if they fail, and still
macro facility defined in IS0 8824. This macro
others never at all. A single data value, the result
definition allows a generalized specification of the
of the unbind-operation, or a single data value,
mapping onto various execution environments.
the unbind-error of the unbind-operation, may
accompany the response.
The macros enabling the specification of bind-
operations, unbind-operations, operations and
The notation for an unbind-operation type is the
errors are listed in figure 4.
keyword UNBIND, optionally followed by the
keyword ARGUMENT and the type of the unbind-
92 . Specification of bind-operations
operation’s argument, the reference name
optionally assigned to it, and the nature of the
A single data value, the argument of the bind-
unbind-operation’s outcome reporting (if any). If
operation, may accompany the request to
the unbind-operation reports success, the
establish the application-association. Some bind-
keyword RESULT and the type of its result and the
operations report their outcome, whether success
reference name optionally assigned to it are
(i.e the normal outcome) or failure (i.e. the
specified. If the Unbind-operation reports failure,
exceptional outcome). Other bind-operations
the keyword UNBIND-ERROR and the type of the
report their outcome only if they fail, and still
error-information it reports and the reference
others never at all. A single data value, the result
name optionally assigned to it are specified.
of the bind-operation, may accompany the positive
response. A single data value, the bind-error of
The value notation for an unbind-operation is
the bind-operation, may accompany the negative
either an argument value, or a result value or an
response.
error value. The value notation for an argument
value (if any) is the keyword ARGUMENT followed by
The notation for a bind-operation type is the
a value of the argument type. The value notation
keyword BIND, optionally followed by the keyword
for a result value (if any) is the keyword RESULT
ARGUMENT and the type of the bind-operation’s
followed by a value of the result type. The value
argument, the reference name optionally assigned
notation for an error value (if any) is the keyword
to it, and the nature of the operation’s outcome
ERROR followed by a value of the error type.
reporting (if any). If the bind-operation reports
success, the keyword RESULT and the type of its
result and the reference name optionally assigned
ISOAEC 90724 : 1989 (E)
Remote-Operation-Notation ( joint-iso-ccitt remote-operations(4) notation (0))
DEFINITIONS :: =
BEGIN
EXPORTS BIND, UNBIND, OPERATION, ERROR;
-a
macro definition for bind-operations
BIND MACRO :: =
BEGIN
l * -
. . -
TYPE NOTATION Argument Result Error
. .
. . =
VALUE NOTATION Argument-value 1 Result-value 1 Error-value
Argument :: = empty 1 “ARGUMENT” Name type (Argument-type)
-- Expects any ASN.1 type and assigns it to the variable Argument
-- type
. .
. .
Result = empty 1 “RESULT” Name type (Result-type)
-- Expects any ASN .I type and assigns it to the variable Result-type
. .
. .
Error = empty ] “BIND-ERROR” Name type (Error-type)
-- Expects any AS.1 type and assigns it to the variable Error-type
. .
. . = empty) identifier
Name
Argument-value : : = empty I “ARGUMENT” value (Arg-value Argument-type)
-- Expects a value for the type in Argument-type, and assigns it to the
Be
variable Arg-value

-- Returns the final value as explicitly tagged type
empty f “RESULT” value (Res-value Result-type)
Result-value :: =
-- Expects a value for the type in Result-type and assigns it to the
--
variable Res-value

-- Returns the final value as explicitly tagged type
Error-value :: = empty I “ERROR” value (Err-value Error-type)
--Expects a value for the type in Error-type, and assigns it to the
--
variable Err-va.lue

-- Returns the final value as explicitly tagged type
END
-a
Remote Operations Notation continued
Figure 4 (Part 1 of 3) - Formal definition of Remote Operations data types
ISOAEC 9072-I : 1989 (E)
-- Remote Operations Notation continued
**
macro definition for unbind-operations
UNBIND MACRO :: =
BEGIN
TYPE NOTATION :: = Argument Result Errors
VALUE NOTATION : : = Argument-value 1 Result-value 1 Error-value
Argument :: =
empty 1 “ARGUMENT” Name type (Argument-type)
-- Expects any ASN.1 type and assigns it to the va.riable Argument-
-- type
. .
. .
Result = empty 1 “RESULT” Name type (Result-type)
-- Expects any ASN .l type and assigns it to the variable Result-type
. .
Error . .
= empty 1 “UNBIND-ERROR” Name type (Error-type)
-- Expects any A&V.1 type and assigns it to the variable Error-type
l = a
. . - empty 1 identifier
Name
Argument-value : : = empty 1 “ARGUMENT” value (Arg-value Argument-type)
-- Expects a value for the type in Argument-type, and assigns it to the
**
variable &-g-value

-- Returns the final value as explicitly tagged type
Result-value :: = empty 1 “RESULT” value (Res-value Result-type)
--Expects a value for the type in Result-type and assigns it to the
**
variable Res-value

-- Returns the final value as explicitly tagged type
Error-value :: = empty I “ERROR” value (Err-value Error-type)
-- Expects a value for the type in Error-type, and assigns it to the
**
variable Err-value

-- Returns the final value as explicitly tagged type
END
-- Remote Operations Notation continued
Figure 4 (Part 2 of 3) - Formal definition of Remote Operations data types
ISOAEC 9072-l : 1989 (E)
9.4 Specification of operations local values. The use of global values is not
restricted.
A data value of type operation represents the
identifier for an operation that a ROSE-user in
9.5 Specification of errors
one open system may request to be performed by a
peer ROSE-user in another open system. A single A data value of type error represents the identifier
data value, the argument, of the operation, may for an exception condition that a ROSE-user in
accompany the request. Some operations report one open system may report to a peer ROSE-user
their outcome, whether success (i.e the normal in another open system, where the exception
outcome) or failure (i.e. the exceptional outcome). condition is reporting an exceptional outcome of a
Other operations report their outcome only if they previously requested operation. A single data
fail, and still others never at all. A single data value, the parameter of the error, may accompany
value, the result of the operation, accompanies a the report.
report of success; a report of failure identifies the
exceptional condition that was encountered. The notation for an error type is the keyword
ERROR, optionally followed by the keyword
The notation for an operation type is the keyword PARAMETER and the type of the error’s parameter
OPERATION, optionally followed by the keyword and the reference name optionally assigned to it.
ARGUMENT and the type of the operation’s
argument, the reference name optionally assigned The notation for an error value is the error’s
to it, and the nature of the operation’s outcome identifier. If a locally unique identifier (local
reporting (if any). If the operation reports success, value) is sufficient, the identifier is of type INTEGER.
the keyword RESULT and optionally the type of its If a globally unique identifier (global value) is
result and the reference name optionally assigned required to allow the unique identification of
to it are specified. If the operation reports failure, errors used in several abstract syntaxes, the
the keyword ERRORS and the reference names of identifier is of type OBJECT IDENTIFIER.
the error values or error types it reports are
specified. If the operation is the parent-operation 96 . Export and import of operations and
of a set of linked-operations, the keyword LINKED- errors
OPERATIONS and the reference names of the linked
Operation values and error values have to be
child-operation values or child-operation types are
unique within a named abstract syntax. If
specified. The reference to error values or child-
operations and errors are specified in several
operation values is preferred, however the
ASN.1 modules and are imported to a module
references to types shall be used if the values are
specifying a specific named abstract syntax, one of
defined elsewhere (see 9.6).
the following rules apply:
The notation for an operation value is the If local values are used and exported, it is
a)
operation’s identifier. If a locally unique identifier in the responsibility of the designer of the
(local value) is sufficient, the identifier is of type importing module to ensure uniqueness.
INTEGER. If a globally unique identifier (global
A module may specify and export
b)
value) is required to allow the unique
operation types and error types. The
identification of operations used in several
operation values and error values are
abstract syntaxes, the identifier is of type OBJECT
assigned in the module importing the
IDENTIFIER.
types. A single value shall be assigned for
each operation type or error type.
Child-operations and errors referenced by a
specific operation shall share a single named If global values are assigned and exported,
abstract syntax (see 8.1) with that operation, if uniqueness is ensured.
the child-operations or errors are identified by
syntaxes might
However different named abstract
be used for conflicting local values.
ISOAEC 9072-I : 1989 (E)
-- Remote Operations Notation continued
-0
macro definition for operations
OPERATION MACRO :: =
BEGIN
TYPE NOTATION :: = Argument Result Errors LinkedOperations
VALUE NOTATION :: = value (VALUE CHOICE{
localValue INTEGER,
globalValue OBJECT IDENTIFIER})
. .
. .
Argument = “ARGUMENT” NamedType 1 empty
l = -
. . -
Result “RESULT”ResultType 1 empty
ResultType :: = NamedType 1 empty
. .
. . = “ERRORS” “(” ErrorNames “}” 1 empty
Errors
. .
. . = “LINKED” “(” LinkedOperationNames “}” 1 empty
LinkedOperations
. .
. . = ErrorList 1 empty
ErrorNames
. .
. . = Error 1 ErrorList “,” Error
E rrorList
n = -
. . - value ( ERROR) -- shall reference a.n error value
Error
shall reference an error type if no error value is specified
I type --
:: = OperationList j empty
LinkedOperationNames
. .
Opera tionlist . . = Operation ] Operationtist “,” Operation
. .
Operation . . = value (OPERATION ) -- shall reference a.n operation va.lue
shall reference an operation type if no operation value is
ItYPe --
-0
specified
. .
. . = identifier type ] type
NamedType
END
-0
macro definition for operations errors
ERROR MACRO :: =
BEGIN
TYPE NOTATION :: = Parameter
VALUE NOTATION :: = value (VALUE CHOICE{
INTEGER,
localValue
OBJECT IDENTIFIER})
globalValue
. .
Parameter . . = “PARAMETER *’ NamedType 1 empty
l * -
NamedType . . - identifier type I type
END
END -- end of Remote Operations Notation
Figure 4 (Part 3 of 3) - Formal definition of Remote Operations data types
ISOAEC 90724 : 1989 (E)
10 Service definition This parameter is the identifier of the operation to
be invoked. The value has to be agreed between
The ROSE services are listed in table 1. the ROSE-users. This parameter has to be
supplied by the requestor of the service.
Table 1 - ROSE services
Table 2 - RO-INVOKE parameters
Service
Type
Parameter name Ind
I
RO-INVOKE Non-confirmed
RO-RESULT Non-confirmed
M(=)
Operation-value M
RO-ERROR Non-confirmed
Operation-class U
RO-REJECT-U Non-confirmed
Argument u CC=)
RO-REJECT-P Provider-initiated
Invoke-ID M MC=)
Linked-ID U CC=)
Priority U
Identification of the named abstract syntax in use
is assumed for all ROSE services, however this is
a local matter and outside the scope of this part of
10.1.1.2 Operation-class
ISO/IEC 9072.
This parameter defines whether a synchronous or
an asynchronous reply is expected and the nature
10.1 RO-INVOKE service
of the expected reply, i.e. result and/or error or
The RO-INVOKE service is used by one ROSE-
none (see clause 6). This parameter has to be
user (the invoker) to cause the invocation of an
supplied by the requestor of the service. This
operation to be performed by the other ROSE-user
parameter is used solely to optimize the turn
(the performer). This service is an non-confirmed
management (see 8.1.1 of part 2 of ISO/IEC 9072).
service.
10.1.1.3 Argument
The related service structure consists of two
This parameter is the argument of the invoked
service-primitives, as illustrated in figure 5.
operation. The type has to be agreed between the
ROSE-users. This parameter has to be supplied by
ROSE-
ROSE-user the requestor of the service.
provider
10.1.1.4 Invoke-ID
RO-INVOKE
This parameter identifies the request of a RO-
request
INVOKE service and is used to correlate this
request with the corresponding replies (RO-
RESULT, RO-ERROR, RO-REJECT-U, and RO-
REJECT-P services) or the invocation of linked
child-operations (RO-INVOKE). This parameter
has to be supplied by the requestor of the service.
Figure 5 - RO-INVOKE service-primitives
This parameter distinguishes several requests of
the service the requestor may have in progress
10.1.1 RO-INVOKE parameters
(asynchronous operations). The requestor may
begin to reuse Invoke-ID values whenever it
Table 2 lists the RO-INVOKE service parameters.
chooses, subject to the constraint that it may not
reuse an Invoke-ID value that was previously
10.1.1.1 Operation-value
assigned to a request of the service for which it
expects, but has not yet received, a reply or the
invocation of a linked child-operation.
ISOAEC 9072-l : 1989 (E)
The ROSE-user to which an RO-INVOKE 10.2 RO-RESULT service
indication is issued, assumes that an Invoke-ID
The RO-RESULT service is used by a ROSE-user
value violating the above rule is a duplicate; and
to reply to a previous RO-INVOKE indication in
therefore, it does not perform the invoked
the case of a successfully performed operation.
operation. Instead, it rejects the duplicate
This service is an non-confirmed service.
invocation.
The related service structure consists of two
If Operation Classes 3, 4 or 5 are used, the
service-Drimitives, as illustrated in figure 6.
...