第四章、 服務導向之整合環境
第五節 服務註冊
為了讓分散網路的服務能夠被更有效地利用，我們將具有一個集中管理服務 資訊的地方，稱為Domain。本架構下的Domain與目前標準的Web Service架構中 的UDDI具有類似的功能，希望提供一組標準的規範用於描述和發現服務，使得 不同的使用者或組織單位可以經由一套適應性強的服務描述，描述服務的相關訊 息。本架構是以XML為標準，將所有的資訊都以XML的格式加以描述，特定的 資訊必需符合系統規格，而Domain是將各個服務藉由服務實體 (Service Instance) 與服務型態 (Service Type) 這兩項資訊加以管理。服務實體中描述了服務的名 稱、位址、以及相關設定，當使用端3與Domain要求服務時，Domain就會將服務 實體透過XML溝通協定傳送給使用端，使用端即可利用XML中所描述的資訊直 接與該服務溝通，不需再以Domain做為媒介。服務型態Domain用來將不同的服 務做適當的分類，使得使用端可以依型態選擇適當的服務，此外，不同型態的服 務具有不一樣的輸入和輸出介面，這些資訊將會被描述在說明文件中 (圖 11)，
讓使用者可以依照設明文件定義的XML介面，正確的使用服務。透過服務型態 的分類以及服務型態介面的定義與描述，使用端可以定義彈性化的規則，例如：
尋找特定型態的服務，使得使用端所使用的服務不侷限於特定服務實體，且因為 型態相同，所以可接受的輸入和輸出介面也相同，因此使用端不用更改程式就可 以因改變使用不同的服務，而提供不一樣的效能或結果。
3 使用端：因為使用服務的不一定為客戶端，有時為另一個服務，所以統稱為使用端。
圖 11 Domain 架構與 Host 之關係圖
圖 12 Domain 瀏覽員。圖中指定了 odex / data / DataService 這個型態的服務，右邊顯示了此型 態的服務所提供的 XML 介面。
當服務要跟 Domain 註冊時，必須將提供服務實體給 Domain 管理，服務實 體中會描述服務型態，若 Domain 不具有該型態，則必需新增一個服務型態，且 最好適當的撰寫說明文件，以便讓以後使用者可以清楚的了解服務的功能以及與 其使用的方式。
第六節 以規則為基礎的組合模式
除了經由使用者設定達到服務整合的功能，透過進階的規則設定，則可以提 供更有彈性的整合。藉由向規則驅動引擎提出要求，規則驅動引擎會依使用者定 義的規則，做出適當的回應，如此就可以獲得其他服務的資訊，進而互相溝通傳
規則驅動引擎為 ODEX 重要的元件之一，因為 ODEX 的操作模式都將視規 則驅動引擎判斷輸出，使用者可依個人的需求，撰寫符合個人需求的規則，當然 若不需要 ODEX 來幫助導覽資料時，也可以完全不使用規則驅動引擎的功能，
系統依然可以正常運作。所以規則驅動引擎主要的功能就是比對輸入的指令，交 給適當的 Rule Set 處理，找出符合的規則並處理輸入然後回傳結果，若沒有符合 的規則，則不做任何事。所以規則驅動引擎做的事情非常簡單，它完全是依照使 用者撰寫的 Rule Sets 反應，也不知道規則本身代表什麼意思，僅僅只是輸入/輸 出的機制。
舉例來說，如下頁圖 13，一開始服務會向規則驅動引擎要求另一個脈絡服 務，而此脈絡服務必需符合特定的型態，此時規則驅動引擎的工作就是找出適當 的服務並回應給需求端。此時規則驅動引擎會藉由詢問 Domain 的方式尋找符合 條件的服務，當然 Domain 的基本功能就是可以藉由型態來查尋服務實體。此時 Domain 就會將服務實體的資訊傳回給規則驅動引擎，規則驅動引擎再將此資訊 經過簡單的轉譯，再回應給需求端的服務，該服務就可以利用所獲得的服務實體 資訊直接使用另一個服務。
圖 13 規則基礎組合機制流程圖