WSRP+利用Data Web Service发展DataPresentation导向并重的通讯协定.docx

WSRP+利用Data Web Service发展DataPresentation导向并重的通讯协定.docx

《WSRP+利用Data Web Service发展DataPresentation导向并重的通讯协定.docx》由会员分享，可在线阅读，更多相关《WSRP+利用Data Web Service发展DataPresentation导向并重的通讯协定.docx（18页珍藏版）》请在冰豆网上搜索。

WSRP+利用DataWebService发展DataPresentation导向并重的通讯协定

WSRP+:

利用網路服務（DataWebService）發展資料（Data）、顯示層（Presentation）導向並重的通訊協定

歐陽芳泉

清雲科技大學資訊管理系

ouyang@cyu.edu.tw

許智誠

中央大學資訊管理研究所

khsu@mgt.ncu.edu.tw

黃麒中

中央大學資訊管理研究所

93423041@cc.ncu.edu.tw

摘要

近幾年來因WSRP以及JSR168規範興起，在供應鏈產生極大功效及價值，我們預期未來Portal的發展可能會是：

WSRP提供者（WSRPProducer）專心建置Portlet，WSRP消費者（WSRPConsumer）致力於將服務整合於自建的Portal平台。

然而，目前WSRP消費者遇到了瓶頸：

無法有效運用資料，進而發揮更高價值，故無法提供更具潛力的整合性服務而錯過許多商機。

在我們的研究中，我們提出一個強調資料（Data）及顯示層導向（Presentation-Oriented）、開放式（open）、可攜式（pluggable）的WSRP進階版標準：

WSRP+。

在WSRP+中，我們依然以WSRP為主要標準，提供顯示層導向應用，將標記區塊（MarkupFragment）發送至WSRP消費者端；在資料層次我們將利用網路服務（DataWebService）做為傳遞資料的方法，將資料由WSRP提供者端發送至WSRP消費者端，藉以讓WSRP消費者有效地運用資料。

本研究的貢獻在於提出結合網路服務及WSRP規範的進階版標準，讓原本WSRP規範能夠更有效地應用於各領域。

壹、引言

WSRP（WebServiceforRemotePortlet）自2003年發展至今已有二年，它讓Portlet能夠由遠端供應，提供以顯示層導向的方式整合現有服務，而這樣的發展也讓B2B、B2C在供應鏈上衍生出不同的應用。

然而，WSRP規範目前並不完善。

在WSRP規範中，WSRP消費者端只負責整合並顯示資訊的中介者，要使WSRP消費者更能發揮價值必須靠WSRP提供者端所提供的資料做儲存、分析用途或是當成工作流程下一個步驟的輸入。

我們發現在目前WSRP規範中並沒有任何機制允許WSRP消費者接收、辨認、儲存或是發送WSRP提供者提供的資料，在WSRP規範中對於回應GetMarkup（註一）請求的SOAP訊息中只規定了MarkupContext（註二）以及SessionContext（註三）二項資料集合；摒除SessionContext不考慮（因為SessionContext資料集規定的是有關於Session的相關資訊），在MarkupContext中最重要的資料型態MarkupString（註四）也僅僅是讓WSRP消費者用以整合並顯示給終端使用者瀏覽的一些標記區塊，WSRP消費者依然不能夠接收、辨認或儲存WSRP提供者提供的資料。

我們所提出的WSRP+基於以下理由：

1.令WSRP消費者端能夠接收、辨認、儲存以及發送WSRP提供者所提供的資料或令WSRP提供者端能夠提供資料給WSRP消費者端或是接收來自WSRP消費者端的資料。

2.提供服務整合者與服務提供者間一種資料通訊方式。

服務整合者與服務提供者建置好的網路服務通訊，根據網路服務互動模式的標準，向服務提供者提供的網路服務取得資料。

3.利用預先輸入提供服務提供者在初始服務時所需的資訊。

所謂預先輸入是指服務整合者在送出GetMarkup請求給服務提供者時，包含在請求中供服務提供者初始服務的資料。

服務提供者利用預先輸入做適當處理後，會在GetMarkup回應中回傳處理過後的標記區塊給服務整合者。

4.幫助服務整合者收集、分析資訊，並經由這些資訊發掘其他有利於商業行為的發現。

5.經由視覺及資料的整合，終端使用者在瀏覽網站時能夠依個人習慣及喜好更加個人化，並能夠在此單一窗口網站完成一系列事宜（如：

規劃旅遊行程）。

我們在本研究欲達到的目標為利用既有的網路服務及WSRP技術發展資料層與顯示層並重之新版通訊協定：

