摘要
现在的Web应用程序，特别是门户程序，正在日益变成内容驱动的。这引出了一个复杂强大的Web内容管理系统（WCMS）的开发。它们有助于Web内容的自动创建、管理、评论、标记、转换、发布、维护和修改。通常这些系统支持很多不同的内容类型和格式；然而，大多数系统缺乏对一种重要类型——应用程序数据的支持。

现在的Web应用程序，特别是门户程序，正在日益变成内容驱动的。这引出了一个复杂强大的Web内容管理系统（WCMS）的开发。它们有助于Web内容的自动创建、管理、评论、标记、转换、发布、维护和修改。通常这些系统支持很多不同的内容类型和格式；然而，大多数系统缺乏对一种重要类型——应用程序数据的支持。

本文使用现实生活中的例子介绍了商业对象的概念，文中将商业对象看成是高度结构化的可发布内容的特殊类别。从这个观点来看，有很多相同的需求要求使用WCMS的发布能力。不幸的是，商业对象也有很多独特的特征，这使得大多数WCMS不能以开箱即用的方式发布它们。我将建立一系列标准作为理想解决方案的基准。

本文描述了几种方法，可以使用这些方法来从已有的WCMS中改进商业对象的创建、管理和发布，并且强调了这些方法的优势和缺点。然后描述了复制方法的实现，该方法利用BEA的XML  Beans的功能来提供一种方便、可靠且可伸缩的解决方案，并且不依赖于任何特定WCMS的专有功能。该方法的实现格式是商业对象发布服务，这种格式本来是为Documentum和WebLogic开发的，但是很容易进行扩展，使之与不同的WCMS和Web应用程序平台协同工作。

定义高度结构化的内容

结构化内容是那些日常使用但是缺少一个简明和公认定义的概念中的一个。在Web上搜索这样一个定义不会产生任何有意义的结果；令人惊奇的是在四大主要CMS供应商的网站上的搜索结果也是一样。

CMS观点
大多数CMS供应商试图通过将结构化内容和非结构化内容或者包含文本、图像等没有清晰定义但是普遍可访问的元数据的普通文本对比来定义结构化内容。与之相反，他们将结构化内容看作包含诸如作者、主题、地理、内容类型等元数据的同样的文件。大多数企业级CMS包使得信息架构师可以定义具有丰富内容类型的系统，每一种内容类型都有自己的属性集合和用于获取、维护和管理该元数据的工作流程。

CMS最后将所有的内容和可用的元数据一起发布到一个门户，在本文中我将门户定义为动态地为用户提供发布内容的Web应用程序。门户使用元数据在适当的时间为适当的用户分类、链接、查找、个性化并分发加了标签的内容。

结构化程度不够
从门户观点来看情况有所不同：结构化内容在提交页面的时候它的表现方式和使用方式很不一样。这使得我们可以区分半结构化内容和高度结构化内容。半结构化内容，或者说就是包含相关但松散类型关系元数据的文件。高度结构化内容，或者说诸如Navigation Nodes、Products、 Special Offers等的商业对象，具有很多具体的强类型检验属性。前者基本上就是CMS世界中所认为的结构化内容。

这些类型之间的主要区别是在半结构化内容的情形中，元数据只是装饰它——这可能会对何时找到特定条目或者如何提交条目产生影响。如果丢失了部分甚至是全部的元属性，或者拥有无效值，但内容仍然是正确的，只是它不能在所有适当的位置显示。而商业对象必须提供所有的属性并且常常对它们的值有严格的限制（例如，Coupon.Discount必须是一个1到99之间的正数，SpecialOffer.EndDate必须是一个未来的有效日期等）。商业对象也能关联其他商业对象，例如Coupon扩展出SpecialOffer，它可以表示属于一个Brand的Product等。有些属性可以是复杂类型或者相关的对象等。Recipe就包含一个RecipeIngredients的列表，该列表由Product、Quantity和UnitOfMeasure所组成。当通过一个门户作为依赖者和父对象而被发布或者不发布来提供这样的对象的时候，能够遍历这些关系并维持它们的完整性是很必要的。

