ISO/IEC 13235-1:1998

Information technology — Open Distributed Processing — Trading function: Specification — Part 1:

The scope of this Recommendation | International Standard is: ? an enterprise specification for the trading function; ? an information specification for the trading function; ? a computational specification for traders (i.e. objects providing the trading function); ? conformance requirements in terms of conformance points. It is not a goal of this Recommendation | International Standard to state how the trading function should be realized. Therefore this Recommendation | International Standard does not include an engineering specification. The field of application for this Recommendation | Intenational Standard is any ODP system in which it is required to introduce and discover services incrementally, dynamically and openly.

Technologies de l'information — Traitement réparti ouvert — Fonction de courtage: Spécification — Partie 1:

Le domaine d'application de la présente Recommandation | Norme internationale est le suivant: ? constituer une spécification d'entreprise pour la fonction de courtage; ? constituer une spécification d'information pour la fonction de courtage; ? constituer une spécification de traitement pour les courtiers (c'est-à-dire les objets assurant la fonction de courtage); ? formuler des prescriptions de conformité en termes de points de conformité. La présente Recommandation | Norme internationale ne vise pas à indiquer la façon dont la fonction de courtage doit être réalisée. Elle n'inclut donc pas de spécification d'ingénierie. Le champ d'application de la présente Recommandation | Norme internationale est tout système dans lequel il faut introduire et découvrir progressivement, dynamiquement et ouvertement des services.

General Information

• Status: Published
• Publication Date: 16-Dec-1998
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 38 - Cloud computing and distributed platforms
• Drafting Committee: ISO/IEC JTC 1/SC 38 - Cloud computing and distributed platforms
• Current Stage: 9093 - International Standard confirmed
• Completion Date: 21-Dec-2022

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 13235-1
First edition
1998-12-15
Information technology — Open Distributed
Processing — Trading function:
Specification
Technologies de l'information — Traitement distribué ouvert — Fonction
commerciale: Spécifications
Reference number
B C
ISO/IEC 13235-1:1998(E)

---------------------- Page: 1 ----------------------
ISO/IEC 13235-1:1998(E)
Contents
Page
1 Scope and field of application . 1
2 Normative References. 1
3 Notations. 1
4 Definitions . 2
4.1 Definitions from ITU-T Rec. X.902 | ISO/IEC 10746-2 . 2
4.2 Definitions from ITU-T X.903 | ISO/IEC 10746-3 . 3
5 Overview of the ODP Trading Function. 3
5.1 Diversity and scalability . 4
5.2 Linking traders. 4
5.3 Policy. 4
6 Enterprise specification of the Trading Function. 5
6.1 Communities. 5
6.2 Roles. 5
6.3 Activities . 6
6.4 Policies . 6
6.5 Structuring rules . 6
7 Information specification of the Trading Function . 7
7.1 Overview . 7
7.2 Basic concepts . 8
7.3 Invariant schema. 12
7.4 Static schema. 13
7.5 Dynamic schemata. 13
8 Computational specification of the Trading Function. 21
8.1 Viewpoint correspondences. 22
8.2 Concepts and data types . 22
8.3 Exceptions . 35
8.4 Abstract interfaces. 37
8.5 Functional interfaces. 39
8.6 Dynamic Property Evaluation interface. 55
8.7 Trader object template. 56
9 Conformance statements and reference points. 58
9.1 Conformance requirement for trading function interfaces as server . 59
9.2 Conformance requirements for query trader conformance class. 60
9.3 Conformance requirements for simple trader conformance class . 60
©  ISO/IEC 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
utilized in any form or by any means, electronic or mechanical, including photocopying and micro-
film, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii

---------------------- Page: 2 ----------------------
©
ISO/IEC ISO/IEC 13235-1:1998(E)
9.4 Conformance requirements for stand-alone trader conformance class. 60
9.5 Conformance requirements for linked trader conformance class . 61
9.6 Conformance requirements for proxy trader conformance class. 61
9.7 Conformance requirements for full-service trader conformance class . 61
9.8 Conformance tests. 61
Annex A – ODP-IDL based specification of the Trading Function. 62
A.1 Introduction. 62
A.2 ODP Trading Function module. 62
A.3 Dynamic Property module . 69
Annex B – ODP Trading Function Constraint Language BNF . 71
B.1 Introduction. 71
B.2 Language basics . 71
B.3 The constraint language BNF. 72
Annex C – ODP Trading Function constraint recipe language. 75
C.1 Introduction. 75
C.2 The recipe syntax . 75
C.3 Example . 75
Annex D – Service type repository. 76
D.1 Introduction. 76
D.2 Service type repository. 76
iii

---------------------- Page: 3 ----------------------
©
ISO/IEC 13235-1:1998(E) ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the
specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the
development of International Standards through technical committees established by the respective organization to deal with
particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft
International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 13235-1 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 33, Distributed application services, in collaboration with ITU-T. The identical text is published as ITU-T
Recommendation X.950.
ISO/IEC 13235 consists of the following parts, under the general title Information technology — Open Distributed
Processing — Trading function:
— Part 1: Specification
— Part 2: (TBD)
— Part 3: Provision of trading function using OSI Directory service
Annexes A to D form an integral part of this part of ISO/IEC 13235.
iv

