第三章一站式旅遊服務平台架構rportal.lib.ntnu.edu.tw/bitstream/20.500.12235/... ·...

第三章一站式旅遊服務平台架構

由於網路上有許多旅遊網站，而其所提供的旅遊服務，大都皆是以套裝行

程如一日遊、二日遊和三日遊等暨定旅遊路線、飯店和餐廳為其主，旅遊消費

者只能在旅遊業者給定的旅遊產品上選擇遊玩，對於消費的旅遊者而言有五個

缺點:

1. 套裝旅遊產品屬於靜態式旅遊，無法滿足以旅遊者個人喜好，做出個

人化動態式旅遊。

2. 套裝旅遊產品在景點、飯店和餐廳的選擇上缺乏彈性，旅遊者只能接

受產品上的安排，而沒有變更的能力。

3. 若旅遊網站所提供的旅遊資訊不完整，如:景點、飯店或餐廳，則旅遊

者需額外花時間和精力去網際網路上到其它網站上，自行找尋所要旅

遊資料。

4. 套裝旅遊產品對於旅遊者而言，必須做好事先的旅遊規劃，對於臨時

起意的旅遊者，則無法滿足並提供服務。

5. 若是要自助旅行的旅遊者，一般的旅遊網站無法滿足其需求，且旅遊

者還要自行去各個景點、飯店和餐廳所提供的網站上分別查詢旅遊資

料和預訂，對於自助旅行的旅遊者來說非常不方便。

因此本研究針對上述缺點，利用工作流程中的自動流程規劃和流程描述語

27

28

言發展出「一站式旅遊服務」平台，並分為下列五節加以討論：一、以工作流

程導入一站式旅遊服務概念架構分析，二、中介排程語言，三、行程規劃，四、

註冊儲存庫與旅遊內容資訊服務，五、聯合作業查詢。

3.1 以工作流程導入一站式服務概念架構分析

本研究「一站式旅遊服務」平台的開發，亦具備下列五大目標，茲說明如

下：

1. 個人化：讓旅遊者可以依個人的喜好來決定行程。

2. 自動化：在景點、飯店和餐廳查詢和預訂的作業上以自動化進行，旅

遊者毋須在自行手動註冊，進而手動訂購所需的旅遊服務。

3. 彈性化：旅遊者在行程上的景點、飯店和餐廳可以自行決定和變更。

4. 整合化：將各類不同性質的旅遊服務整合起來，如景點查詢和訂票、

飯店查詢和訂房、及餐廳查詢和訂位等旅遊服務整合起來，

進而提供相關的旅遊資訊，以方便旅遊者使用。

5. 擴充化：為了方便以後因增加不同的地點，隨之而來的景點、飯店、

交通和餐廳等相關旅遊資訊的增加，就需要有一個資料庫來

負責管理這些旅遊資源的新增、修改和刪除。

但要達成上述所提「一站式旅遊服務」的五大目標，在實作上尚需克服下

列三個問題:

1. 行程規劃能力:：設計出如何能讓旅遊者依照自己需求規劃行程。

2. 異質平台之溝通整合：各個景點、交通、飯店和餐廳所提供不同類型

的旅遊服務，「一站式旅遊服務」要如何去整合溝通這些旅遊服務。

3. 服務協同運作機制：由於各旅遊服務之間有很大的相依性，要如何來

處理旅遊服務之間的關係?例如以預訂景點服務來說，若是旅遊者想要

去的景點達成遊玩人數上限時，則要重新處理變更相關的餐廳和飯店。

上述這些問題對於實作一站式旅遊服務時，所需要解決的問題，故本研發

便依據這些問題，提出解決方案─一站式旅遊服務平台，如圖 15所示

圖 15 一站式旅遊服務平台架構圖

29

30

「一站旅遊式服務」平台提出三層式的流程描述語言轉換模式，將旅遊規

劃由領域觀點的旅遊工作描述語言轉換成技術觀點之 BPEL4WS 工作流程描述

語言，分別區分為上層、中層與下層共三層，上層為領域觀點(Domain View)

主要是幫助旅遊者透過平台的幫助將行程規劃出來，中層為中介排程語言是擔

任媒介的角色，負責將領域觀點轉換成技術觀點(Techinque View)，下層為技術

觀點(Techinque View)則是將中介排程語言轉換出來的 BPEL4WS 語言並將能以

自動化佈署至 BPEL Engine 上。本研究「一站式旅遊服務」平台，利用中介排

程語言，讓一站式服務的領域觀點可以與工作流程的技術觀點來做溝通整合，

進而達到以旅遊消費者為角度能以自動化運作的旅遊服務平台。

3.2 中介排程語言

中介排程語言的主要目的，是將本研究中「一站式旅遊服務」的領域觀點

(Domain View)概念能透過中介排程語言幫忙，將其轉換成成工作流程整合語言

之中BPEL4WS的技術觀點(Technique View)且能交由BPEL Engine來執行，如圖

16所示，茲說明如下。

圖 16 中介排程語言

3.2.1 旅遊行程描述語言

旅遊者透過本研究一站式旅遊服務平台規劃好行程之後，便會產生一個以

XML為基礎之「旅遊行程描述語言」。此描述語言目的在於，描述並紀錄旅遊

者此次的旅遊規劃，包括了參加人數、旅遊人數、旅遊天數、景點資訊、用餐

資訊與住宿資訊等相關旅遊者此次行程規劃資訊，如表 4所示。

圖 17為「旅遊行程描述語言」架構，第零層標籤為此檔案的根元

素，第一層、、、、、<

用餐資訊>、、和等標籤，主要是用來紀錄

描述某次旅遊的相關資訊，第二層的標籤主要描述旅遊的第幾天，第三

層、、、、、、、、等標籤，則主要用來紀錄如景點、飯店和餐廳等相關旅遊資訊。

31

32