换句话说，高度结构化的内容表示条目将在应用程序代码中变成对象或在数据库模式中变成一个或多个表的对象。需要重点强调的是，本文中讨论的商业对象是严格的内容，它们只能由内容提供者创建和修改，对于所有的门户用户都是只读的。发布的比喻不适用于用户可修改的对象，诸如User Profile、Shopping Cart、Blog等。这些对象类型不能被看作内容，它们不在本文讨论的范围之内。

商业对象的例子
本部分基于两个最近实现的例子阐明高度结构化内容的概念和它在门户应用程序中的角色。

Food和Nutrition门户
该门户的对象是美食家。它包含了关于食物、不同烹饪方法和相关事宜的广泛内容。它从很多投稿者和食品制造商成员那里接收内容，用来提升他们的产品知名度。它使用一个高级的CMS实现来管理所有的内容并且协调分散的提交和发布。除了诸如商品、广告、特征、商业活动等的半结构化内容之外，食品制造商还需要能过发布很多商业对象的功能。这包括他们可以加入到产品目录中的产品、品牌和包装选项；配方表示的进入到配方框中的产品；提升产品知名度的特殊提议等。图1显示了一个简化的域对象模型。

图 1

系统支持浏览和搜索产品目录、配方框和特殊提议片断的各种方式。它具有很强的在配方和特色产品之间以及提议和合格产品之间导航的能力。商业对象显示页面不止是简单的显示信息，而且还要用下列几种的方式处理信息：

·         建立和验证对象间的横向链接。

·         显示配方的时候为用户提供度量单元转换能力。

·         让用户可以计算配方的收益和价格 。

·         让用户可以计算coupon 页面上节约的资金。

当发布、更新和作废商业对象的时候，系统除了要服从要求的工作流程之外，还应该验证并维护复杂引用的完整性规则，例如：

·         如果Special Offer引用了一个未发布的Product，不要发布它。

·         如果Recipe引用了一个未发布的Retail Product，不要发布它。

·         如果Members Product 有任何发布了的Retail Products，不要取消其发布。

·         如果Product用作了任何Recipe中的一种成分，不要取消其发布。

·         重新发布任何商业对象时，保留所有以其为目标的关系。

系统应该赋予其成员对其包含商业对象在内的内容的完整控制权。除此之外，成员应该能够以相关的半结构化内容（诸如广告等）和显示商业对象的页面作为目标。

全局知识存储库
该存储库是一个提供健康和生命科学系统化信息的信息门户。它集中了来自不同捐献者或者信息源的广泛内容，并将其提供给从一般公众到研究员和健康专家的用户。所有内容的精确性和相关性是极为重要的。信息源是很多组织内部的管理单元，这些单元在门户信息域中的特定信息领域是公认的权威。他们应该能够在那个领域发布和管理内容，并且能够决定覆盖该领域的门户分类法。站点上所有的信息都应该归结于和起源于一个具体的来源。内容和导航的管理应该支持层次授权，例如，如果一个肿瘤研究所拥有所有肿瘤相关的页面和内容的特权，它应该能够将与肺癌相关的所有特权授权给它的专业部门。

门户和分类法一起组织，与图2所示的雅虎Web站点目录中的类似。分类是作为导航节点的多个层次来实现的。为了使导航更容易，节点应该可以穿过它们的直接子节点和父节点，并且应该能够建立所有子孙的索引。站点上所有的信息都以到信息源页面链接的形式绑定连接回它的源。我们通过各自的管理实体来维护这些页面，并且建立另外一个可穿越的层次。

图 2

站点上包括导航节点、信息源和独立页面在内的所有信息页面都可以由捐献者直接发布，而不需要开发者和站点管理员的任何介入。这些页面拥有以不同内容类型格式发布的特殊内容，并且在导航节点内容标准的情况下，允许门户在运行时将它们绑定到已发布的半结构化内容的元数据上（见图3）。

图 3

发布的挑战

如果一个门户使用高度结构化的内容，它需要一个现代CMS包为半结构化内容所提供的相当成熟的发布机制。特别地，它应该是您能够：

·         定义内容状态并发布工作流程。

·         提供带有回退支持的版本机制。

