CN103885809A

CN103885809A - 一种跨平台c++corba容器及实现方法

Info

Publication number: CN103885809A
Application number: CN201210566168.XA
Authority: CN
Inventors: 郭捷夫
Original assignee: China Mobile Group Liaoning Co Ltd
Current assignee: China Mobile Group Liaoning Co Ltd
Priority date: 2012-12-24
Filing date: 2012-12-24
Publication date: 2014-06-25

Abstract

本发明公开了一种跨平台C++CORBA容器。所述容器包含在主程序中；所述容器包括一个可以被部署的归档文件；所述可以被部署的归档文件包括业务逻辑动态库、所述业务逻辑动态库依赖的动态库和xml部署描述符文件。采用该容器进行业务开发，能够使业务逻辑实现和容器的松耦合，降低开发复杂度，明确部署和解部署过程。

Description

一种跨平台C++CORBA容器及实现方法

技术领域

本发明涉及CORBA C++应用技术领域，尤其涉及一种跨平台C++CORBA容器及实现方法。

背景技术

Java应用有EJB容器技术，可以规定容器组装业务逻辑的标准，这样应用开发者只需要关心业务逻辑，容器负责管理应用的生命周期、session数据共享、数据库访问以及安全和交易等底层技术。但是，C++应用仅有CORBA的CCM(CORBA Component Model，CORBA组件模型)规范有容器的支持，这个规范由于过于复杂、缺乏实践的价值导致基本上没有商用产品实现对CCM的支持，基于CCM的CORBA应用很少见。

目前C++应用在关键业务系统尤其是业务支撑系统BOSS里得到了大规模使用，对于业务逻辑需要有类似于EJB的技术。但是CCM比EJB要复杂得多，CCM需要支持各种语言和各种平台，其中包括了EJB的语义规范。CCM的复杂度在很大程度上制约了程序员对齐理解和掌握，一个经验丰富的CORBA开发人员掌握CCM都需要经过不短的时间，更不用说普通的程序员了，CCM带来的好处完全被其复杂度抵消了。另外，CCM模型是侵入式的，业务逻辑与容器接口高度耦合。例如，在客户端要获得一个远程对象，程序员需要显示的调用1ookup得到home接口，然后调用home的create得到远程对象，同时在服务端程序员需要相应的修改代码，这种方式的弊端十分明显，服务端业务逻辑类是否是远程接口以及客户端是否是发起远程调用的实现对于程序员来讲都是不透明的，因此，程序员不能无缝地把远程调用切换为本地类的调用，增加了开发调试的复杂度。

因此，对于程序员来讲由于上述的原因导致CCM复杂度远超EJB，程序员面临着基于C++的应用开发的细节繁琐，业务改动设计程序变更时开发周期长等问题。

发明内容

为了解决现有技术中CCM组件开发复杂度高的技术问题，本发明提出一种跨平台C++CORBA容器，能够使业务逻辑实现和容器的松耦合，降低开发复杂度，明确部署和解部署过程。

本发明的一个方面，提供一种跨平台C++CORBA容器，所述容器包含在主程序中；所述容器包括一个可以被部署的归档文件；所述可以被部署的归档文件包括业务逻辑动态库、所述业务逻辑动态库依赖的动态库和xml部署描述符文件。

本发明的跨平台C++CORBA容器，通过容器为主程序提供宿主服务，并且通过部署描述符来生成应用对象并控制应用对象的生命周期，同时通过编译器技术生成Bean的委托类实现了业务逻辑和容器的松耦合，部署描述符提供丰富的语义支持比较复杂的容器组装行为，通过该容器能够降低开发人员在开发业务时的复杂度。

附图说明

图1是本发明实施例中可以被部署的归档文件的目录结构的示意图；

图2是本发明实施例中跨平台C++CORBA容器的逻辑结构示意图。

具体实施方式

本发明一种跨平台C++CORBA容器实施例是实现一个包含main函数的主程序，根目录下包括META-INFO(元信息)文件，由一系列的cecb.xml文件(xml部署描述符文件)组成；BEAN-IMPL(初始程序装入)文件，由业务逻辑动态库组成；LIB库文件，由业务逻辑动态库依赖的动态库组成。以上文件的名称均为Java范畴中的标准表述。上述三个文件打包在一个压缩包里构成一个可以被部署的归档文件，在本实施例中称之为CBAR(CORBABean Archive)。该文件的目录结构如图1所示。

