经过近四年的开发，CAM（内容组装机制）1.1版于2007年6月1日获准成为OASIS的标准。这项开发可以追溯到早期UN/CEFACT（联合国贸易便捷化与电子商务中心）为消息事务处理以及核心元件、操作和处理（BRIM WG）所做出的努力。

　　目前发布的CAM提供的模板能够定义验证数据服务，尤其是基于XML的事务处理。虽然采用W3C XSD schema、命名空间、XSLT或其它工具（如Schematron和XMLBeans）的现有技术已经存在一些时日，但它们提供更多的是以开发人员为中心并且可能比较脆弱的设计选项。CAM的初衷就是为了提供一种更加敏捷、容错能力好、适应性强的方法，以帮助建立更强健的服务接口。特别值得一提的是，CAM模板提供了WYSIWYG式的XML结构映射和情景驱动规则，选择组件（和服务）及其内容。

　　为什么这一点对SOA数据服务这么重要呢？当采用面向服务设计方法时，Web服务会提供与预定义（标准）模式结构匹配的信息内容。可能最初会认为这些内容足够了，但在具体运作中会发现该模式可能只能够提供一个泛而空的框架，而缺乏实际的实施细节。

　　此外，XML Schema语言以程序员为中心。开发人员可能觉得模式代码不错，但这并不一定对敏捷的、视业务情景标准而反应的信息接口很有帮助。例如，业务分析师和普通员工就无法有效地共享XML Schema的定义。

　　在典型的SOA实施中，服务行为的一致性和可靠性受到青睐，客户项目也通常提出这样的要求。所以，服务接口内容可能会直接影响支持和使用这些服务所需的服务质量理解和努力水平。CAM是一项旨在改善这些方面的技术，它允许业务和数据分析师影响甚至改变数据服务接口。例如，图1描述了CAM模板如何在实际企业中共享。

 
　　图1：CAM典型的传送过程——分析师在模板发布前可以添加规则和其它内容

　　CAM平台的另一特征在于提供了便于服务版本控制和重新利用的机制，这通常是软件支持人员负责的服务治理区域。基于模式的软件很容易受到事务处理格式微小变化的影响，这些机制旨在克服由此产生问题。

　　总而言之，CAM可以看作是满足了提供开放、公共机制的需要，这些机制可以让组织内部业务和软件开发层面的所有参与人员实现共享。这也将同样适用于集成供应商产品和数据服务时内部进行的系统交换。

　　实例：Amazon.com Web 服务（AWS）

　　在业界声誉卓著的AWS平台已经运行三年多了，研究这个平台能了解许多信息。Amazon的Web服务提供的定价和产品信息，几乎与顾客在Amazon.com网站上获得的信息一样多。

　　和这些服务接口的AWS合作伙伴在获得一致的结果前，要不断地重复事务处理过程。他们需要学习AWS回应消息如何创建和打包的细微差别。这不是只看一下运作模式就可以了。Amazon采用自我版本控制的方式，在这种方法中，请求的版本标识包含在请求本身的语法中。

　　Amazon不断地改变内容模型，结果他们需要支持几年前的版本请求。这样具有灵活性，但同时也增加了支持的压力。图2显示的是针对产品请求以及控制使用和回应细节的相关情景规则的AWS事务处理整体布局。

 
　　图2：AWS事务处理的整体组件布局

　　Amazon采用一定的模板结构，这些结构支持的产品范围很广，包括书、DVD、玩具、电子产品等。每种产品种类都有不同的信息模型（具体如上图所示）。对某个范围的产品代码查询将返回一个由不同部分组成的XML块。这些结构的一些细微差别大量体现在不同结构块中的XML元素标记和不同的关联元素中。不仅如此，每个产品都包括了价格、存货量、Amazon.com之外的下游供应商的全新和二手产品以及这些供应商评级的信息。

　　当然，Amazon会对这些信息有所选择，将某些产品优先靠前，让列表看上去更具有购买引导性，并使用“最低价”标签。然而，发生在为请求者服务的信息最有意思的变化，就是优化一天中不断发生的高峰负荷。随着Amazon的服务器面临的压力增大，公司通过减少查询的返回内容，从而降低服务处理的负担。

　　l 根据这项研究的结果，我们将情景驱动进行了如下量化：
　　l Amazon自身偏好的销售和定价技巧
　　l 信息结构中产品种类的变化
　　l 新特征、新内容的版本控制
　　l 不断的性能优化
　　l 信息成分和内容价值的关系

　　显然，W3C模式和命名空间机制都不支持这些情景行为。你看到的是可能发生的整体结构的总体布局。

　　研究了典型的接口实例之后，我们再来看看CAM如何用更系统的方法来满足这些需求。

　　简化复杂的信息结构

