CNS 14648-2002 Management of the transport network-Application of the RM-ODP framework《传送网络管理─开放分布式处理参考模型﹝RM─ODP﹞框架之应用》.pdf

《CNS 14648-2002 Management of the transport network-Application of the RM-ODP framework《传送网络管理─开放分布式处理参考模型﹝RM─ODP﹞框架之应用》.pdf》由会员分享，可在线阅读，更多相关《CNS 14648-2002 Management of the transport network-Application of the RM-ODP framework《传送网络管理─开放分布式处理参考模型﹝RM─ODP﹞框架之应用》.pdf（64页珍藏版）》请在麦多课文档分享上搜索。

1、1 傳送網路管理開放分散式處理參考模型（RM-ODP）框架之應用 印行年月 94 年 10 月 本標準非經本局同意不得翻印 中華民國國家標準 CNS 總號 類號 ICS 01.040.33 14648 X1233 經濟部標準檢驗局印行 公布日期 修訂公布日期 91 年 6 月 6 日 年月日(共 64 頁) Management of the transport network Application of the RM-ODP framework 1.適用範圍：本標準係描述網路層模型模型化的概念，本模型使用開放分散式處理參考模型（ Reference Model of Open Distri

2、buted Methodology；簡稱 RM-ODP）框架構來作為定義此方法論之起始點。 依據此方法論發展一套完整的規範之程序描述在附錄 5。 1.1 目標：本標準有下列幾個目標： (1)定義一個方法論，用以規定支援在 TMN 架構裡的網路運算系統介面之網路管理模型，初期是 OSI 管理和其它基礎架構 (例如 :CORBANIDL 和 ODP 功能 )一起使用。 (2)產生的各個模型能夠彈性分散到不同的管理系統架構中 (例如 :使用 OSI 管理或是以分散式處理為基礎的系統 )。 (3)應使規格和處理的個體的可再用性提昇至最高。 (4)應與現有以 OSI 管理為基礎之標準保持最大的相容性，且

3、應被視為其延伸。 備考 :此方法論定義之企業、資訊和計算觀點與實作無關，對 OSI 管理之定義而言透過這種方法論亦可適用於其它的基礎架構之定義，因此初期標準雖以 OSI 管理基礎建設為目標，但是本標準中所定義關於企業、資訊和計算觀點的模型仍然與基礎架構無關。 1.2 原則 (1)選用 RM-ODP 係為了提供一種可追溯到需求之精確規格技術框架構。 (2)技術之選用，係以遵循保留以 OSI 管理之最高相容性為目標。 (3)與現有的 OSI 管理為基礎之標準相容例如 CNS_(ITU-T M.3100)、CNS_(ITU-T G.774-X)、 CNS_(ITU-T X.700)系列中有關 OSI

4、 管理部份，CNS_(ITU-T Q.821)、 CNS_(ITU-T Q.822)等。 (4)在人類可讀性與機器的可讀性和精確性 (如正規表示法之使用 )等需求之間，取得一個平衡。 (5)此標準應在以實作為基礎的不同基礎架構上處促進應用交互運作。 1.3 標準結構：第 2 節為用語釋義，第 3 節為縮寫定義，第 4 節為其餘的章節所提方法論之概要描述，第 5、 6、 7 和 8 節將規定 RM-ODP 方法論上所使用之各個觀點，分別是企業、資訊、計算和工程，第 9 節將描述如何使用整體技術來定義網路管理應用系統，最後則為本標準所使用到之參考文獻。 附件 1、 2、 3 和 4 分別描述用以定

5、義企業、資訊、計算和工程觀點來的樣板，附件 5 定義方法論上所使用之標籤語法，附件 6 描述用以定義管理整體技術之樣板。 2 CNS 14648, X 1233 附錄 1 到 5 包括許多運用本方法論來解決網管問題的應用實例，並說明如何透過本方法論以發展標準規格，附錄 6 定義使用在本方法論上的各個不同的RM-ODP 觀點間的對應，附錄 7 提供在資訊觀點中的運用 Z 表示法的一些準則。 2.用語釋義：本標準定義下列名詞。 2.1 合約型式 :所有合約特徵的表示 (即是 :必要的、需協商或選項的 )。 2.2 合約實例 :提供者和某客戶間經協商而得到的結果。 3.縮寫 ASN.1 Abstra

6、ct Syntax Notation One 抽象語法記法 (一 ) BEO Basic Engineering Object 基本工程物件 BNF Backus-Naur Form Backus-Naur 形式 CMIP Common Management Information Protocol 共同管理資訊協定 CMISE Common Management Information Service Element 共同管理資訊服務元件 CORBA Common Object Request Broker Architecture 共同物件請求仲介者架構 DCE Distributed C