WSRP+。

我們的貢獻為強化了原有WSRP規範，讓其能更有效地應用於各領域。

本研究接下來的架構如下：

相關工作將於第二章討論。

第三章將詳述WSRP+架構及功能。

第四章則是結論。

貳、相關工作

WSRP+架構的所有相關工作將在這個章節討論，我們將詳述如何利用已有開放標準以及其他相關研究去幫助我們完成WSRP+並解決資料傳遞和互動模式上的相關議題。

一、網路服務（DataWebService）：

分散式（distributed）、跨平台（platform-independent）、簡單而方便的服務

DataWebService，中文可以稱之為網路資訊服務計算技術，也有人稱之為網路服務等等，在台灣資訊網中（XML.ORG.TW）對網路服務的說明為：

網路服務（DataWebServices）是分散式系統未來發展的趨勢，讓應用程式在網路上提供服務，供其他機器上的程式所使用。

網路服務具有強大的互通性和延伸性，讓應用程式能更簡單的整合網路上的程式，藉由交談的方式達成某些複雜的運作過程，如企業間的交易等。

而W3C對於網路服務的定義如下：

”一項網路服務是由一個URI所定義的軟體系統，它的公用介面及實體連結都由XML所描述。

它的定義可由其他軟體系統發現。

這些軟體系統得以經由該網路服務的預先定義利用包覆在網路通訊協定中的XML訊息與網路服務溝通（註五）。

簡單來說，網路服務利用HTTP通訊協定、XML、UDDI、SOAP以及WSDL建構了一個完整的平台，並且解決中間元件（RMI、CORBA、COM+…等）交換資訊技術問題，提供一個廣泛而適用的介面，讓開發者只需要專注於本身系統的開發而非自行花費時間維護相關資訊資料庫。

對於開發者來說，得以快速地將系統建構完成；對於服務提供者來說，只要能夠設計出一個好的服務，它的潛在使用者市場將不受到使用者平台的限制。

相對於WSRP的顯示層次，網路服務只提供資料層次的服務，但在此我們所著重的正是網路服務所提供的資料。

因為WSRP僅提供顯示層次整合，WSRP消費者無法識別WSRP提供者發送的資料，需由網路服務彌補WSRP不足，提供WSRP消費者需要的資料。

二、WSRP：

可共享（Sharable）、可攜帶並且基於顯示層整合的開放通訊協定標準

Portal自1998年以來已經被當成一個人化存取資訊及應用程式的概念。

Portal是一個以網路（web）為基本架構的應用程式，它提供個人化、單一登入、整合不同資料來源內容並提供資訊系統顯示層次的整合。

利用Portal，使用者所獲得的利益是後端服務的整合。

與傳統架構不同的是，Portal整合了異質性應用程式的使用者介面、功能以及資料。

與網路服務不同的是，運用網路服務需要我們自行處理前端顯示，利用Portal則能夠順利地整合網站中顯示的部份。

Portlet是一個顯示層導向、具互動性的網路應用（webapplication）元件，由Portlet容器（Container）所管理；它被設計成依附於Portal伺服器（Server）並且能夠與使用者溝通、接收使用者請求並產生動態內容。

原始依附在Portal伺服器上的Portlet是本地端的（local），也就是說，Portlet只能由本地端產生，供本地端Portal伺服器應用，雖然本地端元件能夠提供快速的反應時間，但這並不適合於動態商業應用整合及異質性資源。

WSRP（WebServiceforRemotePortlets）提供了讓Portlet能夠遠端化（Remotable）的方法，WSRP規範定義存取以及顯示層導向網路服務互動的網路服務介面，以致於Portlet具備由遠端提供服務的能力，只要具備Portlet的WSDL文件（可能會經過註冊程序），就能夠把它當成是本地端的Portlet一樣讓Portal伺服器使用，最終不再需要服務整合者花費成本再處理顯示層。

經由WSRP，服務提供者能夠利用不同服務提供者所提供各式各樣的Portlet、自身所建置的環境以及少許工作任務流程組成一系列相關規劃事宜提供終端使用者單一窗口、整合、完整而個人化的加值服務；在我們提出的架構中，WSRP規範幫助WSRP提供者把發展的Portlet經由所定義好的互動模式及必要資訊提供給WSRP消費者，讓WSRP消費者能順利整合於Portal伺服器中。

三、WSRP+：

利用網路服務（DataWebService）發展資料（Data）、顯示層（Presentation）導向並重的通訊協定

現今WSRP應用趨向於WSRP消費者端的發展：

整合各項服務於WSRP消費者之處。

