關於Web 2.0 的SOA 經驗教訓

Kyle Brown, 傑出工程師, IBM
Rachel Reinitz, 傑出工程師, IBM

歷史重演

我們以前都聽說過：一項新的技術推出了，然後突然之間，所有使用較舊的技術完成的東西都變得過時，將會消失。乍看之下，新的 Web 2.0 技術似乎也遵循這種模式。這些技術的中堅分子將告訴您需要放棄所有 SOAP 服務；不僅使用 SOAP 和 WSDL 進行構建會延遲專案進行時間，而且還不能帶來任何好處。事實當然並不是這麼簡單。

雖然通過 REST 可以更為簡單地構建一些服務，尤其是面向 Internet 或 Ajax 客戶端的服務，但是仍然有大量服務能通過應用 SOAP、WSDL 和 WS-* 規範受益。另外，根據您所擁有的 SOAP 服務型別，您可以通過將服務轉換為 REST 服務來採用 Web 2.0；這一點尤其適合面向資料的服務。不過，把這個問題放在一邊，即使您決定對服務採用 REST，也最好看看我們通過構建企業 SOA 系統得到的一些經驗教訓，瞭解如何在構建基於 REST 的服務時加以應用。我們從幾個重大的領域吸取了一些非常慘痛的教訓，這對與您而言無疑是幸運的。我們在這裡與您分享這些經驗教訓，旨在幫助您避免類似的難題，成功實現 Web 2.0。

1. 實現新業務模型

CEO（以及 CIO）的首要目標是進行創新和開拓新市場。SOA 的一個關鍵賣點是，能夠通過將服務作為構建塊提高業務流程的靈活性，從而實現新業務模型和創新。SOA 通過與業務流程管理（Business Process Management，BPM）結合，能夠為企業提供最大的價值。BPM 的一個常見目標是開拓新市場或地區，加速新產品或服務的推出。與此類似，通過 Web 2.0，您可以採用之前不可能的方式觸及客戶及合作伙伴、與之溝通和進行協作。

Web 2.0 概念可以通過多種方式驅動新業務模型。企業可以構建社群，使使用者成為關鍵資料的源頭，圍繞使用者構建生態系統，尋找與使用者溝通的新方式以及支援將資訊“混裝”為新表單或檢視。eBay、Amazon.com、Flickr 和 Twitter 等企業就是核心價值和業務模型來自使用者生成的資料的企業。這當然是簡化的說法，但是如果將 Web 2.0 僅視為以豐富型 UI、Atom Feed 和基於 REST 的服務為重點的一項很眩的技術，那麼就可能會忽視 Web 2.0 如何用於實現基本業務變更。

2. 與業務部門溝通

SOA 的一個重要成功要素是，它在兩個級別同時取得了成功；它既能與業務部門成功溝通，也能與 IT 部門產生共鳴。為了實現上面所討論的 Web 2.0 的更高階的價值，企業必須明白 Web 2.0 所扮演的轉型角色以及實現所需的投資。通常，為了採用新技術，IT 需要通過將技術與業務價值結合獲得企業的支援。BPM 和 SOA 之間的聯絡強調了業務和 IT 間需要保持一致性。最簡單的方法是，首先解釋 BPM 的好處，然後說明 BPM 為什麼最好在 SOA 上實現。通過這樣，就可以說明二者之間的補充關係。

這個成功的部分原因是，IBM 能夠很好地整理出我們實現 SOA 優勢的方式，並使用業務和 IT 部門都能理解的語言進行表述。這裡，我們使用一些常見場景（如一系列關於電子商務模式的紅皮書中的 IBM SOA Foundation 場景）來幫助以業務人員能夠理解的方式說明價值。

這方面要吸取的關鍵經驗教訓是，您需要儘可能具體地說明業務價值，最好能提供採用 Web 2.0 的預計投資回報（Return On Investment，ROI）。讓我們面對現實：業務社群不一定會像開發人員一樣對新技術的出現表現出很大的熱情。因此，為了採用 Web 2.0，您需要使用業務人員熟悉的語言與業務社群進行溝通（就像與開發人員溝通時一樣）。一個示例啟動場景是，使用 Web 2.0 為業務或產品構建一個社群，並以此驅動價值，如提高客戶服務和品牌忠誠度。在表述這些價值方面，我們都需要更為成熟（這方面的書籍越來越多，可以提供幫助；請參見參考資料），而且我們都需要在不過度提及所使用的詳細技術的前提下解釋 Web 2.0。這是我們在 SOA 方面相當成功的一個方面，與能夠在不涉及細節的情況下介紹 Web 2.0 的業務好處一樣重要。

3. 以堅實的方法為基礎推動採用

IBM SOA 方法即面向服務的建模和體系結構（SOMA 和 RUP-SOMA）。SOA 的另一個關鍵成功因素是作為 IBM SOA 方法基礎的各種實踐、過程和規則，及這個方法與業務建模技術的緊密聯絡。IBM Business Consulting 開發了元件業務建模（Component Business Modeling，CBM）並將其作為 SOMA 的關鍵輸入。CBM 和其他業務建模方法會讓業務使用者參與進來，幫助他們瞭解業務和 IT 的一致性。SOMA 強調在服務指定和實現的全過程中與業務的一致性。SOMA 和 RUP-SOMA 並不是最初使用 Web 服務時從 IBM Rational® Unified Process (RUP) 的使用情況一下子就完全形成的，它的開發和細化經歷了多年時間，而且將繼續進行評估和修訂。

