1、INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOM M U N I CAT ION STANDARDIZATION SECTOR OF ITU X.904 Amendment 1 (03/2000) SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS Open distributed processing Information technology - Open Distributed Processing - Reference Model: Architectural seman
2、tics Amendment 1 : Computational formalization ITU-T Recommendation X.904 - Amendment 1 (Previously CCITT Recommendation) ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS PUBLIC DATA NETWORKS Services and facilities X. l-X. 19 Interfaces X.20-X.49 Transmission, signalling
3、and switching X.50-X.89 Network aspects X.90-X.149 Maintenance X. 150-X. 179 Administrative arrangements X. 180-X. 199 Model and notation X.200-X.209 Service definitions X.210-X.219 Connection-mode protocol specifications X.220-X.229 Connectionless-mode protocol specifications X.230-X.239 PICS profo
4、rmas X.240-X.259 Protocol Identification X.260-X.269 Security Protocols X.270-X.279 Layer Managed Objects X.280-X.289 Conformance testing X. 290-X. 299 General X.300-X.349 MESSAGE HANDLING SYSTEMS X.400-X.499 DIRECTORY X.500-X.599 OS1 NETWORKING AND SYSTEM ASPECTS Networking X.600-X.629 Efficiency X
5、.630-X.639 Quality of service X.640-X.649 Naming, Addressing and Registration X.650-X.679 Abstract Syntax Notation One (ASN.l) X.680-X.699 Systems Management framework and architecture X.700-X.709 Management Communication Service and Protocol X.7 10-X.7 19 Structure of Management Information X.720-X
6、.729 x.730-x.799 SECURITY X.800-X.849 OS1 APPLICATIONS Commitment, Concurrency and Recovery X.850-X.859 Transaction processing X. 860-X. 879 Remote operations X. 880-X. 899 OPEN DISTRIBUTED PROCESSING X.900-X999 OPEN SYSTEMS INTERCONNECTION INTERWORKING BETWEEN NETWORKS Satellite data transmission s
7、ystems x.350-x.399 OS1 MANAGEMENT Management functions and ODMA functions II For further details, please refer to the list of IT-TRecommendafions. INTERNATIONAL STANDARD 10746-4 ITU-T RECOMMENDATION X.904 INFORMATION TECHNOLOGY - OPEN DISTRIBUTED PROCESSING - REFERENCE MODEL: ARCHITECTURAL SEMANTICS
8、 AMENDMENT 1 Computational formalization Summary Amendment 1 to ITU-T Rec. X.904 I ISO/IEC 10746-4 refines and extends the ODP architecturai semantics with a formalization of the computational language of the Reference Model for ODP. The computational language of the RM-ODP provides for a descriptio
9、n of ODP systems as collections of interacting objects. This Amendment formalizes the concepts and rules of the ODP computational language using different formai description techniques (LOTOS, SDL, Z and Estelle). Source ITU-T Recommendation X.904, Amendment 1, was prepared by ITU-T Study Group 7 (1
10、997-2000) and approved on 31 March 2000. The identical text is also published as ISO/IEC International Standard 10746-4, Amendment 1. ITU-T Rec. X.904/Arnd.l(2000 E) i FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications
11、. The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication St
12、andardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of informat
13、ion technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with IS0 and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.
14、 LNTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Righ
15、ts, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementor
16、s are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database. o ITU 2001 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopy
17、ing and microfilm, without permission in writing from the ITU. 11 ITU-T Rec. X.904/Amd.l(2O E) CONTENTS Foreword . Clause O . Introduction . Clause 1 . Scope . Clause 2 . Normative references . Subclause 3.2 . Definitions from ITU-T Recommendation 2.100 Subclause 3.3 . Definitions from the Z-Base St
18、andard Annex A Annex A . Computational Formalization . Formalization of the Computational Viewpoint Language in LOTOS Formalization of the Computational Viewpoint Language in Z . Formalization of the Computational Viewpoint Language in ESTELLE A.l A.2 A.3 A.4 Formalization of the Computational Viewp
19、oint Language in SDL . Page 1 1 2 2 2 2 3 3 3 12 20 28 . ITU-T Rec . X.904/Amd.l(2000 E) 111 ISO/IEC 10746-4: 199WAmd. 1 :2001 (E) INTERNATIONAL STANDARD ITU-T RECOMMENDATION INFORMATION TECHNOLOGY - OPEN DISTRIBUTED PROCESSING - REFERENCE MODEL: ARCHITECTURAL SEMANTICS AMENDMENT 1 Computational for
20、malization 1) Foreword Replace the Ist paragraph of the foreword This Recommendation I International Standard is an integral part of the ODP Reference Model. It contains a formalisation of the ODP modelling concepts defined in ITU-T Rec. X.902 I ISO/IEC 10746-2, clauses 8 and 9. The formalisation is
21、 achieved by interpreting each concept in terms of the constructs of the different standardised formal description techniques. with This Recommendation I International Standard is an integral part of the ODP Reference Model. It contains a formalization of the ODP modelling concepts defined in ITU-T
22、Rec. X.902 I ISO/IEC 10746-2, clauses 8 and 9 and in ITU-T Rec. X.903 I ISO/IEC 10746-3, clause 7 (Computational Language). The formalization is achieved by interpreting each concept in terms of the constructs of the different standardized formal description techniques. 2) Clause O - Introduction Re
23、place the fourth bullet under The RM-ODP consists of ITU-T Rec. X.904 1 ISO/IEC 10746-4: Architectural Semantics: contains a formalisation of the ODP modelling concepts defined in ITU-T Rec. X.902 I ISO/IEC 10746-2, clauses 8 and 9, and a formalisation of the viewpoint languages of ITU-T Rec. X.903
24、I ISO/IEC 10746-3. The formalisation is achieved by interpreting each concept in terms of the constructs of the different standardised formal description techniques. This text is normative. with ITU-T Rec. X.904 I ISO/IEC 10746-4: Architectural Semantics: contains a formalization of the ODP modellin
25、g concepts defined in ITU-T Rec. X.902 I ISO/IEC 10746-2, clauses 8 and 9, and a formalization of the computational viewpoint language of ITU-T Rec. X.903 I ISOIEC 10746-3. The formalization is achieved by interpreting each concept in terms of the constructs of the different standardized formal desc
26、ription techniques. This text is normative. Replace the fourth paragraph The purpose of this Recommendation I International Standard is to provide an architectural semantics for ODP. This essentially takes the form of an interpretation of the basic modelling and specification concepts of ITU-T Rec.
27、X.902 I ISO/IEC 10746-2 and the viewpoint languages of ITU-T Rec. X.903 I ISO/IEC 10746-3, using the various features of different formal specification languages. An architectural semantics is developed in four different formal specification languages: LOTOS, ESTELLE, SDL and Z. The result is a form
28、alisation of ODPs architecture. Through a process of iterative development and feedback, this has improved the consistency of ITU-T Rec. X.902 I ISO/IEC 10746-2 and ITU-T Rec. X.903 I ISO/IEC 10746-3. with The purpose of this Recommendation 1 International Standard is to provide an architectural sem
29、antics for ODP. This essentially takes the form of an interpretation of the basic modelling and specification concepts of ITU-T Rec. X.902 I ISO/IEC 10746-2 and the computational viewpoint language of ITU-T Rec. X.903 I ISO/IEC 10746-3, using the various features of different formal specification la
30、nguages. An architectural semantics is developed in four different formal ITU-T Rec. X.904/Arnd.l(2000 E) 1 specification languages: LOTOS, ESTELLE, SDL and Z. The result is a formalization of ODPs architecture. Through a process of iterative development and feedback, this has improved the consisten
31、cy of ITU-T Rec. X.902 I ISO/IEC 10746-2 and ITU-T Rec. X.903 I ISO/IEC 10746-3. 3) Clause 1 - Scope Add the following paragraph at the end of Scope: Annex A shows one way in which the computational viewpoint language of ITU-T Rec. X.903 I ISO/IEC 10746-3 can be represented in the formal languages L
32、OTOS, SDL, 2 and Estelle. This Recommendation I International Standard also makes use of the concepts defined in ITU-T Rec. X.902 I ISO/IEC 10746-2. 4) Clause 2 - Normative references Change publication date for ITU-T Recommendation 2.100 from (1993) to (1999). ISO/IEC 13568: Add the following refer
33、ence: Z Notation, ISO/IEC JTC 1 SC 22 WG 19 Advanced Working Draft 2.C, July 13th 1999. 5) Replace the list with the following terms: Subclause 3.2 - Definitions from ITU-T Recommendation 2.100 active, adding, all, alternative, and, any, as, atleast, axioms, block, call, channel, comment, connect, c
34、onnection, constant, constants, create, del, decision, default, else, endalternative, endblock, endchannel, endconnection, enddecision, endgenerator, endnewtype, endoperator, endpackage, endprocedure, endprocess, endrefinement, endselect, endservice, endstate, endsubstructure, endsyntype, endsystem,
35、 env, error, export, exported, external, fi, jnalized, for, fpar, from, gate, generator, $ import, imported, in, inherits, input, intelface, join, literal, literals, map, mod, nameclass, newtype, nextstate, nodelay, noequality, none, not, now, offspring, operator, operators, or, ordering, out, outpu
36、t, package, parent, priority, procedure, process, provided, redefined, referenced, refinement, rem, remote, reset, return, returns, revealed, reverse, save, select, self; sender, service, set, signal, signallist, signalroute, signalset, spelling, start, state, stop, struct, substructure, synonym, sy
37、ntype, system, task, then, this, timer, to, type, use, via, view, viewed, virtual, with, xor. 6) Change subclause title to: 3.3 - Definitions from the Z Notation. Replace the list with following terms: axiomatic description, data rejnement, hiding, operation refinement, overriding, schema (operation
38、, state, framing), schema calculus, schema composition, sequence, type. Subclause 3.3 - Definitions from the Z-Base Standard 2 ITU-T Rec. X.904/Amd.l(2000 E) ISOIEC l746-4:1998/Amd.l:2001 (E) 7) Annex A Add a new Annex A as follows: Annex A Computational Formalization A.l A.l.l Concepts The formaliz
39、ation of the computational language in LOTOS uses the concepts defined in the formalization of the basic modelling and structuring rules given in ITU-T Rec. X.902 1 ISO/IEC 10746-2 clauses 8 and 9. Elementary Structures Associated with Operational and Signai Interfaces To formalize the computational
40、 language in LOTOS it is necessary to introduce certain elementary structures. These include parameters that might be associated with certain computational interfaces and a basic model of information that might be used in a stream flow. To formalize parameters it is necessary to introduce two concep
41、ts: names for things and types for things. Names are simply labels. As we shall see, the computational viewpoint requires that checks, e.g. for equality, are done on these labels when interfaces are constructed. We may represent names generally by: Formalization of the Computational Viewpoint Langua
42、ge in LOTOS type Name is Boolean sorts Name opns newName: - Name anotherName: Name - Name eq,-ne-: Name, Name - Bool endtype (* Name *) For brevity sake we omit the equations, which are expected to be obvious. It is possible to be more prescriptive here, e.g. using character strings from the LOTOS l
43、ibrary. The only thing we are interested in regarding names is that we can determine their equality or inequality. As discussed in this Recommendation I International Standard, a type in the ODP sense may not be interpreted directly in the process algebra part of LOTOS. It is however possible to mod
44、el types through the Act One part of LOTOS. Unfortunately, whilst Act One was designed specifically for representing types, it is limited in the ways in which types and types relationships are checked. For example, it is not possible to check subtyping or equivalence up to isomorphism between types
45、due to type equality in Act One being based on name equivalence of sorts. As a basis for reasoning here we introduce an elementary notion of types that allows us to test for equality, inequality and subtyping. type AnyType is Boolean sorts AnyType opns newType: - AnyType anotherType: AnyType - AnyTy
46、pe -eq,JsSubtype-: AnyType, AnyType - Bool endtype (* AnyType *) A parameter is a relation between a name and its underlying type representation. Thus a parameter may be represented by: type Param is Name, AnyType sorts Param opns newparam: Name, AnyType - Param eq,-ne-,-isSubtype-: Param, Param - B
47、ool endtype (* Param *) As previously, we require checks on the equality or inequality of parameters as well as when one parameter is a subtype of another. Two parameters are in a subtype relationship when their types are in a subtype relationship. It is also useful for us to introduce sequences of
48、these parameters. type PList is String actualizedby Param using sortnames PList for String Param for Element Boo1 for FBool opns -issubtype-: PList, PList - Bool endtype (* PList *) ITU-T Rec. X.904/Amd.l (2000 E) 3 Here we use the type String from the LOTOS library actualised with the type Param de
49、fined previously. We also include an operation here issubtype that can check whether one sequence of parameters is a subtype of another. One parameter list is a subtype of a second when all of the parameters it contains are subtypes of those found in the first. In addition the parameters should be in the same position in their respective lists. It should be noted that these parameters might contain references to interfaces used to restrict the interactions that can take place. Whilst it is quite possible to model an interface in the process algebra, it is not possible to model a refer
