OMG CORBA构件技术体系(4)

最新推荐文章于 2022-05-12 14:05:18 发布

jiayu007

最新推荐文章于 2022-05-12 14:05:18 发布

阅读量1.5k

点赞数

分类专栏：软件构件技术—开发技术文章标签：服务器 components 应用服务器 constructor application 数据结构

本文链接：https://blog.csdn.net/jiayu007/article/details/18745

版权

软件构件技术—开发技术专栏收录该内容

3 篇文章 0 订阅

订阅专栏

OMG CORBA构件技术体系(4)

作者: 贾育

email: jia_yu@263.net

（3）CCM服务

CCM应用服务器为构件提供下列服务：

§ 事务服务（Transaction Services）

§ 安全性服务（Security Services）

§ 名字服务（Naming Service）

§ 持久性服务（Persistence）

§ 资源管理（Resource Management）

（3.1）事务服务

CCM支持两种事务管理：容器管理和人工自管理。容器管理事务仅需申明构件部署描述文件，完全由容器完成，使用方便；人工自管理事务使用容器的UserTransaction接口或直接调用事务服务，需要编程实现。

容器管理事务可以改变构件和操作级的事务策略进行微调，策略与Enterprise JavaBean 规格说明类似的方法定义，下表是CORBA策略属性及其作用：

属性	说明
Not Supported	调用程序调用一个方法时，调用程序的事务被挂起，方法调用后恢复。
Required	构件需要当前事务才能执行。如果调用程序提供了事务环境，被调构件在调用程序的事务环境中; 如果调用程序不在事务环境里，容器在事务开始执行时启动一个新的事务，在操作完成时提交事务。
Supports	如果调用程序提供一个事务环境，被调构件成为调用程序事务环境的一个组成部分；如果调用程序不在事务环境里，操作在如何事务范围之外执行。
RequiresNew	构件需要自己的事务才能执行。如果调用程序提供事务环境，调用程序的事务将被挂起，并且为方法的执行创建一个新的事务。如果调用程序没有提供事务环境，容器为方法的执行创建一个新的事务。
Mandatory	构件的方法调用之前，调用程序必须在事务环境中。被调构件成为调用程序事务环境的一个组成部分。如果调用程序没有提供事务环境，容器发出一个TRANSACTION_REQUIRED CORBA异常信息。
Never	如果调用程序提供一个事务环境，容器发出一个INVALID _TRANS ACTION CORBA异常信息；如果调用程序没有提供一个事务环境，容器将不启动新的事务。

（3.2）安全性服务

安全性策略等同地实施到各类构件。容器的安全策略依赖于CORA的安全性，从配置描述中获取策略说明，为调用操作检查活动证书。安全性策略一直保持有效性，直到调用了含不同策略的其他构件。

存取许可在构件相关的部署描述中定义。许可的粒度必须和部署所装的CORBA安全机制保持一致，因为它会用作在操作调用时的检查。存取许可可以在任何构件端口中定义，当然也包括构件本原接口。

（3.3）事件服务

CCM构件使用一个简单的CORBA通知服务的子集发送和接受事件。该子集可以通过下列属性来描述：

§ 对构件的实现者和构件客户，事件表示成值类型（valuetypes）；

§ 事件数据结构映射到结构化事件体的any，呈现给CORBA通知，或从其中接收；

§ 结构化事件的固定部分发送时容器添加到事件数据结构中，接收时从事件数据结构中移去；

§ 事件具有事务性和安全性，与构件事件接口相关的安全性策略在部署描述中定义；

§ 通道管理用容器实现，而不是构件；

§ 过滤器由容器管理和设定而不是构件；

因为事件事件既可能是客户发送和接收，也可能是构件的实现者，所以发送和接收事件的操作是由构件IDL规格说明生成。容器把这些操作映射到CORBA通知服务上。

（3.4）命名服务

使用查找器方法的客户定位和执行CCM构件的一个操作，可以查找CORBA名字服务或交易服务（如果在网络环境下）；另一个办法是使用本原的find_by_primary_key方法定位实体构件；显然如果使用工厂方法，什么也找不到。

（3.5）持久性服务

CCM支持CORBA的持久性状态服务（Persistent State Service，PSS），PSS操作模式有容器管理持久性和人工自管理持久性之分。使用容器管理持久性时，程序员必须用OMG PSDL（持久性定义语言，是OMG IDL的一个子集）定义构件的状态，在激活/休眠周期里保存和恢复对象状态的过程对程序员来说是完全透明的。使用人工自管理持久性时，程序员必须在构件被容器调用的休眠之前亲自保存构件状态，在方法执行之前从休眠中亲自恢复状态。