表 4 旅遊行程描述語言標籤以及屬性意義

標籤屬性說明

基本資料(profile) 為此 XML 檔案的根元素

姓名(name) 紀錄旅遊者姓名

人數(amount) 本次旅遊參加人數

日期(date) 本次旅遊日期

天數(days) 本次旅遊所玩天數

旅遊景點(site_list) 紀錄旅遊的相關景點

景點(site) 紀錄景點名字

第幾天(day) 紀錄天數

用餐資訊(dine_information) 紀錄用餐資訊

用餐(dine) 紀錄用餐相關資訊

用餐時間(dine_time) 紀錄用餐時間

用餐餐廳(restaurant) 紀錄餐廳名稱

類型(type) 紀錄餐廳類型

價位(price) 紀錄餐廳的價位

餐廳座位(seat) 紀錄餐廳的座位數

電話(tele) 紀錄電話號碼

地址(address) 紀錄地址

網址(website) 紀錄網址位置

查詢(query) 紀錄查詢 Web Service 位置

訂位(book) 紀錄訂位 Web Service 位置

景點資訊(site_info) 紀錄景點資訊

景點名稱(site_name) 紀錄景點名稱

景點描述(site_description) 紀錄描述

交通資訊(transport_information) 紀錄交通相關資訊

捷運(rapid transit) 紀錄捷運站名

公車(bus) 紀錄公車車號

住宿資訊(hotel_information) 紀錄住宿相關資訊

飯店(hotel) 紀錄飯店名稱

房間數(room) 紀錄飯店房間總數

圖 17 旅遊行程描述語言架構圖

圖 18為旅遊行程描述語言的範例，其中則是描述並紀錄旅遊者此次的旅遊

規劃，包括了參加人數、旅遊人數、旅遊天數、景點資訊、用餐資訊與住宿資

訊等相關旅遊者此次行程規劃資訊。

33

圖 18 旅遊行程描述語言範例

34

完成旅遊行程描述語言之後，需再經過轉換以整合各類旅遊服務的參數，

並檢查是否有相同的Web Service，若有相同的Web Service則替換成擁有相同功

能的Web Service，如圖 19所示，之後在經由轉換成SWSFL再對應到BPEL4WS。

圖 19 整合 Web Service 所需參數範例

3.2.2 精簡資訊網服務流程語言(SWSFL)

精簡資訊網服務流程語言(Simple Web Service Flow Language，以下簡稱

SWSFL)是由張嘉漢【27】所提出，在本研究中主要用途在於旅遊行程描述語

言，先轉換以XML為基礎SWSFL再將其轉換成BPEL4WS，如下各表所示，主

要將標籤分成共通標籤、流程控制標籤和互動標籤。

35

表 5 SWSFL 之共通標籤及屬性意義

(資料來源: 資訊網服務整合在旅遊服務之探討)

表 6 SWSFL 流程控制標籤及屬性意義


36

表 7 SWSFL 之互動標籤及屬性意義


為 SWSFL 的標籤結構，第零層標籤為此語言的根元素，第一層

則有、、和共四個標籤，其功能如上各

表所述，第二層則有、、、、和

共六個標籤，其功能如上各所述，第三層則有、

、共三個標籤，其功能為上各表所述。

37

圖 20 SWSFL 標籤結構圖

圖 21為SWSFL轉換旅遊行程描述語言後的範例，標籤主要是描述

和紀錄輸入的參數，主要是描述和紀錄輸出的結果，一個代

表著一個Web Service的執行，例如景點、餐廳或飯店的查詢資訊網服務，或者

是景點、餐廳或飯店的訂購資訊網服務，而圖 22則為SWSFL轉換成BPEL4WS

的部份範例。

38

圖 21 SWSFL 之範例

圖 22為轉換後的BPEL4WS範例，主要是採用BPEL4WS結構化活動之中的

的並行執行功能，標籤之中的標籤主要是定義要執行程序

的名稱，利用來接收所要執行Web Service的參數，來執行Web

Service，來回覆執行的結果，之中的參數的傳遞乃是採用和

來完成。

39

圖 22 轉換後的 BPEL4WS 範例

3.3 旅遊行程規劃模組

平台中提供旅遊者以下的旅遊行程規劃功能：

1. 提供二天以上的行程規劃。

2. 可以讓旅遊者依照自己的喜好來決定行程。

3. 提供旅遊者完善的旅遊相關資訊，如景點資訊，交通資訊、飯店資訊

和餐廳資訊。

4. 自動幫助旅遊者訂購景點門票、餐廳座位和飯店房間。

5. 可讓旅遊者變更行程上的餐廳或飯店。

40

旅遊排程規劃模組主要是讓旅遊者可以透過網頁的介面，來選擇自己喜歡

的景點，進而獲得相關的景點資訊，當旅遊者選好景點之後，便可獲得用餐餐

廳、路徑規劃、住宿飯店等相關旅遊資訊及預訂行程所需要的資訊，等旅遊者

確定好預訂行程之後，平台便會產生「旅遊行程描述語言」，之後就完全由平台

來處理，旅遊者只要等待其平台完成處理即可，以達成一站式旅遊服之中「自

動化」之目標，如圖 23所示。本節將討論旅遊排程規劃模組中的旅遊行程產生

器與旅遊行程轉換器，其中旅遊行程產生器是為了達成一站式旅遊服務中「個

人化」之目標，旅遊行程轉換器是達成一站式旅遊服務中「整合化」之目標。

圖 23 旅遊行程規劃架構圖

41

3.3.1 旅遊行程產生器

旅遊行程產生器主要會透過使用者選擇喜愛景點，經過排程之後再選擇吃

飯的餐廳以及住宿的飯店後，便會產生動態的行程，並產生出「旅遊行程描述

語言」。圖 24為旅遊行程產生器內部架構，由圖中說明了旅遊產生器的執行流

