1.简介

　　CommonJ是BEA和IBM联合推出的一个规范，其目的是为了给开发人员在开发可移植的服务端应用程序时提供一些更加简单和功能更加强大的方法。CommonJ中包括的几个子项都是各自领域的一些事实标准，而且正处于标准化的过程中。CommonJ中包括的内容在BEA WebLogicServer和IBM WebSphere Application Server已经提供了支持或者在将来的新版本中即将会提供支持。

　　CommonJ中主要包括了以下几个部分：

　　（1）SCA：Service Component Architecture，主要用来简化SOA系统的开发。

　　（2）SDO:Service Data Objects，主要用来简化数据访问，并且提供一个统一的数据访问模型。

　　（3）Work Manager and Timer：主要用来提供在Servlet与EJB中处理多线程与定时器的功能要求。

　　（4）Enterprise Metadata Discovery，主要用于提供JCA（Java连接器体系）下元数据的发现功能。

　　关于更多的信息可以访问BEA和IBM的官方网站：

　　BEA: http://dev2dev.bea.com/wlplatform/commonj/

　　IBM:http://www-128.ibm.com/developerworks/library/specification/j-commonj-sdowmt/index.html

　　2.Service Component Architecture

　　SCA(Service Component Architecture)是一个基于SOA而实现的新技术，主要是用来简化应用程序的开发。使用SCA，客户能够更容易的创建新的服务或者是转换已存在的服务，以达到服务重用的目的。这样可以更加快速的适应业务需求快速变化。SCA技术极大的减少了与应用程序编程语言相关联而造成的复杂性，提供了一个良好的方法来统一这些服务，而不用关心使用的编程语言以及运行的平台的不同。SCA提供了一个与技术无关的方式定义接口、实现和引用的模型。

　　更多的信息，参见这里： SCA specification page.

　　3.Service Data Objects

　　Service Data Objects(SDO)被设计来简化与统一应用程序处理数据的方式。使用SDO，应用程序的编程人员能够以一种一致的方式访问和操作从异构数据源中获取的数据，如下图所示，这些数据源包括关系数据库，XML数据源，Web服务和企业信息系统（EIS）。比如BEA的产品Liquid Data的基础技术之一就是SDO。更多关于SDO设计目标与构架的信息，请参考“Next-Generation Data Programming: Service Data Objects”。

　　SDO是一种离线数据集。与微软的ADO.NET 2.0 Dataset和Datatable，以及CachedRowSet都是类似的数据处理技术。在Java应用程序中使用SDO相当于在内存中建立一个XML形式存在的数据库。如下图所示，当客户端请求数据源的数据时，先是将请求发送给SDO中介程序，可以从异构的数据源中取得所需要的数据，组成一个以XML形式存在的Data Graph，然后传回给客户端，客户端可以对这个Data Graph可以进行相关的操作如查询，删除，查询，更新等，然后将这个经过客户端更新过的Data Graph再回传给SDO中介程序，由SDO中介程序负责将客户端执行的操作同步到数据源中去。

　　SDO中对数据进行处理可以使用静态（强类型）编程模型和动态（松散类型）编程模型。静态编程模型类似于JavaBean中的get/set方法，动态编程模型采用一种类似HashTable中对象的查找方法，比如我们在取得一个数据对象（DataObject） 的“name”属性的值时，使用静态方法可能会是这样的，dataObj.getName(),而动态编程模型则是dataObj.get("name")。使用这两种编程模型，既可以保证编程的简单性，而且不会失去工具程序与框架(framework)程序设计与实现时所需要的动态编程的特性。

　　SDO1.0规范最初由BEA和IBM联合制定发布，SDO规范的最新版本是2.01版，2005年11月发布，现在Java程序和C++程序都可以使用SDO规范，越来越多的公司也加入到了SDO规范的制定中，包括SAP，Oracle，Sybase，Siebel等许多知名的大公司，同时也在他们的产品中加了对SDO的支持，更多的信息请参考：SDO specification page。

　　4.Work Manager and Timer

　　由于J2EE规范的限制，在Servlet和EJB中执行用户自定义的多线程并发与定时器服务一直以来是困扰J2EE开发人员的一个大问题。现在CommonJ项目中的Work Manager和Timer规范将是解决这些问题的一个优秀方法。