---------------------- Page: 4 ----------------------
©
ISO/IEC ISO/IEC 13235-1:1998(E)
Introduction
The rapid growth of distributed processing has lead to a need for a coordinating framework for the standardization of Open
Distributed Processing (ODP). The Reference Model of Open Distributed Processing (RM-ODP) provides such a framework. It
defines an architecture within which support of distribution, interoperability and portability can be integrated.
One of the components of the architecture (described in RM-ODP Part 3: Architecture) (ITU-T Rec. X.903 | ISO/IEC 10746-3)
is the ODP Trading function. The trading function provides the means to offer a service and the means to discover services that
have been offered. This Recommendation | International Standard provides an architecture for systems implementing the
trading function and the specification of interfaces within the architecture.
NOTE – The specification of computational interfaces in this Recommendation | International Standard is technically aligned with the
OMG Trading Object Service.
The goals of this Recommendation | International Standard are:
– to provide a standard which is independent of any implementation;
– to ensure implementations are capable of being made to interoperate (i.e. can be federated);
– to provide sufficient detail to allow conformance claims to be assessed.
Annex A is a normative ODP-IDL specification of the trading function interface signatures.
Annex B is a normative specification of the ODP trading function constraint language.
Annex C is a normative specification of the ODP trading function constraint recipe language.
Annex D is an informative description of a Service Type Repository.
v

---------------------- Page: 5 ----------------------
ISO/IEC 13235-1:1998(E)
INTERNATIONAL STANDARD
ISO/IEC 13235-1 : 1997 (E)
ITU-T Rec. X.950 (1997 E)
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY – OPEN DISTRIBUTED PROCESSING –
TRADING FUNCTION: SPECIFICATION
1 Scope and field of application
The scope of this Recommendation | International Standard is:
– an enterprise specification for the trading function;
– an information specification for the trading function;
– a computational specification for traders (i.e. objects providing the trading function);
– conformance requirements in terms of conformance points.
It is not a goal of this Recommendation | International Standard to state how the trading function should be realized. Therefore
this Recommendation | International Standard does not include an engineering specification.
The field of application for this Recommendation | Intenational Standard is any ODP system in which it is required to introduce
and discover services incrementally, dynamically and openly.
2 Normative References
The following Recommendations and International Standards contain provisions which, trough reference in this text, constitute
provisions of this Recommendation | International Standard. 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 Recommendation |
International Standard are encouraged to investigate the possibility of applying the most recent edition of the Recommendations
and Standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards. The
Telecommunication Standardization Bureau of the ITU maintains a list of currently valid ITU-T Recommendations.
– ITU-T Recommendation X.901 (1997) | ISO/IEC 10746-1:1998, Information technology – Open distributed
processing – Reference Model: Overview.
– ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1996, Information technology – Open Distributed
Processing – Reference Model: Foundations.
– ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1996, Information technology – Open Distributed
Processing – Reference Model: Architecture.
– ITU-T Recommendation X.920 (1997) | ISO/IEC 14750:1998, Information technology – Open Distributed
Processing – Interface Definition Language.
1)
– ISO/IEC 13568 , Information technology – The Z Specification Language.
3 Notations
The information specification of the trading function is described using the Z formal description language. The signature of the
computational interface for the trading function is described using ODP Interface Definition Language, in clause 8 and in
Annex A.
ITU-T Rec. X.950 (1997 E) 1

---------------------- Page: 6 ----------------------
ISO/IEC 13235-1:1998(E)
4 Definitions
4.1 Definitions from ITU-T Rec. X.902 | ISO/IEC 10746-2
This Specification is based on the framework of abstractions and concepts developed in RM-ODP and makes use of the
following definitions from RM-ODP Part 2: Foundations (see ITU-T Rec. X.902 | ISO/IEC 10746-2).
a) action;
b) activity;
c) behaviour;
d) behavioural compatibility;
e) binding;
f) client object;
g) conformance point;
h) contract;
i) domain;
j) establishing behaviour;
k) failure;
l) identifier;
m) initiating object;
n) instance;
o) interaction;
p) interface;
q) interface signature;
r) name;
s) object;
t) obligation;
u) ODP system;
v) permission;
w) policy;
x) prohibition;
y) quality of service;
z) reference point;
aa) responding object;
bb) role;
cc) server object;
dd) subtype;
ee) supertype;
ff) template;
gg) template type;
hh) trading;
ii) transparency;
jj) type;
kk) viewpoint.
2 ITU-T Rec. X.950 (1997 E)

---------------------- Page: 7 ----------------------
ISO/IEC 13235-1:1998(E)
4.2 Definitions from ITU-T X.903 | ISO/IEC 10746-3
This Specification is based on the framework of abstractions and concepts developed in RM-ODP and makes use of the
following definitions from RM-ODP Part 3: Architecture (see ITU-T Rec. X.903 | ISO/IEC 10746-3).
a) community;
b) computational interface template;
c) computational viewpoint;
d) dynamic schema;
e) engineering viewpoint;
f) enterprise viewpoint;
g) exporter;
h) information viewpoint;
i) invariant schema;
j) schema;
k) service export;
l) service import;
m) service offer;
n) static schema;
o) technology viewpoint;
p) federation.
5 Overview of the ODP Trading Function
In the context of the ODP goal of providing distribution transparent utilization of services over heterogeneous platforms and
networks, the role of the Trading Function is to allow users to find potential services. It is a corollary of distribution that the
finding of services will occur dynamically.
The ODP trading function facilitates the offering and the discovery of instances of interfaces which provide services of
particular types. A trader is an object that supports the Trading Function in a distributed environment. It can be viewed as an
object through which other objects can advertise their capabilities and match their needs against advertised capabilities.
Advertising a capability or offering a service is called "export". Matching against needs or discovering services is called
"import". Export and import facilitate dynamic discovery of and late binding to services.
To export, an object gives the trader a description of a service together with the location of an interface at which that service is
available. To import, an object asks the trader for a service having certain characteristics. The trader checks against the
descriptions of services and responds to the importer with the location(s) of matched service interface(s). The importer is then
able to interact with a matched service. These interactions are shown in Figure 1.
T
2
1
EI
3
T0727950-97/d01
Sequence of interactions:
1. Export
2. Import
3. Service Interaction
Figure 1 – Interaction between the trader and its clients
FIGURE 1/X.950.[D01] =
ITU-T Rec. X.950 (1997 E) 3

