第二章文獻探討

(1)

第二章文獻探討

2.1 資訊網服務技術

Curbera[4]等人在研究中提到資訊網服務（Web Service）主要包含 XML、

SOAP、WSDL、UDDI 等四種標準。上述四種都是開放式的標準，因此網際網路

中不同的平台之間可以透過資訊網服務溝通，從傳統人與應用程式之間的「操作

模式」，轉變為應用程式與應用程式之間或者電腦與電腦之間的「溝通模式」。

傳統人與應用程式間互動時，必須開啟瀏覽器，輸入需要的網址跟主機要求網頁

資料，主要由人負責解析資訊，並進行操作；資訊網服務的溝通模式則變為應用

程式之間互相傳遞訊息，客戶端程式可以自動向伺服端程式預訂一張機票，而伺

服端程式回傳預訂的結果。根據 W3C 對「資訊網服務」的定義[5]，一個資訊網

服務會使用 WSDL 定義，而資訊網服務在 W3C Working Group 的定義如下：

A Web service is a software system identified by a URI [6], whose

public interfaces and bindings are defined and described using XML. Its

definition can be discovered by other software systems. These systems may

then interact with the Web service in a manner prescribed by its definition,

using XML based messages conveyed by Internet protocols.

(2)

根據此定義可以了解資訊網服務有兩個特性：第一點，資訊網服務是一個提

供服務的元件。第二點，資訊網服務以網路的開放標準為基礎，並且擁有許多優

點。

依「提供服務的元件」的角度來看，資訊網服務可以用來建構分散式架構系

統，實現分散式架構動態整合、平衡存取負擔、單元升級等優點。而依「網路的

開放標準為基礎」的角度來看，在已經廣泛使用的網路架構上來運作，採用開放

式標準讓資訊網服務具有良好互通性，在不同平台上用不同程式語言建置的系統

也透過使用資訊網服務輕易整合，克服目前分散式系統各自使用不同機制造成整

合困難的情形。

舉一個旅遊的例子來說明資訊網服務在實際應用上帶來的可能性。假設我們

建立一個旅遊網站，網站提供的服務包括旅遊資訊查詢、機票和飯店的預訂和付

款、天氣狀況查詢等，未來只要找到提供這些服務的資訊網服務，並將各個資訊

網服務整合到網站中即可，而不再需要花費時間和資源自己去維護一個包含了旅

遊資訊、天氣資訊的資料庫，不需要再自行建立和各飯店、航空公司的資料聯繫

和訂位付款機制等。這個網站就像是在網路上建立整合這些資訊網服務元件的應

用程式系統。

透過使用資訊網服務，我們不再需要擔心服務所使用的平台、或是依據什麼

技術來建立，而將來有更好的服務或服務提供者時，也可以輕易的將服務更換或

(3)

更新。對系統開發者而言，可以輕鬆快速地將系統建構完成，將心思專注在規劃

更好、更完善的系統上。對服務提供者而言，所需要注意的只有設計出一個良好

的服務，將服務以資訊網服務方式建置，就可以供使用者使用。使用者只要依據

WSDL 的資訊就可以方便的使用資訊網服務，因此資訊網服務必然會成為將來網

路服務之主流。

在下面的小節我們會詳細探討 XML、SOAP、WSDL、UDDI 等四種主要資

訊網服務相關標準。

2.1.1 XML(Extensible Markup Language)

Doug Tidwell[7]在文獻中對 XML 做出解釋，可擴充標記語言（XML,

Extensible Markup Language）是一種可以用來建立自己標記的標記語言。此標準

由 World Wide Web Consortium（W3C）建立，用來克服 HTML（Hypertext Markup

Language）無法標記自己標記語言的侷限。同時 XML 和 HTML 一樣是以標準通

用標記語言（SGML, Standard Generalized Markup Language）為基礎來發展，Doug

Tidwell 文獻中也提到包含第一聯合銀行（First Union）在內，已有許多政府部門

或是企業投入 XML 的研發。

根據 W3C 對於 XML 之定義[8]，XML 是個簡單可格式化的標記語言，可以

自己定義並發展出基於 XML 的標準。因此 XML 被視為網際網路與商業應用的關

(4)

鍵技術，目前有許多基於 XML 的技術正持續發展中。

Barillot 與 Achard 認為使用 XML 來做資料交換，具有以下幾個優點[9]：

z XML 為公開的標準，具有開放的特性。

