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