---------------------- Page: 8 ----------------------
ISO/IEC 13235-1:1998(E)
The service interaction could be decoupled from the trading interactions (export and import) by modelling a service provider
object and a service user object explicitly. This would imply interactions between service provider and exporter and between
importer and service user that are trading actions, as defined in ITU-T Rec. X.902 | ISO/IEC 10746-2. However, these implied
interactions need not conform to this Specification.
Due to the sheer number of service offers that will be offered worldwide, and the differing requirements that users of the
trading service will have, it is inevitable that the trading service will be split up and that the service offers will be partitioned.
Each partition will, in the first instance, meet the trading needs of a community of clients (exporters and importers). Where a
client needs a scope for its trading activities that is wider than that provided by one partition, it will access other partitions
either directly or indirectly. Directly means that the client interacts with the traders handling those partitions. Indirectly, means
that the client interacts with one trader only and this trader interacts with other traders responsible for other partitions. The
latter possibility is referred to as federation of traders. In some cases, interceptors may be required between federated traders.
A user of a trader that interoperates with other traders, may associate with only one trader, and can transparently access the
service offers of other traders with which that trader can interoperate .
Thus, the trading function in an ODP environment allows:
– objects to export (advertise) services;
– objects to import information about one or more exported services, according to some criteria;
– federation of traders.
5.1 Diversity and scalability
The concept of trading to discover new services is one that is applicable in a wide range of scenarios. A trader may contain a
large number of offers of service and its implementation may be inclined to be based upon a database. Or, a trader may contain
a few offers only and so be implementable as a memory resident trader. These two cases exhibit different qualities: availability
and integrity in the first case and performance in the second. The variation in these scenarios illustrates the need for scalability,
both upwards for very big systems and downwards for small, fast systems.
To discover any arbitrary offer of service, a trader needs all offers to be, in some sense, visible to it. One partition cannot hold
every offer, many will necessarily be held at other partitions, therefore, in addition to a number of offers, a trader must possess
information about other partitions. However, there is no need for a trader to know about all other partitions. Some of this
knowledge can be obtained indirectly via other traders.
The partitioning of the offer space and the limited knowledge held with one partition about other partitions is the basis for
meeting requirements for both distribution and contextualisation of the trading function.
5.2 Linking traders
The requirements to contextualise the offer space and to distribute the trading function are both met by linking traders together.
By linking to other traders, each trader makes the offer space of those traders implicitly available to its own clients.
Each trader has a horizon limited to those other traders to which it is explicitly linked. As those traders are in turn linked to yet
more traders, a large number of traders are reachable from a given starting trader. The traders are linked to form a directed
graph with the information describing the graph distributed among the traders. This graph is called the trading graph.
Links may cross domain boundaries: administrative, technological or whatever. Trading may thus be a federated system, i.e.
one that spans many domains.
5.3 Policy
To meet the diverse requirements likely to be placed upon the trading function, some degrees of freedom are necessary when
specifying the behaviour of a trader object. To accomplish this, and yet still meet the goals of this Specification, the concept of
policy is used to provide a framework for describing the behaviour of any ODP conformant trading system.
This Specification identifies a number of policies and gives them semantics. Each policy partly determines the behaviour of a
trader. When claiming conformance, an implementation may need to state which combination of policies will ensure
conformant behaviour.
Policies may be communicated during interaction, in which case they relate to an expectation on subsequent behaviour.
4 ITU-T Rec. X.950 (1997 E)

