SOA初級班(3)淺談SOA架構設計

近年來很多人討論SOA（Service Oriented Architecture，服務導向架構），也有很多廠商在暢談自己代表SOA。在企業被產品說明書淹沒之前，筆者希望用中立的角度描述SOA與架構設計，希望幫助讀者建立更中立的SOA架構設計觀點。

維基百科的定義－SOA不代表任何廠商的特定技術或產品

維基百科中清楚地描述到SOA的幾個重點：

1. SOA 是一種軟體架構，這個架構主要是藉由低耦合力的軟體服務技術，實現商業市場中重要的資訊商業行為

2. SOA並不代表任何軟體廠商的特定實作技術或產品

圖一是維基百科中提到的典型SOA系統架構示意圖，在SOA平臺中，商業需求是由不同的軟體服務所實現的，而同時這些軟體服務則是由特定的應用系統所提供，這樣的層次分明下軟體系統背後的商業流程，能夠被明確的分工與定義，同時當商業流程的變化出現時，軟體元件也能夠「自然的」汰舊換新，甚至是百花齊放。

但是，問題來了，我們不難發現在實際導入的過程中，真正的挑戰會是在「 如何在 『Application Layer』上實作『Business Layer』 的規格』。」畢竟在SOA開章定義中，明確說明SOA軟體架構是不受限任何實作上的技術的。換句話說，真正的挑戰是系統與系統間必須要能夠互相的整合、銜接；在Linux平臺上的Java軟體服務，要能夠平順的和Windows平臺上的.NET軟體服務整合。

一般性指引：可重複利用、標準化、可量化管理
平順整合無疑是一件相當具有挑戰性的事情，對實際開發與導入的團隊來說，需要的絕對不只是「夢幻般的理想世界定義而已」，需要的是更務實的設計指引，以及更多實務上的經驗與運用。

好在維基百科不愧是開放智慧的結晶，一口氣就描述了3條一般性設計與架構指引，以及10條特定架構描述。

什麼是一般性設計與架構指引呢 ?

維基百科的描述重點，是描述在SOA的架構之下，所有支援商業流程的軟體服務，必須滿足「可以重複利用」、「標準化」、「可以被量化管理」三個要素：

● 可以重複利用：代表商業服務在流程不斷變動的情況下，可以重複運用在不同的商業流程之中。軟體服務是有價的資產，訂單服務不應該只支援現今的網路訂單流程，同時也應該可以支援未來手機行動裝置的線上下單流程。

● 標準化：代表軟體服務在實作上，必須要擁有跨平臺溝通的能力，因此也延伸出一系列平臺的規格標準化議題。W3 所制定一系列以Web Services為主體的標準規格，毫無疑問會是標準化的最佳男主角，然而需要更加注意的細節，是Web Services不只是通訊的標準，還有身分認證、授權信任等重要的規格議題。

● 可以被量化管理：對真實世界來說，複雜的商業行為，代表了複雜的軟體服務在背後運作，而這些服務之間如果無法被追蹤、管理、設定KPI等效能指標，軟體服務的實用性會大受質疑。

特定架構描述－消費者與提供者必須是低關聯相依性

剩下的10條特定架構描述，大體上可區分為描述「服務消費者與服務提供者之間的互動關係」、「服務提供者本身的設計指引」兩大類，筆者想談的是前者。

在SOA描述的系統願景中， 服務消費者與服務提供者彼此之間是不存在有任何「綁死」的描述性規範。這代表了兩件事情：首先，是服務消費者與服務的提供者間，必須是有非常低的「關聯相依性（Loose coupling）」， 服務消費者不能夠因為服務提供者本身的變化，而受到強迫性影響。

從實作技術的角度來看會讓你更容易了解：「元件A呼叫服務元件1.0 」， 當服務元件因為創新技術而提升為2.0版本時， 元件A實際上沒有任何重新改變內部設計或重新編程的必要。更生活化的例子，你我都是台電的電力服務用戶， 台電多年以來持續創新，電力系統的軟、硬體改版多次，但用戶家裏的插座，並不會因為服務提供者的內部變化，而需要重新拆除變更。

其次，是服務消費者與服務提供者彼此之間，只仰賴「服務的合約（Service contract）」 做為溝通依據。在這樣的前提下，合約的設計是很重要的，必須滿足一般性規範，合約本身的標準化、可重複使用性不受甲乙雙方限制，並且可以被量化約束。

除此之外， 另一個重點，既然服務合約有這樣的特性，合約在設計上就不僅僅是「技術問題」而已，在「服務的抽象化設計上」也是十分重要的一個設計議題。也許你會想，技術規格的標準化與量化不是難事，但所謂「抽象設計」就是個挑戰。

業界有許多BPM的顧問服務，或是特定商業與運用領域的專家，針對抽象化設計服務有相當多的經驗與建議，但是，很多人會問：「誰說的算？」其實，「抽象化」不是指「標準化」，畢竟每個組織運用的商業模式都不同，每個組織有各自的創新流程與方向，抽象化的目的，只在於讓服務的提供者所提供的服務能「更容易重複使用 (Reuse)」。

一個夠標準化的服務就能夠提供更多元創新的商業流程，例如7-11代收現金服務，目前可以支援代收信用卡費、電話費、線上購物……等創新流程，這就是一個可重複利用的好服務。

在SOA架構建議中，對服務消費者來說，因為不受限於特殊版本服務提供者，只受限於服務的合約，問題將演變成服務提供者的取得，就會是另一個有趣的議題。因為當服務真能設計得如此彈性，就可以任意取代替換不適用的服務提供者。

《作者簡介》李學麟
現任開發技術推廣經理，喜歡思考的獨立知識愛好者，專精於物件導向分析、設計、編程及軟體工程。曾任資策會 MCSD.NET 講師、Run！PC 雜誌特約專欄作家、台灣微軟特約技術顧問。