ITU-T Q 816 1-2001 CORBA-Based TMN Services Extensions to Support Coarse-Grained Interfaces Series Q Switching and Signalling Q3 Interface《CORBA 基于TMN业务 支持粗粒接口的基于CORBA的TMN业务扩展-系列Q .pdf

《ITU-T Q 816 1-2001 CORBA-Based TMN Services Extensions to Support Coarse-Grained Interfaces Series Q Switching and Signalling Q3 Interface《CORBA 基于TMN业务 支持粗粒接口的基于CORBA的TMN业务扩展-系列Q .pdf》由会员分享，可在线阅读，更多相关《ITU-T Q 816 1-2001 CORBA-Based TMN Services Extensions to Support Coarse-Grained Interfaces Series Q Switching and Signalling Q3 Interface《CORBA 基于TMN业务 支持粗粒接口的基于CORBA的TMN业务扩展-系列Q .pdf（35页珍藏版）》请在麦多课文档分享上搜索。

1、! INTERNATIONAL TELECOMMUNICATION UNION ITU-T TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU SERIES Q: SWITCHING AND SIGNALLING Q3 interface Q.816.1 (08/2001) CORBA-based TMN services: Extensions to support coarse-grai ned interfaces ITU-T Recommendation Q.816.1 ITU-T Q-SERIES RECOMMENDATIONS SWITC

2、HING AND SIGNALLING SIGNALLING IN THE INTERNATIONAL MANUAL SERVICE FUNCTIONS AND INFORMATION FLOWS FOR SERVICES IN THE ISDN SPECIFICATIONS OF SIGNALLING SYSTEMS No. 4 AND No. 5 SPECIFICATIONS OF SIGNALLING SYSTEM No. 6 SPECIFICATIONS OF SIGNALLING SYSTEM R1 SPECIFICATIONS OF SIGNALLING SYSTEM R2 DIG

3、ITAL EXCHANGES INTERWORKING OF SIGNALLING SYSTEMS SPECIFICATIONS OF SIGNALLING SYSTEM No. 7 INTERVATIOXx4L AUTOMATIC A?- SEMI-AUTOMATIC WORKhC CLAUSES APPLICABLE TO ITU-T STANDARD SYSTEMS General Message transfer part (MTP) Signalling connection control part (SCCP) Telephone user part (TUP) ISDN sup

4、plementary services Data user part Signalling System No. 7 management ISDN user part Transaction capabilities application part Test specification 43 INTERFACE DIGITAL SUBSCRIBER SIGNALLING SYSTEM No. 1 PUBLIC LAND MOBILE NETWORK NTERWORKING WITH SATELLITE MOBILE SYSTEMS NTELLIGENT NETWORK BROADBAND

5、ISDN SIGNALLING REQUIREMENTS AND PROTOCOLS FOR IMT-2000 Q. 14.3 4.60-4.99 Q.lOO-Q.119 Q. 1204.249 4.2504.309 4.3 10-4.399 4.400-4.499 Q.500-Q.599 4.6004.699 4.7004.799 4.700 Q.701-Q.709 4.71 14.719 Q.72O-Q.729 4.7304.739 4.750-4.759 4.760-4.769 4.7704.779 4.7804.799 Q.SOO-Q.849 Q.850-Q.999 Q.1000-Q.

6、1099 Q. 1 10O-Q. 1 199 Q. 1200-Q. 1699 Q.170O-Q.1799 Q.200O-Q.2999 Q.4-Q.59 4.740-4.749 For further details, please refer to the list of ITU-T Recommendations ITU-T Recommendation Q.816.1 CORBA-based TMN services: Extensions to support coarse-grained interfaces Summary This Recommendation defines ex

7、tensions to the set of TMN CORBA Services required to support coarse-grained interfaces. It specifies how CORBA Common Object Services are used to support coarse-grained interfaces, and defines extensions to the TMN-specific support services defined in ITU-T Q.816. A CORBA IDL module defining the in

8、terfaces to the new TMN-specific support services is provided. Source ITU-T Recommendation Q.8 16.1 was prepared by ITU-T Study Group 4 (200 1-2004) and approved under the WTSA Resolution 1 procedure on 13 August 200 1. Keywords Coarse-grained, Common Object Request Broker Architecture (COMA), CORBA

9、 Services, Distributed Processing, Interface Definition Language (IDL), Managed Objects, TMN Interfaces. ITU-T Rec. 4.816.1 (08/2001) 1 FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecomrnunicaticns. The ITU Teleccmmunicaticn Sta

10、ndardization Sector FU-FI 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 Standardization Assembly (WTSA), wh

11、ich 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 information technology which fall within