程，主要功能為規劃行程，以及使用景點、交通、飯店和餐廳之旅遊物件，並

達成一站式旅遊服務中「個人化」之目標，茲說明如下。

圖 24 旅遊產生器架構圖

旅遊產生器的主要功能是將旅遊者所選取的景點之後，便交由平台來決定

出午餐及晚餐的景點、決定要住宿的景點，進而找出景點附近有什麼餐廳和飯

店，並透過 ebXML 註冊儲存庫來輔助查詢，以便獲取有關旅遊相關資訊，如

42

景點的簡介、飯店和餐廳的資料，進而再經由如上圖中的四個規劃模組來產生

出「旅遊行程描述語言」，茲說明如下。

規劃景點

規劃景點模組主要功能為根據旅遊所選擇的景點之後，經由交通ebXML

註冊儲存庫所轉換的交通XML檔案格式，取得旅遊者所選取景點的東經與北緯

之後，再透過圖 25經緯度距離公式，求得各景點之間的距離，並經由Greedy

演算法方式來安排景點順序，進而藉由景點ebXML註冊儲存庫所找到所要的景

點旅遊物件。除了獲得景點的相關資訊外，並使用景點所提供的查詢資訊網服

務(Site Query Web Service)，進而呼叫查詢服務來協助平台告訴旅遊者其所選擇

景點是否可以訂購其門票，如此一來便決定出在「旅遊行程描述語言」之中景

點的部份資料。

圖 25 經緯度距離公式

43

44

規劃餐廳

藉由「規劃景點」模組的幫助安排出景點的順序之後，如此一來便可以決

定出每天旅遊者午餐和晚餐所要停留的景點，此時「規劃餐廳」模組便會根據

用餐所停留景點，並透過餐廳 ebXML 註冊儲存庫的輔助，除了找到相關用餐

旅遊物件，景點附近有什麼餐廳以供旅遊者再做進一步的選擇，亦使用餐廳旅

遊物件找尋到所提供的餐廳相關資料和查詢資訊網服務 (Rest Query Web

Service)，進而呼叫其查詢服務來協助平台告訴旅遊者其所選擇餐廳是否可以預

訂其座位，如此一來便決定出在「旅遊行程描述語言」之中餐廳的部份資料。

規劃飯店


定出每天旅遊者所要住宿的景點，此時「規劃飯店」模組便會根據住宿所停留

景點，並透過飯店 ebXML 註冊儲存庫的輔助，除了找到相關住宿旅遊物件，

景點附近有什麼飯店以供旅遊者再做進一步的選擇，亦使用住宿旅遊物件找尋

到所提供的飯店相關資料和查詢資訊網服務(Hotel Query Web Service)，進而呼

叫其查詢服務來協助平台告訴旅遊者其所選擇飯店是否可以預訂其房間，如此

一來便決定出在「旅遊行程描述語言」飯店的部份資料。

規劃交通


定出每天旅遊者的交通路線規劃，此時「規劃交通」模組便會根據景點順序，

並透過交通 ebXML 註冊儲存庫的輔助，並利用交通旅遊物件找尋到所提供的

交通相關資訊，進而幫助平台規劃交通路線出來和提供旅遊者交通資訊，如此

一來便決定出在「旅遊行程描述語言」交通的部份資料。

本平台亦整合PaPaGo系統中路徑規劃中開車資訊功能【31】，以提供自行

開車時路線資訊給旅遊者做為參考，如圖 61所示

圖 26 開車路線規劃

45

3.3.2 旅遊行程轉換器

旅遊行程轉換器主要的功能，在於把旅遊者利用旅遊行程產生器所規劃出

來的行程，再轉換成上一節所提到的「中介排程語言」，將所要訂購和查詢的資

訊網服務的參數整合起來之後，再轉換成可讓 BPEL 引擎執行的 BEPL4WS 檔

案，以達到一站式旅遊的「整合化」目標。

圖 27 複合資訊網服務

如圖 27所示，本研究一站式旅遊服務平台在複合資訊網服務上乃是整合旅

遊者在景點、飯店和餐廳三者不同種類的資訊網服務，目的是將旅遊者所需要

的三種不同類型的資訊網服務整合起來包括查詢資訊網服務 (Query Web

Service)和訂購資訊網服務(Book Web Service)通通整合起來變成BPEL4WS檔

案，再交由BPEL Engine來執行，隨後會再次確認旅遊者在「旅遊行程描述語言」

中的景點、飯店和餐廳皆是可預訂的狀態，都確認可行之後再一起逐一訂購，

來達到自動化訂購的目的，並達成所謂「Workflow-based Federation Query」。

46

3.3.3 旅遊者行程變更模組

旅遊者在預訂好行程之後，再回頭檢視行程時，有時會因某些因素會有更

換飯店或餐廳的需求。為了讓旅遊者可以更自由自主，旅遊者行程變更模組提

供變更的服務，以達到一站式旅遊服務中「彈性化」之目標，其架構如圖 28所

示，其主要程序為刪除、訂購與查詢，茲說明如下。

圖 28 旅遊者行程更改模組

取消(Cancel)

取消程序的主要目的在於把旅遊者原先預計好飯店或是餐廳的訂購先刪

除，這樣一來才不會發生，同一時間旅遊者出現在不同飯店或餐廳的訂單之中。

而取消的過程主要是透過 SOAP 和各 Web Services 之中的 Cancel Web Service

來達成刪除的功能。

預訂(Book)

預訂程序的主要目的在於旅遊者原先用餐或住宿的景點附近的餐廳和飯店

47

48

重新尋找出來，讓旅遊者再一次的預訂新的飯店和餐廳，而預訂的過程主要是

透過 SOAP 與各 Web Services 之中的 Book Web Service 來達成預訂的功能。

查詢(Query)

查詢程序的主要目的在於使用飯店或餐廳的 Query Web Service 來檢查

