SCA(Service Component Architecture)，即服务组件架构，是最新发布的组件集成架构，SCA体现的是一种利用通用组件定义方式来集成分散商业功能的思想，SCA的出现，为企业系统集成带来了新的方法和标准，实质上SCA即将成为SOA系统的基本构建方式，同时SCA也是新发布的WPS(WebSphere Process Server)中的最重要的技术基础架构。许多SOA开发人员以及系统管理人员对于SCA模块及其组件的运行监控和调试还不是很熟悉，在本文中，作者将向大家简单介绍如何配置和使用CEI(Common Event Infrastructure)在WPS中监控SCA组件的运行情况。

　　引言

　　本文将主要介绍以下几个方面的内容：

　　1， 什么是CEI和CBE；

　　2， 如何为SCA组件激活和配置CEI事件监视器；

　　3， 如何在WPS中配置CEI来监控SCA组件的运行情况；

　　4， 如何利用CEI提供的API来实现灵活定制的事件管理；

　　1.什么是CEI和CBE

　　1．1 什么是CEI

　　CEI (Common Event Infrastructure)本质上是一种用来封装应用程序中产生事件的通用机制。整个CEI的框架是基于EMF(Eclipse Modeling Framework)之上构建起来的，因此我们也可以看到CEI的底层实现是基于MDA/MDD来构建的。CEI也为开发人员提供了一套完备的API来生成和发布事件，另外也提供了客户端的API来帮助开发人员便利地检索已经记录下来的事件。在CEI的框架中是通过中央的CEI服务器来完成事件捕获和分发任务的。CEI是 SOA 核心的一部分，我们可以使用 CEI 捕获用于监视应用程序的事件（如在 IBM WebSphere Business Monitor 或Tivoli 产品中）。CEI 是WebSphere Process Server 的重要组成部分,并通过它为每一个 SCA 服务组件生成一组特定的事件。图 1 是WPS的框架图,我们可以看到CEI是SOA底层的核心组成部分。

　　图1：WebSphere Process Server整体框架图
 
　　CEI的整体架构示意图如 图 2 所示：

　　图2：Common Event Infrastructure整体架构图
 
　　CEI服务器是CEI架构的核心部分，主要完成了以下几个功能：

　　实现了所谓的”事件总线”，所有的事件都可以由不同的事件源发布到事件总线上。在CEI架构的物理实现上，事件总线（Event Bus）被实现为普通的J2EE应用并通过无状态Session Bean和消息驱动Bean两种形式提供了不同的使用方法。

　　提供平台来把记录下来的事件分发到相应的事件消费者那里。这包括两种不同的分发方式，即点对点的方式和PUB/SUB的方式。

　　除了提供事件的发布支持以外，CEI也提供了强有力的事件持久化的实现。通过一定的配置，可以将CEI平台与不同的关系型数据库系统（DB2,Oracle，Cloudscape等）关联起来，利用这些已有的关系型数据库来实现完备的事件持久化支持。WPS内置的CEI平台默认是以Cloudscape数据库来提供事件持久化支持的。

　　CEI实质上是提供了一种中央集中的事件服务器拓扑结构的具体实现。

　　1．2 什么是CBE

　　CBE(Common Base Events)即公共基本事件是一些复杂的EMF对象。CBE模型是一种标准，用来定义将由企业管理和业务应用程序使用的事件的公共说明。此标准由 IBM 自治计算体系结构委员会开发，支持对记录、跟踪、管理和使用基于公共 XML 格式的业务事件进行编码，并使得不同应用程序生成的不同类型的事件之间可以相互关联。

　　图3：Common Base Events结构图
 
　　CBE事件体中的事件负载（Payload）是一种被扩展了的数据元素，所有事件的具体内容都包含在事件负载中，具体事件的内容和结构取决于事件本身。在SCA模块中，所有的组件都可以被配置成生成三种不同的事件负载模式：

　　满负载模式（Full Payload）：所生成事件中包含最充足的信息，在SCA架构中完整的商业对象（Business Object）的实体都被提供在所生成事件的事件负载中。

　　摘要负载模式（Digest Payload）：所生成事件中并不包括完整的商业对象实体，只包含商业对象实体的关键字。

　　空负载模式（Empty Payload）：所有商业对象的相关数据都不会被包含在事件体中，在这种模式下，用户实际上并不关心事件的内容，而只关心事件发生的位置，发生的时间等其他信息。

　　2.如何为SCA组件激活和配置CEI事件监视器

　　如果我们想要利用CEI来监控SCA组件的运行情况，我们就需要为相应的SCA组件激活CEI的事件监控功能。这里有两种方式可以利用：

　　在开发SCA组件的过程中使用静态配置的方式：

