基于CCM构建SOC分布式系统

基于CCM构建SOC分布式系统      胡绪同 

摘要：

SOC 已成为安全管理方式的主流解决方案，随着 SOC 的不断应用， SOC 产品本身各组件的即插即用，以及和已有的资产之间实现互联互通等问题变得越来越重要，分布式构件技术是解决这些问题的主要办法。

目前，主要的分布式构件技术有 Microsoft 公司的 COM + (Component Object Model) ， SUN 公司的 EJB ( Enterprise Java Bean) ， OMG 组织的 CCM(CORBA Component Model) 。在它们中间只有 OMG 的 CCM 技术具有既不局限于特定系统平台，也不局限于特定开发语言的优点。

基于 CORBA 的 CCM 模型构建 SOC 分布式系统主要要做到以下两点：①利用 CORBA 提供的分布式服务的机制，为各组件之间建立稳定、高效、安全的通信信道；②利用 CORBA 的调度机制和异步消息等机制实现各组件之间的异步、同步功能。

对系统的优化主要集中在提高系统的容错性和负载平衡能力等方面。

关键 词： CORBA;CCM;SOC; 分布式系统

Keyword: CORBA; CCM ;SOC; Distributed System

 

前言

SOC （ Security Operations Center ）－安全运营中心，是为了解决传统安全管理领域的协调性差等问题而提出的解决方案。广义上说，所有与安全防护有关的设施部署都包括在 SOC 系统之内，例如：防火墙，入侵检测系统，专家系统，安全代理，管控器，安全审计，安全通讯，漏洞检测等，但其核心产品是安全管理与控制平台。

SOC 将不同位置、不同安全系统中分散且海量的单一安全事件进行汇总、过滤、收集和关联分析，得出全局角度的安全风险事件，并形成统一的安全决策对安全事件进行响应和处理。

目前，永达 SOC 的通讯方式采用的是公司内部的协议，与其他的软、硬件通讯存在一定的困难；而且产品只能以全套部署，无法实现各部件的即插即用，无法保护客户以前的投资影响市场的拓展。分布式构件技术是解决这些问题的主要办法。

与其他分布式构件技术相比， OMG 的 CCM 技术具有既不局限于特定系统平台，也不局限于特定开发语言的优点。

基于 CORBA 的 CCM 模型构建 SOC 分布式系统主要要做到以下两点：①利用 CORBA 提供的分布式服务的机制，为各组件之间建立稳定、高效、安全的通信信道；②利用 CORBA 的调度机制和异步消息等机制实现各组件之间的异步、同步功能。

对系统的优化主要集中在提高系统的容错性和负载平衡能力等方面。

 

一． CORBA － CCM(corba component model)

1 ． CCM 模型产生背景

CORBA ( The Common Object Request Broker Architecture : 通用对象请求代理结构 ), 是对象管理集团（ OMG ）为适应当前激增的软硬件之间的互操作而在 80 年代末提出的一种规范。

为了克服 CORBA 规范中的不足， OMG 提出了 CCM 的概念。 CCM 构 件在 CCM 构件应用系统中是最小的系统组成单位。 CCM 的一个最重要的贡献是 CCM 模型标准化了采用 CORBA 为中间件的基础系统框架的构件开发的标准。

2 ． CCM 抽象模型

CCM 规 范 中的抽象模型为构件的开发者提供了描述构件接口和特性的方法。它扩展了接口描述语言 IDL ，并形成了构件实现描述语言 CIDL (Component Implementation Definition Language) 。对构件的属性、构件间的依赖关系和构件的生命周期管理做了详细的约定，包括构构件的端口 (ports) 机制和事件服务等内容．

端口机制主要描述客户端进程和服务器端构件之间调用和被调用的方法以及构件和其他构件或对象、接口的依赖关系．一个构件可以向用户提供多个接口，客户端可以通过其中的任意—种类型的接口来访问构件；构件和对象之间既可以通过插座 (Receptacles) 进行同步通讯，也可以通过事件源 (Event Source) 和事件池 (Event Sink) 进行异步通讯．

CCM 规范定义了组件接口 (Component interface) 、刻面 (Facet) 、插

座 (Receptacles) 和事件源／事件池 (Event Source/Sinks) 四种类型的端口和

属性 (Attributes). 一个构件可以提供多个端口，每个端口提供构件和其他对