說，旅遊者所預訂的飯店或餐廳是否可讓其預訂，若查詢未通則返回訂購程序

再一次預訂，而查詢的過程主要是利用 SOAP 和各 Web Services 來達成查詢的

功能。

3.3.4 自動佈署

BPEL4WS執行引擎在佈署(Deploy)資訊網服務的時候，需要使用者自行手

動輸入其資訊網服務，當其數量少的時候尚可接受，但以本研究論文之旅遊情

景，所使用的資訊網服務整合語言BPEL4WS，乃整合了景點、餐廳與交通等多

項資訊網服務的整合，其數量之多將其造成嚴重缺點，在佈署上就必需一個一

個的自行輸入，造成非常多無謂的時間在其佈署資訊網服務上，如圖 29所示。

圖 29 BPEL4J 佈署資訊網服務

本研究一站式旅遊服務平台改善其需手動輸入的缺點，進而改善成能自動

化佈署資訊網服務，大大地減少使用者在BPEL4J上無謂的佈署所花費的時間，

以及當使用者不小心輸入錯誤的資訊網服務所導致BPEL4WS佈署不成功的機

率，如圖 30所示。

圖 30 自動佈署成功畫面

49

50

3.4 註冊儲存庫

為了方便日後，旅遊的景點、飯店、餐廳和交通的新增、修改、刪除等管

理者的工作，以及讓旅遊者可以方便的查詢到景點、飯店、交通和餐廳等相關

旅遊資訊，以達成一站式旅遊服務之中「擴充化」目標。本平台採用 ebXML 註

冊儲存庫來分門別類的景點、飯店、交通和餐廳儲存旅遊物件，茲說明如下。

3.4.1 ebXML 註冊儲存庫 – 交通

在旅遊行程過程中，會有好幾個交通階段，例如以台北旅遊為情境，要從

某點出發到另一個景點，若是搭乘大眾交通工具的話，就需要搭乘捷運、公車

或者捷運轉公車、公車轉捷運，這些相關資訊需事先就要儲存好，讓旅遊者在

使用平台時可以迅速方便查詢所要的交通資訊。

在規劃交通的ebXML 註冊儲存庫之中的旅遊交通物件時，乃先設計其

XML檔案格式後，再對映到其ebXML 註冊儲存庫之中的RO物件以方便管理且

存取，在旅遊平台執行時，若需要交通的RO物件時，也會將其轉換至交通之

XML檔案格式，以方便平台程式處理，如表 8所示。

51

表 8 交通 XML 檔案之標籤之屬性意義

標籤名稱屬性名稱說明

景點列表(profile) 此標籤為此 XML 檔案的

根元素

名稱(site_name) 此屬性代表著此景點的

名稱

東經(east) 此標籤代表著此景點 GPS

東經位置

北緯(north) 此標籤代表著此景點 GPS

北緯位置

抵達捷運站(conveyance) 此標籤代表距景點最近

的捷運站資訊

有無轉乘公車

(transport_bus)

此屬性代表捷運站到景

點是否要轉搭公車

捷運站(station) 此標籤代表捷運站

附近有無捷運站

(station_info)

此標籤代表景點附近捷

運站的資訊

有無(yes_no) 此屬慌說明有或無

站名(station_name) 此標籤代表捷運站站名

公車(bus) 此標籤代表到達此景點

的公車

公車到最近捷運站

(busToconveyance)

此標籤代表著公車到最

近捷運站的資訊

有無需要(yes_no) 此屬性代表著有無需要

公車站(bus_station) 此標籤代表公車站的相

關資訊

車號(No.) 此屬性代表公車車號

交通XML檔案的標籤結構如圖 31所示，第零層的標籤代表著

此XML檔案的根元素，第一層的標籤代表著某個景點，第二層的

標籤代表著此景點的東經位置、標籤代表著此景點的北緯位置，標籤代表著抵達景點的捷運站的相關資訊、標籤代

表著景點附近是否有無捷運站，標籤代表著紀錄到達此景點的公車資

訊，標籤代表著景點公車到達最近捷運站的相關資訊，第

三層的則是紀錄著捷運站站名，則是紀錄著捷運站到景點的公

車號碼，代表著景點附近的公車，第四層代表著景點公

車抵達最近捷運的站名。

圖 31 交通 XML 檔案格式架構圖

圖 32為一交通XML檔案格式的範例，此範例說明了在景點貓空，其東經

為 121.596374，北緯為 24.9674787，抵達捷運站為動物園站，且需要轉乘公車

才能抵達貓空，搭乘公車為 236、237、282、611、指南 1、指南 2、指南 3、10，

貓空附近並沒有捷運站，必須搭乘公車才能抵達最近的動物園站。

52

表 9說明了交通XML格式檔案如何對映到交通ebXML註冊儲存庫之中

RO，其中景點的名稱對映到RO的name屬性，其它的東經、北緯、抵達捷運站、

有無轉乘公車、捷運站…等，皆存放在RO之中的Slot屬性。

圖 32 交通 XML 檔案格式範例

53

54

表 9 交通 XML 格式對映交通 eb XML RR 的 RO

標籤名稱屬性名稱交通 ebXML 註冊儲存庫

之 RO

景點列表(profile)

名稱(site_name) RO.name

東經(east) RO.Slot

北緯(north) RO.Slot

抵達捷運站(conveyance) RO.Slot

有無轉乘公車

(yes_no) RO.Slot

捷運站(station) RO.Slot

附近有無捷運站(station_info) RO.Slot

有無(yes_no) RO.Slot

站名(station_name) RO.Slot

公車(bus) RO.Slot

公車到最近捷運站

(busToconveyance) RO.Slot

有無需要(yes_no) RO.Slot

公車站(bus_sation) RO.Slot

車號(No.) RO.Slot

3.4.2 ebXML 註冊儲存庫 – 景點

在旅遊行程中會安排許多景點，旅遊者須知道或者欲查詢景點的相關資