（3.6）管理服务器端的资源

从体系结构的角度来看，典型的CCM应用包括一组构件工厂，在运行时按照请求创建构件实例，例如电子商务应用可能包括消费者构件、购货车构件和支付构件。数据库里的每一个消费者都有对应的消费者构件实例，购货车实例是在每次消费者购买商品时（一个特定的时间段）创建，支付构件实例是在消费者按下“付款”按钮的一瞬间。

CORBA实例构件和过程构件是永久性构件，它们的生命期延展到多重调用，因为在客户端没有构件激活和休眠的API，所有客户应该可以在任何时候调用构件实例操作（甚至服务器崩溃时，也可以提交调用请求。），因此每次构件实例的创建和销毁对客户端是可见的，而构件实例的激活和休眠只能服务器可见。

所以，对于数据库中成千上万的消费者不能悠久驻留内存，CCM管理这些实例，调用请求到达时激活，任务完成时休眠，但是对客户端，消费者构件一直在运行。这样优化了运行时的资源，增强了大型应用软件系统（例如各种规模电子商务系统）负载处理能力，可见CCM构件的市场潜力。

除了“每次调用时激活”方式外，CCM还有其他四种资源分配方式。

（4）CCM构件类型

CCM把构件分为四类：

§ 服务构件（Service Components）

§ 会话构件（Session Components）

§ 过程构件（Process Components）

§ 实体构件（Entity Components）

其中，服务构件和会话构件带有暂时性构件参考，也即如果服务器进程终止和服务器重启动时，参考将失效，服务构件和会话构件仅用在短暂的、自包含的操作或函数。与之相反，过程和实体构件只在客户发删除命令且安全策略允许的情况下，构件参考才可能失效，否则即使服务器重新启动，构件参考也能存取。因此过程构件和实体构件适合长效记录和功能，例如消费者档案和银行帐户。

服务构件的生命期最短，一次调用即结束，适用于自包含的功能，例如为购货车中的商品付款的完整过程：从订单上清点货物项目，在消费者的信用卡上记帐，为运输部门编制运单。由于服务构件占有的资源最少，效率最高，因此在基于构件服务器上，最大可能地使用服务构件。另外进程构件和实体构件中的“一次性”功能也应该加载成服务构件。

会话构件可以被多次调用，但是非持续地存储在服务器中：服务器停机后再启动，构件就不复存在了。会话构件仅仅用在一些暂时性功能中。

过程构件定义一个开始和结束的过程，例如申请银行帐户。过程期间构件永久可靠，即使服务器停机再启动，过程仍然通过调用继续下去，在过程结束时销毁构件实例和释放资源。

实体构件是真正的永久性构件，例如消费者信息、帐户信息等等都要定义成实体构件。典型地实体构件存储在数据库中，通过后端的CORBA持久性状态服务和数据库联络，前端是构件接口为应用通过服务。每个实体构件带有一个关键字，作为构件检索的依据。

CCM服务器的资源分配基于构件的类别。上述类别由上到下健壮性越强，资源占有越多。在应用设计阶段就要考虑合理的分割构件，在不损失可靠性的条件下尽可能使用靠前的构件类型，增强服务器的负载能力。

创建CCM构件

为了在CCM中定义构件，构件的开发者需要定义如下几个方面：

§ 构件接口

§ 主接口的端口

§ 构件实现

§ 配置文件

§ 部署描述

（1）构件接口

构件接口用OMG IDL和CIDL（Component Implementation Definition Language，构件实现定义语言）编写，把功能呈现给客户端的调用程序。接口是客户端和构件之间的语法契约，是功能的列表，而不描述功能的实现方法。CCM编译器从构件的接口申明生成构件的骨架。

（2）主接口的端口

主接口呈现出构件的生命周期方法。CCM自动生成创建和移去服务器构件的方法，由于缺省的构建程序（constructor）是自动创建的，所以只需要添加你专需的构件，构件的本原将会记录你的扩展。