·         提供一个健壮并灵活并且具有基于角色的ACL和授权能力的安全模型。

·         验证可发布内容和全部内容完整性并为发布者提供精确并及时的反馈。

·         如果门户的版本损坏了，则刷新整个的内容。

更可取的高度结构化和半结构化内容的发布解决方案是具有一致的观感、工作流程和安全性。完成这些目标的最明显的方法是通过与站点其余内容相同的CMS包发布商业对象。

这不是惟一的选项；实际上这里描述的Food 和Nutrition门户最初是和一个定制的基于Web的商业对象发布系统一起实现的。发布部分的实现占用了超过整个门户开发一半的时间和资源，开发出来的系统在工作流程和授权方面的灵活性不如市场上的任何一种CMS产品。此外，每次任意商业对象发生变化时都要修改发布系统。最终，内容提供者在发布商业对象和其余的内容时必须使用完全不同的机制。

在全局知识存储库中，商业对象发布是通过和其余门户内容相同的Documentum CMS实现的。这使得内容发布者可以利用Documentum的全部功能并享用统一的环境。尽管事实上全部的域对象模型比Food和Nutrition 门户模型要复杂的多，但门户开发人员花在商业对象发布上的时间还不到整个开发时间的10％。

我相信这证明了发布高度结构化内容的最好方法是通过一个CMS包。本文的其余部分将集中讨论该解决方案。

需求
让我们为一个最优商业对象发布解决方案建立一系列的核心需求。很自然地，这些需求取决于将要使用发布对象的门户应用程序的特征；然而，实践表明很多关键需求适用于大部分情形。

1.       快速访问：门户应用程序应该能够在为最终用户提供页面的同时快速读取已发布对象。

2.       事务处理：对象应该能够以事务的方式进行发布、更新或者取消发布从而随时维持一致性。

3.       可引用：应该可以从其他实体引用已发布的对象。

4.       可验证： 发布解决方案在发布、更新或取消发布对象时应该能够验证对象并维护引用的完整性。

5.       可靠：如果一个操作失败或者被拒绝时应该有一种机制来通知对象的发布者。

CMS的性能
因为Documentum不能以满足上述需求的方式发布高度结构化的内容，为了解决这个问题就开发了该解决方案，作为一种规避方法。然而，我们相信这个问题是普遍的，下面列出的方法能够用在大多数商业CMS软件包中。基于对包括Documentum、Open Text的Livelink和Interwoven在内的大量CMS软件包的分析，我们已经验证了下列关于一般的CMS在商业对象发布方面的能力和限制的假设。

1.       CMS支持高度结构化内容授权，通常使用符合特定DTD或者XSD模式的XML文档格式。在一个最小的特定包开发中，可以为每个商业对象类实现一系列输入表单和验证规则。

2.       CMS包支持创建和维护文档之间的链接。链接对象可以考虑它们的状态，也就是说，规则可以只允许链接到处于已发布状态的对象。

3.       CMS包不能将高度结构化内容直接发布到关系型数据库中。在所有的产品中我们只是发现Interwoven具有将XML数据直接映射并部署到数据库模式中的能力。然而，根据它们的文档，这种能力是为了将产品数据库和开发过程中创建的内容进行同步。这样，它就不太适合正在进行的高度结构化内容管理。

4.       CMS包可以将与结构化内容相关的元数据发布到关系型数据库中。通常软件包为元数据规定模式，元数据经常是可变的、弱类型和高度不规范的。

方法
面对从CMS包发布高度结构化内容的问题，我们考虑了很多种方法。每种方法都有优势和缺点，并且实现它们的时候所需的工作量也大不相同。在本部分中我们列出了四种最可行的方法并给出了它们的优缺点（见表1）。

表 1：业务对象发布方法

关系方法
首先考虑的事情是将商业对象直接发布到数据库中，在数据库中的对象马上就可以被门户应用程序访问。这看起来是目前最自然的方法，满足了所有的需求并且不需要定制开发。不幸的是，它不能在Documentum 中工作，后来的研究表明对于大多数CMS包都是同样的情形。

