SOA：美學為架構的IT技術

最近一年多以來，SOA（Service-Oriented Architecture，服務導向架構）成為IT界的當紅炸子雞。

隨著媒體與IT大廠的炒作，好像一談到「整合」就非SOA不可。很多技術詞匯（例如：BPEL、ESB、BAM…）也在這個過程中不斷地被創造出來，但這些技術詞匯好像并不會幫助我們對于SOA在應用上的了解，甚至只會令人更懷疑這些名詞只是IT產業又拿出來營銷的噱頭而已。

事實上，技術出身的我不得不承認，SOA有一種架構性美很容易讓技術人員醉心。但在同事朋友們討論SOA的時候，總覺得少了什么？這樣的美可以幫助我們解決什么樣的問題呢？如果只是架構上的美，終究也只限于技術架構的美而已，有什么信息問題是無法用傳統EAI（Enterprise Application Integration）技術手法來解決而一定要采用SOA嗎？還是它的美只存在于IT學院的象牙塔之中呢？

面對業界許多（非IT領域）朋友的疑惑，我決定寫這一篇文章來重新為SOA「正名」，從IT在商業運作上應用的角度來闡述SOA主要所要解決的問題，讓大家再從另一個角度來看SOA。

定義：不只是技術，是IT架構

或許已經有讀者注意到了，我們通常談到IT，大部份都會說是XX「技術」，但為什么沒有聽過有人說SOA「技術」呢？如果我們看SOA（Service-Oriented Architecture）這三個英文字母，會發現SOA中的「A」竟然是Architecture（架構）這個字。單就語句結構上來看，如果在「架構」這個字詞后面再扯上「技術」兩個字，還真有點奇怪。

嚴格說來，SOA這一個詞并不是指一種「技術」，而是指一種IT架構，當然，這樣架構下會有各種不同的技術，來解決企業在面對商業自動化的所面臨的各種不同的問題。

本文將先介紹SOA對企業的意義，主要在藉由商業自動化，以協助企業解決一個千古不變的難題：變。

自動化服務組件是商業自動化的第一步

SOA（Service-Oriented Architecture，服務導向架構）顧名思義，以「服務」做為導向來出發，以設計并建構我們的系統構架。簡單來說，我們可以說：「服務導向架構」目的是要達到一個自動化的商業行為。

首先，讓我們舉個例子說明。澳圖美德（Automated）科技是一個系統整合廠商，在他的商業行為中，他需要經常對他的供貨商（例如SUN Microsystems）來進行詢料（特別是在庫存中并沒有足夠的備料時）。

早期這樣的一個行為，是由純人工的方式來處理，需要再透過SUN業務同仁處理（包括報價及答復商品的Delivery Time），但在整個商業流程中，商品的報價與Delivery Time并不會有經常性的異動，因此這樣的做法是一種人力資源的浪費。

為了避免這樣的問題，我們可以將上下流兩個公司的系統做適當的調整，讓SUN公司在系統中建架一個服務組件來提供價格與Delivery Time 的數據查詢，直接利用在澳圖美德內部的系統來呼叫SUN公司所提供的服務組件，澳圖美德的同仁即可完成報價與Delivery Time（交期）的詢問。所以可以認知到的是，在商業自動化的前提下，SOA需提供一個「跨系統的數據交換與傳遞的規范與方法」，以便商業上的信息交換。而在整個架構中，被實做出來以負責信息的交換與傳遞的程序一個個的模塊，我們可稱為服務組件。

或許有些讀者會發現，這樣的做法，不就是幾年前 Web Service的技術觀念下就已經提出來的做法嗎？這跟SOA 有什么關系呢？

當然，如果只是上述的例子中所提到的需求，其實只要用 Web Service就可以做到了。那SOA可以再解決什么樣的問題呢？藉由上面的例子，我們再來拉大企業的需求，以再進一步認識 SOA。

「服務組件」結合「流程」提供更多樣的自動化服務

由上述的例子，如果單純從數據流的角度來看，我們可以說：「澳圖美德公司與SUN公司在做資料交換的動作，讓澳圖美德員工可以很輕易得到他需要的數據?！沟鋵?STRONG>自動化的商業行為并不只是數據交換那么單純；例如，以身份認證而言：是不是所有的廠商都不需經過認證就可以呼叫SUN公司所提供的組件來取得SUN的報價與 Delivery Time 呢？或者不同的協力廠商所取得報價會相同嗎（不同的協力廠商有可能會因不同的規范而有不同的報價）？再從流程的角度來看，整個商業行為并不是在取得報價后就結束了–是不是要有詢價記錄（以便未來的追蹤）？

或者，如果價格合理，那就會進入采購的程序。如果價格不被接受，那則有可能進行到議價的程序，如果該項商品還有多個供貨商的話，那也有可能進入到詢價、比較的不同的程序。甚至不同供貨商也有可能有不同的作業流程或程序，有些一定要先下單再出貨，有些關系好的則可以先出貨再下單。有的商品則有可能要先下樣品單，甚至樣品交貨的同時也要先付貨款等等。

因此很單純地由一個服務組件來進行數據交換，并無法滿足商業行為自動化的所有需求。在一個完整的商業自動化行為中，往往需要由一組（多個）可能由多個不同系統提供的服務組件來進行服務。

例如，系統應該先進行身份確認（這里是一個身份確認的服務組件），再來才進行詢報價程序（這里應該又是另外一個服務組件），最后，當買方確認要進行下單的時候，才會進入采購程序（進入采購流程應該又是另外一組服務組件，甚至有可能對應到另外一個獨立的系統中）。而組織、整合并決定所有的服務組件的使用順序地即是「流程」。因此在商業自動化的目的下，如何進行跨程序語言、跨系統、跨組織、甚至跨企業的流程架構、規劃、設計與實作，也是SOA 要思考與規范的重點項目。

我一開始說SOA有種架構性的美，是指它作為一種IT架構，竟與哲學中的現象學具有同樣的世界觀?，F象學提到「存有」與「關系」?！复嬗小乖贠O（對象導向，Object-Oriented）中（注），可以視為是對象，而在SOA中，我們可以說它是服務組件。而關系，在OO中就是那個方法，而在SOA中，就是跟時間一起被定義在流程之中。SOA即是結合服務組件及流程的很嚴謹、很工整的架構。

注：Service-Oriented 與 Object-Oriented：

看到Service-Oriented，IT產業較熟悉的人應該就會直接覺得想到OO（Object-Oriented，對象導向）。確實，從觀念上來說，這兩個概念是雷同的，只不過它們所關切并要解決的問題是屬于不同層面的：SOA是從商業邏輯層面來看，以減少系統中服務組件設計與開發的時間；而OO則是關注程序設計與開發的層面，以減少程序組件重新開發的時間。