水廠基于企業服務總線的應用集成研究

冼 峰，朱海峰

(上海市自來水市北有限公司，上海 200086)

1 引言

隨著現代企業系統信息化應用水平的不斷提高，信息化系統的應用規模已進入多系統、多業務、多層次、大規模的階段。為了進一步提高各個系統的集成性、統一性和可維護性，保障業務開展和系統運維效率，需要對信息系統進行新的總體規劃。通過業界先進成熟的IT技術，以實現內部眾多業務系統之間的數據集成、應用集成、流程集成，實現信息共享與知識管理，使得業務更集約化、扁平化。

本次基于企業服務總線(ESB)的應用集成研究的總體目標是:通過ESB的應用研究，在技術、標準和管理方面，為建設基于SOA的企業架構及進一步推進企業信息化，奠定堅實的基礎。

2 應用集成現狀與問題

2．1 集成現狀

首先分析供水企業管理工作中的地理綜合展示系統與相關業務系統的集成方式。然后分別分析涉及產水［如數據采集與監視控制系統(Supervisory Control And Data Acquisition，SCADA)、水質監測］、供水(如新裝業務、項目工程、GIS管網)、售水服務(如營收、現場維修)各個環節的核心業務流程、信息系統及其集成方式。

總體情況概括如圖1所示。

2．2 存在的問題

經過分析整理，這些應用存在的問題主要有:

(1)各系統/部門之間的數據交換方式包括線上和線下，線下傳遞的圖紙等資料由專人錄入，項目工程的編號依賴人工約束。

(2)系統間是點對點的集成，一般直接通過數據庫，或者XML RPC交換數據。

(3)各個系統有自己獨立的用戶管理體系，而且安全堪憂。

(4)各系統的主數據分散管理，有些系統還存在主數據無管理、錯誤的情況。

(5)包括供水熱線提供的外部主數據沒有得到管理和復用。

圖1 應用集成現狀Fig．1 Status Quo of Application Integration

(6)各種服務接口一般由提供數據的系統廠商作為服務提供者，與作為服務使用者的系統廠商根據兩兩約定后進行設計開發。這樣的服務接口沒有復用，且大多處于無管理的狀態，也沒有安全控制。

3 面向服務的集成架構

3．1 面向服務的體系結構與集成

面向服務的集成(Service Oriented Integration，SOI)是在面向服務的體系結構(Service Oriented Architecture，SOA)下，通過服務的交互來集成企業的各種數據資源，幫助企業將不靈活的舊系統集成起來，把業務數據或業務功能釋放為可重用的服務。

面向服務的集成使得IT機構能夠在已有的應用中提取可重用的服務功能，將傳統的集成對象與開放的、高靈活性的Web服務整合在一起，提供抽象的接口來規定系統如何與其他系統進行通信。系統可以通過這些接口進行交互，而不是使用底層協議和自定義的編程接口。

SOI是對以往企業集成技術的繼承與發展。它基于關注點分離、松散耦合等源自最佳實踐的架構原則，繼承了企業應用集成、消息總線、流程集成、數據集成等優秀技術。結合SOA先進思想的SOI正在成為企業集成的新方向。

SOA是能夠使IT和業務緊密結合的手段和工具，為提升業務靈活性，其主要達成的目標包括五個方面:

(1)可重用:通過服務封裝在應用之間實現可重用，這也是SOA的核心價值體現;

(2)分布式:遠程訪問、集中管理;

(3)開發性:在不同平臺和操作環境下共享;

(4)靈活性:SOA的目標是實現業務的靈活性，應用可以被加入到新的模塊;

(5)松散耦合:服務的實現與使用分離。

3．2 企業服務總線

企業服務總線(Enterprise Service Bus，ESB)的概念是從面向服務的體系結構發展而來的，與以服務為導向的應用架構體系緊密連接在一起，是SOA核心組成部分，是SOA架構中應用整合的骨干。

