SOA面面觀

近兩年來SOA（Service-Oriented Architecture；服務導向的架構）是被資訊產業喊得震天價響的當紅炸子雞，事實上，SOA並不是新的概念，早在十幾年前DCOM及CORBA規格中的ORBs（Object Request Brokers）即SOA的應用。Gartner預計，到2006年將有超過 60%的企業，會考慮以SOA作為建立關鍵業務應用的基本原則。SOA及SODA（Service-Oriented Development of Application；服務導向的軟體開發模式）在未來幾年將逐漸成為主流。Web之所以大行其道，鬆散藕合是關鍵

網際網路最初是為了分享學術及科學上的研究成果，第一份HTML網頁是由單純的文字與超連結組成，不久之後，內含圖形與其他多媒體資料的能力，很快地就被加到視覺化的Web身上。瀏覽器讓網際網路在短短幾年間，成為橫跨全球的資料庫。

然而，對企業而言，重要的商業資訊都儲存於資料庫而非文件中，隨著時間的演進，維護大量的靜態HTML網頁，將成為繁瑣的任務。因此CGI、ASP、JSP等動態網頁技術應運而生，網站成了資料查詢、線上交易等服務的提供者，開始執行應用程式的任務。當任務變得愈來愈重要，便出現新一代的中介軟體－應用伺服器，介於前端表現層及後端資訊系統之間，兼顧安全性、穩定性、可用性、延展性及效能等各方面要求，擔任執行商業邏輯的角色。

網際網路之所以成功，BEA技術經理蕭百齡認為：「遵循開放標準，帶來鬆散藕合（Loose Coupling）的模式是最重要的關鍵。」然而網路的應用必須依賴瀏覽器，又顯得被僵化地限制，因此人們開始思考更中立的方式，讓消費端可自行決定如何處理及呈現服務端所提供的資訊。

XML就是在這樣的時空背景下產生的技術，目的在於提供一個精準描述資料的機制，以彌補HTML太過著重資料呈現的特質。Web Services讓服務端提供的資訊，除了瀏覽器外，手機、IA家電、其他伺服器上的服務，甚至辦公室文書軟體都成了潛在的資訊消費者。

業務導向的組裝式系統
傳統應用導向開發的軟體，試圖在各個領域提供解決方案，產生ERP、CRM、SCM及PLM等，獨立、訊息不交流且難以整合的系統。然而量身訂作自行建置的成本過高，因此企業多選擇套裝的解決方案，再自行加以客製化。然而由於套裝系統的架構僵硬，缺乏變動的彈性，往往是使用者屈就系統功能，而非系統配合使用者的習慣，這也是導入系統時，容易遭遇使用者因習慣改變而反彈的原因。

「開發即整合，整合即開發」是SOA的新思維，顛覆傳統應用導向的思維，強調的「服務」是以業務為主軸，提供各項資訊基本應用功能，以拉近資訊系統與業務之間的距離，而著眼於貫穿資訊孤島，提供可排列組合的各項服務。

將系統功能模組轉換成各種服務後，透過BPM橫向貫穿ERP、CRM、SCM及PLM等，企業對內和對外各種系統，串連服務成為請採購等各類商業流程。未來業務需求或商業流程改變時，將保有調整的最佳彈性。

SODA也確保應用系統以先天即能互相整合的方式來設計，讓企業所開發的新應用系統能輕易地與其他系統整合，迅速藉由新的或現有的「服務」來建立組合式的應用系統，並賦予因應未來整合所需要的彈性。

臺灣IBM公司軟體事業處商業整合產品專員董俊賢說明：「SOA類似硬體IC的概念，再透過流程串連各種服務，組合成解決方案。」過去軟體設計無法實現IC模組的概念，是因為各家使用專屬的技術及規格，使得模組受到特定技術的箝制；而今在開放標準下，整合不再是夢想。

Services未必是Web 「Services」
要建構有效的SOA，必須先清楚了解「Service」這個專有名詞的意義，Service是一個定義明確且獨立運作的功能，且與其他Services的內容及狀態沒有相依性。

董俊賢強調：「SOA是架構性的概念，不能窄化SOA的定義，Services指的並不一定是Web Services。」Services是物件導向的延伸，過去SmallTalk、CORBA到後來微軟的DCOM及J2EE的EJB和JavaBean等都是SOA的應用。由於使用專屬的語言，所以無法互通，直到Web Services的出現，才露出整合的曙光。