但要能使WSRP消費者更發揮其價值，還需要有額外的能力，也就是上述所提到，能夠分析、儲存、應用的能力。

試想像有一家網際網路公司想要整合航空公司及租車公司的服務於一個網站中，提供終端使用者機票查詢、訂機票、車種及可用車查詢、訂車等服務，傳統網路服務（WebService）的描繪如圖一，服務整合者自行建構網頁，在後端利用網路服務取得航空公司及租車公司的資料，終端使用者只需瀏覽服務整合者所建立的網站並與之互動即可得到航班資訊及可用車資訊，完成訂機票及訂車的動作。

圖一利用傳統網路服務之解決方案

然而，這樣的解決方案有以下缺點：

1.服務整合者必須自行建構網頁及相關服務。

2.自行處理與航空公司以及租車公司網路服務之間的溝通和互動、網頁排版、外框顯示以及內容等等，許多細節的建置都需自行處理。

會有如此缺點的原因是因為網路服務是屬於資料層導向（Data-Oriented）的應用，由服務提供者所提供之網路服務發送給服務整合者的只有資料，而非標記區塊。

服務整合者雖然能夠取得資料，仍需撰寫與使用者互動之顯示介面部份的程式。

有鑑於此，我們提出使用Portlet以及WSRP以有效解決上述之問題（參照圖二）。

Portlet是顯示層導向的網路（web）元件，而WSRP則是一個能夠讓Portlet遠端化（Remotable）的規範，利用Portlet與WSRP能讓服務整合者迅速建構網站並省去撰寫程式的工作。

服務整合者利用WSRP整合航空公司及租車公司提供的Portlet；所有服務整合者要做的事為提供既有工作流程並整合Portlet至本身之Portal網站即可，此解決方案的詳細步驟為：

1.終端使用者選定欲訂定的機票，按下確定鍵送出資料。

2.WSRP消費者送出請求（Request）給WSRP提供者#1做訂機票的動作。

WSRP提供者#1提供Portlet供使用者訂機票、搜尋可用機票等等有關飛機班次及機票事宜。

3.WSRP提供者#1在處理過後，最終傳回確認並包含顯示層結果。

4.WSRP消費者根據訂機票的資訊，向WSRP提供者#2送出要求畫面及租車相關資訊請求。

WSRP提供者#2提供Portlet供使用者查詢車種、租賃汽車、預約租車。

5.WSRP提供者#2傳回包含顯示層顯示及處理過後的資訊給WSRP消費者。

6.WSRP消費者整合畫面資訊並傳回給終端使用者。

圖二WSRP解決方案

在圖二中，我們可以了解到，在終端使用者訂完機票後，下一步驟就是要租賃汽車。

在圖二的步驟四中，租賃汽車必須根據所訂定機票的相關資訊如飛機班次或目的地顯示相對應目前可租賃的汽車，故WSRP消費者需能取得並辨識終端使用者所訂的機票資訊，並將此資訊在發送GetMarkup請求時包含在請求中當成租車公司對應Portlet的預先輸入。

我們發現在目前WSRP規範中並沒有任何機制允許WSRP消費者接收、辨認、儲存或是發送WSRP提供者提供的資料，在WSRP規範中對於回應GetMarkup請求的SOAP訊息中缺乏傳送資料給WSRP消費者的部份，WSRP消費者無法遵循WSRP規範取得有關於機票的任何資訊。

這正是我們想要解決的難題。

在我們所提出的架構（WSRP+）當中，我們仍然把WSRP當成顯示層核心，提供顯示層可攜式（pluggable）的整合；利用網路服務傳遞資訊，提供跨平台資料傳輸的功能，讓WSRP消費者能順利取得資料；除此之外我們擴充了WSRP規範，在WSRP消費者及WSRP提供者二端我們各別多加了請求網路服務模組（CallDataWebServiceResponding）以及準備網路服務模組（PrepareforDataWebService），讓我們所提出的架構能夠順利地進行。

參、WSRP+架構及功能

WSRP+是建構於WSRP以及網路服務，針對WSRP現有缺點而提出的架構，WSRP+比原本WSRP多了請求網路服務模組以及準備網路服務模組，二者分別對應於WSRP消費者和WSRP提供者端。

由於架構中的需要，我們將要求並做以下假設：

1.每個WSRP提供者所提供的Portlet可以有預先輸入。

2.每個WSRP提供者若能夠提供網路服務，則在Markup階段前就準備好並能正常運作。

3.每個WSRP提供者所提供的Portlet都可以有各自的網路服務。

