【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种以上可选结构。
版本控制
版本控制本身的困难使其从业务上下文参数管理中分离出来。这些困难可以总结为如下几条：
- schema版本变化后如何保证不会破坏本地验证？
- 在生产环境下如何快速适应规则变化？
- 怎样开发用户上下文驱动版本控制并支持子构件的重用？
- 如何通过提高故障修正流程的透明度和公开改动量来缩短并自动化版本测试周期，提高测试流程的速度。（能否提供对回归测试的支持？）
CAM在模板布局中有关于结构、规则和验证扩展的详细区域。在公开改动量的情况下这种透明度尤为重要。
在W3C schemas中这三个方面在语法上是混在一起的。这表示在不同的schema版本中使用软件工具(比如Text DIFF程序)会得到混乱的结果。 然而，CAM模板上的DIFF程序却可以将各方面单独列出来，这使得决定行为时会变得很简单。这个行为决定取决于这些改动的影响，以及它们是否重要，是否良性的，是否是可以考虑的新的功能部件。
CAM模板使用XPath语句描述结构中规则与目标物的联接。这些语句非常灵活，因为它们可以直接标记子元素路径，而不需要知道完整路径。这使得结构改动时可以不对规则产生任何影响，因为这些联接在改动后仍然匹配。
CAM模板的一项特别强大的功能是其对外部代码集合（事务处理中某个代码值相关的外部代码允许值的集合）的支持。比如美国各州代码、产品目录、货币代码、国家代码及度量衡等。OASIS开发了一种叫做Genericode的中性语义表示法处理这种码表。{0>Genericode itself is an abstract format.<}0{>Genericode本身是一种抽象的规范。要在CAM等工具中使用，必须赋予代码值，并将其储存在优化的布局中，以实现高速检索。CAM对响应检索表的转换与表达提供内置的支持。
CAM作为SOA实现的一部分
图4展示了在SOA环境中用CAM处理程序部署数据服务层的一个例子。这里使用jCAM（CAM的Java开源实现），针对与SOA相关联的典型交互提供了三种不同的部署模式，包括Web服务、B2B和独立的本地模式。
图4 CAM部署与应用模式样例
一般实现人员会根据他们的传输方式将现有的数据服务嵌入到自己的转换方法中。这其中包括可用做单独组件或调用服务的CAM处理程序。使用CAM开放标准模板的好处是，可以在第三方系统中自由共享规则与结构定义，当然厂商使用转换工具前需要先安装专有的软件工具。与此相似，内部转换规则却通常包含专用规则检查，并需连接到后端数据库对非共享的内容进行检索和评估。解决办法是将企业内容与结构检查分开整合到CAM模板中。
并且，实现人员可以用开源工具协助开发和集成第三方系统。jCAM实现为此提供了方便，因为它支持标准的Java API，并可以使用不会增加处理系统开销的XML DOM 指针交换处理内容和模板。如图5所示，jCAM开源实现也包含基于Eclipse的编辑工具。
图5 运行中的jCAM Eclipse编辑工具
Eclipse编辑器可以在本地独立运行CAM模板以支持SOA实现。通过SOA系统提供的传输方法可以在实际进行SOA业务交易前节省大量无效工作和时间。 对内容进行预测评估可使业务分析人员和软件开发人员更快速地进行交互微调，而无需等待信息周转。
这同样也会减少因使用无效的事务结构而返回混乱或冲突结果时第三方维护人员的查询请求。更常见的是这些无效事务在第三方系统中消失了，很少甚至没有服务请求方所需的反馈。这样，维护人员就需要在系统内部定位与分析问题时花费一些时间。这说明如果CAM模板可对大量的先决条件进行预测试，就能方便第三方SOA系统的快速集成。
这同样适应于SOA传输包封本身。比如，面向服务的解决方案可能依赖于使用包含SAML（安全断言标记语言）文件的SOAP（简单对象访问协议）标头的信息。使用CAM模板可以允许第三方为这些文件和标头内容进行传输设置的预测试。同样，对SOAP和ebXML(电子商务全球化标准)包封结构（角色、行为、事务细节及扩展，比如CPA ID值）的编排格式可以用CAM模板进行预检。
CAM模板另一个优点是引用和检索模板的广泛应用。这有利于SOA环境下的重用和灵活性。第三方系统可以在对库进行检索和引用时获得即时升级和更新，并应用到本地系统中。
结论
OASIS CAM技术标准为实现人员提供了极大的便利，使之获得了以前不可能在公开发行软件包中包含的SOA数据服务层。其中，最重要的是让业务分析人员参与到构建事务交互、文件编制和实现业务规则集的流程中，而非以往仅仅依靠软件开发人员。这将缩短测试和集成周期，获得更快的实现速度。
CAM规范下的jCAM开源实现为开发和测试模板提供了运行时部署引擎和交互可视化Eclipse编辑器。 Eclipse编辑器促进了企业领域共同开发事务与规则并共享文档和模板。使用jCAM编辑器产生规则和结构与传统业务分析人员制作数据表格形成鲜明对照。
SOA在商业上的成功取决于其对商业活动提供的便利和价值减去为此付出的代价。因此，OASIS CAM模板提供的企业标准技术能满足关键服务便利性的需求，在预定时间内构建、测试、部署并支持面向服务的解决方案。