　　Work Manager规范为在应用服务器中支持并发任务的执行提供了一些简单的接口。通过这些接口，我们可以方便的在Servlet和EJB中执行并发的计划任务。有了多线程并发的支持，我们的服务端程序可以取得更高的呑吐量，并且缩短服务端程序的响应时间。在具体应用中，应用程序主线程将一些可以并发的任务分解为多个子项，将这些子项提交到Work Manager去并发执行，主线程处于等待状态， Work Manager将任务子项处理完毕后，主线程得以继续执行，并处理任务子项所返回的结果。其具体过程如下图所示：

　　关于Work Manager规范请参考这里，JSR 237: Work Manager for Application Servers。

　　定时器(Timer)规范提供了一个在Servlet和EJB中设置定时器的简单方法，同时允许在Servlet和EJB中响应定时器的提醒。该规范提供了一个在不能或者不方便使用java.util.Timer环境中使用定时器功能的替代方法。

　　现在在WebLogic Server 9.0中已经提供了对Work Manager规范的支持，在WebLogic Server 7和8中需要使用该项功能请参考这里，xcommonj-work。

　　关于Work Manager和Timer规范的更多信息请访问这里：Timer and Work Manager for Application Servers。

　　5.Enterprise Metadata Discovery

　　J2EE 是一个用于构建和管理企业类应用和解决方案的丰富环境。

　　J2EE为企业的各种应用提供了丰富的解决方案。目前，随着SOA 的出现，越来越多的企业开始在 J2EE 环境中部署 SOA 解决方案，但是只有对他们现有的“IT资产”“开启”服务支持（service-enable），才能获得 SOA 实现业务自动化的所有好处。BEA 与 IBM 在这个基础上进行规范合作，以支持集成的“最后一米”的更具生产效率的开发和部署。“Metadata Discovery and Invocation Specification for J2CA”是 BEA 和 IBM 发起的一个跨行业的计划，并受到相关的适配器供应商和应用供应商合作伙伴的支持。这个新的规范提供管理这种“最后一英里”的一种标准方式以及无缝的设计期体验，从而为客户在服务支持其现有 IT 资产方面带来重大的生产率提高。

　　独立的研究表明，集成解决方案或 SOA 实现的主要成本都源自集成的“最后一英里”（即从集成应用到遗留系统的连接）。适配器的采购、支持和服务成本（或者没有现成的就需要自己构建）直接影响集成解决方案的 TCO 和时间价值。

　　关于这一点的原因有很多，但是都归结到行业中的一个基本结构问题。基础设施供应商没有足够的规模来降低成本，也就不能为所有终端系统的一个子集构建丰富的、高质量的适配器。基于伙伴化的行业可以解决这些问题，但是还是存在标准不够成熟的等问题。

　　客户要求有丰富的工具，用于服务支持和将后端应用功能连接到 SOA 中。但是目前还没有支持这类互操作性工具的 Java 标准，所以供应商只能通过为开发人员构建专有扩展（proprietary extension）来解决这个问题。但是这会导致平台和适配器供应商的解决方案之间互操作性困难，一般利用昂贵的一次开发或现场咨询来解决。总之，最后成本还是转嫁到了客户头上。

　　Enterprise Metadata Discovery 规范的目的是为适配器解决标准的丰富工具接口问题，从而挖掘集成行业的潜能，以更低的成本向更多的终端系统交付更高质量的适配器。适配器供应商可以集中精力构建更多更好的适配器，而不用担心专有扩展的互操作性。基础设施供应商可以集中精力构建更好的平台和更好的开发体验。而应用供应商和其他 ISV 可以构建他们自己的“最后一英里”组件，确保一个标准的实现将会同时满足运行时和设计时互操作性的要求。因此，任何适配器产品都可以无缝地插入到任何基础设施供应商的 J2EE SOA的实现中，同时提供良好的端到端的运行时行为和还能提供开发人员的生产率。

　　对最终用户的所取得的好处是，能以更低的成本获得更好的高可用性和高质量的适配器。这样现有 IT 资产可以更加容易得到服务的支持，从而降低 TCO 并改善 SOA 实现的时间价值。而且端到端解决方案中的每个组件将被构建成支持规范并不用进行专有的一些扩展，从而也减少供应商各自为战的这种局面。