z XML 是標籤語言，可以自行定義所需要的格式，可被符合定義的應用程式在不同平台中解釋，不會有平台的限制。

z XML 能使用在不同的應用程式，可使用於不同領域的地方。

z 可定義 DTD(Document Type Definition)，藉由定義 DTD 的功能，可以定義規劃 XML 檔案中包含元素的屬性，達成資料結構的統一。

z XML 為純文字的檔案，不會像 Word 的檔案在不同的 Word 版本中，可能會有相容性的問題，因此可以長時間儲存資料，並可依照需要作不同

的呈現。目前根據 XML 延伸出來的標準非常的多，SVG、MathML、

ebXML 等都是。

一個簡單的 XML 檔案如【表三】所示，personData 是 root，檔案中包含兩筆

資料 person，第一筆資料的姓名是 Stella、電話是 0982508034、生日是 09/17/1982；

第二筆資料的姓名是 Maya、電話是 0966024925、生日是 05/08/1982。

【表三】XML 範例

<?xml version="1.0" encoding="utf-8"?>

(5)

<name>Stella</name>

</person>

</personData>

2.1.2 SOAP (Simple Object Access Protocol)

段智華在淺談 SOAP[10]中提到，隨著電腦技術的不斷發展，現代企業面臨

的環境越來越複雜，其訊息系統許多是由多平台、多系統組合而成的複雜系統。

因此現今企業解決方案特別注重廣泛的相容能力，必須支援不同的系統平台、資

料格式和多種連線方式，要求在網際網路環境中，實作鬆散耦合、跨平台、與所

使用程式語言無關並且與特定介面無關的系統，而且必須提供具安全性的網路應

用程式以供使用。

在 2001 年四月份的時候，W3C 聯盟召開了第一次資訊網服務專題研討會，

目的在探索 W3C 應該向什麼方向發展以實作新興資訊網服務架構的標準化，期

間提出了一個「資訊網服務架構」的構想，其中提及 SOAP(Simple Object Access

Protocol )將在資訊網服務架構中用於互相傳遞 XML 訊息時非常基本的通訊協

定，佔有十分重要的地位。

(6)

SOAP 其底層以 XML 格式為基礎。SOAP 本身沒有規定其通訊協定，所以可

利用此特性來整合不同平台上的「遠端呼叫」。SOAP 主要組成有三部分[11]如

【圖七】所示，三個部份分述如下：

z Envelope：SOAP Envelope 是一份 XML 文件，它有兩個子元素、分別是 Header 及 Body。

z Header：用來寫入與應用程式無關的資訊。

z Body：包含應用程式專屬的資訊、如輸出及輸入等資訊。

而一個簡單的 SOAP 範例如【表四】所示：

【圖七】 SOAP 組成三部分

﹝資料來源：Simple Object Access Protocol (SOAP) 1.1[12]﹞

(7)

【表四】SOAP Message Embedded in HTTP Request

﹝資料來源：Simple Object Access Protocol (SOAP) 1.1[12]﹞

POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn SOAPAction: "Some-URI"

<SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelo pe/ SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<m:GetLastTradePrice xmlns:m="Some-URI">

</m:GetLastTradePrice>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

2.1.3 WSDL (Web Service Description Language)

WSDL 是描述資訊網服務的標準，以 XML 為其格式，WSDL 由 Ariba、Intel、

IBM 和微軟等開發商提出。使用和具體語言無關的抽象方式定義用以表達資訊網

服務收發的有關操作和消息。

根據 W3C 的規範說明[13]，WSDL 為 XML 格式用來描述服務與服務傳遞的

訊息資訊，一個 WSDL 檔中需要包含下列幾個部份：

z types：定義使用的資料型態

z Message：為抽象型別，定義通訊的資料訊息名稱與資料型態(types)

(8)

z Operation：為抽象的描述，敘述此服務提供的功能名稱

z Port Type：為 Operation 的集合，定義此服務提供哪些 Operation

z Binding：定義將 Port Type 跑在何種通訊協定之上

z Port：指定 Binding 需要的服務通訊之端點位址

z Service：為多個 Port 的集合，可指定如何存取服務之資訊

一個簡單的 WSDL 檔案如【表五】所示：

【表五】WSDL 範例

<wsdl:definitions name="nmtoken" targetNamespace="uri">

<wsdl:documentation .... />

<wsdl:types>

<xsd:schema .... />

<-- extensibility element -->

</wsdl:types>

<wsdl:message name="nmtoken">

</wsdl:message>

<wsdl:portType name="nmtoken">

