以 XML 技術為基礎的模擬系統 - RSIP H 模擬系統實作 - 家庭網路的相關議題與解決方案

5.5 RSIP H 模擬系統實作

5.5.1 以 XML 技術為基礎的模擬系統

RSIP^H是一種網路位址轉換機制，必須記錄一些參數以維持位址轉換機制的正常運作，而在本文之前的章節裡也已描述，為解決RSIP^H在執行時可能發生的混亂現象，若干必要的資訊也需要在連線期間被額外地記錄下來，因此，在實作模擬系統時，資料存取的方式自然是設計系統時的關鍵考量；再加上，本文在第四章以XML技術定義被管理物件，因此，本模擬系統以XML技術作為資料收集技術，

並不考慮X.500目錄（directory）結構或其他資料庫管理系統，因為，XML具備以下好處：

1. 較小的儲存需求：因為XML文件是包含結構化資訊的文字型態檔案，只需要少量的儲存空間。

2. 容易維護：因為XML Schema是包含邏輯結構的文字型態文件，使得動態修改結構以符合新的資訊家電規格變得更加容易，所以，XML schema的使用很適合應付快速改變的資訊家電產業。

3. 支援多樣的顯示需求：Extensible style-sheet language（XSL）提供多種顯示樣版（templates），使得擁有不同顯示規格的設備（如：PDA、行動電話、車用電腦…等）能存取相同的XML文件。

5.5.1.1 XML Schema 設計

本文在實作上為RSIP^H定義了四個XML Schemas。表5-1至表5-4分別定義了 RG、RM、MIA以及RSIP^H參數的XML Schema，表5-1描述RG的XML Schema，表 5-2描述RM的XML Schema，表5-3描述MIA的XML Schema，而表5-4描述專門記錄 RSIP^H參數的XML Schema，其中包括三個專門用來解決RSIP^H混亂現象的擴充標記

（tags），RG根據這四種Schemas來產生必要的XML文件，而HAN裡任一設備的所有屬性都被儲存在由其所屬的XML Schema（RG、RM或MIA）所產生的相對應XML 文件裡，而這些產生出來的XML 文件紀錄著設備的必備資訊，例如： Home_Name、RM_Name、MIA_Name、Description…等。將這些XML文件整合起來，則可視為註冊資訊庫，至於參考RSIP^H參數的XML Schema所產生的XML文件則是用在支援RSIP^H連線。除此之外，正如本文第四章所描述的，RG提供WWW服務，當網際網路上的主機試圖連結MIA（如：數位電視）時，WWW服務機制必須提供以XML為基礎的網頁，使得身處遠端主機的使用者能透過點選適當而具有意

義的名稱識別（例如：設備的MIA_Name）來進行遠端操作與管理。換句話說，藉由瀏覽器的使用，遠端操作與管理的需求能在名稱-設備對應（name-device mapping）機制的輔助下正確傳送至目的MIA。

除了第四個XML Schema外，RG、RM與MIA三個XML Schema是設計來建構所有家用設備的屬性結構，並藉以支援名稱-設備對應機制。家庭網路的成員能在登入HAN後以存取相對應的XML文件中的標記內容來進行遠端操作與管理，因為一般人為了容易記憶，在指定或描述事物時通常使用慣用名稱或措辭（例如：

DeviceName、PhoneNumber、Location…等），所以，在存取家用設備的屬性時，

在考慮易讀性的情形下，以慣用名稱或措辭作為標記名稱是合理的。一般來說，

慣用名稱或措辭的命名完全取決於使用人，所以，慣用名稱或措辭的使用會出現衝突現象是必然的結果，再加上XML文件的產生是依據XML Schema，參考同一個 XML Schema所產生的不同的XML文件自然會包含相同的標記名稱，例如：所有的 RM都會有一個共同的標記名稱（RM_ID）來記錄個別RM的識別碼。為了解決這種矛盾問題，我們使用XML技術裡的命名空間（Namespaces）機制[63]迫使標記在真正被引用時具有唯一性。

XML 的命名空間是 W3C 在 1999 年 1 月提出，大約是 XML 1.0 版規格定案一年之後才完成。這個規格定義在一個XML 文件中併用好幾個 XML 應用規格或 DTD 的機制。這個機制具有兩項優點：

1. 可合併使用多個標準的標記語彙：可以在一個 XML 文件中直接使用其他 XML 應用規格所定義的標示語彙，而不用自行發明新的標示語彙。在發展 XML 應用系統時，許多元素已經在其他行之多年的應用規格中定義了。引用這些規格，可以節省研發的時程，也可與標準同步。

2. 使系統設計模組化：在 XML 應用系統中呼叫已設計好的各個 XML 應用規格的軟體模組，而不需自行撰寫該功能。

一份XML 應用規格或 DTD 中所定義的所有的標籤及屬性的集合，稱之為「標記語彙」（Markup Vocabulary）。當混用多個標記語彙時，會產生下列兩項問題：

1. 名稱重複：來自不同的標示語彙，可能發生標籤或屬性名稱相同而無法區別的困境。

2. 軟體不易處理：軟體系統不易區別各個標籤及屬性來自哪個標記語彙。

命名空間這份規格的解決方案就是，簡單地以參引（reference）到 URI 的前置字串（prefix）加在各個標籤及屬性名稱之前的方式，明確地指定（qualify）其

