【IT168 专稿】
从早期联合国贸易促进和电子商务中心（UN/CEFACT）在信息交换与核心构件表示、处理及操作技术（业务参考信息模型工作组，BRIM WG）上做出努力开始，历经近四年的开发，内容装配机制（CAM）规范1.1版于2007年6月1日通过结构信息标准化促进组织（OASIS）审核，成为OASIS标准之一。
当前的CAM版本为数据服务验证——特别是基于XML的数据处理提供了定义模板。 虽然现有使用W3C XSD schema、命名空间、XSLT和其它诸如Schematron和XMLBeans等工具的技术已经存在一段时日，它们仍有许多以开发人员为中心的潜在的设计问题。CAM的设计初衷是为创建稳定的服务接口提供一个更灵活、容错率更高，并且兼容性更好的方案。特别是，CAM模板提供了所见即所得（WYSIWYG-style）的XML结构映射，和按上下文驱动规则分组的构件（服务）及其内容。
为什么这一点对SOA数据服务很重要呢？应用面向服务的设计方法时，Web服务趋向于提供与预定义（标准）的schema结构相匹配的信息。虽然最初认为这已经足够，但在实际实现中schema结构可能只有一个空阔模糊的外框。
另外，XML Schema语言是以程序员为中心的。开发人员感觉不错的schema代码，却不一定适用于需要响应业务上下文标准的灵活的信息接口。比如，业务分析人员和一般职员就不能完全理解XML Schema的结构定义。
在具体的SOA实现中，稳定可靠的服务性能是客户程序的首要考虑内容，并且经常是必需的。这样，服务接口内容将直接影响到客户对服务质量，以及支持和使用相应服务所需付出的代价的认识。CAM技术允许业务和数据分析人员控制甚至改变数据服务接口，以此提高服务性能。图1说明了CAM模板是如何在企业圈中实现共享的。
图1 一个典型的CAM实现过程，其中分析人员可以优先于发布模板决定规则和内容
CAM平台的另一个作用是，它提供了便于服务版本化和重用的机制，而这些服务单元的治理（版本化与重用）正是软件维护人员的工作范围。这些机制是用来解决以往基于schema的软件对事务处理格式要求过于严格的问题。
总的来说，CAM可以看作是应企业中业务与软件开发对可共享的开放公共机制的需求产生的，同样的机制也适应于实现厂商产品与数据服务集成所需的内部系统互通。
一个实例：Amazon.com Web服务（AWS）
我们可以通过研究已稳定运行超过三年的AWS平台学到很多东西。Amazon的Web服务提供了对Amazon.com网站几乎所有产品、价格信息的访问支持。
使用这些服务的AWS的业务伙伴在确定结果之前必须先检查一遍业务交互流程。他们必须了解各种AWS响应信息构成与打包的细微差别。这不仅仅是看一下schemas规则那么简单。Amazon采用了版本自助服务的方法：请求语法本身包含了对版本标志的请求。
由于Amazon一直在努力改进其内容模型，所以他们几年前就已经开始支持版本请求了。他们获得了不错的柔性，但支持服务的负担也越来越重。图2展示了AWS的产品请求处理机制与相关的控制应用和响应细节的上下文规则的整体布局。
图2：AWS事务处理整体结构
Amazon使用schema结构对大范围的产品提供支持，包括书籍、DVD、玩具和电子产品等。每种产品都有自己的信息模型（已在图中明显列出）。对某种产品代码的查询将返回包含许多部分的整块XML结构。这些结构的一些细微差别大量体现在不同结构块中的XML元素标记和不同的关联元素中。不仅如此，每种商品都有诸如单价、库存级别、除Amazon.com本身之外的下游供应商的新的和可用的商品，以及供应商等级的信息。
Amazon用这些信息筛选出部分商品，放在列单显要位置上作为热卖产品，并贴上“最低价”的标签。然而，最值得注意的地方是，关于返回客户请求的信息基于负载峰值的实时动态优化。随着Amazon.com服务器负荷加重，他们开始通过减少返回的检索内容来减轻服务处理的负担。
通过以上简短的研究，我们可以量化以下的上下文驱动：
- Amazon自己的优先销售与价格技巧
- 产品类型随信息结构变化
- 新部件与内容的版本控制
- 即时的性能优化
- 信息与内容价值的关系
显然W3C schema和命名空间机制都不提供对这些上下文相关行为的支持。你能看到的只是可能出现的整体结构的总体布局。
分析完这个交互实例，我们再看一下CAM如何更系统地满足这些需求。
简化复杂的信息结构
整合到CAM中的功能之一便是上下文感知技术。UN/CEFACT为促进上下文技术发展而开发的核心组件技术规范（CCTS）在这里得到了应用。这意味着你可以根据上下文驱动从内容内部，或者用外部声明并传送到CAM进行处理的参数来改变CAM模板行为。
当在有组件变动的结构中应用上下文技术时，CAM可以从不同的技术层面提供支持。其中最重要的一项技术是可以用多个主结构模板作为处理内容的基本参考。另一项技术则是包含结构区域或调用子模板。然后，可用这项功能根据上下文对结构部件进行增删，或从不同的结构元素中进行选择，具体操作取决于内容本身。
AWS的CAM模板的默认结构规则如下：
显然以上各方面都适用于Amazon.com AWS XML响应和结构，并且可为每种商品（比如DVD、书籍、玩具、服装和电子产品等）添加可引发相应商品类型规则的详细规则。这使集成到系统的客户无需经过反复试验便可掌握使用模式。 这不仅避免了初期测试和开设时的精力浪费，也大大简化了版本变更流程（下面将谈到这一点）。
继续结构简化的概念。结构中经常有重复的模式，仅仅由于其在结构中出现的位置不同而在使用模式上的稍有差异。 由于W3C schemas缺少上下文驱动机制，实现人员必须在schema中手动重复同一条结构代码来实现每个区域的内嵌变化。这个过程极大地限制了服务接口的灵活性与柔性，更不利于结构部件的重用。最近为PESC学生贷款申请schemas而开发的CAM模板就是一个详尽的例子。
图3显示了CAM模板结构概念图与RAW模式复杂性的对比。由于对事务交互文档视图的支持，业务数据分析人员也可以使用CAM模板。这对schemas非常重要，因为高等教育机构需要使用这些schemas交换学生申请信息。信息本身由于海外与本地学生的不同有复杂的细微差异，并与美国的信息实践和表现有关。
图3 PESC学生贷款schema概念组件
地址、负责人与联系方式构件在schema结构中重复出现。由于需要手工创建各种区域和不能定义可供上下文规则选择处理的可重用构件的限制，这个模式会变得非常模糊。下面的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种以上可选结构。