<wsdl:operation name="nmtoken">

(9)

<wsdl:input name="nmtoken" message="qname">

</wsdl:input>

<wsdl:output name="nmtoken" message="qname">

</wsdl:output>

<wsdl:fault name="nmtoken" message="qname">

</wsdl:fault>

</wsdl:operation>

</wsdl:portType>

<wsdl:binding name="nmtoken" type="qname">

<wsdl:operation name="nmtoken">

<wsdl:input>

</wsdl:input>

<wsdl:output>

</wsdl:output>

<wsdl:fault name="nmtoken">

</wsdl:fault>

</wsdl:operation>

</wsdl:binding>

<wsdl:service name="nmtoken">

<wsdl:port name="nmtoken" binding="qname">

(10)

</wsdl:port>

</wsdl:service>

</wsdl:definitions>

目前主要實作資訊網服務的平台，大都有自動產生 WSDL 的功能，描述資訊

網服務的存取介面，其功能讓開發者在開發資訊網服務更為容易。

2.1.4 UDDI (Universal Description Discovery and Integration)

UDDI 標準由 OASIS TC(http://www.oasis-open.org)主導[14]，主要目的是讓資

訊網服務提供者登錄自己所提供的服務，讓使用者可以查詢到所需要的程式。目

前 Microsoft、IBM、SAP 三家公司則依此標準共同維護及管理全球商業 UDDI 註

冊儲存庫(Universal Business Registry，簡稱 UBR)，提供 UDDI 在商業上的應用。

透過 UDDI 的機制，可以提供使用者在網路以查詢的方式直接找到需要的服

務在哪邊可以取得，類似我們在生活中可以使用電話簿找到公司的電話，其在資

訊網服務中所扮演的角色如【圖八】所示：

(11)

【圖八】 UDDI 在 Web Service 扮演之角色

（資料來源：http://www.w3.org/2004/10/presentations/claus.ppt）

服務提供者平時將提供的服務登錄於 UDDI 伺服器，當服務使用者要使用

時，服務使用者一開始不知道服務提供者在哪裡，因此服務使用者必須向 UDDI

伺服器提出所需要的服務，UDDI 伺服器收到後回覆服務提供者的 URI，接著服

務使用者才向服務提供者要求服務。UDDI 扮演路標的角色，讓需要服務的使用

者可以找到提供服務的地方。

(12)

2.2 嵌入式系統

目前嵌入式系統已經廣泛運用到人們日常生活之中，許多常見的東西，內部

都是以嵌入式系統開發，小到電子體溫計、血壓計，大到智慧型資訊家電、掌上

型遊戲機以及汽車的控制系統等，內部都是以嵌入式系統開發，提供了生活中高

科技的應用，並有應用越來越廣泛的趨勢。微軟也看準嵌入式系統的市場，宣布

新建 Windows CE 硬體設計中心、微軟嵌入式發展中心[15]。目前最常看到的 PDA

只是嵌入式系統的其中一種應用，將來的 IA 資訊家電，SmartPhone 智慧型手機，

也將都是嵌入式系統的天下。

2.2.1 嵌入式作業系統

目前嵌入式系統盛行，嵌入式的作業系統也跟著蓬勃發展。嵌入式作業系統

與一般作業系統有一個簡單的區別方法，在於是否有沒有硬碟，一般作業系統儲

存於硬碟機中，而嵌入式作業系統都是「嵌入」在可抹寫唯讀記憶體 Flash ROM

中。目前嵌入式作業系統的三大主要使用的為 Palm、WinCE、Linux，三個作業

系統比較如【表六】所示：

(13)

【表六】三大熱門嵌入式作業系統比較表

（資料來源：資策會 MIC，2001/05）

授權程度 /價格

系統大小

所需記憶體

即時性表現

支援硬體

ＡＰ資源

多媒體功能

開發工具

通訊能力

Palm 保守/中小小佳少多普通標準普通

WinCE 開放(特定)/高

大大普通多普通佳標準普通

Linux 開放/免費

小小普通多多佳視廠商

而定

視廠商而定

2.2.2 嵌入式系統開發流程

趙文鵬[16]在文獻中說明嵌入式系統程式的開發流程如【圖九】所示，首先

必須考慮硬體平台支援性，了解硬體平台驅動方式以及支援程度之後，再考慮軟

體平台支援性，也就是所建構的環境是什麼樣的作業系統，如：Palm、WinCE、

Linux 等，以及所要使用的程式語言與編譯器，接著就可以進行應用程式開發，

若應用程式開發不成功，則需要重新檢查硬體、軟體環境支援程度，若應用程式

開發成功，就可以藉由交叉編譯實際移植至嵌入式系統，完成開發流程。

(14)

【圖九】嵌入式系統程式開發流程

在嵌入式系統的開發流程非常特殊，如【圖十】所示，原因在於開發的平台

一般為個人電腦，執行的平台為嵌入式系統，兩者的系統環境並不相同。一般開

發時，開發的平台稱為 Host，執行的平台稱為 Target，我們必須在開發平台使用

交叉編譯（Cross Compiler）產生出執行平台的執行檔後，把該執行檔直接複製到

執行平台中執行，若有問題需回到開發平台做修改後重新產生執行平台的執行檔

再測試。經過反覆修改與測試後，最後沒有問題的版本才使用燒錄的方式寫入到

執行平台的 ROM 或 Flash 中，如此才完成嵌入式環境程式的開發。

選擇嵌入式處理器 (硬體平台)

選擇嵌入式操作環境 (軟體平台)

開發嵌入式應用軟體

測試通過系統測試

開發結果是

否

(15)

【圖十】嵌入式系統交叉編譯示意圖 Cross Compiler

Target 平台之執行檔

執行與測試

個人電腦 開發平台(Host)

修改

嵌入式 執行平台

(Target)

(16)

2.3 電子商務註冊中心－ebXML 2.3.1 ebXML 簡介

ebXML（Electronic Business using eXtensible Markup Language），是開放性

的電子商務建構標準。主要是結合 XML 的技術優勢與網際網路普及性以及低廉

的成本，主要應用在商業領域，達到全球任何產業的企業，皆可透過 ebXML 架

構彼此交流、相互溝通的目的。因此 ebXML 目的即為提供一個以 XML 為基礎開

放性的基礎環境，讓全球市場上所有的參與者能以互通、安全及一致性的方式，

使用電子商務資訊。ebXML 架構由不同的模組構成，每個模組由各個的工作小組

負責，由工作小組研發該模組的技術與規格。[17]

ebXML 主要由兩個組織推動的，分別由聯合國貿易促進與電子商務中心

（UN/CEFACT）以及美國結構化資訊標準推動組織（OASIS）共同推動。ebXML

提出一套完整的技術規範，訂定電子商務中各種功能的標準，其中包括商業流程

的建立、資訊的發掘、訊息的包裝與傳輸等，其目的是使全球企業，無論其規模

大小，都可以透過網際網路進行電子商務交易。藉由這套規範，各個大小公司將

有一套標準可循，用來建立交易夥伴的關係，或是交換商業訊息。在過程當中，

參與交易的公司都可使用共同的術語來交換資料，並定義和註冊商業流程。[18]

2.3.2 ebXML 註冊儲存庫

(17)

OASIS 組織在發展 ebXML 底層的標準方面，訂定了 ebRIM 和 ebRS 等標準，

依據這些標準所發展的內容管理系統通稱為 ebXML 註冊儲存庫（ebXML

Registry/Repository）。目前 Sun Microsystems 公司工程師領導的 Open Source 專

案（OASIS ebXML Registry Reference Implementation Project, ebxmlrr）[19]，所發

展的 ebXML 註冊儲存庫系統主要是依據 OASIS 組織發展的 ebRIM 和 ebRS 等標

準，也是目前市面上可取得的 ebXML 註冊儲存庫系統之一。

ebXML 註冊儲存庫架構是由服務端和客戶端組成，如【圖十一】所示。服務

端提供儲存庫的管理介面，包括交付的物件管理介面(LifeCycleManager；簡稱

LM)、和物件查詢管理介面(QueryManager；簡稱 QM)，客戶端則是提供使用服務

端的介面(RegistryClient；簡稱 RC)。

註冊服務 (Registry Service)

顧客 (Registry

Client)

LM QM

RC

【圖十一】ebXML 註冊服務處架構圖

註冊服務端透過兩個介面：LM(Life Cycle Management)、QM(Query

Management)，提供儲存庫內物件的列管及使用。服務端介面的定義可分成概念

層(abstract level)及實質層(concrete level)，前者定義註冊服務處應該提供的介面、

客戶端

(18)

介面的使用方法(method)、及每一方法所需的參數及回應。概念層並不涉及任何

的製作技術細節。有關製作技術的細節是在實質層定義，ebXML 註冊服務規範

2.0 版說明兩種技術：SOAP 和 ebXML Messaging Service 供參考。註冊服務處可

用任一種技術、或兩者，製作其概念層介面。客戶端可選用適當的技術使用註冊

服務，如【圖十二】所示。

註冊服務 (Registry

Service)

顧客 (Registry

Client)

QM/SOAP LM/SOAP

QM/ebXML LM/ebXML

RC/SOAP

RC/ebXML

【圖十二】ebXML 註冊服務處實質架構圖

顧客端介面(RC)是用來和服務端建立連結關係，介面內有一些方法讓服務端

傳送非同步的回應給客戶端。

2.3.3 ebXML 註冊服務處的資訊模型

ebXML 註冊服務處管理的儲存庫的基本資料單元稱為註冊項目(Registry

Entity)，這些註冊項目的格式是依照 OASIS 組織訂定的註冊資訊模型(Registry

Information Model)標準來實作的。每一個註冊項目均附有詮釋資料，以供註冊服

務處作為註冊項目分類、及其生命週期內的各種控管之用。【圖十三】顯示註冊

服務處資訊模型的類別圖。在註冊服務資訊模型中最重要的核心物件是註冊物件

(Registry Object)，此註冊物件就是註冊項目在儲存庫內的內部表示格式。註冊物客戶端

(19)

件是資訊模型內的基礎類型，所有註冊進入的物件均屬於此一類型。

【圖十三】註冊機制資訊模型圖(UML)

一個註冊物件具有下列屬性：增加屬性欄位(Slot)；描述一個物件和其他物件

間的關聯性(Association)；提供外在識別碼(ExternalIdentifier)；提供額外描述資訊

的外部連結(ExternalLink)；分類資訊，包括分類架構(ClassificationScheme)、分類

節點(ClassificationNode)、分類(Classification)；相同註冊處物件套裝

(RegistryPackage)；稽核事件(AuditableEvent)；使用者(User)；郵寄地址

(PostalAddress)；電子郵件地址(EmailAddress)；組織(Organization)；服務資訊

(Service)；服務方式(ServiceBinding)；服務技術規範連結(SpecificationLink)。

(20)

2.4 全球衛星定位系統(Global Position System, GPS)

全球衛星定位系統(Global Position System, GPS)[20]由美國國防部自 1970 年

開始發展的系統，包含 28 顆人造衛星(其中 4 顆為備用)，主要原理是利用人造衛

星發射無線電波至地面接收器所需時間計算距離，利用三顆不同的衛星能夠計算

出地面接收器的經度、緯度。

2.4.1 GPS 的用途

全球衛星定位系統最初的目的是針對軍事用途開發，目前已逐漸開放給民間

作為定位使用。以往考慮到國防需要，美國國防部對於非軍事用途的 GPS 使用，

長期利用干擾碼的設置，將定位精確度降低，因此民間 GPS 的誤差約在 100 公尺

上下。在這種精確度之下，無法達到一般車輛導航或監控的需求，因此必須提供

輔助系統，以增加定位精度，例如差分全球衛星定位系統(Differential GPS, DGPS)

即為一種，簡單來說，差分全球衛星定位系統是在地面上增設基地台，以修正接

收器的觀測值，其定位精度可達 2 至 5 公尺。

近年來由於民間與商業的全球衛星定位系統用途越來越廣，要求美國國防部

取消人為誤差干擾(Selective Availability)的呼聲相當強烈，於是美國政府在 2000

年 5 月 1 日取消這種限制，如此一來全球衛星定位系統的誤差最佳可達到 10 公

尺左右，大幅提昇全球衛星定位系統精確度。

(21)

2.4.2 GPS 訊息

從 GPS 我們可以接收到的相當多的資訊，從 GPS35LP Series Technical

Specification[21]得知我們可以從 GPS 訊號接收器取得資訊如【表七】所示：

【表七】 GPS 所擷取到之訊息實例

$GPGSA,A,3,01,,06,14,,,,22,25,,,,2.0,2.0,1.0*36

$GPGSV,3,1,10,01,46,335,33,05,15,040,,06,32,112,37,14,68,060,43*72

$GPGSV,3,2,10,16,30,218,29,18,03,160,,20,02,323,,22,36,184,38*71

$GPGSV,3,3,10,25,42,312,35,30,35,039,,,,,,,,,*70

$GPRMC,141134,A,2501.6573,N,12131.7406,E,001.8,006.4,010406,003.4,W*6D

$GPGGA,141134,2501.6573,N,12131.7406,E,6,05,2.0,31.6,M,17.0,M,,*76

表中各標籤代表意義如下述，GPGGA(Global Positioning System Fix Data)傳

遞修正位置座標的資訊，GPGSA(GPS DOP and Active Satellites)可得知 GPS 系統

是否有正常與衛星通訊以及位置定位之精凖度，GPGSV(GPS Satellites in View)

中描述目前定位使用到運作中之衛星，GPRMC(Recommended Minimum Specific

GPS/TRANSIT Data)中描述目前 GPS 所在之經緯度，物體移動速度等資訊。

2.4.3 GPRMC

在本研究中所使用之主要資訊為 GPRMC，接下來我們更詳細的解讀該資

訊，如【表八】所示。

(22)

【表八】 GPRMC 訊息所表之意義

$GPRMC,141134,A,2501.6573,N,12131.7406,E,001.8,006.4,010406,003.4,W*6D

$GPRMC,<1>,<2>,<3>,<4>,<5>,<6>,<7>,<8>,<9>,<10>,<11><CR><LF>

1) 標準定位時間（UTC time）格式：時時分分秒秒（hhmmss）。