ESB是預裝的SOA實現，包括了實現SOA目標所必需的基礎功能組件。服務通過ESB進行交互。

ESB是傳統中間件技術與Web Service、XML等技術結合的產物，用于消除眾多平臺及具體應用間的異構性，促進平臺間的互操作，使不同格式數據間實現共享。

通過調查研究，我們選擇Oracle完全基于J2EE技術構建 ESB產品——甲骨文服務總線(Oracle Service Bus，OSB)進行供水企業應用集成的實證研究。

4 基于OSB的應用集成研究

4．1 工廠總體規劃

工廠總體規劃及建議如圖2所示。

圖2 IT總體規劃Fig．2 Blueprint of Enterprise IT

4．2 服務設計開發標準

通過研究實際情況，編寫《XX供水企業基于企業服務總線的應用集成信息化標準》(以下簡稱《標準》)，對Web服務供應方和ESB建立包括互操作性、消息內容規范、消息協議、傳輸協議、服務描述、服務安全等在內的開發標準。

可以據此基于標準的接口定義和一致的實現手段，以面向服務的方式展開企業集成，逐步開發出一套強壯的集成解決方案。

4．3 既有WEB服務問題分析

參照《標準》，分析發現企業中既有服務的合規情況如表1所示。

表1 既有服務合規情況Tab．1 Compliance of Existing Services

具體而言，既有服務存在以下問題:

1)數據格式在服務接口中沒有通過XML Schema(XSD)加以規范

業務數據作為消息交換主體，在服務接口里被模糊地定義為字符串類型，這使得服務接口無法做到自我描述，增加了調試維護及使用驗證等方面的困難;另外，由于缺乏對業務數據的對象類描述，Web服務消息協議SOAP(簡單對象訪問協議)被事實上降格為一種傳輸通道，完全失去了使用SOAP的好處和意義。

2)個別服務實現有SQL注入的安全風險

空間查詢和管網查詢服務在請求消息的主體內直接注入SQL查詢語句，這是上述問題所帶來風險的一個極端化實例。

3)業務數據沒有統一標準

這更多的不是服務設計問題，而是由于企業缺乏統一數據標準，無法對系統開發商提出相應的要求與約束;缺乏數據標準的結果就是同一數據類型在不同Web服務里表現為不同格式，從而造成服務開發與使用環節的浪費。

4)缺乏對命名空間的規范管理

所有既有服務的描述文件(WSDL)都使用臨時的http://tempuri．org/作為目標命名空間;這在服務數量不多的情況下沒什么問題，但隨著服務數量不斷增多，缺乏對命名空間的規范定義和使用會造成潛在的資源名字沖突和管理混亂。

5)缺乏對服務發布地址的規范管理

表2列出了既有服務的發布地址;隨著服務數量的不斷增多，缺乏對服務發布地址的規范定義會造成資源管理混亂。

表2 既有服務發布地址Tab．2 Addresses of Existing Services

4．4 典型集成實例的設計開發

4．4．1 以透傳的方式發布既有服務

“透傳”即透明傳遞，也就是把既有服務接入OSB，然后在不改變服務接口定義的情況下原樣發布出去。

通過OSB透傳發布既有服務非常簡單，分兩個步驟來做，如表3所示。

表3 既有服務發布步驟Tab．3 Steps for Publishing Existing Services

顯然，將既有服務以透傳方式發布在OSB上有以下好處:

1)便于對服務的發布地址進行規范管理

這從所有代理服務的新地址上就可一目了然(如表4)。

表4 規范服務發布地址Tab．4 Addresses of Normative Services

2)便于對服務的使用情況進行集中監控

一旦對既有服務的調用都割接到對透傳代理服務的調用，我們就可以通過OSB管理界面對服務的使用情況進行有效的集中監控。

