「服務導向架構」（Service-Oriented Architecture；SOA）透過定義明確、自給自足、可在電腦網路上隨處呼叫的服務元件，建立企業流程與應用程式。SOA架構可提供前所未有的商業效益，不但軟體功能可以重複使用，而且商業流程精確有效，亦容易彼此搭配使用維護。這些潛在效益，使SOA在企業應用上炙手可熱。服務元件的組織架構，對於SOA系統的品質有重大影響。因此，如何架構SOA的基礎服務元件，協助開發人員設計一套有用的SOA服務，便是相當重要的課題。

在服務導向架構（SOA）中，一個服務乃是指服務提供者所執行的一個工作單元，以達到一個或多個服務消費者所預期的結果。每個服務提供定義明確、自給自足的功能，採取例如與執行環境之間鬆散耦合的方式。這個功能完全透過介面契約與行為屬性來描述，隱藏實際建構方式，在網路上隨處可用。

SOA的基本要件包括服務提供者、服務儲存庫、服務仲介者、服務消費者等等，都以服務規格定義（service definition）作為描述、存取、傳輸、瞭解各項服務的要素。

轉換企業架構型態的現代SOA逐漸嶄露頭角，關於服務發掘與服務設計的方針也逐漸成型。在這個SOA逐漸成熟的階段，一些重要SOA建構方式的概念與實務經驗相當值得注意。關於服務設計的各個層面，我們將探討一些通用的軟體工程理念與考量點，以落實SOA的關鍵層面為重點，例如如何建立商務的歸屬、如何發掘及設計服務內容、以及如何實現SOA企業架構轉型工程。

我們以國際物流服務供應商──德國郵政公司廣泛採用SOA的實務經驗為例。德國郵政公司的SOA架構以商務為重心，該公司建立了多個SOA流程與方法，將SOA的潛在效益付諸實現。此外，該公司還採用一套相當精細的企業級服務平台，稱為SOPware（服務導向平台），這套平台以甲骨文（Oracle）的Fusion Middleware Suite為主，提供商務服務仲介所需的支援架構。如此一來，各個業務部門不需要擔心服務建構與供應的技術細節，而能輕鬆快速地組合高階商務服務與流程。

起跑點：服務發掘（Service Discovery）與套件管理（Portfolio Management）

商務服務與技術服務之異同

SOA架構的主要特色，在於能透過商務推動IT發展，又能透過更具彈性的IT來提昇商務運作。雖然SOA的基本概念能用來建立更有效率的IT運作，但SOA更大的優點在於能讓業務營運快速建立高競爭力的商務應用軟體，並使這些軟體能經得起環境變遷的考驗。相較之下，技術服務通常內含於商務服務的支援架構中。雖然這些技術服務也相當重要，但一套良好的SOA建構體系應該明確劃分商務服務以及技術服務的區別。

為了完全發揮SOA的轉型效益，商務人員應該負責找出商務服務的適用範圍，並描述這些商務服務的特性。包含德國郵政公司在內的多家企業，都採用商務領域（business domain）的概念來建立商務歸屬。

建立SOA之商務歸屬（Business Ownership）

為了建立一套共通的語言，讓商務人員與IT人員能藉此討論相關服務、界定商務服務的歸屬，我們應該先檢視商務營運的基本結構與相互關係 。首先，將一家公司的商務範圍劃分為多個商務領域，每個商務領域都內含緊密相關的功能與資料，例如可劃分為客戶、產品、合約等領域。為了設計出最佳的領域劃分方式，發揮長期的穩定性效益，並在各層面建立紮實的SOA根基，我們必須先了解這家公司的經營方式，如(圖一)所示。

《圖一　簡化的高階商務領域基本架構示意圖》

德國郵政公司的實務經驗顯示，判定主要的商務物件以及彼此的相互關係，是建立領域架構的重要第一步，接下來可以更深入分析各個商務流程以及彼此的互動關係，建立更精確的領域規格，以及某些主要領域中的次領域。領域架構應該和實際商務情境以及未來可能的商務情境加以比對，以檢查領域架構是否紮實。

設計商務領域必須對業務有深入的了解，同時也需要仰賴某些直覺。就以「客戶」與「客戶關係」兩個領域來說，第一個領域主要管理其他領域所需的主要客戶資料，而第二個領域則追蹤長期客戶關係的各個層面。如果仔細分析基本的業務關係，可發現兩者其實有基本的差異。客戶領域提供的資訊，變動頻率不高，但需要提供一個客戶各層面的360°視角，而且客戶資料的使用方式，在大多數領域都相當近似。相較之下，客戶關係領域所提供的功能則有相當多的變異，而且變更頻率頗高。只要客戶與該公司有新的交易，或是該公司的CRM策略有所演變，都會使客戶關係領域產生變化。除此之外，負責客戶關係的商務人員，使用這些資訊的方式也各不相同，例如有些人將其應用於即時交叉銷售（real-time cross-selling）；有些人則使用這些資訊來提供更佳的客戶服務。

