基于SOA的高速鐵路綜合調度系統設計方法研究

蘇雪，奚進

0 前言

高速鐵路綜合調度系統是高速鐵路建設和運營管理的重要組成部分，是高速行車的中樞，需要運輸組織、機車車輛、通信信號等多個成分的協同工作。一個功能完備、性能可靠、可移植性好的調度系統是保障高速鐵路安全、高效運營的基本保障。

傳統的鐵路信息系統通常采用C/S雙層的結構模式。通常是一臺個人計算機做客戶機使用，另外一臺服務器用于存放后臺的數據庫系統。應用程序與客戶端直接相連，中間沒有其它邏輯。程序的業務邏輯則一般存在于前臺的應用程序中，即程序員根據客戶的業務要求定制客戶端程序，這種定制的程序沒有通用性。業務邏輯也可存在于后臺數據庫中，以觸發器的方式實現。這種方式有一個很大的缺點，就是一旦客戶的業務邏輯有所改變,將引起應用程序的修改以及后臺觸發器的修改。所有程序模塊都重新修改、編譯、連接的工作量是相當大的。另外由于這種結構將用戶界面和業務邏輯以及數據源綁定在一起，會消耗客戶機的大量資源，對客戶機來說是一個很大的負擔，無法適應大規模客戶服務應用需求。同時，在傳統的二層客戶機/服務器模式中，由于客戶端與服務器端直接連接，系統的安全性很低。非法用戶可較容易通過客戶端直接進入中心數據庫，造成系統數據的丟失、損壞、修改和泄密,容易引起高速鐵路運行計劃的混亂并危及列車控制系統的安全，同時客戶端與服務器間的大量數據傳送,容易造成業務高峰期網絡流量暴增，形成網絡阻塞。對于系統的可靠性、實時性和安全性均存在著潛在的威脅。

在高速鐵路調度系統的設計中，為了避免上述二次軟件結構模式所面臨的問題，本文提出基于SOA的高速鐵路綜合調度系統設計方法，采用三層或多層客戶/服務器結構模型，以提高系統的易用性、安全性、可靠性和可擴展性。從本質上說，SOA架構將業務應用分解為開放、可重用、松耦合的服務結構，通過服務的編排組合滿足業務的需求，通過服務的重用實現業務的變化[1]。SOA與其他IT架構的最大區別在于它與業務的關聯性，它以服務為基本單元組織IT資源，其中的每一項服務都可以完成實際業務流程中的一項任務。業務人員可以參與服務的創建并且用它們定義新的業務流程。SOA使業務人員和IT人員在創建新業務流程的過程中能夠更有效地協作。

1 面向服務的軟件開發

1.1 SOA概述

面向服務的架構代表了一種將軟件資源作為網絡上的服務的分布式計算方式[2]。面向服務的體系結構是設計和構建松散耦合的軟件解決方案。這個解決方案能夠以程序化的可訪問的軟件服務的形式公開業務功能，以使其它應用程序可以通過已發布的和可發現的接口來使用這些服務。像XML和SOAP這樣的開發標準可以提供不同廠商的解決方案的互操作性。這樣，對交互中某一方的接口改變不會破壞另一方。這兩個核心原則使公司可以實現服務而不需要知道消費這項服務的任何細節，反之亦然。SOA描述了服務提供者、服務請求者、服務代理三種角色，分別承擔了不同的任務；在這三種角色上又有三個操作:發布、查找、綁定。它們之間的關系，如圖1所示:

圖1 SOA架構中的角色

其中:

1）服務提供者，或簡稱為服務。它們一般有定義良好的接口（對內的和對外的），并且接口的定義是平臺和語言中立的。接口的描述信息被發布到服務代理中，這樣就可以被動態發現和調用。

2）服務消費者，或稱為服務請求者，在需要某項服務的時候，先查詢服務代理，得到相關服務的描述信息，然后動態地綁定到相關服務，這樣就可以以一種對服務消費者透明地方式調用服務。

3）服務代理是連接服務消費者和服務提供者的橋梁。服務提供者可以向它注冊服務，服務消費者可以通過它查詢服務描述信息。在服務代理中注冊的服務可以按某種準則分類，方便服務消費者查詢。

服務提供者和服務消費者通過發送消息通信。這種消息不是指令性的，沒有攜帶任何底層通信協議的語義，而僅僅是對服務接口契約的描述。服務通過接口描述了服務的行為、接收的消息和返回的消息。這種描述是平臺中立和語言中立的。這就要求消息的格式必須也是平臺中立的，而且消息格式還要提供無限制的類型定義能力，以滿足平臺中立和語言中立的要求。XML無疑滿足了這種需求。消息通信使用的協議也應該是平臺中立和語言中立的，被Web Services采用作為應用層消息傳輸協議的SOAP協議正是這樣一種協議。滿足上述要求的架構提供了服務選擇的靈活性和應用程序間的無縫集成能力。

1.2 SOA軟件開發過程

由于SOA涉及到業務的諸多方面，因此需要從一開始就對SOA項目進行細心的規劃和設計。需要考慮項目的整個生命周期，從最初的階段到第一個實現，再一直到可能的修訂和重用。