　　这种方式主要是在我们基于WID开发SCA组件的过程中来静态的配置和使用CEI。主要的缺点是如果我们需要重新配置相应的SCA组件，我们只有通过重新deploy 相应SCA模块的方式来实现，不是十分的灵活。

　　在运行环境中使用动态设置的方式：

　　这种方式主要是通过WPS的控制台来动态的配置和使用CEI。这种方式比较灵活，但是需要配置人员对于整体SCA应用程序的组件粒度划分了解的比较清晰。

　　在SCA应用模块中的所有的调用都可以被CEI监控，所有的SCA组件都可以被配置（动态或者静态）成相应的CEI事件源。不同组件可以生成的事件类型是不尽相同的，但是对于基本的事件类型，如Entry，Exit和Failure，每种SCA组件是都可以生成这些事件的。

　　2．1 以静态配置的方式来为SCA组件激活并设定CEI参数

　　我们可以通过WID (WebSphere Integration Developer)中的集成编辑器（Assembly Editor）来为不同的SCA组件配置CEI参数。如图 4 所示，在我们选中了某一个SCA组件之后，可以在WID中的Properties > Event Monitor视图中来配置相应的CEI参数。我们可以选择不同的配置方案，比如只捕捉SCA组件的Entry事件。另外在这个视图中我们也可以选择所捕捉事件的类型（full payload，digest payload和empty payload）以及所选用的Transaction类型。

　　图4：WID中SCA组件的Event Monitor视图
 
　　静态配置方式范例: BPEL流程

　　在图 5 中我们可以看到，即使Invoke和Receive都是BPEL流程中的元素，它们所拥有的CEI事件配置也是不尽相同的。

　　图5：WID中BPEL组件的Event Monitor视图
 
　　2．2 以动态设定的方式来为SCA组件激活并设定CEI参数

　　我们可以通过WPS中的管理控制台来动态的为SCA组件激活CEI配置。在WPS的管理控制台中选择Troubleshooting > Logs and Trace > server > Change Log Level Details，然后选择runtime页，然后就可以动态的配置不同的组件。所有的组件必须已经至少运行过一次才能出现在这个视图中，如果我们已经知道确切的组件名字，我们可以在这个配置视图下方的trace定义栏里来配置我们所需要的组件。

　　图6：WPS管理控制台中Log Level配置视图
 
　　动态配置方式中的一些选项:

　　在 图6 中我们可以看到，有两组不同的组件配置定义方式，一组是以CEI作为前缀的，一组是以LOG作为前缀的。以CEI作前缀的组会将生成的事件发送到CEI事件服务器上，而以LOG作前缀的组会将生成的事件发送到WAS的LOG记录器上。

　　图7：WPS管理控制台中Log Level配置视图
 
　　3.如何在WPS中配置CEI来监控SCA组件的运行情况

　　3．1 如何在WPS中配置CEI

　　在WPS的管理控制台来配置CEI主要有以下两个需要配置的地方：

　　CEI自身相关的资源：
　　WebSphere平台相关的资源：

　　下面简要介绍了一些比较重要的配置点：

　　事件服务器（Event Server）配置：

　　通过Common Event Infrastructure Provider>Event Server Profile页面来开启或者关闭事件分发的功能；开启或者关闭事件持久化的功能；并可以配置事件服务器相应的事件数据存储源的信息。图 8 显示了WPS管理控制台中Event Server配置视图。

　　图8：WPS管理控制台中Event Server配置视图
 
　　事件组（Event Groups）配置

　　通过事件组的配置，我们可以将事件划分到不同的分组当中，所有属于某一个事件组的事件都会被一起分发到相应的事件消费者那里。我们可以定义PUB/SUB或者P-to-P的事件发布模式。

　　事件发射器（Emitters）和发射器工厂（Emitters Factory）配置：

　　事件发射器实质上是一些功能类的集合，通过这些功能类提供的功能，不同的事件源可以创建或者发布不同的事件。而这些事件发射器是通过事件发射器工厂得到的。通过对事件发射器工厂的配置，我们可以指定所生成的事件将会被发布到什么样的事件总线上去，是异步还是同步方式发布的，是不是以支持transaction的方式来发布事件。

　　图9：WPS管理控制台中Event Service配置视图
 
　　事件传送（Transmission）配置：

　　CEI相关的事件传送有两种方式，第一种是利用事件总线（Event Bus）来同步的发布事件；第二种是利用JMS机制来异步的发布事件。CEI中的事件总线机制是由无状态的Session Bean来实现的，而异步的事件发布机制是由MDB(消息驱动Bean)来实现的。

　　J2EE相关资源的配置

　　JMS 相关资源

　　为事件服务器上配置相应的队列（Queue）去接受发布的事件；