---------------------- Page: 9 ----------------------
ISO/IEC 13235-1:1998(E)
6 Enterprise specification of the Trading Function
The scope of an enterprise specification is defined in RM-ODP Part 3: Architecture (see ITU-T Rec. X.903 | ISO/IEC 10746-
3). This enterprise specification identifies the objectives and the policy statements that govern the activities of a trading
function.
The objective of the trading function is to provide the means to offer and to discover instances of a particular type of service,
with particular characteristics.
A trading community is comprised by members that have different roles, for example, trader, exporter and importer. An object
can have several roles within the same community. For example, an object can both be an importer and an exporter.
The trading activities of the community are service exports and service imports. These activities are governed by a set of
policies of the trading community. A service import activity may propagate from one trading community to another. In such a
case the domains associated with these two traders are federated. These trader domain boundaries may coincide with other
domain boundaries (e.g. type domain or security policy domain).
A policy is a set of rules with a particular objective. Each rule constrains some aspects of a trader’s behaviour consistent with
the common objective. Members of the trading community are obliged to obey the rules of the policies. These rules provide the
guidelines for decisions to satisfy the community’s objectives. The rules are not prescribed in this Specification. The enterprise
specification identifies the set of policies that limit the trader in certain type of behaviour. The policies identified provide a
framework within which the trader object's behaviour may be implemented or configured.
6.1 Communities
6.1.1 trading community: A community of objects established for the purpose of trading and governed by a trading
policy. The objects perform roles listed in 6.2.
A single trading community (at one level of abstraction) may be refined into a number of interworking trading communities at a
second, more detailed level of abstraction. Subject to community policy, the interworking of trading communities at the
detailed level is able to maintain the impression of the single abstract community, allowing objects with trader, importer or
exporter roles in one subcommunity to interact with objects in any other subcommunity.
6.2 Roles
Objects may play the following roles within a trading community.
6.2.1 trader: A role which registers service offers from exporter objects and returns service offers upon request to importer
objects according to some criteria.
6.2.2 exporter: A role which registers service offers with the trader object.
6.2.3 importer: A role which obtains service offers, satisfying some criteria, from the trader object.
6.2.4 trader administrator: A role which defines, manages, and enforces the trader policy of the trader object. The trader
administrator is the controlling object of a trader domain (the trader and its set of service offers).
6.2.5 service offer: A role which maintains a description of a service.
NOTE – The description may be the basis of a future contract.
ITU-T Rec. X.950 (1997 E) 5