2) 定位狀態，A = 資料可用，V = 資料不可用。

3) 緯度，格式：度度分分.分分分分（ddmm.mmmm）。

4) 緯度區分，北半球（N）或南半球（S）。

5) 經度，格式：度度分分.分分分分。

6) 經度區分，東（E）半球或西（W）半球。

7) 相對位移速度， 0.0 至 1851.8 knots。

8) 相對位移方向，000.0 至 359.9 度。實際值。

9) 日期，格式：日日月月年年（ddmmyy）。

10) 磁極變量，000.0 至 180.0。

11) 度數。

12) Checksum.(檢查位元) 。

全球衛星定位系統的應用相當廣泛，在地面運輸方面，鐵路運輸公司利用做

為火車定位與控制之用，防止火車相撞，並可提升系統的運量與效率。在航空運

輸方面，全球衛星定位系統的定位功能協助機上的自動導航系統，在降落或飛行

途中精確定位，下面【圖十四】為全球衛星定位系統於運輸可行之應用。

【圖十四】GPS 於運輸可行之應用

(23)

2.5 開發所需之工具

本研究實作系統的過程中，需要幾種不同的開發工具，主要開發環境使用

JAVA 程式語言，在本研究中主要使用的工具為 AXIS 與 OMAR，JDOM 的功用