另一重要考量則是，如果要使用SOA轉變整個企業IT架構，商務人員必須對商務架構有所歸屬，該業務的歸屬者同時也需負責定義商務領域的範圍，並負責提供意見，判斷該業務領域該提供哪些業務服務，以及該領域需要哪些服務（所需服務則由其他領域提供）。這樣的做法可以建立一套整體的商務及IT規範，包含資料歸屬的明確定義。在德國郵政公司，來自商務IT機構的企業架構工程師與服務設計師，可協助商務歸屬者敲定服務的細節，但最終的責任還是要由商務人員來負擔，如（圖二）所示。

《圖二　商務服務架構作為流程與應用間的抽象層示意圖》

商務領域以及商務服務，可形成企業流程架構與應用架構之間的一個抽象層，其效益相當明顯：透過領域與相關服務的概念，將流程與應用程式拆解開之後，變遷週期就可以各自獨立管理。IT系統（包括應用層與基礎架構層）可以變更或替換，只要服務合約保持穩定，就不會影響商務流程。反過來說，如果許多建構元件（商務服務）已經就位，可供重複使用時，商務流程就可以相當輕鬆地變更或擴充。

服務發掘（Service Discovery）

雖然在某些方面，服務與元件相當類似，但服務也類似小型的應用程式，需要以管理應用程式的類似方式加以管理。如（圖三）所示：德國郵政公司制定了五個服務設計流程，提供服務套件的建構與改進基礎。這些流程也可廣泛應用於任何其他產業。

《圖三　服務設計流程示意圖》

要建立與管理一套商務服務套件，第一步先要進行服務的發掘。為了找出一個商業領域應該提供哪些服務，首先要調查全部的商務物件與其相互關係。商務物件（例如客戶、發票、住址等等）並不是IT物件，商務物件是業務營運所需的要件，完全以商業詞彙加以敘述，不牽涉任何IT系統的細節。例如「客戶」領域的一項重要服務可能是Customer Information（客戶資訊），而這項商務服務的基本操作方式可能是「建立、讀取、更新、刪除」等類型，但這個領域也可能有更複雜的功能，需要結合數個基本的服務運作，例如客戶領域可能包含一個Customer Address Consistency（客戶地址一致性）服務，可以檢查客戶資料是否存在、檢查客戶的正確名稱，並檢驗（甚至更正）客戶的地址。其它還可能需要的服務，可透過主要商務物件的特定組合而得知（例如合約與相關的發票）。

這種由上而下的服務發掘，可以再搭配兩種額外的方式。第一種是追蹤商務流程、追查這些流程與商務環境之間的主要互動方式，然後將類似的功能集合起來。這種方式有助於發掘實用性服務，這是單以由上而下方法所容易忽略的。這種商務流程導向的方式，可有效檢查服務的完整性，並顯示特定服務的重覆使用性，但運用這種方式時也需要小心：不同的商務流程（尤其是不同商務人員所制定的流程）常會用不同的語意來表達相同（或近似）的概念。要使服務套件合乎實用，一項重要條件就是要對商務詞彙的語意進行透徹而嚴格的分析（包含商務詞彙的翻譯與協調）。值得注意的一點是，如果單用這種方式，常可能造成服務的定義過於微細瑣碎。

除此之外，也可以透過用途導向的服務發掘方式，來尋找有哪些IT基礎架構應用程式（例如大型主機或舊型應用程式）的功能和資料；至今仍有商務應用程式在使用當中，然後將這些程式外加服務介面的包裝，在未來的商務應用程式中繼續使用這些服務。雖然這種由下而上的方式可以搭配其他兩種服務發掘方式，但由於各服務之間的語意缺乏協調，因此這種方式無法帶動長遠的SOA轉型，只能用於諸如在行政環境中證明SOA一般性運作的階段。

在服務發掘過程一開始，可先投資小量的成本，結合上述的各種方法，建立一些概念性的服務（例如只有規格，沒有實際建構內容），然後逐步進行服務的實際建構，嚴格遵守每個專案的商務優先度與商務案例。因此，商務分析師以及企業商務架構工程師，在整個商務服務發掘的過程中，就扮演相當重要的角色。

實現改革：透過SOA轉變企業架構

建構服務套件