7、omputing Environment 分散式計算環境 DPE Distributed Processing Environment 分散式處理環境 GDIO Guidelines for the Definition of Information Objects 資訊物件定義指引 GDMO Guidelines for the Definition of Managed Objects 受管理物件定義指引 GRM General Relationship Model 通用關係模型 IDL Interface Definition Language 介面定義語言 ITU-T Internat

8、ional Telecommunication Union-Telecommunication Standardization Sector 國際電信聯盟 -電信標準部門 MOCS Managed Object Conformance Statement 被管理物件符合性聲明 ODL Object Definition Language 物件定義語言 OMG Object Management Group 物件管理組織 OSI Open System Interconnection 開放系統互連 PICS Protocol Implementation Conformance Statemen

9、t 協定實作符合性聲明 SDH Synchronous Digital Hierarchy 同步數位階層 SMI Systems Management Information 系統管理資訊 SNC Subnetwork Connection 子網路連接 SNMP Simple Network Management Protocol 簡易網路管理協定 TMN Telecommunications Management Network 電信管理網路 3 CNS 14648, X 1233 4.方法論概觀 4.1 簡介：從網路管理的觀點， RM-ODP 提供物件導向框架 (對於分散式管理系統 )提供

10、每個管理應用的使用者需求 (例如組態管理 )，提供和資源相關的資訊 (或資料 )能夠被管理，提供資訊存取與運作的方式能夠以和管理系統實作所使用的技術和分散無關的方式來定義。 針對系統和被管裡的資源 RM-ODP 框架構提供五個觀點，如圖 1 所示 : 圖 1 RM-ODP 觀點 RM-ODP 提供 : (1)一套描述開放式分散系統的概念。 (2)與任何存在的分析和 /或設計和 /或撰寫程式的方法 /語言無關。 初始的網路階層模型化工作，只利用 RM-ODP 的企業、資訊、計算和工程觀點。 技術觀點的國際電信聯盟的電信標準部門目前暫不予考慮。 網路階層模型的資訊與計算觀點，著重在針對每一個別或一

11、連串管理應用，而必須交換的是資訊的語義意而非語法，由於要達成系統內部的互運必須藉著外部的介面定義，所以就技術的觀點而言，這層所定義的是有足夠的能力去訂定更詳細的系統規格，符合性的需求將定義在這些相互關聯的外部介面上，以工程觀點而言特定的通信技術勢必被定義，就像是 OSI 系統管理。 網路層模型的定義乃是運用本方法論文件所定義之觀點而訂定。 4.1.1 RM-ODP 觀念的描述： RM-ODP 觀點的完整描述，在相關標準中列出，RM-ODP 觀點簡述如下： (1) 企業觀點 :在 RM-ODP 系統及其環境下，所謂的觀點著重在該系統的目的、範圍和策略，企業規範能賦予 ODP 系統客戶表達他們的需

12、求和策略，由此在 ODP 系統的提供者和客戶之間可以建立一份合約，因此，企業規範必須以能使雙方瞭解的方式陳述。 T1521040-96資訊計算企業技術有那些資訊、有那些資源存在，它們之間的關連及靜態和動態方面的數據需求敘述那些有共同目標角色和政策的代理共同體計算物件間的互動包括計算物件的內部行為及介面定義以分散式為基礎的物件檔案 ,如何達成一致的計算模式作業系統的選擇 ,平台 ,一致性開放式系統工程 4 CNS 14648, X 1233 (2) 資訊觀點 :在 RM-ODP 系統及其環境下，所謂的觀點著重在系統內部資訊的語意和資訊處理的活動，資訊觀點著重在資訊物件型式的定義以及它們之間的關係

13、、狀態值及被允許的狀態改變。 (3) 計算觀點 :在 ODP 系統及其環境下，所謂的觀點著重在將功能分解到適合的分散式架構。計算規格描述計算物件式及它們的介面式，這些物件型式的實例將透過介面彼此間相互合作。透過運算標記和聯合行為詳細定義了運算的介面式。所有計算物件被分散到不同的系統，在此方法論的背景裡，除非有更進一步的計算介面被定義，否則任何被定義的計算物件不能被進一步的分散。 (4) 工程觀點 :在 ODP 系統及其環境下，所謂的觀點著重在系統中支援分散所需的功能，一個工程規範格用來做分散計算物件的實質決定，此外，也決定支援分散式物件的基礎架構元件。 (5) 技術觀點 :在 ODP 系統及其