　　CAM一开始就设计了许多功能，情景意识(context awareness)是其中的一项功能。这是UN/CEFACT对核心组件技术规范（CCTA）进行研究的结果，其中CCTA的基本观点是利用情景决定使用方式。这也就是说，你可以根据情景驱动改变CAM模板的行为，可能是改变内容本身，也可能是改变外部的声明并传递到CAM过程的参数。

　　当将情景运用到组成部分差异较大的结构时，CAM提供不同技术的支持。最明显的就是CAM拥有多个主结构模板作为处理内容的基本参考。接下来的功能则是将其纳入结构中的某一部分或者调用子模板。随后紧接着是根据情景删减结构的部分，或者根据内容本身选择不同的结构元素。

　　以下是AWS中CAM模板的默认结构规则：
 
　　很明显，这些内容都可以应用到Amazon网站的AWS XML回应和结构中。而且，还可以添加与产品（DVD、书、玩具、衣服、电子产品等等）相关的具体规则，不同的产品引发不同的规则。接下去要做的就是提供进程计划，为与你系统集成的合作伙伴澄清使用方式，而无需尝试错误式学习曲线。这样不仅略去了测试和建立初期的猜想工作，也大大简化了版本控制过程（在下面章节中讨论）。

　　随着结构简化概念的深入，结构中通常存在重复的模式，这些模式由于在结构中发生地点不同而有细微的差别。W3C模式不能采用情景驱动机制， 必须手工重复整个模式中的每个结构代码，然后手工改变联机中的每一部分。这个过程严重限制了服务接口的敏捷性和灵活性，而且阻止了结构组件的重复利用。具体例子可见在学生申请贷款中使用的PESC模式，这是CAM模板最近开发的模式。

　　图3给出了CAM模板结构的概念视图，并说明其与原始的复杂模式有什么差别。CAM模板支持这类事务交换的文档视图，这样企业的数据分析师就能加以采用了。这对这些模式尤其重要，因为它们可以被需要交换学生申请信息的高等教育机构采用。信息本身的差异很复杂，同时美国在处理和表征海外学生与国内学生的信息时也有很大不同。

 
　　图3：PESC学生贷款模式的概念组件

　　在模式结构中，Address、Sponsor、Contact等会不断出现。然而看看原始模式就会发现，由于采用手工编辑创建了不同的组成部分和限制条件，这些概念变得非常模糊。手工创建的限制条件阻止了重复利用（引用）功能的定义，而利用情景规则可以有选择地修改这些功能。下面记录学生信息的CAM模板片段给出了合并引用功能的简便方法。

　　<TransmissionData>
  <DocumentID>%DocumentID0%</DocumentID>
 <CreatedDateTime>%2006-05-04T18:13:51.0Z%</CreatedDateTime>
 <DocumentTypeCode>%Request%</DocumentTypeCode>
 <TransmissionType>%Original%</TransmissionType>
  <Source>
   <as:include>pesc-organization.xml</as:include>
   <NoteMessage>%NoteMessage%</NoteMessage>
  </Source>
 <Destination>
   <as:include>pesc-organization.xml</as:include>
   <NoteMessage>%NoteMessage%</NoteMessage>
  </Destination>
 <DocumentProcessCode>%TEST%</DocumentProcessCode>
 <DocumentOfficialCode>%Official%</DocumentOfficialCode>
 <DocumentCompleteCode>%Partial%</DocumentCompleteCode>
 <RequestTrackingID>%RequestTrackingID0%</RequestTrackingID>
 <NoteMessage>%NoteMessage14%</NoteMessage>
</TransmissionData>

　　CAM采用这些技术的目的在于根据使用模式的情景定义多层结构、选择结构模型。因此在上文给出的例子中，利用CAM结构的选择规则可以改变源及目的结构，以符合模型使用中的特殊情况。注意，每个组织的定义长52行，且包含10个以上的结构选项。

　　版本控制和变化控制

　　版本控制除了带来业务情景的参数管理，还引起了自身的挑战和需要，这些挑战可以概括为：

　　l 如果模式版本改变，我们如何确保其不破坏合适的验证？
　　l 规则变化如何快速适应产品环境？
　　l 如何开发用户情景驱动版本控制，如何支持子组件的重复利用？
　　l 如何通过提高漏洞修补过程的透明度来加快并自动化测试发布周期，如何改变增量，从而加快测试进程？（若要减慢进程又该怎么办？）

　　CAM在其模板结构内有不同的组成部分对应结构、规则和验证扩展。这样的透明度对改变增量尤为重要。

　　W3C模式中这三个方面在语法上密不可分。也就是说，在模式版本中利用文本DIFF等软件工具得到的结果是多方混合的，可能不容易区分。另一方面，CAM中的DIFF会独立展示各个方面，从而使行为决策变得简单。行为决策往往取决于那些变化的影响，并考虑变化是紧急的还是温和的或者是一项新的特征。