---------------------- Page: 10 ----------------------
ISO/IEC 13235-1:1998(E)
6.3 Activities
The following activities are relevant to a trading community.
6.3.1 service export: A chain of actions by an exporter object and the trader object which establish and terminate a liaison
in which the trader object is permitted to provide the exporter object's service offer to a group of importer objects.
6.3.2 service import: A chain of actions between an importer object and the trader object in which the importer object
obtains a number of service offers which meet some criteria.
6.4 Policies
The behaviours of enterprise objects within a trading community are governed by the policies of the trading community. Some
policies govern trading activities, and some policies place constraints on other aspects of behaviour of a trader and other roles
in the trading community, consistent with the common objective of the community. Where an activity involves interactions
between objects, the resulting policy will be a compromise between the policies of the interacting objects. The compromise will
be reached via a form of arbitration.
NOTE – For example, a trader object may be governed by policies such that it is obliged to propagate a search to a depth of 2 links, but it
is also permitted to terminate a search after propagating a search to a depth of 1 link. If the trader object is permitted (or obliged) to meet
an importer’s requirement regarding depth of links to be traversed for a search, then there is a need for some rules to arbitrate between
conflicting policies.
6.4.1 Export activity policy: A set of rules related to the service export activity (i.e. the offering of services so that they
might subsequently be discovered by other objects).
The policy may include, amongst other things:
– an obligation for a service offer to be described in a specific way;
– a prohibition of specified service import activities from discovering the service offer;
– an obligation for a service offer providing rules to be evaluated as part of a service import activity.
Each exporter may have its own export policy. This would describe the exporter’s expectation of a service export. Therefore,
the service export activity is governed by both the trader’s export policy and the exporter’s export policy.
6.4.2 Import activity policy: A set of rules related to the service import activity (i.e. the attempt to discover offered
services that meet a specified requirement.
The policy may include, amongst other things:
– an obligation to limit the use of resources, including duration of activity;
– permissions to propagate the service import to one or more interworking trading communities.
6.4.3 Arbitration policy: A set of rules to arbitrate on conflicting rules arising during trading activities.
The policy may include, amongst other things, an obligation to arbitrate in favour of the trader object’s rules on:
– use of resources during service import;
– propagating service import activities.
6.4.4 Service offer acceptance policy: A set of rules restricting the set of service offers that will be accepted by the trader.
6.4.5 Type management policy: A set of rules related to the specification of types and the relationship between types.
NOTE 1 – The policy may be to defer to a type repository function with respect to either or both of these aspects.
NOTE 2 – Examples would be to use name equivalence or to use signature subtyping in type matching.
6.4.6 Search policy: A set of rules guiding the search for suitable service offers through the trading system.
6.5 Structuring rules
6.5.1 Community rules
In a trading community there must be an object which assumes a trader role (a trader object). Becoming a member of a trading
community enables an object to interact with the trader obje
...

NORME ISO/CEI
INTERNATIONALE 13235-1
Première édition
1998-12-15
Technologies de l'information —
Traitement réparti ouvert — Fonction de
courtage: Spécification
Information technology — Open Distributed Processing — Trading
function: Specification
Numéro de référence
ISO/CEI 13235-1:1998(F)
©
ISO/CEI 1998

---------------------- Page: 1 ----------------------
ISO/CEI 13235-1:1998(F)
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier peut
être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence autorisant
l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées acceptent de fait la
responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute responsabilité en la
matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info du
fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir l'exploitation de
ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation, veuillez en informer le
Secrétariat central à l'adresse donnée ci-dessous.
© ISO/CEI 1998
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication 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’ISO à
l’adresse ci-après ou du comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 734 10 79
E-mail [e-mail]
Web www.iso.ch
Version française parue en 2000
ImpriméenSuisse
ii © ISO/CEI 1998 – Tous droits réservés

---------------------- Page: 2 ----------------------
ISO/CEI 13235-1:1998(F)
Sommaire
0AGE
1 Domaine et champ d’application. 1
2 Références normatives . 1
3 Notations . 1
4 Définitions. 2
4.1 Définitions extraites de la Rec. UIT-T X.902 | ISO/CEI 10746-2 . 2
4.2 Définitions extraites de la Rec. UIT-T X.903 | ISO/CEI 10746-3 . 3
5 Aperçu général de la fonction de courtage ODP. 3
5.1 Diversité et échelonnabilité. 4
5.2 Mise en liaison de courtiers . 4
5.3 Politique . 4
6 Spécification d'entreprise de la fonction de courtage. 5
6.1 Communautés . 5
6.2 Rôles . 5
6.3 Activités . 6
6.4 Politiques . 6
6.5 Règles de structuration. 7
7 Spécification informationnelle de la fonction de courtage. 7
7.1 Aperçu général. 7
7.2 Concepts de base. 8
7.3 Schéma d'invariant. 12
7.4 Schéma statique . 13
7.5 Schémas dynamiques . 13
8 Spécification de traitement de la fonction de courtage . 21
8.1 Concordances entre points de vue. 22
8.2 Types de concepts et de données . 22
8.3 Exceptions. 35
8.4 Interfaces abstraites. 37
8.5 Interfaces fonctionnelles . 39
8.6 Interface d'évaluation de propriété dynamique . 56
8.7 Gabarit d'objet-courtier . 57
© ISO/CEI 1998 – Tous droits réservés iii

---------------------- Page: 3 ----------------------
ISO/CEI 13235-1:1998(F)
9 Déclarations de conformité et points de référence . 60
9.1 Prescription de conformité des interfaces ayant la fonction de courtage en tant que serveurs . 60
9.2 Prescriptions de conformité pour la classe de conformité de courtier d'interrogation . 62
9.3 Prescriptions de conformité pour la classe de conformité de courtier simple. 62
9.4 Prescriptions de conformité pour la classe de conformité de courtier autonome. 62
9.5 Prescriptions de conformité pour la classe de conformité de courtier lié . 62
9.6 Prescriptions de conformité pour la classe de conformité de courtier de procuration . 63
9.7 Prescriptions de conformité pour la classe de conformité de courtier tous services. 63
9.8 Tests de conformité. 63
Annex A – ODP-IDL based specification of the Trading FunctionAnnex A – ODP-IDL based specification of the Trading Function . 6464
A.1A.1 IntroductionIntroduction. 6464
A.2A.2 ODP Trading Function moduleODP Trading Function module. 6464
A.3A.3 Dynamic Property moduleDynamic Property module . 7171
Annex B – ODP Trading Function Constraint Language BNFAnnex B – ODP Trading Function Constraint Language BNF . 7373
B.1B.1 IntroductionIntroduction. 7373
B.2B.2 Language basicsLanguage basics. 7373
B.3B.3 The constraint language BNFThe constraint language BNF . 7474
Annex C – ODP Trading Function constraint recipe language . 77
C.1 Introduction. 77
C.2 The recipe syntax . 77
C.3 Example . 77
Annex D – Service type repository . 78
D.1 Introduction. 78
D.2 Service type repository . 78
iv © ISO/CEI 1998 – Tous droits réservés

---------------------- Page: 4 ----------------------
ISO/CEI 13235-1:1998(F)
Avant-propos
L'ISO (Organisation internationale de normalisation) et la CEI (Commission électrotechnique internationale)
forment le système spécialisé de la normalisation mondiale. Les organismes nationaux membres de l'ISO ou de la
CEI 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 domaines particuliers de l'activité technique. Les comités
techniques de l'ISO et de la CEI collaborent dans des domaines d'intérêt commun. D'autres organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO et la CEI participent également
aux travaux.
Dans le domaine des technologies de l'information, l'ISO et la CEI ont créé un comité technique mixte,
l'ISO/CEI JTC 1. Les projets de Normes internationales adoptés par le comité technique mixte sont soumis aux
organismes nationaux pour vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au
moins des organismes nationaux votants.
La Norme internationale ISO/CEI 13235-1 a été élaborée par le comité technique mixte ISO/CEI JTC 1,
Technologies de l'information, sous-comité SC 33, Services d'applications distribuées, en collaboration avec
l'UIT-T. Le texte identique est publié en tant que Recommandation UIT-T X.950.
L'ISO/CEI 13235 comprend les parties suivantes, présentées sous le titre général Technologies de l'information —
Traitement réparti ouvert — Fonction de courtage:
� Partie 1: Spécification
� Partie 2: (TBD)
� Partie 3: Fourniture de la fonction de courtage au moyen du service d'annuaire OSI
Les annexes A à D constituent des éléments normatifs de la présente partie de l'ISO/CEI 13235.
© ISO/CEI 1998 – Tous droits réservés v

---------------------- Page: 5 ----------------------
ISO/CEI 13235-1:1998(F)
Introduction
La rapide croissance des applications réparties a fait naître le besoin d'un cadre pour coordonner la normalisation du
traitement réparti ouvert (ODP). Le modèle de référence ODP fournit ce cadre. Il établit une architecture qui permet la
prise en compte de la répartition, de l'interopérabilité et de la portabilité.
L'une des composantes de l'architecture décrite dans la Rec. UIT-T X.903 | ISO/CEI 10746-3: Traitement réparti ouvert
e
– Modèle de référence: architecture (3 partie du modèle RM-ODP) est la fonction de courtage ODP, qui permet d'offrir
un service et de découvrir les services qui ont été offerts. La présente Recommandation | Norme internationale décrit une
architecture applicable aux systèmes qui mettent en œuvre la fonction de courtage. Elle spécifie également les interfaces
contenues dans cette architecture.
NOTE – Dans la présente Recommandation | Norme internationale, la spécification des interfaces de traitement est techniquement
alignée sur le service de courtage du groupe de gestion des objets (OMG).
Les objectifs de la présente Recommandation | Norme internationale sont les suivants:
– offrir une norme qui soit indépendante de toute réalisation;
– garantir que l'on pourra faire interfonctionner (c'est-à-dire fédérer) les mises en œuvre;
– donner suffisamment de détails pour permettre d'évaluer les revendications de conformité.
L'Annexe A (normative) est une spécification en langage IDL (langage de définition d'interface) du traitement ODP pour
les signatures d'interface de la fonction de courtage.
L'Annexe B (normative) est une spécification du langage de contrainte pour la fonction de courtage ODP.
L'Annexe C (normative) est une spécification du langage de recette de contrainte pour la fonction de courtage ODP.
L'Annexe D (informative) est une description du conteneur de types de service.
vi © ISO/CEI 1998 – Tous droits réservés