德國郵政公司的服務發掘過程，產生了將近100個候選的商務服務（每個服務平均有五到十個操作功能），這些服務根據商務價值、重複運用性、IT複雜度降低能力等因素排定優先順序。這些候選服務可做為後續服務套件管理過程的基礎，讓服務的定義更為妥善，並帶動特定服務的細節規格、建構方式、重複使用與生命週期管理。

在建立整個服務套件的過程中，有許多重大問題需要解決，例如服務的歸屬、建構與維護這些服務的資金來源、生命週期的管理等等。究竟應特別注重SOA服務，或特別注重專案的執行，兩者之間應求取平衡，其中有多種不同的服務實踐風格可供運用。例如，可以先在企業內部建立大部分可能有用的服務，然後再進行一系列SOA專案來建構或使用這些服務。這種較為服務導向的方式首先建立一套豐富的服務套件，並制定紮實的長期策略，同時需要某種程度的先期投資（尤其是服務設計方法學以及服務仲介平台）。另一種較為專案導向的方式，則是以某些專案所需的服務為優先，不強調這些服務將如何共用，這種方式可提供短期的投資報酬，但可能影響長期的SOA效益。

德國郵政從一開始，就強調架構的轉型應該根據SOA原則逐步演進，這種演進方式以較小的IT專案著手，具備明顯的商務案例以及有限的範圍，以提供短期的商務效益（策略性），並符合企業整體的最終應用目標（根據商務領域所制定的SOA藍圖）。這些專案必須有其商務歸屬者，且無論使不使用SOA，這些專案都必須執行，因此這種演進法可在服務導向與專案導向方式之間取得良好的平衡，如（圖四）所示。

《圖四　SOA逐步演進示意圖》

制定服務規格

每個專案所建構的服務，都需要針對服務的各種特性擬定細節。德國郵政公司採用三步驟的服務規格法。第一步驟得自於服務發掘過程，提供一個「企業服務說明」搭配德國郵政的企業架構模型。這個企業商務物件與服務模型，旨在說明服務架構的邏輯觀點，其中包含商務領域、物件與服務。在這個模型中，各種服務以介面加以描述（UML為其正式語言），服務操作的相關說明，則參照模型中的商務物件與其他資料類型。

第二步驟為詳細的商務服務規格，其中包括：擬定服務介面的細節、分析IT專案的特定層面（例如服務範圍的可能限制），然後進行服務的實踐或獲取。商務服務的規格在服務設計過程中相當重要，因為這些規格是該服務所牽涉的人員之間基本的溝通方式。在擬定服務規格時，應該考慮下列幾大類的資訊：

服務規格的最後一步是「技術服務規格」，特別探討服務仲介平台的相關要求，而其他先前所未提及的技術規格（例如特定的資料流量、訊息大小等等）也在此詳細說明。將服務加以適當分類，也有助於該服務在設計與建構上應用業界最佳慣例。

一項服務的功能、品質與方針，定義了服務供應者與消費者之間的合約型態，這也就是所謂的服務契約。目前產業界並沒有全體通用的服務規格標準，但WSDL與UDDI已經儼然成為基本服務規格的描述與發表標準。此外，現在也有愈來愈多的試驗採用WS-I（Web Services Interoperability）規格，讓服務能更廣泛地重複使用。

規格的重複修訂，可以產生更精緻、更紮實的細節，具體說明服務的介面與功能性，讓服務規格可符合目前的需求以及未來預估的需求，使服務更具彈性及成本效益。服務規格的重複修訂，通常需要商務服務歸屬者、商務分析師、技術分析師三者之間密切的配合。

服務的最佳粗細度？

SOA開發人員常常爭論服務的最佳粗細度，雖然服務粗細度目前並沒有一致的量化標準，但可以沿用元件設計的理念，例如：呼叫該服務所影響的功能點或資料元素數目。如果一個服務在商務應用程式中呼叫的次數太頻繁，或通常只有一小部分的功能被使用，則該服務可能劃分太粗。如果一個服務需要太多的參數，則該服務可能太低階、劃分太細。雖然這些觀察乃是以實際的服務建構結果為基礎，這個問題仍可透過有效的服務套件與生命週期管理過程來解決：服務套件的適用性可隨時間大幅成長，首先針對高價值的服務運作來著手，然後逐步加以擴充、演進。一項服務若能達到適當的粗細程度，將可發揮最高的簡便性、重複使用性以及可管理性。最適當的服務並不一定要以粗細度來區分，而應以能否發揮最高商務價值來考量。