4.網路服務WSDL位址資訊（DataWebServiceWSDLLocationInformation）已儲存在準備網路服務模組模組中。

WSRP+架構圖如下（我們以循序圖呈現）：

圖三WSRP+架構圖

圖三所示為WSRP規範中Markup階段的擴充版本，在WSRP+中除了Markup階段以外，其餘階段的流程皆與原有WSRP規範相同無異。

詳細步驟如下：

[1].終端使用者在WSRP+消費者端Portlet填入資料，並送出表單資料。

[2].Poral伺服器將請求轉送給WSRP消費者端模組進行處理。

[3].WSRP消費者端模組透過網路向WSRP提供者端模組請求處理。

[4].WSRP提供者端模組處理完成後，將表單及處理完成之資訊（如計算成績）儲存在WSRP提供者端的儲存區。

[5].WSRP提供者端模組回報處理完成回應給WSRP消費者端模組。

[6].WSRP消費者端模組根據收到的處理完成訊息向WSRP提供者端模組發送GetMarkup請求。

[7].假設此次連線為WSRP消費者端與WSRP提供者端之最後一次連線，準備網路服務模組會將此次請求Portlet對應網路服務之網路服務WSDL位址資訊發送給WSRP提供者端模組。

[8].WSRP提供者端模組將標記區塊、網路服務WSDL位址資訊及WSRP結束標記包含中回應中發送給WSRP消費者端

[9].WSRP消費者端模組收到回應後，將WSRP結束標記值及網路服務WSDL位址資訊轉送給請求網路服務模組。

[10].請求網路服務模組根據網路服務WSDL位址資訊向對應的網路服務請求資料，並以WSRP結束標記值為主要根據

[11].對應的網路服務依WSRP結束標記值，將資料由WSRP提供者端儲存區取出

[12].對應的網路服務回傳資料給請求網路服務模組

[13].請求網路服務模組將資料儲存在WSRP消費者端儲存區

[14].請求網路服務模組向WSRP消費者端模組回報處理完成訊息，若在後續需依據終端使用者輸入的表單及處理資訊呼叫另一WSRP提供者端模組以取得另一Portlet之畫面，則會在此時回傳終端使用者表單及處理資料給WSRP消費者端模組

[15].WSRP消費者端模組將收到的標記區塊轉送給Portal伺服器處理

[16].Portal伺服器將整合處理過之畫面傳送給終端使用者

肆、WSRP+實作

本章架構如下：

第一節我們將講述利用WSRP+解決情境問題─一家網際網路公司建構一個整合性服務的網站，將租車公司及航空公司的服務整合至一個網站提供給使用者。

第二節我們將詳述請求網路服務模組與準備網路服務模組的功能與目的。

（一）、WSRP+解決方案實例

我們所提出WSRP+解決方案如圖四。

圖四WSRP+解決方案

我們首先講述利用WSRP+解決問題的詳細步驟：

[1].WSRP+消費者向航空公司WSRP+提供者#1請求相關資訊以建立二者之間的連結。

[1.1].WSRP+消費者向航空公司WSRP+提供者#1提出GetServiceDescription（註六）請求。

[1.2].航空公司WSRP+提供者#1回覆WSRP+消費者的請求，並在回覆當中包含了Metadata及OfferedPortlets（註七）。

[2].WSRP+消費者向租車公司WSRP+提供者#2請求相關資訊以建立二者之間的連結。

[2.1].WSRP+消費者向租車公司WSRP+提供者#2提出GetServiceDescription請求。

[2.2].租車公司WSRP+提供者#2回覆WSRP+消費者的請求，並在回覆當中包含了Metadata及OfferedPortlets。

[3].終端使用者已取得畫面，選好所需機票並填完必要資訊，按下送出鍵把資料送到WSRP+消費者端。

[4].WSRP+消費者根據WSRP規範中的二步驟通訊協定（Two-StepProtocol）（註八）送出資料給航空公司WSRP+提供者#1-Portlet1，並請求WSRP+提供者#1-Portlet1回傳標記區塊並取得終端使用者所訂的機票資訊。

[4.1].WSRP+消費者送出PerformBlockingInteraction（註九）請求並送出表單資料給航空公司WSRP+提供者#1-Portlet1。

[4.2].航空公司WSRP+提供者#1-Portlet1回傳PerformBlockingInteraction回應給WSRP+消費者，在回應中包含了NavigationalState和/或Newmode和/或NewWindowState（註十）。

[4.3].WSRP+消費者送出GetMarkup請求給航空公司WSRP+提供者#1-Portlet1，在請求中包含了NavigationalState和/或Mode和/或WindowState。