　　配置事件分发和订阅所需要的队列和主题（Topic）；

　　配置事件服务器的激活规范（Activation spec）；

　　JDBC 数据源

　　为事件数据库配置相应的数据源；

　　BPEL流程和HTM（Human Task Management）容器的配置

　　对于BPEL和HTM的容器来说，CEI需要被显示的激活，否则在默认的情况下CEI在这些容器中是没有被激活的。在WPS的整体系统配置的架构中，这些容器的配置信息是整个WPS服务器配置信息的一部分。在WPS的管理控制台中，我们可以定位到Application Servers > server > Business Process Container Settings (或者 Human Task Container Settings)来显示地激活相应的CEI监控功能。如图 10 所示：

　　图10：WPS管理控制台中Business Process Container配置视图
 
　　3．2 如何在WPS中监控SCA组件的运行情况

　　我们可以通过WPS管理控制台中的CBE浏览器（CBE Browser）（位于控制台中的Integration Applications > Common Base Event Browser页面中）来浏览和检索所有已经发布到CEI事件服务器上的事件。如图 11 所示：

　　图11：WPS管理控制台中内嵌的CBE浏览器视图
 
　　不同类型的事件消费者：

　　针对CEI中的事件存在着两种不同的事件消费者，一类是”Pull”类型的事件消费者，另一类是事件的订阅者类型。对于”Pull”类型的事件消费者来说，他们通过主动查询事件数据库来得到所需要的事件信息；对于事件的订阅者来说，他们不会主动的去查询或者检索事件数据库，他们是依靠事件服务器所提供的”Push”事件的功能来将他们所订阅的事件发送给他们，可以说这是一种被动接受事件信息的方式。

　　CEI为开发人员提供了相应的API来支持这两种事件消费方式。CEI事件服务器通过无状态的Session Bean来支持第一种事件消费方式；通过JMS机制来发布事件到相应的事件订阅者来支持第二种事件消费方式。

　　4.如何利用CEI提供的API来实现灵活定制的事件管理

　　4．1 CEI提供的API

　　在WPS中，CEI提供以下几类API：

　　a.创建事件API