訊，如景點遊玩的類型、區域、花費時間、網址以及關於景點描述等相關旅遊

資訊，然而這些資訊需事先要儲存好，以方便旅遊者在使用平台時可迅速方便

查詢所要的景點資訊。

在規劃景點的ebXML 註冊儲存庫之中的旅遊景點物件時，乃先設計以

XML為基礎的檔案格式後，再對映到其ebXML 註冊儲存庫之中的RO物件以方

55

便管理且存取，在旅遊平台執行時，若需要景點的RO物件時，也會將其轉換至

景點之XML格式以方便平台處理，如表 10所示。

表 10 景點 XML 格式標籤及屬性意義


景點列表(profile) 此標籤為此 XML 檔案的根元素

景點(site) 此標籤描述著關於景點的相關資訊

名稱(site_name) 此屬性表示此景點的名稱

類型(type) 此標籤表示著景點屬於什麼類型

區域(area) 此標籤表示著景點隸屬什麼區域

網址(website) 此標籤表示著介紹景點的網站

描述(description) 此標籤表示著簡單描述景點

查詢(query) 此標籤表示著景點查詢的 Web Service

訂票(book) 此標籤表示著景點訂票的 Web Service

訂購情形(status) 此標籤表示著景點訂購情形的資料庫

景點XML檔案格式架構如圖 33所示，第零層的標籤為景點

XML檔案的根元素，第一層的標籤是說明某一點景點，第二層的

是說明景點屬於什麼類型的景點;標籤則是說明景點屬於哪個區域;標籤則是說明這個景點約花費多少時間;標籤則是說明介紹這個

景點的網站網址;標籤則是紀錄著此景點的查詢Web Service;標籤

則是紀錄著此景點的訂購Web Service;標籤則是存放著此景點的訂

購情形;標籤則是存放著景點的簡單敘述。

圖 33 景點 XML 檔案格式架構圖

圖 34為景點XML檔案格式的範例，此範例說明在霞海城隍廟這個景點，

其類型歸為古蹟/寺廟，隸屬於大同區，遊玩時間約花費 2 個小時，其中還包括

介紹霞海城隍廟的網站網址，查詢及訂購的Web Service網址，和紀錄訂購情形

的位置。

圖 34 景點 XML 檔案格式範例

表 11說明了景點XML格式檔案如何對映到景點ebXML 註冊儲存庫之中

56

57

RO，其中景點的名稱對映到RO的name屬性，其它的名稱、查詢、訂票與訂購

情形對映到RO之中的Slot屬性，描述則對映到RO之Description，網址則對映到

RO之中的External Links，剩下的區域與類型則對映到RO之中的Classifications。

表 11 景點 XML 格式對映到景點 eb XML RR 的 RO

標籤名稱屬性名稱景點 ebXML 註冊儲存庫之 RO

景點列表(profile) 根元素不必轉換

景點(site)

名稱(site_name) RO.Slot

類型(type) RO.Classifications

區域(area) RO.Classifications

網址(website) RO.External Links

描述(description) RO. Description

查詢(query) RO.Slot

訂票(book) RO.Slot

訂購情形(status) RO.Slot

3.4.3 ebXML 註冊儲存庫 – 飯店

在旅遊行程中有時會需安排住宿的飯店，此時旅遊者須知道或者要過夜景

點附近飯店的相關資訊，如飯店名稱、電話、房間數量、地址、網址等飯店相

關資訊，然說這些資訊需事先要儲存好，以方便讓旅遊者能在使用平台時可以

迅速方便查詢所要的飯店資訊。

在規劃飯店的ebXML 註冊儲存庫之中的旅遊飯店物件時，乃先設計以

XML為基礎的檔案格式後，再對映到其ebXML 註冊儲存庫之中的RO物件以方

58

便管理且存取，在一站式旅遊服務平台執行時，若需要飯店的RO物件時，也會

將其轉換至飯店之XML檔案格式以方便平台處理，如表 12所示。

表 12 飯店 XML 檔案格式標籤與屬性意義


景點列表

(profile) 此標籤為此 XML 檔案的根元素

景點(site) 此標籤描述著關於景點飯店的相關資訊

名稱(site_name) 此屬性表示為某一景點名字

飯店(hotel) 此標籤描述著關於飯店的相關資訊

名字

(hotel_name) 此屬性表示為某一飯店名字

價位(price) 此標籤表示著此飯店的價位

電話(tele) 此標籤表示著此飯店的電話

房間數(rooms) 此標籤表示著此飯店的房間數

網址(website) 此標籤表示著此飯店的網址

地址(address) 此標籤表示著此飯店的地址

查詢(query) 此標籤表示著此飯店的查詢的Web Service

訂房(book) 此標籤表示著此飯店的訂房的Web Service

訂購情形(status) 此標籤表示著此飯店的訂購情形的位置

飯店XML檔案格式架構如圖 35所示，第零層的標籤為飯店

XML檔案格式的根元素，第一層的標籤表示為某一景點，第二層的標籤表示為某一飯店，第三層的標籤表示為此飯店的價位;標

籤表示為此飯店的電話;標籤表示為此飯店總房間數;標籤表示

為此介紹此飯店的相關網站網址;紀錄著此飯店的查詢Web Service位

置;紀錄著此飯店訂房Web Service位置;紀錄著此飯店訂購情

形的位置。

圖 35 飯店 XML 檔案格式架構圖

圖 36為飯店XML檔案格式的範例，此範例說明了在陽明山國家公園這個

景點之中的中國麗緻飯店，其價位為 7000 元起，電話為 02-2861-6661，房間總

數為 47 間，其它還有地址、網址、查詢、訂房、訂購情形等相關飯店資訊。

圖 36 飯店 XML 檔案格式範例

表 13說明了飯店XML格式檔案如何對映到飯店ebXML 註冊儲存庫之中