[4.4].航空公司WSRP+提供者#1-Portlet1回傳GetMarkup回應，並在回應之中包含了標記區塊（MarkupFragment）、WSRP結束標記（EndOfWSRPToken）及網路服務WSDL位址資訊（DataWebServiceWSDLLocationInformation）（有關於WSRP結束標記及網路服務WSDL位址資訊解釋請見下文）。

[4.5].WSRP+消費者端的請求網路服務模組模組根據WSRP結束標記及網路服務WSDL位址資訊與相對應的網路服務互動溝通，並取回終端使用者所訂的機票資訊。

[5].WSRP+消費者在GetMarkup請求中將終端使用者所訂機票資訊發送給租車公司WSRP+提供者#2-Portlet3，當成租車公司WSRP+提供者#2-Portlet3的預先輸入，WSRP+提供者#2-Portlet3經過適當處理後回傳給WSRP+消費者。

[5.1].WSRP+消費者送出GetMarkup請求給租車公司WSRP+提供者#2-Portlet3，並在請求之中包含了終端使用者所訂機票資訊，當成租車公司WSRP+提供者#2-Portlet3的預先輸入。

[5.2].租車公司WSRP+提供者#2-Portlet3根據機票資訊處理完之後，回傳GetMarkup回應給WSRP+消費者，並在回應中包含了處理過後的標記區塊。

[6].WSRP+消費者整合Portlet至Portal頁面中，將結果回傳給終端使用者。

由以上詳細步驟我們可以發現，WSRP+只比原有WSRP多了4.4步驟中所附加的資訊（我們以粗斜體字標示）以及步驟4.5，並且也未更改任何GetServiceDescription介面標準有關流程或步驟，我們只需要在Markup介面中新增些許傳遞的資訊（WSRP結束標記與網路服務WSDL位址資訊）及步驟（步驟[4.5]）即可。

在Markup介面中我們將焦點專注於所謂二步驟通訊協定（Two-StepProtocol）（步驟[4.1]到步驟[4.4]）的GetMarkup回應訊息（[4.4]）與步驟[4.5]。

由步驟[3]（終端使用者取得畫面，在Portlet1’上選好所需機票並填完必要資訊，按下送出鍵把資料送到WSRP+消費者端）到步驟[4.3]（WSRP+消費者送出GetMarkup請求給航空公司WSRP+提供者#1，在請求中包含了NavigationalState和/或Mode和/或WindowState）都是WSRP的標準流程，我們在此略過。

在步驟[4.4]中，WSRP+提供者判斷這次的Markup回應為此次連線（Session）最後一次的通訊，在WSRP+提供者已將使用者所訂的機票處理完畢並儲存供網路服務使用後，會在回應中附加WSRP結束標記提醒WSRP+消費者這次的回應為連線結束（EndofSession），WSRP+提供者與WSRP+消費者的通訊到此即結束；此外WSRP+提供者也由準備網路服務模組中取得相對應的網路服務WSDL位址資訊，並附加在GetMarkup回應中回傳給WSRP+消費者。

詳細的SOAP訊息如表一：

表一包含WSRP結束標記及網路服務WSDL位址的GetMarkup回應

getMarkupResponsexmlns:

urn="urn:

oasis:

names:

tc:

wsrp:

v1:

types">

markupContext>

mimeType>text/html;charset=UTF-8

mimeType>

markupString>

[CDATA[略]]>

markupString>

requiresUrlRewriting>true

requiresUrlRewriting>

preferredTitle>PortfolioManager

preferredTitle>

markupContext>

sessionContext>

SessionID>sessionID_1

SessionID>

expires>300

expires>

sessionContext>

WSRP結束標記

NamedString>

name>EndOfWSRPToken

name>

value>Session_ID

value>

網路服務WSDL位址

NamedString>

NamedString>

name>DataWebServiceWSDLLocation

name>

value>

NamedString>

getMarkupResponse>

WSRP+消費者收到GetMarkup回應後，將WSRP結束標記及網路服務WSDL位址資訊交給請求網路服務模組處理，請求網路服務模組可以根據網路服務WSDL位址資訊與相對應的網路服務互動溝通，而WSRP結束標記中的值（Session_ID）則可以當成Key，藉此取回正確的機票資訊。

在步驟[4.5]中，WSRP+消費者的請求網路服務模組模組根據所收到的WSRP結束標記以及網路服務WSDL位址資訊開始執行與網路服務標準互動模式與網路服務溝通藉以取得終端使用者所訂機票資訊，這部份的互動會遵循著網路服務互動模式