OMG CORBA构件技术体系(3)

 

OMG CORBA构件技术体系(4)<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

作者: 贾育
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）代码以及持久性管理，代码的执行业务规则插入在这些文件之中（编译成为代码），在构件容器运营商的工具的支持下，开发者把这些实现代码和配置文件、特性文件封装成为软件包。

（2）应用集成人员

有两个地方需要集成人员：首先需要将多个构件的集合商业化，构件集成体作为销售的单位。其次用户购买独立的构件，但需要与第三方构件、用户自己的构件集成在一起部署。

（3）应用部署人员

       应用部署人员在完成对部署描述文件的修改之后，把应用部署到CCM-认同的应用服务器上。部署设置有些在运行时会被覆盖，有些只能在运行时配置。

（4）服务器提供者

   按照CCM规格说明提供应用服务器的实现。

（5）容器提供者

   容器提供者的任务是编写容纳CCM构件的容器，一般是服务器提供者的职责。

（6）管理员（Administrators）
管理员的任务是管理数据库的理解、名字服务与交易服务和性能监控。
 

IDLScript

IDLScript 是CORBA 3.0规格说明的一个组成部分，充分利用了动态机制，它的特点是简单易学，CorbaScript是IDLScript的第一个实现，用作实现和操作CORBA对象。
 

商业EJB构件的文挡编写

商业构件是不带源代码的“黑盒”，文挡给出详细的产品信息作为客户评价的依据。典型的文挡包括：
（1）技术文挡
       在线文挡；常见格式是HTML，HELP文件和PDF文件。
       演示软件；演示软件可以证明构件的价值，有利于理解基于构件的产品的功能和性能，还可以借此培训用户，测试构件的运行环境。
       评估试用；用户对非自己开发的构件常常持怀疑态度，构件的评估十分必要，给一段试用期是一种很好的评估方法。
       代码样例；代码样例对用户建立原型和评价构件功能十分有用，可以让用户了解如何构件的操作方法。
       Readme文件；包括构件发行的最后更改、勘误表、系统环境要求、构件文件的定义、安装注意事项、项目样例的注意事项和分发信息等。