14、環境下，所謂的觀點著重在該系統的技術選擇。 4.2 在規格設計方法論中運用 RM-ODP 觀點：雖然開放分散式處理的參考模型提供一模型化的方法 (也就是 :RM-ODP 觀點 )，但是在開發系統時，它並沒有提供規範性的方法讓開發人員遵循。本節介紹運用 RM-ODP 的觀點的方法論，使用在傳送網路管理模型的標準化，藉由充分定義的介面使應用元件看做是物件溝通，那些外部顯現的行為是運用一個和實作無關的方式來描述。本方法論使用下列步驟 : (1)確認需求。 (2)定義描述系統的資訊。 (3)描述運作資訊和提供服務之程序。 (4)做分散和實作的決定。 每一個設計步驟都和 RM-ODP 的觀點相互結合，事

15、實上觀點的時間順序並不重要，比較需要的是 RM-ODP 框架涉及到的分類，以本方法論為基礎的規格處理實例呈現在附錄 6，和觀點之間的關係呈現在附錄 7。 形成傳送網路架構的一連串資源，只能用 RM-ODP 的企業和資訊觀點來描述，然而一個網路管理服務必須附加計算觀念，開發管理能力的工程程序期間，傳送網路架構和服務定義兩者將會合併，例如在發展 Q3 介面時。 4.3 觀點之間的追蹤：本方法論容許在需求和工程規範結果之間做追蹤，這是藉由將文件用每一企業社群間皆有直接關係的建構方法來達成，例如 :靠著以標籤綱要的描述從工程規格追溯回到需求。 4.3.1 標籤：標籤將提供特定的規格元素件，並容許標籤成

16、為其它規格的參考。橫跨在相同服務的數種觀點或數個服務規格中，在相同觀點下作成參考。 (例如 :當使用 IMPORT 項目 )。 4.3.1.1 標籤宣告結構：標籤結構是使用 BNF 為基礎的結構。 標籤參考結構為樹狀結構，在樹狀上的每一個節點將是事先定義好的關鍵字 (像定義在本標準，例如 ATTRIBUTE、 COMMUNITY、 ROLE)或元件標籤，元件標籤是提供給規格元件做辨識，例如 :網路蹤跡的終端點（ networkTTP），運算狀態 (operational_state)。定義的元件標籤在樹狀 5 CNS 14648, X 1233 結構的直屬上層節點下所有下層節點裡必須是唯一的，

17、參考用標籤在上下文中必須是唯一的，參考標籤必須提供到能提供唯一的指標到被參考到的規格部份之層，元素標籤定義成一個文字串，參考標籤是以 標籤圈起，例如 :在同一標準中的參考標籤，並無需附加標準元件，同理，若於某觀點中參考到該觀點的其它元素時也不用額外的觀點號元件標籤。 BNF 定義的標籤結構在附件 5 說明。 5. 企業觀點：企業觀點是定義在 RM-ODP 的第三部份，主要定義開放分散式處理系統的目標、範圍和策略，其目標在於規定所有參與的相關系統需求，這些需求是以系統和使用者環境間的交互作用來陳述，任何以系統行為方式影響的管理應用間的交互作用，必須在企業觀點裡定義。 企業觀點之所以包含於網路層模

18、型之理由如下 : (1) 將所使用到模型中不同部份以文件記載下來，此模型乃基於有相同共同功能 (應用 )之社群。 (2) 在定義模型時提供規定需求的方法。 樣板和語言使用在遵從需求的規範裡，定義在 RM-ODP 的第三部份。 樣板用來描述社群，它表示各功能間的關係藉以滿足一個特定的目標 (管理應用 )就像連接管理，企業社群明確提出特定問題的領域，企業社群是由一連串角色、一連串動作、一連串政策所組成，以用來滿足共同的目標或合約，那是被分配到各個角色之間，一個社群不規定物件 -只對他們扮演的角色作說明，因此指定的物件在不同的社群可以扮演許多不同的角色，社群不規定處理過程 (透通 )，一社群支援在社

19、群合約角色之間的許多不同的實例，每一個角色 (或一連串角色 )和另一個角色之間有一個個別的合約，在合約中的實例將從一連串可取用的服務中挑選服務要點。 聯合每一個社群描述以下的專有名詞 : (1)Contract 合約 (2)Community roles 社群角色 (3)Community policies 社群政策 (4)Community actions 社群動作 (5)Community activities 社群活動 (6)Service 服務 (7)Service feature 服務特徵 下列的子節更詳細 描述企業的元件，定義它們的企業樣板和語言被描述在附件 1。 5.1 企業觀點

