杜奕鋒 2007/02/01 11:43:52
最近一年多以來，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公司在做資料交換的動作，讓澳圖美德員工可以很輕易得到他需要的資料。」但其實自動化的商業行為並不只是資料交換那麼單純；例如，以身份認証而言：是不是所有的廠商都不需經過認証就可以呼叫SUN公司所提供的元件來取得SUN的報價與 Delivery Time 呢？或者不同的協力廠商所取得報價會相同嗎（不同的協力廠商有可能會因不同的規範而有不同的報價）？再從流程的角度來看，整個商業行為並不是在取得報價後就結束了–是不是要有詢價記錄（以便未來的追蹤）？
或者，如果價格合理，那就會進入採購的程序。如果價格不被接受，那則有可能進行到議價的程序，如果該項商品還有多個供應商的話，那也有可能進入到詢價、比較的不同的程序。甚至不同供應商也有可能有不同的作業流程或程序，有些一定要先下單再出貨，有些關係好的則可以先出貨再下單。有的商品則有可能要先下樣品單，甚至樣品交貨的同時也要先付貨款等等。
因此很單純地由一個服務元件來進行資料交換，並無法滿足商業行為自動化的所有需求。在一個完整的商業自動化行為中，往往需要由一組（多個）可能由多個不同系統提供的服務元件來進行服務。
例如，系統應該先進行身份確認（這裏是一個身份確認的服務元件），再來才進行詢報價程序（這裏應該又是另外一個服務元件），最後，當買方確認要進行下單的時候，才會進入採購程序（進入採購流程應該又是另外一組服務元件，甚至有可能對應到另外一個獨立的系統中）。而組職、整合並決定所有的服務元件的使用順序地即是「流程」。因此商業自動化的目的下，如何進行跨程式語言、跨系統、跨組織、甚至跨企業的流程架構、規劃、設計與實作，也是SOA 要思考與規範的重點項目。
我一開始說SOA有種架構性的美，是指它作為一種IT架構，竟與哲學中的現象學具有同樣的世界觀 。現象學提到「存有」與「關係」。「存有」在OO（物件導向，Object-Oriented）中（註），可以視為是物件，而在SOA中，我們可以說它是服務元件。而關係，在OO中就是那個方法，而在SOA中，就是跟時間一起被定義在流程之中。SOA即是結合服務元件及流程的很嚴謹、很工整的架構（待續）。
註
Service-Oriented 與 Object-Oriented：
看到Service-Oriented，IT產業較熟悉的人應該就會直接覺得想到OO（Object-Oriented，物件導向）。確實，從觀念上來說，這兩個概念是雷同的，只不過它們所關切並要解決的問題是屬於不同層面的：SOA是從商業邏輯成層面來看，以減少系統中服務元件設計與開發的時間；而OO則是關注程式設計與開發的層面，以減少程式元件重新開發的時間。
留言列表
