VFP 愛用者社區

Ruey · 註冊時間: 2003-03-12 文章: 1698 來自: tunglo 第 1 樓

首部曲: Web services 與全新的商業模式
作者：李清培

2003 年 04 月

繼 Internet 導入到商業環境後，資訊工業又進行了另一項重大的變革。這一項變革除了影響整個資訊產業的整體概念，包括軟體的設計、銷售、部署、與執行的方式外，更進而影響到整個網路經濟的商業模式。

資訊技術的演進對商業行為的影響
在商業行為深度依賴資訊科技的今天，我想不會有人去質疑資訊技術的改革對商業行為所具有的影響力，只是對影響深度的認知有所差異而已。

拜規模經濟之賜，科技進步的速度常是令人無法想像的，不論是在電腦的運算能力，網路的連結能力，亦或是個人智慧型的周邊設備上，都有驚人的發展。其中在運算能力上，大約每十八個月，CPU 的運算速度就可以加快一倍；在連結能力上，高速的網際網路，以及無線通訊、寬頻的普及，讓人與人、企業與企業間的互動日趨頻繁，尤其在台灣，寬頻的普及率甚至高過美國；另一方面，消費性電子的普及化，豐富的周邊設備，像智慧型手機、手持式電腦、個人數位助理更提供了方便的資訊存取管道；再加上資訊產業的一些標準規範不斷的出現，一個完整的網路經濟環境儼然成形。在這樣的環境下，傳統的商業行為與市場生態勢必受到衝擊。

典型的商業世界與電腦所建立之關係包括：資料處理與儲存、商業邏輯的運算、商務規則的執行、商業流程之整合、電子交易等…，其中最能凸顯商業世界與電腦世界兩者之關係的在於商業規則與企業需求之實現。

商業規則所規範的是一些定義商業行為的典範與策略，通常可能是一些通用的概念或規則，而在這些規則下所產生的特有企業行為則決定了公司的市場優勢。這些特有的企業行為，往往來自於企業自我定義的企業需求。在規劃企業應用系統程式架構的時候，這些特定的需求自然成為應用程式需求的基礎，同時也是程式開發者開發企業程式時所必須依循之規範，企業系統開發者必須儘可能的去滿足這些需求目標。而一但將這些商業規則與企業需求包裹成企業系統程式後，整個商業行為即必須依循這一套系統來運作。因此，一但系統發生任何錯誤或變更時，都可能對企業造成極大的影響。

在建立一套能協助企業達成其營運目標的應用程式系統時，商業規則與個別的企業需求構成了系統分析所需之參數；而電腦系統則在實現商業目標以及與市場互動的優勢上扮演了非常重要的角色，因此形成商業世界與電腦世界密不可分的現象。而隨整科技的發展，這樣的關係更加的緊密，也因此一但資訊技術有任何的改變，企業軟體架構與商業行為也會跟著改變。