20、的領域：合約的建立提供了提供者和客戶間的關係，一份指定的合約反映服務和伴隨的品質，那是靠提供者提供給客戶以及客戶的認可。 服務合約將包括所有的特徵，此特徵賦予定義服務型式的能力，包括 : (1)一個社群定義。 (2)伴隨社群的角色表列。 可適用於社群社群的政策略。 (4)每個動作和聯合的政策略。 (5)每個活動，若有的話。 5.2 概念 6 CNS 14648, X 1233 5.2.1 社群：此需求的獲得是在開放式分散處理系統社群第一次被確認時，社群是一個為達成若干目標而聚在一起的角色團體，社群的目標必 須明確清楚，典型地社群目標是提供一個特定服務。例如 :子網路連接管理社群，資源管理社群等

21、。 RM-ODP 的第三部份產生下列定義 : 社群 :是由一個或一個以上的物件為滿足目標所構成，此目標的表示如同合約它規定目標如何滿足。 社群根據它的目的被定義 (例如 :共同目標是由伴隨社群的角色所構成 )，定義隱含在社群的每個角色和適用的策略到整個社群。 5.2.2 合約：服務經由協商的結果成為一個合約實例，它反映出經由雙方議定選擇的提供者服務要點，這些服務要點能獲得一連串的支援動作、活動及合適的支援政策。 RM-ODP 的第二部份乃針對合約產生下列定義 : 合約 :管理協議是一組物件的集體行為的一部份，合約規定參與的義務、允許和禁止，合約規格包括 : (1) 規格擁有各種不同角色，在合約

22、裡的物件依據角色的不同可以擔負不同的任務，使介面和角色結合起來。 (2) 服務品質的屬性。 (3) 持續或有效期間的指示。 (4) 使合約無效的那些行為之標指示。 (5) 生存及安全條件。 針對一個指定提供者 (強制提供者和 /或客戶的行為 )的所有客戶，某些合約特徵將是必要的，其它的在合約建立之前提供者和每個客戶間 將透過協商，協商處理結果決定是否提供服務支援，此外，在合約建立後一些合約要點可以保留下來，以供選擇且可供客戶和提供者協調時使用或作為本地的政策基礎 (諸如 ”best effort”)。 為了反映此策略，一個企業規格應具有兩部份，第一部份將反映所有合約特徵的表示 (即 :必要的、

23、經協商的結果而定的或選項的 )，此第一部份提供者和指定客戶間協商的結果將被提供者用來建立第二部份，就這個觀念，第一部份勢必仔細考慮服務合約型式同時第二部份也儘可能考慮像服務合約實例。 合約協商處理已經超越方法論的範疇。 備考 :在本方法論的企業觀點裡無法在介面和角色間做區別。 5.2.3 角色：在方法論裡應用企業角色概念定義在 RM-ODP 的第二部份，每個服務的所有角色都會被定義。 呼叫者角色表示定義某一服務的服務要求之企業物件行為。 提供者角色表示執行某一服務的服務要求之企業物件行為。 服務的其他角色表示，在服務內容上下文中反映資源的相互關連之企業物件行為。 5.2.4 策略：社群政策規定

24、一連串的允許、義務、禁止和例外，此政策適用於客戶或是適用於提供者。有關社群 RM-ODP 的第二部份提供下列定義 : 7 CNS 14648, X 1233 策略 :和特定目的相關聯的一連串規則，規則能夠表示義務、允許或禁止。 備考 :不是每一個策略都是強制的，有一些策略是授予權力的。 義務 :要求特定行為的規定，義務是履行規定的行為事件。 允許 :准許發生特定行為的規定，允許和義務是相對的，換句話說如果沒有行為發生就沒有所謂的義務。 禁止 :不准發生特定行為的描述，禁止相當於沒有行為發生的義務。 5.2.5 動作：根據 RM-ODP 的第二部份，行為的定義乃依據 : 動作事件發生。 每個社群

25、都有一連串的動作用來支援社群目標，動作用來表示服務要求和交換客戶和提供者間的聯合回應，典型的動作包括 :連接建立，連接釋放和連接變更，這些動作可以集合起來變成活動，且可規定動作發生的順序。 每個動作是由動作名稱和動作策略的規格所定義。 聯合每個動作成為一連串的動作策略，動作政策根據義務、允許、禁止來描述，且此義務、允許、禁止適用於與社群有關之客戶和提供者，這些政策的角色狀態和資訊伴隨在每個政策裡，總之，企業觀點沒有意圖去做關於資訊的相關規定。 5.2.6 活動：定義在社群內的一連串行為，包括各種活動的描述和活動名稱，把每個活動聯合在一起所定義的動作圖表，包括較小的動作和活動聯合在一起的表列，另