　　WPS中的CEI提供两个产生事件的工厂,一个是通用事件工厂（org.eclipse.hyades.logging.events.cbe.EventFactory）,另外一个是Webphere特定的事件工厂(com.ibm.websphere.cem.ECSEmitter）。前者由于需要用户自己处理事件的相关性， 所以在WPS环境中不推荐使用， 后者是集事件的创建，相关性，发送于一体的,创建事件的用法如列表1所示。

　　列表1 创建事件代码片断

 
　　ECSEmitter 自动为事件添加一个parent id 和current id来处理事件的相关性，这样就会形成一个事件树。另外如果要往事件里面添加很多扩展数据，可以把一个java.util.Properties实例传给ECSEmitter,这样会自动根据Properties内容创建事件，并发送给CEI server，请参考列表2。

　　列表2 使用Properties对象创建事件代码片断

 
　　b.发送事件API

　　用户创建的事件是通过ECSEmitter类的API来发送给CEI server的,用法如列表3所示。此外事件的发送可以是同步的，也可以是异步的。

　　列表3 发送事件代码片断
 
　　c.查询事件API

　　WPS中的CEI对外暴露出一个无状态的Session Bean, 通过这个bean用户可以查询符合给定条件的事件，用法见列表4。

　　列表4 查询事件代码片断

 
　　EventAccess这个bean，提供了几个查询方法，可以传入不同的检索条件，对于样例里面的queryEventsByEventGroup方法，第一个参数是事件组的名子，第二个参数是事件选择器，选择条件是基于xpath的，例如CommonBaseEvent[@extensionName = ‘ WBI.JService.MethodInvocation.ENTRY ‘] 表示只选择扩展名为WBI.JService.MethodInvocation.ENTRY的事件, 构建event selector这个参数时请参看CBE定义文件。

　　d.事件分发API

　　对于每一个事件组，用户可以配置一个JMS queue 或者Topic。当CEI server收到一个事件，判断这个事件是否属于某个事件组，如果属于，那么就会把事件发布到事件组的JMS queue或者Topic上， 用户只要写一个MDB监听这个queue或者Topic就可以获取和处理发布的事件了。注意com.ibm.events.notification.NotificationHelper这个Helper提供了把JMS message转换成CBE实例的功能，列表5是这个Helper的使用方法。

　　列表5 NotificationHelper使用代码片断

 
　　e.事件编目API

　　事件编目就是一个存储事件元数据的地方， 可以指定事件的定义， 并且提供了一些用于添加，修改，删除事件定义的API,通过CEI对外暴露的一个session bean，用户可以访问这些API， 获取这个bean的代码如下。用户可以使用事件的定义进行事件的校验。

　　列表6 获取EventCatalog的代码片断

 
　　4．2 使用范例

　　4.2.1范例简介

　　这是一个提供水果报价服务的SCA例子，下图是其组装图。对外提供的功能很简单，用户输入一个水果的名字，那么就会返回相应的水果报价。下面解释一下具体的调用流程。

　　首先，客户端（JSP）通过stand-alone reference, 把水果名字发送给Fruit组件,接着Fruit组件去调用同一个module里面的Characteristic Provider组件，Characteristic Provider组件根据水果的名字，返回给Fruit组件一个关于该水果特征（id，产地，描述）的BO(Business Object)， 然后Fruit组件从获得的BO中取得该水果的id，根据这个id去调用另外一个module里面的seller组件，seller组件把水果价格返回给Fruit组件，最后，Fruit组件再把获得的结果传给客户端。

　　图12：WID中使用范例的组装视图
 
　　4.2.2加入事件管理代码

　　a.启动事件监控

　　注意上图中，Fruit组件的接口部分有一个小黄旗，这是由于我们为组件Fruit的接口中的方法配置了事件监测，对于组件Fruit的调用所产生的事件(包括Entry，Exit和Failure)，都会自动发送到CEI服务器。

　　b.添加产生事件的代码

　　在Characteristic Provider组件中，我们添加了产生/发送事件的代码，如果用户输入的水果名子不是apple或者 orange，那么就会触发这部分代码。

　　列表7 产生/发送事件代码片断

 
　　c.添加事件访问代码

　　在Seller组件中，我们添加了事件访问代码， 同样，如果用户输入的水果名子不是apple或者orange，这段代码会去检索CEI server中的所有事件，并且找到Characteristic Provider组件中产生的事件，把该事件的信息打印到控制台。列表8是添加的代码片断。列表9是运行时，在客户端页面(http://localhost:9080/FruitModuleWeb/index.jsp), 用户输入ora之后，打印在控制台的事件信息。

　　列表8 事件访问代码片断

 
　　列表9 控制台打印信息

 
　　d.通过Common Base Event Browser浏览CEI server的事件

　　打开WPS管理控制台，点击Integration Applications–>Common Base Event Browser,之后在右侧窗口，点击Get Event按钮，然后选择All Events这个事件组，就会显示这个事件组的所有事件，在事件组中可以找到ora这个事件，选中它，就可以查看这个事件的详细信息了,在下图（事件浏览页面）中， Event Data部分就是ora的详细信息了, 在图中还可以看到,在ora事件的下面是WBI.JService.MethodInvocation.EXIT事件，这个事件表示退出Fruit组件方法的调用， 这个事件是通过a部分的配置产生的。

　　图13：WPS管理控制台中内嵌的CBE浏览器视图
 
　　5.结束语

　　本文简要介绍了有关CEI、CBE以及如何在WID/WPS中使用CEI及其提供的API来完成SCA组件运行的监控和调试任务。本文的内容只是涉及到了有关于CEI的一部分内容，希望能对基于SCA架构以及WID/WPS来开发SOA系统的系统开发设计人员起到一定的帮助作用。

　　在我们利用CEI提供的强大功能的同时，我们也要注意到CEI的使用会对系统性能带来比较大的影响。这主要是由于CEI平台中的事件都是EMF对象，而EMF对象的初始化是比较消耗时间和资源的，而且所创建事件的处理和发布也比较的耗时。因此，如果使用CEI的环境是一个对性能要求较高的环境的话，我们应该有选择性的使用CEI来监控系统运行情况，在可以使用LOG机制的地方可以选用LOG来记录我们所需要的信息。另外，如果我们是想利用监控到的数据来提供KPI的参考，我们应该考虑使用传统的PMI（Performance Monitoring Infrastructure）来满足我们的需求。通常来讲，使用PMI架构所带来的系统性能影响要小于CEI架构所带来的性能影响。

　　作者简介

　　王强，IBM软件工程师，工作在IBM中国软件开发实验室 – SOA Design Center，从事Incubator及SOA，Grid项目的工作，对J2EE架构、SOA架构、MDA/MDD、AOP以及网格计算等技术有较深入的研究。联系方式：wangq@cn.ibm.com
 
　　李方太，自2004年起加入IBM CSDL Incubator小组工作，从事Incubator及SOA，Grid项目的工作。对J2EE架构、SOA架构、AOP等技术有较深入的研究。联系方式：lifangt@cn.ibm.com
 
　　卢中延，IBM软件工程师，2004年加入IBM中国软件开发实验室，从事WPS，WID及BTT的技术支持工作。对J2EE、Struts、WPS、WID、WSADIE等技术和产品有较深入的研究。联系方式：luzhongy@cn.ibm.com