企業軟體架構的演進
在 PC 時代來臨以前，電腦的世界屬於大型主機的天下，而電腦的使用者也只是少數 IT 部門的人員。1980`s PC 的到來，改變了部份企業的工作方式，電腦文書處理取代了傳統打字機；1990 年，圖型化介面以及 PC 的網路架構來臨，縮短了人與電腦的距離，並快速地改變了這個世界與商業運作的模式；1995 年 Internet 的到來，推翻了我們原有的溝通方式，全球吹起了一股網路風，豐富的資訊與快速的資訊散佈模式，帶給我們一個全新的電子商務環境。而隨著資訊技術的演變，企業軟體架構也由傳統大型主機與終端機的組合，轉而以PC為操作介面的主從架構或三層式架構為主，尤其是後期分散式運算與網際網路存取架構的大量使用，更是徹底的打破傳統大型主機的做法。並迫使一些主導網路市場的垂直整合系統大廠，紛紛改變策略，開始切割原有的解決方案，提供客戶更彈性的選擇。(這一部份將在談到工具與平台選擇時，再作進一步的說明)

然而，科技的進步是永遠不會遲疑的。我們若將圖型化介面與 Internet 當作資訊產業與商業模式的兩次革命，那麼我們現在正經歷著第三次的產業革命。在跨入 21 世紀的時候，全球將近有三十億的人口使用 Web，企業與企業間的互動日趨頻繁，使用者對網站的要求已不單單只有瀏覽資訊而已，還希望能夠直接編輯、分析、與交換資料，企業開始期待一個嶄新的程式架構，希望能夠讓應用程式、裝置、與企業流程能夠充份的協同合作，另一方面，由於市場變動與競爭激烈，企業也開始企望一套類似人類神經網路的應用程式系統，希望能對快速變化的市場做出即時的回應，這些需求隨著科技的發展變成可能，其中很重要的技術就是 Web services。

不知道您是否注意到一個手機的廣告詞“將無窮的力量，放在一個小盒子裡”，這樣的概念跟 Web services 的系統架構不謀而合。以前講到電腦系統，就是由硬體、作業系統、應用軟體所組成，未來，不只是電腦，任何豐富的周邊設備皆可利用 Web services 的開放式存取能力延伸現有應用程式的功能。

Web services 延伸了來自網際網路及作業系統的概念，讓網際網路本身成為一種全新的作業平台。Web services 擺脫了以往硬體的限制，將資料存放在網際網路中，再透過各種多樣化的平台設備，包括桌上型電腦、手提電腦、手機或掌上型裝置來達到即時傳遞資訊的目的；Web services 能讓您輕鬆地在資料或應用程式間建立連結並完成交易；藉著將多種安全性機制與資料整合到單一使用介面，您不再需要為了瀏覽不同部門或不同網站的資料，而開啟一堆的視窗；Web services 甚至可以是一種可程式化的自動決策引擎，快速的為您作出最佳的選擇；Web services 架構跳脫出目前網頁應用的限制，讓使用者可以隨心隨欲地透過任何裝置，在任何時間、任何地點自由地存取資料或將這些資訊整合於應用程式中，企業的軟體架構也因此而無限延伸。

因此，在 Web services 的世界裡，如果您要問企業應用程式系統的平台在哪裡？您可能必須先回答我Internet在哪裡？因為 Internet 本身就是一個應用程式的平台。也就是說，在 Web services 的世界裡，企業應用程式系統是架構在整個 Internet 之上。

Web services 如何創造全新的商業模式
電子商務雖然泡沫化，但網路經濟卻一直驅策著商業模式的改革。Web services 不同於其他分散式應用程式的重點在於“標準”與“整合”的概念，這兩個概念正好符合目前企業應用程式整合 (EAI) 與 B2B 的需求。若以 Web services 在商業行為中所扮演的角色來分，可以將 Web services 分成兩大應用範疇，第一種是以 Web services 作為企業營運與交易之機制，這一類的用途主要用在企業的整合上，包括資料整合、EAI、B2B、流程管理等；另一種做法則是直接將 Web services 當作交易標的，也就是直接出售Web services的功能服務，包括功能性的隨選服務 (Services-on-Demand)，以及軟體積木等。

對於許多企業而言，使用 Web services 的第一個實作通常會是內部應用程式的整合。利用 Web services 延伸或擴充原有應用程式的功能，或將不同系統，以 Web services 加以連結或整合。Web services 帶給企業系統整合所需之標準與彈性，有彈性的商務模型會讓組織更適應商業環境裡的變化。

另一個驅動 Web services 發展的主要力量則為 B2B 的商業模式。有人甚至斷言供應鏈整合將會是最具威力的 Web services 應用程式。主要是因為供應鏈影響的範圍廣，而 Web services 提供供應鏈應用程式所需之 XML 及相關之產業標準。利用 Web services 加上流程管理軟體，可以讓企業內部或與外部合作夥伴間建立起天衣無縫的作業流程，如此不但能提升企業組織的效率並降低企業經營的成本。

至於將 Web services 當作交易的標地，則可能直接影響資訊系統的設計、部署與採購模式。企業可經由外部所提供之軟體服務，取得執行商業行為所需之應用程式功能，而不需全然由內部來開發。透過這種方式，程式開發者不須再使用傳統建立單一、集中式伺服器應用程式的方法，即可快速地建立或延伸現有應用程式的規模。企業因此可節省系統開發所需之時間，加快市場開發速度。

例如，您如果想在企業的網站上或一般視窗程式上提供像 Google 一樣強大的搜尋引擎功能，您大可不必大費周章地建置資料庫、蒐集資料、分析、儲存、再辛苦地建立搜尋索引；您可以直接使用 Google 所提供的 Web services，就可在應用程式中加入此一功能。(目前這個服務是免費的，請參考 http://www.google.com/apis/)

在軟體銷售/採購的方式則可能改為租用或隨選服務的模式；企業也可以利用 Web services 將原有企業的智慧財產或成功經驗，重新包裝出售，以開拓全新的軟體服務市場。對 ISV 或 VAR、OEM 等廠商，更是提升商品附加價值的方式。

有關 Web services 在商業行為上的應用部份，將會在第三篇的文章中(三部曲: Web services 與企業營運之規劃與策略)作更進一步的解說。在這裡，先以一個實際的例子作說明。

由於工作關係，常常往返於北高之間，最佳的交通工具可就非飛機莫屬了。我是一個到了國外也不太會有時差的人 (反正日夜顛倒習慣了)，而飛機上小睡片刻，可能為一天的工作提供基本的能量，而遠東航空機長優雅的飛行技術，以及體貼的空服員，總是讓我睡得很安穩。在機票的購買上，除了臨時電話訂位外，通常我會選擇透過易飛網 (ezfly.com) 的網路訂位系統訂位。在商業的生態上，易飛網代理多家航空公司的網路機票銷售，提供消費者單一窗口的銷售機制；各航空公司則透過這樣的合作模式，在拓展電子商務的市場上，省卻了網路票務系統的開發成本。但若純粹由航空公司的銷售角度來看，ezfly.com 只是特殊通路中的一種而已。

雖然在開放的市場上沒有誰是誰的客戶，但卻可以透過一些客戶關係管理的機制，爭取客戶再次消費的機會。最常使用的方式通常是所謂的會員制，除了提高客戶的品牌認同以外，大多會再以哩程數、紅利、積點等刺激再次消費，我除了是遠東航空的會員，當然也是 ezfly.com 的會員。在一次偶然的機會，我以會員身分登入到遠東航空的網站，網站上提供了線上訂位的機制，好奇的點選後卻被重新導置到 ezfly.com 的網站，唯一不同於直接登入 ezfly.com 的是網頁上只顯示遠東航空公司的班次。

這時候您是否跟我一樣開始思考，有沒有一套機制，可以讓客戶一直停留在遠東航空的網站上，卻同時能利用 ezfly.com 的票務系統呢？傳統的做法就是遠航自行開發一套網路訂位系統；另外一種則是利用 Web services 直接使用 ezfly.com 的票務系統，遠航只需在自己的網站上提供一張美美的使用者介面就可以了，客戶將一直停留在遠東航空的網站上，而整個交易行為仍由 ezfly.com 的票務系統進行處理。

這樣的網路經濟模式對 ezfly.com 而言，除了原有供應練、B2C的交易模式外，還可將執行多年網路票務系統的成功經驗，重新包裝成 Web services 出售給其他航空公司；對航空公司而言，除透過 ezfly.com 的通路銷售機票以外，也可透過 ezfly.com 所提供的 Web services ，建立自己的電子商務交易機制，並建立起客戶的品牌認同。(以上僅是個人經驗上的認知，若對兩家公司造成困擾，僅此致歉。)

Web services 與分散式應用程式的需求
在了解 Web services 對企業所造成的影響及可能產生的商業模式後，或許您會問，那是怎麼作到的？這樣的模式對企業有什麼好處？我可以利用 Web services 做些什麼嗎？要回答這些問題，我們必須回過頭來，談談 Web services 發展的背景，以及所要解決的問題。

首先，如同前面所說的，Web services 也是分散式應用程式的一種，不管是分散式應用程式、三層式架構、或多層架構應用程式，聽了很多，架構也有很多種，那麼 Web services 又有什麼特別。我們就從分散式應用程式的需求談起。

什麼是分散式應用程式呢？廣義的來講，將應用程式系統分成好幾個子系統，再將這些子系統的程式分別放在不同的行程、不同的機器、甚至不同的國家一起執行以完成共同的任務，那麼這就是所謂的分散式應用程式。但問題是這些程式之間要如何進行溝通呢？這就是各系統或軟體廠商在發展分散式應用程式時所要處理的問題。我們如果以國際貿易來作比喻，不同國家的企業要如何進行交易呢？我們需要一個交易的管道、我們需要一套標準的貨幣機制、我們會依循一般貿易的習慣、我們會訂定一些契約，在雙方認知下才能進行交易。相對的如果回到資訊的世界，兩個跨行程或跨機器的應用程式要能進行溝通，必須有共通的資料格式、共通的應用程式介面、共通的網路環境，當然還要有一套讓兩個應用程式相互認知的機制。為了處理這樣的問題，各家系統或軟體廠商分別提出不同的中介軟體與架構來簡化開發過程。如果以微軟的 DCOM 架構為例，圖 1 列出了分散式應用程式所需的四個基本技術。(對於個別技術在此不多作解釋，我將會在另一個 Web services 系列文章，以技術觀點來談這些架構。) 首先兩個應用程式必須協調好透過什麼管道(通訊協定)進行溝通，再來必須協調好使用什麼樣的資料格式，以及契約書描述的方式 (IDL)，最後則是一套能夠找到遠端程式的機制(探索機制)。有了這四個機制，應用程式之間就可以進行溝通了。

圖 1 DCOM分散式應用程式架構圖

雖然這種分散式的應用程式架構為商業運算帶來了更彈性、更經濟、更具效能的開發與企業營運模式，然而目前各組織或軟體廠商所使用的分散式應用程式架構，如 DCOM、CORBA、RMI 等皆使用自己獨特的一套技術，使得系統整合不易。企業一旦採用某一套架構後，就很難再作改變。當企業面臨應用系統整合的規劃與需求時，總是困難重重；對一堆異質的資料來源，總必須花費許多的雜工才能加以整合利用。每一個系統都成了一個個孤島，更不要說跟其他企業作溝通與整合了。

圖 2 不同分散式應用程式原件物件技術之比較

當這些技術應用在傳統區域網路時，這些問題還不會構成太大的困擾，然而隨著網際網路技術的發展，企業對網站的要求不單單只有瀏覽資訊而已，還希望能夠編輯、分析料、與交換資料；希望能夠讓應用程式、裝置、與企業流程能夠充份的協同合作，這時候，這樣的應用程式架構立刻面臨了嚴重的考驗。

為了解決這個問題，由 WS-I 組織 (ws-i.org) 定義了一套共通的分散式應用程式標準 -- Web services，利用 HTTP、XML、SOAP 和 WSDL 這些標準規範，實現跨平台、跨語言、跨 Internet 的整合目的。透過這樣的開放式標準，應用程式之間可以進行交互作用，並輕易地與其他應用程式分享與共用資訊。圖3所展示的即是利用這四項公開的標準技術，所構成的 Web services 應用程式架構。在眾多的分散式中，如果 Web services 能夠成功，其原因應該是在於“標準”與“彈性”。

圖 3 WS-I 基本規範之分散式應用程式架構圖

Web services 與企業的需求
在了解 Web services 所要解決的程式架構問題後，另一個重要的問題就是，這樣的技術，是否能滿足企業在商業行為上的需求。

各企業在建立資訊系統時的營運目標可能大不相同，但通常可歸納為以下幾點：

即時的取得正確資訊
形成最佳的商業決策
快速反應變動市場
加強與員工及客戶的溝通
員工能力與智慧的激發
產生最佳的投資報酬率

決策的困難往往在於經驗不足與資訊不足。然而透過高速的運算能力、豐富的周邊設備、廉價的寬頻網路、以及標準的資料格式，即時資訊的取得已不再困難，而 Web services 則提供取得資訊所需的軟體架構。若再配合專家系統與決策引擎的建置，由 Web services 提供源源不斷的資訊作為判斷的參考數據，想要“掌握資訊、預測未來”就不是太大的問題了。

傳統取得市場資訊的方式主要來自靜態的新聞，近年來盛行的電子報及電子媒體的即時財經報導，雖然讓資訊的取得更為快速與多樣化，但如何將些資料轉換為決策的參數值，可就很傷腦筋了。雖然許多新聞媒體也提供了網路版的功能，然而要將靜態網頁裡的資料淬取出來也不是一件簡單的事，若能透過 Web services 直接取得這樣的資料，就可以加快資訊取得與分析利用的速度。也就是讓應用程式自己去瀏覽網頁以取的所需的資訊，不過這樣的網頁不是傳統 HTML 的網頁，而是 Web services。

有一位業界資深的系統分析師在為某家連鎖超商規劃應用程式架構的時候，跟我交換了一些意見。其中一部份與即時資訊取得有密切關係的，在此提出一小段與各位分享。在這家連鎖超商的商品中，有一項是近來非常熱門的商品—便當 (市場白熱化的戰爭我想不是今天的主題) 。這項商品有幾項特色，其中替代性太高與保存期限短，限制了每日生產量。在所有參考的變數中有一項是氣象資訊，有沒有下雨、各時段、各地區的氣溫，都可能影響到整體的銷售量。雖然氣象資訊取得並不困難，但能否在決策者的程式介面上，就可以動態的展示最新的氣象資訊，而不需另外開啟另一個氣象資訊的視窗；或是直接將這些資訊當作參數值輸入到應用程式系統中，而不須由人工查詢與輸入。這樣的解決方案並不難，唯一的需求是氣象局必須提供這些資訊的 Web services。

在與員工及客戶的關係上，Web services 同樣的可以發揮效用，除了利用 Web services 提供彈性與客製化的服務外，利用 Web services 所建立的單一簽入與單一整合操作介面，讓客戶以及公司的知識工作者，可以更輕鬆地利用電腦資訊與公司溝通。透過 Web services 可以讓公司的知識工作者，包括分公司、駐點辦公室、或行動工作者，可以輕易的與公司建立連結。

而在變動的市場上，企業要能夠快速的調整，並提高投資報酬率並不是件容易的事。根據經驗值，當企業為反應市場的變動而對應用程式作相對調整時，其最大的成本除開發費用以外，開發期間所產生的機會成本、員工的教育訓練及生產力暫時性降低的成本，都是主要的考量。有一次遇到一位以前帶過的學生，他正在為公司進行一套系統移植與升級的工作，他很緊張的告訴我，老闆給他的條件是花多少錢都沒關係，但如果因為計畫的執行，讓公司少接了一張訂單，那他就不要幹了。

如果開發新系統能夠以模組化的方式進行，可以部分自製、部分外購，即可降低系統開發所需的時間與成本，並加快新產品或新服務導入市場的時間；若能夠將人因操作介面與商業邏輯分開，則可以降低因系統或商業邏輯變更，對使用者所造成的衝擊。這些問題一樣是 Web services 所要解決的。

Web services 的設計目標是讓企業可以透過網際網路，編輯、存取與交換資料，讓應用程式、裝置、與企業流程能夠充份的協同合作。在高度變動與競爭的市場中，資訊收集、管理和使用的方式，即足以決定企業的輸贏；而 Web services 無論在速度、反應、訊息、認知、執行、應用、主導、整合等各方面都提供了絕佳的表現。

平台及開發工具的選擇
若您已準備要開始建置 Web services 的解決方案，那麼，在資訊系統的建置上，平台與開發工具的選擇亦是一個重要的課題，這一方面是否具有像 Web services 一樣的彈性呢？這個答案是肯定的，很多人一聽到平台的選擇，立刻想到 .NET 與 J2EE 的競爭，這樣就完全背離了 Web services 的精神。

拜規模經濟與自由市場之賜，資訊市場早已由傳統的垂直整合轉變為水平整合，因此在平台與開發工具上有更多的選擇機會，更進而降低整體擁有的成本。在傳統的垂直整合市場中，我們幾乎毫無選擇的只能向一家公司購買整個解決方案，從硬體設備、作業系統、應用程式、網路設備和服務，每家廠商都有自己的垂直整合方案，即使號稱所謂跨平台的規範，在各個系統廠商客製化，最佳化、或特殊化的結果的結果，整合不同廠商既困難也不經濟，更不改輕言更換系統。因為整個解決方案從硬體到軟體是環環相扣，牽一髮動全身。再加上軟硬體規格綁死的狀況下，無論建置、服務、與維護成本都高得離譜。尤其以硬體見長的台灣，似乎無法因此取得相對的優勢。

在資訊產品形成規模經濟之後，垂直整合的的架構不再是唯一的選擇。客戶可以在每一個環節上，由硬體設備、晶片、處理器等，到系統軟體、應用軟體、開發工具及系統整合服務等，都可依企業的需求選擇適合自己的產品，雖然原有大型垂直整合廠商仍佔有大部分的市場，但已紛紛改變策略，開始分割並重新包裝原有解決方案，提供客戶彈性的整合。水平整合帶給企業無限的彈性。

目前在實作 Web services 所使用的平台架構包括 .NET 與 J2EE，相關支援的產品與開發工具也非常多。我們將會在最後一篇文章中，再作詳細的比較說明，不過唯一可以確定的是，您不需再像以前被大型系統業者牢牢的綁死，取而代之的是一種超彈性的選擇。未來在規範標準化後，市場的競爭不在於哪一個平台超越另一個平台，而是在於誰能提供快速、安全、與準確的實作能力。

Web services 的限制與展望
雖然前面不斷的展現 Web services 的威力以及為企業所帶來的競爭優勢，然而在本篇文章的最後，我必須說明的是，Web services 並不是萬靈丹。在描繪 Web services 架構的時候，除注意商業規則與企業需求以外，還必須注意程式開發的環境、商業流程以及流程管理；再來則是資訊表示的方式與系統整合，如此才能設計出符合企業需求且具彈性的應用程式系統架構。

另一方面，一般在介紹到 Web services 時，通常侷限在 XML、SOAP、WSDL、UDDI，這對真實企業環境而言，是不夠的，對於個企業級的應用程式系統，可靠度、妥善率、生產力、安全性、擴充性、延展性等 ...，都是不可或缺的，若不能滿足以上的需求， Web services 將只是一個技術名詞而已。目前由WS-I所訂定的規範主要在處理分散式應用程式上的問題，若要將 Web services 應用到全球的商業環境上，仍有些技術必須去克服，例如安全性的問題，交易的保全，訊息傳遞路徑的設定，大型資料傳遞等問題。幸運的是，由 WS-I 的會員組織包括 Microsoft 與 IBM 等，不斷的在協商、訂定一些相關的標準規範，以彌補基本規範的不足，而且截至目前為止，已有相當可觀的成果。更令人振奮的是，隨著這些規範的定案，相對的開發工具或模組也陸續的完成，其中以微軟的 WSE(Web Services Enhancements) 就是屬於這些規範的實作工具。

在未來的幾篇文章中，我們將進一步的探討 Web services 應用程式的架構與設計模式，以及 Web services 所衍生的全新商業模式，當然也會包含平台與工具的選擇，以及導入時機與建議步驟。

Ruey · 發表於: 星期六十一月 15, 2003 2:36 pm 文章主題:

二部曲: 服務導向的應用程式架構
作者：李清培

2003 年 05 月

隨著市場環境的變遷，以及企業規模、型態的轉變，企業為了保有市場上的競爭優勢，大多數會採取 e 化的方式，藉由資訊科技的協助，以最有效率的運作模式，降低成本、提高獲利來達成營運目標。然而基於成本與效率的考量，以及各部門屬性之差異，企業組織在導入資訊系統的初期過程中，大多以階段式、逐一系統的方式進行，且多著重於部門內部業務效能的改善，較少針對跨部門或整體企業作全面之規劃。雖然導入之初可以立即感受到 e 化之成效，但隨著 e 化的部門與系統功能不斷的擴增，由於時空因素的變遷，以及不同的部門、不同的時間具有不同的需求考量，使得企業內的各個系統，形成了一個個的資訊孤島。尤其當整個產業電子商務的動向，由簡單的企業 e 化轉型到講求整體規劃的 ERP 系統時，企業想進一步整合現有系統，則顯得困難重重，而這樣的隔閡，透過以 Web services 作為存取介面的服務導向應用程式架構 (Services Oriented Application Architecture, SOA) 似乎可找到一個不錯的解決方案。

在上一篇的文章中，我們談到了 Web services 的基本概念以及對商業行為的影響。這個月我們將進一步的了解 Web services 的應用程式架構，並了解這樣的架構與企業應用程式之間的關聯；其中最重要的關鍵點在於如何利用“服務導向的應用程式架構”以滿足企業應用程式強烈的“彈性”與“整合”之需求，而 Web services 則是實作服務導向的應用程式架構的最佳典範。

Web services 的意義
為了能正確的將 Web services 導入到企業的系統架構中，在進到本文之前，我想先就 Web services 的定義作一些簡單的說明，並釐清一些容易混淆的疑惑。前一篇文章提到，在 Web services 的世界裡，企業應用程式系統是架構在整個 Internet 之上，Internet 本身就是一個應用程式的平台。然而 Web services 只能用在 Internet 嗎？Web services 只是為了 Internet 而設計的嗎？Web services 不就是網路服務嗎？如果不是，那什麼是 Web services 呢？甚至哪一家平台所提供的才是真正的 Web services 呢？為了能正確的使用 Web services，這些問題的釐清是有其必要性的。

簡單的說 Web services 是一種可透過開放式網路通訊協定存取的應用程式元件，相對於使用者透過網際網路以存取動態網頁的應用程式架構而言，Web services 則是提供一種軟體服務的介面。

有人比喻說，HTML、ASP、Web Forms 等是給人看的網頁，而 Web services 則是給程式看的網頁。就某些角度而言，這樣的說法很容易讓人理解，然而這樣的定義卻常造成一些的誤解，使得 Web services 被歸類為純網際網路的應用技術，因此在系統架構設計上，便被局限於網際網路的應用範疇。也有人說 Web services 是為了解決跨應用程式防火牆的問題，這是一種化果為因的說法。我們若就企業系統整合與溝通的角度來看，用“咫尺天涯”這四個字來形容企業內部的應用程式系統是再恰當不過了。假設兩台比鄰的電腦系統，雖然沒有防火牆與地域之隔，但只要是異質平台的系統，一樣成了一個個的孤島。在這裡要特別強調的是，Internet 只是 Web services 的手段，而非 Web services 的目的。Web services 不是只為了 Internet 而設計，重點在於他是一種使用標準技術的分散式應用程式，可以使用於 LAN、Intranet、Internet 的任何環境，Web services 與以瀏覽器為中心、專注於 HTML 的全球資訊網 (www) 事實上並沒有什麼直接關係，只是技術的名稱有個 Web 而已。

而另一方面，這一兩年，Web services 已成了熱門的名詞，各廠商紛紛宣示擁有或支援 Web services 相關技術，有個在國外從事教育訓練的朋友表示，近來到教育訓練中心學習程式設計的熱門科目即是 Web services，似乎不會 Web services 就是個“looser”。然而對於什麼是 Web services，卻沒有一個統一的說法。對這樣的現象並不需要覺得奇怪，如果您是一位資深的資訊人，回想物件導向應用程式設計初萌階段，同樣存在類似的情形，一直到抽象、封裝、繼承、多型等相關定義完備後，物件導向設計才真正成為應用程式設計的主流，也因此有些專家認為 Web services 技術尚未成熟，還不能用在真實企業環境；但也不乏走在時代尖端者，以比較健康正確的心態去面對這一個技術而造就不少商機；而新加坡政府更於去年 10 月完成全國性的、以 Web services 為核心的公共服務，且截至 2002 年 10 月正式發表時，基於這些核心服務所建立的各式應用服務時已高達一百多種，而最令驚訝的是整個程式撰寫時間只有 11 個禮拜。

我想企業真正要的應該不只是一份定義或規範，而是一套可以真正實現並為企業帶來利益的技術。上一篇文章曾特別強調，Web services 的精義在於整合與標準上，因此在整個規範的定義上就必須依循整合與標準的原則。這樣的原則已由數百家知名廠商所認可，包括 Microsoft、IBM、BEA、HP、VeriSign 等大廠，透過 WS-I 組織的運作，以集體協商的方式共同訂定相關的規範。現在若有任一廠商宣稱某項規範是屬於他們的，那就失去了 Web services 的意義了 (我想大多數人不會願意看到有另一種特殊規範的出現)。因此企業在建立 Web services 應用程式時，只要依循 WS-I 所訂定或審核之規範，自然可以享有 Web services 所帶來的彈性、標準、與整合優勢，至於導入的時機以及企業應用將會在後續的文章中一一介紹。

以上之所以會花了不小的篇幅說明 Web services 的意義以及與傳統 Web 網頁之差異，主要在釐清一些觀點，並減少 Web services 規劃上的限制，使企業在規劃 Web services 時，可以有更多、更大的彈性。接下來我們就來看 Web services 的執行模式與流程。

Web services 的執行模式
Web services 應用程式的執行模式與流程可大致分為四大部分，包括搜尋、發現、認知、溝通等。用戶端程式 (服務需求者) 可在設計階段或執行期動態的依據所需服務之類別、名稱、供應商、識別項、或其他特殊條件進行搜尋與探索的動作，以取得正確的服務。然而前面提過，Web services 的應用範圍包括 LAN、Intranet、Internet 等任何環境，那在“茫茫網海中”如何找到所需的服務呢？我想在您的腦海中可能出現了各種不同的影像。有人可能想到類似網際網路的 DNS 網域服務；有人可能想到目錄服務機制；當然您也可以想像有一種類似電話簿黃頁的服務。其實只要將上述的概念稍加調整，就可能成為不錯的解決方案。在 WS-I 組織所定義的登錄服務技術稱為 UDDI (Universal Description, Discovery, and Integration)，UDDI 目錄提供一個服務登錄的集中位置，透過 UDDI 的服務，您可以尋找公司內部或其他公司所提供的 Web services，或是當用戶端程式找不到原本繫結的 Web services 時，可到此取得最新的服務狀態。當應用程式找到所需之服務後，便可依據所提供之登錄資料找到服務所在位置 (DISCO 規格定義了尋找服務描述的方法)，若用戶端已知道服務描述的位置，便可略過這一個步驟。

下一個步驟則依據所取得的資料，找到服務的窗口，取得服務的描述文件 (WSDL)。用戶端必須知道如何與 Web services 溝通，才能使用它；若要知道如何與特定的 Web services 溝通，就必須了解其服務描述，因此下一個步驟就是認知的過程。最後則是透過標準的通訊協定 SOAP 作為溝通管道，與 Web services 進行溝通，並使用所提供之服務。

或許您會覺得這樣的過程很繁瑣，然而相對獲得的是無比的彈性與方便。還記得我們一再強調的，有彈性的商務模型會讓組織更適應商業環境裡的變化，Web services 則帶給企業系統整合所需之標準與彈性。

各位可以想像，我們可能大部分的時間都在家裡或公司用餐，偶爾外出聚餐，也可能直接走到平日熟悉的餐廳，那是多麼自然的事，菜色、價位等，都是那樣的熟悉。可是當我們出差在外時，這一切都改變了，這些熟悉的資訊不再管用 (當然您也可能走到熟悉的麥當勞等連鎖店)，要如何找到適合自己的餐廳呢？我們可能直接使用飯店內的餐飲服務或隨機的找一家，當然我們也可能拿起電話簿的黃頁，在一頁頁的說明中找到我們心中理想的餐廳 (搜尋過程)，包括地點、價位、服務內容等，當我們選定後，我們會抄下電話、地址，接下來可能以電話先確認 (確認是否還有營業) 或直接前往 (發現過程)。到達餐廳後，除了菜單上所列的項目與價格外，我們可能還會進一步了解消費的方式 (認知過程)，例如有些餐廳可能有最低消費的限制、以及供餐的時段、服務費等；了解消費方式後，我們才進行點餐 (溝通過程)，享受餐廳所提供的服務。

類似這種以服務為基礎的應用程式模式，稱之為服務導向應用程式架構，而 Web services 則是實作服務導向應用程式架構最佳的選擇。那麼，什麼是服務呢？要如何實作服務導向的應用程式架構呢？

服務導向應用程式
所謂服務導向的應用程式架構，就是將個別程式或系統當成一個一個的服務，再利用共通的服務介面進行溝通的一種應用程式架構設計方法。每一個服務具有完整的資料結構與程式邏輯，並透過定義好的訊息格式進行溝通。以 Web services 為介面的服務導向應用程式架構只是其中的一種實作方式。

Web services 服務導向的應用程式架構主要由三個角色所構成，包括服務提供者、服務要求者、服務登錄機制。服務提供者負責建立服務的描述，將服務刊登到服務登錄目錄中，服務要求者則在需要服務的時候到服務登錄目錄尋找服務，至於服務登錄則負責服務的“廣告”代理工作，而整個服務導向應用程式的關鍵在對於服務的相關描述，這些透過服務登錄機制所釋放出的服務描述將影響服務會被採用以及溝通的方式。除了這三個角色以外，服務導向應用程式架構還包含三種重要的活動，包括服務的刊登、服務的搜尋、以及服務的使用。其中服務的刊登與搜尋部分已在前面 Web services 的執行模式中說明，而至於服務使用部分，這牽涉程式對程式、或系統對系統的對話方式，我們將在下節中再詳細的說明。

AP-to-AP 溝通模式的解決方案
應用程式/系統間的溝通並不是什麼新的技術問題，現有分散式運算的方式同樣能提供應用程式/系統間的溝通管道，為什麼還需要所謂的以 Web services 為介面的服務導向應用程式架構呢？這可以由幾個方面來談，包括當初規劃架構時所要解決的問題範圍、所能選擇的技術、以及整個產業的動向。傳統的分散式應用程式技術，大多以解決各自平台內程式互通的問題，且通常是著眼於技術設計與效能的開發，而忽略系統整合這樣較為廣泛的問題。

兩個跨行程或跨機器的應用程式要能進行溝通，最基本的必須有共通的資料格式、共通的應用程式介面、以及共通的網路環境。目前各組織或軟體廠商所使用的分散式應用程式架構，如 DCOM、CORBA、RMI 等皆基於自己的平台與網路環境、使用自己獨特的一套技術。當這些技術應用在傳統區域網路時，這些問題還不會構成太大的困擾，然而隨著產業動向的改變，當企業面對資源整合的迫切需求時，這樣的應用程式架構立刻面臨了嚴重的考驗。資訊產業開始企圖在現有技術的基礎架構下，尋找一套彼此可以溝通的對話方式，這一套技術架構必須是已經成熟的，且為各家所支援的，希望利用這一套技術平台，建立一個統一的溝通管道 (services bus)，在這樣的需求下，Internet 就成了不二的選擇。

以 Web services 為介面的服務導向應用程式架構利用 HTTP、XML、SOAP 和 WSDL 這些 Internet 上的標準技術規範，實現跨平台、跨語言、跨 Internet 的整合目的。透過這樣的開放式標準，應用程式之間可以進行交互作用，並輕易地與其他應用程式分享與共用資訊。利用 Web services 為介面的服務導向應用程式架構，其核心特性之一是將服務的實作與存取介面作分開，也就是一般所謂黑箱作業的方式，所有程式邏輯及服務內容全部包裹在服務內部，僅透過標準的介面與外部作溝通，透過這種高度抽象化的技術，將不再有物件模型之戰或程式語言較勁的問題。

在資訊領域中，利用標準介面取得或提供服務的應用程式架構，可大致分為了兩大範疇。第一種稱為軟體服務的概念，利用上述標準介面的方式，延伸應用程式的功能。另一種則為企業應用程式整合的運用，將各應用程式或系統，利用標準的介面加以包裝成服務的型態，再透過定義好的共通平台進行溝通，這對解決資訊孤島的問題有很大的幫助。以下將分別這兩種架構之應用。

Web services 與簡易的 SOA 使用情境
在所有服務導向應用程式架構的應用中，軟體服務可以說是最簡單的一種。生活中，這種透過標準介面取得或提供服務的方式比比皆是，像我們每天用的電話，或家裡收看的有線電視節目都是。電視機的製造商不需要在出廠時就在機器裡面裝滿一堆不一定符合客戶需求的節目，只需要提供一些標準規格的端子即可。當我們將電視買回家後，只要跟有線電視業者簽好合約 (通常按月付錢就可以了) 並插上電纜接頭，立即可以享受頻道業者所提供的服務。至於什麼時候要看、或要看什麼樣的節目全由您決定。

另一個有趣的現象，自從 PC 時代來臨，電腦文書處理就徹底的取代了打字機，而眾多的文書處理軟體，隨著功能不斷的增加，程式變得越來越大，有些企業甚至在這些現有的軟體上加入許多自訂的功能，實在很難想像這些軟體以後會膨脹到什麼程度。然而，如果仔細想想，在這些應用程式中，可能可以列出一大堆您從來都沒有用過、將來也不會使用的功能，而其他人可能也從來沒有用過您經常使用的某些功能，大多數的功能只是為了滿足某些特殊的使用者。是否可以利用一套機制，讓我們能夠自訂應用程式，使其僅包括您所需的功能呢？軟體服務的概念就提供了這種功能。透過網路所提供的服務，您可以依需要安裝或使用所需的軟體部分，重要的是您可能只需要為您所使用的部分付費，而企業也可以更彈性的增加一些自訂的功能。

同樣的在企業內部，對於一些核心的服務機制 (例如身分驗證)，或非核心的功能性應用程式 (例如計算運費等)，也可以實作成 Web services，以軟體服務的方式提供其他應用程式使用。這些用戶端程式可能屬於不同的應用程式系統、可能來自不同的平台、甚至可能來自網際網路，但都可以使用相同的軟體服務。這樣的做法不只簡化部署及維護的時間，也不須為每一個不同的平台實作相同功能的應用程式，對於程式或系統的瘦身功作，以及未來程式功能的改版都有很大的幫助。因此未來對於電腦的定義將不再只是硬體設備加上作業系統與應用程式而已，還包括延伸自網路的軟體服務。

Web services 與完整的企業應用程式架構
另一種利用 Web services 所實作的服務導向應用程式架構則是在處理企業應用程式整合部分，包括 EAI、B2B、Workflow 等。

對於許多企業而言，使用 Web services 的第一個實作通常會是內部應用程式的整合。對大多數公司來說，幾乎每個部門實際上都採用自訂的一些軟體系統，因此導致許多有用、但孤立之資料與企業邏輯孤島的產生。由於每個程式都基於不同的環境與需求所設計，加上產業技術不斷更新的特性，要在這些應用程式間建立功能性的組合是極具挑戰性的工作。而透過服務導向的設計方法，將每個現有應用程式的功能與資料公開為 Web services，透過標準的 Web services 技術平台進行溝通，便可達到應用程式整合的目的。您也可以採用複合的方式來使用 Web services，利用 Web services 延伸或擴充原有應用程式的功能，或將不同系統，以 Web services 加以連結或整合。

另一個驅動 Web services 發展的主要力量則為 B2B 的商業模式，Web services 提供了建立點對點應用程式的強大的機制。而通常這類方案大多會配合流程管理軟體，進行較複雜的商業邏輯或流程運算。利用 Web services 加上流程管理軟體，可以讓企業內部或與外部合作夥伴間建立起天衣無縫的作業流程，如此不但能提升企業組織的效率並降低企業經營的成本。而 BizTalk Framework 以及 BizTalk Orchestration 技術 (包含於 BizTalk Server 的技術) 則提供 Web services 流程管理所需之服務。有關這一部分的應用，將會在下一篇文章中詳細的說明。

結論
在本篇文章中，我們介紹了服務導向應用程式架構的概念與應用範疇，以及為應用程式延展、擴充、以及整合所帶來的好處。但在最後還是要提醒，服務導向應用程式架構的特性是“彈性”與“整合”，因此如果沒有這樣的需求，是否還需要採用這樣的架構則有待商榷。雖然以 Web services 為介面的存取方式是實作服務導向應用程式架構最直接的做法，但若只是將原有系統在未經分類、規劃、或整合情形下，隨意的包裹起來，或是為了實作此一架構，而將原本完整的系統分割成一個個的服務，這都是系統規劃上常見的錯誤。有關 Web services 的設計與規劃策略，將在下篇文章中進一步的說明，我們下回見。

Ruey · 發表於: 星期六十一月 15, 2003 2:36 pm 文章主題:

三部曲: Web services 之規劃策略
作者：李清培

2003 年 06 月

在上一篇文章中，我們談到了以 Web services 作為存取介面的服務導向應用程式架構，以及其與企業應用程式之間的關聯；其中最重要的關鍵點在於如何利用“服務導向的應用程式架構”滿足企業應用程式強烈的 “彈性”與“整合” 之需求。這個月，我們將進一步的談談，如何將 Web services 應用在真實的企業環境，以及其規劃策略。

Web services 企業運用設計模式
在談到如何將 Web services 導入到企業的系統架構中之前，還要再強調一次，雖然在以下的各種應用模式中，使用的是 Internet 的技術，但 Internet 只是 Web services 的手段，而非 Web services 的目的。Web services 不是只為了 Internet 而設計，重點在於他是一種使用標準技術的分散式應用程式。

分散式應用程式讓企業在建置資訊系統時不論在採購上或建置上都更為彈性，企業可依需要不斷的擴充系統，而不需在初期即一次購足；企業也可以將系統以功能模組的方式分階段建置或升級；企業也可以依實際需求，將資料庫或資訊系統分布在不同的地方，再以網路加以連結。分散式應用程式有助於將商業邏輯集中管理，並取得較佳的安全機制，另外在伺服器與資料庫資源的充分利用以及多樣化的用戶端的設計模式，更是分散式應用程式所帶來的好處。

然而隨著市場全球化以及網路經濟的成形，雖然給了分散式應用程式一個絕佳的揮灑空間。卻也因此突顯了一個嚴重的問題，也就是在上一篇文章中所提到異質平台的問題。理論上，分散式應用程式只要設計得當，便可以將分散在各地的系統與資料整合成一個抽象的大系統，但由於各家系統廠商所使用的技術不同，以及新舊系統技術與設計概念不同，所導致的不相容問題，使得分散式運算的優點大打折扣。因此在發展新一代分散式應用程式時，就企業觀點而言首先必須解決的，是企業內系統整合的問題，包括資料的整合與應用程式的整合，如何讓異質平台或新舊系統間的資料能互通，以及新開發的應用程式能繼續使用舊系統或異質平台的應用程式，以保留就有投資的價值。再來則是跨企業間的程式互通，包括 B2B 的電子商務，以及供應練的整合。最後則是各應用程式的流程整合。而 Web services 則是符合這些需求的重要技術。

除了解決企業全球化與網路化的整合需求以外，延伸自 Web services 的特殊技術，也為企業帶來了另一種商業價值，這種價值來至於 Web services 的商品化，也就是在上一篇題到的軟體服務。這種直接出售 Web services 的軟體服務，包括功能性的隨選服務 (Services-on-Demand)，以及組成應用程式的軟體積木等。

接下來我們就一一的介紹如何將 Web services 導入到企業的真實環境，以及其規劃策略與所帶來的好處。

企業應用程式的整合
對於許多企業而言，使用 Web services 的第一個實作通常會是內部應用程式的整合。利用 Web services 延伸或擴充原有應用程式的功能，或將不同系統，以 Web services 加以連結或整合。

企業應用程式整合工作如果加以細分，包括應用程式的整合、資料整合、與流程整合。關於流程整合在後面再來談。應用程式與資料的整合需求對許多企業來講是很重要的議題。當企業合併或併購時，原本不同企業的資訊系統需要整合成一個完整的資訊系統；開發新的系統必須與舊的系統整合；企業因需求與設計考量，將原本集中式大型主機系統改為分散式應用程式系統時也需要整合，尤其當系統或資料庫是分散在各地時，必須透過 Internet 整合加以整合；再來則是企業再進行軟體採購或委外服務時，為了符合最佳的經濟效率或協力廠商使用技術的限制，常無法取得與原有系統相同技術或平台之解決方案，這時候也需要整合。

企業應用程式整合的市場仍相當龐大，而每個專案動則花費數百甚至數千萬的預算。目前市場上整合的解決方案很多，但大多是一對一的整合，典型的像連結 MSMQ 與 MQSeries 的 FalconMQ。 Web services 則提供另一種全然不同的方法，利用實作標準介面的方式，進行多點的整合。只要將現有的傳統系統可以包裝成 Web Service，便可與企業內的其他系統整合使用。利用這種技術，將複雜的舊系統包裝在標準的 XML 之後，以 Web services 的標準溝通介面，取代原有一對一的整合方式，同時在規劃時，還可以依需要，僅選擇一部分或全部的功能作為整合的介面。

供應鏈的建立與開發
另一個驅動 Web services 發展的主要力量則為 B2B 的商業模式。有人甚至斷言供應鏈整合將會是最具威力的 Web services 應用程式。主要是因為供應鏈影響的範圍廣，而 Web services 提供供應鏈應用程式所需之 XML 及相關之產業標準。在一份由 InfoWorld 針對 CTO 所作的調查統計，70 % 的 CTO 認為 Web services 對企業最有影響的是在 B2B 電子商務上。B2B 應用程式可以像信用卡驗證這樣簡單或者像產業的供應鏈這樣複雜的程式。建置 B2B 應用程式的挑戰結合 B2B 背後的廣大市場潛力是驅使 Web Service 快速改進的原動力。

台灣的 B2B 計畫，最重要的應該是由經濟部技術處主導的 A、B、C、D、E 計畫。其中 A 計畫，讓 HP、Compaq、IBM 將採購資訊下放到台灣來；B 計畫則把華碩、仁寶、英業達等 15 家台灣廠商的資訊與美國採購商搭上線，讓台灣的製造業在世界 PC 市場上，保住一年 180 億美元的市場。A、B 計畫的核心，是以「大廠為中心廠，帶動下游供應商加入」的垂直聯結方式，藉由 Internet 將市場變動的資訊，即時回饋到計畫中的產業，讓廠商可以針對變動來調整庫存。

另一個不同於 A、B 計畫的，則是由下游零組件大廠明基與資策會合作的「星動計畫」，在這個計畫中，Internet 所連結的是一種水平溝通的電子交易平台（Hub），以「水平」的產業平台，取代「垂直」的供應鏈體系。星動計畫是以資策會開發的 viaHub 作為公共平台，讓參與廠商、供應商之間可以跨越不同的系統平台作 RosettaNet 的資料存取。

除了製造業以外，傳統各產業之間其實都存著一套共通的電子交換格式 EDI 以進行 B2B 的資料交換，不同於 Web services 的是，這些交換格式都並須建立產業間特殊的交換平台與資料格式或規範，而 Web services 不需要特定平台，Internet 本身就是一個很好的平台，只需依 XML 的規範，定義各產業的 Schema，即可在共通的標準上進行交易，利用 Web services 建置的好處在於他的建置成本低，參與的廠商利用 Web services 的標準規範建置溝通介面，只需按照各產業所訂的標準定義描述資料的名詞及內容格式即可，例如一比訂單資料應包含哪幾個項目，訂單是用 Orders 還是 PO 來表示等。另外一個好處在於這樣的規範還可以是跨產業的，B2B 不是只有供應鏈而已，還必須考慮金流、物流等，這些都會應用到跨產業的溝通方式。因此，以 Web services 作為 B2B 溝通介面的規劃策略，具有相當大的彈性與經濟效益，也因此有些權威人士認為供應鏈整合將會是一個殺手級的 Web Service 應用程式。

現有與未來應用程式的擴充
由於目前個人所能取得的數位週邊設備相當豐富，除傳統 PC 與筆記型電腦以外，PDA、手機、簡訊等，使得用戶端程式的客製化顯得非常重要，其中尤以手機最回嚴重，由於消費性產品的市場化，各家在樣式上求新求變，使程式開發工作更為困難。Web services 繼承自分散式應用程式商業邏輯集中的優點，可以快速開發多樣化的用戶端程式。只要將商業邏輯以 Web services 呈現，再針對不同用戶端撰寫資了展示的方式就可以了。目前市場上的用戶端程式開發工具，大多數都支援 Web services 的存取，其中 Visual Studio .NET 更可以在單一的畫面裡面，完成所有應用程式的開發。

然而對大部分的企業而言，許多的商業邏輯都已寫完，而且行之多年，不可能為了開發一隻手機的程式，而將整個程式重寫。前面提到，Web Service 提供一組吸引人的技術，就是將現有的傳統系統包裝成 Web Service ，以提供其他應用程式使用。藉由這種方式，不只可以享有 Web services 所帶來的便利，更可因此延伸原有應用程式的生命週期。

在這裡舉一個典型的例子，在擔任 .NET 開發技術的講師與顧問的兩年多時間裡，最常碰到的問題是有關 ASP.NET 網頁設計的問題。由於 ASP.NET 提供像 VB 開發視窗程式一樣拖曳的視覺化開發環境，使得很多人就習慣性的將兩者拿來比，但事實上這兩者還是又差異的。網頁的程式，由於透過 Internet 在伺服器上執行完畢後，再將結果傳回用戶端展示層，因此有其先天上的限制。

很多人會希望能符合老闆以及市場形象的需求，使用 Web based 的架構，(在一些特殊的各案中，企業選擇 Web based 的原因是因為老闆認為這樣才跟得上時代)但用希望像視窗程式一樣的使用者操作介面，其實透過 Web services 就可以解決這樣的問題。

另外一種則應用程式擴充的例子，則是將應用程式系統分為核心程式與服務程式，將必要的程式邏輯部分也在核心程式，在以 Web services 的方式依功能分類，撰寫各個服務程式。可以將核心程式當作是主機板與 CPU 等重要元件，而各個服務程式則有如週邊設備一樣,可依需要隨時擴增。

降低系統建置的時間與成本
除了解決應用系統整合與溝通上的問題外，對於新系統的開發，Web services 也可以降低開發的時間與成本，這一類的設計模式大概可分為幾種狀況。

第一種稱為軟體積木的開發方式，企業直接利用 Internet 上的 Web services，以軟體積木的方式，加快系統開發的速度，尤其對於一些輔助性的功能，或一些共通的商業智慧。在上一篇文章中，我們也舉了 Google 的例子，您可以直接使用 Google 所提供的 Web services，就可在應用程式中加入此一功能。除此以外，由微軟我提供的 .NET My Service 也提供了非常多的軟體積木可供使用，其中最為熟悉的應屬 Passport 驗證機制。

另外對於新市場的開發，企業往往必須重新熟悉這一個市場的商業邏輯或專門的技術，而透過 Web services 的服務即可快速的修正系統的功能，以加快新市場的開拓。例如企業在進行全球貿易時，除了基本的商務應用程式外，可能還會建立連接貨運倉儲部門與國際貨運公司間的 B2B 運輸系統。這樣的系統通常是以緊密結合的方式所建立，也就是企業的資料庫裡，必須知道貨運公司的價格、航班、週期、速度等。當企業的業務拓展到新的國家時，如果原有的貨運公司無法到達時，這時候只有兩種選擇，第一是放棄市場，第二是重新洽談另一家貨運公司，重新改寫程式。但如果反過來，這些 B2B 的關係是建立在 Web services 的連結上，只要透過 UDDI 找到所需的服務，便可輕易的進入新市場。

再來則是企業在提供全球技術服務時，也可以利用 Web services 來達到技術支援的目的。例如目前主要汽車大廠的服務點都以全球部署作為其市場競爭的利器。而針對高階人士設計的筆記型電腦，為因應國際商務的需求，也都強調全球保固的服務。然而這也衍生一個問題，由於服務點遍佈全球，各地的技術水平並不一致，如何達到相同的服務品質，則是一個很大的考驗。

以汽車廠為例，假設今天擁有一部數百萬的進口名車，在台灣要找到維護場並不難，但今天如果在某些落後國家，狀況可能不一樣了，即使原廠所設的服務點，也會應當地的技術人力，而有所不同。幸運的是，目前大多進口名車都採取電腦診斷的方式以進行故障排除，因此只要能提供詳細的檢修步驟，讓維修人員按照步驟完成檢修工作。

然而這樣還不能完全解決問題。由於修護系統的高度機密與價值，不大可能在所有的地方都建置一套這樣的系統，這時又是 Web services 發揮其強大功能的時候了。這些汽車大廠可依各服務點的規模及技術能力等，建置一般功能的維修檢測系統，以應付一般性的檢修工作，對於重大的或具機密性的技術，則至於原廠或各地區之核心廠。當各小型檢修場無法判讀汽車電腦晶片內的數據時，再透過 Web services 連接原廠或各地區之核心廠取得相關檢修步驟。如此不但保有技術的機密性外，又可符合全球服務的需求，更重要的是，當擴點需求產生時，可加快建置的時間，而當重要的技術問題產生時，只需更新原廠或各地區之核心廠的資料庫，即可將資料傳送至全球的檢測系統。

軟體租用新模式
以上所舉的例子都是以使用者的角度區看，在上一篇文章中提到服務導向應用成架構實提到，參與這個架構的還包括服務提供者與服務登錄與代理兩個角色。前面也提到Web services本身也可以當作一項產品來販賣。出售服務的架構其實到處都有，只不過型式不同罷了，目前網際網路裡面，線上刷卡代收服務是最典型的例子。

將 Web services 當作交易的標地，可能影響到資訊系統的設計、部署與採購模式。企業可經由外部所提供之軟體服務，取得執行商業行為所需之應用程式功能，而不需全然由內部來開發。透過這種方式，程式開發者不須再使用傳統建立單一、集中式伺服器應用程式的方法，即可快速地建立或延伸現有應用程式的規模。企業因此可節省系統開發所需之時間，加快市場開發速度。

對服務的提供者而言，大概可以有幾種模式，第一種可能在軟體銷售/採購的方式改為租用或隨選服務的模式；這裡提到的租用與隨選服務事實上是有差異的。ISV可以將核心程式及部分的模組直接安裝於客戶端，以租用的方式實施，而為了避免租期與租金的爭議，可保留一小部分的啟動機制至於ISV的伺服器上。在租約期間，客戶透過Web services機制，聯結至ISV啟動其應用程式；租約到其，ISV僅須關閉此一機制即可。至於隨選服務，則針對一些工具服務，或延伸的功能，讓客戶依需要連結使用。

企業也可以利用 Web services 將原有企業的智慧財產或成功經驗，重新包裝出售，以開拓全新的軟體服務市場。對ISV或VAR、OEM等廠商，更是提升商品附加價值的方式。

對於一些電子資訊提供者，也可以改變提供的格式，目前大部分都是透過電子郵件或網頁瀏覽方式，未來也可以利用Web services提供相同的資訊，讓用戶端可以直接加以利用，將Web services當作資料來源，直接提供應用程式存取。例如在設計網頁時，若希望能取得氣象、股票、球賽、產經最新消息，只要將所需之資訊版面空下，利用網頁上的控制項直接連結個資料來源之Web services，即可取得最新的資訊。而服務的提供者則可依訂戶的需求收取不同之費用。

企業流程管理
最後則來談談流程整合的部分，之所以會流到最後在來講，主要上避免在談到流程整合時，只侷限在企業內得整合。利用 Web services 加上流程管理軟體，可以讓企業內部或與外部合作夥伴間建立起天衣無縫的作業流程，更可依需要不斷的加入應用程式模組，而不影響到其他的應用程式，這些模組可以自行開發，也可以直接使用ISV所提供資服務。如此不但能提升企業組織的效率並降低企業經營的成本。或許您要問，目前已有很多的流程管理軟體與跨平台整合軟體，位什麼還要有 Web services，這是因為這些軟體都是為個別系統接整合所設計，即使主要大廠所提供的流程管理軟體，包括 Microsoft、IBM、BEA 等，也須為不同的 Adapter 付出不同的軟體授權費，若採用 Web services 則不須為不同的系統就要採購另一套整合或流程軟體。

導入時機
看完了以上的文章，或許會懷疑，這樣的技術成熟了嗎？我需不需要導入？要如何導入？而且在前兩年，資訊界還傳著一個很奇怪的說法，雖然各主要大廠及 WS-I 組織以提供相當完整的規範與技術，但還是有些所謂權威人士會說 Web services 是個不成熟的技術，還不能導到企業中使用。雖然對於全面性的將 Web services 應用到全球的網路經濟還有些技術與規範要克服的，但也有不少廠商與政府或非政府機構以成功的導入 Web services。若要等一套技術完全成熟在一次導入，那時候可能又已經推出另外一套更新的技術，或許我們把他當作是一種市場競爭的手段罷了，對於技術跟不上速度的廠商，通常會以這種方式以減緩對手搶攻市場的速度。下回我們再來分析哪些技術是可以導入的，哪些是還有限制的，哪些是目前不可行的，以及導入的步驟。我們下回見。

Ruey · 發表於: 星期六十一月 15, 2003 2:37 pm 文章主題:

後章：Web services 之導入與平台選擇
作者：李清培
弈飛資訊首席顧問
台灣微軟特約資深講師

2003 年 07 月

在前幾篇文章中，我們由商業世界與電腦世界的關係談起，再談到 Web services 的發展背景與商業行為之改變，接著則進一步介紹 Web services 的應用程式架構，並談到如何以服務導向的觀念，將商業行為對應到資訊系統服務架構，上一篇文章中我們也針對 Web services 在商業行為上的應用以及其規劃策略作了一些說明，然而，看完了以上的文章，或許會懷疑，這樣的技術成熟了嗎？我需不需要導入？以及要如何導入？以下我們就來介紹如何導入 Web services 以及不同平台與開發工具之比較。

導入時機與步驟
新技術的導入，往往決策本身就是個很大的挑戰，需不需要導入、何時導入等問題就可以讓決策人員傷透腦筋。當然有些企業可能因企業文化或營業項目的需要，總是一味的追求新的東西，只要有新的技術就照單全收，這一種適合以技術服務或IT顧問服務為主要營業項目的公司。另一種模式則恰好相反，是屬於極度保守的，通常要等到同業都作了，或是有更新的技術發表(原本的新技術已經變成舊技術了)，甚至舊技術已經找不到資源了，才想到要更新，這種做法通常是對資訊技術依賴不大，或公司年代久遠，舊系統資料龐雜不易更新的企業。在擔任企業 SQL Server 2000 的技術支援經驗中，有幾個升級個案便是從 NT 3.51 加 SQL 4.2 直接升級到 Windows 2000 與 SQL 2000。當然也有一些是想由 DOS 系統升級上來的案例。不過，一般會對這篇文章有興趣的，就算不是新知的絕對追求者，也不大可能是極度保守的人，至少都是對新技術具有一定接受度的朋友；當然絕大部分也不會是所有新技術都照單全收的。因此，既不能照單全收，也不能枯等坐失良機，那麼何時才需要導入 Web services 呢？要回答這個問題，以下幾項參考依據可供您在作決策的參考：

企業應用程式架構，使用元件或物件的程度。
開發部門對「存放與轉寄」的訊息架構 (Store and Forward) 是否了解。
是否想將一些客製化的應用程式產品銷售到開放市場。
使用 Web services 是否能為企業帶來市場競爭優勢。
使用 Web services 的開發模式，是否可以為企業降低成本。
以上問題可以歸類為兩大部份，首先是評估企業對物件導向 / 訊息架構的使用成熟度，這一部份將會牽涉到 Web services 的實作能力。雖然物件導向程式已經發展多年，許多的 ISV 也都宣稱以物件導向的方式在開發應用程式，但在個人輔導企業的過程中，常常發現有些企業應用程式，仍然是功能函數導向的設計方式，只是利用物件將一些函數整合在一起而已。另一方面則是評估導入 Web services 對企業所帶來的實質利益在哪，任一項技術的導入，都必須有其價值存在，不是為了導入而導入。如果您的企業已經具有開發、建置、或使用 Web services 的能力，而且也清楚的了解 Web services 能為企業帶來什麼，那麼現在就是最好的導入時機。如果您的開發人員還不具有開發 Web services 所需的技能，也找不到相關可提供技術支援的合作夥伴，或是您還無法明確的了解 Web services 未來在企業應用程式中所佔的角色，那麼目前先不要急著導入。

以上的判斷方式是來自於企業內部的內省；另一個判斷的方式則是來自外在的，例如產業的趨勢，或合作夥伴的要求等。尤其當企業對 Web services 的應用還不是很明確的時候，參考業界的案例或產業的趨勢，也是一個很好的方法。雖然目前台灣真正完全導入 Web services 的不多，但全球已有許多成功的案例可供參考。在上一篇文章中，我們也介紹了幾種 Web services 的應用與設計模式，如果將全球使用 Web services 的方式加以分類，大致可分為三大類：第一類為利用 Web services 強化內部商業流程的效率與降低成本的做法，最典型的就是用在企業應用程式整合 (EAI) 上，或是利用 Web servcies 延伸舊有應用程式的功能或提供 Internet 的存取介面，以減少開發網際網路應用程式所需的時間與成本；第二類是利用 Web services 處理 B2B 的交易，也就是在第二篇服務導向應用程式所說的 Services-Bus 的觀念。Web services 在 B2B 市場中所具有的最大優勢在於它比目前所有的 EDI 應用程式都要簡單，大幅降低了許多程式的複雜性，而且架構更為標準與彈性。可以預期的，隨著 B2B 市場的擴大，Web services 在網際網路技術的覆蓋率將越來越高；第三類則為利用 Web services 提供個人或公共服務。實務上企業利用外部所提供的專業性軟體積木來開發應用程式，或提供軟體積木給其他企業使用的不多；而提供免費公共服務的則以微軟的 .NET My Services 為代表；除此之外，前面介紹過的 Google 所提供的搜尋引擎 Web services 也是很典型的一種軟體服務。企業可參考上一篇所介紹的各種應用模式，如果其中某一種模式恰巧可以解決企業目前所面臨的問題，或著可以預期地為企業帶來相當的利益，或許您也可考慮導入 Web services。

經過上述由內而外的考量之後，下一步就是決定是否要導入 Web services。如果答案是肯定的，接下來再依據自身的能力，選擇適當的建置方式，並著手進行規劃與規範訂定，最後再依據規範及所選擇的建置方式，選擇適合的平台與工具進行實作。接下來就來談談建立 Web services 的方法。

建立 Web services 的方法
雖然說企業在導入 Web services 之前，必須先衡量自身掌握 Web services 的能力，但並不代表企業必須由無到有去實作 Web services。我們一再強調 Web services 的好處在於開放的標準與彈性，標準的東西讓企業應用程式系統可以跨平臺的整合，而彈性的架構意味著可以依企業需要，以模組化的方式加以組合。只要依循產業的標準，就可以將不同平臺的應用程式系統，不管是硬體也好、軟體也好，都能夠整合在一起，既可保障企業原有的投資，更可改善工作流程提供生產力。也因此在 Web services 的實作上就有很多的方法可以選擇，以下介紹幾種可行的方案以供參考。

首先可以依企業的技術背景選擇系統或軟體供應商所提供的應用程式伺服器平台，這些專門為 Web services 所設計的應用程式伺服器平台通常包括一整套的開發、展示、與部署工具，以協助開發人員快速建立 Web services，同時各供應商通會在平臺中提供一些加值的軟體服務，可能包括流程管理軟體、安全機制、交易處理機制等底層服務，以減少開發人員的負擔，並降低程式的複雜性。目前市場上的應用程式平台可分為兩大類，一種是提供完整的開發環境、硬體設備、及專業的服務，這一種模式比較像傳統垂直整合的 SI 公司做法，其中以 IBM、Sun、HP 為代表，詳細部分在後面市場概況再作說明。另一類則以 Microsoft 與 BEA 為代表，以水平整合的方式，提供完整強大的開發環境及相關的底層架構為主，並不以銷售硬體為主要獲利來源，因此企業可以有更彈性的選擇，尤其當 Web services 走向標準後，實在沒有道理在綁在某一種硬體、平台或程式語言上，應該是一種跨硬體、跨平台、跨語言的解決方案才對。

第二種方式，若企業具有強大的開發能力，則可以選擇直接採購或取得適當的開發工具，自行開發 Web services 應用程式。目前除各家大廠所提供的 SDK 外，最主要的還是由開放原始碼的 Apache XML 專案所提供的許多開發工具。不過選擇這種方式企業必須自己有能力處理不同應用程式間整合的問題，同時還必須進一步的自行加強或建置應用程式伺服器的環境，包括底層服務、流程管理與其他加值服務。通常選擇這種做法的結果，都會再結合第三種做法，或是回到前面再找系統廠商協助，也因此有些硬體廠商會先以開放原始碼的方式先導入，事後再收取高額的顧問服務費。因此除非開發團隊的技術能力夠強，或是系統實在是很簡單，否則還是不要選擇這一種方式。

第三種做法就是委外服務的做法，可以直接請 IT 顧問廠商協助開發，或直接交由合作廠商代為開發。

最後還有一種做法雖然目前不大可能，但未來卻很有遠景，也就是之前提到過的軟體積木或軟體服務。由 ASP 業者將軟體元件或商業智慧以 Web services 的方式提供給客戶使用，並收取一定的服務費。但礙於目前交易機制、安全機制、商業智慧、目錄登錄機制、及收費機制等還未完全建立，應此還不適合在開放市場中直接銷售 Web services。由 ASP 業者提供軟體積目或軟體服務，企業只要依其需要加以組裝即可。或許有人認為這不大可行，在微軟以前，也沒有人相信軟體可以獨立於硬體而單獨銷售。然而當軟體與硬體的分開銷售的模式形成後，也使得資訊市場由傳統的垂直整合轉變為水平整合的競爭環境。

選擇平台及開發工具
若您已準備要開始建置 Web services 的解決方案，那麼，在資訊系統的建置上，平台與開發工具的選擇亦是一個重要的課題，這一方面是否具有像 Web services 一樣的彈性呢？這個答案是肯定的，很多人一聽到平台的選擇，立刻想到 .NET 與 J2EE 的競爭，這樣就完全背離了 Web services 的精神。Web services 特色之一就是要讓應用程式之間很容易的整合及溝通，而不論所使用的是哪一種語言與平台，在傳統的垂直整合市場中，我們幾乎毫無選擇的只能向一家公司購買整個解決方案，從硬體設備、作業系統、應用程式、網路設備和服務，每家廠商都有自己的垂直整合方案，即使號稱所謂跨平台的規範，在各個系統廠商客製化，最佳化、或特殊化的結果的結果，整合不同廠商既困難也不經濟，更不改輕言更換系統。因為整個解決方案從硬體到軟體是環環相扣，牽一髮動全身。再加上軟硬體規格綁死的狀況下，無論建置、服務、與維護成本都高得離譜。尤其以硬體見長的台灣，似乎無法因此取得相對的優勢。

在資訊產品形成規模經濟之後，垂直整合的的架構不再是唯一的選擇。客戶可以在每一個環節上，由硬體設備、晶片、處理器等，到系統軟體、應用軟體、開發工具及系統整合服務等，都可依企業的需求選擇適合自己的產品，雖然原有大型垂直整合廠商仍佔有大部分的市場，但已紛紛改變策略，開始分割並重新包裝原有解決方案，提供客戶彈性的整合。您不需再像以前被大型系統業者牢牢的綁死，取而代之的是一種超彈性的選擇。未來在規範標準化後，市場的競爭不在於哪一個平台超越另一個平台，而是在於誰能提供快速、安全、與準確的實作能力。

選擇 .NET 或 J2EE
目前在實作 Web services 所使用的平台架構包括 .NET 與 J2EE，相關支援的產品與開發工具也非常多。對於慣用 Java 的開發人員，.NET 可能看起來類似 Java 平台；它們都提供結構化的方法來建立應用程式，都將語言編譯成中繼程式碼，而且都提供應用程式開發所需的龐大 API 程式庫。不過，.NET 的核心目標不同於 Java 平台。

在概念上，Java 是由 Java 平台 (Runtime 和 API) 和 Java 語言所組成。Java 平台的目的是支援使用 Java 語言撰寫的應用程式，並將它編譯成 Java Bytecode。雖然有人將其他語言編譯成 Java Bytecode，但也只是學術上的研究而已。Java 的理想一直都是在多重平台上使用單一語言。

而 .NET 則是由 .NET Framework (Runtime 和 API) 和支援程式設計語言的所組成。.NET Framework 的目的是支援使用任何語言撰寫的應用程式，並將它編譯成 MSIL。.NET 的目標是多重語言共用單一平台，由於 MSIL 所使用的 CLI 規範是開放的，目前支援 .NET 的語言早已超過25種。

目前所發表有關 .NET 與 J2EE 的比較上，大多數的評比項目 .NET 都略佔上風，其中 VeriTest 在 2002 年 5 月所作的一份報告顯示「在無快取的狀況下，Microsoft 的 .NET 應用程式在效能上明顯優於 Java 應用程式，在 5,000 位虛擬使用者的狀況下快了超過 10 倍，在快取狀況下效能快了超過 2 倍。」(VeriTest𦲷 Benchmark and Performance Testing Microsoft𦲷 .NET Pet Shop)。另外一份代表性的報告則是由一直支持 J2EE，並以 J2EE 作為其企業核心技術的 Middleware 公司所作的報告，其結果 .NET 仍然是優於 J2EE。雖然 Java 的理想「Write Once, Run Everywhere」非常吸引人，但目前大多數應用程式都只針對單一作業系統來設計，而且實務上，因為 Java Framework 受限於廣泛性和豐富性，程式 \ 開發人員必須經常使用專屬類別來存取平台上的功能，各家應用伺服器廠商在市場競爭的環境下，也必須針對自己的硬體、系統、資料庫等作最佳化，應此長有些專屬的類別庫，這些不同供應商實作之間的不相容性持續困擾著真正的跨平台工作，開發人員必須在想要支援的每個平台上測試其程式碼。因此，有些開發人員半開玩笑地戲稱 Java 為「撰寫一次即可隨處偵錯」平台。而 .NET 所提出來的概念則是提供快速的整合開發環境，協助系統及 Web services 建置，利用 Web services 的 loosely couple 模式，達到「Write Once, Connect Everywhere」的目的。所以如果真的要把 Web services 的競爭當作是 .NET 與 Java 的一場戰爭，目前看來，.NET 是暫時領先的。

資料來源：Middleware Company

資料來源：Middleware Company

Web services 的市場概況
嚴格上來說，並沒有所謂的 Web services 市場，Web servies 只是“應用伺服器”市場的一部分而已。什麼是應用伺服器呢？應用伺服器可以說是一個產品的集合名詞，提供應用程式開發、部署所需之軟體，並包括延伸的加值功能，以利於系統建立、部署、與維護。目前實場上的應用伺服器主要由幾家大廠提供，其中 IBM、Sun、Oracle 提供 J2EE-based 的應用伺服器，BEA 則提供可在不同平台執行的 Web services 平台及開發工具，Microsoft 則提供在 Intel-based 硬體平台上所能執行的應用程式平台、程式語言、開發工具、及其他流程管理及內容管理等加值軟體。Microsoft 的策略稱為 .NET、Sun 的 Sun ONE、HP 的 Netaction、Oracle 的 Dynamic services 等 ...，各家都想成為市場主流。這場競爭的賭注其實相當大，根據 Giga Group 的預測，應用伺服器市場的獲利在 2001 年約 17 億美元，但 2003 年預估將高達 90 億美元。而競爭激烈的原因不只是金額成長而已，而是因為資訊決策者對系統平台的忠誠度問題，通常選定平台或解決方案後很少再更改了，而目前應用伺服器市場的競爭都是為了看到 Web services 的龐大市場而準備。如前面所說，Web services 所牽涉的不只是一些通訊協定、目錄、登錄等標準的實作而已，建立 Web services 還需要有其他額外的流程、開發、整合、安全、維護、管理等元素，應用伺服器正好補足這些不足。

使用 All-In-One 的應用伺服器開發 Web services 好處在於應用伺服器的供應商已經幫我們處理了很多整合與最佳化的部分。開發人員不需要再花時間去處理這些問題。大部分的應用程式伺服器都包括建立應用程式所需之開發工具，並可直接編譯、部署、展示，同時還可搭配一些流程管理軟體。這些整合的產品套件可以節省很多的開發時間，並消除程式開發的複雜性，縮短程式開發週期並降低成本。

目前幾家主要的供應商中，IBM、Sun、HP 銷售策略是利用整合的開發套件，帶動其硬體的銷售，其模式類似於傳統垂直整合的銷售模式。BEA 及 Microsoft 則以銷售應用伺服器軟體解決方案為主，其目標不在於銷售硬體，因此選擇上較為彈性。BEA 的 Weblogic 可以在不同的系統環境上執行，相同的 Microsoft Windows 2003 Server 內建的應用伺服器，則可以在所有 Intel-based 的 Server 上執行，其硬體則來自於 Compaq、Dell、HP 及其他硬體廠商。這兩家都不以硬體收入作為其獲利方式。不同的是 BEA 則另外以提供開發部署的專業服務，以獲取利潤。在這一方面，Microsoft 雖然有數千個專業的服務人員，但主要在處理一些進階的技術部份，對一般企業的開發則由全球數十萬通過認證的技術人員及合作夥伴提供服務，Microsoft 的策略是將這一部分的利潤分享給合作夥伴，這是各家在市場上策略的不同。

根據 CIO 雜誌所作的市場調查顯示，選擇微軟 .NET 平台作為 Web services 的開發平台的佔 46.5%，選擇 IBM Websphere 佔 19%，選擇 Sun ONE 的佔 8.9%。(CIO Magazine Tech Poll Jan 2003)

以下兩張圖則是 Gatner 公司對目前各家廠商在 Web services 市場上的影響力所作的評估，特別要注意得是，從 2001 年到 2002 年市場上已經作了很大的改變，然而就實作能力而言還是以 Microsoft、IBM 與 BEA 為主流。

結論
雖然前面不斷的展現 Web services 的威力以及為企業所帶來的競爭優勢，然而最後還是要說，Web services 並不是萬靈丹。企業必須先經過審慎的規劃、評估，再依據自己的需求，決定 Web services 的導入時機，同時在規劃 Web services 架構的時候，除注意商業規則與企業需求以外，還必須注意程式開發的環境、商業流程以及流程管理；再來則是資訊表示的方式與系統整合，如此才能設計出符合企業需求且具彈性的應用程式系統架構。在選擇開發方式則建議選擇一套為 Web services 所設計的應用伺服器平台，以降低開發成本與風險，至於平台，由於 Web services 是一套標準的規範，因此平台的獨特性並不是那麼重要，最重要的是所能提供的實作能力與相關資源、服務等，這也是我選擇 .NET 平台作為主要研究對象的原因。

後記：
要完成這一篇文章實在不容易，早在去年六月份即已擬好大綱，卻一直苦無時間撰寫，而資訊技術的更新，一日數變，因此在撰寫過程中，整體架構也稍微作了一些調整，雖然已盡力做好文章的構思，但還是有許多個人的疏漏與偏見，還請賜教。

Ruey · 發表於: 星期六十一月 15, 2003 2:38 pm 文章主題:

Web services 之規劃策略與設計模式 -- 企業觀點
導讀
作者：李清培

2003 年 04 月

Web services 是繼 Internet 導入到商業環境後，資訊工業的另一項重大改變。很多人在聽到 Web services 的時候，腦海裡立刻浮現一朵雲的影像，透過這朵雲，形成所謂鬆散偶合的網際網路應用程式架構。也許是因為市場行銷廣告包裝的太好，造成在很多人的印象裡，Web services 就和那朵雲一樣，高來高去、毫不留痕跡，只能看得到、抓不到。也許有人還要問 Web services 是什麼？我需要了解 Web services 嗎？我需要使用 Web services 嗎？不論得到的答案是什麼，Web services 早已開始構築一種全新的網路經濟模式。

Web services 原本是要解決分散式應用程式整合的問題，然而在商業行為深度依賴資訊科技的同時，Web services 的影響力早已全面地滲透到現有商業規則與經濟模式中。就技術層面來說，Web services 只是分散式應用程式架構中的一種。將分散式應用程式架構，應用在大型商務系統的開發上，已經是相同普遍的作法，那麼為什麼還要特別介紹 Web services 呢？最主要在於“溝通”與“整合”的概念。

分散式應用程式架構雖然為商業運算提供了更彈性、更經濟、更具效能的開發與操作模式，然而目前各組織或公司在處理分散式應用程式架構時，皆使用自己獨特的一套技術，使得系統整合相當困難。因此由 WS-I 組織 (ws-i.org) 定義了一套共通的分散式應用程式標準構 -- Web services，利用一些標準規範，實現跨平台、跨語言、跨 Internet 的整合目的。透過這些開放式的標準，可以讓應用程式彼此間交互地作用，並輕易的與其他應用程式分享與共用資訊。這樣的技術除了影響應用程式的建立與部署、資訊的展示與共享，以及軟體的購買與銷售方式外，更可能進而重建現有商業行為所依循的規則與流程。因此即使您不負責技術層面的決策或營運，但只要您的管理工作是必須使用到電腦資訊技術，那麼您就必須了解 Web services。

就經濟層面來看，Web services 則是另一種的商業模式。對於企業而言，是否需要使用 Web services，則要看該企業對變動市場所採取的態度。有一個美國商場上的諺語“如果鐵路知道他所經營的是運輸事業，而非鐵軌事業，那麼我們天可能就只有聯合太平洋航空的飛機可以選擇了”，聯合太平洋鐵路原本是美國獨大的鐵路公司，在 50 年代未轉型成功而沒落，否則現在全球最大的航空公司就非聯合太平洋航空莫屬了。同樣的故事，但不同的結果則發生在台灣。雖然長榮海運服務網路早已遍及全球五大洲，成為全球最大的貨櫃船運公司之一；但如果 14 年前，長榮海運只有一些無法飛上天的船隊，那麼就不會有今天的長榮航空、台灣之翼。

台灣的經濟競爭力長久以來是建立在一個“快”的基礎上。然而，隨著市場環境的變遷，以及企業規模、型態的轉變，這樣的優勢早已受到質疑，而 Web services 則帶來另一種全新的市場優勢。企業將可利用 Web services 對變動的市場作出快速的回應；更可利用 Web services 來加速新市場的開拓。另一方面， Web services 所帶來全新的商業流程管理概念，除了降低企業整體管理、銷售及共同成本外，更提高了企業整體經營的效率。隨著 Web services 技術的日趨發展，目前成功企業所依循的商業模式都可能因此而徹底改變。為確保企業在這一波資訊技術的衝擊下，仍能保有相對的競爭力，也就不得不去了解 Web services。失去 Web services 的脈動，等於是去開放市場的競爭力。

然而對這樣的新技術該如何去面對呢？曾在一次與幾位 CTO 的聚會中聊到有關知識管理的一些看法，當全球知識經濟蔚為風潮的時候，許多企業不惜重資開始導入 ERP、CRM、KM 等...，其中一位提到該公司花了不少的金錢與人力，卻不見得有什麼樣的效果，公司由上到下從未真正感覺知識管理所帶來的好處。當時我所作的回應是“沒有知識，哪來的管理”。我想這是一句雙關語，一味的花錢買解決方案，並無法取得公司所需要的“知識”；印象裡的智者，通常是滿頭白髮，但滿頭白髮卻無法全然的代表智慧。知識的形成通常必須經過接觸、詮釋、與儲存，在高度變動與競爭的環境中，資訊收集、管理和使用的方式，即足以決定企業的輸贏，而資訊系統只是加速這些工作的遂行。同樣地，在導入 Web services 的技術時，除了瞭解什麼是 Web services 外，最重要的還是要了解 Web services 能為企業帶來什麼好處、Web services 的執行與使用模式、以及如何在企業中建立 Web services 的基礎架構平台，而不是為了 Web services 而 Web services。

在未來的幾篇文章裡，我將嘗試著以非技術的觀點，去解釋 Web services，然而畢竟這不是一篇散文作品，而是確確實實的技術類文章，加上 20 年來資訊人的包袱，要擺脫這樣的束縛實在有些困難。而為了減輕閱讀上的負擔，我將整篇文章分為四部份，在首部曲中，我們將由商業世界與電腦世界的關係談起，再談到 Web services 的發展背景與商業行為之改變，如果您想對 Web services 有一個概觀性的了解，或是您沒有時間看完全文，您就讀完第一篇吧；二部曲則進一步介紹 Web services 的應用程式架構，並以服務導向的觀念，將商業行為對應到資訊系統服務架構，如果您想了解服務導向應用程式架構的設計概念，或者您想使用非技術性的商業邏輯概念來設計企業應用程式架構，那麼您可以讀這篇文章；三部曲則直接探討 Web services在商業行為上的應用以及其規劃策略，如果您想了解 Web services 如何應用在真實的商業環境，以及設計上所要考量的問題及策略，您可以跳過前面的部分，直接讀這一篇；(不過如果您已經拿到了首部曲，請看完吧)。最後則介紹如何導入 Web services 以及平台與開發工具之比較。如果您正準備要將 Web services 導入到企業的架構中，那麼這篇文章將提供一些重要的觀念可供參考。在與一些組織與企業接觸的經驗中，發現許多的組織在評估 Web services 時，往往先由平台開始，或是討論用哪種架構比較好，這樣本末倒置的做法，往往讓整個評估過程流於一場一場的會議中，因此在最後，將特別提出個人對 Web services 評估及導入步驟的建議。

以下的大綱是依照目前的思緒所描繪出來的，希望在撰寫過程中能得到您的回應與建議，以彌補個人知識之不足：

首部曲: Web services 與全新的商業模式

資訊技術的演進對商業行為的影響
企業軟體架構的演進
Web services 如何創造全新的商業模式
Web services 與分散式應用程式的需求
Web services 與企業的需求
平台及開發工具的選擇
Web services 的限制與展望

二部曲: 服務導向的應用程式架構

Web services 的定義
Web services 的執行模式
Web services 的服務導向架構 (SOA)
AP-to-AP 溝通模式的解決方案
Web services 與簡易的 SOA 使用情境
Web services 與完整的企業應用程式架構

三部曲: Web services 與企業營運之規劃與策略

Web services 企業運用設計模式
企業應用程式的整合
供應鏈的建立與市場開發
現有與未來應用程式的擴充
降低程式開發的時間與成本
軟體租用新模式
企業流程管理
導入時機

後章: Web services 的導入與平台之選擇

導入時機與步驟
建立 Web services 的方法
選擇平台及開發工具的參考因素
選擇 .NET 或 J2EE
Web services 的市場概況

Ruey · 發表於: 星期六十一月 15, 2003 2:39 pm 文章主題:

廣達

http://www.microsoft.com/taiwan/msdn/casestudies/case14.htm

宇瞻科技

http://www.microsoft.com/taiwan/msdn/casestudies/case8.htm

相關網站

http://www.microsoft.com/taiwan/msdn/columns/dotNETResearch/webservicesent_00.htm

http://www.microsoft.com/taiwan/msdn/columns/dotNETResearch/webservicesent_01.htm

http://www.microsoft.com/taiwan/msdn/columns/dotNETResearch/webservicesent_02.htm

http://www.microsoft.com/taiwan/msdn/columns/dotNETResearch/webservicesent_03.htm

http://www.microsoft.com/taiwan/msdn/columns/dotNETResearch/webservicesent_04.htm

Ruey · 發表於: 星期六十一月 15, 2003 3:18 pm 文章主題:

勞虎觀點 3 --
SOAP 與 Web services
( 2002 / 7 /29 )
因為篇幅的限制，這次要接續上次的專欄文章，再和大家談些SOAP。這次我們將進一步談及應用層面，包括如何利用SOAP來輔助legacy systems的整合，以建構順應新時代的電子商務環境；並探討SOAP在未來Web services當道的網路世界中所扮演的重要角色。
SOAP的概念起源於Userland Software創辦人Dave Winer的XML/RPC。我們知道，XML誕生的動機，最早是鑒於網路上通行的HTML格式，往往無法對檔的內容架構作明確的描述。隨後大家很快地發現：XML簡練的語法，不僅適用於描述檔，更可以拿來描述資料──包括被程式讀取和產生的資料，以及DBMS中的資料。從跨AP、跨資料庫、跨平臺的資訊整合，一直到B2B電子商務，這個藉由純文字來描述資料的特性，正是Gartner Group所謂，XML將在未來幾年內成為「EC之語」的精隨所在。Dave Winer在當時看到了這樣的特性，便以XML定義出一套簡單的RPC (Remote Procedure Call) 包裝機制，並名為XML/RPC，這可說是SOAP的前身。
"SOAP"的名稱則是當DevelopMentor的Don Box應微軟之邀，開始研發一個彌補MTS/COM不足的標準時才產生的。當初研發的動機，根據Don Box的現身說法，是著眼於MTS/COM的機制對系統資源索求過重、不夠輕巧，難以應付未來需求。在SOAP制定初期，微軟扮演了主要的推手，同時也是最早宣佈全力支援這個標準的大型業者。去年年初開始，隨著IBM及其他業者加入標準的制定，新版的SOAP (version 1.1) 已較趨完備，同時並加入了以W3C Schema標準來定義資料類型的重要功能。類似於過去Web上許多既成標準，SOAP1.1是以Note的身分被呈遞給W3C標準會作參考 ( http://www.w3.org/TR/SOAP)。Notes在W3C形同於備忘錄，並不代表已具業界共識，標準會亦不給予正式推薦。
因為SOAP所造成的騷動，引發業界對XML傳訊協定的注意，W3C也因而成立了一個工作小組，從事XML Protocol的標準研發。目前XML Protocol的標準研發尚在訂Requirements的草創階段，還有相當長的路要走。好消息是，這個正式標準將會考慮到SOAP的相容性，使users及軟體廠商不至有無所適從的窘境。另一個最近發佈的雙贏抉擇是，重要的XML推手組織OASIS (Organization for the Advancement of Structured Information Standards)、聯合國和昇陽電腦(Sun Microsystems)等廠商所主推的ebXML標準，日前終於決定將把SOAP整合成為ebXML Messaging Services的一部份。雄心勃勃的ebXML架構相當複雜，功能在某些程度上和微軟主推的BizTalk框架有重疊性及替代性。Sun過去對支援SOAP一事一直反反覆覆，看來亦將隨著ebXML的宣告支援而逐漸塵埃落定。
現在來談談SOAP的應用。儘管EAI（企業內資訊整合）早已不是什麼新鮮的話題，但SOAP和XML的出現，讓傳統EAI軟體的觸角得以延伸至Web，「企業內」的資訊整合搖身一變為「跨企業」，legacy systems中的程式得以被Web上的users AP及交易夥伴的資訊系統呼叫，以成就電子商務。舉例而言，Software AG的EntireX Broker middleware，便提供以XML和SOAP作為包裝RPC呼叫的一種新選擇，讓古老的大型主機得以和Web銜接起來（見圖）；在一片ERP業者紛紛開始支援Web和XML聲中，SAP也提供以XML作為它RFC (Remote Function Call) 的一種新形式，讓R/3上的function可透過XML和Business Connector來作呼叫。
除了legacy systems的整合之外，從更宏觀的角度看來，SOAP很可能將成為未來Web services時代重要的訊息呼叫格式。Web services的概念是近幾年來逐漸凝聚形成的，而非一朝一夕。微軟的.NET、Sun的ONE，及HP的e-Speak等則是迎接Web services時代到來的概念型架構及市場行銷新辭令。事實上，一篇網頁可以簡單地把它看成是一個提供內容的service。網頁上常見的股市行情更新，內容搜尋、訂閱電子報的表單欄位等，現在的網路上早已有許許多多的services，而Web services時代的到來，只是進一步將這個概念發揚光大，把所有程式介面都generalize成Web上的一項項服務，而負責用來描述及呼叫這些程式介面的格式，正是SOAP/XML。上面提到的mainframe及ERP系統中既有的舊functions，經過SOAP和XML的包裝後自然也搖身一變成為最新、最時髦的Web services。

sanchi · 註冊時間: 2003-11-11 文章: 61 第 8 樓

偶這個新手要好好研讀
謝謝前輩提供如此好之資訊