26、外，聯合各個活動變成一連串活動政策，連同動作圖表，如同在一個活動內的動作順序的依存狀態必須如政策般清楚的規定。 根據 RM-ODP 的定義，活動是通用服務認知的一部份及提供者和客戶間唯一的交換行為那是提供者活動的動作項目屬於合約規範的一部份，事實上它是在服務認知的基礎上去做明確的抉擇動作項目是遵循抑或是不遵循接下來的動作，無論如何，對於一些案例，客戶向供應者提出許多相關聯的動作如同服務要點的一部份，在這個案例裡，這些相關聯的動作都是活動的一部份。 RM-ODP 的第二部份提供下列定義 : 活動 :一個單一表頭非循環的動作圖表，在圖表上每個動作當其之前的所有動作發生後即可發生 (所謂先前的動作即

27、與本動作相鄰且較接近表頭之動作 )。 5.2.7 服務：服務是經由服務提供者和服務使用者兩者間透過特定的一連串服務特徵做協商，此協商取決於使用者的需求和提供者能力，在 TMN 的觀念裡服務沒有所謂的服務管理，服務是藉一連串的運算動作去完成 特定的目標，且可以存在於任何邏輯層架構的層次。 5.2.8 服務特徵：服務特徵是由一連串的共同策略，活動和 /或動作及它們的聯合政策所構成。 5.2.9 服務的合成：以現存合約為基礎的合約定義留待未來研究。 5.3 社群的延伸：社群的伸展方法留待未來研究。 5.4 領域： RM-ODP 的領域概念，定義在 RM-ODP 的第二部份的 10.3 節，是有關社群

28、的建立，意圖將領域變成方法論的一部份，總之此概念須要被重新定義在網路層模型的項目裡，此概念應用在本方法論裡留待未來研究。 8 CNS 14648, X 1233 6. 資訊觀點：資訊觀點定義在 RM-ODP 的第三部份的第三節，此章節定義分散式系統裡的資訊型式，從網路層模型的角度來說，資訊觀點影響被管理物件和管理應用的資訊面 (包括狀態和重要變遷 )。 資訊觀點定義資訊物件型式及物件型式的屬性，連同它們被允許的時態變遷間的關係，從網路層模型的角度，資訊觀點藉著模型來定義靜態的不變的資訊事件 (綱要 )和被管理資源間的關係 (例如 :連接、鏈路、網路終端點等 )同時定義資源的動態綱要，動態綱要定

29、義一個或一個以上資訊物件可容許的狀態改變。 下述三部份用來規定資訊觀點 : (1) 非正規描述規定自然語言偕同專有標籤關鍵字 ( 例如 :DEFINITION ，INVARIANTS 等 )。 (2)半正規描述，規定使用定義被管理物件 (GDMO)指引的子集合和通用關係模型(GRM)，如同使用在 OSI 管理。和 (3)正規定義被提供使用在 Z 記法。 此外，亦表列出共同的資訊觀點的潛在關係以增進其可讀性。 附件 2 提供一個完整的描述資訊觀點的樣板。 本方法論在資訊觀點中的表示，並沒有硬性規定在計算觀點或技術觀點必須提供存取的描述。 6.1 資訊觀點：本標準規定傳送網路管理資訊觀點的共同元件

30、，而共同資訊觀點所包含資訊物件的定義和關係則表示在傳送網路之一般功能架構資源，其與任何特定的管理服務無關，共同資訊的屬性和狀態也被規定。 對於管理特定應用資訊觀點的開發工作，共同性資訊觀點可以提供良好的基礎。 當需求被定義予特定的管理應用 (例如連接管理 )，它們被定義在企業社群，此相對應的管理應用特定資訊觀點隨後被開發，本標準傳送網路管理 -資訊觀點之共同元件從管理應用特定觀點的開發裡提供依據。 在共通資訊觀點中，管理應用特定資訊物件可以從此物件產生子類別，擴展它們以作為應用，從共通資訊觀點，在本案例，新的管理應用特定子類別可以包括其他屬性，額外增加的其他定義在它的父類別，額外增加的的關係和

31、屬性如果管理應用需要也可以產生新的物件，從 network Information Top 物件繼承而來，也能被增加。 如果屬性定義和現存的 GDMO 被管理物件模型的屬性是相容的，且參照到的這些屬性將是非正規性的被提供，在此案例，資訊觀點規範引進屬性的語義，而非語法 (哪些可以引進到相對應的計算觀點 )。 本標準被修改的通用關係模型 (GRM)樣板，它指示出多少物件彼此是有關聯的，每個 GRM 樣板在關係中定義角色和資訊物件，以便彼此可以扮演這些角色，在此共同資訊觀點規範裡，初始定義關係的資訊物件可以從物件描述的可能關係表列部分取走一部分的關係表列，對於管理特定應用的資訊觀點，當共同資訊觀點