在本实施例中，容器上设置作用所有应用对象的属性，需要部署的应用对象最终编译成一个个动态库。一个动态库可以包含一个或多个应用对象，应用对象使用xml部署描述符文件来表述其属性和部署行为。CBAR和容器主程序在同一个进程空间内，构成一个独立的进程，这个进程和其他的CORBA服务进程是同等的，负责应用组件的生命周期管理。即所述跨平台C++CORBA容器为所述主程序提供宿主服务，通过所述xml部署描述符文件生成应用对象并管理所述应用对象的生命周期。

如图2所示，为本发明跨平台C++CORBA容器实施例的逻辑结构示意图。所述容器包括部署接口，用于部署应用时，根据预设的xml规范解析所述应用的部署描述符文件，根据所述应用设定的policy和对象名称激活CORBA对象。当所述容器负责交易或安全功能时，修改CORBA产品使所述容器根据预先配置的交易或安全属性传输交易或安全的上下文以及提交和回滚事务控制功能。所述容器中包括CORBA Bean(CORBA豆)和CORBABean Tie(CORBA豆委托类)；所述CORBA Bean是预设的业务逻辑实现；所述CORBA Bean Tie是所述CORBA Bean的委托类。

其中CORBA Bean是应用开发人员写的业务逻辑实现不需要继承任何的接口，而CORBA Bean Tie是CORBA Bean的委托类，由编译器自动生成，是实际的Servant。请求首先是派发到CORBABean Tie，然后由CORBA BeanTie转发给CORBA Bean，从而实现了Bean的松耦合。CORBA Bean Tie提供内向接口被容器调用，容器底层是ORB，(Object Request Broker对象请求代管者)，容器通过ORB双向接口与各种服务交互。

容器实现了main的主体程序，一般情况下都不需要重新启动。容器提供部署接口，当有应用需要部署时，容器根据预设的xml规范定义解析应用的部署描述符文件，根据应用设定的policy，对象名称和其它的属性激活CORBA对象。

容器这些实现通过标准的CORBA接口就可以做到，因此可以不修改CORBA产品代码的前提下实现这个简单的功能。但涉及到容器需要负责交易，安全等基础功能时，如果CORBA产品没有提供足够灵活的接口则需要对CORBA产品本身做一定的修改。例如对于交易来说，修改的目的是让容器根据用户配置的交易属性自动传输交易上下文以及提交和回滚等事务控制的功能。

为了实现让CORBA Bean可以是POCO对象(plain old C++object，基本原C++对象)，必须有一定的手段来让CORBA Bean和容器的基类接口进行关联。如果是Java的话可以通过反射的方式来轻松解决，但是C++语言并没有提供这种语法支持。为了达到这个目标，采用了通过编译器来生成动态代码的方式。编译器可以实现跟EJB3类似的注解支持，做法就是扫描C++代码中的注解然后按照规定的语法规则来生成代码。编译器解决了CCM和CORBA原始编程模型中业务代码侵入的问题。

以下为本发明C++CORBA容器实施例的工作流程，包括：

步骤部署CBAR的时候，容器依次做如下工作：

1、展开CBAR；

2、设置好动态库搜索路径，动态载入业务对象动态库；

3、解析cecb.xml文件，根据文件描述激活CORBA Enterprise C++Bean为CORBA远程对象。

解部署CBAR的时候，容器做如下工作：

1、去活CORBA对象；

2、卸载动态库。

Xml部署描述符文件是本发明的核心部分，下面列举部分实现代码说明其实现方法，<！ELEMENT…>部分就是定义了一个poa所包括的元素。<！ATTLIST…>定义了poa中的一些属性。在下面表格中有说明。。

POA(Portable Object Adapter可移植对象适配器)部分的定义如下：

每一个POA都有一个唯一的名字，POA由容器创建。下边是POA运行时的policy列表，容器在创建POA的时候将会从部署描述符文件中取出这些policy并赋给创建的POA。

CORBA对象

oid是对象id，rep-id是接口池id，activate指定是否需要激活对象，servant是需要激活的CORBA对象的Bean。

下面以一个实际开发的例子说明采用本发明的容器后能够取得的实际效果。

程序A发送一个事件通知给服务端，然后服务端从A取相关的消息。

传统CORBA应用开发过程如下：

1、需要定义如下idl；

2、使用idl生成stub和skeleton代码；

3、编写实现代码(注意实现代码必须继承CORBA的相关类)；

4、编写主程序；

5、启动程序。

使用CCM的开发过程，以CIAO(Component-Integrated ACE ORB)为例，概述如下：使用CCM比传统编码复杂很多，除了编写业务的idl外，两个接口对应两个组件，针对每个组件需要编译生成相关代码，对每个组件各自编写一个idl和cidl，除了业务代码外需要实现多个容器相关的类例如home接口。通过CosMIC生成部署描述符，现在可以开始部署了，首先需要启动Execution_Manager，然后再运行Plan_Launcher来完成部署。整个过程相当冗长和复杂。