但是，簡單的透傳代理服務無法解決既有服務的《標準》合規問題，前面第4．3(既有WEB服務問題分析)中列出的1)～4)項問題依然存在。

為此我們繼續研究如何基于OSB重構現有的服務。

4．4．2 為業務數據定義規范的XSD描述

在既有服務的WSDL里被定義為字符串類型的業務數據，其實有著自身的XML結構;所以，第一步要做的就是用XML Schema(XSD)語言對這些既有數據結構進行規范定義。

以遠傳水表服務的MeterHistoryInfo操作為例，給定水表ID和時間范圍，它會返回水表在這個時間段內的讀數信息(如圖3、圖4)。

＜MeterHistoryInfoResult＞元素在 WSDL里被定義為模糊的String類型，但它其實也是一個XML結構，我們用XSD對其的定義如圖5所示。

圖3 SOAP請求消息Fig．3 SOAP Request Message

圖4 SOAP響應消息Fig．4 SOAP Response Message

圖5 XSD定義Fig．5 XML Schema Definition

從上面的業務數據結構可以看出幾個問題(其他既有服務都存在同樣問題):

(1)元素和元素屬性命名非常隨意，在英文大小寫和縮寫的使用上完全沒有規范可循;

(2)不少元素屬性的命名采用了讓人無法直觀理解的縮寫，不利于服務維護與使用。

為此，我們為每個服務定義了全新的采用一致命名規范的業務數據格式。還是以上面的XML結構為例，新的XSD描述如圖6所示。

基于新XSD的XML結構與既有結構的格式對照如圖7所示。

4．4．3 為代理服務定義新的WSDL描述

對既有服務的重構體現在代理服務擁有不同于(優于)既有服務的WSDL描述，這些不同包括:

1)新WSDL對消息格式的定義基于新的業務數據XSD

這樣的WSDL在語義上實現了自我描述，容易理解和使用，也便于支持將來的業務數據標準化(如圖8)。

2)新WSDL及其引用的新XSD都采用了規范的命名空間

(1)新代理服務的命名空間都以http://shanghaiwater．com/wsdl開頭;

圖6 規范的XSD定義Fig．6 Normative XML Schema Definition

圖7 格式對比Fig．7 Schema Comparison

圖8 WSDL定義Fig．8 WSDL Definition

(2)新業務數據的命名空間都以http://shanghaiwater．com/xsd 開頭。

3)新WSDL對服務操作的命名進行了規范

操作名的修改使得語義上更準確直觀，英文大小寫和縮寫也得到規范，例如:

MeterGISInfo→getMeterInfo;

MeterHistoryInfo → getMeterMeasurement。

4．5 設計并實現代理服務的消息流

對既有服務重構的核心在于設計并實現代理服務的消息流業務邏輯。該消息流把服務請求方發來的符合新WSDL定義的SOAP請求消息，轉換成符合既有服務WSDL定義的SOAP請求消息發送給對應的業務服務，再把業務服務返回的符合既有服務WSDL定義的SOAP響應消息，轉換成符合新WSDL定義的SOAP響應消息返回給服務請求方(如圖9)。

由于響應消息的轉換比請求消息的轉換來得復雜，所以我們以前者為例做進一步的說明;響應消息的轉換涉及多個步驟，其中最關鍵的有兩個:

1)提取既有服務響應消息里的結果字符串并轉換為XML對象

如前所述，既有服務的WSDL把響應消息里代表結果的XML結構都籠統地定義為字符串;我們要做的就是把這個字符串從響應消息里提取出來，然后轉換成OSB所需要的XML對象以便后續處理。我們為此寫了一個Java調用函數XmlObject StringResultParser．parse(String)(如圖 10)。

圖9 重構后的信息流Fig．9 Reconfigured Information Flows

圖10 Java調用代碼Fig．10 Java Callout

2)把上一步得到的XML對象轉換為新的SOAP響應消息