在於 XML 檔案之讀取以及寫入之動作，AXIS 主要用途在於資訊網服務之開發，

而 OMAR 主要用於實作 ebXML 註冊儲存庫，接下來的章節我們分別來探討

JDOM、AXIS 以及 OMAR。

2.5.1 JDOM

一般在控制 XML 檔時，W3C 有提供一套依標準所制定出的 API，稱為 DOM

API ，然而對於 JAVA 程式的程式設計師而言，DOM API 卻不能完全滿足 JAVA

程式設計師的需求，Wes Biggs 與 Harry Evans[21]在文獻中提到當我們在 JAVA

的環境中使用 DOM 所面臨到的限制，而會產生這些限制主要的原因在於 DOM

API 並不是專為 JAVA 所設計的 API，因此對於 JAVA 的程式設計師而言並不方

便，支援度也低，而 JDOM[22]卻改善了這些缺點，主要下面三個優點：

• JDOM 是 Java 平台專用的：JDOM API 盡可能的使用 Java 語言中所內 建的 String，因此 Text 也是使用 String 實作。JDOM API 還可以利用

Java 2 平台的類(Class)，如 List 和 Iterator，JDOM 為程式設計者提供

了一個豐富的並且和 Java 語言類似的環境。

(24)

• 沒有層次性：在 JDOM 中，Element 實作了 XML 元素，Attribute 實作

