SOA進階班(2)建立標準管理模式，克服SOA帶來的全新挑戰

複合應用程式和服務分層
對服務定義和構造採取分層定義，反而可讓開發團隊建構出粗細適中的混合服務，以滿足現在和未來的業務需求。

SSLC的執行階段
SSLC 執行階段管理得當的話，將有助於實現SOA計畫希望驅動的企業靈活性和敏捷性。

安全和管理
唯有管理得當，回應業務需求，企業組織IT專案能才能稱得上成功。在SOA的功能中，這意謂著更明確了解服務使用的情境，才能為正確的客戶提供更高品質的服務。

應用程式的封裝
SOA計畫在組織中取得成功的另一項新挑戰，可能來自令人出乎意料的地方：就是打包既有的應用程式。建置SOA計畫的組織單位，無論大小往往都會形成專案小組，以支援服務當前或所需業務流程。此一服務工程團隊的主要任務可能是研究SSLC（Shared Service Lifecycle，共用服務生命周期）的整個生命周期與SSLC相關的特定問題。

複合應用程式和服務分層
SOA實踐是一種突破單一應用程式的局限性、縮短開發／發布／測試周期的途徑。只有專注於複合應用程式的概念，才能獲得這樣的敏捷性。按定義來說，複合就是把一些現有和新建服務裝配到一起，從而創造出滿足業務需求的新功能。

在成熟的SOA環境中，為快速滿足業務需求，利用現有服務，即可將完整的業務應用程式裝配在一起。為確保此供應過程的靈活性，開發團隊在設計階段必須非常謹慎，避免把業務邏輯直接實作在服務中。

另外，為了保證不會喪失敏捷性，SSLC 執行階段應致力於確保服務協定、策略和後設資料（meta data），讓它們不會造成未來需求的阻礙。獲得這種執行階段靈活性的方法之一，是要設計和提供一些服務，定義出特定層次，其中可能需要畫分成系統的邏輯層和概念層。

在SOA計畫中，利用現有資產，並以高度秩序化的方式實現業務靈活性，需要一些關鍵能力，而複合正是其中一種方式。許多企業服務切割得太細碎，以至於增生許多小服務，但難以複合成更大的邏輯服務。對服務定義和構造採取分層定義，反而可讓開發團隊建構出粗細適中的混合服務，以滿足現在和未來的業務需求。

實體服務
資訊和存取服務是將資料以原始形式提取出來的功能。定義實體服務構成企業參考架構資訊和存取層的一部分。這類服務應該要能支援特定資料來源中細膩的CRUD（新增、讀取、更新、刪除）作業。

規範服務
規範服務定義的是企業讀取資訊的標準方式。通常，這種讀取方式會使用像是SWIFT（Society for Worldwide Interbank Financial Telecommunications，金融訊息交換平臺）等業界標準格式或其他特定產業的標準。建立通用的基礎語言，就能形成清晰的製作人層（Producer Layer）。這個標準層獨立於實體服務，可作為共用服務或複合應用程式的起源。

邏輯服務
在企業內建立標準規範結構時，還有一個問題，就是這些結構大量的占用資源。服務的使用者其實想要的只是結果的一小部份，但此類一般性服務回送的資訊過多，使用者可能會擔心效能因而下降。

建立邏輯服務則可實現更細膩的互動，而不會犧牲在規範結構上建構服務的效益。而且，上游應用程式（Upstream Applications）也需要對資訊執行邏輯分組，例如將客戶資料整理成單一版本。理論上，標準的邏輯服務可以提供複合性的功能，並幫助企業獲得立即重覆使用和縮短上市時間等效益。SSLC的執行階段
深入了解SOA中分層服務的重要性之後，現在讓我們進入SSLC 執行階段的探討。這些階段管理得當的話，將有助於實現SOA計畫希望驅動的企業靈活性和敏捷性。

