Using Web Services for supporting the users of wireless devices T Using Web Services for supporting the users of wireless devices T. Pilioura*, S. Hadjiefthymiades, A. Tsalgatidou, M. Spanoudakis Available online 27 June 2005 授課老師：林娟娟 教授 報告人 98756015 劉昌武 98756017 尹中文

Abstract 摘要 這編文章主要是在描述無線設備裡使用Web Service，並且提出所擁有的優勢以及所支援的技術。 第?章會再進一步介紹Web Services應用上的參考建議，最後會利用實驗所產生的數據作出評據。

Agenda Introduction Motivation Web Services technology and the wireless world 傳統遠端method call Scenarios of using WS in wireless devices Building blocks for using WS in wireless devices Experiments on the wireless WS provider scenario Summary and conclusions

1： Introduction Wireless carriers offer services that allow information such as weather, stock quotes, news…updates to be pushed to wireless terminals Wireless Communications and Web Service = computing at the edge WS technical considerations need to take into account issues like cost, temporary unavailability like outages, performance related issues 1.目前我們正目睹無線服務的爆炸，無線服務將生活/工作的資訊都不斷的push到你的無線設備裡 2.在生活中到處都是無線的應用，例如：A-GPRS、MMS、Nissan tobe、股票機甚至流通業、物流業都在充分的利用這樣的技術 3.將行動網路的通訊以及網路上的各種服務整合後，我們就已準備好讓服務供需的兩方在網路上進行溝通了~ 4.這麼好的解決方案，當然也會有issue。開發、維運的成本、客戶心中理想的費用、斷線停機時如何處理、效能相關的問題

2： Motivation The marketplace may be supported by either a centralised or a decentralised architecture Centralised architecture：eBay Decentralised architecture：商店街 動機 以前，我們需要跨出家門，到賣場、商店裡去挑選我們要的東西。但現在因為網路;而造就了”宅”經濟，人們可以在家裡休閒的點著 滑鼠去選購服飾、3C、食品，再用網銀匯款，最後由快遞送到你家。這種marketplace我們可分為集中式，以及非集中式架構。 實務化的說法，就是傳統市場以及生機門市

2.1：Scenario No single point of failure Better distribution of work Instant notification of the seller regarding the auction status Sellers’autonomy in the provided functionality 我們以非集中式架構來討論，對我們有什麼益處 會有更強的銷售管道、賣方可以更即時的回應、賣方對於平台的自主性更高

2.2：Requirements 客戶 賣家 使用網路進行搜尋 可追蹤產品，並且收到相關訊息 可以設定底價 可將該產品的價格變動通知客戶 需要知道買家交易、送貨資訊 為了要達成上述的scenario，我們必需達到下列的需求 會有更強的銷售管道、賣方可以更即時的回應、賣方對於平台的自主性更高

2.3：Developers’Requirements Easy and fast deployment Interoperability 開發人員的需求 1.容易和快速的部署程式 2.互用性：開發者不用知道作業系統，發展環境和技術上的應用

2.3：End-users’Requirements Dynamic selection of services Quick response Disconnected operation

3：Web Service technology and the wireless world This model allows the publishing of business functions to the Web and enables universal access to these functions. WSDL：Web Service Description Language UDDI： Universal Description, Discovery, Integraton SOAP：Simple Object Access Protocol

3.1：WSDL XML為基礎 讓 Services應用程式能以一種標準方法來描述自己擁有那些能力，以便讓互動更容易進行 例如：Java匯入一個新的Class後，我們能否藉由Web Services把遠端執行的程式、函示等，當成Local端的來執行，關鍵就在於WSDL，必須要有WSDL，Web Services才可以啟動 WSDL主要是描述Web Services的細節，也是使用XML格式之語言， 讓Web Services應用程式能以一種標準方法來描述自己擁有哪些能 力，以便讓互動更容易進行。例如：Java匯入一個新的Class，也就 是說我們能否藉由Web Services把遠端執行的程式、函示等當成Local 端的來執行，關鍵就在於WSDL，必須要有WSDL，Web Services才可 以啟動。所以想要瞭解Web Services，第一步就是先好好瞭解WSDL 的定義、目的以及結構等。 如果我們對上述WSDL項目瞭若指掌的話，我們就可以快速地在別 人已經完成的Web Services裡，藉由對WSDL結構的瞭解，快速設計 出我們自己的Web Services，有關分析工具，將在後面的內容中說 明。