59

60

RO，其中飯店的名稱對映到RO的name屬性，網址對映到RO的External Links，

其它的景點名稱、價位、電話、房間數、地址、查詢、訂房與訂購情形對映到

RO的Slots。

表 13 飯店 XML 格式對映到飯店 ebXML RR 的 RO

標籤名稱屬性名稱飯店 ebXML 註冊儲存庫之 RO

景點列表(profile) 為此 XML 檔案的根元素不須對映

景點(site)

名稱(site_name) RO.Slots

飯店(hotel)

名字(hotel_name) RO.name

價位(price) RO.Slots

電話(tele) RO.Slots

房間數(rooms) RO.Slots


地址(address) RO.Slots

查詢(query) RO.Slots

訂房(book) RO.Slots

訂購情形(status) RO.Slots

3.4.4 ebXML 註冊儲存庫 – 餐廳

旅遊行程過程中，需要吃午餐與晚餐的餐廳，此時旅遊者須知道或要吃飯

的景點附近餐廳的相關資訊，如飯店名稱、電話、座位數、地址、網址等相關

餐廳資訊，然而這些資訊需要事先就要儲存好，讓旅遊者在使用平台時可以迅

速方便查詢所要的餐廳資訊。

在規劃餐廳的ebXML 註冊儲存庫之中的旅遊餐廳物件時，乃先設計以XM

為基礎的檔案格式後，再對映到其ebXML 註冊儲存庫之中的RO物件以方便管

61

理且存取，在旅遊平台執行時，若需要餐廳的RO物件時，也會將其轉換至餐廳

之XML檔案格式以方便平台處理，如表 14所示。

表 14 餐廳 XML 檔案格式標籤與屬性意義


景點列表(profile) 此標籤為此 XML 檔案的根元素

景點(site) 此標籤描述著關於景點餐廳的相關資訊

名稱(site_name) 此屬性表示為某一景點名字

餐廳(rest) 此標籤描述著關於餐廳的相關資訊

名字(name) 此屬性表示為某一餐廳名字

餐廳風格(type) 此標籤表示著此餐廳的風格

價位(price) 此標籤表示著此餐廳的價位

電話(tele) 此標籤表示著此餐廳的電話

座位數(seat) 此標籤表示著此餐廳的座位數

網址(webseat) 此標籤表示著此餐廳的網址

地址(address) 此標籤表示著此餐廳的地址

查詢(query) 此標籤表示著此餐廳的查詢的 Web Service

訂位(book) 此標籤表示著此餐廳的訂房的 Web Service

訂購情形(status) 此標籤表示飯店的訂購情形的位置

餐廳XML檔案格式架構如圖 37所示，第零層的標籤為餐廳

XML檔案格式的根元素，第一層的標籤表示為某一景點，第二層的標籤表示為某一餐廳，第三層的標籤表示為此餐廳店的價位;標籤表示為此餐廳用餐風格 ;標籤表示為此餐廳的電話;

標籤表示為此餐廳總座位數;標籤表示為此介紹此餐廳的相關網站網

址;紀錄著此餐廳的查詢Web Service位置;紀錄著此餐廳訂房Web

Service位置;紀錄著此餐廳訂購情形的位置。

圖 37 餐廳 XML 檔案格式架構圖

圖 38為餐廳XML檔案格式的範例，此範例則是說明在陽明山國家公園這

個景點附近餐廳之中的雙魚花園，其餐廳風格為西式餐廳，價位約 200 元起，

座位總數約 100 位，餐廳電話為 02-2862-6898，還有餐廳地址、網址、查詢、

訂位與訂購情形等相關餐廳資訊。

圖 38 餐廳 XML 檔案格式範例

表 15說明了餐廳XML格式檔案如何對映到餐廳ebXML 註冊儲存庫之中

62

63

RO，其中餐廳的名稱對映到RO的name屬性，網址對映到RO的External Links，

其它的景點名稱、餐廳風格、價位、電話、座位數、地址、查詢、訂位與訂購

情形對映到RO的Slots。

表 15 餐廳 XML 格式對映到餐廳 eb XML RR 的 RO

標籤名稱屬性名稱餐廳 ebXML 註冊儲存庫之 RO

景點列表(profile) 為此 XML 檔案的根元素不須轉換

景點(site)

名稱(stie_name) RO.Slots

餐廳(rest)

名字(name) RO.name

餐廳風格(type) RO.Slots

價位(price) RO.Slots

電話(tele) RO.Slots

座位數(seat) RO.Slots


地址(address) RO.Slots

查詢(query) RO.Slots

訂位(book) RO.Slots

訂購情形(status) RO.Slots

3.5 旅遊資源服務

一站式旅遊服務平台在執行過程，BPEL4WS Engine 會去呼叫所需要的

Web Service，這些 Web Service 主要分別由景點資訊網服務提供者、餐廳資訊

網服務提供者以及飯店資訊網服務提供者，這些 Web Service 不論是查詢、訂

購或者刪除時，都需要透過個別的旅遊資源服務資料庫來達成，這此資料庫皆

是以 XML 為基礎產生出來分別為景點訂購資料庫、餐廳資料庫和飯店資料庫。

64

張嘉漢(2005)在「資訊網服務整合在旅遊服務之探討」一文中曾利用 XML

建立餐廳、飯店、交通及景點訂購檔案之標籤及屬性意義，本平台延續其研究

並採用了其景點、餐廳，但修改其中飯店 XML 資料格式，以符合本研究需要，

茲說明如下:

3.5.1 旅遊資源服務-餐廳

每個餐廳資訊網服務提供者都有各自的 Web Service，且其中每個 Web

Service 皆可與一站式旅遊服務平台作整合與連結。其中餐廳資訊網服務提供

者，提供 Restaurant query information 以便旅遊者查詢餐廳是否可預訂座位，