URI（Uniform Resource Identifier）資源識別字串，是用於在網路環境中識別文件、可供下載的檔案、各式服務及電子郵箱等等的各式資源。URI 是 URL 及 URN 的超集合（superset），也就是除了 URL 及 URN 的資源定址方法之外，還提供容納新定址方式的可能性。URL（Uniform Resource Locator）為網址，是個已定義好的格式，用於讀取目前網路上的各式資源，例如：http:、ftp:、gopher:、news:

及mailto:等通訊協定的資源。URN（Uniform Resource Name）是任何一個機構所承諾，永久有效的資源名稱，它使用 urn:的機制標明某一項資源。這個資源並不一定實際在網路上存在，而是一本實體的書籍。是實體的資源，也並不一定存在，

例如：已經失落或是尚未出版的書籍。但是這個 URN 值確切地標明是某本書。

目前URN 在網路上並沒有一個普遍使用的機制可以轉換為 URL 值，以便讀取該資源。

W3C 在多年前已在各個規格中以 URI 取代 URL 來表示資源地址了。在每個 XML 應用規格中，都會定義其 Namespace 的 URI 值。每個規格都有個獨一無二 Namespace 的 URI 值，即使是同個規格的不同版本也會有不同的 URI 值。

XML技術正漸漸在產官學界普及應用，可以預見的是，在不久的將來，許多產業組織將會為其需要定義XML標記語彙，並為標記語彙的命名空間定義眾所周知（well-known）的URIs，方便其領域裡XML的應用。不過，目前在資訊家電產業裡還沒有定義出特定的標記語彙的XML命名空間，而為了本模擬系統的實作，

我們暫時先定義了一些URI樣本來使用。

表5-1 RG 的 XML Schema

……

<ElementType name=”RG_ID” dt:type=”Id”/> <!--The identifier of RG

<ElementType name=”Home_Name” dt:type=”String”/> <!--The common name of HAN

<ElementType name=”IP_Address” dt:type=”Uri”/> <!--The public IP address of HAN

<ElementType name=”Manager” dt:type=”Id”/> <!--The manager of RG

<ElementType name=”Telephone” dt:type=”String”/> <!--The telephone number of HAN

<ElementType name=”Location” dt:type=”String”/> <!--The location address of HAN

<ElementType name=”Description” dt:type=”String”/> <!--The related description of RG

<ElementType name=”RM”/> <!--The RMs of RG

……

</Schema>

表5-2 RM 的 XML Schema

……

<ElementType name=”RM_ID” dt:type=”Id”/> <!--The identifier of RM

<ElementType name=”RM_Name” dt:type=”String”/> <!--The common name of RM

<ElementType name=”Owner” dt:type=”String”/> <!--The owner of RG, the default owner is RG

<ElementType name=”PrivateAddress” dt:type=”Uri”/> <!--The private address of RM

<ElementType name=”Description” dt:type=”String”/> <!--The related description of RM

<ElementType name=”MIA”/> <!--The MIAs of RM

……

</Schema>

表5-3 MIA 的 XML Schema

……

<ElementType name=”MIA_ID” dt:type=”Id”/> <!--The identifier of MIA

<ElementType name=”MIA_Name” dt:type=”String”/> <!--The common name of MIA

<ElementType name=”Owner” dt:type=”String”/> <!--The owner of MIA

<ElementType name=”PrivateAddress” dt:type=”Uri”/> <!--The private address of MIA

<ElementType name=”Description” dt:type=”String”/> <!--The related description of MIA

……

</Schema>

表5-4 RSIP^H參數的XML Schema

……

<ElementType name=”LeasedAddress” dt:type=”Int”/> <!-- The address given by RSIP gateway

<ElementType name=”LeasedPort” dt:type=”Int”/> <!--The port number given by RSIP gateway

<ElementType name=”ICMP_ID” dt:type=”Id”/> <!--The ICMP identifier

<ElementType name=”FragIP_ID” dt:type=”Id”/> <!--The Fragmentation identifier

<ElementType name=”LeaseTime” dt:type=”Time”/> <!--The leased time duration for each RSIP

<ElementType name=”TupleState” dt:type=”String”/> <!--The state of RSIP tuple

……

</Schema>

利用前三種XML Schema所產生的XML文件能解決第四種混亂現象的第二個問題，因為文件裡的標記能視為註冊資訊的邏輯結構，而所有的標記內容正好形成完整的註冊資訊庫。至於其他RSIP^H混亂現象的解決，就必須使用下述定義在 XML Schema裡的標記：

1. PrivateAddress(原有的)：定義在RM與MIA的XML schema裡，這個標記被用來 紀錄每一個RSIP^H主機的私有IP位址，這個標記所組成的內容集合可被視為一張完整的位址列表，有助於避免第五種混亂現象。

2. LeasedPort(原有的)：定義在RSIP^H參數的XML schema裡，這個標記被用來紀

4. FragIP_ID(新定義的)：定義在RSIP^H參數的XML schema裡，這個標記被用來紀錄進行fragmentation時的IP identifier，這個標記被用來解決第三種混亂現象。

5. TupleState(新定義的)：定義在RSIP^H參數的XML schema裡，這個標記被用來紀錄已被指定給RSIP^H主機使用的位址埠號組合的使用狀態（state），這個標記被用來解決第一種混亂現象。

在文檔中家庭網路的相關議題與解決方案 (頁 44-48)