DCOM是微軟執行遠端呼叫的專屬機制，雖然與Web Services同樣是跨語言的技術，卻僅支援Visual C++、Visual Basic及C#等語言，受到微軟平臺的綑綁，便限制了應用範圍。最新的.NET Remoting也是.NET平臺SOA的應用，但也僅限於.NET平臺。

事實上，CORBA與Web Services類似，擁有跨平臺及程式語言能力，且成熟度較高，但必須付出較高的學習成本。CORBA仰賴IDL解譯資料，但一般人難以理解IDL的內容，開發人員必須學習IDL，困難度因而成為阻礙發展的金箍咒，影響市場的接受度。相較之下Web Services的XML可讀性高，且多數開發Web Services的工具均可自動產生WSDL。再加上CORBA的架構必須在每個用戶端安裝IDL的解譯器，所以只適合企業內部網路的應用。

SOA大放異彩的原因，與XML及Web Services的成熟有絕對的關係，由於遵循開放標準，而帶來鬆散藕合的架構，SOA的架構將不再受到特定技術或產品緊密的綑綁。BPM是串連服務的神經系統

在SOA的架構中，BPM（Business Process Management；企業流程管理）扮演串連各種服務形成企業流程或資訊流的角色，也可說是流程管理的解決方案，由流程模型建置、流程分析、流程模擬、流程執行、流程監控及流程管理等功能組成。但實現BPM未必需要搭配BPM產品，董俊賢強調：「BPM這個專有名詞，是為解決整合的問題而提出的概念，並非產品。」傳統以紙本傳遞，或土法煉鋼撰寫程式的方法，也是BPM的作法。套裝化BPM產品的目的，是為減少撰寫程式的負擔，並降低維護與管理的成本。

BPM若要成為SOA架構中，串連服務的神經系統，除了要支援Web Services，及提供連接既有系統的配接器之外，還必須使用相同的標準，BPM產品才有互通的可能。在戰國時代百家爭鳴的標準中，OASIS的BPEL是大家認為比較可能成為主流的標準。

不過企業仍然存有疑慮，即使各家BPM產品都支援BPEL，然而會不會上演類似J2EE的情況，在標準之外加入專屬的規格，因而破壞了相容性。蕭百齡表示：「各廠商或許有提供額外加值的功能，但最基本的相容性可以透過認證，確保跨BPM產品對 BPEL 格式匯出/匯入的相容性。」這就類似現在WS-I推的Basic Profile觀念，只要遵循指導方針，即可以產業標準為基礎，開發及建置具互通性的BPEL格式。

另一個擔憂是使用BPEL與合作夥伴串接流程，會不會洩露內部流程？事實上，只要遵循建置B2B流程的最佳實作，訂定Public和Private Processes，內部與外部的介面是完全隔開的。

SOA的好處
開發軟體時，建置健全的服務層，將帶來更好的投資報酬率。每個Service對應到明確的商業領域，當系統產生新的需求時，只需開發新的元件提供額外的服務。由於各項服務擁有明確的獨立性，所以其生命周期很有可能比最初的系統還長久。

SOA的Services位置必須透明，應用程式將Services以目錄管理，在執行階段才動態結合在一起。這樣的特性促使更好的延展性，因為負載平衡機制可在不知道Services用戶端的情況下，轉送要求到多個Instance。也因為這樣的透明度，可以在多臺伺服器的Instance建立相同的Services，如果部分網路或某臺伺服器出現問題，使用者的要求可重新指派到其他伺服器的Services，使得系統擁有更好的穩定性。

既然Services存放位置的透明度是SOA的特性，程式可攜性即可實現。用戶端無需在意服務的所在地點，因此企業可彈性地移動服務到不同的地方，甚至提供合作夥伴或客戶使用。

SOA促使應用程式分為多層式的架構，每一層都有專門的技術，開發人員將專業分工，負責應用程式不同部分。企業得利於不再過度仰賴高成本的獨門人才，可使用經驗較少的大眾人才。