及 Restaurant book information 來讓旅遊者預訂座位兩個 Web Service。

在 Restaurant query information與 Restaurant book information兩個 Web

Service在執行過程中，有些資訊需要被紀錄下來，而這些資訊會被存放在餐廳

旅遊資源服務資料庫之中，如表 16所示。

表 16 餐廳旅遊資源服務資料庫之標籤及屬性意義(資料來源，張嘉漢(2005))


標籤為這個 XML 文件的根元素 restaurant

seat seat 屬性表示這家餐廳共有幾個座位 name name 屬性表示是哪一家餐廳

標籤包含了訂餐日期的資訊 date

time time 屬性表示哪一天訂了位置 lunch 標籤包含了訂午餐的資訊 dinner 標籤包含了訂晚餐的資訊

標籤記鍵有幾個座位已被預定 booked

people people 屬性表示是誰訂的座位

餐廳旅遊資源服務資料庫的標籤結構如圖 39所示，每個餐廳的Web

Service都有此格式結構的XML檔案，主要是用來紀錄餐廳所訂購之情形，其中

第零層的標籤代表著這XML的根元素，第一層的標籤代表著

某天，第二層的與這兩個標籤代表著午餐和晚餐，第三層的

代表著座位的訂購情形。

圖 39 餐廳旅遊資源服務資料庫之標籤結構

圖 40為一項餐廳旅遊資源服務資料庫範例，這範例可以看出來是這家餐廳 65

的名字雙魚花園，這家餐廳的座位數有 100 個，在民國 95 年 5 月 4 號的午餐共

被預訂了 9 個座位，晚餐也被預訂了 1 個座位，其中還紀錄預訂者的名字。

圖 40 餐廳旅遊資源服務資料庫之範例

3.5.2 旅遊資源服務-景點

每個景點資訊網服務提供者都有各自的 Web Service，且其中每個 Web

Service 皆可與一站式旅遊服務平台作整合與連結。其中景點資訊網服務提供

者，提供 Site query information 以便旅遊者查詢飯店是否可預訂座位，及 Site

book information 來讓旅遊者預訂房間兩個 Web Service。

在Site query information與Site book information兩個Web Service在執行過程

中，有些資訊需要被紀錄下來，而這些資訊會被存放在景點旅遊資源服務資料

庫之中，如表 17所示。

表 17 景點旅遊資源服務資料庫之標籤及屬性意義(資訊來源，張嘉漢(2005))

66


tickets 標籤為此文件的根元素

amount amount 屬性表示門票

date 標籤包含訂票的時間資訊

time time 屬性記錄某天的門票

booked 標籤包含訂票者資訊

people people 屬性記錄實際訂購者是誰

sell 標籤紀錄售出幾張票

景點旅遊資源服務資料庫之標籤架構如圖 41所示，第零層代表著

此檔案的根元素，第一層的標籤代表著某天的日期，第二層的

標籤代表著訂購者的資訊，第三層的代表著訂購了多少門票。

圖 41 景點旅遊資源服務資料庫之標籤結構

圖 42為一個景點旅遊資源服務資料庫之範例，此範例可以看出為景點陽明

山國家公園，其遊客容納數量上限為 500 人，在民國 95 年 5 月 9 號時，總共有

7 張門票被預訂，其中還紀錄預定者的資訊。 67

圖 42 景點旅遊資源服務資料庫之範例

3.5.3 旅遊資源服務-飯店

每個景點資訊網服務提供者都有各自的 Web Service，且其中每個 Web

Service 皆可與一站式旅遊服務平台作整合與連結。其中景點資訊網服務提供

者，提供 Site query information 以便旅遊者查詢飯店是否可預訂座位，及 Site

book information 來讓旅遊者預訂房間兩個 Web Service。

在Site query information與Site book information兩個Web Service在執行過程

中，有些資訊需要被紀錄下來，而這些資訊會被存放在飯店旅遊資源服務資料

庫之中，如表 18所示。

表 18 飯店旅遊資源服務資料庫之標籤及屬性意義

68

標籤屬性說明

hotel 標籤為此文件的根元素

name name屬性表示是哪一家旅館

rooms 標籤包含房間的一切資訊

room 包含房間的細部資料

nb nb屬性為房間號碼

bootktime 標籤記錄房間在某天被預訂

people people屬性記錄訂購者是誰

飯店旅遊資源服務資料庫的結構如圖 43所示，標籤代表著此檔案

的第零層的根元素，第一層的標籤代表著房間的類型，第二層的

標籤代表著房間的訂房情形，第三層的標籤代表著什麼時候房間被

預訂。

69

圖 43 飯店旅遊資源服務資料庫之結構

為一個飯店旅遊資源服務資料庫之範例，這個檔案主要可以看的出來此飯

店為上林大飯店，其房間數有 20 間，其中 s01 號房的預訂情形在民國 95 年 4

月 3 號及民國 95 年 5 月 4 號被預訂，而且紀錄預訂者的名字。

圖 44 飯店旅遊資源服務資料庫之範例

3.6 聯合查詢(Federation Query)

本旅遊平台使用兩種聯合查詢(Federation Query)，在 ebXML 註冊儲存庫的

聯合查詢稱為 RR-based Federation Query ，在旅遊資源服務則稱為

Workflow-based Federation Query，茲說明分析比較如下:

70

3.6.1 RR-based Federation Query

本一站式旅遊服務平台在 ebXML註冊儲存庫是採用 ebXML特有的

「Hierarchical Repository」，只要將眾多擁有相同處理能力的註冊儲存庫其中之

一設為Federation Home就如同樹的根節點，這樣一來在查詢之時，只要對

Federation Home發送查詢需求，Federaiton便會將查詢需求轉送到其它的註冊儲

存庫，最後會將在全部註冊儲存庫的查詢結果回傳給Federation Home，而這樣

的聯合查詢互作方式本研究稱為「RR-based Federation Query」，如圖 46所示。