3.2：UDDI XML為基礎 其主要的目的為提供Web Services的提供者，透過 UDDI告知其他人，提供者有提供Web Services 因此UDDI的功能也就類似電話簿目的就是要快速告知服務使用者他可以利用的Web Services有哪些 SOAP指的是一種提供給Web Services以XML製作出來的通訊協定， 目前版本是1.2，就像是打電話必須通過電話線或是無線基地台等， 其目的就是讓應用程式與應用程式能相互溝通，但不需要知道彼此 的作業平台是那一種或是各自如何實作等細節資訊。例如：E-mail 是藉由SMTP的標準傳送資料，在一封E-mail中，除了文字以外，也 定義了SMTP的協定內容，如此欲將封包傳送出去時，必須是SMTP協 定看得懂的格式，才能夠傳送。SOAP的概念也是如此，其XML架構如 【圖二】所示，相關參考資料詳見【註九】。

3.3：SOAP XML為基礎 提供給Web Services的通訊協定，目前版本是1.2 像是打電話必須通過電話線或是無線基地台等等，其目的就是讓應用程式與應用程式能相互溝通，但不需要知道彼此的作業平台是那一種或是各自如何實作等細節資訊 SOAP指的是一種提供給Web Services以XML製作出來的通訊協定， 目前版本是1.2，就像是打電話必須通過電話線或是無線基地台等， 其目的就是讓應用程式與應用程式能相互溝通，但不需要知道彼此 的作業平台是那一種或是各自如何實作等細節資訊。例如：E-mail 是藉由SMTP的標準傳送資料，在一封E-mail中，除了文字以外，也 定義了SMTP的協定內容，如此欲將封包傳送出去時，必須是SMTP協 定看得懂的格式，才能夠傳送。SOAP的概念也是如此，其XML架構如 【圖二】所示，相關參考資料詳見【註九】。

3.4：Overview

4：傳統遠端method call 要達到load balance，一般是用分散式的架構來達到 傳統的RPC方式以Java平台為例，必須要透過Java專屬通訊協定來呼叫遠端method call，而.Net也是利用類似的技術來達到，這種傳統的遠端method呼叫方式無法跨平台和跨語言，在系統的擴充性和整合性上就會有所限制。

4.1：Web Service 以XML base的資料交換，建立在HTTP之上，所以不會被開發語言所限制 而以web service為基礎的RPC(如圖四)就可以避免掉上述的缺點，因為web service是XML base的資料交換，且通訊協定是建立在HTTP之上，因為是公共的通訊協定和資料交換方式，所以不會被開發語言所限制，既然不被開發語言所限制當然也就不就有跨平台不相容的問題了。

5： Scenarios of using WS in wireless devices Wireless device acting as WS requestor WS-aware wireless device (fat client scenario) WS-agnostic wireless device—a proxy-based architecture (thin client scenario) Wireless device acting as WS provider Web Services 於無線網路中的應用情境，兩種情境： 假設無線設備扮演Web Services請求者 兩種架構： WS-aware wireless device (fat client scenario) WS-agnostic wireless device—a proxy-based architecture (thin client scenario) 假設無線設備扮演Web Services提供者 移動的賣家通過他的無線設備提供買家相關產品服務。

5.1： Wireless device acting as WS requestor 無線設備扮演Web Services請求者： 這種情境最適合一個移動中的使用者對典型服務的請求 例如：貨幣匯率 這種情境也適合於對情況具有感知的應用(context-aware applications) 例如：找到在使用者附近的拍賣賣家的服務

5.1.1： WS-aware wireless device (fat client scenario)(1/5) 在這種架構下一個無線設備擔任WS requestor的角色，它需要處裡客戶端的服務， 並且要和WS Provider及WS Broker在WS protocols(WLAN、GPS、GPRS)下通過無線網路互相溝通。 這種無線設備具有處裡XML的能力，它具有以下優勢： 它可以使手機製造商在一個開放的標準下快速的部署網路解決方案。 它讓應用程式更加動態，滿足客戶的需求。 它促進了企業軟體與無線設備上的軟體之間的溝通及整合。