元数据方法
可选的方法是，商业对象可以像半结构化内容那样发布，它所有的属性都作为元数据保存。从技术的意义上讲，这将意味着所有类型的对象将被存储在同一个元数据表里的多个行中。尽管可以定义一些递归的视图来以希望的格式提供数据，但可能对于复杂的模式行不通而且可能需要消耗很多资源。在任何情形下，特别是处理对象之间关系的时候，从名称－值格式读取商业对象都需要额外的计算，包括属性和限制的验证。另外，需要一个定义良好的拒绝机制来处理悬空的链接和畸形的对象，因为元数据表示不允许您在数据库级别上强加这样的限制。要进一步复杂化事情，大部分标准对象保存机制和工具（诸如CMP、DAO产生器等）不能使用作为元数据所存储的对象，并且需要一个定制的解决方案。最终，添加新的对象类型或者改变已有对象类型将需要改变CMS元模型。在大多数CMS包中，这是一个耗时且易出错的操作（例如，在Documentum中任何对元数据模式的改变将引起Web缓存的刷新并重新发布整个内容）。该方法的积极方面是它支持事务访问，并且如果遵从了严格的命名规定，可以开发一个基于映射的通用的DAO来使持久层的开发实现自动化。

XML方法
只要将属性值按照XML标记进行编码就可以将每个商业对象作为XML文档发布。尽管需要实现一个定制建立的拒绝机制，这还是使验证变得相对容易。然而，将XML解析成对象要比从数据库中读取数据消耗更多的资源；更重要的是，在提供客户页面的时候这种额外负载会出现在应用程序服务器中。这种方法缺少对事务处理的支持。

复制方法
这是一种混合方法。首先，商业对象可以通过元数据或者XML方法发布；然后一个分阶段的过程读取对象，进行必要的验证，然后将它们放到应用程序定义模式中的适当对象表中。同样的过程应该监控取消发布活动并从对象表中移走已删除的记录。这就保证了数据转换开销在一个对象的生命周期中只出现一次；然而，这可能导致某些数据一致性问题。分阶段过程必须保留一个事务日志来记录哪些记录已经被移植、删除等。

商业对象发布服务

基于上面的分析，我们可以知道对于性能要求高的应用程序和不支持直接向关系型数据库中发布对象的CMS来说，复制方法是最好的方法。本节描述用商业对象发布服务格式来实现该方法，该实现支持在Documentum 中商业对象的授权和将对象发布到在WebLogic 应用程序服务器上运行的门户应用程序中。该服务被成功地用在了类似于前面描述的知识门户的实现中。

架构
很多应用程序专有的商业对象在域分析过程中被识别并以UML模型的格式被捕获。这些模型用于为对象持久和XML模式（XML文件）派生出数据库模式，以XML文档的形式描述可发布对象的表示形式。然后将这些XSD文件导入到Documentum 中并用来定义对象输入格式。另外还使用BEA的 WebLogic Workshop 8.1来将它们编译成XML Beans。

在Documentum 中定义了一种特殊的内容类型——商业对象，每个具体对象类还有子类型。在Documentum 中授权了一个新的商业对象实例，并仔细检查在相关工作流程中定义的所有必要步骤后，将对象实例发布到Web缓存中。在那里发布服务对它进行处理，决定合适的发布者并调用需要的动作。然后发布者检查其完整性和其他对象专有的商业限制并更新适当的门户数据库表或者将无效对象退回到Documentum 。发布服务使用相似的步骤来发布更新和取消发布对象。所有的发布事务都记录在一个事务日志中，日志用来使已发布对象和XML文档相一致。门户缓冲服务使用同样的日志来决定何时从数据库刷新对象。

发布服务是作为一个J2EE应用程序来实现的，它可以由内容管理员通过一个Web接口手动运行，也可以部署为一个服务来帮助实现近似实时的发布。

图 4：业务对象发布服务的高级架构

