作者 Boris Lublinsky 譯者 陳義 發佈於 2009年11月30日 上午12時32分
Jeff Davis的新書《Open Source SOA》在選擇和使用開源產品實施SOA方面爲我們提供了大量有價值的信息。
在他的這本新書《Open Source SOA
》
中，Jeff
Davis討論了使用開源產品構建SOA解決方案的優勢。書的開篇首先討論了SOA的主要原理和完整的實施架構，接着介紹了架構中每層選擇開源產品的標
準，然後詳細介紹了每種產品，論述了它們的工作原理和如何在SOA實施中使用以及與其它開源產品進行整合。
Manning爲Infoq讀者提供了該書的第二章節選 ，本章介紹了SOA實施如何選擇開源產品。該書爲我們提供了現有開源SOA產品的功能介紹和最佳實踐的寶貴信息。該書和其Manning網站 都提供了對應的代碼實例，使得該書更適合於開發者。
InfoQ有幸採訪了Jeff。
InfoQ ：在您的這本書中，您將SOA定義爲“可用於構建新業務流程或者應用的離散的、可複用的業務服務”的集合，而另一方面，您將SOA比喻爲不同的分佈式計算方法。多大程度上您將SOA看作是一種技術——分佈式系統，還是業務問題？您如何區分服務、業務流程和應用呢？
Jeff ：這是個很好的問題！首先，我認爲SOA是一種架構，它爲如何研發軟件解決方案提供了藍圖。在某種意義上，SOA是一種由業 務需求驅動的技術挑戰，現在的業務需要應用間具備更多的靈活性，並易於整合和共享，同時更敏捷地響應市場變化。如果採用了SOA方法論，那麼應用在本質上 會更加淡化整體性，而更類似於混搭（mashups）。爲什麼呢？因爲應用可能由多種服務組成，這些服務可以由許多各異的應用/客戶端組成。
我將業務流程看作是多個服務間的服務編排，這些服務可能包含或不包含人工元素（比如任務需要人類介入），在SOA中，服務就是積木構件，在書寫應用和流程時可以利用這些服務。
InfoQ ：有一本書討論了Web服務和REST之間的論戰。您認爲Web服務與REST會和平共存嗎？它們在哪些特定領域更有各自的優勢呢？
Jeff ：SOAP的主要優勢是WSDL。它規範瞭如何調用一個特定的服務。.NET和Jave平臺都提供了將WSDL生成服務接口 的工具。我個人認爲這就是 SOAP的最大價值。當然，這也增加了SOAP的複雜性，在試着理解WSDL的時侯，很多人都感到害怕。目前，REST世界有一個類似WSDL的產物（但 是沒有公認的命名）。比如，Web應用描述語言(Web Application Description Language)或WADL。它與WSDL的功能相似。在SOAP中WS-Security越來越被廣泛採用，但REST世界中的應用公共安全模式和 SOAP中不一樣。我認爲REST將會不斷繁榮壯大，而在企業應用中，SOAP將更普遍。
InfoQ ：您在這本書裏將服務接口和服務契約等同起來，並建議二者都使用WSDL。您認爲WSDL對服務的定義夠用嗎？您如何定義服務的QOS、服務/信息語義呢？
Jeff ：是的，WSDL定義了參數，操作，內容需求，以及基於SOAP的Web服務的端點。很明顯，作爲服務的消費者與服務進行交 互時，這點是非常重要的。顯然，WSDL並不關注服務的真正實現，它只表示註冊的服務哪些是可用的。（除非你在一個大的WSDL中定義所有的事情，很多人 都這麼做）。在下一個章節中我將介紹如何使用WSO2的註冊產品實現服務註冊（我的bloghttp://jdavis.open-soa.info/wordpress/ 上將會發表這個章節的內容）。 QoS相關的語義可以通過WS-Policy擴展。例如，可以使用Apache Synapse定義策略，策略中定義客戶端可以訪問服務的次數以及管理服務的優先級。
InfoQ ：當我們談論到SOA的核心特徵時，會提到服務的無狀態性。在您的書中，您也談到了SCA的（有狀態）交互。那麼SOA和SCA是如何共存呢？
Jeff ：我認爲在理想的狀態裏所有的服務本應該都是完全無狀態的，就如同我們每年都期望Packers應該贏得超級盃（Super Bowl）一樣。不幸地是，這種假設不一定是可行或者現實的。一些複雜的服務需要和客戶端進行更多的交互。我認爲應該儘可能地避免這種情況，但是有時候很 難做到這點。我認爲SCA對交互的支持是非常靈活的，但是從一個實現的視角來看需要一些時間去領會和理解（希望我的這本書提供了這方面的幫助）。
InfoQ ：在您的書中有一個描述SOA層的圖表，但您沒有具體討論在實施每個SOA層時該使用哪些產品或者方法。您認爲需要特別地介紹SOA嗎？關於實施SOA您有哪些建議呢？
Jeff ：我並沒有深入介紹這些內容，因爲可供選擇的產品實在是太多了。然而，很多流行的GUI框架，比如， Flex、Tibco GI、GWT (尤其是SmartGWT)、Ruby on Rails，都爲Web服務交互提供了強有力的支持，無論這些Web服務是基於REST還是原生的SOAP。我認爲客戶端層應該簡化訪問和消費SOA環境 中暴露的各種服務，但事實上，Web應用更多地用於管理頁面流、安全以及其他內容，然而，對它所擁有的可用服務而言，它就是客戶端。
InfoQ ：您爲我們提供了一張評估開源產品標準的表格，但該表格並沒有將“堅持標準”作爲評估標準之一。您認爲在選擇開源產品時對 評估其對標準的支持有多重要呢？同樣，其他的開源產品，比如JBoss和Mule，都爲他們的產品提供了支持服務。那麼對於產品，能夠購買產品支持服務， 在你看來又有多重要呢？
Jeff ：很不錯的觀點。我確實省略了這點。堅持標準是非常重要的，當涉及到如何暴露服務時尤其重要。在SOAP中，我認爲SOAP 服務框架創建服務時都遵循WS- I標準非常重要，比如，該標準使得.NET和Java客戶端可以平穩地相互通信。同樣，當你開發BPEL腳本時，對你而言，能將這些腳本從一個框架或者應 用移植到另一個框架中並且無需全部丟棄私有擴展可能非常重要。然而，Mule並不是一個遵循JBI規範的容器，這有什麼問題嗎？在你想將適配器從一個 ESB遷移到另一個時可能是，但通常情況是你選擇了一款產品並打算使用一段時間（Mule支持許多標準，比如JSON，RSS，SOAP，REST等）， 這些因素可能就不是最主要的（與實現、可擴展性相比）了。
至於是否能夠購買支持，我認爲這爲客戶提供了不錯的定心丸，還可以保證開源產品的長期生命力。如果你仔細觀察，可以發現絕大多數成功的開源項目都有 贊助公司，它們以某種方式從開源項目獲取利潤，比如產品支持或者諮詢實施。我確實對這樣一種模式避而不談，即開源產品提供的原型在某些方面存在着功能限 制，所以不得不購買商業版本來滿足我們的需要。比如，與Mule或者Active Endpoints相比，我更喜歡JBoss和WSO2的模式。我認爲即使有贊助公司在背後支持開源項目，開源社區反饋也是非常重要的，因爲這樣可以幫助 提升產品的功能併爲它的長期發展做出一些貢獻。
InfoQ ：當談到服務註冊時，您經常提到註冊(registry )和存儲庫(repository )。您認爲它們是同一個概念嗎？書中關於註冊的討論更多的是圍繞支持設計時製品，同時註冊產品的選擇包含了多種LDAP實現，它們爲支持運行時（身份）信 息提供了優化。您認爲註冊的運行期使用也和設計時一樣嗎？
Jeff ：我認爲服務的動態發現是一種舊概念，它最初由UDDI所支持，相當天真，這也是爲什麼沒有人真正這麼做的原因。我認爲服務 註冊的主要焦點是WSO2和 Mule如何提升服務註冊，它更像是一個協作和支持工具。我認爲通過WSDL或者WADL這些技術規範，服務可以充分地實現自我描述。
InfoQ ：在您的評估表中，您將ESB從服務組件框架中分離出來，並建議使用Apache Tuscany和Apache Synapse。您認爲它們二者是成功實施SOA中必不可少的嗎？
Jeff ：我認爲ESB最適合作爲各種協議間的中間件（或者中介），它也是管理安全和策略實施的不二選擇。我認爲ESB不適合用於構 建可複用的組件和服務，而像 Tuscany或者OSGi框架更適合做這些。ESB顯著的特點是可以通過其他的協議將現有的遺留服務包裝成服務，而不需從零開始實現這些服務。如此看 來，ESB擅長於將舊應用服務化。最初對ESB的一些混淆是將它們作爲SOA的“瑞士軍刀”，而忽視瞭如何構建服務和組件。
本書的一個焦點是如何整合像Synapse、Tuscany、jBPM、Drools和Esper這些技術，讓它們與SOA的規則保持一致，利用它們各自的功能。
InfoQ ：雖然您提及到了SCA工具——一個Eclipse插件，但在書中您並沒有談到如何使用它。您認爲這個工具將會被廣泛使用還是仍處於試驗階段？
Jeff ：我確實用過SCA的Eclipse插件工具，它一直在發展。它的一些特徵比如SCA圖，有時候看起來很漂亮，只是用於構建 配置文件時有些不太好用，這只是我的個人觀點。我可能有點守舊，但我更想知道它的底層實現。相比之下，從開發的角度而言，我認爲jBPM插件的圖表特徵非 常有用。我確信SCA的可視化工具會不斷地發展和改進。
InfoQ ：書中對SDO的描述，SDO的優勢並不能立即顯現。如果說WSDL常用於服務設計的話，那麼SDO提供的多種“規格化”XML解析有什麼優勢呢？
Jeff ：你確實深入地看了我的這本書！根據我的經驗，我更傾向於將SDO作爲另外一種 XML/Java的綁定技術，不像JAXB、Caster或者Axiom。因爲它與SCA緊密地集成在一起，這是很正常的。實際上，如果你是採用自頂向下 的方式開發服務，也就是先設計WSDL，然後可以使用SDO的WSDL-to-Java 工具創建Java綁定類（我認爲自頂向下的方式是一種基本的構建一致性和設計良好服務的方法）。我使用這種方式處理過相當複雜的WSDL，並得到了理想的 效果。當然，SDO也提供了對非連接的變化集的支持，可以將離線狀態下發生的變化和原始的進行比較，事實上，與變化日誌有點相似。事實上，這種用法還不多 見，但它確實很有趣。
InfoQ ：書中對BPM的討論並沒有專門討論流程建模。您認爲流程建模是成功實施BPM中必需的嗎？您能建議一些適合jBPM的開源BPM建模工具嗎？
Jeff ：我認爲使用流程建模工具或許存在一些優點，尤其是在構建非常複雜的模型時。然而，經常不會這樣，這也不是慣例。顯然，在 BPEL中有一些產品，它們使用 BPMN符號建模，致力於促進業務分析師和專家開發流程。會生成一些代碼，並將BPEL作爲輸出（Intalio就是使用這種方法）。然而，在實際運用 中，它是非常複雜的，因爲BPMN支持的符號比BPEL支持的更豐富，因此一個複雜的轉換層就出現了。由於BPEL的代碼是生成的，不應該被修改或者逆向 工程的解決方案也不支持。根據我的經驗，這種類型的解決方案經常有問題。
也就是說，通過使用Eclise插件構建模型的jBPM圖的設計目的就是向建模人員屏蔽底層實現。換句話說，即使是非開發人員也可以像使用 Visio一樣構建工作流，而開發人員可以插入具體的實現細節。不同的是，像Active Endpoints BPEL 設計器之類的產品都假設建模人員都熟悉BPEL的相關術語，這些術語對於沒有接受過這方面培訓的人來說是一種挑戰。本書中，我使用jBPM演示了一些相當 複雜的模型，並描述了SCA是如何和jBPM相互協作工作的。
InfoQ ：這本書介紹了許多關於使用事件流流程實施BAM解決方案的有趣細節。那麼您想使用事件流流程來啓動業務流程或者服務嗎？
Jeff ：當然！我認爲CEP應該編織到你所設計的服務和流程中。如果適當地使用CEP預先構建服務，那麼會相當簡單。即使你最初不 想處理太多的事件，也可以通過添加一些過濾規則和模式來靈活處理。它和縱橫交錯的事情相似，比如預先構建的日誌，你更樂於以後再做。通過這種方法可以很容 易地追蹤服務調用的頻率和監控錯誤。這本書中有一些關於如何使用jBPM發送事件到Esper的實例，書中提到的Esper是一個開源的CEP產品。
InfoQ ：這本書大篇幅地介紹了Drools的用法，但是規則、服務以及業務流程之間的關係仍然不是非常清晰。您可以詳細描述它們之間的關係嗎？
Jeff ：我認爲規則是如何將服務組合成複合應用或者流程的粘合劑。在這方面，我認爲規則引擎對SOA而言非常重要，這就是爲什麼我 要這本書中詳細討論這個主題的原因。例如，在業務流程中的工作流通常是由決策驅動的。例如，如果你有一個訂單流程工作流，本質上說，和審批相關的決策無疑 就是業務規則。因此，業務規則對於業務流程非常關鍵。這本書中我們討論了Drools RuleFlow，它描述了在Drool的上下文中如何創建業務流程。
一直以來阻礙業務規則在企業中被廣泛應用的問題是如何在應用中整合業務規則引擎。即使在應用中已經嵌入了規則引擎，你未必就取得了多大的進展，因爲 你的規則仍然深埋在應用之內。反之，如果你將這些規則從應用中抽取出來，作爲單獨的決策服務，它們更具備可見性。而且，通過一個業務規則管理庫，比如 Drools Guvnor（本書中已描述的）提供的功能，更易於集中維護這些規則。當你從應用中提取這些規則並將它們放到可供業務人員訪問的中心庫時，你可以真正地將 這些業務規則當作是可管理、可監控以及易於變更的真實資產。
InfoQ ：ESB的一個賣點是安全的透明實現。您在書中描述Synapse時，討論了安全的某些方面，包括WS-Security 的實現。但有一個方面您沒有談到，也就是當在屬於不同安全域（比如WS-Trust或者OpenID）的服務間路由請求消息時，證書轉換的身份管理如何處 理。在這方面，您對安全產品有哪些建議嗎？
Jeff ：對。在這本書中，我並沒有介紹身份管理，它是一個廣泛的主題。顯然，近幾年來這個領域中出現了一些標準，比如，SAML。 然而，我認爲由於它的複雜性，它還沒有被大型企業所廣泛採用。另一方面，OpenID取得了極大的成功，但是它更專注於Web應用，而不是Web服務。到 目前爲止，除了支持OpenID 的WSO2認證產品外，還沒有出現一些令人滿意的開源安全產品，對於對這一領域感興趣的人而言，WSO2的認證產品是非常值得關注的。
InfoQ ：您可以爲開始使用開源產品實施SOA的人們提供一些建議嗎？
Jeff ：哈哈。推薦購買我的這本新書！坦率地說，令人值得慶幸的是，目前有大量的、可供選擇的開源產品協助我們實施SOA。顯然， 在我的這本書中，我只介紹了諸如 ESB、CEP、BPM、服務/組件框架和業務規則這些產品的一種開源產品，而除此之外，還有許多同樣出色的開源產品。我認爲在選擇開源產品時，最重要的 是評估該開源產品社區的活躍度，以及其背後的贊助商的大力支持。正如我經常所說，商業產品更加具有風險性，尤其是在當前的環境下，因爲許多公司突然倒閉或 者被收購，用戶又使用了他們的產品，這些產品很可能只擁有少量的客戶羣。另外，像我在本書中提及的主流開源產品擁有廣大的用戶，源碼免費公開，並且有許多 非常熟悉這些源碼的開發人員。所以說商業產品更具有風險！
Jeff ：非常感謝你提出的問題，這些問題都很精彩！
InfoQ的讀者在Manning.com 上購買這本書時，可以使用 'infoq35' 打折。
查看英文原文： Book Excerpt and Interview: Open Source SOA 。
譯者簡介： 陳義，計算機應用技術專業碩士研究生，一直專注於SOA、BPM、ESB、EAI和MOM的研究及應用。熱衷於開源SOA 項目，有志致力於 Mule、ServiceMix、ODE、ActiveBPEL、ActiveMQ、OpenJMS、Camel、CXF、XFire以及Tuscany 在中文社區的研究和推廣工作。您可以通過honnom (at) 163.com聯繫到他。
原文發表在infoq中文站 。