ISO/IEC 13712-1:1995
(Main)Information technology — Remote Operations: Concepts, model and notation
Information technology — Remote Operations: Concepts, model and notation
Describes the concepts and model of ROS. It uses ASN.1 to specify information object classes corresponding to the fundamental concepts of ROS, such as operation and error. This in turn provides a notation so that designers can specify particular instances of those classes, e.g. particular operations and errors. It provides a generic set of PDUs which can be used when realizing ROS concepts between objects remote from one another. These PDUs are used in the OSI realization of ROS, which are specified in the respective Recommendations (International Standards). Partial revision of ISO/IEC 9072-1 und ISO/IEC 9072-2.
Technologies de l'information — Opérations distantes: Concepts, modèle et notation
General Information
Relations
Standards Content (Sample)
INTERNATIONAL
lSO/IEC
STANDARD 13712-1
First edition
1995-09-15
Information technology - Remote
Operations: Concepts, model and notation
Techno/ogies de I’information - Opbrations a distance: Concepts, modele
et notation
Reference number
lSO/IEC 13712-1 :‘I 995(E)
ISO/IEC 13712=1:1995(E)
CONTENTS
Page
1 Scope .
2 Normative references .
........................................................................ 1
2.1 Identical Recommendations I International Standards
.......................... 1
2.2 Paired Recommendations I International Standards equivalent in technical content
Additional references .
2.3
Definitions .
OS1 reference model definitions .
3.1
ASN. 1 defmitions .
3.2
...................................................................................................................................
3.3 ROS definitions
Abbreviations .
Conventions .
..................................................................................................................................................... 3
ROS model
Realization of ROS .
ROS concepts .
8.1 Introduction .
Operation .
8.2
Error .
8.3
Operation package .
8.4
............................................................................................................................
8.5 Connection package
............................................................................................................................
8.6 Association contract
8.7 ROS-Object class .
8.8 Code .
Priori ty .
8.9
....................................................................................................................................
9 Generic ROS protocol
.........................................................................................................................................
9.1 Introduction
92 ROS .
9:3 Invoke .
Return result .
.........................................................................................................................................
9:5 Return error
..................................................................................................................................................
9.6 Reject
....................................................................................................................................
9.7 Reject Problem
.............................................................................................................................................
9.8 Invoke id
No invoke id .
9.9
..................................................................................................................................................
9.10 Errors
9.11 Bind .
................................................................................................................................................
9.12 Unbind
ISO/IEC 1995
All rights reserved. Unless otherwise specified, no part of this publication may be
reproduced or utilized in any form or by any means, electronie or mechanical, including
photocopying and microfilm, without Permission in writing from the publisher.
ISO/IEC Copyright Office l Case postale 56 l CH-121 1 Geneve 20 l Switzerland
Printed in Switzerland
ii
o ISO/IEC ISO/IEC 137124: 1995(E)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Useful definitions
.........................................................................................................................................
10.1 Introduction
10.2 Empty bind .
Empty unbind .
10.3
.................................................................................................................................................
10.4 Refuse
10.5 No-op .
10.6 Forward .
10.7 Reverse .
10.8 Consumer performs .
10.9 Supplier performs .
All operations .
10.10
10.11 recode .
10.12 switch .
10.13 combine .
10.14 ROS Single abstract Syntax .
10.15 ROS consumer abstract Syntax .
ROS supplier abstract Syntax .
10.16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex A - ASN.l modules
....................................................................................................
Annex B - Guidelines for the use of the notation
............................................................................................
B.l Examples of Operations and their Errors
.................................................................
B.2 Examples of Operation Packages and the use of switch{ }
..........................................................................................
B.3 Examples of Bind and Unbind operations
Examples of Connection Packages .
B.4
B.5 Example of an Association Contract .
Examples of ROS-objects .
B.6
Example of the use of Forward( ) and Reverse{ } .
B.7
.................................
B.8 Examples of ConsumerPerforms { }, SupplierPerforms { } and AllOperations { }
............................................................................................................
Annex C - Migrating from the ROS macros
C. 1 Introduction .
C.2 Operation .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
c.3 Error
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .*.*.
C.4 Bind
C.5 Unbind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex D - Assignment of Object identifier values
0.
ISO/IEC 13712=1:1995(E)
0 ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the Inter-
national Electrotechnical Commission) form the specialized System for worldwide
standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established
by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with
ISO and IEC, also take part in the work.
In the field of information technology, ISO 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 voting. Publication
as an International Standard requires approval by at least 75 % of the national
bodies casting a vote.
International Standard ISO/IEC 137 12- 1 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Information technology, Subcommittee SC 21, Open
Systems interconnection, data management and open distributed processing, in
collaboration with ITU-T. The identical text is published as ITU-T Rec-
ommendation X.880.
This part of ISO/IEC 137 12 is a partial revision of ISO/IEC 9072- 1: 1989 and
ISOIIEC 9072-2: 1989.
ISO/IEC 137 12 consists of the following Parts, under the general title Information
- Remote Operations:
technology
- Part 1: Concepts, model and notation
- Part 2: OS1 realizations - Remote Operations Service Element (ROSE)
Service definition
- Part 3: OSI realizations - Remote Operations Service Element (ROSE)
protocol specijkation
Annex A forms an integral part of this part of ISO/IEC 137 12. Annexes B to D
are for information only.
iv
o ISO/IEC
ISO/IEC 13712=1:1995(E)
Introduction
Remote operations (ROS) is a paradigm for interactive communication between objects. As such it tan be used in the
design and specification of distributed applications. The basic interaction involved is the invocation of an Operation by
one Object (the invoker), its Performance by another (the Performer), possibly followed by a report of the outcome of the
Operation being returned to the invoker.
The concepts of ROS are abstract, and may be realized in many ways. For example, objects whose interactions employ
by an OS1 network.
ROS concepts may be separated by a Software interface or
This Recommendation I International Standard describes the concepts and model of ROS. It uses ASN.l to specify
information Object classes corresponding to the fundamental concepts of ROS, such as Operation and error. This in turn
provides a notation so that designers tan specify particular instances of those classes, e.g. particular operations and
errors.
This Recommendation I International Standard provides a generic set of PDUs which tan be used in realizing the ROS
concepts between objects remote from one another. These PDUs are used in the OS1 realization of ROS, which are
specified in the companion Recommendations I International Standards to this one.
This Recommendation I International Standard also provides a number of definitions of general Utility to designers of
ROS-based applications.
Annex A forms an integral part of this Recommendation I International Standard.
Annexes B, C and D do not form an integral part of this Recommendation I International Standard.
This page intentionally left blank
ISO/IEC 13712-1: 1995 (E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY -
REMOTE OPERATIONS: CONCEPTS, MODEL AND NOTATION
1 Scope
This Recommendation I International Standard specifies the Remote Operations Service (ROS) using the Abstract
Syntax Notation (ASN.1) to define information Object classes corresponding to the fundamental concepts of ROS. This,
in turn, provides the notation that will allow application designers to specify particular instances of these classes.
This Recommendation I International Standard also provides a collection of definitions for specifying the generic
protocol between objects that communicate using ROS concepts. These definitions are used in the companion
Recommendations I International Standards to this one to provide the protocol data units, the Service primitives and the
application context definitions used in the OS1 realization of ROS.
A number of definitions of general Utility to designers of ROS-based applications is also provided.
No requirement is made for conformance to this Recommendation I International Standard.
2 Normative references
The following ITU-T Recommendations and International Standards contain provisions which, through reference in this
text, constitute provisions of this Specification. At the time of publication, the editions indicated were valid. All
Recommendations and Standards are subject to revision, and Parties to agreements based on this Specification are
encouraged to investigate the possibility of applying the most recent editions of the Recommendations and Standards
indicated below. Members of IEC and ISO maintain registers of currently valid International Standards. The
Telecommunications Standardization Bureau of the ITU maintains a list of currently valid ITU-T Recommendations.
21 . Identical Recommendations I International Standards
-
ITU-T Recommendation X.680 (1994) I ISO/IEC 8824-1: 1995, Information technology - Abstract Syntax
Notation One (ASN. I): Specification of basic notation.
-
ITU-T Recommendation X.68 1 (1994) I ISOLIEC 8824-2: 1995, Information technology - Abstract Syntax
Notation One (ASN. I): Information Object specification.
-
ITU-T Recommendation X.682 (1994) I ISOfIEC 8824-3:1995, Information technology - Abstract Syntax
Notation One (ASN. 1): Constraint specification.
-
ITU-T Recommendation X.683 (1994) I ISO/IEC 8824-4: 1995, Information technology - Abstract Syntax
Notation One (ASN. I): Parameterization of ASN.1 specifications.
-
ITU-T Recommendation X.200 (1994) I ISO/IEC 7498-1: 1994, Information technology - Open Systems
Interconnection - Basic Reference Model: The basic model.
-
ITU-T Recommendation X.881 (1994) I ISO/IEC 137 12-2: 1995, Znformation technozogy - Remote
Operations: OSI realizations - Remote Operations Service Element (ROSE} Service deflnition.
-
ITU-T Recommendation X.882 (1994) I ISO/IEC 137 12-3: 1995, Information technology - Remote
Operations: OSI realizations - Remote Operations Service Element (ROSE) protocol specijkation.
22 . Paired Recommendations I International Standards equivalent in technical content
-
CCITT Recommendation X.219 (1988), Remote Operations: Model, notation and Service definition.
Text communication - Remote Operations -
ISO/IEC 9072- 1: 1989, Information processing Systems -
Part Ir Model, notation and Service definition.
-
CCITT Recommendation X.229 (1988), Remote Operations: Protocol specification.
Text communication - Remote Operations -
ISO/IEC 9072-2: 1989, Information processing Systems -
Part 2: Protocol specification.
IT&T Rec. X.880 (1994 E) 1
ISO/IEC 1371211: 1995 (E)
23 l Additional references
-
CCITT Recommendation X.407 (1988), Message handling systems: Abstract Service definition
conventions.
3 Definitions
0 OS1 reference model definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.200 I
ISO/IEC 7498- 1:
abstract Syntax;
a>
b) protocol data unit;
c) quality of Service.
32 . ASN.1 definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.680 I
ISO/IEC 8824- 1:
a) @ata) type;
b) (data) value.
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.681 I
ISO/IEC 8824-2:
a) field;
b) (information) Object;
(information) Object class;
C)
(information) Object set.
d)
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.682 I
ISO/IEC 8824-3:
constraint;
a)
exception value.
b)
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.683 I
ISO/IEC 8824-4:
-
parameterized.
33 . ROS definitions
This Recommendation I International Standard defines the following terms:
argument: A data value accompanying the invocation of an Operation.
3.3.1
3.3.2 association: A relationship between a pair of objects, serving as the context for the invocation and perfomance
of operations.
communicating objects who may have an
association contract: A specification of the roles of a pair of
3.3.3
associ ion with each other.
3.3.4 asymmetrical: Describing an Operation package (or association contract), where the sets of operations which
the two Parties arc capable of performing differ.
connection package: A specification of the roles of a pair of communicating objects in the dynamic
3.3.5
establishment and release of associations between them.
3.3.6 contract: A set of requirements on one or more objects prescribing a collective behaviour.
error: A report of the unsuccessful Performance of an Operation.
3.3.7
2 ITU-T Rec. X.880 (1994 E)
ISO/IEC 13712-1 : 1995 (E)
An Opera tion in .voked d uring the Performance
3.3.8 linked Operation: of another Operation by the (latter’s)
Performer and intended to be performed by the (latter ‘9) invoker.
3.3.9 Object: A model of (possibly a self-contained part of) a System, characterized by its initial state and its
behaviour arising from external interactions over well-defined interfaces.
3.3.10 Operation: A function that one Object (the invoker) tan request of another (the Performer).
3.3.11 Operation package: A collection of related operations used to specify the roles of a pair of communicating
objects, each Operation being invokable by one or both objects of the pair and performable by the Partner.
3.3.12 Parameter (of an error): A data value which may accompany the report of an error.
3.3.13 result: A data value which may accompany the report of the successful performante of an Operation.
3.3.14 ROS-Object: An Object whose interactions with other objects are described using ROS concepts.
3.3.15 symmetrical: Describing an Operation package (or assocation contract) in which both Parties are capable of
performing the same set of operations.
3.3.16 synchronous: A characteristic of an Operation that, once invoked, its invoker cannot invoke another
synchronous Operation ( with the same intended Performer) u ntil the outcome has been reported.
4 Abbreviations
For the purposes of this Recommendation I International Standard, the following abbreviations apply:
ASN. 1 Abstract Syntax Notation One
PDU Protocol Data Unit
Quality of Service
QOS
RO (or ROS) Remote Operations
5 Conventions
This Recommendation I International Standard employs ASN.l to define:
a) Information Object classes corresponding to the ROS concepts - These also provide notation with which
designers of ROS applications tan specify particular instances of those classes.
b) Particular information objects of those classes.
c) The PDUs of the generic ROS protocol.
d) Data types needed in these definitions.
Many of these definitions are parameterized, so that their users must supply actual Parameters in Order to complete them.
6 ROS model
Remote operations (ROS) is a paradigm for interactive communication between objects. Objects whose interactions are
described and specified using ROS are ROS-objects. The basic interaction involved is the invocation of an Operation by
one ROS-Object (the invoker) and its Performance by another (the performer).
return, by the
Completion of the performante of the Operation (whether successfully or unsuccessfully) may lead to the
Performer to the invoker, of a report of its outcome. This is illustrated in Figure 1.
A report of the successful completion of an Operation is a result; a report of unsuccessful completion an error.
During the Performance of an Operation, the Performer tan invoke linked operations, intended to be performed by the
invoker of the original Operation.
For correct interworking, certain properties of the Operation must be known by both invoker and Performer. The
properties include:
whether reports are to be returned, and if so, which ones;
the types of the values, if any, to be conveyed with invocations of the Operation or returns from it;
ITU-T Rec. X.880 (1994 E) 3
ISO/IEC 13712-1: 1995 (E)
which operations, if any, tan be linked to it;
the code value to be used to distinguish this Operation from the others that might be invoked.
ROS-Object ROS-object
(invoker)
(performW
TlSO4150-94/dOl
Figure 1 - Invocation, performante, and return of an Operation
The interworking capabilities of (pairs of) ROS-objects of some ROS-Object class are defined in terms of sets of related
operations called Operation packages. A package may be symmetrical, in which case it is defined by a Single set of
operations which each ROS-Object in the pair tan invoke (of the other). Alternatively, a package may be asymmetrical,
in which case it is defined by two sets of operations, those which one ROS-Object of the pair tan invoke and those which
the other tan invoke. For the purpose of defining an asymmetrical package, the two ROS-objects are (arbitrarily)
labelled the consumer and supplier respectively.
NOTE 1 - While these labels are, in general, arbitrary, it will often be the case that an intuiti ve assignment tan be made,
given that frequently in such a pair of obj ects one will be supplying a Service which the other consumes.
A pair of ROS-objects must have an association between them to serve as a context for the invocation and Performance
of operations. Esch such association is governed by an association contract. A contract is specified in terms of the set
of packages which (collectively) determine the operations which tan be invoked during the association. If the contract
specification includes one or more asymmetrical packages then the contract is itself asymmetrical. For the purpose of
specifying an asymmetrical association contract, the two ROS-objects which establish an association with each other are
labelled the initiator and responder.
An association may be brought into and out of existente by “Off-1ine” means. Alternatively, an association may be
established and released dynamically. One Option, described in this Recommendation I International Standard, by which
an association may be established and released dynamically is, respectively, through the invocation and Performance of
special bind and unbind operations. The contract for associations of the latter variety includes a connection package,
which includes the particular bind and unbind operations to be used.
NOTE 2 - The mechanism for the establishment and release of associations may also be done by other means described in
other Recommendations I International Standards.
An association requires a relationship between the objects, the existente of which corresponds to the mutual agreement
of the objects to the terms of some association contract.
NOTE 3 - This specification does not address the means by which these relationships are established or terminated.
In the foregoing, the only objects seen to be involved in an Operation have been the invoker and Performer. However, in
general, the invoker and Performer of an Operation are not directly attached to one another, but are connected by some
medium through which invocations and returns tan be conveyed. This expanded view is illustrated in Figure 2.
ROS-object Medium ROS-object
(Performer)
(invoker)
?lS04160-94/dO2
Figure 2 - Expanded view
ITU-T Rec. X.880 (1994 E)
ISO/IEC 13712-1: 1995 (E)
The medium may introduce delay and the possibility of failure or inaccuracy both in the conveyance of invocations and
returns, and in the establishment, release, and maintenance of associations. It may also introduce the possibility of the
security of the association and its operations being threatened. The extent of these (together with other factors) are
described as the quality-of-Service (QOS).
Association contracts tan now be seen as having three Parties, the third party being the medium. The medium’s
Obligation under the contract is to satisfy the QOS requirements.
NOTE 4 - In the future, target and minimum acceptable QOS requirements may form part of the specification of
operations, Operation packages and of the association contract itself directly. Different aspects of QOS are applicable to these different
levels of specification.
7 Realization of ROS
A realization of ROS involves the definition of a suitable medium to convey invocations and returns between ROS-
objects. Such a medium may, for example, comprise:
a message-passing or procedure calling capability allowing the invoker and Performer of an Operation to
be implemented in separately developed Software modules within a Single Computer System;
b) a communications capability, allowing the invoker and Performer of an Operation to be implemented in
separate Computer Systems.
A realization may be general-purpose, in which case it tan be employed to support any association contract. Others are
special-purpose, accommodating only some particular contract(s).
Figure 3 depicts an approach to realizing ROS by communications means which is likely to be widely used.
TE041 70-94/dO3
Figure 3 - Approach to communications redization of ROS
In this approach, the medium is composed of stub objects, one for each ROS-Object, and an information transfer Object.
The stub Object associated with each ROS-Object appears to play the role of the Partner ROS-Object. However, it does
not actually invoke or perform any operations, merely transforming invocations and returns into PDUs and vice versa, as
appropriate. These PDUs are exchanged between the stubs by means of the information transfer Object.
Thus, to invoke an Operation, the invoker invokes the Operation of the associated stub, which forms a PDU describing
the invocation. The stub uses the information transfer capability to transfer the PDU to the other stub. The latter stub
interprets the PDU and then invokes the appropriate Operation of the ROS-Object with which it is associated, the
Performer. When the Operation has been performed, the Performer conveys any return to its associated stub, which forms
a PDU describing it. The stub then, uses the information transfer capability to transfer the PDU to the other stub. The
latter stub interprets the PDU and then reports the return to the invoker.
Clause 9 defines a collection of suitable PDUs.
Various information transfer capabilities tan be used in a ROS realization of this kind. Of particular importante are
the information transfer capabilities of OSI. The pair of companion Recommendations I International Standards,
ITU-TRec. X.881 I ISO/IEC 13712-2 and ITU-T Rec. X.882 I ISO/IEC 13712 -3, describe a number of such
realizations.
ITU-T Rec. X.880 (1994 E) 5
ISO/IEC 13712-1: 1995 (E)
8 ROS concepts
81 . Introduction
8.1.1 This clause defines the information Object classes corresponding to the basic concepts of ROS, specifying the
characteristics that objects of such classes have. The following information Object classes are defined:
-
OPERATION (describing operations);
-
ERROR (describing errors);
-
OPERATION-PACKAGE (describing Operation packages);
-
CONNECTION- PACKAGE (describing connection packages);
-
CONTRACT (describing association contracts);
-
ROS-OBJECT-CLASS (describing ROS-Object classes).
8.1.2 The information Object classes are defined using ASN.l. This provides notation which is available to designers
of ROS applications for specifying particular instances of those classes. Designers are encouraged, but not obliged, to
use this specification approach. If some other approach is employed, the resulting specification shall include or reference
a description of how a valid use of the notation provided could be derived.
NOTE - A number of existing specifications employ the ASN.l MACRO notation (which were defined in previous
Versions of this Recommendation I International Standard: see CCITT Rec. X.219 I ISOLIEC 9072-1) to specify operations, errors, and
other classes of information Object relevant to ROS. Annex C describes how the use of these macros tan be transformed onto the
notation provided. These macros should not be used for new applications.
Operation
82 .
8.2.1 An Operation is a function that one Object (the invoker) tan request of another (the Performer). The
information Object class OPERATION, to which all operations belong, is specified as follows, the various fields being
described in 8.2.2 to 8.2.13:
OPERATION ::= CLASS
r; I
{
&ArgumentType OPTIONAL,
BOOLEAN OPTIONAL,
&argumentTypeOptional
&returnResult BOOLEAN DEFAULT TRUE,
&ResultType OPTIONAL,
BOOLEAN OPTIONAL,
&resultTypeOptional
&Errors ERROR OPTIONAL,
&Linked OPERATION OPTIONAL,
&synchronous BOOLEAN DEFAULT FALSE,
&alwaysReturns BOOLEAN DEFAULT TRUE,
Priority OPTIONAL,
MnvokePriority
&ResultPriority Priority OPTIONAL,
&operationCode Code UNIQUE OPTIONAL
WITH SYNTAX
[ARGUMENT &ArgumentType [OPTIONAL &argumentTypeOptional]]
&ResultType [OPTIONAL &resultTypeOptional]]
[RESULT
[RETURN RESULT &returnResult]
&Errors]
[ERRORS
&Linked]
[LINKED
[SYNCHRONOUS &synchronous]
&alwaysReturns]
[ALWAYS RESPONDS
[INVOKE PRIORITY MnvokePriority]
[RESULT-PRIORITY &ResultPriori ty]
&operationCode]
[CODE
The &ArgumentType field specifies the data type of the argument of the Operation. If in some Operation the
8.2.2
field is omitted, then that Operation takes no argument value.
6 ITU-T Rec. X.880 (1994 E)
ISO/IEC 13712-1 : 1995 (E)
8.2.3
The &argumentTypeOpt ional field, which tan be present only if the &ArgumentType field is present,
specifies if the data type of the Operation argument may optionally be omitted. If this field is absent or takes the value
FALSE, the value of the &ArgumentType cannot be omitted from the Invoke ( } PDU (see 9.3).
8.2.4 The &returnResul t field specifies whether a result is returned in the event that the Operation is performed
successfully, taking the value TRUE if it is, and FALSE otherwise.
8.2.5 The &ResuItType field specifies the data type of the value returned with the result of the Operation. If it is
omitted, then the Operation returns no result value. It shall be omitted if the &returnResul t field is FALSE.
8.2.6
The WesultTypeOptional field, which tan be present only if the &ResultType field is present,
specifies if the data type of the value returned as the result of performing the Operation may optionally be omitted. If this
field is absent or takes the value FALSE, the value of the &ResultType cannot be omitted from the
ReturnResult {} PDU(see9.4).
8.2.7 The &Errors field specifies a set of errors, any one of which may be returned to report an unsuccessful
performante of the Operation. If this field is omitted, then unsuccessful Performance of the Operation is either not
possible or not reported.
8.2.8 The &alwaysReturns field specifies whether the outcome of performing the Operation is always returned,
taking the value TRUE if it is and FALSE otherwise. If this field is set to TRUE, at least one of the &returnResult
or &Errors field must be present.
8.2.9 The &Linked field, if present, specifies a set of operations, any of which may be invoked as linked operations
during the performante of the Operation. If this field is omitted, then no operations may be linke8 to an invocation of this
one.
8.2.10 The &synchronous field specifies whether or not the Operation is synchronous, taking the value TRUE if it
is, and FALSE otherwise. If the &returnResult field is FALSE, this field shall also take the value FALSE. When the
&synchronous field is set to TRUE, it implies that no other synchronous Operation may be invoked by this side until
this Operation has returned.
NOTE - The combination of the &alwaysReturns and the &synchronous Felds replaces the earlier concept of
“Operation classes” defined in CCITT Rec. X.219 I ISO/IEC 9072-1.
8.2.11 The &InvokePriority field specifies the permitted Priority (see 8.9) levels at which this Operation tan
be invoked.
8.2.12 The &ResultPriority field specifies the permitted Priority (see 8.9) levels at which the result of this
Operation tan be returned. If the &returnResuI t field is FALSE, this field shall be omitted.
8.2.13 The &operationCode field, if present, specifies the Code value (see 8.8) which is used to identify this
Operation, e.g. when it is to be invoked.
NOTE - An Operation which does not have an &operationCode cannot be invoked using the Invoke { } PDU
(see 9.3). In practice, therefore, all operations should have &operationCodes assigned except when intended for use in some
special circumstances, e.g. as a bind Operation.
83 . Error
8.3.1 An error is a report of the unsuccessful Performance of an Operation. The information Object class ERROR, to
vhich all errors belong, is specified as follows, the various fields being described in 8.3.2 to 8.3.5:
ERROR ::= CLASS
&ParameterType OPTIONAL,
¶meterTypeOptional BOOLEAN OPTIONAL,
&ErrorPriority Priority OPTIONAL,
&errorCode Code UNIQUE OPTIONAL
WITH SYNTAX
[PARAMETER &ParameterType [OPTIONAL ¶meterTypeOptional]
[PRIORITY &ErrorPriority]
[CODE &errorCode]
The &ParameterType field specifies the data type of the Parameter of the error. If in some error the field is
8.3.2
omitted, then that error takes no Parameter value.
ITU-T Rec. X.880 (1994 E) 7
ISO/IEC 13712-1: 1995 (E)
8.3.3 The ¶meterTypeOptional field, which tan be.present only if the &ParameterType field is
present, specifies if the data type of the value returned as the Parameter qualifying the error may optionally be present. If
this field is absent or takes the value FALSE, the value of the &ParameterType cannot be omitted from the
ReturnError {} PDU(see9.5).
8.3.4
The &ErrorPriority field specifies the permitted Priority (see 8.9) levels at which the error tan be
returned.
8.3.5 The &errorCode field, if present, specifies the Code value (see 8.8) which is used to identify this error, e.g.
when it is returned.
NOTE - An error which does not have an &errorCode cannot be retumed using the ReturnError { } PDU defined
below. In practice, therefore, all errors should have their &errorCode fields assigned except when intended for use in some special
circumstances, e.g. as a bind error.
84 . Operation package
8.4.1 An Operation package is a specification of the roles of a pair of communicating objects, in terms of the
operations which they tan invoke of each other. Where the package is asymmetrical, the terms “consumer” and
“supplier” are employed for the two objects involved. The information Object class OPERATION-PACKAGE , to which
all such packages belong, is specified as follows, the various fields being described in 8.4.2 to 8.4.7:
OPERATION-PACKAGE ::= CLASS
&Both OPERATION OPTIONAL,
&Consumer OPERATION OPTIONAL,
&Supplier OPERATION OPTIONAL,
&id OBJECT IDENTIFIER UNIQUE OPTIONAL
WITH SYNTAX
{
[OPERATIONS &Both]
[CONSUMER INVOKES
Mupplier]
[SUPPLIER INVOKES &Consumer]
&id]
D
The &Both field specifies a set of OPERATIONS which both objects shall be capable of performing. This field
3.4.2
may be omitted.
8.4.3 The Konsumer field specifies a set of OPERATIONs which one of the objects, known as the consumer, shall
be capable of performing. This field may be omitted, in which case the consumer shall only be capable of performing the
operations specified by the &Both field.
8.4.4 The Wupplier field specifies a set of OPERATIONs which one of the objects, known as the supplier, shall
be capable of performing. This field may be omitted, in which case the supplier shall only be capable of performing the
operations specified by the &Both field.
NOTE - A parameterized Operation package, swi tch { } , is provided (see 10.12) to allow one Operation package to be
derived by switching the roles of some other.
8.4.5 The &id field, if present, specifies the OBJECT IDENTIFIER value which is used to identify this package
e.g. if it is being announced or negotiated.
NOTE - A package which does not have an &i.d cannot be announced or negotiated.
8.4.6 All operations included (directly or indirectly) by the &Both, Konsumer, and &Supplier fields shall
have distinct &operationCode values.
All errors included in the &Errors field of all of the operations included (see 8.4.6), shall have distinct
8.4.7
&errorcode values.
85 . Connection package
8.5.1 A connection package is a specification of the operations and QOS involved in dynamic establishment and
release of an association. The connection package shall be specified only if the bind and the unbind operations are used
The information Object class CONNECTION-
to, respectively, dynamically establish and release an association.
8 IT&T Rec. X.880 (1994 E)
ISO/IEC 13712-1 : 1995 (E)
PACKAGE, to which all such connection packages belong, is specified as follows, the various Felds being described
in 8.52 to 8.56:
1 CONNECTION-PACKAGE ::= CLASS
I{
&bind OPERATION DEFAULT emptyBind,
&unbind OPERATION DEFAULT emptyunbind,
&responderCanUnbind BOOLEAN DEFAULT FALSE,
&unbindCanFail BOOLEAN DEFAULT FALSE,
&id OBJECT IDENTIFIER UNIQUE OPTIONAL
WITH SYNTAX
[BIND &bind]
[UNBIND &unbind]
[RESPONDER UNBIND &responderCanUnbind]
&unbindCanFail]
[FAILURE TO UNBIND
&id]
[ID
8.5.2 The &bind field specifies an OPERATION which is to be performed as part of the establishment of an
association. Such an Operation must have its &returnResult and &alwaysReturns fields set to TRUE, and
have a Single error, present in the &Errors field. If the association is successfully established, the bind Operation will
return a result. If the association is not successfully established, the bind Operation will report its error. If the &bind
field is not explicitly included, the connection package will include the emptyBind Operation (see 10.2).
The &unbind field specifies an OPERATION which is to be performed as part of the release of an
8.5.3
association. Such an Operation must have its &returnResult and &alwaysReturns fields set to TRUE, and must
have a Single error, defined by the &Errors field. If the association is successfully released, the unbind Operation will
return a result. If the association is not successfully released, the unbind Operation will not return a result, and will report
its error. If the &unbind field is not explicitly included, the connection package will include the emptyunbind
Operation (see 10.3).
The &responderCanUnbind field indicates whether or not the association responder (as well as the
8.5.4
initiator) tan invoke the &unbind Operation.
8.5.5 The &unbindCanFail field indicates whether or not it is possible for the association to still exist after the
&unbind Operation has signalled an error.
The &id field, if present, specifies the OBJECT IDENTIFIER value which is used to identify this
8.5.6
connection package e.g. if it is being announced or negotiated.
NOTE - A connection package which does not have an &id cannot be announced or negotiated.
86 . Association contract
An association contract is a specification of the roles of a pair of communicating objects who may establish an
8.6.1
association with each other. The information Object class CONTRACT, to which all such contracts belong, is specified as
follows, the various Felds be
...
lSO/CEI
NORME
13712-l
INTERNATIONALE
Première édition
1995-09-15
Technologies de l’information -
Opérations distantes: Concepts, modèle et
notation
- Remote Operations: Concepts, mode/ and
Information technology
notation
Numéro de référence
ISO/CEI 13712-I :1995(F)
ISOKEI 137124: 1995(F)
Sommaire
Page
Domaine d’application .
Références normatives .
2.1 Recommandations et Normes internationales identiques .
2.2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
....... 2
2.3 .
Autres références
Définitions .
3.1 Définitions relatives au modèle de référence OS1 .
3.2 Définitions relatives à la notation ASN. 1 .
3.3 Définitions relatives au service ROS .
Abréviations .
Conventions .
Modèle ROS .
Réalisation des services ROS .
Concepts ROS .
81 Introduction .
*:2 Opération .
8.3 Erreur .
8.4 Lot d’operations
...................................................................................................................................
8.5 Lot de connexion .
8.6 Contrat d’association .
8.7 Classe d’objets ROS .
8.8 Code .
8.9 Priorité .
Protocole générique ROS .
91 .
Introduction . 12
92 Type ROS . 12
9:3 Type Invoke . 13
96 . Type Reject .
97 Type RejectProblem .
9:s Type InvokeId .
99 Valeur NoInvokeId
............................................................................................................................. 18
9’10 Ensemble Errors . 18
9’11 Type Bind .
9’12 . Type Unbind .
0 ISOKEI 1995
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publi-
cation ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun
procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans
l’accord écrit de l’éditeur.
ISOKEI Copyright Office l Case Postale 56 l CH-121 1 Genève 20 l Suisse
Version française tirée en 1996
Imprimé en Suisse
ii
ISOKEI 13712-l: 1995(F)
@ ISOKEI
10 Définitions utiles . 19
10.1 Introduction . 19
10.2 Opération emptyBind .
.....................................................................................................................
10.3 Opération empty Unbind 20
10.4 Notification refuse . 20
10.5 Opération no-op . 20
10.6 Ensemble Forward . 20
10.7 Ensemble Reverse .
10.8 Ensemble ConsumerPerforms .
10.9 Ensemble SupplierPerforms . 21
10.10 Ensemble AllOperations . 21
10.11 Opération recode . 22
10.12 Lot d’opérations switch . 22
10.13 Lot d’opérations combine .
10.14 Type ROS-SingleAS . 23
10.15 Type ROS-ConsumerAS . 23
10.16 Type ROS-SupplierAS . 23
Annexe A - Modules ASN. 1 . 24
Annexe B - Directives pour l’utilisation de la notation . 31
B. 1 Exemples d’opérations et d’erreurs .
B.2 Exemples de lots d’opérations et de l’utilisation de l’opérateur switch .
B.3 Exemples d’opérations de rattachement et de détachement .
Exemples de lots de connexion
B.4 . 34
B.5 Exemples de contrat d’association . 34
B.6 Exemples d’objets ROS . 34
B.7 Exemple d’utilisation des opérateurs Forward{ } et Reverse{ } . 35
B.8 Exemple d’utilisation des opérateurs ConsumerPerforms { ), SupplierPerforms { ) et
AllOperations ( ) . 36
Annexe C - Migration des macro-instructions ROS . 37
C. 1 Introduction . 37
C.2 Macro-instruction OPERATION . 37
C.3 Macro-instruction ERROR . 38
.......................................................................................................................
C.4 Macro-instruction Bind 38
...................................................................................................................
C.5 Macro-instruction Unbind 38
Annexe D - Affectation de valeurs d’identificateurs d’objets . 39
. . .
ISOKEI 13712=1:1995(F)
0 ISOKEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes
nationaux membres de I’ISO ou de la CE1 participent au développement de
Normes internationales par l’intermédiaire des comités techniques créés par
l’organisation concernée afin de s’occuper des différents domaines particuliers de
l’activité technique. Les comités techniques de I’ISO et de la CE1 collaborent
dans des domaines d’intérêt commun. D’autres organisations internationales,
gouvernementales ou non gouvernementales, en liaison avec I’ISO et la CE1
participent également aux travaux.
Dans le domaine des technologies de l’information, 1’ISO et la CE1 ont créé un
comité technique mixte, 1’ISOKEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux
pour approbation, avant leur acceptation comme Normes internationales. Les
Normes internationales sont approuvées conformément aux procédures qui
requièrent l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 137 12- 1 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de I?nformation, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec I’IUT-T. Le texte identique est publié en tant que
Recommandation IUT-T X.880.
La présente partie de I’ISOKEI 137 12 est une révision partielle de
1’ISOKEI 9072-l: 1989 et 1’ISOKEI 9072-2: 1989.
L’ISOKEI 137 12 comprend les parties suivantes, présentées sous le titre général
Technologies de l’information - Opérations distantes:
Partie 1: Concepts, modèle et notation
- Partie 2: Réalisations OSI - Définition du service de l’élément de service
d’opérations distantes (ROSE)
- Partie 3: Réalisations OSI - Spécification du protocole de l’élément de
service d’opérations distantes (ROSE)
L’annexe A fait partie intégrante de la présente partie de l’ISO/CEI 137 12. Les
annexes B à D sont données uniquement à titre d’information.
1v
@ ISOKEI ISOKEI 137124: 1995(F)
Introduction
Le concept d’opérations distantes (ROS) est un paradigme de la communication interactive entre objets. En tant que tel,
il peut être utilisé pour la conception et la spécification des applications réparties. L’interaction de base mise en jeu est
l’invocation d’une opération par un objet (l’invocateur), son exécution par un autre (l’exécutant), éventuellement suivie
par un rapport sur le rhultat de l’opération retourné à l’invocateur.
Les concepts d’opérations distantes (ROS) sont abstraits, et peuvent être réalisés de multiples manières. Ainsi, les objets
dont les interactions mettent en jeu les concepts d’opérations distantes peuvent être séparés par une interface logicielle ou
par un réseau OSI.
La présente Recommandation I Norme internationale décrit les concepts et le modèle de service ROS. Elle utilise
l’ASN.1 pour spécifier les classes d’objets informationnels correspondant aux concepts fondamentaux du service ROS,
tels que les classes opération et erreur. Ces éléments fournissent à leur tour la notation qui permet aux concepteurs de
spécifier des instances particulières de ces classes, comme des opérations ou des erreurs spécifiques.
La présente Recommandation I Norme internationale fournit un ensemble générique d’unités de données de protocole
(PDU) qui peuvent être utilisées pour réaliser les concepts de service ROS entre objets distants les uns des autres. Ces
PDU sont utilisées dans les applications OS1 des concepts de service ROS, qui sont spécifiées dans les
Recommandations I Normes internationales jumelles de celle-ci.
La présente Recommandation I Norme internationale fournit également un certain nombre de définitions d’ordre général
pour les concepteurs d’applicati .ons à base d’opérations distan tes ROS.
L’Annexe A fait partie intégrante de la présente Recommandation I Norme internationale.
Les Annexes B, C et D ne font pas partie intégrante de la présente Recommandation i Norme internationale.
Page blanche
ISOKEI 13712-l : 1995 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION -
OPÉRATIONS DISTANTES: CONCEPTS, MODÈLE ET NOTATION
1 Domaine d’application
La présente Recommandation I Norme internationale spécifie le service d’opérations distantes (ROS) et utilise la notation
de syntaxe abstraite numéro un (ASN.l) pour définir les classes d’objets informationnels correspondant aux concepts
fondamentaux du service ROS. Ces éléments fournissent à leur tour la notation qui permettra aux concepteurs
d’applications de spécifier des instances particulières de ces classes.
La présente Recommandation I Norme internationale renferme également une collection de définitions qui spécifient le
protocole générique d’échange entre objets communiquant selon les concepts du service ROS. Les’ Recommandations I
Normes internationales associées à celle-ci utilisent ces définitions pour définir les unités de données de protocole, les
primitives de service et les définitions de contexte applicatif qui interviennent dans la réalisation OS1 du service ROS.
Un certain nombre de définitions d’intérêt général pour les concepteurs des applications à base d’opérations distantes sont
également données.
Aucune spécification n’est imposée quant à la conformité à la présente Recommandation I Norme internationale.
Références normatives
Les Recommandations de FUIT-T et les Normes internationales suivantes contiennent des dispositions qui, par suite de
la référence qui y est faite, constituent des dispositions valables pour la présente Spécification. Au moment de la
publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes internationale sont sujettes à
révision et les parties prenantes aux accords fondés sur la présente Spécification sont invitées à rechercher la possibilité
d’appliquer les éditions les plus récentes des Recommandations et Normes internationales indiquées ci-après. Les
membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de I’UIT tient à jour une liste des Recommandations UIT-T en vigueur.
21 . Recommandations et Normes internationales identiques
-
Recommandation UIT-T X.680 (1994) I ISOKEI 8824-: 1995, Technologie de l’information - Notation de
syntaxe abstraite numéro un: Spécification de la notation de base.
-
Recommandation UIT-T X.681 (1994) I ISOKEI 8824-2:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un: Spécijkation des objets informationnels.
-
Recommandation UIT-T X.682 (1994) I ISOKEI 8824-3: 1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un: Spécifkation des contraintes.
-
Recommandation UIT-T X.683 (1994) I ISOKEI 8824-4: 1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un: Paramétrage des spécifications ASN.1.
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l : 1994, Technologie de l’information -
Interconnexion de systèmes ouverts - Modèle de référence de base. Le modèle de base.
-
Recommandation UIT-T X.88 1 (1994) I ISOKEI 137 12-2: 1995, Technologie de Z’information -
Définition du service de 1 ‘élément de service d’opérations
Opérations distantes: Applications OSI -
distantes.
-
Recommandation UIT-T X.882 (1994) I ISOKEI 13712-3:1995, Technologie de Z’information -
Opérations distantes: Applications OSI - Spécification du protocole de 1 ‘élément de service d’opérations
distantes.
Rec. UIT-T X.880 (1994 F)
ISOKEI 13712-l : 1995 (F)
Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
22 .
-
Recommandation X.219 du CCITT (1988), Opérations distantes: modèle, notation et définition du
service.
ISOICEI 9072- 1: 1989, Systèmes de traitement de l’information - Communication de texte - Opérations à
distance - Partie 1: Modèle, notation et définition du service.
-
Recommandation X.229 du CCITT (1988), Opérations distantes: Spécification du protocole.
ISOKEI 9072-2: 1989, Systèmes de traitement de l’information - Communication de texte - Opérations à
distance - Partie 2: Spécijkation du protocole.
23 . Autres références
-
Recommandation X.407 du CCITT (1988), Systèmes de messagerie: Conventions pour la définition des
services abstraits.
3 Définitions
31 . Définitions relatives au modèle de référence OS1
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.200 1
ISOKEI 7498- 1:
syntaxe abstraite;
a>
b) unité de données de protocole;
c) qualité de service.
32 . Définitions relatives à la notation ASN.1
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.680 I
ISOKEI 8824- 1:
type (de données);
a>
valeur (de données).
b)
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.681 I
ISOKEI 8824-2: ’
champ;
a)
objet (informationnel);
b)
classe d’objets (informationnels);
C)
ensemble d’objets (informationnels).
d)
La présente Recommandation I Norme internationale utilise le terme suivant, défini
dans la Rec. UIT-T X.682 I ISOKEI 8824-3:
contrainte;
a>
valeur d’exception.
b)
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.683 I
ISOKEI 8824-4:
paramétré.
2 Rec. UIT-T X.880 (1994 F)
ISOKEI 13712-l : 1995 (F)
33 . Définitions relatives au service ROS
La présente Recommandation I Norme internationale définit les termes suivants:
3.3.1 argument: Valeur de données accompagnant l’invocation d’une opération.
3.3.2 association: Relation entre un couple d’objets, servant de contexte à l’invocation et à l’exécution d’une
opération.
3.3.3 contrat d’association: Spécification des rôles d’un couple d’objets communicants pouvant être associés l’un à
l’autre.
3.3.4 asymétrique: Qualificatif d’un lot d’opérations (ou d’un contrat d’association), pour lequel les ensembles
d’opérations pouvant être exécutées par chacune des deux parties diffèrent l’un de l’autre.
lot de connexion: Spécification des rôles d’un couple d’objets communicants dans l’établissement
3.3.5 ou la
libération dynamique de leur association.
3.3.6 contrat: Ensemble de spécifications imposées à un ou plusieurs objets prescrivant un comportement collectif.
3.3.7 erreur: Rapport notifiant l’échec d’exécution d’une opération.
3.3.8 opération liée: Opération invoquée, pendant l’exécution d’une autre opération, par le (précédent) exécutant et
qui doit être exécutée par le (précédent) invocateur.
3.3.9 objet: Modèle de système (ou éventuellement de sous-système autonome), caractérisé par son état initial et son
comportement découlant d’interactions externes à travers des interfaces bien définies.
3.3.10 opération: Fonction qu’un objet (l’invocateur) peut demander à un autre (l’exécutant) d’exécuter.
3.3.11 lot d’opérations: Collection d’opérations liées utilisée pour spécifier les rôles pour un couple d’objets
communicants, chaque opération pouvant être invoquée par un des deux objets ou par les deux pour être exécutée par
l’autre.
3.3.12 paramètre (d’une erreur): Valeur de données pouvant accompagner le rapport d’erreur.
résultat: Valeur de données pouvant accompagner le rapport d’exécution avec succès d’une opération.
3.3.13
3.3.14 objet ROS: Objet dont les interactions avec d’autres objets sont décrites à l’aide des concepts d’opérations
distantes ROS.
3.3.15 symétrique: Qualificatif d’un lot d’opérations (ou d’un contrat d’association) dans lequel les deux parties sont
capables d’exécuter le même ensemble d’opérations.
3.3.16 synchrone: Qualificatif d’une opération qui, une fois invoquée, interdit à son invocateur d’invoquer une autre
opération synchrone (avec le même exécutant désigné) tant que son résultat n’a pas été notifié.
4 Abréviations
Pour les besoins de la présente Recommandation I Norme internationale, les abréviations suivantes sont utilisées:
ASN. 1 Notation de syntaxe abstraite numéro un (abstract syntax notation one)
PDU Unité de données de protocole (protocol data unit)
Qualité de service (quality of service)
QOS
RO (ou ROS) Opérations distantes (remote operations)
5 Conventions
La présente Recommandation I Norme internationale utilise I’ASN. 1 pour définir:
a) les classes d’objets informationnels correspondant aux concepts ROS; elle indique également la notation
avec laquelle les concepteurs d’applications ROS peuvent spécifier des instances particulières de ces
classes;
b) les objets informationnels particuliers de ces classes;
c) les PDU du protocole générique d’opérations distantes (protocole ROS);
d) les types de données nécessaires à ces définitions.
Rec. UIT-T X.880 (1994 F)
ISOKEI 137124 : 1995 (F)
Beaucoup de ces définitions sont paramétrées; pour les compléter, les utilisateurs doivent en préciser les paramètres
effectifs.
6 Modèle ROS
Le concept d’opérations distantes (ROS) est un paradigme de la communication interactive entre objets. Les objets dont
les interactions sont décrites et spécifiées a l’aide de concepts ROS sont des objets ROS. L’interaction de base mise en
jeu est l’invocation d’une opération par un objet ROS (l’invocateur) et son exécution par un autre (l’exécutant).
échec) peut entraîner le renvoi par l’exécutant à l’invocateur
L’achèvement de l’opération (sur u n succès ou un d’un
rapport sur le résultat de l’opération. Ceci est illustré à la Figure 1.
Un rapport notifiant l’achèvement avec succès d’une opération est un résultat; un rapport notifiant l’achèvement d’une
opération sur un échec est une erreur.
Pendant l’exécution d’une opération, l’exécutant peut invoquer des opérations liées, à exécuter par l’invocateur de
l’opération d’origine.
‘opération doivent être connues à la fois de l’invocateur
Pour un interfonctionnement correct, certaines des propriétés de 1
et de l’exécutant, notamment:
-
si des rapports doivent être envoyés en retour, et dans l’affirmative, lesquels;
-
les types des valeurs accompagnant le cas échéant les invocations d’opérations et les notifications
envoyées en retour;
-
les opérations pouvant le cas échéant être liées a l’opération d’origine;
-
la valeur de code a utiliser pour distinguer l’opération en question des autres opérations pouvant être
invoquées.
Objet ROS Objet ROS
(exdcutant)
(invocateur)
l-604 150-94/dO 1
Figure 1 - Invocation, exécution et retour d’une opération
Les capacités d’interfonctionnement des (couples d’)objets ROS d’une quelconque classe d’objets ROS sont définies en
termes d’ensembles d’opérations liées appelés lots d’opérations. Un lot peut être symétrique, auquel cas il est défini par
un seul ensemble d’opérations que chaque objet ROS du couple peut invoquer (pour être exécutées par l’autre). Ou alors,
le lot peut être asymétrique, auquel cas il est défini par deux ensembles d’opérations, chacun pouvant être invoqué par
un seul des deux objets du couple. Pour les besoins de la définition d’un lot asymétrique, les objets ROS sont
arbitrairement étiquetés l’un comme client et l’autre comme serveur.
NOTE 1 - Alors que ces étiquettes sont en général arbitraires, il arrivera souvent que leur affectation soit intuitive, l’un des
objets offrant manifestement un service que l’autre consomme.
Un couple d’objets ROS doivent être liés par une association servant de contexte à l’invocation et à l’exécution
d’opérations. Chaque association de cette sorte est gouvernée par un contrat d’association. Un contrat est spécifié en
termes de lots qui déterminent (collectivement) les opérations qui peuvent être invoquées dans le cadre de l’association.
Si les spécifications de contrat comprennent un ou plusieurs lots asymétriques, le contrat est lui-même asymétrique. Pour
les besoins de la spécification d’un contrat d’association asymétrique, les deux objets ROS qui établissent l’association
entre eux sont étiquetés l’un comme initiateur et lautre comme répondeur.
Une association peut être créée ou dissoute par des moyens «hors ligne». Mais elle peut être aussi établie ou libérée
dynamiquement. Une des options décrites dans la présente Recommandation I Norme internationale et permettant
d’établir et de libérer dynamiquement une association est réalisée par l’invocation et l’exécution des opérations spéciales
respectivement de rattachement et de détachement. Le contrat de cette dernière catégorie d’associations inclut un lot
de connexion comprenant les opérations particulières de rattachement et de détachement à utiliser.
4 Rec. UIT-T X.880 (1994 F)
ISOKEI 13712-l : 1995 (F)
ations peut
NOTE 2 - Le mécanisme d’établissement et de libération également être assuré par d’autres moyens
dans d’autres Recommandations I Normes internationales.
Une association necessite qu’existe entre les deux objets une relation qui corresponde a l’acceptation par ces objets des
termes d’un quelconque contrat d’association
NOTE 3 - Cette spécifïcation ne traite pas des moyens par lesquels de telles relations sont établies ou terminées.
Dans ce qui suit, les seuls objets qu’on voit impliqués dans une opération sont l’invocateur et l’executant. Toutefois,
l’invocateur et l’exécutant d’une opération ne sont généralement pas directement rattachés l’un à l’autre, mais connectés
par un intermédiaire quelconque à travers lequel sont transmis les invocations et les rapports en retour. La Figure 2
illustre ce schéma élargi.
Objet ROS Intermddiaire Objet ROS
(inwcateur) (exdwtant)
TlSO4 160-94/dO2
Figure 2 - Schéma élargi
L’intermédiaire peut introduire un retard et une possibilité d’échec ou d’inexactitude dans la transmission tant des
invocations que des rapports, ainsi que dans l’établissement, la libération et la maintenance des associations. Il peut
également introduire une possibilité de menace pour la sécurité de l’association et de ses opérations. L’importance de ces
éléments (ainsi que d’autres facteurs) sont décrits dans le cadre de la qualité de service (QOS).
Les contrats d’association peuvent dans ce cas être vus comme tripartites, la partie tierce étant l’intermédiaire. Les
obligations de l’intermédiaire au titre du contrat sont de satisfaire aux spécifications de qualité de service.
NOTE 4 - Ultérieurement, les spécifications objectifs et les spécifications minimales en matière de qualité de service
pourront faire partie de la spécification des opérations, des lots d’opérations et du contrat d’association lui-même. Aux spécifications
de chacun de ces niveaux correspondent différents aspects de qualité de service.
Réalisation des services ROS
Une réalisation de service ROS implique la définition d’un intermédiaire approprié permettant de véhiculer les
invocations et les rapports entre objets ROS. Un tel intermédiaire peut par exemple comprendre:
une capacité de passation de message ou d’appel de procédure permettant de programmer séparément
a)
l’invocateur et l’exécutant d’une opération dans des modules logiciels distincts dans un même ordinateur;
une capacité de communication, permettant de programmer l’invocateur et l’exécutant d’une opération
b)
dans des ordinateurs distincts.
Une application peut être polyvalente, et peut alors être utilisée pour prendre en charge un contrat d’association
quelconque. D’autres applications peuvent être spécifiques et n’accepter que des contrats d’un type particulier.
La Figure 3 illustre une façon de réaliser un service ROS avec un système de communication en intermédiaire, schéma
qui sera vraisemblablement largement utilisé.
TE041 70-94/dO3
Figure 3 - Service ROS avec un système de comrnmication en intermédiaire
Rec. UIT-T X.880 (1994 F)
ISO/CEI 13712-l : 1995 (F)
Dans cette approche, l’intermédiaire est constitue d’objets pivots @tub), un pour chaque objet ROS, plus un objet de
transfert d’information. L’objet pivot associé à chaque objet ROS apparaît comme jouant le rôle de l’objet ROS
partenaire. En fait, il n’invoque ni n’exécute aucune opération, et se contente de transformer les invocations et les
rapports en PDU et vice versa. Ces PDU sont échangées entre les pivots au moyen de l’objet de transfert d’information.
L’invocateur adresse donc son invocation au pivot qui lui est associé, lequel forme une PDU décrivant l’invocation. Le
pivot utilise ensuite la capacité de transfert d’information pour transférer la PDU à l’autre pivot. Ce dernier interprète la
PDU puis invoque l’opération appropriée de l’objet ROS qui lui est associé, c’est-à-dire l’exécutant. Une fois l’opération
exécutée, l’exécutant remet s’il y a lieu un rapport au pivot qui lui est associé. Ce dernier forme la PDU décrivant le
rapport, puis utilise la capacité de transfert d’information pour transférer la PDU à l’autre pivot, qui l’interprète et notifie
le résultat a l’invocateur.
L’article 9 définit une collection de PDU appropriées.
Différentes capacités de transfert d’information peuvent être utilisées pour réaliser un système ROS de ce type. Parmi
celles-ci, les capacités de transfert d’information de l’architecture OS1 revêtent une importance particulière. Les deux
UIT-TX.881 i ISO/CEI 13712-2 et UIT-T X.882 1
Recommandations I Normes internationales jumelles
ISOKEI 137 12-3 décrivent de telles réalisations.
Concepts ROS
81 . Introduction
8.1.1 Cet article définit les classes d’objets informationnels suivantes, qui correspondent aux concepts de base
d’opérations distantes, et spécifie les caractéristiques des objets de ces classes:
-
OPERATION (décrit les opérations)
-
ERROR (décrit les erreurs)
-
OPERATION-PACKAGE (décrit les lots d’opérations)
-
CONNECTION-PACKAGE (décrit les lots de connexion)
-
CONTRACT (décrit les contrats d’association)
-
ROS-OB JECT-CLASS (décrit les classes d’objets ROS)
8.1.2 Les classes d’objets informationnels sont définies en ASN.1. Ces définitions servent ensuite aux concepteurs
d’applications de service ROS pour spécifier des instances particulières de ces classes. Les concepteurs sont encouragés à
adopter cette approche pour leurs spécifications, mais pas obligés de le faire. Si une autre approche est suivie, la
spécification résultante devra comprendre une description sur la manière d’en dériver une notation valide, ou faire
réference à une telle explication.
NOTE - Un certain nombre de spécifications existantes utilisent la notation en macro-instructions ASN. 1 (définie dans des
versions antérieures de la présente Recommandation I Norme internationale: voir la Rec. X.219 du CCITT I ISOKEI 9072-l) pour
spécifier les opérations, les erreurs et les autres classes d’objets informationnels se rapportant au service ROS. L’Annexe C décrit la
manière de transformer ces macro-instructions dans la notation indiquée. Ces macro-instructions ne devront plus être utilisées pour les
nouvelles applications.
6 Rec. UIT-T X.880 (1994 F)
ISOICEI 13712-l : 1995 (F)
82 . Opération
Une opération est une fonction qu’un objet (l’invocateur) peut demander à un autre objet (l’exécutant)
8.2.1
d’exécuter. La classe d’objets informationnels OPERATION, à laquelle toutes les opérations appartiennent, est spécifiée
comme suit, les différents champs étant décrits dans 8.2.2 a 8.2.13:
OPERATION t:= CLASS
&ArgumentType OPTIONAL,
&argumentTypeOptional BOOLEAN OPTIONAL,
&returnResult
BOOLEAN DEFAULT TRUE,
&ResultType OPTIONAL,
&resultTypeOptional BOOLEAN OPTIONAL,
&Errors ERROR OPTIONAL,
&Linked OPERATION OPTIONAL,
&synchronous BOOLEAN DEFAULT FALSE,
&alwaysReturns BOOLEAN DEFAULT TRUE,
&InvokePriority Priority OPTIONAL,
&ResultPriority Priority OPTIONAL,
&operationCode Code UNIQUE OPTIONAL
WITH SYNTAX
[ARGUMENT &ArgumentType [OPTIONAL &argumentTypeOptional]]
[RESULT &ResultType
[OPTIONAL &resultTypeOptional]]
[RETURN RESULT &returnResult]
[ERRORS &Errors]
[LINKED &Linked]
[SYNCHRONOUS &synchronous]
[ALWAYS RESPONDS &alwaysReturns]
[INVOKE PRIORITY &InvokePriority]
[RESULT-PRIORITY
&ResultPriority]
[CODE &operationCode]
8.2.2 Le champ &ArgumentType “argument) spécifie le type de donnees de l’argument de l’opération. Si,
(
type d
opération donnée, ce champ es
pour une t omis, l’opération ne prend pas de valeur d’argument.
8.2.3 Le champ &argumentTypeOptional (type d’argument optionnel), qui ne peut exister que lorsque le champ
&ArgumentType est lui-même présent, spécifie si le type de données de l’argument de l’opération peut optionnellement
être omis. Si ce champ est absent ou s’il prend la valeur FALSE vaux), la valeur de &ArgumentType ne peut être
omise de la PDU Invoke{} (voir 9.3).
8.2.4 Le champ &returnResult (retourner le résultat) spécifie si un résultat doit être retourné en cas d’achèvement
avec succès de l’opération, et prend la valeur TRUE (vrai) si c’est le cas, FALSE (faux) sinon.
Le champ &ResultType (type de résultat) spécifie le type de données de la valeur retournée avec le résultat de
8.2.5
l’opération. Si cette indication est omise, l’opération ne retourne pas de valeur de résultat. Ce champ est omis si le champ
&returnResult a la valeur FALSE (faux).
8.2.6 Le champ &resultTypeOptional (type de résultat optionneZ), qui ne peut exister que lorsque le champ
&ResultType est lui-même présent, spécifie si le type de données de la valeur retournée comme résultat de la bonne
exécution de l’opération peut optionnellement être omis. Si ce champ est absent ou s’il prend la valeur FALSE vaux), la
valeur de &ResultType ne peut être omise de la PDU ReturnResult{} (voir 9.4).
8.2.7 Le champ &Errors (erreurs) spécifie un ensemble d’erreurs, l’une quelconque de ces valeurs pouvant être
retournée pour notifier l’échec d’exécution de l’opération. Si ce champ est omis, alors soit que l’échec d’exécution de
l’opération est impossible, soit qu’il n’est pas notifié.
8.2.8 Le champ &alwaysReturns (toujours retourner) spécifie s’il faut toujours retourner le résultat de l’opération,
(vrai) si c’est le cas, FALSE (faux) sinon. Si ce champ a la valeur TRUE (vrai), au moins l’un
et prend la valeur TRUE
des deux champs &returnResult ou &Errors doit être présent.
8.2.9 Le champ &Linked (lié) spécifie, lorsqu’il est présent, un ensemble d’opérations, l’une quelconque de ces
opérations pouvant être invoquée en tant qu’opération liée pendant l’exécution de l’opération d’origine. Si ce champ est
omis, aucune opération ne peut être liée à l’invocation de l’opération en cours.
Rec. UIT-T X.880 (1994 F) 7
ISOKEI 13712-l : 1995 (F)
8.2.10 Le champ &synchronous (synchwze) spécifie si l’opération est synchrone ou non, et prend la valeur TRUE
(vrai) si c’est le cas, FALSE (faux) sinon. Si le champ &returnResult a la valeur FALSE (faux), ce champ aura
toujours la valeur FALSE (faux). Si le champ &synchronous a la valeur TRUE (vrai), ceci implique qu’aucune autre
opération synchrone ne pourra être invoquée par cette source jusqu’à la réception du rapport d’exécution en retour.
NOTE - La combinaison des champs &alwaysReturns et &synchronous remplace le concept antérieur de «classe
d’opération» défini dans la Rec. X.21 9 du CCITT I ISOKEI 9072- 1.
8.2.11 Le champ MnvokePriority (priorité de I?nvocation) spécifie les niveaux de priorité Priority (voir 8.9) avec
lesquels il est permis d’invoquer l’opération.
8.2.12 Le champ 8zResultPriority (priorité de résultat) spécifie les niveaux de priorité Priority (voir 8.9) avec
lesquels il est permis de retourner le résultat de l’opération. Si le champ &returnResult a la valeur FALSE (faux), ce
champ sera omis.
8.2.13 Le champ &operationCode (code d’opération) spécifie lorsqu’il est présent la valeur Code (voir 8.8) utilisée
pour identifier l’opération, par exemple pour l’invoquer.
NOTE - Une opkation qui n’a pas un &operationCode ne peut être invoquée par une PDU &Invoke{} (voir 9.3). De fait,
toutes les opérations doivent se voir affecter un code d’opération sauf lorsqu’il est prévu de les utiliser dans des circonstances
particulières (les opérations de rattachement par exemple).
83 l Erreur
Une erreur est un rapport notifiant l’échec d’exécution d’une opération. La classe d’objets informationnels
8.3.1
ERROR, à laquelle toutes les erreurs appartiennent, est spécifiée comme suit, les differents champs étant décrits dans
8.3.2 à 8.3.5:
ERROR ::= CLASS
{
&ParameterType OPTIONAL,
¶meterTypeOptional BOOLEAN OPTIONAL,
&ErrorPriority Priority OPTIONAL,
&errorCode
Code UNIQUE OPTIONAL
WITH SYNTAX
[PARAMETER &ParameterType [OPTIONAL ¶meterTypeOptional]]
[PRIORITY &ErrorPriority]
[CODE &errorCode]
8.3.2 Le champ &ParameterType (type de paramètre) spécifie le type de données du paramètre de l’erreur. Si, pour
une erreur donnée, ce champ est omis, l’erreur ne prend alors pas de valeur de paramètre.
8.3.3 Le champ JkparameterTypeOptional (type de paramètre optionnel), qui ne peut exister que lorsque le champ
&ParameterType est lui-même présent, spécifie si le type de données de la valeur retournée en tant que paramètre
qualifiant l’erreur peut optionnellement être présent. Si ce champ est absent ou s’il prend la valeur FALSE (faux), la
valeur de &ParameterType ne peut être omise de la PDU ReturnError{} (voir 9.5).
8.3.4 Le champ &ErrorPriority (priorité d’erreur) spécifie les niveaux de priorité Priority (voir 8.9) avec lesquels
il est permis de retourner le résultat d’échec de l’opération.
8.3.5 Le champ &errorCode (code d’erreur) spécifie la valeur Code (voir 8.8) utilisée pour identifier l’erreur, par
exemple pour la retourner.
NOTE - Une erreur qui n’a pas un &errorCode ne peut être retournée par la PDU &ReturnError{} définie ci-dessous. De
fait, toutes les erreurs doivent se voir affecter un code d’erreur sauf lorsque leur utilisation se fait dans des circonstances particulières,
comme pour les erreurs de rattachement.
8 Rec. UIT-T X.880 (1994 F)
ISOKEI 13712-l : 1995 (F)
84 b Lot d’opérations
8.4.1 Un lot d’opérations est la spécification des rôles tenus par un couple d’objets communicants, en termes
d’opérations que chacun des deux objets (l’invocateur) peut demander à l’autre (l’exécutant) d’exécuter. Lorsque le lot
d’opérations est asymétrique, les termes «client» et «serveur» sont utilisés pour désigner les deux objets impliqués. La
classe d’objets informationnels OPERATION-PACKAGE, à laquelle tous les lots d’opérations appartiennent, est
spécifiée comme suit, les différents champs étant décrits dans 8.4.2 a 8.4.7:
OPERATION-PACKAGE ::= CLASS
&Both OPERATION OPTIONAL,
OPERATION OPTIONAL,
&Consumer
&Supplier OPERATION OPTIONAL,
&id OB JECT IDENTIFIER UNIQUE OPTIONAL
WITH SYNTAX
[OPERATIONS &Both]
[CONSUMER INVOKES &Supplier]
[SUPPLIER INVOKES &Consumer]
&id]
D
8.4.2 Le champ &Both (couple) spécifie un ensemble d’opérations OPERATION que les deux objets peuvent
exécuter. Ce champ peut être omis.
8.4.3 Le champ &Consumer (client) spécifie un ensemble d’opérations OPERATION que l’un des deux objets, le
client, peut exécuter. Ce champ peut être omis, auquel cas le client ne pourra exécuter que les opérations spécifiées par le
champ &Both (couple).
8.4.4 Le champ &Supplier (serveur) spécifie un ensemble d’opérations OPERATION que l’un des deux objets, le
serveur, peut exécuter. Ce champ peut être omis, auquel cas le serveur ne pourra exécuter que les opérations spécifiées
par le champ &Both (couple).
NOTE - Un opérateur switch{} a été défini (voir 10.12) pour permettre de dériver un lot d’opérations d’un autre par simple
commutation des rôles.
8.4.5 Le champ &id (identzjkateur) spécifie, lorsqu’il est présent, la valeur OBJECT IDENTIFIER (identificateur
d’objet) utilisée pour identifier ce lot, s’il doit par exemple être annoncé ou négocié.
NOTE - Un lot d’opérations qui n’a pas d’identificateur &id ne peut être ni annoncé ni négocié.
8.4.6 Toutes les opérations incluses (directement ou indirectement) dans les champs &Both, &Consumer et
&Supplier auront des codes d’opération 8zoperationCode distincts.
8.4.7 Toutes les erreurs incluses dans les champs &Errors de toutes les opérations concernées (voir 8.4.6) auront
des codes d’erreur &errorCode distincts.
85 . Lot de connexion
8.51 Un lot de connexion est la spécifïcation des opérations et de la qualité de service intervenant dans
l’établissement et la libération dynamiques d’une association. Un lot de connexion ne sera spécifié que si des opérations
de rattachement et de détachement sont utilisées pour respectivement établir et libérer dynamiquement une association.
Rec. UIT-T X.880 (1994
...
lSO/CEI
NORME
13712-l
INTERNATIONALE
Première édition
1995-09-15
Technologies de l’information -
Opérations distantes: Concepts, modèle et
notation
- Remote Operations: Concepts, mode/ and
Information technology
notation
Numéro de référence
ISO/CEI 13712-I :1995(F)
ISOKEI 137124: 1995(F)
Sommaire
Page
Domaine d’application .
Références normatives .
2.1 Recommandations et Normes internationales identiques .
2.2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
....... 2
2.3 .
Autres références
Définitions .
3.1 Définitions relatives au modèle de référence OS1 .
3.2 Définitions relatives à la notation ASN. 1 .
3.3 Définitions relatives au service ROS .
Abréviations .
Conventions .
Modèle ROS .
Réalisation des services ROS .
Concepts ROS .
81 Introduction .
*:2 Opération .
8.3 Erreur .
8.4 Lot d’operations
...................................................................................................................................
8.5 Lot de connexion .
8.6 Contrat d’association .
8.7 Classe d’objets ROS .
8.8 Code .
8.9 Priorité .
Protocole générique ROS .
91 .
Introduction . 12
92 Type ROS . 12
9:3 Type Invoke . 13
96 . Type Reject .
97 Type RejectProblem .
9:s Type InvokeId .
99 Valeur NoInvokeId
............................................................................................................................. 18
9’10 Ensemble Errors . 18
9’11 Type Bind .
9’12 . Type Unbind .
0 ISOKEI 1995
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publi-
cation ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun
procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans
l’accord écrit de l’éditeur.
ISOKEI Copyright Office l Case Postale 56 l CH-121 1 Genève 20 l Suisse
Version française tirée en 1996
Imprimé en Suisse
ii
ISOKEI 13712-l: 1995(F)
@ ISOKEI
10 Définitions utiles . 19
10.1 Introduction . 19
10.2 Opération emptyBind .
.....................................................................................................................
10.3 Opération empty Unbind 20
10.4 Notification refuse . 20
10.5 Opération no-op . 20
10.6 Ensemble Forward . 20
10.7 Ensemble Reverse .
10.8 Ensemble ConsumerPerforms .
10.9 Ensemble SupplierPerforms . 21
10.10 Ensemble AllOperations . 21
10.11 Opération recode . 22
10.12 Lot d’opérations switch . 22
10.13 Lot d’opérations combine .
10.14 Type ROS-SingleAS . 23
10.15 Type ROS-ConsumerAS . 23
10.16 Type ROS-SupplierAS . 23
Annexe A - Modules ASN. 1 . 24
Annexe B - Directives pour l’utilisation de la notation . 31
B. 1 Exemples d’opérations et d’erreurs .
B.2 Exemples de lots d’opérations et de l’utilisation de l’opérateur switch .
B.3 Exemples d’opérations de rattachement et de détachement .
Exemples de lots de connexion
B.4 . 34
B.5 Exemples de contrat d’association . 34
B.6 Exemples d’objets ROS . 34
B.7 Exemple d’utilisation des opérateurs Forward{ } et Reverse{ } . 35
B.8 Exemple d’utilisation des opérateurs ConsumerPerforms { ), SupplierPerforms { ) et
AllOperations ( ) . 36
Annexe C - Migration des macro-instructions ROS . 37
C. 1 Introduction . 37
C.2 Macro-instruction OPERATION . 37
C.3 Macro-instruction ERROR . 38
.......................................................................................................................
C.4 Macro-instruction Bind 38
...................................................................................................................
C.5 Macro-instruction Unbind 38
Annexe D - Affectation de valeurs d’identificateurs d’objets . 39
. . .
ISOKEI 13712=1:1995(F)
0 ISOKEI
Avant-propos
L’ISO (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes
nationaux membres de I’ISO ou de la CE1 participent au développement de
Normes internationales par l’intermédiaire des comités techniques créés par
l’organisation concernée afin de s’occuper des différents domaines particuliers de
l’activité technique. Les comités techniques de I’ISO et de la CE1 collaborent
dans des domaines d’intérêt commun. D’autres organisations internationales,
gouvernementales ou non gouvernementales, en liaison avec I’ISO et la CE1
participent également aux travaux.
Dans le domaine des technologies de l’information, 1’ISO et la CE1 ont créé un
comité technique mixte, 1’ISOKEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux
pour approbation, avant leur acceptation comme Normes internationales. Les
Normes internationales sont approuvées conformément aux procédures qui
requièrent l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 137 12- 1 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de I?nformation, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec I’IUT-T. Le texte identique est publié en tant que
Recommandation IUT-T X.880.
La présente partie de I’ISOKEI 137 12 est une révision partielle de
1’ISOKEI 9072-l: 1989 et 1’ISOKEI 9072-2: 1989.
L’ISOKEI 137 12 comprend les parties suivantes, présentées sous le titre général
Technologies de l’information - Opérations distantes:
Partie 1: Concepts, modèle et notation
- Partie 2: Réalisations OSI - Définition du service de l’élément de service
d’opérations distantes (ROSE)
- Partie 3: Réalisations OSI - Spécification du protocole de l’élément de
service d’opérations distantes (ROSE)
L’annexe A fait partie intégrante de la présente partie de l’ISO/CEI 137 12. Les
annexes B à D sont données uniquement à titre d’information.
1v
@ ISOKEI ISOKEI 137124: 1995(F)
Introduction
Le concept d’opérations distantes (ROS) est un paradigme de la communication interactive entre objets. En tant que tel,
il peut être utilisé pour la conception et la spécification des applications réparties. L’interaction de base mise en jeu est
l’invocation d’une opération par un objet (l’invocateur), son exécution par un autre (l’exécutant), éventuellement suivie
par un rapport sur le rhultat de l’opération retourné à l’invocateur.
Les concepts d’opérations distantes (ROS) sont abstraits, et peuvent être réalisés de multiples manières. Ainsi, les objets
dont les interactions mettent en jeu les concepts d’opérations distantes peuvent être séparés par une interface logicielle ou
par un réseau OSI.
La présente Recommandation I Norme internationale décrit les concepts et le modèle de service ROS. Elle utilise
l’ASN.1 pour spécifier les classes d’objets informationnels correspondant aux concepts fondamentaux du service ROS,
tels que les classes opération et erreur. Ces éléments fournissent à leur tour la notation qui permet aux concepteurs de
spécifier des instances particulières de ces classes, comme des opérations ou des erreurs spécifiques.
La présente Recommandation I Norme internationale fournit un ensemble générique d’unités de données de protocole
(PDU) qui peuvent être utilisées pour réaliser les concepts de service ROS entre objets distants les uns des autres. Ces
PDU sont utilisées dans les applications OS1 des concepts de service ROS, qui sont spécifiées dans les
Recommandations I Normes internationales jumelles de celle-ci.
La présente Recommandation I Norme internationale fournit également un certain nombre de définitions d’ordre général
pour les concepteurs d’applicati .ons à base d’opérations distan tes ROS.
L’Annexe A fait partie intégrante de la présente Recommandation I Norme internationale.
Les Annexes B, C et D ne font pas partie intégrante de la présente Recommandation i Norme internationale.
Page blanche
ISOKEI 13712-l : 1995 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION -
OPÉRATIONS DISTANTES: CONCEPTS, MODÈLE ET NOTATION
1 Domaine d’application
La présente Recommandation I Norme internationale spécifie le service d’opérations distantes (ROS) et utilise la notation
de syntaxe abstraite numéro un (ASN.l) pour définir les classes d’objets informationnels correspondant aux concepts
fondamentaux du service ROS. Ces éléments fournissent à leur tour la notation qui permettra aux concepteurs
d’applications de spécifier des instances particulières de ces classes.
La présente Recommandation I Norme internationale renferme également une collection de définitions qui spécifient le
protocole générique d’échange entre objets communiquant selon les concepts du service ROS. Les’ Recommandations I
Normes internationales associées à celle-ci utilisent ces définitions pour définir les unités de données de protocole, les
primitives de service et les définitions de contexte applicatif qui interviennent dans la réalisation OS1 du service ROS.
Un certain nombre de définitions d’intérêt général pour les concepteurs des applications à base d’opérations distantes sont
également données.
Aucune spécification n’est imposée quant à la conformité à la présente Recommandation I Norme internationale.
Références normatives
Les Recommandations de FUIT-T et les Normes internationales suivantes contiennent des dispositions qui, par suite de
la référence qui y est faite, constituent des dispositions valables pour la présente Spécification. Au moment de la
publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes internationale sont sujettes à
révision et les parties prenantes aux accords fondés sur la présente Spécification sont invitées à rechercher la possibilité
d’appliquer les éditions les plus récentes des Recommandations et Normes internationales indiquées ci-après. Les
membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de I’UIT tient à jour une liste des Recommandations UIT-T en vigueur.
21 . Recommandations et Normes internationales identiques
-
Recommandation UIT-T X.680 (1994) I ISOKEI 8824-: 1995, Technologie de l’information - Notation de
syntaxe abstraite numéro un: Spécification de la notation de base.
-
Recommandation UIT-T X.681 (1994) I ISOKEI 8824-2:1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un: Spécijkation des objets informationnels.
-
Recommandation UIT-T X.682 (1994) I ISOKEI 8824-3: 1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un: Spécifkation des contraintes.
-
Recommandation UIT-T X.683 (1994) I ISOKEI 8824-4: 1995, Technologie de l’information - Notation
de syntaxe abstraite numéro un: Paramétrage des spécifications ASN.1.
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l : 1994, Technologie de l’information -
Interconnexion de systèmes ouverts - Modèle de référence de base. Le modèle de base.
-
Recommandation UIT-T X.88 1 (1994) I ISOKEI 137 12-2: 1995, Technologie de Z’information -
Définition du service de 1 ‘élément de service d’opérations
Opérations distantes: Applications OSI -
distantes.
-
Recommandation UIT-T X.882 (1994) I ISOKEI 13712-3:1995, Technologie de Z’information -
Opérations distantes: Applications OSI - Spécification du protocole de 1 ‘élément de service d’opérations
distantes.
Rec. UIT-T X.880 (1994 F)
ISOKEI 13712-l : 1995 (F)
Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
22 .
-
Recommandation X.219 du CCITT (1988), Opérations distantes: modèle, notation et définition du
service.
ISOICEI 9072- 1: 1989, Systèmes de traitement de l’information - Communication de texte - Opérations à
distance - Partie 1: Modèle, notation et définition du service.
-
Recommandation X.229 du CCITT (1988), Opérations distantes: Spécification du protocole.
ISOKEI 9072-2: 1989, Systèmes de traitement de l’information - Communication de texte - Opérations à
distance - Partie 2: Spécijkation du protocole.
23 . Autres références
-
Recommandation X.407 du CCITT (1988), Systèmes de messagerie: Conventions pour la définition des
services abstraits.
3 Définitions
31 . Définitions relatives au modèle de référence OS1
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.200 1
ISOKEI 7498- 1:
syntaxe abstraite;
a>
b) unité de données de protocole;
c) qualité de service.
32 . Définitions relatives à la notation ASN.1
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.680 I
ISOKEI 8824- 1:
type (de données);
a>
valeur (de données).
b)
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.681 I
ISOKEI 8824-2: ’
champ;
a)
objet (informationnel);
b)
classe d’objets (informationnels);
C)
ensemble d’objets (informationnels).
d)
La présente Recommandation I Norme internationale utilise le terme suivant, défini
dans la Rec. UIT-T X.682 I ISOKEI 8824-3:
contrainte;
a>
valeur d’exception.
b)
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.683 I
ISOKEI 8824-4:
paramétré.
2 Rec. UIT-T X.880 (1994 F)
ISOKEI 13712-l : 1995 (F)
33 . Définitions relatives au service ROS
La présente Recommandation I Norme internationale définit les termes suivants:
3.3.1 argument: Valeur de données accompagnant l’invocation d’une opération.
3.3.2 association: Relation entre un couple d’objets, servant de contexte à l’invocation et à l’exécution d’une
opération.
3.3.3 contrat d’association: Spécification des rôles d’un couple d’objets communicants pouvant être associés l’un à
l’autre.
3.3.4 asymétrique: Qualificatif d’un lot d’opérations (ou d’un contrat d’association), pour lequel les ensembles
d’opérations pouvant être exécutées par chacune des deux parties diffèrent l’un de l’autre.
lot de connexion: Spécification des rôles d’un couple d’objets communicants dans l’établissement
3.3.5 ou la
libération dynamique de leur association.
3.3.6 contrat: Ensemble de spécifications imposées à un ou plusieurs objets prescrivant un comportement collectif.
3.3.7 erreur: Rapport notifiant l’échec d’exécution d’une opération.
3.3.8 opération liée: Opération invoquée, pendant l’exécution d’une autre opération, par le (précédent) exécutant et
qui doit être exécutée par le (précédent) invocateur.
3.3.9 objet: Modèle de système (ou éventuellement de sous-système autonome), caractérisé par son état initial et son
comportement découlant d’interactions externes à travers des interfaces bien définies.
3.3.10 opération: Fonction qu’un objet (l’invocateur) peut demander à un autre (l’exécutant) d’exécuter.
3.3.11 lot d’opérations: Collection d’opérations liées utilisée pour spécifier les rôles pour un couple d’objets
communicants, chaque opération pouvant être invoquée par un des deux objets ou par les deux pour être exécutée par
l’autre.
3.3.12 paramètre (d’une erreur): Valeur de données pouvant accompagner le rapport d’erreur.
résultat: Valeur de données pouvant accompagner le rapport d’exécution avec succès d’une opération.
3.3.13
3.3.14 objet ROS: Objet dont les interactions avec d’autres objets sont décrites à l’aide des concepts d’opérations
distantes ROS.
3.3.15 symétrique: Qualificatif d’un lot d’opérations (ou d’un contrat d’association) dans lequel les deux parties sont
capables d’exécuter le même ensemble d’opérations.
3.3.16 synchrone: Qualificatif d’une opération qui, une fois invoquée, interdit à son invocateur d’invoquer une autre
opération synchrone (avec le même exécutant désigné) tant que son résultat n’a pas été notifié.
4 Abréviations
Pour les besoins de la présente Recommandation I Norme internationale, les abréviations suivantes sont utilisées:
ASN. 1 Notation de syntaxe abstraite numéro un (abstract syntax notation one)
PDU Unité de données de protocole (protocol data unit)
Qualité de service (quality of service)
QOS
RO (ou ROS) Opérations distantes (remote operations)
5 Conventions
La présente Recommandation I Norme internationale utilise I’ASN. 1 pour définir:
a) les classes d’objets informationnels correspondant aux concepts ROS; elle indique également la notation
avec laquelle les concepteurs d’applications ROS peuvent spécifier des instances particulières de ces
classes;
b) les objets informationnels particuliers de ces classes;
c) les PDU du protocole générique d’opérations distantes (protocole ROS);
d) les types de données nécessaires à ces définitions.
Rec. UIT-T X.880 (1994 F)
ISOKEI 137124 : 1995 (F)
Beaucoup de ces définitions sont paramétrées; pour les compléter, les utilisateurs doivent en préciser les paramètres
effectifs.
6 Modèle ROS
Le concept d’opérations distantes (ROS) est un paradigme de la communication interactive entre objets. Les objets dont
les interactions sont décrites et spécifiées a l’aide de concepts ROS sont des objets ROS. L’interaction de base mise en
jeu est l’invocation d’une opération par un objet ROS (l’invocateur) et son exécution par un autre (l’exécutant).
échec) peut entraîner le renvoi par l’exécutant à l’invocateur
L’achèvement de l’opération (sur u n succès ou un d’un
rapport sur le résultat de l’opération. Ceci est illustré à la Figure 1.
Un rapport notifiant l’achèvement avec succès d’une opération est un résultat; un rapport notifiant l’achèvement d’une
opération sur un échec est une erreur.
Pendant l’exécution d’une opération, l’exécutant peut invoquer des opérations liées, à exécuter par l’invocateur de
l’opération d’origine.
‘opération doivent être connues à la fois de l’invocateur
Pour un interfonctionnement correct, certaines des propriétés de 1
et de l’exécutant, notamment:
-
si des rapports doivent être envoyés en retour, et dans l’affirmative, lesquels;
-
les types des valeurs accompagnant le cas échéant les invocations d’opérations et les notifications
envoyées en retour;
-
les opérations pouvant le cas échéant être liées a l’opération d’origine;
-
la valeur de code a utiliser pour distinguer l’opération en question des autres opérations pouvant être
invoquées.
Objet ROS Objet ROS
(exdcutant)
(invocateur)
l-604 150-94/dO 1
Figure 1 - Invocation, exécution et retour d’une opération
Les capacités d’interfonctionnement des (couples d’)objets ROS d’une quelconque classe d’objets ROS sont définies en
termes d’ensembles d’opérations liées appelés lots d’opérations. Un lot peut être symétrique, auquel cas il est défini par
un seul ensemble d’opérations que chaque objet ROS du couple peut invoquer (pour être exécutées par l’autre). Ou alors,
le lot peut être asymétrique, auquel cas il est défini par deux ensembles d’opérations, chacun pouvant être invoqué par
un seul des deux objets du couple. Pour les besoins de la définition d’un lot asymétrique, les objets ROS sont
arbitrairement étiquetés l’un comme client et l’autre comme serveur.
NOTE 1 - Alors que ces étiquettes sont en général arbitraires, il arrivera souvent que leur affectation soit intuitive, l’un des
objets offrant manifestement un service que l’autre consomme.
Un couple d’objets ROS doivent être liés par une association servant de contexte à l’invocation et à l’exécution
d’opérations. Chaque association de cette sorte est gouvernée par un contrat d’association. Un contrat est spécifié en
termes de lots qui déterminent (collectivement) les opérations qui peuvent être invoquées dans le cadre de l’association.
Si les spécifications de contrat comprennent un ou plusieurs lots asymétriques, le contrat est lui-même asymétrique. Pour
les besoins de la spécification d’un contrat d’association asymétrique, les deux objets ROS qui établissent l’association
entre eux sont étiquetés l’un comme initiateur et lautre comme répondeur.
Une association peut être créée ou dissoute par des moyens «hors ligne». Mais elle peut être aussi établie ou libérée
dynamiquement. Une des options décrites dans la présente Recommandation I Norme internationale et permettant
d’établir et de libérer dynamiquement une association est réalisée par l’invocation et l’exécution des opérations spéciales
respectivement de rattachement et de détachement. Le contrat de cette dernière catégorie d’associations inclut un lot
de connexion comprenant les opérations particulières de rattachement et de détachement à utiliser.
4 Rec. UIT-T X.880 (1994 F)
ISOKEI 13712-l : 1995 (F)
ations peut
NOTE 2 - Le mécanisme d’établissement et de libération également être assuré par d’autres moyens
dans d’autres Recommandations I Normes internationales.
Une association necessite qu’existe entre les deux objets une relation qui corresponde a l’acceptation par ces objets des
termes d’un quelconque contrat d’association
NOTE 3 - Cette spécifïcation ne traite pas des moyens par lesquels de telles relations sont établies ou terminées.
Dans ce qui suit, les seuls objets qu’on voit impliqués dans une opération sont l’invocateur et l’executant. Toutefois,
l’invocateur et l’exécutant d’une opération ne sont généralement pas directement rattachés l’un à l’autre, mais connectés
par un intermédiaire quelconque à travers lequel sont transmis les invocations et les rapports en retour. La Figure 2
illustre ce schéma élargi.
Objet ROS Intermddiaire Objet ROS
(inwcateur) (exdwtant)
TlSO4 160-94/dO2
Figure 2 - Schéma élargi
L’intermédiaire peut introduire un retard et une possibilité d’échec ou d’inexactitude dans la transmission tant des
invocations que des rapports, ainsi que dans l’établissement, la libération et la maintenance des associations. Il peut
également introduire une possibilité de menace pour la sécurité de l’association et de ses opérations. L’importance de ces
éléments (ainsi que d’autres facteurs) sont décrits dans le cadre de la qualité de service (QOS).
Les contrats d’association peuvent dans ce cas être vus comme tripartites, la partie tierce étant l’intermédiaire. Les
obligations de l’intermédiaire au titre du contrat sont de satisfaire aux spécifications de qualité de service.
NOTE 4 - Ultérieurement, les spécifications objectifs et les spécifications minimales en matière de qualité de service
pourront faire partie de la spécification des opérations, des lots d’opérations et du contrat d’association lui-même. Aux spécifications
de chacun de ces niveaux correspondent différents aspects de qualité de service.
Réalisation des services ROS
Une réalisation de service ROS implique la définition d’un intermédiaire approprié permettant de véhiculer les
invocations et les rapports entre objets ROS. Un tel intermédiaire peut par exemple comprendre:
une capacité de passation de message ou d’appel de procédure permettant de programmer séparément
a)
l’invocateur et l’exécutant d’une opération dans des modules logiciels distincts dans un même ordinateur;
une capacité de communication, permettant de programmer l’invocateur et l’exécutant d’une opération
b)
dans des ordinateurs distincts.
Une application peut être polyvalente, et peut alors être utilisée pour prendre en charge un contrat d’association
quelconque. D’autres applications peuvent être spécifiques et n’accepter que des contrats d’un type particulier.
La Figure 3 illustre une façon de réaliser un service ROS avec un système de communication en intermédiaire, schéma
qui sera vraisemblablement largement utilisé.
TE041 70-94/dO3
Figure 3 - Service ROS avec un système de comrnmication en intermédiaire
Rec. UIT-T X.880 (1994 F)
ISO/CEI 13712-l : 1995 (F)
Dans cette approche, l’intermédiaire est constitue d’objets pivots @tub), un pour chaque objet ROS, plus un objet de
transfert d’information. L’objet pivot associé à chaque objet ROS apparaît comme jouant le rôle de l’objet ROS
partenaire. En fait, il n’invoque ni n’exécute aucune opération, et se contente de transformer les invocations et les
rapports en PDU et vice versa. Ces PDU sont échangées entre les pivots au moyen de l’objet de transfert d’information.
L’invocateur adresse donc son invocation au pivot qui lui est associé, lequel forme une PDU décrivant l’invocation. Le
pivot utilise ensuite la capacité de transfert d’information pour transférer la PDU à l’autre pivot. Ce dernier interprète la
PDU puis invoque l’opération appropriée de l’objet ROS qui lui est associé, c’est-à-dire l’exécutant. Une fois l’opération
exécutée, l’exécutant remet s’il y a lieu un rapport au pivot qui lui est associé. Ce dernier forme la PDU décrivant le
rapport, puis utilise la capacité de transfert d’information pour transférer la PDU à l’autre pivot, qui l’interprète et notifie
le résultat a l’invocateur.
L’article 9 définit une collection de PDU appropriées.
Différentes capacités de transfert d’information peuvent être utilisées pour réaliser un système ROS de ce type. Parmi
celles-ci, les capacités de transfert d’information de l’architecture OS1 revêtent une importance particulière. Les deux
UIT-TX.881 i ISO/CEI 13712-2 et UIT-T X.882 1
Recommandations I Normes internationales jumelles
ISOKEI 137 12-3 décrivent de telles réalisations.
Concepts ROS
81 . Introduction
8.1.1 Cet article définit les classes d’objets informationnels suivantes, qui correspondent aux concepts de base
d’opérations distantes, et spécifie les caractéristiques des objets de ces classes:
-
OPERATION (décrit les opérations)
-
ERROR (décrit les erreurs)
-
OPERATION-PACKAGE (décrit les lots d’opérations)
-
CONNECTION-PACKAGE (décrit les lots de connexion)
-
CONTRACT (décrit les contrats d’association)
-
ROS-OB JECT-CLASS (décrit les classes d’objets ROS)
8.1.2 Les classes d’objets informationnels sont définies en ASN.1. Ces définitions servent ensuite aux concepteurs
d’applications de service ROS pour spécifier des instances particulières de ces classes. Les concepteurs sont encouragés à
adopter cette approche pour leurs spécifications, mais pas obligés de le faire. Si une autre approche est suivie, la
spécification résultante devra comprendre une description sur la manière d’en dériver une notation valide, ou faire
réference à une telle explication.
NOTE - Un certain nombre de spécifications existantes utilisent la notation en macro-instructions ASN. 1 (définie dans des
versions antérieures de la présente Recommandation I Norme internationale: voir la Rec. X.219 du CCITT I ISOKEI 9072-l) pour
spécifier les opérations, les erreurs et les autres classes d’objets informationnels se rapportant au service ROS. L’Annexe C décrit la
manière de transformer ces macro-instructions dans la notation indiquée. Ces macro-instructions ne devront plus être utilisées pour les
nouvelles applications.
6 Rec. UIT-T X.880 (1994 F)
ISOICEI 13712-l : 1995 (F)
82 . Opération
Une opération est une fonction qu’un objet (l’invocateur) peut demander à un autre objet (l’exécutant)
8.2.1
d’exécuter. La classe d’objets informationnels OPERATION, à laquelle toutes les opérations appartiennent, est spécifiée
comme suit, les différents champs étant décrits dans 8.2.2 a 8.2.13:
OPERATION t:= CLASS
&ArgumentType OPTIONAL,
&argumentTypeOptional BOOLEAN OPTIONAL,
&returnResult
BOOLEAN DEFAULT TRUE,
&ResultType OPTIONAL,
&resultTypeOptional BOOLEAN OPTIONAL,
&Errors ERROR OPTIONAL,
&Linked OPERATION OPTIONAL,
&synchronous BOOLEAN DEFAULT FALSE,
&alwaysReturns BOOLEAN DEFAULT TRUE,
&InvokePriority Priority OPTIONAL,
&ResultPriority Priority OPTIONAL,
&operationCode Code UNIQUE OPTIONAL
WITH SYNTAX
[ARGUMENT &ArgumentType [OPTIONAL &argumentTypeOptional]]
[RESULT &ResultType
[OPTIONAL &resultTypeOptional]]
[RETURN RESULT &returnResult]
[ERRORS &Errors]
[LINKED &Linked]
[SYNCHRONOUS &synchronous]
[ALWAYS RESPONDS &alwaysReturns]
[INVOKE PRIORITY &InvokePriority]
[RESULT-PRIORITY
&ResultPriority]
[CODE &operationCode]
8.2.2 Le champ &ArgumentType “argument) spécifie le type de donnees de l’argument de l’opération. Si,
(
type d
opération donnée, ce champ es
pour une t omis, l’opération ne prend pas de valeur d’argument.
8.2.3 Le champ &argumentTypeOptional (type d’argument optionnel), qui ne peut exister que lorsque le champ
&ArgumentType est lui-même présent, spécifie si le type de données de l’argument de l’opération peut optionnellement
être omis. Si ce champ est absent ou s’il prend la valeur FALSE vaux), la valeur de &ArgumentType ne peut être
omise de la PDU Invoke{} (voir 9.3).
8.2.4 Le champ &returnResult (retourner le résultat) spécifie si un résultat doit être retourné en cas d’achèvement
avec succès de l’opération, et prend la valeur TRUE (vrai) si c’est le cas, FALSE (faux) sinon.
Le champ &ResultType (type de résultat) spécifie le type de données de la valeur retournée avec le résultat de
8.2.5
l’opération. Si cette indication est omise, l’opération ne retourne pas de valeur de résultat. Ce champ est omis si le champ
&returnResult a la valeur FALSE (faux).
8.2.6 Le champ &resultTypeOptional (type de résultat optionneZ), qui ne peut exister que lorsque le champ
&ResultType est lui-même présent, spécifie si le type de données de la valeur retournée comme résultat de la bonne
exécution de l’opération peut optionnellement être omis. Si ce champ est absent ou s’il prend la valeur FALSE vaux), la
valeur de &ResultType ne peut être omise de la PDU ReturnResult{} (voir 9.4).
8.2.7 Le champ &Errors (erreurs) spécifie un ensemble d’erreurs, l’une quelconque de ces valeurs pouvant être
retournée pour notifier l’échec d’exécution de l’opération. Si ce champ est omis, alors soit que l’échec d’exécution de
l’opération est impossible, soit qu’il n’est pas notifié.
8.2.8 Le champ &alwaysReturns (toujours retourner) spécifie s’il faut toujours retourner le résultat de l’opération,
(vrai) si c’est le cas, FALSE (faux) sinon. Si ce champ a la valeur TRUE (vrai), au moins l’un
et prend la valeur TRUE
des deux champs &returnResult ou &Errors doit être présent.
8.2.9 Le champ &Linked (lié) spécifie, lorsqu’il est présent, un ensemble d’opérations, l’une quelconque de ces
opérations pouvant être invoquée en tant qu’opération liée pendant l’exécution de l’opération d’origine. Si ce champ est
omis, aucune opération ne peut être liée à l’invocation de l’opération en cours.
Rec. UIT-T X.880 (1994 F) 7
ISOKEI 13712-l : 1995 (F)
8.2.10 Le champ &synchronous (synchwze) spécifie si l’opération est synchrone ou non, et prend la valeur TRUE
(vrai) si c’est le cas, FALSE (faux) sinon. Si le champ &returnResult a la valeur FALSE (faux), ce champ aura
toujours la valeur FALSE (faux). Si le champ &synchronous a la valeur TRUE (vrai), ceci implique qu’aucune autre
opération synchrone ne pourra être invoquée par cette source jusqu’à la réception du rapport d’exécution en retour.
NOTE - La combinaison des champs &alwaysReturns et &synchronous remplace le concept antérieur de «classe
d’opération» défini dans la Rec. X.21 9 du CCITT I ISOKEI 9072- 1.
8.2.11 Le champ MnvokePriority (priorité de I?nvocation) spécifie les niveaux de priorité Priority (voir 8.9) avec
lesquels il est permis d’invoquer l’opération.
8.2.12 Le champ 8zResultPriority (priorité de résultat) spécifie les niveaux de priorité Priority (voir 8.9) avec
lesquels il est permis de retourner le résultat de l’opération. Si le champ &returnResult a la valeur FALSE (faux), ce
champ sera omis.
8.2.13 Le champ &operationCode (code d’opération) spécifie lorsqu’il est présent la valeur Code (voir 8.8) utilisée
pour identifier l’opération, par exemple pour l’invoquer.
NOTE - Une opkation qui n’a pas un &operationCode ne peut être invoquée par une PDU &Invoke{} (voir 9.3). De fait,
toutes les opérations doivent se voir affecter un code d’opération sauf lorsqu’il est prévu de les utiliser dans des circonstances
particulières (les opérations de rattachement par exemple).
83 l Erreur
Une erreur est un rapport notifiant l’échec d’exécution d’une opération. La classe d’objets informationnels
8.3.1
ERROR, à laquelle toutes les erreurs appartiennent, est spécifiée comme suit, les differents champs étant décrits dans
8.3.2 à 8.3.5:
ERROR ::= CLASS
{
&ParameterType OPTIONAL,
¶meterTypeOptional BOOLEAN OPTIONAL,
&ErrorPriority Priority OPTIONAL,
&errorCode
Code UNIQUE OPTIONAL
WITH SYNTAX
[PARAMETER &ParameterType [OPTIONAL ¶meterTypeOptional]]
[PRIORITY &ErrorPriority]
[CODE &errorCode]
8.3.2 Le champ &ParameterType (type de paramètre) spécifie le type de données du paramètre de l’erreur. Si, pour
une erreur donnée, ce champ est omis, l’erreur ne prend alors pas de valeur de paramètre.
8.3.3 Le champ JkparameterTypeOptional (type de paramètre optionnel), qui ne peut exister que lorsque le champ
&ParameterType est lui-même présent, spécifie si le type de données de la valeur retournée en tant que paramètre
qualifiant l’erreur peut optionnellement être présent. Si ce champ est absent ou s’il prend la valeur FALSE (faux), la
valeur de &ParameterType ne peut être omise de la PDU ReturnError{} (voir 9.5).
8.3.4 Le champ &ErrorPriority (priorité d’erreur) spécifie les niveaux de priorité Priority (voir 8.9) avec lesquels
il est permis de retourner le résultat d’échec de l’opération.
8.3.5 Le champ &errorCode (code d’erreur) spécifie la valeur Code (voir 8.8) utilisée pour identifier l’erreur, par
exemple pour la retourner.
NOTE - Une erreur qui n’a pas un &errorCode ne peut être retournée par la PDU &ReturnError{} définie ci-dessous. De
fait, toutes les erreurs doivent se voir affecter un code d’erreur sauf lorsque leur utilisation se fait dans des circonstances particulières,
comme pour les erreurs de rattachement.
8 Rec. UIT-T X.880 (1994 F)
ISOKEI 13712-l : 1995 (F)
84 b Lot d’opérations
8.4.1 Un lot d’opérations est la spécification des rôles tenus par un couple d’objets communicants, en termes
d’opérations que chacun des deux objets (l’invocateur) peut demander à l’autre (l’exécutant) d’exécuter. Lorsque le lot
d’opérations est asymétrique, les termes «client» et «serveur» sont utilisés pour désigner les deux objets impliqués. La
classe d’objets informationnels OPERATION-PACKAGE, à laquelle tous les lots d’opérations appartiennent, est
spécifiée comme suit, les différents champs étant décrits dans 8.4.2 a 8.4.7:
OPERATION-PACKAGE ::= CLASS
&Both OPERATION OPTIONAL,
OPERATION OPTIONAL,
&Consumer
&Supplier OPERATION OPTIONAL,
&id OB JECT IDENTIFIER UNIQUE OPTIONAL
WITH SYNTAX
[OPERATIONS &Both]
[CONSUMER INVOKES &Supplier]
[SUPPLIER INVOKES &Consumer]
&id]
D
8.4.2 Le champ &Both (couple) spécifie un ensemble d’opérations OPERATION que les deux objets peuvent
exécuter. Ce champ peut être omis.
8.4.3 Le champ &Consumer (client) spécifie un ensemble d’opérations OPERATION que l’un des deux objets, le
client, peut exécuter. Ce champ peut être omis, auquel cas le client ne pourra exécuter que les opérations spécifiées par le
champ &Both (couple).
8.4.4 Le champ &Supplier (serveur) spécifie un ensemble d’opérations OPERATION que l’un des deux objets, le
serveur, peut exécuter. Ce champ peut être omis, auquel cas le serveur ne pourra exécuter que les opérations spécifiées
par le champ &Both (couple).
NOTE - Un opérateur switch{} a été défini (voir 10.12) pour permettre de dériver un lot d’opérations d’un autre par simple
commutation des rôles.
8.4.5 Le champ &id (identzjkateur) spécifie, lorsqu’il est présent, la valeur OBJECT IDENTIFIER (identificateur
d’objet) utilisée pour identifier ce lot, s’il doit par exemple être annoncé ou négocié.
NOTE - Un lot d’opérations qui n’a pas d’identificateur &id ne peut être ni annoncé ni négocié.
8.4.6 Toutes les opérations incluses (directement ou indirectement) dans les champs &Both, &Consumer et
&Supplier auront des codes d’opération 8zoperationCode distincts.
8.4.7 Toutes les erreurs incluses dans les champs &Errors de toutes les opérations concernées (voir 8.4.6) auront
des codes d’erreur &errorCode distincts.
85 . Lot de connexion
8.51 Un lot de connexion est la spécifïcation des opérations et de la qualité de service intervenant dans
l’établissement et la libération dynamiques d’une association. Un lot de connexion ne sera spécifié que si des opérations
de rattachement et de détachement sont utilisées pour respectivement établir et libérer dynamiquement une association.
Rec. UIT-T X.880 (1994
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...