德國郵政公司通常將較粗的服務首先加以建構，這些服務都是較穩定的基本服務，從一開始就可以確立。漸漸地，服務消費者愈來愈多，需求也愈來愈精細，因此可以建構較細的服務運作。這些精細的服務運作可提供良好的基礎，用以制定一套更豐富、更複雜的服務運作。例如，可將服務彼此結合（複合式服務運作）或搭配成一套流程（搭配式服務運作）。

服務建構與生命週期管理

雖然服務的建構在大多數層面與軟體開發相差不多，不過仍有兩大差異。

第一點，根據所選定的服務仲介平台，其服務介面程式碼不一定要人工撰寫，如果有合適的服務設計工具鏈，可以透過工具自動產生。德國郵政公司根據模型導向架構法，採用一套服務設計工具鏈，起點為企業商務物件與服務模型，接著將這個模型轉變為專案商務物件與服務模型（PBSM）。PBSM的細節在專案規格中進一步敲定之後，工具鏈可以產生德國郵政公司SOPware服務仲介平台的程式碼骨幹，以及服務規格說明文件。服務規格採用適當的工具建立模型，而XML與XMI則是廣獲肯定的標準化交換語言。

第二點，在建立或獲取服務仲介平台時，必須謹慎考量該平台是否支援服務測試，因為服務本身需要鬆散耦合的環境。以德國郵政為例，服務模組的測試採用DevBox，該元件為SOPware的一部分，可提供服務呼叫程式庫，並可在開發人員的本機電腦上模擬服務供應者。除此之外，德國郵政也設立了一個服務架構測試實驗室，該實驗環境提供了所有服務與服務供應者，以供SOA應用程式的整合測試之用。

雖然服務介面將成為企業架構中的穩定要素，服務將會逐步成長，因為愈來愈多的服務運作將加入系統中，不過隨著幕後的服務供應者逐漸改變，服務的建構方式也會變遷。儘管SOA架構可以將變遷的影響降到最低，服務的生命週期還是需要管理，其中包括版本控制、商務服務儲存庫（包括服務模型與規格）、以及可在建構與執行期提供服務實體存取的技術服務儲存庫（服務登錄庫）。

技術考量：服務平台與標準

從以上得知，商務服務可以將商務變遷與IT變遷有效解離，但服務仲介所需的IT基礎架構（或其中某些要件）也有需要變動的時候，許多企業在EAI或舊型中介軟體之中糾纏不清，無法切實配合商務所需的腳步而變遷。當某些技術已經過時而無法因應效能成長需求時，仰賴特定工具的EAI配接器與介面，由於需要專屬的中介軟體協定，因此不能輕易地加以轉移，在這種情況下，原先預計藉由科技所實現的彈性也不復存在。

採用標準化的服務仲介方式或可解決以上課題。例如新發表的Java標準JBI（Java Business Integration）、或是類似德國郵政SOPware的方式（其也是採用JBI）。SOPware之中採用了另一個抽象層，特別將商務服務邏輯與其下的IT基礎架構互相解離。這個抽象層完全採用J2EE（也可選用.NET）、XML、WS-I等標準。在2001年完成開發的SOPware，經過技術進展與功能擴充過程，幾乎所有的基礎架構元件（例如應用伺服器、MOM、目錄伺服器、轉型引擎等等）都已經經過有效的更新升級，但開發介面仍然不受影響。關於服務的仲介方式，開發人員只需知道簡單的XML語法API，即可開發服務或呼叫服務，相關的技術細節與工具則隱藏於幕後。程式設計師可以專心建構商務邏輯，不需要浪費時間撰寫低附加價值的基礎架構碼。對於德國郵政而言，這種策略提供最佳的彈性與投資保障，這不僅針對商務邏輯而言，對IT基礎架構也有傑出的效益。

結語

雖然有許多科學原則可作為服務發掘與設計的指引，但如同許多架構研究一般，業界老手的直覺經驗在整個發展過程中相當有益，尤其對於初期開發過程更為顯著。SOA的實踐，需要快速而簡易的建構方式：商務人員應該以商務邏輯為重，而不應該操心通訊協定與傳輸方式，因此採用功能完整的SOA平台可說是相當實用。此外，採用開放式標準與模組化技術元件，可以讓SOA資產的重複使用率更高、TCO更低，並可避免被廠商牽著走，也可降低採用SOA技術的風險。

簡而言之，SOA=語意整合+鬆散偶合+系統化演進。SOA可作為商務人員與IT人員之間的共通語言，消除許多企業長期存在的代溝，突破交流瓶頸，讓商務流程與IT基礎架構發揮更高的彈性。（作者為美商甲骨文Oracle台灣分公司解決方案協理）