　　而且，CAM模板采用XPath表达式表示结构中规则与目标选项之间的关联。这样就非常灵活，因为可以标识为子元件路径，而无需描述全路径。由于需要不断匹配链接，就可以使结构在发生很大变化的同时不影响应用规则。

　　CAM有一种强大的功能，即支持外部代码清单——在事务处理中与特定代码值相关的多组代码值。常见的例子有：合法的美国州代码、产品种类目录、货币代码、国家代码、度量衡等等。OASIS制定了一套客观的表述方法，叫做“Genericode”，用以处理这些信息清单。Genericode本身是一种抽象的格式。在CAM模板中使用Genericode需要提取出代码值，然后将其存储在最佳的布局中，以实现快速查找。CAM支持相应查找表的嵌入式转换和表征。

　　CAM作为SOA实施的一部分

　　图4表示的是利用CAM处理器在SOA中数据服务层部署的示例。该环境采用了jCAM（CAM的java 开源实现方式）技术，为与SOA相关的典型交互方式提供了三种不同的部署模式，包括Web服务、B2B和独立的本地模式。

 
　　图4：CAM部署和使用模式的示例

　　通常供应商会将现有的数据服务嵌入自身的转换方法和传输方法。CAM处理器可以作为独立元件包含其中，也可以通过急修服务包含其中。采用CAM开放的标准模板的好处在于规则和结构的定义可以在所有的合作系统中免费共享，供应商的转换工具则需要配安装专用的软件工具。同样，内部转换规则通常包括个体规则检验，以及与后台数据库的链接，用于实现无法共享的查询和评价。可以通过分离行业内容和CAM模板中的结构检验解决这一难题。

　　而且，使用人员可以利用开放源码开发工具帮助发展、集成合作系统。因此采用jCAM技术能使工作变得更加方便，因为它支持Java APIs标准版，也支持XML DOM指针的使用，来交换事务内容和模板，而无须增加流程开销。实现jCAM开放源码也包括基于Eclipse的编辑工具，如图5所示。

 
　　图5：运行中的jCAM Eclipse编辑工具

　　Eclipse编辑工具允许本地主机独立使用CAM模板，且支持SOA的实现。在处理实际的SOA交换事务过程中采用SOA系统提供的传输方法，可以省去不少麻烦，节约大量时间。对内容进行预测试评价，能使业务分析师和软件开发人员更快地微调交互作用，而不必等待消息周转。

　　采用无效的交易结构有时会得到混淆不清或者彼此矛盾的结果，此时合作伙伴的查询需求也降低了。大多数时候，这些无效交易就在合作系统中简单地“消失”了，服务请求者只得一点点的反馈内容或者根本得不到反馈。而支持员工则需在网站内部找出交易问题，并对其进行诊断。这就表明，CAM模板能对一组扩展的先决条件进行预测试，因此提供CAM模板能使SOA和外部合作伙伴的集成变得非常便捷。

　　CAM模板也适用于SOA传输进行自我封装的过程。例如，服务型解决方案可能依赖采用SOAP headers和 SAML profiles方式的消息。我们可以建立CAM模板，以允许合作伙伴对传输配置进行预测试，检验profiles和header内容。同样，对于SOAP和ebXML的封装结构（包括角色、行为、处理细节以及CPA ID值等扩展内容），也可以利用CAM模板预先对其格式进行检查。

　　CAM建模方法的另一好处在于广泛使用引用（include）和查找（lookup）模板，可以在SOA环境中实现重复利用，并且非常敏捷。合作系统可以通过常用的查找和引用功能，实现快速更新和改变，然后应用到本地系统中。
 
　　结论

　　OASIS CAM技术标准为SOA数据服务层的使用人员提供了新颖而重要的便利条件，而之前在公共分散式数据包中无法获得这种便利。尤为重要的是，该技术能使业务分析师参与事务交换的创建过程，以及业务规则的记录和实施过程，而不是纯粹地依靠软件开发人员。这就缩短了测试和周期集成的时间，加快应用速度。

　　实现CAM操作规范中的jCAM开发源码可以提供运行部署引擎和可视化交互编辑工具Eclipse，用于发展和测试模板。Eclipse编辑工具使行业域小组能采用相同的方法联合开发事务和规则，共享资料和模板。jCAM编辑工具产生的规则和结构报告能将传统的通常由也业分析师创建的表单和表格保存到镜像站点。

　　SOA能否获得商业成功取决于其提供的业务便利和商业价值，实现SOA和支持SOA实施需要付出很大努力。因此，OASIS CAM模板提供了行业标准技术，及时针对关键的服务便利需求提供相当可观的改进措施，以构建、测试、部署和支持面向服务的解决方案。