5.1.1： WS-aware wireless device (fat client scenario)(2/5) End-user’s requirements(滿足客戶的需求) Ｄynamic selection of services Ｑuick response Ｄisconnected operation dynamic selection of services：動態選取服務 quick response：快速回應 disconnected operation：斷線情況下的運作

5.1.1： WS-aware wireless device (fat client scenario)(3/5) End-user’s requirements(滿足客戶的需求) (Ｄynamic selection of services) 在無線的世界中，最大的問題是移動的問題，當位 置變化後如何更加具體的發現服務，在於如何提升 Web service的directory’s sevice entries(目錄服務 項目) 。在這方面的一個初步研究結果是擴展UDDI 的註冊中心，以克服UDDI的限制 End-user’s requirements(滿足客戶的需求)： dynamic selection of services： 動態選取服務，在有線的網路世界裡，仍然是未解決的問題，在無線的世界中，最大的問題是移動的問題。當位置變化後如何更加具體的發現服務，在於如何提升Web service的directory’s sevice entries(目錄服務項目)，WSDL（Web服務描述語言）並不包括這種能力。如何克服以上的問題，於Web Service上豐富客戶所要求的服務，使其可以找到最適合自己的服務，這是研究的目標。在這方面的一個初步研究結果是擴展UDDI的註冊中心，以克服UDDI在支持基於位置的服務發現上的限制。

5.1.1： WS-aware wireless device (fat client scenario)(4/5) End-user’s requirements(滿足客戶的需求) (Ｑuick response) 優化的SOAP和XML， Call-back機制，非同步機制，優化的www End-user’s requirements(滿足客戶的需求)： quick response(快速回應)： 優化的SOAP和XML，可以實現(Section 4討論過) Call-back機制，只傳送需要更新的內容，減輕了相同訊息傳遞的負擔。 非同步機制，掩蓋了緩慢的網路，讓無線設備可以執行其他的工作，而不需停在那裡等待回應。 這需要一個訊息標識符和一個關聯處裡在SOAP應用程式下同時發送和接收，架構如本文： 在Host I中，一個Request SOAP message，Message Identifier Handler於SOAP的標頭中產生了一個唯一的訊息標識，app2接收app1的訊息後，產生回覆訊息並同時產生一關聯，使回覆內容與請求內容相關聯，當app1收到回覆的內容後，依據回覆內容中的關連匹配到相關的內容。 較低層的通訊協定TCP層也可以實現(SOAP is based on HTTP which is based on TCP)，因無線的頻寬稀少，所以為了無線設備而優化 www 。在這領域，值得一提的是IBM的WebExpress(適用於行動環境下的Web瀏覽系統)

5.1.1： WS-aware wireless device (fat client scenario)(5/5) End-user’s requirements(滿足客戶的需求) (Ｄisconnected operation) message queuing(訊息佇列)，要發送的訊當被加入佇列中 ，當無線設備與伺服器再次建立網路連線時，訊息就會被發送 End-user’s requirements(滿足客戶的需求)： disconnected operation(斷線情況下的運作)： message queuing(訊息佇列)，要發送的訊當被加入佇列中 ，當無線設備與伺服器再次建立網路連線時，訊息就會被發送。 (Softwired )Ibus/Mobile product 提供了JMS的功能，可在容錯和可靠的方式下調用WS的服務。

5.1.2： WS-agnostic wireless device-a proxy-based architecture (thin client scenario) (1/6) 在此架構中Proxy接收客戶的需求，通過WS protocols 與WS Broker及WS Provider互相溝通，並回覆客戶的需求， Proxy與wireless device通過尚未定論的協定溝通(像WAP/XHTML或i-Mode/cHTML)。 因Proxy擔任溝通的角色，從而減輕了無線設備在與WS溝通上的時間及處裡器的消耗。 他的功能與WAP gateway很像，WAP gateway負責WWW protocols(例如：HTTP,TCP) 與 wireless-optimised variants(例如：WSP,WTP,UDP)的轉換。