發布和供應
SSLC的發佈和供應階段重點在：邊界需要做些什麼。更特別的是，這個階段應建立SOA管理的控制點，並透過定義諸如服務介面和契約等促進服務重覆使用。

服務介面
服務介面為客戶提供了一種標準機制，使客戶能夠根據它所提供的契約，存取此實作提供的功能性。

服務契約
此契約應包含Functional Metadata（用來表示與服務互動的方法）和Non-Functional Metadata（表示哪些條件和限制適用該服務的用戶）。如能確保該服務實作中未出現某些邏輯，像是使用的條件和限制，服務也就更可能透過更多元方式複合，但目前開發團隊或企業多半都還未考慮到其中大多數的因素。服務契約在執行階段可作更改，無需在實作中重新編譯代碼，這一點很重要，而絕妙之處正在於如何有效利用這種靈活性。

Metadata和規則
只有為支援服務而定義的Metadata和規則，才能真正實現服務重覆使用性和複合服務。建立真正靈活的SOA環境時，Metadata的管理乃是竅門所在。透過定義一系列規則，即可在實作外，輕鬆管理單一的服務或某一類服務的執行階段控制。這些規則不僅定義了規則適用的客戶，還定義供應內容的對象、時機和服務細節。由Metadata驅動的規則的另一項優點是，它可在動態條件下串連用戶連線和訊息轉載。

由於專注於SSLC執行階段需求，在SOA計畫成功管理上，控制和管理開始發揮越來越重要的作用。結果，服務應該要發布到某種形式，以便可支援服務生命周期的組態和變更管理的註冊庫（Registry）。此註冊庫也可與一個企業儲存庫整合，而該儲存庫又可能儲存了其他的相關資訊。

整合和部署
SSLC和SOA以提高靈活性和敏捷性為圭臬。服務重覆使用是達成目標的方法之一。如SSLC的「建構和複合」階段中所提及，服務可當成新服務的一部份使用。這聽起來很自然，但以下這句話很重要：確保設計階段的複合服務，使它不會影響SSLC的整合和部署階段的靈活性。

然而依靠服務實作來動態組合服務，以支援業務需求，可能引發以下問題：後續階段進行更改時，使得相依性和版本的不一致。因此，我們建議你利用比如Business Process Modeling（BPM）等動態工具促進服務聯結，而勿將服務嵌入在實作中。

另一種方法是在服務實作中使用代理服務（Proxy Services），而不使用真正的業務服務終端。利用ESB（Enterprise Service Bus，企業服務匯流排）公開代理服務，實體服務就可能獨立於消費服務而便於更改。

執行階段服務的動態組裝並不是與生俱來的。無縫整合和部署的能力需要一個去耦（Decoupled）的服務環境，以解決一些需求，例如降低服務間或智慧終端之間的點對點關係──這表示服務實作包含了編碼邏輯，它會阻止服務在未明確規畫（編碼）情況下重覆使用。

另外，服務的開發團隊也必須認清，服務必然會隨時間而更改，舊版本退役，必然會有新版本發布。在整合和部署階段，應該設法支援服務的多種版本，避免組織演變為一種製作者大雜膾、不受控制的狀態。

為了在SOA計畫中支援這種動態性，必須尋求以組態為基礎的路由機制，它必須有能力詢問一個服務請求的前後關連，並以組態為基礎的方法發送，而非寫程式強制終端達成目的。甚至該環境需能支援無縫的變更控制，對變更資訊提供更精確稽核的能力，而且可聚集組態到管理群組中，一旦出現問題時還可回復到原來的狀態。

最後，SSLC的整合和部署階段應支持以角色（Role）為基礎的操作介面。管理功能不能只限於管理發布和供應階段所定義出的服務契約。因為如果只專注在單項的服務，以及單項服務的變更管理功能，就忽略了複合應用程式的問題，便退回到傳統應用程式開發的情況，使得某些系統難以監控。安全和管理
唯有管理得當，回應業務需求，企業組織IT專案能才能稱得上成功。在SOA的功能中，這意謂著更明確了解服務使用的情境，才能為正確的客戶提供更高品質的服務。