实现
该服务是作为活动对象开发的，它实现了接口捕获并封装了一个后台线程。尽管项目的其余部分使用了Struts，在作为服务运行的时候，为了实现自动生命周期管理而将它配置为一个插件。服务对象有很多控制参数，诸如超时时间、优先权等，可以通过一个配置文件或者通过发布者控制台来设置这些参数。有些对象发布操作是非幂等的（也就是说，它们不能多次执行而不引发错误）。避免这些问题的最简单的方法是保证在任何时候只运行一个服务实例。如果因为负载均衡或者高可用性的考虑而使之不可行的话，就需要更多的安全措施来保证每个实例能够检测到重复的操作，并且每一个非幂等的操作只被执行一次。通过诸如数据库锁定或JNDI等的相互排除机制可以实现这些功能。

每次运行服务的时候都对Web缓存和事务日志执行三次查询来确定新的发布、更新和删除的列表。然后这些实体就转发相应发布者的适当的操作。发布者是作为状态无关的会话beans来实现的，在验证和数据库更新的过程中提供自动化的事务处理。每一个发布者处理一种特定类型的对象。根据在Documentum 中发布的XML文档的内容子类型来确定发布者类型。这种机制使您能够扩展服务来处理新的对象类型而不用对服务代码本身作任何修改。需要我们做就是将XSD模式编译成新的XML Bean，编写一个新的发布者并将它们和服务进行注册。

与WebLogic和Documentum集成
将对象发布服务和Documentum集成还需要一些额外的步骤。

1.       Documentum使用字符串作为文档ID。这些字符串作为应用程序对象ID（OID）是不合适的，所以发布服务必须在事务日志中使用的两种数据类型之间进行转换。

2.       Documentum的Web缓存模式是非常不规范的，它经常会发生变化，并且它的主键是不惟一的。我们发现定义过滤视图并据此运行发布服务有助于隔离很多不必要的复杂性。

3.       有时Documentum 宁愿直接发布文档的一个新版本，而不愿先取消发布文档然后再重新发布新的版本。为了在这种情形下保存对象之间的关系，在事务日志中保留取消发布对象的初始OID，所以在以后重新发布对象时可以恢复它们。

4.       Documentum 外部没有任何机制来向工作流程报告发布失败，所以全部失败的事务都被记录到数据库中并通过电子邮件发送给对象发布者。

WebLogic不需要很多定制；我们只需要保证在集群环境中部署应用程序时总是只运行一个服务实例就可以了。

当在包含多种环境（例如QA、分段、产品等）的架构中使用发布服务的时候，最好的方法是在每一种环境中部署一个服务实例，然后利用CMS包的多重环境发布能力来保证已发布对象的传播控制。

结束语

本文将封装了应用程序数据的商业对象看作高度结构化可发布内容的一种特殊类型。高度结构化内容和其他被授权使用Web内容管理系统的内容类型有很多相似之处，不同之处在于大部分已有的WCMS没有对它们提供支持。在列出了几种解决该问题的方法之后，本文描述了一个在类似于全局知识存储库的项目中成功应用商业对象发布服务的架构和实现。所需花费的精力还不到门户显示功能开发的10％。相反，在一个类似于Food和Nutrition门户的项目中决定实现定制对象发布解决方案。这需要投入与开发门户显示功能相同的精力，但是仍然开发出了一个在效率和灵活性方面都比任何商业CMS包差的解决方案。

尽管复制方法和对象发布服务最初是为Documentum 开发的，但是它们不依赖于任何其他WCMS中没有的一般功能，所以对于任何商业CMS都可以使用相同的技术，这使得公司可以充分利用它们的投资并且显著减少复杂Web应用程序的开发。

参考文献

·  "Vitrage: a Framework for Compartment-Oriented Application Development." Whitepaper by Roundarch, Inc. describes a framework developed for rendering Business Objects in Portal Applications. www.roundarch.com/features/vitrage.html

·  Siemens, George. "Content Management: Our Organized Future." A good introduction to CMS concepts and features. www.elearnspace.org/Articles/contentmanagement.htm

·  "Automatic Content Categorization and Tagging with Content Intelligence Services." A whitepaper from Documentum provides an idea of how CMS vendors typically view structured content. www.documentum.com/products/collateral/platform/wp_tech_cis.pdf

·  Bau, David. "XMLBeans." BEA Senior Staff Engineer and XML Beans Architect. dev2dev.bea.com/technologies/xmlbeans/articles/Bau.jsp