5.1.2： WS-agnostic wireless device-a proxy-based architecture (thin client scenario) (2/6) End-user’s requirements(滿足客戶的需求) (Ｄynamic selection of services) 同fat client scenario

5.1.2： WS-agnostic wireless device-a proxy-based architecture (thin client scenario) (3/6) End-user’s requirements(滿足客戶的需求) (Ｑuick response) 快取機制 IBM的WebExpress 應用快取機制，Proxy可以cache Response message並以此回覆客戶，從而降低網路的頻寬及WS Provider的工作量： Host I 送出一個SOAP request(“ExchangeRatesRequest”)到Host II(WS Provider)。 Host II回覆Host I(“ExchangeRatesResponse”)，同時會在Response中增加一個CacheControl Header， CacheControl Header包括CacheKey和Expires，Response message傳送到Proxy後，Proxy會複製一份，之後如有相同的請求， Proxy可以從其複製的有效期資料中找到回覆客戶的資料。 IBM的WebExpress提供的differencing mechanism(差分機制)

5.1.2： WS-agnostic wireless device-a proxy-based architecture (thin client scenario) (4/6) End-user’s requirements(滿足客戶的需求) (Ｑuick response)

5.1.2： WS-agnostic wireless device-a proxy-based architecture (thin client scenario) (5/6) End-user’s requirements(滿足客戶的需求) (Ｄisconnected operation) 利用快取機制，當客戶重新建立連線時，Proxy通過caching mechanism，把資訊傳給客戶 利用快取機制，當客戶重新建立連線時，Proxy通過caching mechanism，把資訊傳給客戶。

5.1.2： WS-agnostic wireless device-a proxy-based architecture (thin client scenario)(6/6) Challenge： 在這裡proxy是一個中心實體，控制所有客戶的資料，並決定其存取 這種集中模式可能導致嚴重的商業問題(Proxy被一個不可靠的，不安全或是abusive monopoly濫用壟斷所控制) Proxy曝露於網路中容易受到攻擊

5.2： Wireless device acting as WS provider(1/5) 無線設備扮演Web Services提供者： 隨著無線設備的功能越來越先進，把無線設備作為WS Provider

5.2： Wireless device acting as WS provider(2/5) Dynamic selection of services中解決位置改變的策略： 當WH-WSP位置改變時，WH-WSP可以依靠現有的API自動更新UDDI Registry WH-WSP及時通知已知客戶位置的改變

5.2： Wireless device acting as WS provider(3/5) Dynamic selection of services中解決位置改變的問題： 當WH-WSP位置改變時，WH-WSP可以依靠現有的API自動更新UDDI Registry

5.2： Wireless device acting as WS provider(4/5) Dynamic selection of services中解決位置改變的問題： 當WH-WSP位置改變時，WH-WSP可以依靠現有的API自動更新UDDI Registry 通過建立UDDI APIs及建立在無線設備中的網路監控代理來實現。 監控代理不斷的檢測網路介面和和位置的變化。當位置發生變化後，WS provider通過呼叫UDDI的 API更新 UDDI registry。 監控代理器是一種Sensor(可能是 GPS接收器或是數位溫度計)檢測變化的環境，並刺激相應的通知。

5.2： Wireless device acting as WS provider(4/4) Dynamic selection of services中解決位置改變的問題： WH-WSP及時通知已知客戶位置的改變。 可以通過SOAP實現 Provisions for such notification mechanism are foreseen in the latest version of the protocol.

6： Building blocks for using Web services in wireless devices(1/3) 可以看到WS Provider 和WS Requestor被分成兩部分，在各自區塊的左邊部分的功能是無線和有線都必須有的，右邊的部份是wireless device額外需要的功能。

