苏雪，奚进

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.