第三章 研究方法
3.3 Service Requester
為一個提出服務要求之實體，當 Client 需要服務時，將其服務需求訊息 依照相關格式傳送 Request Message 至 Extended Registry，而 Extended Registry 會先搜尋 Category List 後將 Request Message 轉送至 Service Provider，
則 Service Provider 接收到 Request Message 後會進行服務配對，而 Client 會等待 Service Provider 提供服務調用資訊，當有多個 Service Provider 符合 服務需求條件時，Client 會優先與第一個傳送服務調用資訊的 Service Provider 來進行服務需求處理與協商，如圖 10 所示。
19
Send Request Message
Search Category list
Match for Suitability
Client :Extended Registry
:Service Provider
Transfer Request Message
Negotiate Deliver Service
20
3.4.1 Message Stanza
Message Stanza 是使用 Push 的機制進行用戶之間的訊息傳遞，當發送 者送出訊息時，則不理會接收者是否收到，若是接收的用戶離線，則可將 訊息存放至 XMPP Server 端，等待用戶上線再進行傳送，圖 11 為 Message Stanza 之示意圖。在 Message Stanza 當中 to 屬性為此訊息的接收方、from 為此訊息的發送方、<body>則是此訊息的主要內容。而在 Message Stanza 中 type 屬性有以下五種值，分別為:
1. Normal:為一種類似郵件的訊息，可能會有回應，也可能沒有。
2. Chat: 此類型的訊息則為實體之間的訊息交換，如即時通訊的私人聊天 對話。
3. Groupchat: 此類型則使用於多個實體的訊息交換，如即時通訊的群體 聊天。
4. Headline: headline 則用於發送提醒與通知，通常用於自動通知服務，並 不需要回應。
5. Error: 發送的訊息發生錯誤時，則會反饋錯誤訊息。
圖 11 Message Stanza
21
3.4.2 Presence Stanza
Presence Stanza 為用來控制與表示實體的當前狀態，如 online、away、
dnd 等狀態，透過 Presence Stanza 使用者可得知其他聯絡人目前的狀態，也 可也可用來進行廣播、訂閱等動作，如圖 12 所示。屬性<status>為顯示是 狀態列的額外訊息、而在 Presence Stanza 中 show 屬性有以下四種值，分 別為:
1. Away:表示用戶為離線狀態。
2. Char:表示用戶目前正在進行交談。
3. Dnd:表示用戶目前不希望被打擾。
4. Xa:表示用戶為離開狀態。
圖 12 Presence Stanza
3.4.3 Iq Stanza
Iq Stanza 為 Info/Query 模式，有 request 與 response 機制，使實體之間 可以發送要求與接收回應，如圖 13 所示，要求的類型有 get 與 set，回應 的類型則有 result 與 error。實體之間可透過 get 與 set 進行請求，當請求成
22
功則會接收到一個 result 類型的訊息，若發生錯誤則會反饋錯誤訊息。
而在 iq Stanza 中 type 屬性有以下四種值，分別為:
1. Get:獲取所要求之值。
2. Set:進行值的設置或替換。
3. Result:回應 request 訊息。
4. Error:若進行 get 或 set 時出現錯誤則會反饋錯誤訊息至 request 者。
圖 13 iq Stanza
3.4.4 Jabber ID 格式
Jabber ID(JID)為 XMPP 架構中，用戶的實體地址，各用戶的 JID 具有 唯 一 性 ， 用 戶 之 間 可 透 過 JID 相 互 溝 通 ， JID 的 格 式 為 : node@domain/resource，與電子郵件的格式類似，以下將說明 JID 格式中 node、
domain、resource 三種元素所代表的意義。
1. Node:為一識別用戶的名稱，通常為用戶自行去 server 端進行註冊申 請。
23
2. Domain: 為伺服器的位址或名稱，若有一用戶 client1 要在伺服器名稱 為 host 的伺服器進行註冊，則此用戶的 JID 為: client1@host。此一用戶可 透過 JID 與其他用戶和伺服器進行溝通。
3. Resource:為用戶在登入伺服器時，所使用之客戶端資源，資源只用來 識別用戶設備，一個用戶可同時使用不同的資源與同一 XMPP 伺服器連
24
圖 14 節點搜尋訊息格式
圖 15 回應訊息格式
得到節點訊息後則開始進行訊息的傳送，再傳送訊息的規格方面同樣 使用 iq 訊息，下圖 16 圖 17 為服務的要求與回應的格式。
25
圖 16 Requesting entity sends IQ-set
圖 17 Responding entity returns IQ-result
26
而對於 WSDL，要支援 SOAP over XMPP 則必須要進行轉換格式使 XMPP 能夠理解 WSDL，下圖 18 為 WSDL 轉換例子。
圖 18 Example of WSDL definition for a translation service that supports SOAP over XMPP
若當傳送過程中發生錯誤時，XEP-0072 有定義了錯誤的尋找表格，若 發生錯誤則可利用此表格來尋找錯誤訊息為何意，錯誤訊息定義如下表 1。
表 1 Mapping of SOAP Faults to HTTP Status Codes and XMPP Error Conditions
27
透過以上方法，XMPP 即可與原始 SOA 架構進行溝通，以達到架構之 相容性。
在此我們透過了 XMPP 各種不同格式之訊息使 Service Provider 與 Client 之間的溝通機制能夠更加完善，除了服務調用訊息外，還可進行更細 節的溝通。
28
第四章 系統架構與實作
本章節主要說明實作的系統架構與使用的軟體與相關技術。在實作架 構上如圖 19 所示，在 Extended Registry 的實作面上由於 Openfire 使用 Java 開發的開放原始碼之即時通訊伺服器軟體，並且使用 XMPP 通訊協議，除 此之外 Openfire 可以透過 web 介面管理伺服器，如圖 20 所示，除了有內 建資料庫，也可與 Mysql 進行連結。而在 Extended Registry 中功能的實現 可利用 Openfire 上的插件(Plugin)系統來進行功能的開發，且可在 web 介面 來進行插件的安裝與卸載，如圖 21 所示，因此我們在實作開發 Extended Registry 時，使用了 Openfire Server。而在 Client 與 Service Provider 兩端則 是使用了 Smack API 來進行開發，Smack 為基於 JAVA 程式語言之 XMPP 用戶端函式庫，在研究中利用 Smack 函式庫來與 Openfire 伺服器進行溝通，
並且註冊所需之 JID 於 Openfire 伺服器之上。詳細之插件實作方法、用戶 端開發、系統運作流程將於下面章節詳細說明。
29
Service Match Maker
Client
Openfire Server
Service Provider
Registry Dispatch Request
30
圖 21 Openfire Plugin web 管理介面
在系統實作架構圖中可看到，本文利用開發插件方式來實現服務分類與 訊息之轉送，以下將對插件做詳細說明。
4.1 插件系統
在 Openfire 中，伺服器本身只提供即時通訊系統基本的功能(註冊 JID、
接收/發送訊息等等)額外的功能則靠插件補足，由於提出之方法中 Extended
Registry 需要擁有服務分類、辨別訊息等等功能，因此所提出之研究方法則 以插件方式進行實作，而在 Openfire Server 中若是想要建置插件則需要先 進行配置動作，此一配置動作代表了再安裝插件至 Openfire Server 中進行 初使話與卸載之動作，相關的程式示意圖如圖 22 所示。以下將會詳細說明 插件功能與在整體架構中分別負責的位子。
31
圖 22 配置訊息攔截器
4.1.1 Message Interceptor
訊息攔截器(Interceptor) 是用來攔截所有通過此一註冊端的訊息並用 來判別各訊息所代表的意義，配置完成之後則可以進行訊息的篩選，並利 用方法在各種不同類型的訊息之間找出我們想要的訊息。相關的程式示意 圖如圖 23 所示。
當有訊息進入 Openfire Server 時，攔截器會攔截符合攔截條件之訊息格 式的訊息進行攔截，攔截到後則讀取內容，若為服務要求訊息則進行內容 的讀取，並將要求條件送至服務分類進行搜尋。
32
圖 23 攔截器程式示意圖
4.1.2 Service category
服務分類(Service category)在實作方面使用了 Group 作為實現的方法，
服務提供者在註冊 UID 後，查詢是否有以存在之 Group，若有存在之 Group 則加入此 Group 完成服務分類，若無符合之 Group 則自行創建一 Group，
Group 之示意圖如圖 24 所示。
圖 24 服務分類示意圖
33
4.1.3 Query Transfer
訊息轉送(Query Transfer)則是將訊息攔截器處理完之訊息配合相對應的
Group名單進行訊息的重新封裝並發送訊息。相關示意圖如圖 25所示。
當服務攔截器處理完服務請求訊息後，會將符合的服務分類清單、服務 要求者之JID、服務要求條件送至此處進行服務的封裝，並進行轉送。
圖 25 訊息轉送示意圖 4.2 用戶端開發
在本節中，將介紹 Client 與 Service Provider 所使用的實作方法與如何 跟 Openfire Server 進行溝通。
34
4.2.1 JID 註冊
實作方面，Client與Service Provider在架構中皆需要與Openfire Server進 行溝通，而要與Openfire Server則Client與Service Provider各自都要擁有一個 屬於自己的JID，因此要進行服務要求或註冊時，第一個步驟為註冊UID，
相關之服務註冊程式碼如圖 26所示。圖中之ConnectionConfiguration()為在 與Openfire Server進行連線時需要確定Server之位址與開放的Port，之後則使 用connection()進行連線。
當 連 線 建 立 後 ， 即 可 進 行 JID 的 註 冊 ， 在 Smack Library 中 可 使 用 AccountManager進行createAccount()的動作。
圖 26 JID 註冊
35
4.2.2 訊息發送/接收
當用戶登入帳號後，即可進行訊息的發送與接收，而在接收與發送訊 息上，在此使用了 MessageListener 來進行訊息的監聽，透過 MessageListener，
接收到的訊息皆可在 processMessage 中依照訊息的種類來進行處理，如圖 27、圖 28 所示。
圖 27 訊息接收
圖 28 訊息發送
36
Send Request Message
Search Groups
Match for Suitability
Client :Message
Interceptor
:Query transfer
:Service Provider
Transfer Request Message Message Transfer
Negotiate
Deliver Service
37
圖 30 JID 示意圖
當服務需求者擁有個人 JID 後，即可發送服務需求訊息至 Server 端，而 Server 端之訊息攔截器插件會將此一訊息攔下，並將訊息中的服務需求條件 取出，並搜尋符合此一條件之 Group，若無此服務則回傳無服務訊息，若有 符合條件之 Group 則將服務需求者之 JID 與需求條件轉送至 Group 中所有 JID，示意圖如圖 31 所示。
圖 31 服務需求訊息轉送之循序圖
38
當服務提供者接收到 server 端所傳送之訊息後，會使用包含在訊息中的 服務需求條件進行服務配對，在此使用關鍵字的方式來進行配對，若配對成 功則開始處理服務，並回傳結果至服務需求者端，完成服務要求。
39 Openfire Server 作為架構中 Extended Registry，另外 Computer2 為 Client、
Computer3 則為 Service Provider，詳細之規格如表 2 所示。
表 2 實驗硬體規格表
5.3 實驗方法
在此分為了兩組進行實驗的比對一組為 Extended SOA 組而另一組為 SOA based on XMPP 組。在 Extended SOA 與 SOA based on XMPP 中 Registry 端使用了 Openfire Server 做為實作，而在 Client 與 Service Provider 使用了 Smack 來進行登入伺服器與傳輸訊息之動作。以 10 個 Client 做為一組進行 一次測試，每個 Client 間隔 500ms 發送一次服務需求訊息至 Openfire Server，
Computer1 Computer2 Computer3
CPU AMD PhenomII X6 1045T Processor 2.70GHz Intel Core i7 CPU 870 2.93GHz 2.93GHz Intel Core i7 CPU 870 2.93GHz 2.93GHz
Memory 8GB DDR2 6GB DDR2 4GB DDR2
OS Windows Win7 64Bit Windows Win7 64Bit Windows Win7 32bit
40
再由 Openfire Server 經過處理後轉送至 Service Provider 端，最後將結果回 傳至 Client 完成一次服務要求，一次實驗持續一分鐘，接著再增加一組 Client 進行實驗直到 10 組為止，兩組實驗不同的地方為 SOA based on XMPP 是依 照 SOA 架構由 UDDI 進行服務的配對，而 Extended SOA 為將服務配對分 散至 Service Provider 端。進行測試的項目有:平均回應時間、CPU 使用率、
IO Read/Write。
5.4 實驗結果
從架構面來看，相較於原始 SOA 架構中負載集中於 UDDI，本文提出
從架構面來看，相較於原始 SOA 架構中負載集中於 UDDI，本文提出