為了成功，需要對現有 SOA 和麵向物件的設計方法進行發展，為 Web 2.0 形成穩固的方法基礎。例如，始終需要確定 Web 2.0 應用程式的目標，另外還要尋找確定其溝通方式的方法。正如前面提到的，對於通過利用這些社群幫助評估服務實現的業務價值，還需要另外的定義這些價值的方法。與此類似，應該對 SOMA 服務標識機制和服務著色測試 (services litmus test) 進行修改或擴充套件，以標識適合於應用程式整合和適合於支援富 Internet 應用程式的服務之間的區別。

為了讓您瞭解必須如何以不同的方式考慮基於 REST 的服務，讓我們看個例子，即與企業 SOA 服務相比時，可以從哪些不同的角度考慮基於 REST 的服務。首先，公開內部服務可能不是觸及大眾的最好方法，外部服務可能需要代表企業獨特的視角。假定您將企業 SOA 擴充套件到一家全球航運企業的 Web 上。在這種情況下，關於如何構建服務有兩個不同的重點。假定您從業務流程建模著手，將其作為在標識服務時應用 SOMA 方法的一部分。如果像這樣建模企業的流程，則建模的重點（內部重點）就是優化資源來儘可能提高盈利率。也就是說，您在像這樣建模時，可能會問：

• 您的飛機和卡車的滿載率如何？
• 如何最大限度減少燃油成本？
• 將 X 個包裹從 A 點送到 B 點的最便宜方法是什麼？

但從使用網站的人員（或希望在 Mashup 中使用您的網站釋出的基於 REST 的服務的人員）的角度看待企業時，建模工作必須採用不同的焦點。也就是說，以外部客戶為重點時，要問的問題可能就變成了：

• 我的包裹在哪裡，什麼時候將送到？
• 從這裡將包裹送到托萊多將要花多少錢？

假定您最初從第一個角度進行建模，然後想要從第二個角度新增基於 REST 的服務，那麼您要認識到需要進行更多的建模和設計工作。不過這是 SOMA 和 RUP-SOMA 這類方法的好處所在：它們是迭代性的，可以在認識到需求時納入此類變更，而不用像要把圓形的銷子插入方形孔中那樣做無用功。

4. 確定遠景、建立路線圖、執行專案

圖 1 顯示了我們使用過的最有用的關係圖之一，用於說明採用 SOA 需要什麼。這是跨業務和 IT 的 SOA 遠景需求的圖形表示形式。您評估目前的狀況，建立從現狀到遠景的路線圖，並實現以循序漸進的方式執行路線圖的專案。這個方法不僅適用於 SOA 採用，也同樣適用於 Web 2.0 採用。

圖 1. SOA 遠景

有兩點至關重要：1) 確定遠景，2) 執行專案。如果僅僅關注 Web 2.0 的遠景和路線圖（包括實現基礎結構和框架專案），而沒有“真正”的專案（用於生產，產生業務價值），那麼就很可能得到一個不滿足專案需求的基礎結構和過程，使專案團隊更難遵循路線圖/體系結構/框架。如果啟動個體 Web 2.0 專案時沒有遠景和路線圖，也沒有公共基礎結構，那麼就有可能減少所提供的價值，再次面臨之前已有的教訓，不能跨專案重用程式碼，無法構建公共基礎結構和過程（如安全性）。早期專案並不需要為了提供價值而做得太大，但總能夠提供機會幫助獲得新技術和業務模型的使用經驗。

5. 不要忽視治理

我們在幫助客戶採用 SOA 的過程中發現相對較晚的一件事是，非常需要 SOA 治理。IT 治理有時候是個很微妙的問題；有時候這方面更多是提得多做得少。SOA 治理是對 IT 治理進行擴充套件的過程，以處理 SOA 所提供的特定語義和業務元素，是構建 SOA 使其能夠發展、維護和擴充套件的關鍵。另外，SOA 治理應該擴充套件到 IT 治理之外，以將業務負責人包括進來。

我們所看到的是，因為隨著使用 SOA 原則構建的體系結構的發展和成熟，SOA 基礎結構和服務開發及部署流程的管理和控制會變得極為重要。IBM Rational Asset Manager、IBM WebSphere® Service Registry and Repository 和 IBM Tivoli® Policy Manager for SOA Security 之類的工具可用於幫助配備可靠的治理流程。

我們從使用 Web 2.0 原則構建的早期應用程式可以看到，Web 2.0 的治理將更具挑戰性，因為 Web 2.0 採用的關鍵是自由溝通、社群協作和資訊共享。在公開基於 REST 的服務和 Atom 服務時，問題就變成了：如何控制但又不限制使用者對這些服務的使用以及對資產的開發？如果構建社群的社交方面受到太過嚴格的治理過程的限制，則社群將不會繁榮。不過，線上社群受到治理不足或不當的影響的情況我們見得太多了，很容易被埋在“垃圾堆”裡，不能夠將現有的寶貴內容突顯出來。

Web 2.0 的治理可以看作管理公園。作為好的公園管理員，您希望在自己的控制範圍內鼓勵多樣化，但不能超過規定的限度。為了確保基於 REST 的服務的生命長且能帶來利潤，在任何情況下，規劃治理並確保您的基於 REST 的服務通過某種治理流程得到控制都非常重要。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-610848/，如需轉載，請註明出處，否則將追究法律責任。