工厂（factory）和搜索器方法：使用服务构件和会话构件时，客户端将使用工厂方法记录创建新实例的档案，工厂将构件的实例参考返回到客户端。使用参考是一次性使用服务构件的有效手段，也是多次重复调用会话构件的主要手段，虽然工厂方法也是创建工厂构件和实体构件的方法，但是对于已经存在的实体构件类型，需要在客户端通过搜索器方法，使用CCM在构件本原里定义的find_by_primary_key操作定位构件。过程构件需要客户端保存参考以被后用，可以存储在客户端的cookie里，或在命名和交易服务中（Naming or Trader service）。

（3）构件实现

CCM实现类必须实现：

§ 远程接口说明的所有方法；

§ 主接口中定义的操作（除缺省的构建程序constructor和销毁程序destructor）；

§ CCM规格说明中定义的回调方法，CCM容器通过调用这些方法管理企业构件，和它们交互作用。

（4）部署描述（descriptor）

每个CCN需要一个部署描述文件。CIDL编译器会自动生成一个文件提纲，但是需要你填写其中的细节。部署描述使用XML，大多数是由工具生成的。描述文件里陈述了构件所需的容器类型，以及事务性、安全性、线程和其他容器提供服务的策略。

（5）特性文件（Property File）

特性文件描述构件和本原的属性设置，属性是构件和本原的安装信息。CCM规格说明描述了特性文件的格式和使用方法，集合体里的特性设置在安装时可能被覆盖。

（6）集合体描述

集成体是构件的应用中构件的部分组合，而非完整的应用。如果想要把CCM构件的集成体作为产品销售，必须建立一个集合体描述文件。

（7）错误处理

构件与应用在错误处理上方法不尽相同，首先要意识到任何错误如果在构件里得不到妥善处理，则将影响调用该方法的客户端，因此客户端接受到的信息应该是明白无误的，又由于客户端并不知道构件的逻辑运行过程，显示错误信息必须反映失败的事务环境，由客户端处理和解释。下面是CCM的主要错误处理技术：

内部错误处理；在CCM中处理错误和在应用中一样。一种方法意外地产生错误，如果得不到错误程序处理，将带来调用应用的崩溃。因此需要截获错误，评估错误的严重程度，采取修正动作；结果不外乎两个：要么改正了错误，从失败处恢复继续运行，要么把相关的异常信息返回给调用客户。

把错误返给客户；要把错误返给用户，必须首先在构件的IDL中定义异常，或者该异常是CORBA的标准异常。客户在接收CORBA异常的调用之处，用try/catch循环包裹（wrap）调用，才有处理异常的机会。CCM给客户的错误信息应该是客户端程序员容易理解的，并且有能力处理，它们绝大部分是错误的、不一致的、超范围的参数值，或者是错误的操作序列。

用错误处理程序提交错误；需要编写一个错误处理软件来解决“未知”错误，尽可能多地给客户提供错误信息，一个普通的“unexpected error”信息于事无补，至少有失败的方法名称和传递的参数。

处理其他构件的错误；如果构件调用了第三方CCM构件，应该处理下一级构件产生的全部已知和未知错误，因为你的构件客户并不知道所用构件与别的构件的依赖关系，要么在文挡里写清楚，要么自己处理问题。

（8）线程

EJB体系结构承担管理并发的任务，不要自己管理线程和线程同步，否则会干扰EJB服务器的线程管理，并且EJB服务器自由地使用多重JVM，你的线程管理也不会正确的工作。

CCM开发和部署中的角色

CCM规格说明定义了应用系统开发和部署过程中的各类角色：

§ 构件开发者（Component Developers）

§ 应用集成人员（ Application Assemblers）

§ 应用部署人员（Application Deployers）

§ 服务器提供者（Server Providers）

§ 容器提供者（Container Providers）

§ 管理员（Administrators）

（1）构件开发者（Component Developers Application Assemblers）

构件开发者的任务是定义远程接口、主接口、构件实现类和部署描述，他们使用的编写工具是OMG IDL, OMG PSDL（Persistent State Definition Language，持久性状态定义语言），和OMG CIDL （Component Implementation Definition Language，构件实现定义语言），前面两种语言的编译器由构件运营商提供，后者的有持久性状态服务（Persistent State Service）运营商提供，编译产生的是Java或C++代码，包括根、骨架、生成的实现代码、资源触发（triggers resource）代码以及持久性管理，代码的执行业务规则插入在这些文件之中（编译成为代码），在构件容器运营商的工具的支持下，开发者把这些实现代码和配置文件、特性文件封装成为软件包。