象相联系的特殊视图。 CCM 构件抽象模型如图 1 ．

图 1.CCM 构件模型

•  组件接口

组件接口是一个有别于其它接口 (Facet) 的接口，这个接口与构件的定义相—致，组件接口向客户端程序表明此构件的外部特性即构件的引用．通过组件接口客户端程序可以定位任何一个构件的刻面，并可连接到这些构件的接口．

•  刻面 (Facet)

刻面是构件为客户端提供的接口，这些接口不一定与被继承的所支持的接口有联系。刻面允许构件通过提供不同的接口为客户端提供不同的视图，这些接口可同步地通过 CORBA 的双向操作所谓用，也可以通过 CORBA 的异步方法调用 (asynchronous method invocations ， AMl) 进行调用．在 CORBA 构件模型中，客户端是通过构件的组件接口 (Equivalent Interface) 对构件进行访问的．组件接口唯一标识一个构件。客户端只要获得构件的组件接口，就能访问该构件提供的所有 Facet ，并可以得到该构件提供的所有 Facet 的描述．用户也可以由构件的一个 Facet 跳转到另一个 Facet ．这些 Facet 的具体实现对客户端来说都是透明的，客户端只需要知道如何访问 Facet 就可以了。图 2 显示了 Facet 在构件中的位置和作用．

图 2.CCM 构件的组件接口和刻面

CCM 模型中的刻面与构件的关系有如下特点：

·刻面接口的实现被封装在构件内部，是构件的组成部分．构件内部结构对客户来说是透明的。

·客户端程序可以通过定位接口 <navigation interface) 从任何一个刻面定位 (Navigate) 到构件的组件接口 (equivalent interface) ，也可以从组件接口定位任何一个刻面。

·客户端程序可以判断任何两个引用是否属于同一构件实例．

·刻面的生俞周期绑定于它所包含的构件。

构件上的每一个刻面都可支持不同的接口类型，对应着构件完成的不同功能，因此就可将构件与多个接口联系起来了．刻面的引入，使客户端可以通过多个不同类型的对象引用访问构件。在不同刻面之间以及刻面和构件之间可以任意游离．正传统的 CORBA 对象模型中，通过继承来对 CORBA 对象进行扩展比较困难，主要是由于无法将多个接口和一个实现的实体关联起来． CCM 引入“刻面 --Facets ”的概念解决／这个问题．刻面是 CCM 构件提供的外部可用接口，和构件的其它支持刻面没有必然的继承关系。

 

•  插座

插座定义的是构件与其它构件或对象之间的依赖关系，描述了构件被实例化叫所依赖的其它构件或对象的接口．如果一个构件要完成某个需要其它构件 ( 对象 ) 才能完成的功能时，那么这个构件就必须先获取它所需用到的构件 ( 对象 ) 的实例的引用．在 CCM 规范中，把这种引用和对象之间的连接称为是对象连接 (Object-Connection), 把这种用于获取这些实例引用的端口叫做插座 (Receptacles) 。插座机制提供了构件与构件、构件与对象间相互协作完成其功能的一种标准途径。通过这个机制，构件可以连接其它构件 ( 对象 ) ，并可同步或异步 (AMI) 地调用它们的功能．而构件的开发者需要说明构件是否愿意与其它的构件相连接。这里说的对象指的是其他的构件或接口。构件开发者可以通过这个特性描述构件和与之关联的对象间的关系。

此外，插座可以是多重插座，即多个对象可以在同—个插座进行多重绑定。图 3 表示出了插座与其它构件或对象的关系。

图 3. 插座与对象 / 构件的关系