了 XML 屬性，Document 實作了 XML 檔案本身。由於在 XML 中這

些不同的實作都代表了不同的概念，因此在引用時可以依不同的類型

引用，而不是作為一個含糊的「Node」。

• 類(Class)驅動：因為 JDOM 對象就是像 Document 、 Element 和

Attribute 這些類的直接實作，因此創建一個新 JDOM 對象就如在

Java 語言中使用 new 操作符一樣容易。代表著使用 JDOM API 不需

要像 DOM API 一樣進行工廠化介面配置，因此我們可以很簡單的使用

JDOM。

由上述的介紹我們可以得知，在 Java 的環境中，要操控 XML 檔案，對 XML

檔案做存取、處理及輸出 XML 資料之解決方案，最簡單的方法莫過於使用

JDOM，因此在本研究中選擇採用 JDOM 做為解決方案。

2.5.2 Axis

Axis[23]是一個 SOAP 引擎，又不單只是個 SOAP 引擎。Axis 建立在 Apache

SOAP 基礎上的 Apache 專案。此一專案致力於建立一個比 SOAP 更模組化、更有

彈性也更高階的 XML 訊息傳輸架構。透過此架構的建立，可直接由 WSDL 產生

服務架構程式碼，或直接由服務產生 WSDL 描述檔。此專案的發展將使得網路服