現在讓我們看看SOA生命周期，此部分概略說明了在生命周期的各個階段發生的事項，并詳細介紹了實現生命周期的各個步驟，如圖2中所示:

圖2 SOA生命周期

(1)建模

面向服務的體系結構項目的第一步幾乎和技術沒有任何關系，所有事項都與項目的業務相關。面向服務的方法將業務所執行的活動視為服務，因此第一步是要確定這些業務活動或流程實際是什么。對項目的業務體系結構進行記錄，這些記錄不僅可以用于規劃SOA，還可以用于對實際業務流程進行優化。通過在編寫代碼前模擬或建模業務流程，可以更深入地了解這些流程，從而有利于構建幫助執行這些流程的軟件。建模業務流程的程度將依賴于預期實現的深度。

(2)組裝

對業務流程進行了建模和優化后，開發人員可以開始構建新的服務和/或重用現有的服務，然后對其進行組裝以形成組合應用程序，從而實現這些流程。在“建模”步驟中，已經確定了需要何種類型的服務以及它們將訪問何種類型的數據。已經存在某種形式的實現這些服務或訪問該類數據所需的一些軟件。“組裝”步驟將要找到已經存在的功能，并為其添加服務支持。另外，還涉及到創建提供功能和訪問數據源所需的新服務，以便滿足SOA涉及的業務流程范圍內的需求。

(3)部署

進行了建模和組裝后，要將組成SOA的資產部署到安全的集成環境中。此環境本身提供專門化的服務，用于集成業務中涉及的人員、流程和信息。這種級別的集成可幫助確保將公司的所有主要元素連接到一起協同工作。此外，部署工作還需要滿足業務的性能和可用性需求，并提供足夠的靈活性，以便吸納新服務（并使舊服務退役），而不會對整個系統造成大的影響。

(4)管理

部署后，需要從IT和業務兩個角度對系統進行管理和監視。在“管理”步驟中收集的信息用于幫助實時地了解業務流程，從而能更好地進行業務決策，并將信息反饋回生命周期，以進行持續的流程改進工作。需要處理服務質量、安全、一般系統管理之類的問題。在本步驟中，監視和優化系統，發現和糾正效率低下的情況和存在的問題。由于SOA是一個迭代過程，因此，在此步驟中，不僅要找出技術體系結構中有待改進之處，而且還要找出業務體系結構中有待改進之處。

完成此步驟后就要開始新的“建模”步驟了。在“管理”步驟中收集的數據將用于重復整個SOA生命周期，再次進行整個過程。

SOA是一種集中系統，其中可以包含來自組織的不同部門的服務，甚至還能包含來自組織外的服務。如果沒有恰當的控制，這種系統很容易失控。控制對所有生命周期階段起到鞏固支撐作用，為整個SOA系統提供指導，并有助于了解系統全貌。它提供指導和控制，幫助服務提供者和使用者避免遇到意外情況。

2 面向服務的高速鐵路綜合調度系統設計

2.1 高速鐵路綜合調度系統結構模型

根據高速鐵路綜合調度系統的用戶需求和系統功能需求，高速鐵路綜合調度系統的系統模型[3]，如圖3所示:

圖3 高速鐵路綜合調度系統結構模型

圖3給出了系統組成及各部分的相互關系。首先高速鐵路綜合調度系統以計劃調度和列車調度為核心。計劃調度根據高速鐵路運營管理部門下達的計劃制定列車運行計劃，并將制定的列車運行計劃交到列車調度系統執行。列車調度系統根據列車運行、動車組、信號、電力、線路、災害等情況對運行計劃進行實時調整，并將生成的可執行列車運行調整計劃提供給其它調度子系統，以便各子調度子系統制定各自的調度策略，同時將列車調整計劃送到各車站。各車站信號系統根據列車調整計劃制定信號控制策略。其它調度子系統根據計劃調度和列車調度所制定的列車運行調整計劃指揮、控制列車及相應的現場設備，并將現場設備的工作狀態、控制指令執行情況等反饋給列車調度和計劃調度系統，從而形成一個閉環的實時監控、控制系統。

2.2 面向服務的系統設計

本文以EWA（讀作“Eva”）這個框架中為作為綜合調度系統遷移到面向服務的體系架構的平臺。EWA是IBM開發的SOA框架，配置定義了一個應用程序，描述了該應用程序的組件以及它們調用的順序和方法。以源中立的方式接收輸入并將其傳送到應用程序。因此，對應用程序邏輯來說是透明的。雖然EWA是完全遵循J2EE，但是它可以連接到外部基于DCOM或CORBA組件的系統。

首先對2.1節的系統模型進行簡化:將每個子系統都以一個應用程序表示。簡化的系統結構，如圖4所示:

圖4 簡化綜合調度系統示意圖