使用本发明提供的C++CORBA容器的开发过程如下：

1、编写idl

2、编写实现类(注意业务代码不需要继承任何的CORBA类)

3、编写简单的部署描述符文件(产品可以提供专门图形界面工具来生成)

4、编译业务代码和自动生成的代码，打包部署包(产品可以提供工具)

5、部署

可以看到，用户不再需要编写任何和CORBA相关的代码，仅仅需要实现业务逻辑，而且业务逻辑实现类不需要继承任何的CORBA接口。因此业务可以任意组装成不同的对象，这个过程不需要改动任何代码甚至不需要重新编译代码。而传统的模型是必须修改代码的。这样大大降低了代码的灵活拆分和组装。同时应用开发人员需要花费较多时间去掌握CORBA相关的知识，这样无形中提高了应用开发的门槛。

因此，采用本发明的C++CORBA容器继续业务开发，能够达到以下效果：

1、非侵入的容器支持，大大提高了代码的可重用和可移植性。

举例来说，没有容器的时候哪怕是使用CCM的模型，业务逻辑类必须继承固定的接口。这使得多个业务逻辑类之间合并和分离成为了很麻烦的事情。使用本案的容器后，完全做到了业务逻辑的POCO独立性。由于C++本身限制，本方案独创性的提出了编译工具自动生成代码的思路。通过这种方式C++同样可以做到目前JAVA最先进的技术和理念。

2、简单高效的组装逻辑，大大的提高了开发效率。

没有容器时，没有独立的组装逻辑，应用对象的部署完全是由应用开发人员通过编程实现。而CCM的实现则引入了很复杂的逻辑，程序员由于容器的引入必须做很多额外的开发工作，虽然容器有灵活的组装功能，但这些额外的复杂工作使得有容器的开发比没有容器的开发更难。而本案的组装逻辑在做到了灵活的前提下极大简化了应用开发人员的开发工作。开发人员只需要写业务逻辑不再需要写跟CORBA相关的代码。

应说明的是：以上实施例仅用以说明本发明而非限制，本发明也并不仅限于上述举例，一切不脱离本发明的精神和范围的技术方案及其改进，其均应涵盖在本发明的权利要求范围中。

Claims

1.一种跨平台C++CORBA容器，其特征在于，

所述容器包含在主程序中；

所述容器包括一个可以被部署的归档文件；

所述可以被部署的归档文件包括业务逻辑动态库、所述业务逻辑动态库依赖的动态库和xml部署描述符文件。

2.根据权利要求1所述的跨平台C++CORBA容器，其特征在于，

所述跨平台C++CORBA容器为所述主程序提供宿主服务，通过所述xml部署描述符文件生成应用对象并管理所述应用对象的生命周期。

3.根据权利要求1或2所述的跨平台C++CORBA容器，其特征在于，

所述业务逻辑动态库和所述业务逻辑动态库依赖的动态库包括不少于一个的应用对象；

所述xml部署描述符文件包括所述应用对象的属性和部署行为。

4.根据权利要求3所述的跨平台C++CORBA容器，其特征在于，

所述xml部署描述符文件的所述应用对象的属性和部署行为通过POA定义。

5.根据权利要求1或2所述的跨平台C++CORBA容器，其特征在于，

所述容器包括部署接口，用于部署应用时，根据预设的xml规范解析所述应用的部署描述符文件，根据所述应用设定的policy和对象名称激活CORBA对象。

6.根据权利要求1或2所述的跨平台C++CORBA容器，其特征在于，

当所述容器负责交易或安全功能时，修改CORBA产品使所述容器根据预先配置的交易或安全属性传输交易或安全的上下文以及提交和回滚事务控制功能。

7.根据权利要求1或2所述的跨平台C++CORBA容器，其特征在于，

所述容器中包括CORBA Bean和CORBA Bean Tie；

所述CORBA Bean是预设的业务逻辑实现；

所述CORBA Bean Tie是所述CORBA Bean的委托类。

8.根据权利要求7所述的跨平台C++CORBA容器，其特征在于，

所述CORBA Bean Tie通过编译器根据所述CORBA Bean生成。

9.根据权利要求7所述的跨平台C++CORBA容器，其特征在于，

业务请求派发到CORBA Bean Tie，由CORBA Bean Tie转发给CORBA Bean，实现Bean的松耦合。

10.根据权利要求7至9所述的跨平台C++CORBA容器，其特征在于，

所述CORBA Bean Tie提供内向接口被所述容器调用；

所述容器底层是ORB，所述容器通过所述ORB的双向接口与各种COS服务交互。