為完成這個轉換，我們須在代表既有服務響應結果的XSD類型(比如MeasurementResultType)和代表代理服務響應結果的 XML元素(比如MeasurementResponse)之間定義 XQuery變換(如圖11)。

OSB開發工具會自動生成XQuery變換代碼，涉及既有服務XSD命名空間的個別地方需要手工調整，最終代碼看起來如圖12所示。

4．6 為代理服務增加安全性配置

我們可以根據《標準》對服務安全性的要求，增加代理服務對請求方的身份認證。下以HTTP Basic Authentication(基本身份驗證)為例，加以說明:

圖11 定義XQuery變換Fig．11 Defining XQuery Transformation

圖12 XQuery變換代碼Fig．12 XQuery Transformation Code

(1)在OSB管理應用里創建用戶賬號和口令(如圖13);

(2)在代理服務的傳輸配置里增加身份驗證選項(如圖14)。

增加上述配置后，調用代理服務必須提供正確的用戶名和口令，否則就會因HTTP 401錯誤而無法訪問服務(如圖15、圖16)。

4．7 結果對比分析

使用OSB實現對既有服務的透傳發布非常容易，只需進行簡單配置，無需定義新的XSD或WSDL等XML描述文件，更不需編程，但獲得的好處有限。

如果嚴格依照《標準》在OSB上實現對既有服務的重構，就必須對既有服務的消息格式進行分析，重新定義代理服務的XSD和WSDL描述文件，設計不同XML格式之間的XQuery變換，甚至要通過Java編程處理更復雜的業務邏輯——這對OSB集成開發員的能力提出了一定要求，但服務重構產生的合規Web服務對企業今后推進面向服務的集成有巨大好處，對企業數據標準化也有明顯促進作用。

圖13 OSB創建用戶界面Fig．13 Creating a User in OSB

圖14 代理服務配置界面Fig．14 Configuring Proxy Service

圖15 調用代理服務Fig．15 Invoking Proxy Service

圖16 調用代理服務結果Fig．16 Response from Proxy Service

5 總結

本次研究充分借鑒國內外公共服務行業SOA建設經驗、融合業界先進技術標準進行自主研發、建設，在一定程度上具有領先性，主要體現在架構先進、技術領先方面。

研究的目標是研究出適合企業適用的技術標準、管理規范，選用統一的架構體系和技術構建開放的、集成的、一體化的信息化應用環境，在此基礎上構建以服務為導向的、一體化的、高效的企業業務應用，便于將來在既有應用信息資源的基礎上分階段實施新的信息系統規劃。

為了在本次研究的成果之上繼續深入推進基于服務總線的企業應用集成，企業考慮從以下幾個方面著手布局:

(1)數據標準——成立專門的企業數據標準管理委員會，負責制定、維護和推廣企業主數據與業務數據標準。該委員會要對企業數據標準的分類、描述語言、變更(版本)管理、保存與發布、使用合規管理等方面做出明確規定，并提供相應的文檔與流程管理工具。基于上述規定，委員會要通過實施專項來定義和維護企業的數據標準;

(2)主數據服務——遵照《標準》(本研究項目的成果)和企業主數據標準，開發企業的主數據服務并在ESB上部署;

(3)業務服務——針對常用的業務功能或業務流程，設計開發可共享的企業級業務服務并在ESB上部署;

(4)人才培養——除非準備完全依靠外部供應商來實施上述任務，企業IT部門應該加強對內部人才的培養和鍛煉，特別是與企業應用集成相關的分析、設計與開發能力。這包括(但不限于):常用的企業集成設計模式與技術、與XML相關的技術標準與 工 具 (XML，XML Namespace，XML Schema，XSLT)、ESB產品的配置與開發工具、常用的Java集成開發環境(Eclipse)等。在項目實施過程中，通過員工管理制度和項目管理安排使內部IT人才和外部供應商團隊融為一體，是快速提高他們工作和學習能力的一個捷徑。