SOA架构下补偿模型驱动的安全苛求软件开发

1 引言

铁路车站信号计算机联锁系统，是铁路信号的基础设备，同时也是铁路运输领域中重要的控制系统，它是以现代计算机技术、控制技术和通信技术为基础来实

现对车站信号设备的联锁控制。计算机联锁软件成为了计算机联锁系统的核心，因此必须确保它对联锁逻辑的描述和安全控制的实现准确无误。而随着我国高速铁路

的快速发展，对联锁软件在技术和功能上提出了新的要求。传统软件开发方法在灵活性、可维护性、软件安全性以及开发效率上都显露出不足。

计算机联锁是以计算机为主要技术手段实现车站联锁的实时控制系统。其基本任务是对车站值班员的操作命令及现场各种表示信息通过计算机进行逻辑运算，并辅以各种“故障-安全”措施。联锁系统各主要部分的功能和设置地点的划分层次结构，如图1所示。

图1 计算机联锁系统

联锁层是联锁控制系统的核心，联锁机构除了接收来自人机会话层的操作信息外，还接收i/o接口层的反映信号机、动力转辙机和轨道电路状态的信息，即

信号控制命令和道岔控制命令。i/o接口层接收来自联锁层的控制命令，经过信号机控制电路，改变信号显示;接收来自联锁层的道岔控制命令，驱动道岔转换。

室外设备是联锁系统的控制对象，它包括信号机、转辙机和轨道电路。

本文针对安全苛求软件的特点，面向我国高速铁路计算机联锁软件的应用需求，基于目前主流的soa思想的实现规范，即服务组件体系结构sca，提出并实现了一个完整的服务组件开发模型，挣脱web service框架对soa思想的束缚，并能根据服务组件模型生成代码框架。

2 soa和sca

面向服务的体系架构soa(service oriented

architecture)是1996年gartner公司描述实施企业“v英文”时第一次提出来的。w3c将soa定义为：“一套可以被调用的组件，用

户可以发布并发现其接口。”soa是一种软件设计开发思想，它超越并包含所有的具体技术和所有的具体架构。服务组件框架sca(service

component

architecture)的java标准来自ibm。sca是一套面向服务的soa编程模型或者说编程架构，也是一种soa思想的实现方式。sca通过

模块 (composite)

将sca的组件集成在一起的。模型开发应用中，总是期望能提高软件开发效率，增强软件安全性。因此，本文针对联锁软件安全性高的特性，提出一种面向联锁的

soa服务组件开发模型。

3 联锁逻辑服务组件的开发模型

联锁软件主要由两大部分构成，一是联锁功能程序，二是联锁数据。联锁功能程序主要是对联锁数据进行逻辑运算以完成联锁功能;联锁数据主要用于反映监

控车站各个设备的区动采集对象的特征和状态。联锁软件的核心部分是关于基本进路过程的处理，包括进路选排、进路锁闭、进路信号开放、进路信号保持和进路解

锁等过程。由此，基本进路可以看成联锁软件提供的流程服务，对应人机会话层操作员办理进路的业务需求。对于操作人员来说，基本进路处理流程作为一个整体服

务被调用。这个流程服务包括以下几个任务：进路选排、进路锁闭、进路信号开放、进路信号保持和进路解锁，每个任务通过调用相应的服务来完成联锁软件的功

能。在业务流程进路办理的过程中，进路选排服务、进路锁闭服务调用成功，但是进路信号开放服务因为信号灯故障不能开灯，此时对于联锁系统软件的人机会话层

来说，业务流程进路办理调用已经失败。而进路选排服务、进路锁闭服务的调用已经成功完成，相关的驱动采集对象如信号机、道岔和区段等设备状态和特性已经被

这些成功调用的服务修改了。这就有可能导致不可控的命令下发到室外设备，导致安全隐患。因此，在进路办理的执行过程中出现了业务流程服务未成功调用，但却

对设备对象数据产生影响的场景。

基于上述问题，本文的服务模块开发模型定义了一种被称为“补偿”的服务机制来完善服务的模型，以解决业务流程服务的执行原子性和数据一致性的问题。

例如流程服务逐个调用两个服务，如果只有一个基本服务调用成功，可以通过适当的事情来补偿前一个服务调用成功所产生的影响。每个基本服务都有一个相应的补