SSLC的安全和管理階段應能讓企業透過規則（Policies）管理安全限制，而非在服務中實作。服務規則可規定呼叫服務的協定等傳輸層安全，以及利用WS-Security標準確保互操作性。較低層級資料安全則可透過資料摘要服務，或某些分散式授權引擎（Entitlement Engine）來管理。尤其對共用服務的生命周期而言，這種安全性是透過對規則和相關契約管理實現。

在SSLC的任何階段，即時獲得流程的透明度都很重要。SSLC中的安全和管理階段重點，在於根據當前實際使用情況管理服務，以滿足業務需求。其中包括效能和錯誤事件的SLA管理。此類資訊的管理能力通常是遵循企業或組織內既有的管理方式。

以購書為例，我們得確保訂單能在一定時間內得到回應，此外，限制級的書籍，就只能賣給已經通過年齡驗證的人。此時便要設計一個服務規則，用以確認使用者是否通過驗證。

任何違反SLA的情形，都可能被通報為異常或違規。一個成熟的SOA組織需具有明確定義的管理流程，以便明確標識控制點和異常情況，所有控制點和異常情況都會記錄在企業儲存庫中。

建立好SLA和業務規則後，組織可利用企業儀表板，提供即時和集中回應。透過這種透明度，安全和管理階段應具備靈活性，以提高達交的服務品質。

評估
SSLC的最終階段牽涉根據使用情況詳細分析服務。這類分析和評估的目的，在於使組織更清楚依據實際情況管理服務使用行為。

最初為實作某種特定功能，或使用層級而開發的服務，往往實際的使用情形又高於原始預期。像這種執行階段的變更是企業SOA的良性發展，但組織必須有效管理，以避免它對SLA和SOA的效率產生不良影響。

在評估過程中，應確定服務利用率是否如預期，或是需要重新分類以維持或改善服務的水準。這種重新分類更改了管理一項服務向前推進的方式，並要求要在支援未來結構上而進行更改。如果該服務是最初為特定業務而設計，現已開始推展到整個企業範圍的水平服務，那麼這一點尤其必要。因為此類服務可重分類為企業服務，並給予相應的管理方式。

評估階段的另一重點是，收集衡量的標準，以展示ROI和SOA計畫的成功。SSLC的一條衡量標準是服務的重複使用率，尤其是評估SOA程式未來成功情況時，重複使用與重新開發的比重是重要的依據。要使衡量標準真正發揮效果，必須從第一天開始蒐集資料，並能與過去的資訊比較，如先前IT計畫中的上市時間、重複使用度以及中斷修復迴圈的減少。

最後，SSLC的評估階段應該用以促使下一輪的候選服務與需求目錄（Need Category）間的一致。度量標準可直接反映需求目錄中標識的相依性是否精確表達出實際情況。

另外，服務使用和複合還顯示其他的關係，保證開發了明確、可管理、可度量的服務。透過評估這些關係，這些相關性服務將比單純透過SSLC的設計階段而容易看得到。

變更
變更，業務演化中無法避免，也是必要不可少的組成部分。管理SOA和SSLC中的變更，帶來了全新的變更管理挑戰。服務引入組織帶來了許多新的抽象概念，例如服務契約和策略等概念，需要用另一種方式思考功能是如何開發的。

SOA還引入一種可能性，在某個特定的時間，組織在執行階段可能擁有多個版本的服務。這種想法並不適於所有組織，也帶來管理的挑戰：應該在一段時間內，應用程式需支援先前版本、更新版本，以及通知用戶即將改版。