6： Building blocks for using Web services in wireless devices(2/3) WS Provider組成： Adaptation Handler(適應處裡) Subscription Handler(訂閱處裡) SOAP Listener Message Identifier/Correlation Handler Message Queue Application Logic Binding Cache Sensor Network Optimization Peer/Registry Update WS Provider，為了支援無線服務，需要以下的功能組成： Adaptation Handler(適應處裡)，在考慮到用戶的喜好和無線設備的能力方面，允許產生個性化和適應性的用戶介面和標記。 Subscription Handler(訂閱處裡)，它是一個負責訂閱/通知的模組，它使ㄧ個SOAP的應用程式向WS訂閱通知，以及處裡其他程式的通知訂閱。 SOAP Listener，它負責以下的功能： serialise method calls into SOAP packets(序列化資訊到SOAP封包中) deserialise SOAP packets into Java calls(解序列化SOAP封包給Java用) wrapXML documents into SOAP packets(打包XML文件到SOAP封包中) unwrapXML documents from SOAP packets(解SOAP XML封包) submit SOAP requests and handle the responses(傳送SOAP請求及處裡回覆) accept SOAP requests and return the responses(接受SOAP請求及回覆請求) Message Identifier/Correlation Handler，此區塊負責非同步訊息的傳遞，a SOAP request header在此產生唯一的標識，同時SOAP response產生與request的關連，以便回覆請求。 Message Queue，資料維護於此，可在容錯和可靠的方式下調用WS的服務 Application Logic，此區塊提供WS Provider/Request必須執行的商業功能。 Binding Cache，它由一維護表構成，此維護表的內容為，WS Provider的位址和已知的訊息及WS Request最近的請求。 Sensor，它的功能是檢測一般環境的變化，像物理位置的變化、生理的變化(身體的溫度及心律等)、情緒的狀態(生氣、冷靜等)，並刺激相應的通知。 Network Optimization，此區塊利用優化的差分和HTTP技術，在無線通訊中實現減少數據量和通信的延遲。 Peer/Registry Update，當WH-WSP位置改變時，負責通知 WS registry 和通知已知的訊息請求者。

6： Building blocks for using Web services in wireless devices(3/3) WS Request組成 WS Broker組成 Proxy組成 WS Request組成： Subscription Handler、SOAP Listener、Message Identifier/Correlation Handler、Message Queue、Application Logic、Sensor、Network Optimization、Peer/Registry Update如WS Provider。 Caching handler：它負責管理來自於WS Responses的緩存，建立適當的SOAP標頭，當緩存到期時的響應。 WS Broker組成： Security handler，它負責所有安全方面，即識別，驗證，授權，完整性，保密性和不可否認性。並且控制資料的存取權。 Repository(容器)，存儲服務描述。   Proxy組成： Caching database，緩存WS responses。

7：Experiments on the wireless WS provider scenario(1/7) 試驗目標：為了評估Section 5.2(Wireless device acting as WS provider)的可行性，我們的試驗目標 研究關於快速回應需求的效能問題 在現有的開發工具下，評估建議的技術解決方案的可行性 論證WH-WSP通過處裡位置的變化和具體信息的改變，如何支援動態選取服務 To quantify the overheads associated with the mechanisms(量化架構)

7：Experiments on the wireless WS provider scenario(2/7) 試驗設備： 一台PDA(Ipag 3870，running Pocket PC2002)，配備了10Mbps WLAN(IEEE 802.11b) PCMCIA card 此PDA植入了IBM’s WebSphere Studio Device Developer 開發的Java虛擬機 另外增加了JVM支持UDDI，SSL及SOAP的功能。 一個輕量級多線程的web server運行於PDA上，並服務SOAP requests 利用IBM test UDDI registry 作為registry

7：Experiments on the wireless WS provider scenario(3/7) WH-WSP的功能： 檢測PDA位置變化所改變的IP位置 檢測PDA IP的變化後，更新UDDI，同時維護使用此web service的客戶與PDA 的連線 Web service 植於PDA上並回報當前無線終端機的位置及其他訊息

7：Experiments on the wireless WS provider scenario(4/7) 實驗情境： 模擬的情景是一個不斷移動的用戶，他通過拍賣過程試圖銷售自己的產品。這個用戶攜帶著PDA，回覆眾多的請求，他們同時對有興趣的部份做的查詢(產品清單，拍賣狀況等)