(25)

務的開發更有效率。Axis 除了 SOAP 引擎的基本功能還包含：

• 一個簡單而獨立的伺服器

• 可被插入(plugs-in)Servlet 引擎(像是 Tomcat)做為一個服務

• 提供對於 WSDL 提供更多的支援

• 一個發行工具，協助將 WSDL 轉換為 Java 程式碼

• 一些網路服務範例程式

• 一個可以用來監視 TCP/IP 封包的工具

Axis 是 Apache SOAP 的第三代工具(Apache SOAP 是由 IBM 的 SOAP4J 專

案演化而來)。在當時 Apache SOAP 第二版的設計者在討論如何將該引擎設計的

更有彈性、更容易安裝、而且可以同時處理 SOAP 和即將被 W3C 通過的 XML

傳輸標準(也就是後來的 WSDL)。經過一連串的討論和提案，最後開展了 Axis

這個專案。

Axis 最主要的價值就在提供數種簡單的模式協助程式設計師開發網路服

務。包括如下：

• 最簡單的模式，直接可以指定將某個物件以網路服務的方式發佈。Axis

會自動產生相關的程式碼和產生 WSDL。程式設計師不需要去瞭解詳

細的網路服務定義即可撰寫網路服務。

(26)

• 由 WSDL 產生 Java 程式碼。Axis 會產生此網路服務所需使用到的大

部分程式碼，程式設計師只要針對所提供的服務撰寫關鍵的程式碼(例

如服務規則、和後端系統的連接)即可。

• 由 Java 程式碼產生 WSDL。藉由提供 Java 類別或是介面，可產生出

WSDL 定義檔。在經由此 WSDL 產生必要的程式碼，以建構網路服務。

藉由以上數個模式的提供，程式設計師可以更快速的開發網路服務，而不需

要浪費時間在重複程式碼的撰寫。且此專案目前已經成熟並有發布正式 1.3 版，

因此我們採用該工具開發資訊網服務。

2.5.3 OMAR

Tony Graham [24]在文獻中提到 OMAR(Object Metadata and Repository)是由

freebXML.org 依據 ebXML Registry/Repository 標準所開發的下一代開放式程式碼

之實作。同時 OMAR 支援了 OASIS ebXML Registry 3,.0 版的規格中訂定的所有

必要功能與絕大多數的選擇功能，目前這個實作支援多種的客戶端來存取 OMAR

伺服器，包括 browser-based thin client、Swing-based client 與一個命令列的管理工

具。

OMAR 本身使用 SOAP 與 HTTP 協定，同時也支援在 JAXR provider JVM 的

程序中執行。其他 ebXML 的功能還包括 role-based access control、automated

(27)

cataloging of any content、content-based event notification、cooperating registries、

registry-managed version control 與 parameterized stored queries。

OMAR 提供了很多方法供使用者將資料以及該資料的 metadata 放進

repository 中，也提供很多方法讓你對這些資料進行處理，以及將資料由 repository

中取出。

OMAR[18]無論在功能上，或是使用上都逐漸趨向完整，是目前發展狀態最

快的 ebXML Registry 系統，不過也由於目前正處於發展階段，在版本的相容性上

依然有部分的問題存在，而在本研究中採用的是目前最新的 OMAR 3.0 beta1。

(28)

2.6 情境感知系統

Schilit 等人在 Context-Aware Computing Applications[1]一文中提到情境感知

的概念，文中 Schilit 等人表示，人的一舉一動其實與他所處的環境有相當大的關

係，例如人接近圖書館的時候，人所進行的活動就可能就是閱讀、借書或還書，

而當人接近廚房的時候，人所進行的活動就可能是開冰箱或是煮咖啡，因此人與

週遭環境的關係是密不可分的，因此 Schilit 等人定義出情境感知（Context-Aware）