32、物件是子類別時，針對應用做強制性的宣告是必要的。 本標準也包含共同屬性，當管理應用特定子類別被產出時，例如這些屬性包括運算狀態 (operation State)和使用者標記 (user Label)。 9 CNS 14648, X 1233 7. 計算觀點：計算觀點的概念定義於 RM-ODP 第三部份，旨在描述如何將系統分解成各個物件，藉由發生於物件介面間的交互作用，使系統易於達到分散的目的。在計算觀點中，應用系統是由彼此互動的物件組織而成，計算觀點下所定義的介面可規範其支援的最大分散程度，至於最後會在所謂開放 系統下展現出的實際分散狀況則取決於工程觀點時設計。另一方面，物件的計算規格乃藉由

33、物件的詳細介面、運算方式、以及發生行為加以定義，利用參數設定即可透過介面規格促使物件發生狀態變遷。 計算觀點的完整設計必須定義所有的計算物件、介面、以及運算方式，至於物件的定義 (相對於單純的介面 )則要考量到介面間的交互作用，以及所支援之介面的個數與型式，如此才能對相關的應用系統做出完整的描述。具多重介面的單一物件可以避免重複處理特定資源的狀態，如果有必要將物件介面加以分散，那麼該物件可能應該再分解成更細的計算物件。 計算觀點應詳載所有計算物件、介面、以及運算動作，茲說明如下： (1)計算物件 (Computational objects)乃針對特定的應用目的，根據資訊物件所定義的訊息衍生而

34、來，計算物件必須規定相關伺服端及客戶端的介面，加上該物件的行為 (例如介面間的限制條件 )。行為描述的部份可說明物件介面間的關係，也能描述當透過某些介面配合物件狀態而提供的特定服務時所扮演的角色。 (2)介面 (Interfaces)定義了可能發生於該介面的運算方式以及介面的行為，行為描述的部份可說明該介面提供的服務，同時也指定各運算動作間的發生順序。 (3)運算動作 (Operations)由運算簽章所定義，運算簽章的構成要素包括輸出入的參數、前置條件與後置條件、可能引發的例外狀況、以及描述運算動作的行為。運算動作也可能參考到定義於資訊物件中的資訊。 7.1 計算的概念 (1)計算物件乃透過

35、介面相互作用。 (2)計算物件可能擁有多重介面，和相同介面型式的多個案例 (instances)。 (3)某介面發生之運算動作所導致的系統狀態變化亦可於該物件之其他介面或其他物件的介面上觀察得到。 (4)介面間的交互作用一旦要標準化，那麼這些計算物件僅是針對特定應用系統加以設計。 (5)計算介面可能提供某些運算動作藉以觀察和處理被管理資源的相關資訊，這些資訊或許已經定義於資訊觀點中，而由運算動作的參數加以指明，其資料型式即是資訊觀點中所定義的資訊物件，而在計算觀點下，這些資料型式因應特定應用而集結起來，並可透過計算介面加以存取。 7.1.1 不涉及通信領域的計算觀點：從本方法立論要點來看，計算

36、觀點可分為兩部份：第一部份和基本工程環境或通信領域無關，另一部分則與工程觀點中使用的通信領域較有密切關係，請參考圖 2，如何描述與通信領域無關的方法定義於附件 3 中，本標準盡量不涉及應該在工程觀點才須要選擇的通信方法 (例如： CMIP/OSI、 CORBA 等等 )。 10 CNS 14648, X 1233 圖 2 各種通信領域規範 7.1.2 對應至與計算領域有關的計算觀點規範：定義於附件 3 的樣板必須轉換成工程實作時所使用的通信領域樣板，此處擬採部份之 ASN.1 語法作為運算動作參數的描述語法，這類抽象式的表示法勢必該於工程實作時轉變為通信領域採用的特定語法和協定，針對每個特定的

37、通信領域，此過程即可產出所謂的計算規範。 8.工程觀點 8.1 簡介：在 RM-ODP 中，工程規範是定義支援 ODP 系統功能分散性的基礎建設，分散透通是藉著組合 ODP 透通的功能和物件的假設作為基礎，此方法論起初就指定把工程程序用來針對兩個通信領域以達到功能分散的實作，包括 OSI 管理的使用，和 CORBA IDL 的使用及 ODP 功能，未來其他的通信領域 (基礎建設 )也可能被考慮，這些可供選擇的基礎建設在圖 2 說明。 8.2 工程概念： RM-ODP 的工程觀點提供機制，以支援計算觀點的透通性，在此計算規範協定和基礎建設是各自獨立的，工程觀點的立論在於特定的基礎建設和腳本的滿足