7：Experiments on the wireless WS provider scenario(5/7) 實驗聚焦點： PDA-hosted WS provider 更新 UDDI Registry 時間的消耗 客戶查詢UDDI Registry的時間(UDDI Search time)，關於PDA-hosted WS provider當前的位置 無線終端機處裡眾多客戶傳入的WS requests(WS Execution Time)時間

7：Experiments on the wireless WS provider scenario(6/7) 實驗的其他設定： 為了說明無線和有線的WS Providers的差異，例如：有限的頻寬和運算能力，因此，在固定終端機上也運行以下功能： 模擬和偵測位置的改變並更新UDDI registry 接收及回覆客戶請求。

7：Experiments on the wireless WS provider scenario(7/7) 實驗的運作： 利用壓力測試工具針對UDDI及PDA-hosted WS Provider的不同節點的多個併發請求的實驗運作 我們研究PDA-hosted WS Provider與 fixed terminal 之間的 UDDI Registry Update的運作 於PDA-hosted WS Provider 上的UDDI Search 運作及 WS Execution 於fixed terminal WS Provider 上的UDDI Search 運作及 WS Execution

7.1：UDDI registry update times Differences are in the order of 50-60 msec and can be attributed to the bandwidth and computing power deficiency that is inherent to the wireless terminal. PDA和Fixed Provider 更新IBM UDDI Registry (檢測IP變化，然後更新UDDI Registry)的時間，通過比較，兩種方案只差50-60毫秒，這可歸因為無線終端機有線的頻寬和運算能力。

7.2：UDDI search and WS execution times UDDI Search Times，WS Execution Times：為了確保觀察統計，每次實驗重複5次一定數目的客戶，例如：在10客戶的情況下，我們得到5x10次的實驗數據。 Fig.12 included 3rd order polynomial interpolation lines(包括三階多項式插值線)及Fig.13 standard deviation(標準差)圖，在兩圖中我們可以發現UDDI Search Times高於WS Execution Times，有此可以推斷UDDI Search Times具有高度的不可預知性。當許多客戶同時存取它時，UDDI的基礎設施可能會趨於飽和， 此瓶頸一旦形成，UDDI responses將連續的回覆客戶的請求，它就像交通的調解者一樣，導引客戶取得PDA-hosted web service。因此WS Execution Times可以在一個高負載的UDDI Search Times情況下縮短WS Execution Times

7.2：UDDI search and WS execution times(1/3)

7.2：UDDI search and WS execution times(2/3) Fig. 14描繪了大量客戶同時存取位於標準桌式PC上的WS Provider的UDDI Search Times和WS Execution Times，可以發現它和Fig.12很像

7.2：UDDI search and WS execution times(3/3) 通過Fig. 15我們觀察到the PDA-hosted and the desktop PC-hosted WS Provider在平均WS Execution Times值行時間上的差別。 此實驗的客戶端硬體為：等級較低的桌上型電腦(AMD Athlon XP 2000+, 512 MB RAM))，在the fixed WS provider的情況下有較高的頻寬。

7.3：小結 WH-WSP方案在當前的軟體技術下是完全可行的 客戶對不斷改變位置的無線終端機的UDDI查詢，導致UDDI registry性能過飽和 完成WS調用的所需時間，WH-WSP始終高於fix WS provider，這可歸因於無線設備處理能力和頻寬的限制 WH-WSP方案在當前的軟體技術下是完全可行的。 客戶對不斷改變位置的無線終端機的UDDI qureies，導致UDDI registry性能過飽和。 完成WS調用的所需時間，WH-WSP始終高於fix WS provider，這可歸因於處理能力和頻寬的限制。

8：Summary and conclusions(1/2) 擴大WS技術在無線網路領域中的應用，可以大大拓寬e-commerce的範圍 WS技術在交易服務方面特別重要，是移動電子商務領域的關鍵因素 WS在任何設備任何時間方便資料和服務的存取。 WS也支援無線設備使用者的動態選取而不是靜態的提供

8：Summary and conclusions(2/2) WS requestor(thin/fat client)和WS provider 三種架構的選擇取決於應用的需求及無線設備的能力

謝謝!