Web services設計模式--企業觀點

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

 

李清培

弈飛資訊首席顧問 /台灣微軟特約資深講師

 

隨著市場環境的變遷，以及企業規模、型態的轉變，企業為了保有市場上的競爭優勢，大多數會採取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的設計與規劃策略，將在下篇文章中進一步的說明，我們下回見。