ISO/IEC 13712-2:1995
(Main)Information technology — Remote Operations: OSI realizations — Remote Operations Service Element (ROSE) service definition
Information technology — Remote Operations: OSI realizations — Remote Operations Service Element (ROSE) service definition
Provides the framework for the realization as an OSI application context of the abstracts concepts of operation package and association contract defined in ITU-T Rec. X.880 ISO/IEC 13712-1. Focuses on the services provided by ROSE, and the way ROSE is used.
Technologies de l'information — Opérations distantes: Réalisations OSI — Définition du service de l'élément de service d'opérations distantes (ROSE)
General Information
Relations
Standards Content (Sample)
INTERNATIONAL
ISOAEC
STANDARD
13712-2
First edition
1995-04-15
Corrected and reprinted
1995-09-15
Information technology - Remote
Operations: OSI realizations - Remote
Operations Service Element (ROSE) Service
definition
Technologies de I’information - Operations 2 distance: ßbalisations
OSI - Definition du Service pour IWment de Service des optkations 5
distance (ROSE)
ISO/IEC 13712-2: 1995(E)
Contents
Page
Scope .
i
Normative references .
........................................................................ 1
2.1 Identical Recommendations I International Standards
.......................... 2
2.2 Paired Recommendations I International Standards equivalent in technical content
Definitions .
Reference Model definitions .
3.1
..........................................................................................................
3.2 Service conventions defmitions
Presentation Service definitions .
3.3
...........................................................................................................
3.4 Association control definitions
3.5 Reliable Transfer definitions .
3.6 ROSE definitions .
Abbreviations .
Conventions .
OS1 Realization model for ROS .
ROS-based application contexts .
General .
7.1
........................................................................................................
7.2 Application context specification
..................................................................
7.3 Relationship with other ASEs and Lower Layer Services
Basic ROSE Services .
..........................................................................................................................
8.1 RO-INVOKE Service
8.2 RO-RESULT Service .
8.3 RO-ERROR Service .
RO-REJECT-U Service .
8.4
........................................................................................................................
8.5 RO-REJECT-P Service
8.6 RO-BIND Service .
8.7 RO-UNBIND Service .
Sequencing information .
........................................................................................................................................
91 . Associations
...........................................................................................................................................
9.2 Operations
.....................................................................................................................
9.3 Further sequencing rules
........................................................................................................................
9.4 Invoke-id management
o ISO/IEC 1995
All rights reserved. Unless otherwise specified, no gart 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 CI-I-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
0 ISO/IEC
ISO/IEC 13712=2:1995(E)
10 Mapping onto ROSE Services . 21
11 Mapping onto RO-BIND and RO-UNBIND Services . 22
11.1 Mapping onto ACSE Services . 23
............................................................................................................. 24
11.2 Mapping onto RTSE Services
Annex A - ASN.l Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Annex B - Guidelines for the use of the notation .
B.l Example of information objects of class Application Context . 28
B .2 Releasing Application-associations in an Orderly Way . 28
Annex C - Assignment of Object identifier values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
. . 0
ISO/IEC 13712-2: 1995(E) o 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 ISOLIEC 137 12-2 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Znformation 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
Recommendation X.88 1.
This part of ISO/IEC 137 12 is a partial revision of ISO/IEC 9072- 1: 1989.
ISO/IEC 137 12 consists of the following Parts, under the general title Information
technology - Remote operations:
- Part 1: Concepts, model and notation
- Part 2: OSI realizations - Remote Operations Service Element (ROSE)
Service definition
- Part 3: OSI realizations - Remote Operations Service Element (ROSE)
protocol specification
Annex A forms an integral part of this part of ISO/IEC 137 12. Annexes B and C
are for information only.
iv
o ISO/IEC
ISO/IEC 13712-2: 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 retumed to the invoker.
The concepts of ROS, as specified in ITU-T Rec. X.880 I ISO/IEC 13712-1, are abstract and may be realized in many
ways. For example, objects whose interactions employ ROS concepts may be separated by a Software interface or by an
OS1 network.
This Recommendation I International Standard provides the framework for the realization of an Operation package and
association contract as an OS1 application context. Such an application context is specified primarily in terms of a
collection of application Service elements (ASE). From a ROS perspective, these ASEs fall into three broad categories:
Operation-specific ASEs, which embody knowledge of the definitions of the operations in the association
a)
contract;
which drives the general-purpose protocol required to invoke and
the Remote Operations ASE (ROSE)
b)
report returns of arbitrary operations;
information transfer ASEs concemed with the establishment and release of associations where necessary,
C>
and the communication of the ROSE protocol control information (PCI). In the OS1 realization, such
ASEs are the Association Control Service Element (ACSE), the Reliable Transfer Service Element
(RTSE) used together with the Services of the Presentation layer.
This Recommendation I International Standard focuses on the derivation of ROSE-based application context
specifications, the Service provided by ROSE, and the way that ROSE is used. This Recommendation I International
Standard is a revision of CCITT Rec. X.219 I ISO/IEC 9072-1. The existing usage of ROSE in connection with ACSE,
RTSE and the Presentation layer as defined in CCITT Rec. X.219 I ISO/IEC 9072-1 remains valid after this revision.
This revision makes no Change to the ROSE PCI.
V
intentionally left blank
This
Page
ISO/IEC 13712-2 : 1995 (E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY -
REMOTE OPERATIONS: OS1 REALIZATIONS - REMOTE OPERATIONS
SERVICE ELEMENT (ROSE) SERVICE DEFINITION
1 Scope
This Recommendation I International Standard provides the framework for the realization as an OS1 application context
of the abstracts concepts of Operation package and association contract defined in ITU-T Rec. X.880 I ISO/IEC 13712-1.
Such an application context is described in terms of a collection of application Service elements, in particular the Remote
Operations Application Service Element (ROSE), which drives the general purpose protocol for invoking and reporting
the returns of arbitrary operations.
The terms, definitions, and mechanisms defined in ITU-T Rec. X.880 I ISO/IEC 13712-1 apply here and are specialized
for an OS1 realization as specified in this Recommendation I International Standard. This Recommendation I
International Standard focuses on the Services provided by ROSE, and the way ROSE is used. The ROSE Services are
provided by the use of the ROSE protocol (specified in a companion Recommendation I International Standard, ITU-T
Rec. X.882 l ISO/IEC 137 12-3), in conjunction with the Association Control Service Element (ACSE) Services (ITU-T
Rec. X.217 I ISO 8649) and the ACSE protocol (ITU-T Rec. X.227 I ISO 8650), and, optionally, the Reliable
Transfer Service Element (RTSE) Services (ITU-T Rec. X.218 I ISO/IEC 9066-1) and the RTSE protocol (ITU-T
Rec. X. 228 l ISO/IEC 9066-2), and the Presentation Service (ITU-T Rec. X.216 I ISO/IEC 8822).
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.200 (1994) I ISOIIEC 7498-1: 1994, Informution technology - Open Systems
Interconnection - Basic Reference Model: The Basic Model.
-
ITU-T Recommendation X.210 (1993) I ISOLIEC 1073 1: 1994, Infomzation technology - Open Systems
Interconnection - Basic Reference Model - Conventions for the definitions of OSI Services.
-
ITU-T Recommendation X.215 (1994) I ISO 8326:- ‘1, Infomzation processing systems - Open Systems
Interconnection - Basic connection oriented Session senke definition.
-
ITU-T Recommendation X.216 (1994) I ISOLlEC 8822: 1994, Information technology - Open Systems
Interconnection - Presentation Service definition.
-
ITU-T Recommendation X.217 (1995) I ISO 8649:- 2), Information processing systems - Open Systems
Interconnection - Service deflnition for the Association Control Service Element.
-
ITLJ-T Recommendation X.227 (1995) I ISO 8650:- 3J, Informution processing systems - Open Systems
Interconnection - Protocol specification for the Association Control Service Element.
-
ITU-T Recommendation X.680 (1994) I ISO/IEC 8824-1: 1995, Information technology - Abstract Syntax
Notation One (ASN. 1): Specification of basic notation.
1) To be published. (Revision of ISO 8326:1987)
2) To be published. (Revision of ISO 8649:1988)
3) To be published. (Revision of ISO 8650:1988)
ITU-T Rec. X.SSl(l993 E)
ISO/IEC 13712-2 : 1995 (E)
-
ITU-T Recommendation X.681 (1994) I ISO/IEC 8824-2: 1995, Information technology - Abstract Syntax
Notation One (ASN. 1): Information Object specijkation.
-
ITU-T Recommendation X.682 (1994) I ISO/IEC 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. 1): Parameterkation of ASN. 1 specifkations.
-
ITU-T Recommendation X.880 (1994) I ISO/IEC 13712-1: 1995, Information technology - Remote
Operations: Concepts, model and notation.
-
ITU-T Recommendation X.882 (1994) I ISOIIEC 13712-3: 1995, Information technology - Remote
Operations: OSZ realizations - Remote Operations Service Element (ROSE} protocol specijkation.
22 . Paired Recommendations I International Standards equivalent in technical content
-
ITU-T Recommendation X.218 (1993), Reliable Transfer: Model and Service definition.
ISO/IEC 9066-1: 1989, Information processing Systems - Text communication - ReliabZe Transfer -
Part I: Model and Service definition.
-
ITU-T Recommendation X.228 (1993), Reliable Transfer - Protocol specijkation.
ISOIIK 9066-2: 1989, Information processing Systems - Text communication - Reliable Transfer - Part 2:
Protocol speczjkation.
-
CCITT Recommendation X.219 (1988), Remote Operations: Model, notation and Service definition.
ISO/IEC 9072-1: 1989, Information processing Systems - Text communication - Remote Operations -
Part 1: Model, notation and Service defznition.
-
CCITT Recommendation X.229 (1988), Remote Operations: Protocol specification.
ISOAEC 9072-2:1989, Information processing Systems - Text communication - Remote Operations -
Part 2: Protocol specification.
3 Definitions
Reference Model definitions
31 .
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)
Application Layer;
W
application-process;
C>
application-entity ;
d)
application-service-element;
e>
f) application-protocol-data-unit;
g) application-protocol-control-information;
h) Presentation Layer;
presentation-Service.
32 . Service conventions definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.210 I
ISO/IEC 1073 1:
service-provider;
a>
b) service-user;
confirmed Service;
C)
ITU-T Rec. X.881(1993 E)
ISO/IEC 13712-2 : 1995 (E)
d) non-confirmed Service;
e) provider-initiated Service;
Service-primitive; primitive;
g) request (primitive);
h) indication (primitive);
response (primitive); and
.
tonfirm (primitive).
J)
33 . Presentation Service definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.216 I
ISO/IEC 8822:
abstract Syntax name;
a>
b) transfer Syntax name;
c) presentation context.
Association control definitions
34 .
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.217 I
ISO 8649:
application-association; association;
a>
b) application context;
c) Association Control Service Element.
35 . Reliable Transfer definitions
This Recommendation I International Standard makes use of the following terms defined in CCITT Recommenda-
tion X.218 I ISO/IEC 9066:
-
Reliable Transfer Service Element.
36 . ROSE definitions
For the purpose of this Recommendation I International Standard the following definitions apply:
3.6.1 association-initiating-application-entity; association-initiator: The application-entity that initiates the
application-association.
3.6.2 association-responding-application-entity; association-responder: The application-entity that responds to
the initiation of an application-association by another AE.
invoking-application-entity; invoker: The application-entity that invokes the Remote Operation.
3.6.3
3.6.4 performing-application-entity; Performer: The application-entity that performs a Remote Operation
invoked by the other application-entity.
3.6.5 requestor: The part of an application-entity that issues a request primitive for a particular ROSE Service.
3.6.6 acceptor: The part of an application-entity that receives the indication primitive for a particular ROSE
Service.
3.6.7 linked Operation: See 3.3.8 of ITU-T Rec. X.880 I ISOLIEC 13712-1.
3.6.8 parent-Operation: An Operation during whose execution the Performer may invoke linked-operations.
response to the latter
3.6.9 Child-Operation: An Operation that is invoked by the Performer of a parent-Operation in
operation’s invocation.
ITU-T Rec. X.881(1993 E) 3
ISO/IEC 13712-2 : 1995 (E)
3.6.10 ACSE-User: That Portion of an application entity which performs the mapping of the bind Operation and
unbind Operation onto ACSE.
Service Element: The application-service-element defined in this Recommendation 1
3.6.11 Remote Operation
International Standard.
3.6.12 ROSE-provider: The provider of the Remote Operations Service Element Services.
3.6.13 ROSE-User: That Portion of an application entity which interacts with ROSE for the purpose of
communicating with the remotely-located peer User.
3.6.14 RTSE-User: That Portion of an application entity which performs the mapping of the bind Operation and
unbind Operation onto RTSE.
4 Abbreviations
AE Application entity
ACSE Association Control Service Element
ASE Application Service element
ASN. 1 Abstract Syntax Notation One
APDU Application protocol data unit
RO (or ROS) Remote Operations
ROSE Remote Operations Service Element
RT (or RTS) Reliable Transfer
Reliable Transfer Service Element
RTSE
5 Conventions
This Recommendation I International Standard defines Services for the ROSE following the descriptive conventions
defined in ITU-T Rec. X.210 I ISO/IEC 10731. In clause 8, the definition of each ROSE Service includes a table that lists
the Parameters of its primitives. For a given primitive, the presence of each Parameter is described by one of the
following values:
Blank Not applicable
Mandatory
M
U User Option
C Conditional
Presence is a ROSE service-provider Option
In addition, the notation (=) indicates that a Parameter value is semantically equal to the value to its left in the table.
This specification employs ASN. 1, as specified in ITU-T Rec. X.681 I ISO/IEC 8824-2, to define the APPLICATION-
CONTEXT information Object class. This also provides the notation with which designers of ROS applications tan
specify particular instances of the class.
6 OS1 Realization model for ROS
A general model for the realization of ROS by communication means is shown in Figure 1 (reproduced from Figure 3 of
ITU-T Rec. X.880 I ISO/IEC 13712-1).
4 ITU-T Rec. X.881(1993 E)
ISOLIEC 13712-2 : 1995 (E)
TE041 80-94/dO 1
Figure 1 - Communications reaiization of ROS
Here the stubs represent the ability for the ROS-objects to invoke operations remotely. A particular stub corresponds to
the operations in some association contract. The information transfer Object conveys protocol data units (PDUs) between
the stubs.
This document is concerned with the ROS-objects being realized as application-processes, and the medium by the
communications Services of OSI.
Figure 2 is a rearranged and expanded version of Figure 1, overlaying on it some of the principal concepts of the
application layer of OSI.
Supporting & ASEs
I
a-AS E z-AS E
.
t
PRESENTATIONSERVICE PROVIDER
TE041 9@94/dO2
a-ASE ASE providing (dynamic) association establishment and release
z-ASE ASE providing information transfer
ROSE Remote Operations ASE
o-AS Es
Operation-specif ic AS Es
Figure 2 - OS1 realization of ROS
ITU-T Rec. X.881(1993 E)
ISO/IEC 13712-2 : 1995 (E)
The stub objects are realized by ROSE together with a collection of Operation-specific ASEs. ROSE, whose services arc
defined in clause 8, drives the generic protocol required to invoke and report returns of arbitrary operations. Esch
Operation-specific ASE embodies knowledge of the definitions of the specific operations involved in some Operation
package. Where the Operation package is asymmetrical, the corresponding Operation-specific ASE is ah asymmetrical,
having a consumer or supplier role to match that of the ROS-Object which it is representing. Collectively, ROSE and the
Operation-specific ASEs have knowledge of all of the operations of the association contract.
The information transfer Object is realized by the OS1 presentation-Service provider, together with a collection of ASEs
which shall include an a-ASE, may include a z-ASE, and may also include ASEs supporting these (e.g. an ASE
providing a Directory User Agent function). The collection always include ACSE. Different OS1 realizations of ROS
result from the use of different collections of these ASEs.
The use of the ROSE Services is only possible after a transfer Service has been made available on the application
association. This transfer Service tan be available either directly at the level of the Presentation Service, or as a Service
provided by an ASE (see the z-ASE in Figure 2).
7 ROS-based application contexts
71 . General
The particular set of ASEs involved in realizing some particular association contract, together with any rules for their
coordinated working, constitutes an application context. The application context include all ASEs contributing to the
stubs and to the information transfer Object.
In realizing the stubs, all application contexts relevant to this Recommendation I International Standard include ROSE.
In addition, each such application context includes one Operation-specific ASE concerned with each Operation package
(including one for the connection package, if there is one).
Different application contexts tan be defined to realize the same association contract by the use of different sets of ASEs
to support information transfer. The information transfer ASEs shall be selected to meet the various Quality of Service
requirements inherent in the association contract.
NOTE 1 - It is possible that in the future, rules could be defined for determining which ASEs should be involved in Order
to meet particular Quality of Service (QOS) requirements. However, it is presently assumed that this is a manual process; that is, the
designer of a realization takes these requirements into account and chooses the ASEs accordingly.
All application contexts include ACSE, although this may be acting as the a-ASE or as a supporting ASE.
NOTE 2 - The application context may include additional ASEs for purposes outside of the scope or concern of ROSE,
provided that they are arranged to be harmonious with the ASEs mentioned here.
72 . Application context specification
The static aspects of a ROS-based application context definition tan be described as an information Object of
7.2.1
the class APPLICATION-CONTEXT, which is specified as follows:
APPLICATION-CONTEXT ::= CLASS
&associationContract CONTRACT,
REALIZATION OPTIONAL,
&associationRealization
&transferRealization REALIZATION,
&AbstractSyntaxes ABSTRACT-SYNTAX,
OBJECT IDENTIFIER UNIQUE
&applicationContextName
WITH SYNTAX
CONTRACT &associationContract
&associationRealization]
[ESTABLISHED BY
INFORMATION TRANSFER BY &transferRealization
ABSTRACT SYNTAXES &AbstractSyntaxes
APPLICATION CONTEXT NAME &applicationContextName
REALIZATION ::= TYPE-IDENTIFIER
6 ITU-T Rec. X.881(1993 E)
ISO/IEC 13712-2 : 1995 (E)
This definition specifies the ROS aspects of an application context definition. If ASEs other than ROS-based ASEs are
used as a patt of some application context, the definition in this clause is an element of a composite application context
definition.
The manner of defining such a composite application context is outside the scope of this Recommendation I International
Standard.
7.2.2 The &associationContract field identifies the association contract which this application context realizes.
NOTE - The application designer’s intentions regarding whether the “responder tan unbind” and “unbind tan fail” is
derived from the &associationContract field.
7.2.3 The IkassociationRealization field shall be present if and only if the honnection field of &associationContract is
present. If present, it shall identify a particular approach to dynamic association establishment and release. A number of
such approaches are specified in ITU-T Rec. X.882 I ISO/IEC 13712-3.
7.2.4 The &transferRealization field shall identify a particular realization of the information transfer Object.
A number of such realizations are specified in ITU-T Rec. X.882 I ISO/IEC 137 12-3. The &AbstractSyntaxes field
contains the abstract syntaxes which are required for the conveyance of information between the objects, including the
PDUs for invoking and reporting on the operations in the contract. Requirements for these abstract syntaxes are specified
in ITU-T Rec. X.882 I ISO/IEC 137 12-3. The &applicationContextName value shall be used, when the OSI association is
being established, to identify the application context which must be in place on this association.
73 . Relationship with other ASEs and Lower Layer Services
7.3.1 Other Application Service Elements
The ROSE is intended to be used with other ASEs in Order to support specific interactive information processing tasks.
Therefore, it is expected that the ROSE will be included in a large number of application-context specifications.
The collection of the ROSE and other ASEs included in an application context are required to use the facilities of the
presentation-Service in a co-ordinated manner among themselves.
The ROSE requires an existing application association controlled by ACSE.
For some application context specifications, a Reliable Transfer Service Element (RTSE) is included.
7.3.2 Presentation Service
If an application context including RTSE and ROSE is defined, ROSE Services do not use the Presentation Service.
If an application context including ROSE but excluding RTSE is defined, the ROSE Services require access to the
P-DATA Service and require the use of the duplex functional unit of the Presentation Service. The ROSE Services neither
use, nor constrain the use of, any other Presentation Service.
Identification of the named abstract Syntax in use is assumed for all ROSE Services, however this is a local matter and
I International Standard.
outside the scope of this Recommendation
8 Basic ROSE Services
The ROSE Services are listed in Table 1.
Table 1 - ROSE Services
Service
Type
Non-confirmed
RO-INVOKE
Non-confirmed
RO-RESULT
Non-confirmed
RO-ERROR
RO-REJECT-U Non-confirmed
RO-REJECT-P Provider-initiated
Confirmed
RO-BIND
RO-UNBIND Confirmed
ITU-T Rec. X.881(1993 E) 7
ISO/IEC 13712-2 : 1995 (E)
81 . RO-INVOKE Service
The RO-INVOKE Service is used by one ROSE-User (the invoker) to Cause the invocation of an Operation to be
performed by the other ROSE-User (the Performer). This Service is a non-confirmed Service.
The related Service structure consists of two Service primitives, as illustrated in Figure 3.
ROSE-user ROSE-provider
RO-INVOKE
TIS 04200~94/dO3
Figure 3 - RO-INVOKE Service primitives
Table 2 lists the RO-INVOKE Parameters.
Table 2 - RO-INVOKE Parameters
Parameter name Req. Ind.
I
M
Operation-id
MC=)
Operation-type U
U
Argument
C(=>
Invoke-id M
MC=)
Linked-id U
C(=>
Priori ty U
8.1.1 Operation-id
This Parameter identifies the Operation to be performed as part of some Operation contract. This Parameter conveys the
&operationCode from the Operation definition.
8.1.2 Operation-type
This Parameter classifies the Operation as to:
-
whether it is synchronous, or not.
The classification is derived from the bynchronous field of the Operation definition. Absence of this Parameter implies
that the Operation is asynchronous.
8.1.3 Argument
This Parameter tan be present if and only if the
This Parameter is the argument of the invoked Operation.
&ArgumentType field is present in the Operation definition. If present, its type shall be as indicated by that field.
Invoke-id
8.1.4
This Parameter identifies the request of a RO-INVOKE Service and is used to correlate this request with the
corresponding replies (RO-RESULT, RO-ERROR, RO-REJECT-U, and RO-REJECT-P Services) or the invocation by
the Performer of linked Child-operations (RO-INVOKE). This Parameter has to be supplied by the requestor of the
Service.
IT&T Rec. X.881(1993 E)
ISO/IEC 13712-2 : 1995 (E)
This Parameter distinguishes several requests of the Service the requestor may have in progress (asynchronous
operations). The requestor may begin to reuse Invoke-id values whenever it chooses, subject to the constraint that it may
not reuse an Invoke-id value that was previously assigned to a request of the Service for which it expects, but has not yet
received, a reply or the invocation of a linked Child-Operation.
The ROSE-User to which an RO-INVOKE indication is issued, assumes that an Invoke-id value violating the above rule
is a duplicate; and therefore, it does not perform the invoked Operation. Instead, it rejects the duplicate invocation.
If the Operation does not always report its outcome, the requestor of this Service may reuse an Invoke-id value after a
reasonably long period of time, or if the reply is carried by other means (e.g. by the result of a “have-you-finished”
Operation).
In some application contexts peer ROSE-users may communicate Invoke-id values. To support this, the set of allowed
values of the Invoke-id Parameter is used in (see Annex A of ITU-T Rec. X.880 I ISO/IEC 137 12-1) defining the generic
ROS PDUs.
Linked-id
S.l.5
If this Parameter is present, the invoked Operation is a Child-Operation and the Parameter identifies the invocation of the
linked parent-Operation. This Parameter has to be supplied by the requestor of the Service. The value is that of the
Invoke-id Parameter of the RO-INVOKE indication primitive of the parent-Operation.
8.1.6 Priority
This Parameter defines the priority assigned to the transfer of the corresponding APDU with respect to the other APDUs
to be exchanged between the AEs. The lower the value, the higher the priority. If several APDUs with the same priority
are awaiting transfer, they are transferred “first in, first out”.
NOTES
1 The priority Parameter is used only in conjunction with the RTSE as a transfer Service. It shall not be used in any
other realization.
2 The Priority Parameter has an effect in the case of a two-way alternate association in that it prioritizes the sending of
APDUs, and may be used to determine when to request the Turn to send APDUs. The Priority Parameter may also have a local effect
in the case of a two-way simultaneous association.
3 The Priority of a reply (RO-RESULT, RO-ERROR, and RO-REJECT-U) should normally be higher (lower in value)
than the priority of the corresponding invocation.
When present, the Priority must be in the range allowed for by the &InvokePriority field of the Operation definition.
82 . RO-RESULT Service
The RO-RESULT Service is used by a ROSE-User to reply to a previous RO-INVOKE indication in the case of a
successfully performed Operation. This Service is a non-confirmed Service.
The related Service structure consists of two Service-primitives, as illustrated in Figure 4.
WO42 l O-94/dO4
Figure 4 - RO-RESULT Service primitives
ITU-T Rec. X.881(1993 E)
ISO/IEC 13712-2 : 1995 (E)
Table 3 lists the RO-RESULT Service Parameters.
Table 3 - RO-RESULT Parameters
Parameter name Req. Ind.
Operation-id U
C(=>
Result
U C(=)
Invoke-id M
MC=)
Priori ty U
Operation-id
8.2.1
This Parameter identifies the Operation whose result is being reported after being performed as part of some Operation
contract. This Parameter conveys the &operationCode from the Operation definition. This Parameter shall be present only
if the Result Parameter is present.
8.2.2 Result
This Parameter is the result of the Operation. This Parameter may be present if and only if the &ResultType field is
present in the Operation definition. If present, its type shall be as indicated by that field.
8.2.3 Invoke-id
This Parameter identifies the corresponding invocation (see 8.1.4). This Parameter has to be supplied by the requestor of
the Service. The value is that of the corresponding RO-INVOKE indication primitive.
8.2.4 Priority
This Parameter defines the priority assigned to the transfer of the corresponding APDU (see 8.1.6).
NOTE - The priority Parameter is used only in conjunction with the RTSE as a transfer Service. It shall not be used in any
other realization.
When present, Priority must be in the range allowed for by the &ResultPriority field of the Operation definition.
83 . RO-ERROR Service
The RO-ERROR Service is used by a ROSE-User to reply to a previous RO-INVOKE indication in the case of an
unsuccessfully performed Operation. This Service is a non-confirmed Service. The related Service structure consists of
two Service-primitives as illustrated in Figure 5.
ROSE-user 1 ROSE-provider 1 ROSE-User
I I TIS04220-94/dO5
Figure 5 - RO-ERROR senke primitives
10 ITU-T Rec. X.881(1993 E)
ISO/IEC 13712-2 : 1995 (E)
Table 4 lists the RO-ERROR Service Parameters.
Table 4 - RO-ERROR Parameters
Parameter name Req. Ind.
M
Error-id
MC=)
Parameter U
C(=>
Invoke-id M
MC=)
Priori ty U
8.3.1 Error-id
This Parameter identifies the error being reported due to the inability to perform the invoked Operation. This Parameter
conveys the &errorCode from the error definition.
Parameter
8.3.2
This is the Parameter of the error, and may be present if and only if the &ParameterType field is present in the error
definition. If present, its type shall be as indicated by that field.
8.3.3 Invoke-id
This Parameter identifies the corresponding invocation (see 8.1.4). This Parameter has to be supplied by the requestor of
the Service. The value is that of the corresponding RO-INVOKE indication primitive.
8.3.4 Priority
This Parameter defines the priority assigned to the transfer of the corresponding APDU (see 8.1.6).
NOTE - The priority Parameter is used only in conjunction with the RTSE as a transfer Service. It shall not be used in any
other realization.
When present, the Priority must be in the range allowed for by the &ErrorPriority field of the error definition.
. RO-RE JECT-U Service
The RO-REJECT-U Service is used by a ROSE-User to reject a request (RO-INVOKE indication) of the other ROSE-
user if it has detected a Problem. The RO-REJECT-U Service may also be used by a ROSE-User to reject a reply
(RO-RESULT indication, RO-ERROR indication) from the other ROSE-User. However, to avoid violating the
sequencing rules of other ASEs in some application contexts, a ROSE-User may choose not to use the RO-REJECT-U
Service to reject replies. This Service is a non-confirmed Service.
The related Service structure consists of two Service-primitives, as illustrated in Figure 6.
Figure 6 - RO-REJECT-U Service primitives
ITU-T Rec. X.881(1993 E) 11
ISO/IEC 13712-2 : 1995 (E)
Table 5 lists the RO-REJECT-U Service Parameters.
Table 5 - RO-RE JECT-U Parameters
Req.
Reject-reason M
MC=)
Invoke-id M
MC=)
Priori ty U
8.4.1 Reject-reason
This Parameter specifies the reason for rejection as follows:
Invoke-Problem: user-reject of an RO-INVOKE indication primitive with values:
a>
-
duplicate-invocation - Signifies that the Invoke-id Parameter violates the assignment rules of 8.1.4
[see also ITU-T Rec. X.880 I ISODEC 13712-1,9.3.3a)];
-
Signifies that the Operation is not one of those agreed between the ROSE-
unrecognized-Operation -
users [see also ITU-T Rec. X.880 1 ISO/IEC 13712-1,9.3.3b)];
-
mistyped-argument - Signifies that the type of the Operation argument supplied is not that agreed
between the ROSE-users [see also ITU-T Rec. X.880 I ISO/IEC 13712-1,9.3.3d)];
-
resource-limitation - The in Performer is not willing to perform the invoked Operation due to
resource limitation
-
The intended Performer is not willing to perform the invoked Operation because
release-in-progress -
it is about to release the application-association;
-
unrecognized-linked-ID - Signifies that there is no Operation in progress with an Invoke-id equal to
the specified Linked-id for which no outcome has been reported [see also ITU-T Rec. X.880 I
ISO/IEC 13712-1,9.3.3 b)];
-
linked-response-unexpected - Signifies that the invoked Operation referred to by the Linked-id is not
one which allows linked-operations to be invoked in response [see also ITU-T Rec. X.880 I ISO/IEC
13712-1,9.3.3b)];
-
unexpected-linked-Operation - Signifies that the invoked Child-Operation is not one that is allowed by
the invoked parent-Operation referred to by the Linked-id. [see also ITU-T Rec. X.880 1 ISO/IEC
13712-1, 9.3.3b)l;
b) Return-result-Problem: user-reject of an RO-RESULT indication primitive with values:
-
unrecognized-invocation - Signifies that no Operation with the specified Invoke-id is in progress for
which a report of the outcome is expected [see also ITU-T Rec. X.880 I ISO/IEC 13712-l9.4.3 a)];
-
result-response-unexpected - Signifies that the invoked Operation does not report a result [see also
ITU-T Rec. X.880 I ISO/IEC 13712-1,9.4.3a)];
-
mistyped-result - Signifies that the type of the Result Parameter supplied is not that agreed between
the ROSE-users [see also ITU-T Rec. X.880 I ISO/IEC 13712-1,9.4.3b)];
Return-error-Problem: user-reject of an RO-ERROR indication primitive with values:
c)
-
unrecognized-invocation - Signifies that no Operation with the specified Invoke-id is in progress for
which the report of the outcome is expected [see also ITU-T Rec. X.880 I ISO/IEC 13712-1,
9.5.3 a)];
-
unrecognized-error - Signifies that the reported error is not one of those agreed between the ROSE-
users [see also ITU-T Rec. X.880 I ISO/IEC 13712-1,9.5.3b)];
-
unexpected-error - Signifies that the reported error is not one that the invoked Operation may report
[see also ITU-T Rec. X.880 I ISO/IEC 13712-1,9.5.3b)];
-
mistyped-Parameter - Signifies that the type of the error Parameter supplied is not that agreed
between the ROSE-User [see also ITU-T Rec. X.880 I ISO/IEC 13712-1, 9.5.3c)l.
This Parameter has to be ied by the requestor of the Service.
SUPPl
ITU-T Rec. X.881(1993 E)
ISO/IEC 13712-2 : 1995 (E)
8.4.2 Invoke-id
This Parameter identifies the corresponding invocation (see 8.1.4). This Parameter has to be supplied by the requestor of
the Service. The value is that of the rejected RO-INVOKE indication, RO-RESULT indication, or RO-ERROR
indication primitive.
8.4.3 Priority
This Parameter defines the priority assigned to the transfer of the corresponding APDU (see 8.1.6, 8.2.4 and 8.3.4).
NOTE - The priority Parameter is used only in conjunction with the RTSE as a transfer Service. It shall not be used in any
other realization.
8.5 RO-RE JECT-P Service
The RO-REJECT-P Service is used to advise a ROSE-User of a corrupted ROSE APDU detected by the ROSE Service
provider. This Service is a provider-initiated Service. The RO-REJECT-P indication primitive arises as a result of an
earlier RO-INVOKE, RO-RESULT, RO-ERROR or RO-REJECT - U request primitive issued by the same RO-User.
The RO-REJECT-P Service tan also be used to inform a ROSE-User of an unsuccessful transfer of a ROSE APDU by
the ROSE Service provider due to a Problem in the underlying layers (e.g. association abort).
The related Service structure consists of a Single Service-primitive, as illustrated in the lower Portion of Figure 7.
ROSE-User ROSE-protide ROSE-User
I 1
RO4WOKE
RO+lESULT
RO-REJECT-U
1 TlSO4240-94/dO7
Figure 7 - RO-REJECT-P Service primitive
Table 6 lists the RO-P-REJECT Service Parameters.
Table 6 - RO-RE JECT-P Parameters
Parameter name Ind.
Invoke-id 0
Reject-reason 0
8.5.1 Invoke-id
This Parameter identifies the corresponding ROS APDU (see 8.1.4) that has been rejected at the remote end. This
Parameter is supplied by the ROSE-provider. The value is that of the rejected RO-INVOKE request, RO-RESULT
NULL
request, RO-ERROR request or RO-REJECT-U request primitives. This Parameter may be replaced by the value
if an Invoke-id could not be derived by the ROSE service-provider.
ITU-T Rec. X.881(1993 E) 13
ISO/IEC 13712-2 : 1995 (E)
8.5.2 Reject-reason
This Parameter specifies the reason for rejection as follows:
a) General-problem: provider-reject of an APDU with values:
-
unrecognized-APDU - Signifies that the type of the APDU, as evidenced by its tag, is not one of the
four gen
...
NORME
ISO/CEI
INTERNATIONALE
13712-2
Première édition
1995-04-I 5
Technologies de l’information -
Opérations distantes: Réalisations OSI -
Définition‘ du service de l’élément de
service d’opérations distantes (ROSE)
Information technology
- Remote Opera tions: OSI realizations -
Remo te Opera tions Service Elemen t (ROSE) service de finition
Numéro de référence
ISO/CEI 13712-2:1995(F)
ISOKEI 13712-2: 1995(F)
Sommaire
Page
Domaine d’application .
Références normatives .
...................................................................... 1
2.1 Recommandations I Normes internationales identiques
....... 2
2.2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
Définitions . 2
3.1 Définitions relatives au modèle de référence . 2
3.2 Définitions relatives aux conventions de service . 3
3.3 Définitions relatives au service de présentation . 3
3.4 Définitions du contrôle d’association . 3
............................................................................................................. 3
3.5 Définitions du transfert fiable
............................................................................................... 3
3.6 Définitions relatives a l’élément ROSE
Abreviations .
Conventions .
Modèle de I’OSI pour la realisation du service ROS . 5
.......................................................................... 6
Contextes de couche application fondés sur le service ROS
7.1 Considérations générales .
............................................................................................... 7
7.2 Spécification du contexte d’application
..................................... 7
7.3 Relations avec les autres éléments ASE et les services de couche inférieure
Services ROSE de base .
81 Service RO-INVOKE .
8:2 Service RO-RESULT . 10
........................................................................................................................... 11
83 Service RO-ERROR
...................................................................................................................... 12
8:4 Service RO-REJECT-U
85 . Service RO-REJECT-P .
86 Service RO-BIND .
8:7 Service RO-UNBIND . 16
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- 1211 Genève 20 l Suisse
Version française tirée en 1996
Imprimé en Suisse
ii
ISOKEI 13712-2: 1995(F)
0 ISOKEI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 Renseignements sur la mise en séquence
91 . Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92 . Opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93 Autres règles d’ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9:4 Gestion des identificateurs d’invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Projection sur les services ROSE .
11 Projection sur les services RO-BIND et RO-UNBIND .
11.1 Projection sur les services ACSE .
........................................................................................................ 25
11.2 Projection sur les services RTSE
..................................................................................................................................... 28
Annexe A - Modules ASN.l
........................................................................................ 29
Annexe B - Directives concernant l’emploi de la notation
B. 1 Exemples d’objets informationnels de la classe Application Context . 29
B .2 Libération méthodique des associations d’application . 29
.................................................................................... 32
Annexe C - Affectation des valeurs d’identificateurs d’objet
. . .
ISOKEI 13712-2: 1995(F)
@ ISOKEI
Avant-propos
LIS0 (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 1’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 1’ISO et la CE1
participent également aux travaux.
Dans le domaine des technologies de l’information, I’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-2 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de Z’information, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec l’IUT-T. Le texte identique est publié en tant que
Recommandation IUT-T X.88 1.
La présente partie de I’ISOKEI 137 12 est une révision partielle de
1’ISOKEI 9072- 1: 1989.
L’ISOKEI 137 12 comprend les parties suivantes, présentées sous le titre général
Technologies de 1 ‘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 1’ISOICEI 13712. Les
annexes B et C sont données uniquement à titre d’information.
1v
@ ISOKEI ISO/CEI 13712-2: 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 utilise pour la conception et la spécification des applications reparties. 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 résultat de l’opération retourné à l’invocateur.
Les concepts d’opérations distantes, tels qu’ils sont spécifiés dans la Rec. UIT-T X.880 I ISOKEI 13712-1, sont abstraits
et peuvent être réalisés de multiples manieres. 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 fournit le cadre pour la réalisation d’un lot d’opérations et d’un
contrat d’association formant un contexte d’application OSI. Un tel contexte d’application est spécifié fondamentalement
en termes d’une collection d’élements de service application (ASE) (application service element). Dans une optique
ROS, ces éléments ASE relèvent de trois grandes catégories:
les éléments ASE spécifiques aux opération s, qui contiennent la tonnai .ssance relative aux définitions des
a)
opérations du contrat d’association
b) les éléments ASE d’opérations distantes (ROSE), qui pilotent le protocole géneral nécessaire à
l’invocation d’opérations quelconques et à l’annonce de leurs résultats;
c) les éléments ASE de transfert d’information qui interviennent dans l’établissement et la libération des
associations, si besoin est, et dans la communication des informations de commande de protocole (PCI)
du service ROSE. Dans l’application OSI, les éléments ASE sont l’élément de service de contrôle
d’association (ACSE) et l’élément de service de transfert fiable (RTSE) utilisés conjointement avec les
services de la couche présentation.
La présente Recommandation I Norme internationale est axée sur l’établissement des spécifications du contexte
d’application d’opérations distantes ROSE, le service qu’assure l’élément de service ROSE et la manière de l’utiliser. Elle
est une révision de la Rec. X.2 19 du CCITT I ISOKEI 9072-l. L’utilisation actuelle du service ROSE, en relation avec
les éléments ACSE et RTSE et la couche présentation, telle qu’elle est définie dans la Rec. X.219 du CCITT I
ISOKEI 9072-l) reste valable après la présente révision. Cette révision ne modifie en rien l’information de commande
du protocole PC1 du service ROSE.
L’Annexe A fait partie intégrante de la présente Recommandation I Norme internationale.
Les Annexes B et C ne font pas partie intégrante de la présente Recommandation I Norme internationale.
Page blanche
ISOKEI 13712-2 : 1995 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION -
OPÉRATIONS DISTANTES: RÉALISATIONS OS1 - DÉFINITION DU SERVICE
DE L’ÉLÉMENT DE SERVICE D’OPÉRATIONS DISTANTES (ROSE)
1 Domaine d’application
La présente Recommandation I Norme internationale fournit le cadre pour la réalisation, d’un contexte d’application OS1
mettant en œuvre les concepts abstraits de lot d’opérations et de contrat d’association définis dans la Rec. UIT-T X.880 I
ISOKEI 137 12-1. Un tel contexte d’application est décrit sous la forme d’une série d’élements de service d’application
(ASE), en particulier l’élément de service d’opérations distantes (ROSE) qui commande le protocole général d’invocation
d’opérations quelconques et d’envoi en retour de leurs résultats.
Les termes, définitions et mécanismes définis dans la Rec. UIT-T X.880 I ISOKEI 13712-1 sont applicables ci-après et
sont spécifiques d’une réalisation OS1 conforme à la présente Recommandation I Norme internationale. La présente
Recommandation I Norme internationale est axée sur les services fournis par le service ROSE et sur la manière de
l’utiliser. Les services ROSE sont assurés par la mise en œuvre du protocole ROSE (spécifié dans la Rec. UIT-T X.882 I
ISOKEI 13712-3) conjointement avec les services de l’élément de service de contrôle d’association (ACSE)
(Rec. UIT-T X.217 I ISOKEI 8649), du protocole ACSE (Rec. UIT-T X.227 I ISOKEI 8650-l) et, facultativement avec
les services de l’élément du service de transfert fiable (RTSE) (Rec. UIT-T X.21 8 I ISOKEI 9066-l), du protocole RTSE
(Rec. UIT-T X.228 I ISOKEI 9066-2) et avec le service de présentation (Rec. UIT-T X.216 I ISOKEI 8822).
Aucune spécification n’est imposée quant à la conformité à la présente Recommandation I Norme internationale.
2 Références normatives
Les Recommandations UIT-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 sont sujettes à révision et les
parties prenantes aux accords fondés sur la présente Spécifïcation sont invitées à rechercher la possibilité d’appliquer les
éditions les plus récentes des Recommandations et Normes 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 b Recommandations l Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l : 1994, Technologie de I?nformation -
Interconnexion de systèmes ouverts - Modèle de référence de base: Le modèle de référence de base.
-
Recommandation UIT-T X.210 (1993) I ISOKEI 10731:1994, Technologie de Z’information -
Interconnexion de systèmes ouverts - Conventions relatives à la définition des services OSI.
-
Recommandation UIT-T X.215 (1994) I ISO/CEI 8326: -l), Technologie de l’information -
Interconnexion de systèmes ouverts - Définition du service de couche session.
- Recommandation UIT-T X.216 (1994) I ISOKEI 8822: 1994, Technologie de l’information -
Interconnexion de systèmes ouverts - Définition du service de présentation.
-
Recommandation UIT-T X.217 (1995) I ISOKEI 8649: -2>, Technologie de l’information -
Interconnexion de systèmes ouverts - Definition du service de l’élément de service de contrôle
d’association.
-
Recommandation UIT-T X.227 (1995) I ISOKEI 8650: -31, Technologie de l’information -
Interconnexion de systèmes ouverts - Spécifkation du protocole de l’élément de service de commande
d’association (ACSE) en mode connexion.
1) À publier (Révision de VIS0 8326: 1987)
2) À publier (Révision de 1’ISO 8649:1988)
3) À publier (Révision de I’ISO 8650:1988)
Rec. UIT-T X.881 (1994 F) 1
ISOKEI 13712-2 : 1995 (F)
-
Recommandation UIT-T X.680 (1994) I ISOKEI 8824-l : 1995, Technologie de I?nformation - Notation
de syntaxe abstraite numéro un: Spéciflcation de la notation de base.
-
Recommandation UIT-T X.681 (1994) I ISOKEI 8824-2: 1995, Technologie de Z’information - Notation
de syntaxe abstraite numéro un: Spécification des objets informationnels.
-
Recommandation UIT-T X.682 (1994) l ISOKEI 8824-3:1995, Technologie de Z’information - Notation
de syntaxe abstraite numéro un: SpécifZcation 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.880 (1994) I ISOKEI 13712-1: 1995, Technologie de L’information -
Opérations distantes: Concepts, modèle et notation.
-
Recommandation UIT-T X.882 (1994) I ISOKEI 137 12-3: 1995, Technologie de Z’information -
Opérations distantes: Réalisations OSI: Spécification du protocole de l’élément de service d’opérations
distantes.
22 . Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation UIT-T X.2 18 (1993), Transfertfiable: modèle et définition du service.
de texte - Transfert
ISOKEI 9066- 1: 1989, Systèmes de traitement de 1 ‘information - Communication
fiable Partie 1: Modèle et définition du service.
-
Recommandation UIT-T X.228 (1993), Transfert fiable: Spécification du protocole.
de texte - Transfert
ISOICEI 9066-2: 1989, Systèmes de traitement de l’information - Communication
fiable Partie 2: Spécification du protocole.
-
Recommandation X.219 du CCITT (1988), Opérations distantes: modèle, notation et définition du
service.
ISOICEI 9072-l : 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.
Communication de texte - Opérations à
ISOKEI 9072-2: 1989, Systèmes de traitement de l’information -
distance - Partie 2: Spécifkation du protocole.
3 Définitions
31 . Définitions relatives au modèle de référence
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.200 I
ISOKEI 7498- 1:
syntaxe abstraite;
a)
b) couche application;
c) processus d’application;
d) entité d’application;
élément de service d’application;
e)
unité de données de protocole d’application;
g) informations de contrôle du protocole d’application;
h) couche présentation;
service de présentation.
Rec. UIT-T X.881 (1994 F)
ISOKEI 1371212 : 1995 (F)
32 Définitions relatives aux conventions de service
.
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.210 I
ISOKEI 1073 1:
fournisseur de service;
a)
utilisateur de service;
W
service confirmé;
Cl
service non confirmé;
d)
service engendré par le fournisseur;
e)
primitive de service; primitive;
f)
(primitive de) demande;
g)
(primitive d’) indication;
h)
(primitive de) réponse; et
.
(primitive de) confirmation.
J)
33 0 Définitions relatives au service de présentation
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.216 I
ISOKEI 8822:
nom de syntaxe abstraite;
a)
b) nom de syntaxe de transfert;
contexte de présentation.
C>
34 . Définitions du contrôle d’association
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.217 I
ISOKEI 8649:
association d’application; association;
a>
b) contexte d’application;
élément de service de contrôle d’association.
Cl
35 . Définitions du transfert fiable
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.21 8 I
ISOKEI 9066:
-
élément de service de transfert fiable.
36 . Définitions relatives à l’élément ROSE
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent:
3.6.1 entité d’application initiant l’association; initiateur d’association: Entité d’application qui prend l’initiative
d’établir l’association d’application.
3.6.2 entité d’application répondant à la demande d’association; répondeur d’association: Entité d’application
qui répond à l’initiative d’établissement d’application prise par une autre entité d’application.
3.6.3 entité d’application invocatrice; invocateur: Entité d’application qui invoque l’opération distante.
3.6.4 entité d’application exécutrice; exécutant: Entité d’application qui exécute une opération distante invoquée
par l’autre entité d’application.
3.6.5 demandeur: Partie d’une entité d’application qui émet une primitive de demande pour un service ROSE
donné.
Rec. UIT-T X.881 (1994 F) 3
ISOKEI 13712-2 : 1995 (F)
3.6.6 accepteur: Partie d’une entité d’application qui reçoit la primitive d’indication pour un service ROSE donné.
3.6.7 opérations liées: Voir 3.3.8 de la Rec. UIT-T X.880 1 ISOKEI 13712-l.
3.6.8 opération mère Opération pendant 1 ‘exécution de laquelle l’exécutant peut in voquer des opérations liées.
par l’exécutant de 1 ‘opération mère en réponse à l’invocation de cette
3.6.9 fille: Opérati on invoquée
dernière.
utilisateur ACSE: La partie d’une entité d’application qui projette les opérations de rattachement et de
3.6.10
détachement sur des éléments ACSE.
3.6.11 élément de service d’opérations distantes: L’élément de service d’application défini dans la présente
Recommandation I Norme internationale.
3.6.12 fournisseur ROSE: Fournisseur des services de l’élément de service d’opérations distantes.
utilisateur ROSE: Partie d’une entité d’application qui interagit avec le service ROSE pour les besoins de
3.6.13
communication avec l’utilisateur homologue distant.
3.6.14 utilisateur RTSE: Partie d’une entité d’application qui projette les opérations de rattachement et de
détachement sur des éléments RTSE.
4 Abréviations
AE Entité d’application (application entity)
ACSE Elément de service de contrôle d’association (association control service element)
ASE Elément de service d’application (application service element)
ASN. 1 Notation de syntaxe abstraite numéro un (abstract syntax notation one)
APDU Unité de données de protocole d’application (application protocol data unit)
RO (ou ROS) (service d’) Opérations distantes (remote operation service)
ROSE Elément de service d’opérations distantes (remote operations service element)
(service de) Transfert fiable (reliable transfer service)
RT (ou RTS)
RTSE Elément de service de transfert fiable (reliable transfer service element)
Conventions
La présente Recommandation I Norme internationale définit les services ROSE conformément aux conventions de
description définies dans la Rec. UIT-T X.210 I ISOKEI 1073 1. L’article 8 comporte, dans la définition de chaque
service ROSE, un tableau des paramètres de ses primitives. Pour une primitive donnée, la présence de chaque paramètre
est décrite par l’une des valeurs suivantes:
Néant Sans objet
M Obligatoire
U Option de l’utilisateur
C Conditionnel
0 Option du fournisseur du service ROSE
gauche
notation (=) indique qu’une valeur de paramètre est sémantiquement égale à la valeur qui figure sur sa
De plus, la
dans le tabl
Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
La présente Spécifïcation utilise la notation ASN. 1, telle qu’elle est spécifiée dans la Rec. UIT-T X.681 I
ISOKEI 8824-2 pour définir la classe d’objets informationnels APPLICATION-CONTEXT. Elle fournit aussi la
notation qui permet aux concepteurs d’applications ROS de spécifier des instances particulières de cette classe.
6 Modèle de VOS1 pour la réalisation du service ROS
La Figure 1, reprise de la Figure 3 de la Rec. UIT-T X.880 I ISOKEI 13712-l) représente un modèle général de
réalisation d’un service ROS avec des moyens de communication en intermédiaire.
TlS04180-941d01
Figure 1 - Service ROS réalisé avec des moyens de comnmication intermédiaires
Dans le cas présent, les pivots représentent la capacité pour les objets ROS d’invoquer des opérations distantes. Un pivot
donné correspond aux opérations d’un certain contrat d’association. L’objet de transfert d’information véhicule des unités
de données de protocole (PDU) entre les pivots.
Le présent document concerne les objets ROS, réalisés en tant que processus de la couche application, et l’intermédiaire
constitué des services de communication OSI.
La Figure 2 réorganise et développe la Figure 1 en lui superposant certains des principaux concepts de la couche
application de I’OSI.
Les objets pivots sont constitues de l’élément de service ROSE et d’une série d’éléments de service d’application (ASE)
propres à des opérations. L’élément ROSE, dont les services sont définis à l’article 8, pilote le protocole générique
nécessaire à l’invocation des diverses opérations et à l’envoi en retour du résultat de leur exécution. Chaque élément ASE
propre à une opération renferme la connaissance des définitions des opérations particulières mises en jeu par un lot
d’opérations donné. Quand celui-ci est asymétrique, l’élément ASE correspondant spécifique est également asymétrique,
et tient le rôle de client ou de serveur correspondant au rôle de l’objet ROS qu’il représente. Ensemble, l’élément ROSE et
les éléments ASE propres aux opérations disposent de la connaissance relative a toutes les opérations du contrat
d’association.
L’objet de transfert d’information est constitué par le fournisseur du service présentation OSI, et une série d’éléments de
service d’application (ASE) comportant un élément a-ASE et éventuellement un élément GA~E, et éventuellement des
éléments ASE leur servant de support (par exemple une élément ASE assurant une fonction d’agent d’utilisateur
d’annuaire). La série comporte toujours l’élément ACSE. Les différentes applications OS1 du service ROS résultent de
l’emploi de différentes séries d’éléments ASE.
On ne peut utiliser les services ROSE qu’après avoir créé un service de transfert sur l’association d’application. Ce
service de transfert peut être fourni soit directement au niveau du service de présentation, soit sous forme d’un service
fourni par un élément ASE (voir l’élément z-ASE de la Figure 2).
Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
p
a
%
P
CO
à
B
E
E
zj
Eléments ASE
l EMments ASE
- + supports w
$
a
a-AS E FASE
‘W
\
t
!E
W
FOURNISSEUR DU SERVICE PRÉSENTATION
Transfert de l’information
Intermédiaire
TE041 90-94/dO2
ément ASE assurant l’établissement et la libération (dynamiques) de l’association
a-ASE E
Bment ASE assurant le transfert de l’information
CASE E
ROSE E ément ASE d’opérations distantes
o-ASE E
éments ASE propres aux opérations
Figure 2 - Réalisation OS1 du service ROS
7 Contextes de couche application fondés sur le service ROS
71 . Considérations générales
Un contexte d’application est formé de l’ensemble des éléments ASE entrant dans la réalisation d’un contrat d’association
donné, munis des éventuelles règles assurant la coordination de leur fonctionnement. Il englobe tous les éléments ASE
contribuant aux pivots et à l’objet de transfert de l’information
Tous les contextes d’application constitutifs des pivots et qui relèvent de la présente Recommandation I Norme
internationale comportent l’élément ROSE. De plus, chacun de ces contextes application comporte un élément ASE
propre aux opérations pour chaque lot d’opérations (dont un pour le lot de connexion s’il y en a un).
On peut définir différents contextes d’application pour réaliser le même contrat d’association en utilisant différents jeux
d’éléments ASE pour prendre en charge le transfert de l’information. Les éléments ASE de transfert d’information seront
choisis de manière à répondre aux diverses spécifications de qualité de service inhérentes au contrat d’association.
NOTE 1 - Il se pourrait qu’à l’avenir on établisse des règles pour déterminer quels éléments ASE sont nécessaires pour
répondre à des spécifications données de qualité de service (QOS) (quality of service). D’ici là, on suppose qu’il s’agit d’un processus
manuel, autrement dit que le concepteur d’une réalisation tient compte de ces spécifications dans le choix des éléments ASE.
Tous les contextes d’application englobent l’élément de service de contrôle d’association ACSE, qu’il y tienne le rôle
d’élément a-ASE ou d’élément ASE support.
NOTE 2 - Le contexte d’application peut comporter des éléments ASE additionnels pour des besoins qui ne relèvent pas
des services ROSE, à condition de les agencer en harmonie avec les éléments ASE mentionnés ici.
6 Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
72 a Spécification du contexte d’application
7.2.1 Les aspects statiques de la définition d’un contexte d’application base sur le service ROS peuvent être decrits
sous la forme d’un objet informationnel de la classe APPLICATION CONTEXT (contexte d’application), qui est
spécifiée comme suit:
APPLICATION-CONTEXT ::= CLASS
&associationContract CONTRACT,
4kassociationRealization REALIZATION OPTIONAL,
&transferRealization REALIZATION,
&AbstractSyntaxes ABSTRACT-SYNTAX,
JkapplicationContextName OBJECT IDENTIFIER UNIQUE
WITH SYNTAX
CONTRACT &associationContract
[ESTABLISHED BY &associationRealization]
INFORMATION TRANSFER BY & transferRealization
ABSTRACT SYNTAXES &AbstractSyntaxes
APPLICATION CONTEXT NAME JkapplicationContextName
REALIZATION ::= TYPE-IDENTIFIER
Cette définition spécifie les aspects ROS d’une definition de contexte d’application. Si des éléments de service
d’application ASE autres que ceux du service d’opérations distantes ROS interviennent dans un contexte d’application, la
présente définition devient un élément d’une définition de contexte d’application composite.
La manière de définir un tel contexte d’application composite sort du cadre de la présente Recommandation I Norme
internationale.
7.2.2 Le champ &associationContract (contrat d’association) identifie le contrat d’association que concrétise ce
contexte d’application.
NOTE - Les intentions du concepteur de l’application quant à la possibilité pour le «répondeur d’effectuer le détachement»
et «la possibilité d’échec du détachement» sont indiquées dans le champ &associationContract.
7.2.3 Le champ &associationRealization (réalisation d’association) sera présent si et seulement si le champ
honnection du champ &associationContract est présent. Si c’est le cas, il identifiera une approche particulière
d’établissement et de libération dynamiques de l’association. Plusieurs de ces approches sont spécifiées dans la
Rec. UIT-T X.882 I ISOKEI 13712-3.
7.2.4 Le champ MransferRealization (réalisation du transfert) identifiera une réalisation particulière de l’objet de
transfert d’information. Plusieurs de ces approches sont spécifiées dans la Rec. UIT-T X.882 I ISOKEI 13712-3. Le
champ &AbstractSyntaxes (syntaxes abstraites) contient les syntaxes abstraites qui sont nécessaires pour véhiculer
l’information entre les objets, notamment les PDU pour invoquer les opérations du contrat et rendre compte de leur
résultat. Les spécifications de ces syntaxes abstraites sont données dans la Rec. UIT-T X.882 I ISOKEI 13712-3. On
utilisera la valeur &applicationContextName (nom du contexte d’application) lors de l’établissement de l’association
OSI, pour identifier le contexte d’application qui doit exister sur cette association.
73 . Relations avec les autres éléments ASE et les services de couche inférieure
Autres éléments de service d’application
7.3.1
L’élément de service ROSE est appelé a être utilisé avec d’autres éléments de service d’application (ASE) pour prendre
en charge des tâches interactives spécifiques de traitement de l’information. Aussi prévoit-on que l’élément ROSE sera
inclus dans un grand nombre de spécifications de contextes d’application.
L’élément ROSE et les autres éléments ASE inclus dans un contexte d’application doivent utiliser les moyens du service
de présentation de manière coordonnée entre eux.
Rec. UIT-T X.881 (1994 F) 7
ISO/CEI 13712-2 : 1995 (F)
L’élément ROSE nécessite qu’existe une association d’application placée sous le contrôle de l’élément de service de
contrôle d’association (ACSE).
Un élément du service de transfert fiable (RTSE) est inclus pour certaines spécifications de contexte d’application.
7.3.2 Service de présentation
Si on définit un contexte d’application incluant l’élément RTSE et l’élément ROSE, les services ROSE n’utilisent pas le
service de présentation.
Si on définit un contexte d’application incluant l’élément ROSE mais non l’élément RTSE, les services ROSE doivent
avoir accès au service de transmission de données de présentation P-DATA et doivent pouvoir utiliser l’unité
fonctionnelle duplex du service de présentation. Les services ROSE n’utilisent aucun autre service de présentation, et
n’imposent pas non plus de contraintes à leur utilisation.
On suppose que pour tous les services ROSE, la syntaxe abstraite nommée utilisée est identifiée. Ceci relève toutefois de
la compétence locale et sort du cadre de la présente Recommandation I Norme internationale.
8 Services ROSE de base
Les services ROSE sont énumérés dans le Tableau 1.
Tableau 1 - Services ROSE
Service
Type
RO-INVOKE (Invocation) Non confirmé
RO-RESULT (Résultat) Non confirmé
RO-ERROR (Erreur) Non confirmé
RO-REJECT-U (Rejet par l’utilisateur) Non confirmé
RO-REJECT-P (Rejet par le fournisseur) A l’initiative du fournisseur
RO-BIND (Rattachement) Confirmé
\
RO-UNBIND (Détachement) Confirmé
81 . Service RO-INVOKE
Ce service est utilisé par un utilisateur ROSE (l’invocateur) pour invoquer une opération devant être exécutée par un
autre utilisateur ROSE (l’exécutant). Il s’agit d’un service non confirmé.
La structure de service correspondante se compose de deux primitiy :s de service, comme l’indique la Figure 3.
Utilisateur Fournisseur Utilisateur
ROSE ROSE
ROSE
Mication
RO-INVOKE ’
TlS04200-94/d03
Figure 3 - Primitives de service ROIINVOKE
8 Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
Le Tableau 2 énumère les
paramètres du service RO-INVOKE.
Tableau 2 - Paramètres du service RO-INVOKE
Nom du paramètre Demande Indication
Operation-id (Identificateur d’opération) M
M(=)
Operation-type (Type d’opération) U
Argument (Argument) U
C(=l
M
Invoke-id (Identificateur d’invocation)
M(=l
Linked-id (Identificateur de ligature) U
C(=)
U
Priority (Priorité)
8.1.1 Operation-id
Ce paramètre identifie l’opération à exécuter dans le cadre d’un contrat donné. Il véhicule l’identificateur
&operationCode (code d’opération) tiré de la définition de l’opération.
8.1.2 Operation-type
Ce paramètre précise si l’opération est de type
-
synchrone ou non.
(synchrone) de la définition de l’opération. L’absence de ce paramètre
L’information est tirée du champ 8zsynchronous
implique que l’opération est asynchrone.
8.1.3 Argument
Ce paramètre est l’argument de l’opération invoquée. Il peut être présent si et seulement si le champ &ArgumentType
figure dans la définition de l’opération. S’il est présent, il est du type indiqué par le champ.
8.1.4 Invoke-id
Ce paramètre identifie une requête de service RO-INVOKE et sert à la carreler avec les réponses correspondantes
(services RO-RESULT, RO-ERROR, RO-REJECT-U et RO-REJECT-P) ou avec l’invocation, par l’exécutant,
d’opérations filles liées (RO-INVOKE). Il doit être fourni par le demandeur du service.
Ce paramètre distingue plusieurs requêtes du service que le demandeur peut avoir en cours (opérations asynchrones). Le
demandeur peut réutiliser s’il le désire les identificateurs d’invocation, sous réserve qu’il ne s’agisse pas d’une valeur déjà
affectée à une demande du service pour laquelle il attend, sans l’avoir encore reçue, une réponse ou l’invocation d’une
opération fille liée.
L’utilisateur ROSE à qui est envoyée une indication RO-INVOKE estimera qu’un identificateur d’invocation
transgressant la règle ci-dessus est dédoublé; de ce fait, il n’exécutera pas l’opération en question et rejettera la requête en
double.
Si l’opération ne rend pas systématiquement compte de son résultat, le demandeur du service peut en réutiliser
l’identificateur d’invocation après un délai raisonnable ou si après réception d’une réponse acheminée par d’autres
moyens (par le résultat d’une opération du type «avez-vous terminé?» par exemple).
Dans certains contextes d’application, les utilisateurs ROSE homologues peuvent se communiquer des valeurs
d’identificateur d’invocation. Pour prendre en charge cette possibilité, on utilise, dans la définition des unités de données
du protocole ROS génériques, l’ensemble des valeurs admises pour le paramètre Invoke-id (voir 1’Annexe A de la
Rec. UIT-T X.880 I ISO/CEI 13712-1).
8.1.5 Linked-id
Si ce paramètre est présent, l’opération invoquée est une opération fille et le paramètre identifie l’invocation de
l’opération mère liée. Il doit être fourni par le demandeur du service, et sa valeur est celle du paramètre Invoke-id
d’invocation de la primitive d’indication RO-INVOKE de l’opération mère.
Rec. UIT-T X.881 (1994 F) 9
ISO/CEI 13712-2 : 1995 (F)
8.1.6 Priority
Ce paramètre définit la priorité assignée au transfert de I’APDU correspondante par rapport aux autres APDU qui
doivent être échangées entre les entités d’application. Plus sa valeur est faible, plus sa priorité est forte. Si plusieurs
unités APDU de même priorité attendent d’être transférées, elles le seront dans l’ordre de leur arrivée.
NOTES
1 Le paramètre de priorité n’est utilisé qu’en association avec l’élément de service de transfert fiable (RTSE) en tant que
service de transfert. Il ne sera utilisé dans aucune autre réalisation.
2 Dans le cas d’une association bidirectionnelle à l’altemat, le paramètre de priorité a pour effet d’attribuer des priorités
pour l’émission d’APDU, et il peut donc être utilisé pour déterminer le moment de demander le «tour» d’émettre. Le paramètre de
priorité peut aussi avoir un effet local dans le cas d’une association bidirectionnelle simultanée.
3 La priorité d’une réponse (RO-RESULT, RO-ERROR et RO-REJECT-U) devra normalement être plus forte (valeur
plus faible) que la priorité de l’invocation correspondante.
Quand il est présent, le paramètre de priorité doit appartenir à l’intervalle de valeurs autorisées par le champ
&InvokePriority de la définition de l’opération.
82 . Service RO-RESULT
Le service RO-RESULT sert à un utilisateur ROSE pour répondre à une indication RO-INVOKE antérieure lorsque
l’opération a été exécutée avec succès. Il s’agit d’un service non confirmé.
La structure de service correspondante se compose de deux primitives de service. comme le montre la Figure 4.
*
Utilisateur
Utilisateur Fournisseur
ROSE ROSE ROSE
Demande
Indication
RO-RESULT ’
RO-RESULT ’
TlSO42 l O-94/dO4
Figure 4 - Primitives du service RO-RESULT
Le Tableau 3 énumere les paramètres du service RO-RESULT.
Tableau 3 - Paramètres du service RO-RESULT
Demande Indication
Nom du paramètre
Operation-id (Identificateur d’opération) U
c(=>
Result (Résultat) U
c(=>
M
Invoke-id (Identificateur d’invocation)
W=)
Priority (Priorité) U
8.2.1 Operation-id
Ce paramètre identifie l’opération dont le système annonce le résultat après l’avoir exécutée dans le cadre d’un contrat
d’opération. Il véhicule la valeur &operationCode (code d’opération) tirée de la définition de l’opération. Il ne sera
présent que si le paramètre Result est lui-même présent.
10 Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
8.2.2 Result
Ce paramètre est le résultat de l’opération. Il ne peut être présent que si et seulement si le champ &ResultType (type de
résultat) est présent dans la définition de l’opération, auquel cas il est du type indiqué par ce champ.
8.2.3 Invoke-id
Ce paramètre identifie l’invocation correspondante (voir 8.1.4). Il doit être fourni par le demandeur du service. Sa valeur
est celle de l’identificateur de la primitive d’indication RO-INVOKE correspondante.
8.2.4 Priority
Ce paramètre définit la priorité attribuée au transfert de I’APDU correspondante (voir 8.1.6).
NOTE - Le paramètre de priorité n’est utilisé qu’en association avec l’élément de service de transfert fiable (RTSE) en tant
que service de transfert. 11 ne sera utilisé dans aucune autre réalisation.
S’il est présent, le paramètre de priorité appartiendra à l’intervalle des valeurs autorisées par le champ &ResultPriority
de la définition de l’opération.
83 a Service RO-ERROR
Le service RO-ERROR sert à un utilisateur ROSE pour répondre à une indication RO-INVOKE antérieure lorsque
l’opération a échoué. Il s’agit d’un service non confirmé. La structure de service correspondante se compose de deux
primitives de service, comme le montre la Figure 5.
Utilisateur
Utilisateur Fournisseur
ROSE ROSE ROSE
~~~------œœ~~
Figure 5 - Primitives du service RO-ERROR
Le Tableau 4 énumère les paramètres du service RO-ERROR.
Tableau 4 - Paramètres du service RO-ERROR
Demande Indication
Nom du paramètre
Error-id (Identificateur d’erreur) M
M(=)
Parameter (Paramètre) U
C(=l
M
Invoke-id (Identificateur d’invocation)
M(=)
Priority (Priorité) U
8.3.1 Errer-id
Ce paramètre identifie l’erreur dont le système rend compte par suite de son incapacité à exécuter l’opération invoquée. Il
véhicule la valeur &errorCode (code d’erreur) tirée de la définition de l’erreur.
8.3.2 Parameter
C’est le paramètre de l’erreur. Il ne peut être présent que si et seulement si le champ &ParameterType (type de
paramètre) est présent dans la définition de l’erreur, auquel cas, il est du type indiqué par ce champ.
Rec. UIT-T X.881 (1994 F) 11
ISO/CEI 13712-2 : 1995 (F)
Invoke-id
8.3.3
Ce paramètre identifie l’invocation correspondante (voir 8.1.4). Il doit être fourni par le demandeur du service. Sa valeur
est celle de l’identificateur de la primitive d’indication RO-INVOKE correspondante.
8.3.4 Priority
Ce paramètre définit la priorité attribuée au transfert de I’APDU correspondante (voir 8.1.6).
NOTE - Le paramètre de priorité n’est utilisé qu’en association avec l’élément de service de transfert fiable (RTSE) en tant
que service de transfert. Il ne sera utilisé dans aucune autre réalisation.
S’il est présent, le paramètre de priorité appartiendra à l’intervalle des valeurs autorisées par le champ &ErrorPriority
de la définition de l’opération.
Service RO-RE JECT-U
84 .
Le service RO-REJECT-U sert à un utilisateur ROSE pour rejeter une demande (indication RO-INVOKE) émanant d’un
autre utilisateur ROSE au cas où il a détecté une difficulté. Le service RO-REJECT-U peut également être utilisé par un
utilisateur ROSE pour rejeter une réponse (indication RO-RESULT ou indication RO-ERROR) provenant de l’autre
utilisateur. Cependant, pour éviter de transgresser les règles d’ordonnancement des autres éléments ASE dans certains
contextes d’application, un utilisateur ROSE peut ne pas utiliser le service RO-REJECT-U pour rejeter les réponses. Il
s’agit d’un service non confirmé.
La structure de service correspondante se compose de deux primitives de service, comme le montre la Figure 6.
Utilisateur Fournisseur Utilisateur
ROSE ROSE
ROSE
Demande
0-11
--œ-
0-œ
RO-REJECT-U ’
RO-RE
...
NORME
ISO/CEI
INTERNATIONALE
13712-2
Première édition
1995-04-I 5
Technologies de l’information -
Opérations distantes: Réalisations OSI -
Définition‘ du service de l’élément de
service d’opérations distantes (ROSE)
Information technology
- Remote Opera tions: OSI realizations -
Remo te Opera tions Service Elemen t (ROSE) service de finition
Numéro de référence
ISO/CEI 13712-2:1995(F)
ISOKEI 13712-2: 1995(F)
Sommaire
Page
Domaine d’application .
Références normatives .
...................................................................... 1
2.1 Recommandations I Normes internationales identiques
....... 2
2.2 Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
Définitions . 2
3.1 Définitions relatives au modèle de référence . 2
3.2 Définitions relatives aux conventions de service . 3
3.3 Définitions relatives au service de présentation . 3
3.4 Définitions du contrôle d’association . 3
............................................................................................................. 3
3.5 Définitions du transfert fiable
............................................................................................... 3
3.6 Définitions relatives a l’élément ROSE
Abreviations .
Conventions .
Modèle de I’OSI pour la realisation du service ROS . 5
.......................................................................... 6
Contextes de couche application fondés sur le service ROS
7.1 Considérations générales .
............................................................................................... 7
7.2 Spécification du contexte d’application
..................................... 7
7.3 Relations avec les autres éléments ASE et les services de couche inférieure
Services ROSE de base .
81 Service RO-INVOKE .
8:2 Service RO-RESULT . 10
........................................................................................................................... 11
83 Service RO-ERROR
...................................................................................................................... 12
8:4 Service RO-REJECT-U
85 . Service RO-REJECT-P .
86 Service RO-BIND .
8:7 Service RO-UNBIND . 16
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- 1211 Genève 20 l Suisse
Version française tirée en 1996
Imprimé en Suisse
ii
ISOKEI 13712-2: 1995(F)
0 ISOKEI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9 Renseignements sur la mise en séquence
91 . Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92 . Opérations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93 Autres règles d’ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9:4 Gestion des identificateurs d’invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Projection sur les services ROSE .
11 Projection sur les services RO-BIND et RO-UNBIND .
11.1 Projection sur les services ACSE .
........................................................................................................ 25
11.2 Projection sur les services RTSE
..................................................................................................................................... 28
Annexe A - Modules ASN.l
........................................................................................ 29
Annexe B - Directives concernant l’emploi de la notation
B. 1 Exemples d’objets informationnels de la classe Application Context . 29
B .2 Libération méthodique des associations d’application . 29
.................................................................................... 32
Annexe C - Affectation des valeurs d’identificateurs d’objet
. . .
ISOKEI 13712-2: 1995(F)
@ ISOKEI
Avant-propos
LIS0 (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 1’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 1’ISO et la CE1
participent également aux travaux.
Dans le domaine des technologies de l’information, I’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-2 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de Z’information, sous-comité SC 21,
Interconnexion des systèmes ouverts, gestion des données et traitement distribué
ouvert, en collaboration avec l’IUT-T. Le texte identique est publié en tant que
Recommandation IUT-T X.88 1.
La présente partie de I’ISOKEI 137 12 est une révision partielle de
1’ISOKEI 9072- 1: 1989.
L’ISOKEI 137 12 comprend les parties suivantes, présentées sous le titre général
Technologies de 1 ‘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 1’ISOICEI 13712. Les
annexes B et C sont données uniquement à titre d’information.
1v
@ ISOKEI ISO/CEI 13712-2: 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 utilise pour la conception et la spécification des applications reparties. 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 résultat de l’opération retourné à l’invocateur.
Les concepts d’opérations distantes, tels qu’ils sont spécifiés dans la Rec. UIT-T X.880 I ISOKEI 13712-1, sont abstraits
et peuvent être réalisés de multiples manieres. 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 fournit le cadre pour la réalisation d’un lot d’opérations et d’un
contrat d’association formant un contexte d’application OSI. Un tel contexte d’application est spécifié fondamentalement
en termes d’une collection d’élements de service application (ASE) (application service element). Dans une optique
ROS, ces éléments ASE relèvent de trois grandes catégories:
les éléments ASE spécifiques aux opération s, qui contiennent la tonnai .ssance relative aux définitions des
a)
opérations du contrat d’association
b) les éléments ASE d’opérations distantes (ROSE), qui pilotent le protocole géneral nécessaire à
l’invocation d’opérations quelconques et à l’annonce de leurs résultats;
c) les éléments ASE de transfert d’information qui interviennent dans l’établissement et la libération des
associations, si besoin est, et dans la communication des informations de commande de protocole (PCI)
du service ROSE. Dans l’application OSI, les éléments ASE sont l’élément de service de contrôle
d’association (ACSE) et l’élément de service de transfert fiable (RTSE) utilisés conjointement avec les
services de la couche présentation.
La présente Recommandation I Norme internationale est axée sur l’établissement des spécifications du contexte
d’application d’opérations distantes ROSE, le service qu’assure l’élément de service ROSE et la manière de l’utiliser. Elle
est une révision de la Rec. X.2 19 du CCITT I ISOKEI 9072-l. L’utilisation actuelle du service ROSE, en relation avec
les éléments ACSE et RTSE et la couche présentation, telle qu’elle est définie dans la Rec. X.219 du CCITT I
ISOKEI 9072-l) reste valable après la présente révision. Cette révision ne modifie en rien l’information de commande
du protocole PC1 du service ROSE.
L’Annexe A fait partie intégrante de la présente Recommandation I Norme internationale.
Les Annexes B et C ne font pas partie intégrante de la présente Recommandation I Norme internationale.
Page blanche
ISOKEI 13712-2 : 1995 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION -
OPÉRATIONS DISTANTES: RÉALISATIONS OS1 - DÉFINITION DU SERVICE
DE L’ÉLÉMENT DE SERVICE D’OPÉRATIONS DISTANTES (ROSE)
1 Domaine d’application
La présente Recommandation I Norme internationale fournit le cadre pour la réalisation, d’un contexte d’application OS1
mettant en œuvre les concepts abstraits de lot d’opérations et de contrat d’association définis dans la Rec. UIT-T X.880 I
ISOKEI 137 12-1. Un tel contexte d’application est décrit sous la forme d’une série d’élements de service d’application
(ASE), en particulier l’élément de service d’opérations distantes (ROSE) qui commande le protocole général d’invocation
d’opérations quelconques et d’envoi en retour de leurs résultats.
Les termes, définitions et mécanismes définis dans la Rec. UIT-T X.880 I ISOKEI 13712-1 sont applicables ci-après et
sont spécifiques d’une réalisation OS1 conforme à la présente Recommandation I Norme internationale. La présente
Recommandation I Norme internationale est axée sur les services fournis par le service ROSE et sur la manière de
l’utiliser. Les services ROSE sont assurés par la mise en œuvre du protocole ROSE (spécifié dans la Rec. UIT-T X.882 I
ISOKEI 13712-3) conjointement avec les services de l’élément de service de contrôle d’association (ACSE)
(Rec. UIT-T X.217 I ISOKEI 8649), du protocole ACSE (Rec. UIT-T X.227 I ISOKEI 8650-l) et, facultativement avec
les services de l’élément du service de transfert fiable (RTSE) (Rec. UIT-T X.21 8 I ISOKEI 9066-l), du protocole RTSE
(Rec. UIT-T X.228 I ISOKEI 9066-2) et avec le service de présentation (Rec. UIT-T X.216 I ISOKEI 8822).
Aucune spécification n’est imposée quant à la conformité à la présente Recommandation I Norme internationale.
2 Références normatives
Les Recommandations UIT-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 sont sujettes à révision et les
parties prenantes aux accords fondés sur la présente Spécifïcation sont invitées à rechercher la possibilité d’appliquer les
éditions les plus récentes des Recommandations et Normes 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 b Recommandations l Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l : 1994, Technologie de I?nformation -
Interconnexion de systèmes ouverts - Modèle de référence de base: Le modèle de référence de base.
-
Recommandation UIT-T X.210 (1993) I ISOKEI 10731:1994, Technologie de Z’information -
Interconnexion de systèmes ouverts - Conventions relatives à la définition des services OSI.
-
Recommandation UIT-T X.215 (1994) I ISO/CEI 8326: -l), Technologie de l’information -
Interconnexion de systèmes ouverts - Définition du service de couche session.
- Recommandation UIT-T X.216 (1994) I ISOKEI 8822: 1994, Technologie de l’information -
Interconnexion de systèmes ouverts - Définition du service de présentation.
-
Recommandation UIT-T X.217 (1995) I ISOKEI 8649: -2>, Technologie de l’information -
Interconnexion de systèmes ouverts - Definition du service de l’élément de service de contrôle
d’association.
-
Recommandation UIT-T X.227 (1995) I ISOKEI 8650: -31, Technologie de l’information -
Interconnexion de systèmes ouverts - Spécifkation du protocole de l’élément de service de commande
d’association (ACSE) en mode connexion.
1) À publier (Révision de VIS0 8326: 1987)
2) À publier (Révision de 1’ISO 8649:1988)
3) À publier (Révision de I’ISO 8650:1988)
Rec. UIT-T X.881 (1994 F) 1
ISOKEI 13712-2 : 1995 (F)
-
Recommandation UIT-T X.680 (1994) I ISOKEI 8824-l : 1995, Technologie de I?nformation - Notation
de syntaxe abstraite numéro un: Spéciflcation de la notation de base.
-
Recommandation UIT-T X.681 (1994) I ISOKEI 8824-2: 1995, Technologie de Z’information - Notation
de syntaxe abstraite numéro un: Spécification des objets informationnels.
-
Recommandation UIT-T X.682 (1994) l ISOKEI 8824-3:1995, Technologie de Z’information - Notation
de syntaxe abstraite numéro un: SpécifZcation 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.880 (1994) I ISOKEI 13712-1: 1995, Technologie de L’information -
Opérations distantes: Concepts, modèle et notation.
-
Recommandation UIT-T X.882 (1994) I ISOKEI 137 12-3: 1995, Technologie de Z’information -
Opérations distantes: Réalisations OSI: Spécification du protocole de l’élément de service d’opérations
distantes.
22 . Paires de Recommandations I Normes internationales équivalentes par leur contenu technique
-
Recommandation UIT-T X.2 18 (1993), Transfertfiable: modèle et définition du service.
de texte - Transfert
ISOKEI 9066- 1: 1989, Systèmes de traitement de 1 ‘information - Communication
fiable Partie 1: Modèle et définition du service.
-
Recommandation UIT-T X.228 (1993), Transfert fiable: Spécification du protocole.
de texte - Transfert
ISOICEI 9066-2: 1989, Systèmes de traitement de l’information - Communication
fiable Partie 2: Spécification du protocole.
-
Recommandation X.219 du CCITT (1988), Opérations distantes: modèle, notation et définition du
service.
ISOICEI 9072-l : 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.
Communication de texte - Opérations à
ISOKEI 9072-2: 1989, Systèmes de traitement de l’information -
distance - Partie 2: Spécifkation du protocole.
3 Définitions
31 . Définitions relatives au modèle de référence
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.200 I
ISOKEI 7498- 1:
syntaxe abstraite;
a)
b) couche application;
c) processus d’application;
d) entité d’application;
élément de service d’application;
e)
unité de données de protocole d’application;
g) informations de contrôle du protocole d’application;
h) couche présentation;
service de présentation.
Rec. UIT-T X.881 (1994 F)
ISOKEI 1371212 : 1995 (F)
32 Définitions relatives aux conventions de service
.
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.210 I
ISOKEI 1073 1:
fournisseur de service;
a)
utilisateur de service;
W
service confirmé;
Cl
service non confirmé;
d)
service engendré par le fournisseur;
e)
primitive de service; primitive;
f)
(primitive de) demande;
g)
(primitive d’) indication;
h)
(primitive de) réponse; et
.
(primitive de) confirmation.
J)
33 0 Définitions relatives au service de présentation
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.216 I
ISOKEI 8822:
nom de syntaxe abstraite;
a)
b) nom de syntaxe de transfert;
contexte de présentation.
C>
34 . Définitions du contrôle d’association
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.217 I
ISOKEI 8649:
association d’application; association;
a>
b) contexte d’application;
élément de service de contrôle d’association.
Cl
35 . Définitions du transfert fiable
La présente Recommandation I Norme internationale utilise les termes suivants, définis dans la Rec. UIT-T X.21 8 I
ISOKEI 9066:
-
élément de service de transfert fiable.
36 . Définitions relatives à l’élément ROSE
Pour les besoins de la présente Recommandation I Norme internationale, les définitions suivantes s’appliquent:
3.6.1 entité d’application initiant l’association; initiateur d’association: Entité d’application qui prend l’initiative
d’établir l’association d’application.
3.6.2 entité d’application répondant à la demande d’association; répondeur d’association: Entité d’application
qui répond à l’initiative d’établissement d’application prise par une autre entité d’application.
3.6.3 entité d’application invocatrice; invocateur: Entité d’application qui invoque l’opération distante.
3.6.4 entité d’application exécutrice; exécutant: Entité d’application qui exécute une opération distante invoquée
par l’autre entité d’application.
3.6.5 demandeur: Partie d’une entité d’application qui émet une primitive de demande pour un service ROSE
donné.
Rec. UIT-T X.881 (1994 F) 3
ISOKEI 13712-2 : 1995 (F)
3.6.6 accepteur: Partie d’une entité d’application qui reçoit la primitive d’indication pour un service ROSE donné.
3.6.7 opérations liées: Voir 3.3.8 de la Rec. UIT-T X.880 1 ISOKEI 13712-l.
3.6.8 opération mère Opération pendant 1 ‘exécution de laquelle l’exécutant peut in voquer des opérations liées.
par l’exécutant de 1 ‘opération mère en réponse à l’invocation de cette
3.6.9 fille: Opérati on invoquée
dernière.
utilisateur ACSE: La partie d’une entité d’application qui projette les opérations de rattachement et de
3.6.10
détachement sur des éléments ACSE.
3.6.11 élément de service d’opérations distantes: L’élément de service d’application défini dans la présente
Recommandation I Norme internationale.
3.6.12 fournisseur ROSE: Fournisseur des services de l’élément de service d’opérations distantes.
utilisateur ROSE: Partie d’une entité d’application qui interagit avec le service ROSE pour les besoins de
3.6.13
communication avec l’utilisateur homologue distant.
3.6.14 utilisateur RTSE: Partie d’une entité d’application qui projette les opérations de rattachement et de
détachement sur des éléments RTSE.
4 Abréviations
AE Entité d’application (application entity)
ACSE Elément de service de contrôle d’association (association control service element)
ASE Elément de service d’application (application service element)
ASN. 1 Notation de syntaxe abstraite numéro un (abstract syntax notation one)
APDU Unité de données de protocole d’application (application protocol data unit)
RO (ou ROS) (service d’) Opérations distantes (remote operation service)
ROSE Elément de service d’opérations distantes (remote operations service element)
(service de) Transfert fiable (reliable transfer service)
RT (ou RTS)
RTSE Elément de service de transfert fiable (reliable transfer service element)
Conventions
La présente Recommandation I Norme internationale définit les services ROSE conformément aux conventions de
description définies dans la Rec. UIT-T X.210 I ISOKEI 1073 1. L’article 8 comporte, dans la définition de chaque
service ROSE, un tableau des paramètres de ses primitives. Pour une primitive donnée, la présence de chaque paramètre
est décrite par l’une des valeurs suivantes:
Néant Sans objet
M Obligatoire
U Option de l’utilisateur
C Conditionnel
0 Option du fournisseur du service ROSE
gauche
notation (=) indique qu’une valeur de paramètre est sémantiquement égale à la valeur qui figure sur sa
De plus, la
dans le tabl
Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
La présente Spécifïcation utilise la notation ASN. 1, telle qu’elle est spécifiée dans la Rec. UIT-T X.681 I
ISOKEI 8824-2 pour définir la classe d’objets informationnels APPLICATION-CONTEXT. Elle fournit aussi la
notation qui permet aux concepteurs d’applications ROS de spécifier des instances particulières de cette classe.
6 Modèle de VOS1 pour la réalisation du service ROS
La Figure 1, reprise de la Figure 3 de la Rec. UIT-T X.880 I ISOKEI 13712-l) représente un modèle général de
réalisation d’un service ROS avec des moyens de communication en intermédiaire.
TlS04180-941d01
Figure 1 - Service ROS réalisé avec des moyens de comnmication intermédiaires
Dans le cas présent, les pivots représentent la capacité pour les objets ROS d’invoquer des opérations distantes. Un pivot
donné correspond aux opérations d’un certain contrat d’association. L’objet de transfert d’information véhicule des unités
de données de protocole (PDU) entre les pivots.
Le présent document concerne les objets ROS, réalisés en tant que processus de la couche application, et l’intermédiaire
constitué des services de communication OSI.
La Figure 2 réorganise et développe la Figure 1 en lui superposant certains des principaux concepts de la couche
application de I’OSI.
Les objets pivots sont constitues de l’élément de service ROSE et d’une série d’éléments de service d’application (ASE)
propres à des opérations. L’élément ROSE, dont les services sont définis à l’article 8, pilote le protocole générique
nécessaire à l’invocation des diverses opérations et à l’envoi en retour du résultat de leur exécution. Chaque élément ASE
propre à une opération renferme la connaissance des définitions des opérations particulières mises en jeu par un lot
d’opérations donné. Quand celui-ci est asymétrique, l’élément ASE correspondant spécifique est également asymétrique,
et tient le rôle de client ou de serveur correspondant au rôle de l’objet ROS qu’il représente. Ensemble, l’élément ROSE et
les éléments ASE propres aux opérations disposent de la connaissance relative a toutes les opérations du contrat
d’association.
L’objet de transfert d’information est constitué par le fournisseur du service présentation OSI, et une série d’éléments de
service d’application (ASE) comportant un élément a-ASE et éventuellement un élément GA~E, et éventuellement des
éléments ASE leur servant de support (par exemple une élément ASE assurant une fonction d’agent d’utilisateur
d’annuaire). La série comporte toujours l’élément ACSE. Les différentes applications OS1 du service ROS résultent de
l’emploi de différentes séries d’éléments ASE.
On ne peut utiliser les services ROSE qu’après avoir créé un service de transfert sur l’association d’application. Ce
service de transfert peut être fourni soit directement au niveau du service de présentation, soit sous forme d’un service
fourni par un élément ASE (voir l’élément z-ASE de la Figure 2).
Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
p
a
%
P
CO
à
B
E
E
zj
Eléments ASE
l EMments ASE
- + supports w
$
a
a-AS E FASE
‘W
\
t
!E
W
FOURNISSEUR DU SERVICE PRÉSENTATION
Transfert de l’information
Intermédiaire
TE041 90-94/dO2
ément ASE assurant l’établissement et la libération (dynamiques) de l’association
a-ASE E
Bment ASE assurant le transfert de l’information
CASE E
ROSE E ément ASE d’opérations distantes
o-ASE E
éments ASE propres aux opérations
Figure 2 - Réalisation OS1 du service ROS
7 Contextes de couche application fondés sur le service ROS
71 . Considérations générales
Un contexte d’application est formé de l’ensemble des éléments ASE entrant dans la réalisation d’un contrat d’association
donné, munis des éventuelles règles assurant la coordination de leur fonctionnement. Il englobe tous les éléments ASE
contribuant aux pivots et à l’objet de transfert de l’information
Tous les contextes d’application constitutifs des pivots et qui relèvent de la présente Recommandation I Norme
internationale comportent l’élément ROSE. De plus, chacun de ces contextes application comporte un élément ASE
propre aux opérations pour chaque lot d’opérations (dont un pour le lot de connexion s’il y en a un).
On peut définir différents contextes d’application pour réaliser le même contrat d’association en utilisant différents jeux
d’éléments ASE pour prendre en charge le transfert de l’information. Les éléments ASE de transfert d’information seront
choisis de manière à répondre aux diverses spécifications de qualité de service inhérentes au contrat d’association.
NOTE 1 - Il se pourrait qu’à l’avenir on établisse des règles pour déterminer quels éléments ASE sont nécessaires pour
répondre à des spécifications données de qualité de service (QOS) (quality of service). D’ici là, on suppose qu’il s’agit d’un processus
manuel, autrement dit que le concepteur d’une réalisation tient compte de ces spécifications dans le choix des éléments ASE.
Tous les contextes d’application englobent l’élément de service de contrôle d’association ACSE, qu’il y tienne le rôle
d’élément a-ASE ou d’élément ASE support.
NOTE 2 - Le contexte d’application peut comporter des éléments ASE additionnels pour des besoins qui ne relèvent pas
des services ROSE, à condition de les agencer en harmonie avec les éléments ASE mentionnés ici.
6 Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
72 a Spécification du contexte d’application
7.2.1 Les aspects statiques de la définition d’un contexte d’application base sur le service ROS peuvent être decrits
sous la forme d’un objet informationnel de la classe APPLICATION CONTEXT (contexte d’application), qui est
spécifiée comme suit:
APPLICATION-CONTEXT ::= CLASS
&associationContract CONTRACT,
4kassociationRealization REALIZATION OPTIONAL,
&transferRealization REALIZATION,
&AbstractSyntaxes ABSTRACT-SYNTAX,
JkapplicationContextName OBJECT IDENTIFIER UNIQUE
WITH SYNTAX
CONTRACT &associationContract
[ESTABLISHED BY &associationRealization]
INFORMATION TRANSFER BY & transferRealization
ABSTRACT SYNTAXES &AbstractSyntaxes
APPLICATION CONTEXT NAME JkapplicationContextName
REALIZATION ::= TYPE-IDENTIFIER
Cette définition spécifie les aspects ROS d’une definition de contexte d’application. Si des éléments de service
d’application ASE autres que ceux du service d’opérations distantes ROS interviennent dans un contexte d’application, la
présente définition devient un élément d’une définition de contexte d’application composite.
La manière de définir un tel contexte d’application composite sort du cadre de la présente Recommandation I Norme
internationale.
7.2.2 Le champ &associationContract (contrat d’association) identifie le contrat d’association que concrétise ce
contexte d’application.
NOTE - Les intentions du concepteur de l’application quant à la possibilité pour le «répondeur d’effectuer le détachement»
et «la possibilité d’échec du détachement» sont indiquées dans le champ &associationContract.
7.2.3 Le champ &associationRealization (réalisation d’association) sera présent si et seulement si le champ
honnection du champ &associationContract est présent. Si c’est le cas, il identifiera une approche particulière
d’établissement et de libération dynamiques de l’association. Plusieurs de ces approches sont spécifiées dans la
Rec. UIT-T X.882 I ISOKEI 13712-3.
7.2.4 Le champ MransferRealization (réalisation du transfert) identifiera une réalisation particulière de l’objet de
transfert d’information. Plusieurs de ces approches sont spécifiées dans la Rec. UIT-T X.882 I ISOKEI 13712-3. Le
champ &AbstractSyntaxes (syntaxes abstraites) contient les syntaxes abstraites qui sont nécessaires pour véhiculer
l’information entre les objets, notamment les PDU pour invoquer les opérations du contrat et rendre compte de leur
résultat. Les spécifications de ces syntaxes abstraites sont données dans la Rec. UIT-T X.882 I ISOKEI 13712-3. On
utilisera la valeur &applicationContextName (nom du contexte d’application) lors de l’établissement de l’association
OSI, pour identifier le contexte d’application qui doit exister sur cette association.
73 . Relations avec les autres éléments ASE et les services de couche inférieure
Autres éléments de service d’application
7.3.1
L’élément de service ROSE est appelé a être utilisé avec d’autres éléments de service d’application (ASE) pour prendre
en charge des tâches interactives spécifiques de traitement de l’information. Aussi prévoit-on que l’élément ROSE sera
inclus dans un grand nombre de spécifications de contextes d’application.
L’élément ROSE et les autres éléments ASE inclus dans un contexte d’application doivent utiliser les moyens du service
de présentation de manière coordonnée entre eux.
Rec. UIT-T X.881 (1994 F) 7
ISO/CEI 13712-2 : 1995 (F)
L’élément ROSE nécessite qu’existe une association d’application placée sous le contrôle de l’élément de service de
contrôle d’association (ACSE).
Un élément du service de transfert fiable (RTSE) est inclus pour certaines spécifications de contexte d’application.
7.3.2 Service de présentation
Si on définit un contexte d’application incluant l’élément RTSE et l’élément ROSE, les services ROSE n’utilisent pas le
service de présentation.
Si on définit un contexte d’application incluant l’élément ROSE mais non l’élément RTSE, les services ROSE doivent
avoir accès au service de transmission de données de présentation P-DATA et doivent pouvoir utiliser l’unité
fonctionnelle duplex du service de présentation. Les services ROSE n’utilisent aucun autre service de présentation, et
n’imposent pas non plus de contraintes à leur utilisation.
On suppose que pour tous les services ROSE, la syntaxe abstraite nommée utilisée est identifiée. Ceci relève toutefois de
la compétence locale et sort du cadre de la présente Recommandation I Norme internationale.
8 Services ROSE de base
Les services ROSE sont énumérés dans le Tableau 1.
Tableau 1 - Services ROSE
Service
Type
RO-INVOKE (Invocation) Non confirmé
RO-RESULT (Résultat) Non confirmé
RO-ERROR (Erreur) Non confirmé
RO-REJECT-U (Rejet par l’utilisateur) Non confirmé
RO-REJECT-P (Rejet par le fournisseur) A l’initiative du fournisseur
RO-BIND (Rattachement) Confirmé
\
RO-UNBIND (Détachement) Confirmé
81 . Service RO-INVOKE
Ce service est utilisé par un utilisateur ROSE (l’invocateur) pour invoquer une opération devant être exécutée par un
autre utilisateur ROSE (l’exécutant). Il s’agit d’un service non confirmé.
La structure de service correspondante se compose de deux primitiy :s de service, comme l’indique la Figure 3.
Utilisateur Fournisseur Utilisateur
ROSE ROSE
ROSE
Mication
RO-INVOKE ’
TlS04200-94/d03
Figure 3 - Primitives de service ROIINVOKE
8 Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
Le Tableau 2 énumère les
paramètres du service RO-INVOKE.
Tableau 2 - Paramètres du service RO-INVOKE
Nom du paramètre Demande Indication
Operation-id (Identificateur d’opération) M
M(=)
Operation-type (Type d’opération) U
Argument (Argument) U
C(=l
M
Invoke-id (Identificateur d’invocation)
M(=l
Linked-id (Identificateur de ligature) U
C(=)
U
Priority (Priorité)
8.1.1 Operation-id
Ce paramètre identifie l’opération à exécuter dans le cadre d’un contrat donné. Il véhicule l’identificateur
&operationCode (code d’opération) tiré de la définition de l’opération.
8.1.2 Operation-type
Ce paramètre précise si l’opération est de type
-
synchrone ou non.
(synchrone) de la définition de l’opération. L’absence de ce paramètre
L’information est tirée du champ 8zsynchronous
implique que l’opération est asynchrone.
8.1.3 Argument
Ce paramètre est l’argument de l’opération invoquée. Il peut être présent si et seulement si le champ &ArgumentType
figure dans la définition de l’opération. S’il est présent, il est du type indiqué par le champ.
8.1.4 Invoke-id
Ce paramètre identifie une requête de service RO-INVOKE et sert à la carreler avec les réponses correspondantes
(services RO-RESULT, RO-ERROR, RO-REJECT-U et RO-REJECT-P) ou avec l’invocation, par l’exécutant,
d’opérations filles liées (RO-INVOKE). Il doit être fourni par le demandeur du service.
Ce paramètre distingue plusieurs requêtes du service que le demandeur peut avoir en cours (opérations asynchrones). Le
demandeur peut réutiliser s’il le désire les identificateurs d’invocation, sous réserve qu’il ne s’agisse pas d’une valeur déjà
affectée à une demande du service pour laquelle il attend, sans l’avoir encore reçue, une réponse ou l’invocation d’une
opération fille liée.
L’utilisateur ROSE à qui est envoyée une indication RO-INVOKE estimera qu’un identificateur d’invocation
transgressant la règle ci-dessus est dédoublé; de ce fait, il n’exécutera pas l’opération en question et rejettera la requête en
double.
Si l’opération ne rend pas systématiquement compte de son résultat, le demandeur du service peut en réutiliser
l’identificateur d’invocation après un délai raisonnable ou si après réception d’une réponse acheminée par d’autres
moyens (par le résultat d’une opération du type «avez-vous terminé?» par exemple).
Dans certains contextes d’application, les utilisateurs ROSE homologues peuvent se communiquer des valeurs
d’identificateur d’invocation. Pour prendre en charge cette possibilité, on utilise, dans la définition des unités de données
du protocole ROS génériques, l’ensemble des valeurs admises pour le paramètre Invoke-id (voir 1’Annexe A de la
Rec. UIT-T X.880 I ISO/CEI 13712-1).
8.1.5 Linked-id
Si ce paramètre est présent, l’opération invoquée est une opération fille et le paramètre identifie l’invocation de
l’opération mère liée. Il doit être fourni par le demandeur du service, et sa valeur est celle du paramètre Invoke-id
d’invocation de la primitive d’indication RO-INVOKE de l’opération mère.
Rec. UIT-T X.881 (1994 F) 9
ISO/CEI 13712-2 : 1995 (F)
8.1.6 Priority
Ce paramètre définit la priorité assignée au transfert de I’APDU correspondante par rapport aux autres APDU qui
doivent être échangées entre les entités d’application. Plus sa valeur est faible, plus sa priorité est forte. Si plusieurs
unités APDU de même priorité attendent d’être transférées, elles le seront dans l’ordre de leur arrivée.
NOTES
1 Le paramètre de priorité n’est utilisé qu’en association avec l’élément de service de transfert fiable (RTSE) en tant que
service de transfert. Il ne sera utilisé dans aucune autre réalisation.
2 Dans le cas d’une association bidirectionnelle à l’altemat, le paramètre de priorité a pour effet d’attribuer des priorités
pour l’émission d’APDU, et il peut donc être utilisé pour déterminer le moment de demander le «tour» d’émettre. Le paramètre de
priorité peut aussi avoir un effet local dans le cas d’une association bidirectionnelle simultanée.
3 La priorité d’une réponse (RO-RESULT, RO-ERROR et RO-REJECT-U) devra normalement être plus forte (valeur
plus faible) que la priorité de l’invocation correspondante.
Quand il est présent, le paramètre de priorité doit appartenir à l’intervalle de valeurs autorisées par le champ
&InvokePriority de la définition de l’opération.
82 . Service RO-RESULT
Le service RO-RESULT sert à un utilisateur ROSE pour répondre à une indication RO-INVOKE antérieure lorsque
l’opération a été exécutée avec succès. Il s’agit d’un service non confirmé.
La structure de service correspondante se compose de deux primitives de service. comme le montre la Figure 4.
*
Utilisateur
Utilisateur Fournisseur
ROSE ROSE ROSE
Demande
Indication
RO-RESULT ’
RO-RESULT ’
TlSO42 l O-94/dO4
Figure 4 - Primitives du service RO-RESULT
Le Tableau 3 énumere les paramètres du service RO-RESULT.
Tableau 3 - Paramètres du service RO-RESULT
Demande Indication
Nom du paramètre
Operation-id (Identificateur d’opération) U
c(=>
Result (Résultat) U
c(=>
M
Invoke-id (Identificateur d’invocation)
W=)
Priority (Priorité) U
8.2.1 Operation-id
Ce paramètre identifie l’opération dont le système annonce le résultat après l’avoir exécutée dans le cadre d’un contrat
d’opération. Il véhicule la valeur &operationCode (code d’opération) tirée de la définition de l’opération. Il ne sera
présent que si le paramètre Result est lui-même présent.
10 Rec. UIT-T X.881 (1994 F)
ISOKEI 13712-2 : 1995 (F)
8.2.2 Result
Ce paramètre est le résultat de l’opération. Il ne peut être présent que si et seulement si le champ &ResultType (type de
résultat) est présent dans la définition de l’opération, auquel cas il est du type indiqué par ce champ.
8.2.3 Invoke-id
Ce paramètre identifie l’invocation correspondante (voir 8.1.4). Il doit être fourni par le demandeur du service. Sa valeur
est celle de l’identificateur de la primitive d’indication RO-INVOKE correspondante.
8.2.4 Priority
Ce paramètre définit la priorité attribuée au transfert de I’APDU correspondante (voir 8.1.6).
NOTE - Le paramètre de priorité n’est utilisé qu’en association avec l’élément de service de transfert fiable (RTSE) en tant
que service de transfert. 11 ne sera utilisé dans aucune autre réalisation.
S’il est présent, le paramètre de priorité appartiendra à l’intervalle des valeurs autorisées par le champ &ResultPriority
de la définition de l’opération.
83 a Service RO-ERROR
Le service RO-ERROR sert à un utilisateur ROSE pour répondre à une indication RO-INVOKE antérieure lorsque
l’opération a échoué. Il s’agit d’un service non confirmé. La structure de service correspondante se compose de deux
primitives de service, comme le montre la Figure 5.
Utilisateur
Utilisateur Fournisseur
ROSE ROSE ROSE
~~~------œœ~~
Figure 5 - Primitives du service RO-ERROR
Le Tableau 4 énumère les paramètres du service RO-ERROR.
Tableau 4 - Paramètres du service RO-ERROR
Demande Indication
Nom du paramètre
Error-id (Identificateur d’erreur) M
M(=)
Parameter (Paramètre) U
C(=l
M
Invoke-id (Identificateur d’invocation)
M(=)
Priority (Priorité) U
8.3.1 Errer-id
Ce paramètre identifie l’erreur dont le système rend compte par suite de son incapacité à exécuter l’opération invoquée. Il
véhicule la valeur &errorCode (code d’erreur) tirée de la définition de l’erreur.
8.3.2 Parameter
C’est le paramètre de l’erreur. Il ne peut être présent que si et seulement si le champ &ParameterType (type de
paramètre) est présent dans la définition de l’erreur, auquel cas, il est du type indiqué par ce champ.
Rec. UIT-T X.881 (1994 F) 11
ISO/CEI 13712-2 : 1995 (F)
Invoke-id
8.3.3
Ce paramètre identifie l’invocation correspondante (voir 8.1.4). Il doit être fourni par le demandeur du service. Sa valeur
est celle de l’identificateur de la primitive d’indication RO-INVOKE correspondante.
8.3.4 Priority
Ce paramètre définit la priorité attribuée au transfert de I’APDU correspondante (voir 8.1.6).
NOTE - Le paramètre de priorité n’est utilisé qu’en association avec l’élément de service de transfert fiable (RTSE) en tant
que service de transfert. Il ne sera utilisé dans aucune autre réalisation.
S’il est présent, le paramètre de priorité appartiendra à l’intervalle des valeurs autorisées par le champ &ErrorPriority
de la définition de l’opération.
Service RO-RE JECT-U
84 .
Le service RO-REJECT-U sert à un utilisateur ROSE pour rejeter une demande (indication RO-INVOKE) émanant d’un
autre utilisateur ROSE au cas où il a détecté une difficulté. Le service RO-REJECT-U peut également être utilisé par un
utilisateur ROSE pour rejeter une réponse (indication RO-RESULT ou indication RO-ERROR) provenant de l’autre
utilisateur. Cependant, pour éviter de transgresser les règles d’ordonnancement des autres éléments ASE dans certains
contextes d’application, un utilisateur ROSE peut ne pas utiliser le service RO-REJECT-U pour rejeter les réponses. Il
s’agit d’un service non confirmé.
La structure de service correspondante se compose de deux primitives de service, comme le montre la Figure 6.
Utilisateur Fournisseur Utilisateur
ROSE ROSE
ROSE
Demande
0-11
--œ-
0-œ
RO-REJECT-U ’
RO-RE
...
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...