---------------------- Page: 6 ----------------------
)3/�#%)�����������������&�
./2-%��).4%2.!4)/.!,%
ISO/CEI 13235-1 : 1998 (F)
Rec. UIT-T X.950 (1997 F)
2%#/--!.$!4)/.��5)4�4
4%#(./,/’)%3��$%��,�).&/2-!4)/.�� ��42!)4%-%.4��2�0!24)��/56%24��
&/.#4)/.��$%��#/524!’%���30�#)&)#!4)/.
� $OMAINE�ET�CHAMP�D�APPLICATION
Le domaine d'application de la présente Recommandation | Norme internationale est le suivant:
– constituer une spécification d'entreprise pour la fonction de courtage;
– constituer une spécification d'information pour la fonction de courtage;
– constituer une spécification de traitement pour les courtiers (c'est-à-dire les objets assurant la fonction de
courtage);
– formuler des prescriptions de conformité en termes de points de conformité.
La présente Recommandation | Norme internationale ne vise pas à indiquer la façon dont la fonction de courtage doit
être réalisée. Elle n'inclut donc pas de spécification d'ingénierie.
Le champ d'application de la présente Recommandation | Norme internationale est tout système dans lequel il faut
introduire et découvrir progressivement, dynamiquement et ouvertement des services.
� 2'F'RENCES�NORMATIVES
Les Recommandations et 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 Recommandation | Norme internationale. 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 Recommandation | Norme internationale 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 CEI et de l'ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de l'UIT tient à jour une liste des Recommandations de l'UIT-T en vigueur.
– Recommandation UIT-T X.901 (1997) | ISO/CEI 10746-1:1998, 4ECHNOLOGIES� DE� L�INFORMATION�
4RAITEMENT�R'PARTI�OUVERT� �-OD¤LE�DE�R'F'RENCE��APER§U�G'N'RAL.
– Recommandation UIT-T X.902 (1995) | ISO/CEI 10746-2:1996, 4ECHNOLOGIES� DE� L�INFORMATION�
4RAITEMENT�R'PARTI�OUVERT� �-OD¤LE�DE�R'F'RENCE��FONDEMENTS�
– Recommandation UIT-T X.903 (1995) | ISO/CEI 10746-3:1996, 4ECHNOLOGIES� DE� L�INFORMATION�
4RAITEMENT�R'PARTI�OUVERT� �-OD¤LE�DE�R'F'RENCE��ARCHITECTURE�
– Recommandation UIT-T X.920 (1997) | ISO/CEI 14750:1998, 4ECHNOLOGIES� DE� L�INFORMATION�
4RAITEMENT�R'PARTI�OUVERT� �,ANGAGE�DE�D'FINITION�D�INTERFACE�
1)
– ISO/CEI 13568 : 4ECHNOLOGIES�DE�L�INFORMATION� �,E�LANGAGE�DE�SP'CIFICATION�:.
� .OTATIONS
La spécification d'information de la fonction de courtage est décrite au moyen du langage SDL-Z. La signature de
l'interface de traitement pour la fonction de courtage est décrite à l'article 8 et dans l'Annexe A au moyen du langage de
définition d'interface (IDL, INTERFACE�DEFINITION�LANGUAGE) du traitement ODP.
_______________
1)
A publier.
2EC��5)4�4�8�����������&� 1

---------------------- Page: 7 ----------------------
)3/�#%)�����������������&�
� $'FINITIONS
��� $'FINITIONS�EXTRAITES�DE�LA�2EC��5)4�4�8�����\�)3/�#%)��������
La présente Spécification est fondée sur le cadre d'abstractions et de concepts mis au point dans le modèle RM-ODP.
Elle fait usage des termes suivants, qui sont définis dans la Rec. UIT-T X.902 | ISO/CEI 10746-2 (Partie 2 du modèle
RM-ODP: fondements):
a) action
b) activité
c) comportement
d) compatibilité de comportement
e) rattachement
f) objet client
g) point de conformité
h) contrat
i) domaine
j) comportement d'établissement
k) défaillance
l) identificateur
m) objet initiateur
n) instance
o) interaction
p) interface
q) signature d'interface
r) nom
s) objet
t) obligation
u) système ODP
v) permission
w) politique
x) interdiction
y) qualité de service
z) point de référence
aa) objet répondeur
bb) rôle
cc) objet serveur
dd) sous-type
ee) supertype
ff) gabarit
gg) type-gabarit
hh) courtage
ii) transparence
jj) type
kk) point de vue
2 2EC��5)4�4�8�����������&�

---------------------- Page: 8 ----------------------
)3/�#%)�����������������&�
��� $'FINITIONS�EXTRAITES�DE�LA�2EC��5)4�4�8�����\�)3/�#%)��������
La présente Spécification est fondée sur le cadre d'abstractions et de concepts mis au point dans le modèle RM-ODP.
Elle fait usage des termes suivants, qui sont définis dans la Rec. UIT-T X.903 | ISO/CEI 10746-3 (Partie 3 du modèle
RM-ODP: architecture):
a) communauté
b) gabarit d'interface de traitement
c) point de vue traitement
d) schéma dynamique
e) point de vue ingénierie
f) point de vue entreprise
g) exportateur
h) point de vue information
i) schéma d'invariant
j) schéma
k) exportation de service
l) importation de service
m) offre de service
n) schéma statique
o) point de vue technologie
p) fédération
� !PER§U�G'N'RAL�DE�LA�FONCTION�DE�COURTAGE�/$0
Dans le cadre des objectifs du traitement ODP, qui consiste à offrir une répartition transparente des services sur des
plates-formes ou réseaux hétérogènes, le rôle de la fonction de courtage est de permettre aux usagers de trouver des
possibilités de service. La découverte dynamique des services est un corollaire de leur répartition.
La fonction de courtage ODP facilite l'offre et la découverte d'instances d'interfaces qui fournissent des services de types
particuliers. Un courtier est un objet qui prend en charge la fonction de courtage dans un environnement réparti. On peut
le considérer comme un objet par l'intermédiaire duquel d'autres objets peuvent faire connaître leurs capacités et adapter
leurs besoins aux capacités signalées. La signalisation d'une capacité ou d'une offre de service est appelée «exportation».
L'adaptation aux besoins ou la découverte de services est appelée «importation». L'exportation et l'importation facilitent
la découverte dynamique de services et le rattachement retardé à des services.
Pour effectuer une exportation, un objet donne au courtier une description de service accompagnée de la localisation
d'une interface à laquelle ce service est disponible. Pour effectuer une importation, un objet demande au courtier un
service possédant certaines caractéristiques. Le courtier effectue une vérification sur la base des descriptions de service
dont il dispose et répond à l'importateur en lui indiquant la localisation d'interface(s) offrant un service concordant.
L'importateur peut ensuite entrer en interaction avec un tel service. Ces interactions sont représentées sur la Figure 1.
T
2
1
EI
3
T0727950-97/d01
Séquence des interactions:
1. Exportation
2. Importation
3. Interaction avec le service
&IGURE��� �)NTERACTION�ENTRE�LE�COURTIER�ET�SES�CLIENTS
FIGURE 1/X.950.[D01] =
2EC��5)4�4�8�����������&� 3