圖 45 RR-based Federation Query

本一站式旅遊服務利用 ebXML 註冊儲存庫來管理景點、交通、飯店和餐

廳等旅遊物件，實作上將景點/交通旅遊資訊放在同一 ebXML 註冊儲存庫，飯

71

店/餐廳旅遊資訊則是放在另外一個 ebXML 註冊儲存庫，並將景點/交通 ebXML

註冊儲存庫設為 Federation Home，進而使用 RR-based Federation Query，來尋

找並取得所要的旅遊資訊。

圖 46 RR-based Federation Query 實作架構圖

3.6.2 Workflow-based Federation Query

工作流程(workflow)的最大特點就是將現存的Web Service，經由工作流程

描述語言重新編制之後，產生功能更加完善齊全的Web Service。利用這項特點

再使用工作流程描述語言特有的並行標籤功能，可以同時執行多個Web

Service，如BEPL4WS之中的，本研究一站式旅遊服務平台便採用上述的

工作流程的特點以及BPEL4WS可並行執行Web Service的能力應用在旅遊服務

查詢上，以便查詢旅遊者所規劃出來的預訂行程之中各項景點、飯店和餐廳是

否皆可成行，而這樣並行的查詢功能便稱為Workflow-based Federation Query，

如圖 47所示。

72

圖 47 Workflow-based Federation Query 實作架構圖

3.6.3 Federation Query 比較

本研究採用了RR-based Federation Query和Workflow-based Federation

Query兩種Federation Query方法，各有其優缺點，如表 19比較說明。

表 19 Federation 比較表

RR-based Federation Query Workflow-based Federation Query 佈署方式需設 Federation Home 需有Ｗorkflow Engine，如BPEL4J查詢方式只能Query Forward 依所需查詢需求撰寫Workflow語言描述語言無有如:BPEL4WS、XPDL等

彈性低高

使用易難

上表所表示兩種 Federation 最主要的不同在於描述語言(Script Language)和 73

74

查詢方式，在描述語言方面 RR-based Federation Query 並沒有像 Workflow-based

Federation Query 有類似 BPEL4WS 這樣的描述語言，並提供相關的語法，如 s

循序 (Sequential)、重覆 (while)或者並行 (flow)等，所以在彈性上 RR-based

Federation Query 比 Workflow-based Federation Query 來得低，但 RR-based

Federation Query 因為每個註冊儲存庫的處理方式及能力皆為相同的，所以使

用、整合、和聯合互作上較容易，但 Workflow-based Federation Query 因為每個

Web Service 的能力和參數的不同，導致在其整合上就需要如 BPEL4WS 整合語

言的描述和專業的撰寫，所以在使用、整合、和聯合互作上較困難。

查詢方式在RR-based Federation Query只能用Query Forward方式查詢，由

Federation Home 發出查詢，以階層式向下查詢，最後才將其查詢結果回覆給

Federation Home，如圖 45所示。

而Workflow-based Federation Query則是利用了BPEL4WS的標籤特

性，以達成並行查詢的方式，如圖 48所示，每個Web Service皆在查詢完就可

以個別的回傳其結果，毋須像RR-based Federation Query 在查詢完才將最後結

果回傳給Federation Home。

圖 48 Workflow-based Federation Query

75

附圖目錄附表目錄緒論1.1 研究背景與動機1.2 研究目的1.3 論文架構

相關文獻探討2.1 SOA與 Web Service平台架構2.1.1 服務導向架構(Service Oriented Architecture):SOA2.1.2 XML(eXtensible Markup Language)2.1.3 SOAP(Simple Object Access Protocol )2.1.4 WSDL (Web Services Description Language)2.1.5 UDDI (Universal Description Discovery and Integration)

2.2 Workflow2.3 BPEL4WS2.3 ebXML 註冊/儲存庫標準2.3.1 ebXML簡介2.3.2 ebXML註冊/儲存庫2.3.3 ebXML註冊服務資訊模型2.3.4 Federation

一站式旅遊服務平台架構3.1 以工作流程導入一站式服務概念架構分析3.2 中介排程語言3.2.1 旅遊行程描述語言3.2.2 精簡資訊網服務流程語言(SWSFL)

3.3 旅遊行程規劃模組3.3.1 旅遊行程產生器規劃景點規劃餐廳規劃飯店規劃交通

3.3.2 旅遊行程轉換器3.3.3旅遊者行程變更模組取消(Cancel)預訂(Book)查詢(Query)

3.3.4 自動佈署

3.4 註冊儲存庫3.4.1 ebXML 註冊儲存庫 – 交通3.4.2 ebXML 註冊儲存庫 – 景點3.4.3 ebXML 註冊儲存庫 – 飯店3.4.4 ebXML 註冊儲存庫 – 餐廳

3.5 旅遊資源服務3.5.1 旅遊資源服務-餐廳3.5.2 旅遊資源服務-景點3.5.3 旅遊資源服務-飯店

3.6 聯合查詢(Federation Query)3.6.1 RR-based Federation Query3.6.2 Workflow-based Federation Query3.6.3 Federation Query比較

一站式旅遊服務平台實作4.1 開發工具4.1.1 JDOM4.1.2 AXIS4.1.3 OMAR4.1.4 BPEL4J

4.2 旅遊行程規劃實作4.2.1 旅遊行程產生器實作景點確認和查詢

4.2.2 旅遊行程描述語言 4.2.3 旅遊行程轉換器4.2.4 旅遊行程變更模組實作

4.3 旅遊物件實作

結論與未來發展5.1 結論5.2 應用及未來發展參考文獻

第三章 一站式旅遊服務平台架構rportal.lib.ntnu.edu.tw/bitstream/20.500.12235/... ·...

Documents

第三章一站式旅遊服務平台架構rportal.lib.ntnu.edu.tw/bitstream/20.500.12235/... ·...