以單一或主從架構建置系統，安全機制一般由前端處理，企業甚至沒有導入資料庫的安全控管機制，因為管理多重的安全機制太過困難。而一個服務可能提供多個應用程式使用，因此有獨立完整的安全機制，應用程式將有用戶端及服務端的雙重認證，可強化安全性。

Services有公開的介面可方便執行單元測試，開發人員可使用工具製作測試案例，以確認Services的獨立性可被任何應用程式使用。除錯是軟體考古學中相當困難的任務，藉由將商業邏輯集中於Services層，系統的可維護性將大幅提升，因為開發人員將更容易找到及更正錯誤的部分。

完整的測試通常意謂著更少的缺失及更好的品質。開發人員將逐漸建構一系列有用Services，企業將了解這些Services是可再利用資產，可以各種方式組裝，新的應用程式將因此而更快被開發出來。

程式碼的再利用是最常被討論的議題，然而由於程式語言及平臺的不相容，一直很難達成這個理想。元件及Services比較容易被再利用，開發人員不需要再煩惱編譯器的版本、平臺或其他可能影響的因素。

多層式的架構也代表可獨立作業，只要在專案開始時建立好介面溝通的契約，各層的開發人員可同時進行自各的開發工作，縮短開發時程。.NET與Java在SOA方面的表現

微軟在Windows Server 2003上市的同時，也結合.NET Framework、IIS 6.0及Visual Studio .NET提出「應用伺服器」的解決方案。Visual Studio .NET是相當方便的Web Services開發工具，並強調獨門的C#及VB.NET語法簡捷且API完整，可強化開發導入的速度。在未來以Web Services為基礎開發的Longhorn作業系統，搭配.NET的Whitehorse及Indigo新套件，將提供更有效率的Web Services開發環境。

BEA WebLogic 8.1以應用伺服器為基礎平臺，結合Portal伺服器提供更好的使用者經驗；資料的彙整與管理也是重要的問題，Liquid Data是EII（Enterprise Information Integration；企業資料整合）解決方案，企業可透過標準XML查詢資料；企業內部與外部合作夥伴應用程式的整合，可透過BEA Integration Framework，以BPM、B2Bi及EAI解決方案完成。

過去WebLogic必須搭配Borland JBuilder，才能開發Web Services。WebLogic Workshop則是所有解決方案共同的開發平臺， 自從前年推出第一代以來，被許多分析機構評為最簡單的Web Services開發工具。BEA認為J2EE就像DOS一樣，很重要卻也很枯燥，微軟的Windows作業系統之所以起飛的原因，就是因為高階圖形化的介面。不是每個人都需要學DOS，也不是每個人都需要了解艱澀難懂的J2EE，WorkShop即提供簡單容易使用的圖形使用者介面，即使一般使用者，也可利用WorkShop開發Web Services、設計Portal及組裝流程。

IBM則基於SOA整個架構，針對企業在資源整合方面，提出ESB （Enterprise Services Bus）架構，以提供企業在導入SOA架構時方便管理及提升效率的基礎架構。 在ESB下提供企業內部或外部不論在企業流程、資料或系統，透過企業入口網站、B2B或 Web Services加以整合。

IBM從2003年起開始將其相關的產品都加以提升支援ESB架構。在基於J2EE 架構WebSphere應用伺服器建構解決方案，MQ及WBI Borkers負責BPM的部分，再搭配入口網站伺服器、Web Services應用機制、WebSphere Business Integration為流程整合、DB2 Information Integrator是即時異質資料庫整合機制，及WebShpere Business Integration Adapters為B2B的配接器。

對於企業既有的系統，Siebel、SAP及Oracle等ERP系統目前都已支援Web Services，多數應用伺服器及BPM工具均提供配接器（Adapter），至於自行開發的系統，由於開發工具普遍支援Web Services，只要有繼續維護，都可透過工具將元件轉換成Web Services。

SOA對EDI與EAI的影響
過去企業透過EDI（Electronic Data Interchange；電子資料交換），運用協定的標準與資料格式，經電子化傳遞方式，與合作夥伴及客戶交換訊息。以EAI（Enterprise Application Integration）整合內部的系統，減少重複輸入的機會。當SOA出現後，對EDI及EAI會造成什麼樣的衝擊？