38、，在現階段介面業已選擇，亦已符合透通的需求。 如果在定義工程觀點期間，發現影響到其它觀點的額外需求，那麼企業、資訊和計算觀點則勢必要更新。 工程觀點必須說明所支持的腳本，腳本首先必須反映符合企業的需求並需要考慮介面的選擇結果，結合計算物件的決定，可能是迫於環境限制的結果，像是即時的需求 (例如兩個物件間互運的最大容忍時限 )。 第 9 節裡討論的以整體技術為基礎，來找出工程物件並且須符合企業需求和所指定腳本的環境限制，整體技術是適合用來定義符合企業需求的腳本。 計算物件的執行版本 (基本工程物件 )可能被組合成叢集以用來滿足整體的需求，叢集可以被視為基本建構區塊，用來做變遷、恢復、初始化和複製

39、，有如單一的實體。 ODP 叢集乃執行在實體系統上，叢集可提供客戶端和伺服端兩者間的介面，它藉著特定的協定連結和連繫來提供支援，儘管基本工程物件未必相同於被管理物件，但對映關係是存在的。 企業規範 資訊規範 不涉及通信領域的計算規範以其他分散式處理方法功能定義的 通信規範 以 CORBA IDL 和 ODP方法定義的 通信規範 以 OSI Management定義的通信規範 工程觀點 計算觀點 11 CNS 14648, X 1233 關係對映樣板 :只有當 GRM 關係對映樣板被定義時，關係的完整規範才會被指定，因為這些繫結 (binding)是特定的基礎建設，所以定義在工程觀點中。 8.3

40、 OSI 管理基礎的工程觀點：此子節只考慮以 OSI 管理基礎的實作和叢集， OSI管理資訊模型定義了座落在兩個不同的 OSI 系統間管理者和代理者之間的關係，計算規範在物件的實質分散上並無假設，但是工程規範必須在 TMN 的背景裡加以考量，把這些相互關聯的計算物件分成兩部份，每部份設置在各自的 OSI系統，在本案例，計算物件可能被集結成兩個叢集偕同計算介面，那些是需要顯露在外使成為從外部看得見的聯合叢集，如同 OSI 系統管理介面，如圖 3 所示。 圖 3 集結計算物件去定義 OSI 管理系統介面 8.3.1 資訊協定的衝突和計算觀點：工程和計算模型必須儘可能的各自獨立，且計算層級由於工程限

41、制將受到影響 (例如 SMI 的使用 )，結論是資訊觀點可能也需要把 SMI 的使用列入計算在內 (例如 GRM 關係對映到指標指示的被管Q1Q2Q3Q5G6Q4Q1Q3G6Q4T1521060-96計算規格對映OSI 系統管理模式系統 S1 系統 S2 12 CNS 14648, X 1233 理物件 )，這將允許從計算的運算動作對映到 CMISE 服務動作或屬性運算動作，資訊的發展是工程程序的一部份，在工程介面開發方面可從下述的認知，引導資訊模型的製作 : (1) 獨立的計算介面規範。 (2) 分散的需求。 (3) 通信能力 (例如 CMISE) 。 8.3.2 企業觀點的工程限制：管理服

42、務的分散橫越數個系統，如同與企業有關的工程限制的陳述 (例如定義管理介面到標準化的網路元件所組成的分散資源的抽象概念 )，在工程限制的企業規範裡，可能有不同腳本的描述，發生在不同的檔案和整體技術的組合中。 8.3.3 GDMO 封裝的使用和被管理物件：在工程層級方面使用 GDMO 來描述資訊，且規定在方法間作必要的選擇。 如同被管理物件資源 (傳輸或被管理資源 )可能被模型化，就上述所表示的實體透過所有的管理服務作處理。 模型化管理服務有兩種方式 : (1) 指定的管理服務也可能被模型化如同一個被管理物件，和聯結在一起的被管理資源所構成，此被管理資源源自於繼承被管理資源及管理服務類別兩者所組成

43、，本方式的結果是導致一個大數量的被管理物件類別，它是由定義在 RM-ODP 中不同的介面所構成 (尤其在動態繫結案例中 )。在被管理資源和管理服務兩者間組合指標的使用必須和介面構成的認知調和一致 ;不過本方式的結果是導致一個大數量的指標的使用。 (2) 指定的管理服務也可能被模型化如同一個封裝，和聯結在一起的被管理資源所構成，此被管理資源是由透過所包含的一些封裝像是在被管理物件類別裡反映資源的條件封裝所組成，本方式必須與事先定義好的工程函式庫調和一致，此函式庫將包含表示傳輸資源的被管理物件 (那是相當於共同資訊觀點的資訊物件 )，針對每一個被管理物件，封裝本身有潛在的被支援服務的能力，這將可避