12、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. INTELLECTUAL PROPERTY RIGHTS ITU

13、 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 Lntellectual Property Rights, whether asserted by ITU membe

14、rs 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, implementors are cautioned that this may not

15、 represent the latest information and are therefore strongly urged to consult the TSB patent database. O ITU 2002 All rights reserved. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permis

16、sion in writing from ITU. 11 ITU-T Rec. Q.816.1 (08/2001) CONTENTS Page 1 1.1 1.2 1.3 2 3 3.1 3.2 3.3 4 5 5.1 5.2 6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 7 7.1 7.2 8 8.1 Scope . Purpose Application Recommendation roadmap . Normative references Definitions Definitions from ITU-T X.70 1 . Definitions from I

17、TU-T X.703 . Definitions from ITU-T 4.8 16 . Abbreviations Conventions Recommendation conventions Compiling the IDL Coarse-grained interface design considerations . Reduced number of IORs . Ability to derive IORs . Application of framework services . Distinguishing between the two types of objects H

18、ierarchical naming Migration of modelled entities across approaches Migration of modelled entities across technologies . Equivalent distinguished names Framework and requirements overview . Framework overview Coarse-grained extensions overview The facade design pattern Managed object name extension

19、Support services for facade-accessible managed objects 7.2.1 7.2.2 7.2.3 7.2.4 Facade modelling . Framework common object services usage requirements for supporting coarse-grained interfaces . i The naming service . 8.1.1 Naming service use on coarse-grained interfaces 8.1.2 Facade interface names 2

20、 2 3 4 4 4 6 7 8 8 9 9 10 11 11 11 11 . ITU-T Rec . 4.816.1 (08/2001) 111 8.2 8.3 8.4 8.5 8.6 9 9.1 9.2 9.3 9.4 9.5 9.6 10 10.1 10.2 8.1.3 8.1.4 Object name comparisons 8.1.5 8.1.6 Naming service requirements for coarse-grained interfaces . Notification service . Managed object name extension Storin

21、g managed object names jn the na users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU-T Recommendations is regularly published. ITU-T Q.8 16

22、 (200 i), CORBA-based TMN services. ITU-T X.780 (2001), Guidelines for defining CORBA managed objects. ITU-T X.780.1 (2001), TA4N guidelines for defining coarse-grained CORBA managed objects interfaces. OMG Document formaV99- 10-07, The Common Object Request Broker: Architecture and SpeciJication, R

23、evision 2.3.1. OMG Document formaV0 1-02-65, Naming Service SpeciJication. OMG Document formaV00-06-20, NotiJication Service Specifzcation, Version 1 .O. OMG Document formaY00-0 1-04, Telecom Log Service Speclfication, Version 1 .O. OMG Document forma1/00-06-25, Securily Services SpeciJication, Vers

24、ion 1.5. OMG Document formaV00-06-28, Transaction Service Specifzcation, Version 1.1. ITU-T Rec. 4.816.1 (08/2001) 101 1 11 OMG TC Document orbos/98-05-05, CORBA Messaging. IETF WC 2246 (1 999), The TLS Protocol Version 1. O. 3 Definit-ions 3.1 Definitions from ITU-T X.701 The following terms used i

25、n this Recommendation are defined in ITU-T X.701: - managed object class; - manager; - agent. 3.2 Definitions from ITU-T X.703 The following term used in this Recommendation is defined in ITU-T X.703: - notification. 3.3 Definitions from ITU-T Q.816 The following term used in this Recommendation is

26、defined in ITU-T Q.8 16: - event channel. 4 Abbreviations This Recommendation uses the following abbreviations: AMI API CMIP COBA cos DN EMS GDMO ID IDL IIOP IOR ITU-T MO MOO NE NMS OAM void operation1 0 ; 5.2 Compiling the IDL An advantage of using IDL to specify network management interfaces is th

27、at IDL can be “compiled“ into programming code by tools that accompany an ORB. This actually automates the development of some of the code necessary to enable network management applications to interoperate. This Recommendation has an annex that contains source code that implementers will want to ex

28、tract and compile. Annex A is normative and should be used by developers implementing systems that conform to this Recommendation. The IDL in this Recommendation has been checked with two compilers to ensure its correctness. A compiler supporting the CORBA version specified in ITU-T 4.816 must be us

29、ed. 4 ITU-T Rec. 4.816.1 (08/2001) Annex A has been formatted to make it simple to cut and paste into plain text files that may then be compiled. Below are tips on how to do this. 1) Cutting and pasting seems to work better from the Microsofi Word version of this Recommendation. Cutting and pasting