---------------------- Page: 9 ----------------------
)3/�#%)�����������������&�
On peut dissocier, d’une part, l’interaction avec le service et, d’autre part, les interactions avec la fonction de courtage
(exportations et importations) en modélisant explicitement un objet FOURNISSEUR�DE�SERVICES et un objet UTILISATEUR�DE
SERVICES. Ce modèle implique des interactions entre fournisseur et exportateur de services ainsi qu'entre importateur et
utilisateur de services, qui négocient des actions comme défini dans la Rec. UIT-T X.902 | ISO/CEI 10746-2. Ces inter-
actions implicites ne sont cependant pas soumises à la présente Spécification.
Etant donné le nombre réel des offres de service dans le monde et les différents besoins qui seront exprimés par les
utilisateurs du service de courtage, il est inévitable que ce service soit subdivisé et que les offres de service soient
partitionnées.
Chaque partition répondra, en première instance, aux besoins de courtage d'une communauté de clients (exportateurs et
importateurs). Lorsqu'un client a besoin, pour ses activités de courtage, d'un domaine de visibilité plus étendu que celui
qui correspond à une seule partition, ce client accédera, directement ou indirectement, à d'autres partitions. En accès
direct, le client entrera en interaction avec les courtiers traitant ces partitions. En accès indirect, le client n'entrera en
interaction qu'avec un seul courtier et celui-ci interagira avec d'autres courtiers, chargés d'autres partitions. Cette dernière
possibilité est appelée F'D'RATION�DE�COURTIERS. Dans certains cas, des intercepteurs peuvent être nécessaires entre des
courtiers fédérés.
L'utilisateur d'un courtier qui interfonctionne avec d'autres courtiers ne peut s'associer qu'à un seul courtier et peut avoir
accès transparent aux offres de service des autres courtiers avec lesquels ce courtier peut interfonctionner.
La fonction de courtage permet donc, dans un environnement de traitement ODP:
– aux objets d'exporter (signaler) des services;
– aux objets d'importer des informations sur un ou plusieurs services exportés, selon certains critères;
– aux courtiers de se fédérer.
��� $IVERSIT'�ET�'CHELONNABILIT'
Le concept de courtage permettant de découvrir de nouveaux services est applicable à une large gamme de scénarios. Un
courtier peut détenir un grand nombre d'offres de service et sa réalisation peut tendre à être fondée sur une base de
données. Un courtier peut également ne détenir qu'un petit nombre d'offres de service et être donc réalisable sous la
forme d'un courtier résident en mémoire. Ces deux cas possèdent des qualités différentes: la disponibilité et l'intégrité
dans le premier cas, la performance dans le second. Les variantes de ces scénarios montrent la nécessité d'une
échelonnabilité, aussi bien vers le haut pour les très grands systèmes que vers le bas pour les petits systèmes rapides.
Pour découvrir une certaine offre de service, un courtier a besoin que toutes les offres lui soient (en quelque sorte)
visibles. Une partition donnée ne peut pas contenir toutes les offres. Celles-ci seront nécessairement réparties entre
plusieurs partitions. Un courtier devra donc posséder, en plus d'un certain nombre d'offres, des renseignements sur
d'autres partitions. Il n'est cependant pas nécessaire qu'un courtier soit informé de toutes les autres partitions. Certaines
de ces connaissances peuvent être obtenues indirectement, par l'intermédiaire d'autres courtiers.
Le partitionnement de l'espace consacré aux offres de services et les connaissances limitées qui sont détenues dans une
partition donnée au sujet des autres partitions constituent la base des prescriptions à observer, tant pour la répartition que
pour la mise en contexte de la fonction de courtage.
��� -ISE�EN�LIAISON�DE�COURTIERS
Les prescriptions de mise en contexte de l'espace consacré aux offres de services et de répartition de la fonction de
courtage sont, dans les deux cas, satisfaites par une mise en liaison de courtiers. Le fait de mettre un courtier en liaison
avec des homologues permet implicitement à ce courtier de mettre à la disposition de ses propres clients l'espace réservé
à des offres de services par ces homologues.
Chaque courtier a un horizon limité aux homologues auxquels il est explicitement lié. Si ces homologues sont à leur tour
mis en liaison avec d'autres courtiers, un grand nombre de courtiers pourront être atteints à partir d'un courtier de départ
donné. Les courtiers sont liés de façon à former un graphe orienté, dont les informations descriptives sont réparties entre
courtiers. Ce graphe est appelé GRAPHE�DE�COURTAGE.
Les liaisons peuvent traverser des frontières de domaine administratif, de domaine technologique, etc. Le courtage peut
donc former un système fédéré, c'est-à-dire englobant de nombreux domaines.
��� 0OLITIQUE
Pour répondre aux diverses prescriptions susceptibles de régir la fonction de courtage, quelques degrés de liberté sont
nécessaires lors de la spécification du comportement d'un objet de courtage. A cette fin – tout en restant en conformité
4 2EC��5)4�4�8�����������&�

---------------------- Page: 10 ----------------------
)3/�#%)�����������������&�
avec les objectifs de la présente Spécification – le concept de POLITIQUE est utilisé en tant que cadre de description du
comportement de tout système de courtage ODP conforme.
La présente Spécification identifie un certain nombre de politiques et leur attribue des sémantèmes. Chaque politique
détermine partiellement le comportement d'un courtier. Pour faire valoir sa conformité, une réalisation peut avoir besoin
d'indiquer quelle est la combinaison de politiques qui garantira un comportement conforme.
Les politiques peuvent être communiquées en cours d'interaction, auquel cas elles se rapportent à une hypothèse quant au
comportement attendu.
� 3P'CIFICATION�D�ENTREPRISE�DE�LA�FONCTION�DE�COURTAGE
Le domaine d'application d'une spécification d'entreprise est défini dans la Rec. UIT-T X.903 | ISO/CEI 10746-3
(Partie 3 du modèle RM-ODP: architecture). Cette spécification d'entreprise identifie les objectifs et les déclarations de
politique qui régissent les activités d'une fonction de courtage.
L'objectif de la fonction de courtage est de donner la possibilité d'offrir et de découvrir des instances d'un type de service
particulier, ayant des caractéristiques particulières.
Une communauté de courtage se compose de membres ayant différents rôles, par exemple courtier, exportateur,
importateur. Un objet peut avoir plusieurs rôles dans la même communauté. Par exemple, un objet peut à la fois être
importateur et exportateur.
Les activités de courtage de la communauté sont les exportations et les importations de services. Ces activités sont régies
par un ensemble de politiques de la communauté de courtage. Une activité d'importation de service peut se propager
d'une communauté de courtage à une autre. Dans un tel cas, les domaines associés à ces deux courtiers sont fédérés. Les
frontières de ces domaines de courtage peuvent coïncider avec celles d'un autre domaine (par exemple un domaine de
type ou un domaine de politique de sécurité).
Une politique est un ensemble de règles visant un objectif particulier. Chaque règle contraint certains aspects d'un
comportement de courtier compatible avec l'objectif commun. Les membres de la communauté de courtage sont tenus de
respecter les règles des politiques. Ces règles fournissent les directives régissant les décisions visant à répondre aux
objectifs de la communauté. Ces règles ne sont pas prescrites dans la présente Spécification. C'est la spécification
d'entreprise qui identifie l'ensemble des politiques qui limitent le courtier dans certains types de comportement. Les
politiques identifiées constituent un cadre dans lequel le comportement de l'objet-courtier peut être mis en œuvre ou
configuré.
��� #OMMUNAUT'S
����� COMMUNAUT'�DE�COURTAGE: communauté d'objets constitué
...