這個看似簡單的scheme是EWA架構的一個起點。現在，添加屬于體系結構概念范圍的服務總線（Service Bus）和服務或流管理器來連接服務和提供服務請求的路徑。流管理器處理定義好的執行序列或服務流，它們將按照適當的順序調用所需的服務來產生最后的結果。業務流程執行語言（Business Process Execution Language，BPEL）[4]就是這種將流程定義為一組服務調用的技術的例子。在這里，需要確定如何調用服務，因而將添加應用程序配置。接著，虛擬化輸入和輸出。最后，提供到后端流程的連接，以便使它們可以按“僅此狀態”運行，并且還可以在將來進行遷移。現在，這個高層次的圖至少在結構上是完整的了，如圖5所示:

圖5 基于服務的綜合調度系統示意圖

在最高的層次上，任何健壯的應用程序框架都必須提供這些功能。接下來的工作是構建組件來豐富這個骨架。把現有的應用程序分解成用于框架的組件就夠了，而不必重新開發所有其他已知將要用到的通用用途組件和系統組件。

服務的選取和組合可以根據服務的QoS進行優化調度。可度量的QoS屬性包括諸如響應時間（Response Time）、可靠性（Reliability）、可用性（Availability）等[5]。根據系統運行需求和綜合QoS度量，可以選取優化的服務組合方案，從而保障整個系統在滿足功能需求的同時達到性能優化。

例如，針對供電系統服務，在其WSDL中的tport元素中加入一個tOperationInst屬性，以描述供電服務的responseTime（服務的響應時間）、availability（服務可以被其客戶正確使用的概率）、concurrency（服務支持并發事務的數量）、price（使用該服務的價格）、fine（服務代理、提供商和客戶之間違約而需支付的罰金）、securityLevel（服務的安全等級）等六個QoS屬性。其他的業務子系統，如綜合調度系統在需要使用供電服務時，按照其給出的tport元素描述的具體QoS需求，選擇可以匹配的供電系統為其提供服務。其他子系統在使用供電服務時亦然。這樣使得供電服務實現按需服務，在滿足供電服務功能的同時，最大化供電系統的供電服務提供效率。

2.3 比較和分析

應用傳統的設計方法設計的綜合調度系統可能是由許多不同性質特征的子系統構成（異構性）。由此帶來的系統集成的復雜性。如果n個應用程序系統必須直接互連，那么將會產生n(n-1)個連接或接口。因此，如果另一個應用程序系統A（第n+1個）必須集成進來，將需要產生、文檔化、測試和維護2n個新的接口。雖然在上圖中，5個應用程序組成的集合需要20個直接接口，但是添加第6個應用程序將需要10個新接口，而更糟的是，必須修改每個已有的應用程序中的代碼以包括進新的接口，因而將發生大量的測試費用。

面向服務架構（SOA）是讓高速鐵路綜合調度系統軟件設計更加關注于業務流程而非底層基礎結構，從而獲得競爭優勢的更高級別的應用程序開發架構。SOA對需要使用信息技術解決關鍵業務問題的高速鐵路運營與維護很有價值。采用服務驅動型方法的高速鐵路運營公司體驗著以下業務和IT好處:

2.3.1 面向服務架構的業務好處

效率:將業務流程從"煙囪"狀的、重復的流程向維護成本較低的高度利用、共享服務應用轉變。

響應:迅速適應和傳送關鍵業務服務來滿足市場需求，為客戶、雇員和合作伙伴更高水準的服務。

適應性:更高效地轉入轉出讓整個業務變得復雜性和難度更小，達到節約時間和資金的目的。

3.2.2 面向服務架構的IT好處

復雜性降低:基于標準的兼容性，與點到點的集成相比降低了復雜性。

重用增加:通過重用以前開發和部署的共享服務，實現了更有效的應用程序/項目開發和交付。

遺留集成:用作可重用服務的遺留應用程序降低了維護和集成的成本。

基于SOA的高速鐵路綜合調度系統設計方法提供了層次化的軟件設計架構和個性化的服務組合方法，有效克服了傳統開發方法的不足，對提高系統的可靠性、高效性和可維護性起到了重要作用。

3 結論

本文分析了SOA的基本體系結構及該體系結構的優點，并闡述了應用該軟件結構設計框架設計高速鐵路綜合調度系統的方法。面向服務的綜合調度系統，可以基于現有的系統投資來發展，而不需要徹底重新創建系統。如果組織將開發力量集中在創建服務、利用現有的技術、結合基于組建的方法來開發軟件上可以獲得減少成本、加快開發進度、降低風險和能持續改進的優越性。

[1]Bell.M.SOA Modeling Patterns for Service-Oriented Discovery and Analysis,John Wiley &Sons Inc,2010.

[2]Papazoglou M P,Heuvel W J.Service oriented architectures:Approaches,technologies and research issues.International Journal on Very Large Data Bases,2007,16(3):389-415.

[3]劉志明.高速鐵路綜合調度系統體系結構的研究[J]中國鐵道科學,2004,252:1-5.

[4]Alexandre Alves等，Web Services Business Process Execution Language Version 2.0,http://docs.oasis-open.org/wsbpel/2.0/,2011

[5]侯貴法,王成耀.Web服務QoS組合優化研究[j].微計算機信息.2007,23(2-3):86-88.