30、from the Adobe Acrobat file format seems to inciude page headers and rooters, which cannot be compiied. All of Annex A, beginning with the line I/* This IDL code .I through the end should be stored in a file named “itut-q816-l.idlt in a directory where it will be found by the IDL compiler. The headi

31、ngs embedded in the annex need not be removed. They have been encapsulated in IDL comments and will be ignored by the compiler. Comments that begin with the special sequence “/*“ are recognized by compilers that convert IDL to HTML. These comments often have special formatting instructions for these

32、 compilers. Those that will be working with the IDL may want to generate HTML as the resulting HTML files have links that make for quick navigation through the files. The annex has been formatted with tab spaces at 8-space intervals and hard line feeds that should enable almost any text editor to wo

33、rk with the text. 2) 3) 4) 5) 6 Coarse-grained interface design considerations This clause identifies several design considerations that must be addressed by the framework as support for coarse-grained interfaces is added. 6.1 Reduced number of IORs As support for coarse-grained interfaces is added

34、to the framework, the framework must enable the number of managed resources (like termination points) to grow without increasing the number of IORs exposed across the management interface. 6.2 Ability to derive IORs A lot of the early debate over the merits of coarse-grained interfaces focused on th

35、e need to reduce the number of IORs supported by a managed system. This was because throughout most of the 1990s Object Request Brokers (ORBs) offered system developers no standard way to persistently store the state of an object between method invocations. Thus, all objects with outstanding IORs ha

36、d to be kept in memory, which limited the number of IORs a system could support. The OMG remedied this with the CORBA 2.2 specification, however, and most ORBs now support the OMGs Portable Object Adapter (POA) standard, which enables systems to persistently store object state between method invocat

37、ions. Thus, the number of objects a managed system can now support is basically limited only by the number of objects it can store in its disk space. This, however, does not negate all the benefits of coarse-grained interfaces. The benefactor, it turns out, will be mainly the managing system. When a

38、 managing system uses a fine-grained COBA interface in order to interact with each managed resource, it must at some time retrieve the IOR for each managed resource, In a system with millions of managed resources, this amounts to millions of IORs. Managing systems will probably implement a range of

39、strategies for dealing with large numbers of IORs. The simplest will be to just resolve a managed resources name to its IOR before each interaction, but this is slow and wasteful of data communications network resources. An alternative will be to retrieve all names and their paired IORs once, and st

40、ore them on the managing system. Another strategy will be to cache names and IORs on the managing system, keeping the most recently used IORs on hand for quick reference while discarding those not used for some time to be retrieved from the managed system when needed again. Other strategies could al

41、so emerge. ITU-T Rec. 4.816.1 (08/2001) 5 Coarse-grained interfaces have the potential to relieve managing systems from having to implement such schemes. Coarse-grained interfaces could enable a managing system to initially retrieve and store just a small number of IO its purpose is to enable intera

42、ction with the objects that do represent manageable resources. All facade objects are created automatically by the managed system, and exist as long as the managed objects are accessible through the facade. Multiple facades for the same type of managed objects may exist on a coarse-grained interface

43、, but a managed object shall be accessible through only 1 facade. See Figure 2 below. Managing System Managed System Managed Object COMA Interface Figure 2/Q.816.1- The facade role 8 ITU-T Rec. 4.816.1 (08/2001) The figure shows a managing system accessing a managed system that supports the coarse-g

44、rained approach. The managed system has two facade interfaces that enable the managing system to access two different sets of managed objects. The managed objects at the top of the figure can only be accessed through the facade. The managed objects at the bottom also support direct CORBA interfaces

45、and cm he accessed either though the facade or directly. Dircct COMIA access is optional, but a managed system that supports the facade approach must provide facade interfaces for each of its managed object instances. A facade may use a managed objects COMA interface to invoke an operation on it, or

46、 some other implementation-specific means. A managed system, in fact, need not even implement managed objects as individual objects internally. By implementing an interface based on this framework, however, it will give the illusion that managed objects are internally implemented as objects. When an

47、 operation is invoked on a managed object through a facade, the facade must then invoke the operation on the actual managed object or entity. Because many managed objects will be accessed through a single facade, the facade must know which managed object is the actual target of the operation. This w

48、ill be handled by adopting the convention of including the name of the target managed object as the first parameter of every facade operation directed at a managed object. While managed objects may no longer have unique IORs, they will still have unique names and can still be thought of as individua

49、l entities representing manageable resources. 7.2.2 Managed object name extension As mentioned above, managed objects accessed through a facade will still have a name even though they may not have an individual CORBA interface. It is important that a managing system be able to determine which facade to use based on the managed objects name. If it cannot it will have to query the managed system or persistently associate a facade IOR with every managed objects name. To support the ability to determine a managed objects facade based on only its name, the names of manag