SOA初級班(6)SOA進入實際應用新紀元

自2005年開始正式進入「Real World」SOA的時代，競爭者仍是資訊市場界的那些大老，工具、產品還是那些熟面孔。業界花了5、6年的時間，終於發現以科技為導向是不正確的方向，以商業為導向的SOA架構才是實際應用需要的SOA。

主力大廠開始倡導他們是Real World SOA，由SOA跨到Real World SOA的另一個原由，是針對SOA的開發步驟。因為運用現代軟體敏捷理念的「持續遞交」理論，成了廠商分解架構的必然利器。

需依循軟體工程
服務（Service）的理念不是現在才有的東西， 跨媒介的協定也早已廣泛受到運用，例如EDI、CORBA、DCOM等，因此今天企業想要解決商業上的問題，而訴求於SOA的解決方案，仍應依循軟體工程的理論。

這一點不論微軟或IBM 都已然體會到，兩家公司不約而同地放入了以Agile 為主的持續遞交（Iteration）概念，這一點讓上述兩家公司在這方面的進展中取得領先，也間接維持IBM RUP 與微軟的MSF Agile分庭抗禮的局勢。

SOA該從哪裡開始？其實，不管是重新解構已有的交易程式，或是建構全新的專案，所謂的Use case或是 User Story 都是十分正確的開始。應該提醒的是，別忘記軟體工程所教導我們的方法，運用在這裡仍然是十分有用的。

軟體工程新的理論快速應運而生，所謂Break down的方法， 異口同聲大家都提出: 解構（Expose）－組合（Compose）－使用（Consume）的開發法則，再配合由上往下（Top-down）、由下往上（Bottom-up）及全新的Middle-out的解構方法，看起來已經有脈絡可循了。

這些模組化（model）的方法並不是創新的理念， 也沒有完全取代既有軟體工程的方法論， 原則上無需取新而捨舊，我們仍應踏實地運用測試開發法（Test-Driven Development），在先寫測試程式、後寫開發程式之下，持續遞交給客戶真正想要的服務才是較成熟的開發法則。

就是多了個訊息層
SOA服務的多階層示意圖（訊息、邏輯和狀態），看起來與傳統的N-tier的架構十分相似，多出來的是訊息層（Message Processing Layer）。服務是SOA的基本單位，但Web Services不等於SOA，只因它具有跨不同平臺的高整合度，才促使得它取得最佳代言人的地位。實質上，Web Services並不符合傳統架構企業級服務平臺的觀念， Web Services看來只是文件交換的一個好協定，而整個可靠的訊息傳遞層才是SOA真正的戰場。軟體廠商們當然都很清楚這一點，因此ESB（Enterprise Service Bus，企業服務匯流排）自然成了最主要的賣點。

企業服務匯流排
服務導向的結構和事件驅動的結構（Event-Driven Architecture，EDA）是處理整合系統的高複雜挑戰的兩個不同範例。企業如何選擇更好的方法滿足業務需求呢？實際上他們無需苦惱，因為ESB允許同時實現SOA和EDA概念。採用服務導向的架構，運用訊息導向作為協定，以事件驅動的方式實作，這是企業推行SOA的最佳指導原則。

許多企業將「多通道（Multi-channel）」視為SOA的終極目標，理所當然地將企業服務匯流排視成實踐SOA的萬靈丹，但就如同一開始所說的，在進入Real World SOA的時代時，競爭者、工具、產品都是老面孔，B2B時代已有的資料轉換機制，如今都已悄悄更換新妝，繼續肩負SOA時代下的重責。

歷經了幾個版本的洗禮，產品已逐漸進入成熟期，正是最最堪用的時候。但工具製作之初，一定有它的定位及規模的限制，但目前Web Services製作如此簡易且氾濫，跨網路通訊的頻繁，已遠非當初B2B時代的規畫可以跟得上，更別談那些看似極端正規的WS-*標準，都必須重新實作。

更新的Web Services標準推陳出新
Web Services也未曾料到它會肩負起這樣的重責大任，許多關鍵性的工作或是巨大的企業組織，若是以現在的方式運用Web Services，管理不易與衍生的災難，恐怕會迅速超越它的效益。

W3C與OASIS這兩個國際性非營利公協組織，他們正在努力制訂新Web Services的標準，從可靠度、安全性、同步與非同步功能及交互運行的效益，設法提出好的考量，因此應運了企業級的Web Services。

這樣的演變過程是十分自然且良性的，但在刻不容緩的商業競爭中，企業時時刻刻都必須適應及調整商務狀態，要如何才能盡快採用SOA的架構而獲得實質的效益呢？這是導入SOA的企業與軟體廠商的最大考驗。

一些錯誤觀念
「服務導向是一種設計理念」，這句話明白告訴工程師，設計程式是以解決商業上的問題為主的行為，因此要兼具相當的商業知識，才可能設計出符合使用者需求的作品。

「製作服務不等於製作Web Services」 IT人員必須知道何時該採用何種訊息傳遞資料，因為基本上Web Services是一種基於TCP/IP之下的HTTP無狀態（stateless）的訊息傳遞（協定）方式。

「別人成功建製的SOA方案，並不一定符合自己」他山之石不見得可取，尤其是以商業狀態為導向的系統架構，還是應該透過軟體工程的分析設計。

幾乎所有的企業在計畫實行SOA之初， 都採用先引進大量顧問的方式。若說BPM像企業流程的重整（re-engineering），那SOA就是企業資料的整合，訊息的流動成了最重要的一環，因此由資料的產出，到訊息的建立、傳遞，形成了一個龐大的企業訊息層，企業若能有效率地從中獲取創價（time to value）的資訊，將明顯獲益；反之，就只是在浪費企業的資源，雖然作到資訊的匯集，卻無法善加運用。

這一點印證Gartner公司在2006年中期一項對158家企業的調查，32％的公司表明，他們在成本方面受到了一定程度上的或者顯著的不利影響，同時47％的公司表明，使用SOA並沒有為公司節省任何成本。但超過50％的受調查公司認為，SOA對商業靈活性有積極的影響。這些反應在在說明了運用才是重點，因此慎選工具才是實質上該作的。

SOA之後
SOA絕對不是企業架構的終點，它是隨著時代的發展而出現的產物，透過實作之後的架構。企業在處理IT無法回應的多樣性和快速變化所帶來的問題時，SOA將展現越來越多的優勢。

SOA廠商產品越來越成熟，工具平臺也依據新制定的標準持續的發展中，尤其當交易數量日漸增加之後，符合企業解決方案的架構就會越發浮現，我們自然會更加認清運用SOA的未來。當它的重要性、價值以及複雜性受到證實後，我們都在期待下一個建構在SOA之上的革命性產品或技術的到來。