成功導入服務導向架構的關鍵
As I’m working with corporate America, as well as the government, I’m finding that SOAs are like snowflakes…no two are alike. I’m also finding that everyone has their own definition of SOA, and I’ve seen everything from messaging systems to portals called a SOA.
Google精確搜尋「Service Oriented Architecture」，大約有320萬個符合項目；服務導向架構（SOA）這樣一個資訊產業熱門詞彙，每個人的認知卻未必相同，所以有人說：「SOAs are like snowflakeso two are alike」。
SOA的本質與原則，也逐漸被商業包裝和不斷推出的標準與協定給埋沒，許多專家開始擔心，貿然導入SOA，甚至是導入特定廠商提供的軟體，不僅浪費有限的資訊預算，長期而言，反而容易受到限制。因此導入前，務必充份了解SOA的意義和目的，選擇最適當的方案。第52期「從原理面探討服務導向架構」，已經詳述服務導向架構的技術本質，本文將著重探討系統面與管理面的關鍵因素。
跨越平台的網路服務技術
目前主流系統架構，都屬於以元件為基礎的架構（Component based Architecture）。以三層式（N-tier）架構為例，系統由部署在資料層、商業層和展現層的一群元件組成。雖然在程式開發工具的協助下，跨伺服器的元件呼叫已經不困難，但是元件管理機制仍然相當複雜，而且不同平台或不同程式語言開發的元件也很難混用。
網路服務（Web services）讓元件透過HTTP和文字來進行溝通，取代過去像是DCOM或是CORBA這些使用特約的分散運算機制，成功地跨越平台與程式語言的限制。現在要製作一個網路服務，也十分容易，但是絕對不能把網路服務與服務導向架構劃上等號；對於本質上是分散式的服務導向架構而言，網路服務只是開啟（enabling）服務導向架構的關鍵技術。
服務導向的本質
然而還有一個棘手的跨系統整合問題：不同系統的元件，有許多功能重疊，或是彼此高度相關；當某個系統試圖去使用另一個系統的元件時，除了需取得該元件的介面規格，還必須注意這個元件是否有副作用。這樣的問題即使是採用網路服務技術，仍然會發生。
服務導向把焦點轉移到應用系統提供的服務層次，將元件的複雜關係鎖進服務黑箱。服務導向關注的是具備高凝聚力和低連結力，獨立完整的服務，外界只要透過簡單而且穩定的網路服務介面，就可以取用這些服務，不必理會黑箱細節，不用擔心副作用，更不必在意開發工具，或是部署的作業平台。當這些服務是獨立無副作用時，重組既有服務的創新流程，才有成功的機會。
服務導向是一種由上往下、長期整體的觀點，而不是將程式碼封裝成網路服務、由下往上的程式開發觀點。不論是既有系統的盤點，或是未來新建系統的規劃，都要符合企業經營發展目標，並且配合組織的架構。因此要以宏觀的角度，去尋找潛藏在既有系統內的可用服務，並且設計與建置新的服務。
系統有生命周期，服務也會有生命周期。如果A系統的客戶資訊最完整，應當提供客戶資料服務給其他系統使用，但是原始設計的負載容量有限，貿然提供額外服務，並不恰當。合理的做法可能是選擇先修改B系統來提供客戶資料服務，並且規劃兩年後A系統改版完成，終止B系統的服務，改由新版的A系統提供服務。由於服務介面保持不變，其他系統也就無須再進行調整。
合理使用網路服務
遠端程序呼叫（Remote Procedure Call）的成本，因為要加上協定程序與網路傳輸時間，必然遠高於本地端的程序呼叫。透過Web Server的網路服務成本更高，加上SOA採取Document-Oriented，Metadata-Driven的原則，所以傳輸的資料量也遠高於一般程序呼叫所傳遞的參數資料。
實務上絕對要避免大量呼叫遠端程序或是網路服務。會導致大量呼叫網路服務，可能源自將共用程序或是共用元件視為共用服務的嚴重誤解。很多程序確實是共用的，例如輸入項目查核程序、內碼轉換程序或是代碼轉換程序等；這些程序在程式當中處處可見。然而一旦將這些程序，直接轉變成共用服務，假設原本的程式有10個輸入項目需查核，5個項目需要轉換，總共15個本地端程序呼叫，將變成20個遠端程序呼叫。這將使得原本瞬間完成的程式，變成費時數十秒的爛程式。
查核或是轉碼程序並非不能轉為共用服務，關鍵在於需要採取整批查核與整批轉碼，也就是服務的處理對象，是整份文件而非單一輸入項目，而且文件本身要描述清楚每個項目的意義，查核與轉碼服務可以據此針對各項目，選擇合適的查核或轉碼方式。因此程式只需要2次遠端呼叫，甚至同時呼叫可以平行運算的兩項服務，並且完全符合前述的Document-Based、Metadata-Driven的精神。
處理以XML描述的資料，需要剖析和轉換時間，如果程式開發人員缺乏XML的處理經驗，不斷使用XML轉換成DOM物件的方式，秏費的系統資源將會十分驚人。良好的XML文件剖析技術，以及適量使用其他替代方式，絕對有助於提升效能。
技術能力的提升
軟體廠商可以提出一百個理由來鼓吹企業必須立即導入SOA；而企業願意接受這樣的概念並且投入資源，實在是因為長期存在的應用系統擴充、延展、維護及整合等問題。
以系統的擴充性為例，這個問題的本質其實在於事先有無可擴充的規劃，以及系統當前的複雜度高低。而常見的擴充問題，多半源自高度連結（Tightly Coupled）的資料表格、程式邏輯與操作介面；所以當其中一方變動時，其他部分就需要配合調整。
再以延展性為例，廣義的延展性，包含負載容量、部署地點與管理規模的延展。一般規劃多半僅針對負載容量延展，並試圖以擴充硬體的方式解決。但如果問題癥結在於設計本身就缺乏延展性，即使擴充設備，還是無法達到期望的負載容量，更無需討論後兩種延展性。所謂延展性設計，應當考慮平行或是分散運算的可行性。如果系統可以適當切割成許多元件與服務，彼此低度連結，沒有狀態關聯（Stateless），就可以高度延展，部署在不同的運算環境。
SOA看來是可以解決這些問題，但真正的靈丹妙藥，是提高對於系統開發技術能力的要求。前面提到把細節和複雜度鎖進服務黑箱，是對現況妥協；要有效解決問題，最好的對策是在系統規劃階段就主動發掘潛在問題，納入規格，提出符合規格的設計，這絕對需要正確的設計觀念與良好的程式開發能力作後盾。
而物件導向方法，正是要透過抽象、封裝、模組、層次這四個基本元素，以及重要的基本設計原則，解決這些造成應用系統日趨複雜的問題。而近年流行的Design Patterns，提供許多良好的物件導向設計的實務經驗，這對於系統的設計與程式開發，也有極大的幫助。或許可以這樣說，SOA並非偶然，它其實是物件導向技術極致發展的表現。因此提升資訊人員技術能力，慎選具備良好物件導向技術能力的廠商，是推動SOA的成功要素。
管理模式的轉變
SOA在不衝擊既有系統運作的狀況下，有目標、有計劃的持續進行體質改造。SOA強調可以修改既有系統，建置新的服務。然而一個運轉順暢的應用系統，管理人員是否願意配合，同意改變現有程式並且容納其他外部系統來使用其有限資源？當這些系統是分屬不同部門時，問題可能將會更加突顯。
SOA架構下，如果依循著過去的管理模式，每個應用系統配置管理人員，很可能這個管理人員會是有責無權，因為他所管理的應用系統，一大部分是引用其他系統所提供出來的服務。
Google桌面是個很好的例子，使用者可以在桌面上設定由世界各地不同服務供應者所提供的新聞、天氣預報、匯率轉換或是股市行情等服務，而且這些服務偶而會出現中斷或是異常狀況，但是在Google的商業模式下，會促使供應者願意自行監控，並且主動排除狀況。
當企業入口網與應用系統也是由一群服務組成，那麼一旦某項服務發生異常，該項服務供應者是否有即時監控能力與設備在第一時間自行排除；或是在接到通知後，願意積極配合解決問題？Google有商業模式的加持，企業則必須找出適當的管理模式。