偿处理服务，用于消除对应基本服务的调用产生的影响。一旦进行补偿，流程服务中已经运行完成的所有服务都会依照特定的逻辑进行补偿。补偿服务机制致力于维

护业务流程的执行原子性，即业务流程的执行结果只能是以下两种情形之一：流程服务执行成功或流程服务执行失败但不产生任何影响。当执行特定的流程服务时，

相关联的用于补偿调用的就是补偿服务。补偿服务仅在流程服务完成时才能够被调用，当流程执行过程中出现故障时，执行预先关联的补偿服务来补偿业务流程服务

的行为。在一个业务流程执行过程中，如果定义了关联的补偿服务，就应该记录业务流程各个服务的执行顺序，注册关联的补偿服务及输入数据到补偿服务处理队

列。如果业务流程正常完成，则不需要任何补偿。因此基于以上补偿机制，完善的服务组件补偿模型应该满足这样的条件：对任意一个业务流程服务，每次调用的结

构要么是成功执行，要么不产生任何影响。即实现了业务流程的执行原子性。基于以上理论，可以得出sca构架下补偿服务处理机制的通用模型如图2所示。

图2 补偿服务处理机制模型

如图2所示，基本服务1和基本服务2属于同一个组合服务，且都成功的完成了调用(第1，2步)。而属于流程服务的基本服务3的调用(第3步)也成功

完成。若此时基本服务4调用(第4步)失败，被业务流程服务关联的补偿服务捕捉到，触发了补偿服务(第5步)。补偿服务开始执行，通过调用后进先出的补偿

服务队列(与业务流程完成的次序相反)，依次调用补偿处理服务(第6-10步)来补偿之前操作产生的影响。

实际的联锁软件应用中，用户的需求经常是比较复杂的。联锁软件服务组件除了调用基本的服务组件之外，也需要调用一些优先级较高的紧急操作服务，而这

些服务组件往往是依赖外部设备驱动采集的状态。因此，在服务模型中引入了两个特殊的端点，一个是“导入”(import)，使得模块中的服务组件可以调用

模块外部的服务。另一个是“导出”(export)，它使得模块外部的应用可以调用模块中的服务组件。导入和导出的引入增加了服务组件的灵活性，使得此模

型的服务调用能够跨越服务模块的限制。

4 模型在计算机联锁软件中的应用

为了验证和测试上述模型的有效性，基于以上服务模块模型，在linux平台上开发了一个计算机联锁软件系统。此联锁逻辑补偿模型可以获得计算机联锁软件系统的服务组件补偿模型如图3所示。

图3 计算机联锁软件系统的补偿模型

联锁软件实时监测人机交互层操作人员的操作命令，调用相应的业务流程服务执行相应的软件功能。在执行流程服务的同时，联锁软件监测是否有来自外部的

高优先级服务调用，以保证紧急情况下联锁软件的安全性需求。在以往的联锁软件进路办理过程中，进路办理的进路选排、进路锁闭、进路信号开放、进路信号关闭

和进路解锁等过程在程序执行时，除了对联锁数据进行逻辑运算，还需要检测各个执行过程是否成功完成。这提高了联锁软件业务流程各个服务模块的耦合度。每个

服务子模块都应包含补偿处理，以消除业务流程执行过程中当前所有已经成功执行的子模块所产生的影响。因此，此服务模型的业务流程子服务模块的补偿处理只关

心当前子模块成功调用产生影响，而不会关联到业务流程执行的上下文环境。因此，本文提出的服务组件开发模型能在相当大的程度上减少软件设计开发的冗余，提

高软件开发的效率，同时这也限制了各个子模块的功能边界，减少了因为模块之间高度耦合而带来的安全性问题。

5 结束语

本文基于soa思想，针对安全苛求软件的特点，设计了在sca标准下一种完整的服务组件开发模型，通过在北京地铁试验线计算机联锁系统的应用验证了

该模型的正确性。由此模型驱动生成服务组件代码框架，不仅提高了软件的安全，还大大提高了软件的开发效率。此服务组件模型的业务流程服务依赖补偿服务，这

种补偿服务机制虽然能提高软件开发效率，但其与业务流程关联度还比较高，提高了服务模块的耦合程度。因此，将来的方向是改进当前补偿服务的执行机制，降低

与具体业务流程之间的耦合程度。