Eclipse新成員Swordfish詳解
原創【51CTO快譯】Swordfish是什么？
企業服務總線（ESB）一直以來都是每個運營商SOA策略的基石。然而一直以來，由于其過于龐大，架構集中化，而且與已有的應用程序難以結合的關系，ESB一直未能將SOA的價值充分的發揮出來。
Swordfish——新生代ESB
正因如此，Swordfish選擇了一條全新的道路。建立在Apach ServiceMix和Apache CXF等開源組件之上，Swordfish提供了一個可擴展框架。這個框架為應用程序開發者以及系統集成商們提供了自己建立ESB的可能性——而且是量身訂造。而且Swordfish不僅僅是框架：秉持著Eclipse“可擴展框架與exemplary插件相結合”的傳統，Swordfish項目也把目標放在了企業級插件上。這將打造一個對“E”（企業）十分重視的，成熟的開源ESB。為了展示Swordfish相對于其他開源ESB的優勢，我們以下會著重說明那些總結了在真實的企業環境下積累了數年SOA經驗所帶來的功能。
第一個功能可以在運行時（runtime）中將一個服務注冊（Service Registry）與一個動態綁定服務（dynamically bind services）整合到一起。也就是說，與其他ESB所不同，Swordfish執行這個任務將無需一個靜態的關聯，以往這個靜態關聯是用來將使用服務的組件（客戶）與提供服務的組件（供應方）聯系起來的。Swordfish的做法是，一個客戶找到一個供應方靠的是邏輯標識符，這個邏輯標識符又依照一個策略將此服務界面標識為重要。所謂策略就是有關用戶非功能能力及需求的一個描述。有了這兩條信息，加上包括了已有服務供應方的數據庫以及他們各自的策略，服務注冊會選擇一個合適的供應方并計算出一個有效策略，這個策略將掌管以后在客戶和供應方之間的一切通信。這個方法的優勢是明顯的：客戶與供應方被松散的組合在一起，無需改動商業應用程序代碼就可以輕松改動雙方的非功能參數。
另一個Swordfish的顯著特征是它的架構模式——“分布的ESB”（Distributed ESB），或者叫做“聯邦的ESB”（Federated ESB）。這個意思就是說，兩個服務參與者之間的通信無需中心組件，只需建立通信后便可實現。相對于“傳統的”中心輻射型集成架構，這種模式的優勢在于它不會因中心組件過時而形成性能瓶頸，從而整個系統具有更強的伸縮性，用戶在SOA化的過程中實現更多功能的同時無需花費大筆的精力財力在硬件設施上。
另一方面，聯邦ESB的潛在缺陷在于它令系統的管理更加復雜化。不過這個缺陷可以通過一個遠程配置機制來彌補。在Swordfish中，管理員可以方便并高效的配置大數量分布的Swordfish個體，而且監控功能也很完善。監控功能在業務過程管理（BPM）中尤其的重要，因為細致監控事件是一個完整的業務活動監控（BAM）的前提，而BAM一般都基于復雜事件處理（CEP）。
OSGi和JBI全面詳解
Swordfish框架所使用的是現在SOA通用的標準。在底層有OSGi，具體來說就是Equinox，即Eclipse基金會的OSGi。OSGi提供了組件模型，一個模塊部署系統，以及一個clean class加載系統。在上層有JBI標準來實現組件之間的消息抽取（messaging abstraction）以及消息路由（message routing）。一開始的JBI 1.0使用自己的組件模型和部署系統，不過后來轉而使用了OSGi。這也符合JBI 2.0工作組的情況，還有Apache ServiceMix的第4版。Apache ServiceMix這個Apache的JBI容器（JBI container）正是Swordfish中的核心消息路由引擎。而ServiceMix不僅僅提供路由功能，它本身就包含了大量做好了的組件，這些組件可以直接被用于連接業務邏輯（business logic）或用于傳輸通道以及協議。
綜合來說，Swordfish是一個建立在ServiceMix基礎上，并將功能延伸至企業SOA范圍的框架。Swordfish核心使用ServiceMix的公共擴展點（public extension points）在規范化消息路由器（NMR）中與消息流建立聯系。
與NMR內部建立聯系的中心概念就是攔截器（Interceptor）。攔截器是一段代碼，這段代碼在消息經過NMR進行消息交換時將其攔截下來并對這個消息做一番動作。Java界面可以在Swordfish API中起到攔截器的作用，借助一些插件便可讓這個攔截器實現一些特定任務，如消息認證（validation），消息轉換（transformation）等。攔截器對消息交換作用的次序可以通過Swordfish框架核心中一個叫做Planner的組件來計算并定義計劃。具體計劃如何實施可以由用戶來決定，所以API中還有一個叫做PlannerStrategy的界面，此界面可以通過插件來使用。舉例來說，評估一個消息交換中的策略便可以通過這個PlannerStrategy來實現。除了傳統攔截器以外，在特定情況下還可以使用特定的攔截器，比如有一種攔截器可以在服務注冊中觀察一個服務并為相應的交換重建路由。這個攔截器的基本性能（JBI相關）是核心運行中的一部分，不過具體的觀察過程如何實施則靠一個將ServiceResolver界面實施到框架API的插件來完成。所有的公共API都是這樣工作的。
面向應用程序開發者的注冊和版本庫
以上我們簡單介紹了使用服務注冊來解決運行時服務端點的優點。不過，服務注冊還有更好的地方：它提供了一個面向服務架構中全部服務的全面總覽，而且對于服務再利用有很大的用處，而服務再利用則是SOA規范的主要優勢之一。如果服務界面在定義的時候就仔細注意到再利用的方面，那么無論多么復雜的服務，在理論上也無非就是把一堆封閉的盒子排列好，再連接起來的問題而已。
以后，服務注冊還會增添服務版本庫（Service Repository）的功能，此功能可以將所有SOA相關的部件（比如服務界面介紹，策略等）作為SOA工作流中的一部分，安全并有序的保存起來。由此可以實現版本控制，定義認可工作流，分析和報告可行性等。這些功能令企業建立并推廣管理流程（governance process）成為可能，而管理流程則是成功SOA的必要組成部分。
【編輯推薦】