•  事件源／事件池 (Evcn[Sources ／ Sinks)

事件源／事件池提供构件通过监测 (monitoring) 异步的事件发生来进行交互的机制。这种基于观测模式的松懈连接常用于分布式应用系统中。一个构件在它的定义中通过定义事件源和事件池来发布 (publish) ／预定 (subscribe) 构件感兴趣的事件．事件源／事件池是构件行为相互触发的一种机制．当一个构件的某一状态发生变化时，可能触发另一构件的某个动作．状态发生变化的构件称为事件源，被触发的构件称为事件池．在 CCM 中定义的事件机制只有推模式 (PushModel) ．构件源持有事件消费者的对象引用，通过调用事件消费者中的各种推的操作，将事件土动地推给所有的事件消费者。图 4 显示了 CCM 中的事件发送过程：

图 4CCM 模型中事件发送过程

在 CCM 规范中，有两种类型的事件源： emitters 和 publishers ．两者都需要通过容器所提供的事件通道来发送事件，一个 emitter 只可以连接一个由容器提供的代理：而一个 publisher 可通过事件通道连接任意数量的事件消费者．

Publisher 类型的事件源有如下特点：

·允许多个事件的订阅者 (subscribers) ／消费者 (consumers) 同时连接到

一十 Publisher 类型的事件源。

·事件订阅者通过由窖器在运行时提供事件通道连接一个 publisher 类型的事件源，日构件只允许一个 publish*r 使用这个事件通道．

Emitter 类型的事件源的特点是：

emitter 事件源同一时刻只允许一个事件消费者进行连接。

允许多个 emitter 事件在同一个事件通道中发生。事件从 emitter 事件源发出后，再由容器将事件作为 connect_<source> 操作的参数，推送到事件消费者。

一般来说， emitter 事件源主要用于构件的配置而不是为客户端应用准备的。 Emitter 事件源可以在初始化、配置构件时用于联系作为客户程序、其它构件及系统对象的事件通道的代理的事件消费者．与之相反， publisher 事件源则用于提供客户端程序以获驭构件所产生的特殊的事件流。

•  属性

为了构件的配置， CCM 规范扩展了在以前的 CORBA 对象模型中的属性的含义．属性可山配置工具设置以用于预置构件初始值的。通过初始化构件属性来为构件建立基本的行为特性．构件的配置过程土要是设置构件属性的过程．在 CCM 规范中把构件的配置生命周期 (Configuration Life Cy cle) 分为配置阶段 (Configuration Phase) 和一些特殊的操作来配置或修改构件的属性集．当配置完毕之后，调用 configuration complete 操作标志配置阶段结束，构件进入可操作阶段． CCM 定义了专门的配置接口 configurator 完成构件配置，它封装了修改构件属性的一个操作集，

和以前的 CORBA 不同， CCM 规范允许当系统配置完成后，通过访问和修改属性 (Attributes) 的值来引发异常．构件的开发者可以利用这个特性在试图去修改已经配置好的构件属性值时引发异常．而以前版本的 CORBA 规范则要求构件开发者必须确定构件的属性是暂态的持久的．

二．基于 CCM 模型的 SOC 分布式系统的设计与实现

1 ． CCM-SOC 服务架构概述

原来的系统是采用永达私有协议进行通讯的，与其他的软、硬件通讯存在一定的困难；而且产品只能以全套部署，无法实现各部件的即插即用，无法保护客户以前的投资影响市场的拓展部署，引入 CORBA-CCM 规范就是为了解决上面的问题。为了减少修改工作量，使原各部件可无缝接入新的平台，系统的架构如图 5 所示 .

图 5. 系统总体架构图

•  配置管理器

安全管理与控制平台的人机交互平台，输入的是人制定的安全策略，管理策略 、 目标等，并向安全管理与控制平台输出对应的配置文件。

 

•  永达核心部件

是永达公司设计开发的原 SOC 部件的核心产品是安全管理与控制平台，接受配置管理器的发来的配置文件，根据各个组件的能力，向各组件分配任务，并负责组件之间的协调。

 

•  适配器

安全管理与控制平台与其他组件之间的联系的转换器。向外提供的 CORBA 的 CCM 接口，向内提供的是 Tpcomme 接口。

 

通过图 5 我可以看到基于 CCM 的 SOC 分布式系统的通讯方式有下面几种情况：

<1> 对于符合 CORBA-CCM 规范的组件就直接用 CORBA-CCM 的机制通讯。

<2> 对于支持永达通讯平台的系统，则通过适配器接入 CORBA 平台。

<3> 对第三方的非 CORBA 业务，可以通过扩展适配器而接入系统中。

 

通过本方案，把原来的认证部件、密码部件、数据采集部件、防火墙等以组件的形式剥离出去。这样布署的时候既可以以整套方案部署，也可以以部分组件部署，同时也实现了和其它资产的互连互通，有效地解决了以前存在的问题。

 

 

2 ．认证组件的设计和实现

认证组件的和外界交互需要使用的接口主要有：加密接口，签名接口，验证接口，认证接口，获取随机数接口等。对应的 CCM 组件的设计如下所示：

module auth

{

typedef sequence<octet> byteArray;

interface AuthServer

{

wstring doAuth(in wstring xmlMsg);

byteArray getRandom();

byteArray RSAEncryptWithID(in byteArray data, in wstring id);

byteArray sign(in byteArray data);

long verifySignWithID(in byteArray data, in wstring id, in byteArray random);

};

 

component AuthServerManager

{

provides AuthServer authserver;

};

 

home AuthServerManagerHome manages AuthServerManager

{

};

};

经过编译后形成 CCM 实现的 monolithic 和 cif 框架。由于原来的认证组件是用 C 写的，所以具体的业务处理用 jni 来写。 Jni 是 java 和本地 C 程序调用的一种规范。 Jni 的部分函数的功能如下：

* 函数名称 : download_cert

* 描 述 : 从证书服务器下载证书到本地，并在本地建立名为 id 的证书文件，同时将证书内容及长度写入 data 和 len

* 函数名称 : get_root_cert

* 描 述 : 读取根证书证书，如果根证书不存在，则需从证书服务器下载，将其内容及长度写入 data 和 len

* 函数名称 : get_sign_pub_key

* 描 述 : 取得用户公钥

* 函数名称 : JniRSAEncryptWithID

* 描 述 : Jni 调用，对数据进行加密

* 函数名称 : JniVerifySignWithID

* 描 述 : Jni 调用，使用公钥对用户或节点的签名验签

* 函数名称 : JniSign

* 描 述 : Jni 调用，随机数进行签名

其它的组件如数据采集组件、密码组件等的封装与认证组件的封装类似。

部分源代码见附录。

 

三．工作总结及展望

本文介绍了 CCM 构件规范和原理，结合 SOC 的实际情况，提出基于 CCM 构建 SOC 分布式系统的模型，并实现了对部分组件的封装，初步构造了一个基于 CCM 的 SOC 分布式系统。下一阶段的工作主要是对系统的优化，提高系统的效率，增强协调性，提高容错性和负载平衡能力等。

四．参考文献

主要参考文献（列出作者、论文名称、期刊名称、出版年月）

[1] 周雯 , 周斌， CORBA 分布构件技术的研究与实现， 计算机应用研究， 2004 年

[2] 刘奕明， 龚红焱， 陈涵生， CCM 构件实现框架的分析与研究，计算机工程 2004 年 4 月， 第 30 卷　第 8 期

[3] 徐焕良 , 李绪蓉 , 丁秋林， 一种基于 CCM 的机构元知识构件模型，机械科学与技术，第 23 卷， 2004 年，第 7 期

[4] 窦　蕾 , 吴泉源 , 贾　焰 , CCM 构件技术的研究与实现 , 　计算机工程与科学 , 2005 年第 27 卷第 1 期

[5] 黄杰 , 陈琳等 , 一种基于 CCM 的构件实现框架模型，计算机工程与科学， 2004 年 ，第 26 卷 第 6 期　

[6] 郑启龙 , 姚震 , 陈国良，基于 Java2CORBA 的机群远程调试器的设计与实现，中国科学技术大学学报，第 33 卷第 3 期

[7] 董富强 , 王克波等，基于 CCM 的持久状态服务集成，计算机应用研究， 2004 年

[8] 韦华颖 , 詹剑锋 , 王沁，分布式构件技术综述，计算机应用研究， 2004 年

[9] 吕行 , 王志坚 , 许峰， CORBA 构件组装技术研究与应用，计算机与现代化， 2004 年第 7 期

[10] 龙湘明，杨放春， CCM 与 EJB 的比较与评价，计算机工程，第 30 卷，第 18 期 2004 年 9 月

[11] OMG.CORBA Components specification[s].http://www.omg.org,2006.1.13

[12] The OpenCCM Platform.http://openccm.objectweb.org/

[13] OMG CCM Implements Group,MARS PTC & Telecom DTC. Corba Component Model Tutorial[z].OMG TC Docment ccm/ 2002-06-01

[14] OMG. Corba Component Model Specification V3.0 Formal/2002-06-65[z].

[15] Henning M,Vinoski S. 徐金梧 . 基于 C++ CORBA 高级编程，北京：清华大学出版社， 2000-11