很多組織 「強制」用戶升級到最新的服務版本，解決這些困擾。儘管這是一個解決方案，但是成熟的組織應該可以提供使用者更多的選擇，讓他們在需要的時候才轉到最新的版本。他們可以透過服務註冊庫支援舊版的服務，並利用契約控管變更及轉換的請求。應用程式的封裝
SOA計畫在組織中取得成功的另一項新挑戰，可能來自令人出乎意料的地方：就是打包既有的應用程式。組織中的應用程式，可能引入數以百計的服務，而且這些服務可能並不符合之前定義的服務指導方針。

未被結構化的服務，可能會對SOA計畫造成嚴重破壞。這些服務可能不符合SLA需求，如果公開的服務來自核心的企業系統，比如客戶關係管理系統、資料倉儲和ERP，我們強烈建議組織建立管理模型，明確地處該理應公開及管理的服務。

方法之一可能是：透過SSLC的發布和供應階段，提供額外的服務策略或契約，控制封裝的應用程式。再與安全和管理階段工作結合，可減輕組織中難以管理的服務不斷增殖。

服務契約
人們往往未能意識到服務契約是一份正式的、有約束力的協議，可能會制約未來的靈活性。由定義可知，一份契約是兩方或多方採用一種特定行為方式的約束性協定。不論你喜歡與否，透過建立服務控制，生產者和消費者都將受到特定規則的管理。

這種規範模式構成了你所公開的、有約束力的契約。所有用戶都必須為服務提供這種規範，並且作為一個輸入參數。我們必須謹慎，確保模式不會允許過高的靈活性，如果靈活性過高，將導致未來嘗試調適或維護服務時，服務變得脆弱，並越來越難以處理。

服務契約提供了一種很好的方法，確保服務能迅速和有效地被利用。此概念與物件件導向（Object-Oriented）程式設計中的多型（Polymorphism） 相似。而服務設計中的最佳實踐，允許需求在契約層級獨立演進，保持服務實現的簡單和整潔。

策略和契約自身可能擁有多對多關係，並且多個服務可能實現同一契約，清楚這一點後，就可利用服務儲存庫隨需調整的能力，從而管理系統執行階段的操作。真正的鬆散耦合，需要服務的基礎架構中存在多對多關係。

遺憾的是，契約和策略所獲得的收益包含一些技術限制。比何WSDL（Web Services Description Language）目前無法對所有組織需要的功能和非功能性需求提供全面支援。此外，WS-Policy規範仍然有所欠缺，它只為交換策略資訊提供可互通的容器，但並未支援指定的策略行為。隨著SOA的持續成熟，相信這些限制不久之後就會得到改善。

管理並利用Metadata
從長遠角度來看，SOA計畫的成功取決於如何管理和利用Metadata。組織中Metadata的使用，將是短期成功和長期改造間的差異。Metadata描述服務以及所服務的用戶之間的互動。理解Metadata可幫助組織避免將管理和流程硬性編碼到工具與服務之中，從而允許了資源的動態發現。

組織必須能夠利用SOA的基礎架構獲取很多資訊，而不僅僅是服務細節，例如建立Metadata儲存庫支援所有SOA文件，描述環境中的流程和操作順序。如能有效管理Metadata將可幫助企業在整個管理流程中，建立恰當、可度量的控制點。

服務是企業的資產，管理得宜將成為關鍵競爭力
執行階段中的服務是企業的資產，如果無法追蹤和度量SOA平臺的收益以及成本節約情況，那麼將來的成本收益決策就可能僅限於主觀資訊。

透過共用服務的執行階段管理，組織將改善SOA計畫的效力。與傳統軟體發展不同，SOA主要聚焦在建構可重用的服務，並透過契約和策略促進服務的靈活性。

除了可靠的設計實作和執行階段的管理外，組織還應認識到SOA也帶來了新的挑戰，必須建立一致的管理模型，並容許一些不確定因素（如變更），變更可能與創新相關，若管理得當，SOA可成為企業的關鍵競爭力。