44、免重寫及提供更同質的系統視野。 注意相同型式多個的實例可能被定義在計算觀點中，在這個案例使用GDMO 封裝是不適當的。 8.3.4 在工程介面的多重管理服務支援：封裝可能 彼此間完全獨立，在這個案例，當工程介面逐一規定對應的服務時封裝可能獨立的包含在被管理物件中，然而某些封裝可能呈現依存的狀態，在這個案例最好的方式是定義一個組合封裝，但在這個案例相對應的組合服務必須定義 (依存關係被表示在企業、資訊和計算觀點中 )，另外，某些封裝在被管理物件中必須是唯一的，這必須在被管理物件行為說明中有所陳述。 8.3.5 識別：依照 RM-ODP，必須定義可供參考的計算介面 (例如關於繫結 )，計算介面可以

45、對映到封裝，如被要求的封裝在同時間支援被管理物件，則此被要求的封裝將被列舉說明，唯一的工程參考將被製作到被管理物件，工程參考可以與任何資訊無關，且還提出一個只有工程系統才能辨別和支援的政策基礎，屬性被定義後則此屬性帶有識別 :實例識別。 13 CNS 14648, X 1233 8.3.6 關係對映：在工程觀點裡 GRM 關係將對映到 ROLE BINDING 樣板，這描述在指標、名稱繫結、運算動作或繼承項目裡。 8.3.7 在關係和狀態修正方面，動作屬性運算動作的使用： CMISE 允許運用兩種方式去修改系統狀態 : (1) REPLACE 使用在屬性上的運算動作 ; (2) 動作。 動作將

46、被使用在當牽涉到多重屬性，和此運算動作考慮連續不可中斷的或如果是重要的行為的需求，如果只有一個屬性被修改和有一個需要提供屬性讀取功能，那麼一個 REPLACE 運算動作可能被指定。 8.4 分散式處理環境 8.4.1 總覽 分散式處理環境 (DPE)的使用需進一步研究，其考慮點如下 : (1) 因為存在很多的實作選擇 (例如 OSI、 CORBA、 DCE 為基礎之 DPEs)，工程模組的組合必需使用共同的分散處理環境，且允許這些領域互相影響。 (2) 本地的名稱形式、協定和可靠性綱要可以使用在每個領域範圍內 ;無論如何，一組用於相互運作之共通支援服務是必需的。 (3) 基本工程物件可以透過連

47、結和協定物件來支援，藉著各種不同的協定促進被選擇物件的相互運作。 同樣的對於分散處理環境使用在傳輸網路管理應用也須要定義 透通性需求。 9. 整體技術在網路管理應用定義上的用法 9.1 範圍：此標準的方法論針對企業、資訊、計算觀點產生特定的應用規範，這些觀點主要與分散基礎建設有關，整體技術定義了技術的解決方式藉以滿足特定的應用腳本，這在圖 4 說明。 14 CNS 14648, X 1233 圖 4 整體技術的使用所產出的應用特定介面 整體技術定義一特定系列管理應用組合 (就企業社群的觀點 )並且伴隨著其他實作限制，像是被提供的分散等級，可看見的層級和介面協定。 整體技術不是任何 RM-ODP

48、 觀點的一部份，但是參考企業、資訊、計算和工程觀點來解決開發以滿足一系列企業社群的需求，整體技術是一個指引，主要是利用 RM-ODP 觀點的資料以解決特定的管理問題，也就是從工程介面規範的觀念來指定管理功能特定的分散性，以提供一個特定的解決方式，在工程觀點裡一致性的符合將會被測試。 整體技術的樣板定義在附件 6。 引用標準 : CNS_(ITU-T G.851.1) 傳送網路管理 _RM-ODP 架構之應用 CNS_(ITU-T G.852.1) 傳送網路管理 企業觀點 簡易子網路連接管理 CNS_(ITU-T G.853.1) 傳送網路管理 資訊觀點之共同元件 相對應國際標準 : ITU-T

49、 G.851.1(1996), Management of the transport network-Application of the RM-ODP framework T1521070-9MIB企業資訊計算工程微小的共同體組成的共同體一般的函式庫CIV計算介面整體 15 CNS 14648, X 1233 相關標準 : CNS_(ITU-T X.901 | ISO/IEC 10746-1, Information technology Basic reference model of open distributed processing: Overview.) CNS_(ITU-T X.902 (1995) | ISO/IEC 10746-2:1996, Information technology Open Distributed Processing Reference Model: Foundations.) CNS_(ITU-T X.903 (1995) | ISO/IEC 10746-3:1996, Information technology Ope