蕭百齡認為：「SOA 的精髓不是在取代什麼，而是要整合。」既有的EDI、EAI方式，及大型主機或ERP系統會繼續存在，但可以整合在SOA的架構之下。SOA可說是解決EAI課題的新方法，可取代舊式做法，而改以開放標準的Web services為溝通協定。董俊賢也表示:「SOA只是實作EDI及EAI的一種新的作法。」

臺灣微軟.NET顧問經理李啟後表示：「以SOA的架構串連企業應用程式，相較於傳統EAI的技術，是比較經濟的作法。」隨著時間的演進，SOA所帶來的好處與價值，將超越傳統EAI投資。BEA則認為：「SOA是EAI的進一步應用，若一開始就考慮SOA，未來就沒有整合的問題，而是彈性組裝的系統。」傳統EAI整合各自獨立的系統難度高，往往需要藉助顧問服務，導致成本太高。SOA可減少建置與維護的門檻，降低專業工匠的需求，提高效率並降低成本。

不過，Borland資深產品經理李匡正分析：「SOA很有機會取代傳統EDI的作法，但在EAI方面SOA並不是萬靈丹。」過去EDI建置的成本太高，無法普及到下游的廠商；而SOA是平價的EDI，且內建支援的開發工具較多，所以很有機會取代EDI。不過EAI屬於企業內部的資訊整合，是相當專業的領域，雖然SOA是低成本的EAI解決方案，但由於Web Services效能較差，除非是時效性要求不嚴苛的系統，否則Web Services的SOA架構不見得是最佳的解決方案。SOA的關鍵原則

Web Services雖是最新SOA架構應用的實作，但正確的設計觀念與周詳的導入規畫才是SOA的關鍵。掌握使用Web Services的技巧，才能發揮潛在的價值，否則將適得其反。蕭百齡表示：「在實作和設計上必須把握關鍵原則：鬆散藕合和正確的顆粒大小。」

鬆散藕合白話文的意思就是立場中立，Web Services是異質系統溝通的介面，為避免被專屬技術緊密綑綁，或單方面調整時會衝擊雙方的溝通，介面要越中立越好。此外，中立的介面也進一步提升重複使用的機率，讓資源可以共享，增加開發的價值。

顆粒大小也是抽象的概念，SOA強調業務導向，與過去設計函式（Function）或方法（Method）小顆粒的作法不同，在設計上XML傳遞的資料內容，應朝向設計業務上有意義的單元。

由於適用Web Services的範圍、介面的長相及所謂顆粒大小的問題，是一門學問，而企業對SOA及Web Services的應用，目前並沒有清楚的概念與足夠的實際經驗，為避免「為Web Services而Web Services」，企業可能會尋求顧問服務。不過蕭百齡認為：「採用SOA架構，中大型企業會得利最多。」所以企業應不假外求，培養內部的建築師，組成專業的規畫團隊與業務單位充分溝通，才能有效降低專案失敗的機率。

用對地方才能發揮效益
根據Gartner Group的調查分析，J2EE將逐漸取代CORBA，這不代表CORBA就此消失，因為J2EE的規格中包含CORBA的架構，所以也可以說J2EE延續CORBA的應用；COM及COM+將逐漸由.NET取代，而.NET及J2EE的互通即透過Web Services。事實上，CORBA、DCOM也均有存在的價值，未來將存在於企業內部；Web Services則善長網際網路的溝通。

SOA舊瓶裝新酒，在近兩年成為當紅的技術名詞，無非是與Web Services的崛起有關，雖然Web Services目前仍不算成熟，不過以其公開標準、跨平臺、成本低廉及鬆散藕合的特性，將是促成SOA引領風騷的主因。

李啟後表示:「臺灣敏感的經濟型態，隨著全球趨勢脈動，企業特別需要SOA的架構，以因應靈活變動的需求。」企業的資訊系統需要更靈活的架構，以因應瞬息萬變的需求，才能發揮展現IT的價值。

不過，一窩蜂的趕流行，可能勞民傷財也不見得有好的效果。Web Services不是萬靈丹，用在對的地方才能發揮真正的效益，蕭百齡認為：「單一系統或語言的溝通，Web Services不見得是最好的候選人；跨企業、系統或程式語言的交流，Web Services便是優先考量。」當然企業也不能忽略效能問題，效能要求嚴苛的系統，可考慮其他解決方案。文⊙李延華