的應用。

2.6.1 情境感知系統功能探討

情境感知應用的原理如下，由於人與週遭之環境為密不可分之關係，因此當

人所身處的環境不同時，情境感知系統應適時地給予使用者其所需要的訊息，而

行動端則使用便於攜帶在身上的裝置實作，如 PDA；舉例來說，當使用者帶著裝

有情境感知系統的 PDA 接近圖書館時，情境感知系統就應該適時的給予如何借

書、還書等訊息供使用者參考，隨著使用者的行動，當使用者移動到廚房時，我

們的系統就應該給予咖啡機的位置，以及咖啡機如何操作的資訊給予使用者，此

即為情境感知系統的用途。

其中 Schilit 等人提到，一個情境感知系統應有下面幾種功能：

1. Proximate Selection：提供使用者介面，列出目前環境週遭中全部的資訊。

(29)

2. Automatic Contextual Reconfiguration：隨著使用者環境的不同，適時的

刪除不再適當的資訊，並能新增新的資訊。

3. Contextual Information and Commands：依使用者的環境給予使用者所需

要的支援。

4. Context-Triggered Actions：有簡單的 IF-THEN 的功能，也就是讓功能可

以依循著特定的規則進行，當某些特定條件符合時，對應的流程就會被

觸發。

以上所提到的四點就是情境感知系統所應該提供的功能，依使用的所需之不

同而將各部份確實建置，來達到情境感知的效果。

2.6.2 情境之定義與分類

在 Schilit 等人[1]在 1994 年定義出情境感知應用之後，Dey 與 Abowd 在 1999

年提出他們對於「情境」（Context）的定義，Dey 與 Abowd 在文中[26]提出：

『所謂「情境」就是任何對現況具代表性且適合之資訊，而此資訊對於使用者與應用程式之間的應用方式有直接的關係，可能指的是一個人、

一個場地或是一個物體，甚至是使用者以及應用程式本身。』

在如此定義之下的情境感知系統，有哪些「情境」可以做為參考的依據呢？

(30)

Wenzhe Zhang、Haibing Guan 等人在 Context-Aware Adaptation for Media Delivery

in Pervasive Computing Environment[27]一文中對其做出歸納，歸納結果有下述四

點：

1. 位置（Location）：如 Schilit 等人所提出，位置與使用者之動態有密不

可分之關係。

2. 時間（Time）：使用者在不同時間同一區域，依然有可能執行不同動作，

例如在廚房環境中，早上的時候會煎蛋煎火腿，到了下午的時候卻可能

是煮咖啡。

3. 網路頻寬（Network bandwidth）：在網路的環境中，我們可能會始用到

多媒體資訊，這時候網路頻寬就必須成為考慮的因素之ㄧ，以圖檔為

例，在低網路頻寬的環境中，我們可能給予 GIF 檔，而在高網路頻寬的

環境中，我們就可以給予 JPG 檔或 BMP 檔。

4. 高階情境資訊（High-level contexts）：真正與使用者有切身關係的資訊，

可代表該使用者獨特的行為模式之資訊，舉例而言，使用者的行事曆資

訊、活動紀錄即是。

前三項所能提供的只是一般化的需求，高階情境資訊很難取得，透過使用者

的自行設定的方式，我們可以獲得部分的資訊，而高階情境資訊正是更具參考價

值，我們也迫切想要了解的資訊。

(31)

2.6.3 情境感知系統規劃

在我們的系統中，我們將情境感知系統依中國人慣用的方式分為五個部份，

分別是人、事、時、地、物，詳細如下所述：

人：使用者資訊，依個人設定之應用方式不同，產生個別化模組。

事：應用程式資訊，系統應有多種不同應用程式，供使用者使用。

時：時間點資訊，提供使用者即時資訊，非傳統無網路導航系統。

地：地點資訊，隨著使用地點不同，套用的應用情境有所不同。

物：傳送資訊，使用者端將人、事、時、地之資訊包裝成 SOAP 訊息傳送，

並藉由 IPv4/IPv6 無線網路傳送 SOAP 訊息。

能感受到情境感知系統優點的時機，在於使用者不熟悉環境的時候，藉

由情境感知系統，使用者可以快速地了解該區域環境，無論是在美術館、博

物館或是任何出差旅遊的地點，透過情境感知系統適時的給予正確訊息，將

避免使用者發生操作錯誤或是行進方向錯誤的情況，是未來開發系統以及提

供服務之趨勢。

第二章 文獻探討