作者：Travis Wissink, TravisWissink001
Interwoven TeamSite是基于web的最佳培训内容管理系统。BEA WebLogic是一个经过认证的具有执行内容传输任务的应用服务器（这是BEA WebLogic多种特征之一）。两个执行非常不同功能的组件却具有相对简单的集成路径，使他们操作起来像是一个。有许多配置这个产品的途径以及不同的方法来完成他们的集成。以下讲的是：依据我的经验可以得到最多功能的最简单的方法。你的认知过程可能有所不同。
TeamSite
Interwoven（主要）是基于Perl的API；Interwoven产品需要实现以下的体系结构：
1． TeamSite服务器：在Interwoven的一套产品中的核心组件，TeamSite服务器已经使用超过了5年并且在行业内相当知名。
2． TeamSite 模板：一个基于Web的接口为了获得内容，TeamSite模板在数据内容记录（DCR）中存储获得了的内容，一个XML（Extensible Markup Language 可扩展标记语言）文件依靠一个特殊的Interwoven DTD（Document Type Definition 文档类型定义）来确认。
3． OpenDeploy：这是一个有附加特征的文件同步应用程序, 像事务的部署，因此它节省网络并且是宽带处理。 所有的开放式部署管理都能通过一个基于Web的配置接口来完成（虽然有时反复无常），这个接口可以支持在服务器上注册了的任何基于文件的内容。
WebLogic服务器
BEA WebLogic服务器是一个被认证了的实现J2EE规范的服务器。BEA公司提供一个广泛的范围紧密的完整产品，在这个结构中我们将用到WebLogic个人服务器(WLPS)和WebLogic商业服务器(WLCS)。同时他们为一些重要的内容管理和用户管理服务提供API。
硬件和软件结构
TeamSite 必须被安装在自己的物理服务器上, 然后TeamSite 模板要安装在相同的服务器上。OpenDeploy必须同时安装在TeamSite服务器和WebLogic服务器上，因为他要处理在两个服务器上的文档根部同步的问题。TeamSite服务器使用 OpenDeploy的Base安装而WebLogic 服务器使用 OpenDeploy的Receiver方安装。这二种安装应该先被配置好，因而Base安装可以发送文件到Receiver安装。Receiver应该被配置成将那些文件放入 BEA WebLogic 文件管理器的指定的文档跟部。
BEA WebLogic服务器将和两个必要的附加组件：WLPS（WebLogic Personalization Server WebLogic个人服务器）和WLCS（WebLogic Commerce Server WebLogic商用服务器）一起被安装在它自己的物理服务器上。当然，为了可以在这个结构下进行内容存储，你将需要一个关系型数据库（RDBMS，Relation DataBase Management System关系数据库管理系统）。关系数据库管理系统不光可以位于是在Interwoven和BEA webLogic服务器上，而且可以位于其他不同的服务器上（参图1看）。
如你可以料想的，传送解决方法几乎不是即插即用的。例如，WLCS和WLPS需要配置一些WebLogic服务器资源。第一个资源是一个数据源对象，用于连接一个WebLogic连接池对象。连接池对象包括了通过JDBC（Java DataBase Connection Java数据库连接）连接关系数据库管理系统的必要信息。WLPS内容管理器的其他两部分是需要配置一个名为文档连接池服务的特殊连接池对象和文档管理服务。文档连接池服务的主要目的是控制内容服务器到不同的文档服务器文件系统资源。文档管理器服务是WebLogic对象为了更快速的服务而用来缓存元数据查询和文档的。为了改善性能，可以有许多的方法来调整各种内容管理器对象的设置。
创建和管理内容
TeamSite Templating允许商务用户制作一个基于浏览器的表单以及提出一个可标记的内容，在我们的情况中就是静态的HTML。在表单中一些必须的区域应该是与内容有关联的元数据。理想地，为了模仿站点的分类你将标准化元数据贯穿你的整个Web站点。元数据对于共同的发生在两个不同的软件系统之间的管理和发送功能尤为重要。这些元数据可以使BEA知道从Interwoven来的哪种静态页面或者内容片断将被传送给（以及在什么样的上下文环境中）最终用户。可能的话，元数据域应该可以向下移动菜单和选项列表，它允许WebLogic的开发者对特定的元数据值进行特定查询。这些查询集中在生成标准的索引页和自动的，动态导航的有效的Web站点。
在一个比较大的站点上，开发者会将编码变成模板和配置文件。对于这种内容和代码的调整以及促进的一般图解被举例说明为图 2 。
当作者保存一个文件，TeamSite可以初始化一个工作流用来配置一个静态的HTML代码片断。TeamSite Templating 将用一个被称为表示模板的转换文件产生HTML代码。表示模板将用一个类型来集合内容。要注意的是表示模板不是XSL（eXtensible Stylesheet Language 可扩展样式语言），但是一个XML文件验证一个Interwoven 特定的DTD （Document Type Definition 文档类型定义）。我们目的是，表示模板应该创建一个仅包含好的Web网页而不是完全的Web网页的HTML片断。其他的Web网页面片断，像头部，尾部和导航元素将在BEA WebLogic服务器中通过JSP（Java Server Page Java 服务器页面）代码被胶合在一起。
内部的配置
为了配置HTML片断，OpenDeploy需要一个配置脚本来允许OpenDeploy Base服务器用TeamSite传送文件到在WebLogic服务器上的OpenDeploy Receiver。 这个配置从TeamSite服务器发送文件到WebLogic文档管理器目录作为在文档管理器服务中的配置。OpenDeploy需要一个配置与运行脚本选项，这样，在完成配置后，它能在WebLogic中触发一个WLPS命令，BulkLoader方法如下：
<deployNRun>
<dnrDeployment location="source" when="after" state="success">
<script cmd="/path/to-the/script/that-starts-the bulkloader.sh"
as "weblogic" where"/tmp" async="yes" />
</ dnrDeployment>
</ deployNRun>
OpenDeploy配置是一个XML文件，他确认一个特殊的Interwoven DTD。在配置文件中的DeployNRun选项描述了在OpenDeploy转换中如何执行一个文件，在deployNRun标记内部是dnrDeployment子标记，它有三个属性描述：
1． Location（位置）：在哪个服务器执行命令，基本安装，或是接受方安装
2． When（时间）：配置之前或之后
3． state（状态）：配置的状态，成功或失败
注意：状态是很重要的因为如果配置失败，你作的改变将全部回滚并且要重作。
在dnrDeployment内部，用脚本标记和他的属性来告诉OpenDeploy执行什么和怎么执行：
. Cmd: 文件执行所需的全路径
. as: 在"WebLogic"时用户运行cmd,
. where: 在那个OpenDeploy目录下执行命令
. async（异步）: OpenDeploy 是否应该等待或者继续执行下一选项
BulkLoader开始时通过一个包括HTML内容的文件的目录查看并且扫描它所关联的元数据。BulkLoader 浏览HTML文件来找到所有meta标记的名字-值（name-value pair）对，并且把它装载到WLCS数据库中，在数据库表中建立一个新的条目，文档元数据，他有四行，其中三行对我们特别重要：ID（编号），Name（名字），和Value（值）。这些包括了各自的URI（从文件根部），name（名字，从meta标记），和value（值，从同一个meta标记）。
BulkLoader发送所有的在HTML页中的meta内容到数据库，因此其他的WLCS库可以用这些描述内容来取回与配置内容有关的关联的URL。
下面内容是和几个重要选项一起的在WebLogic中的BulkLoader指令。因为它是一个Java类文件，它以"java"命令开头。
java
com.beasys.commerce.axiom.document.loader.BulkLoader
[-/+verbose] [-/+recurse] [-/+delete] [-/+cleanup] [- schemaName <name>]
[-properties <name>] -conPool <name> [-match <pattern>]
[-ignore <pattern>] [-d <dir>] [--] [files… directories…]
你可选择"verbose"选项，所以你能观察到它在执行什么；这只用在调试中。"recurse"选项允许你进入并处理任何子目录。"delete"和"cleanup"是两个重要的选项，他们是从数据库中删除文件的唯一方法。你的脚本要执行BulkLoader有些东西应该看起来像Listing1。
内部的传送
在BulkLoader已经处理了元数据之后，我们能向我们Web站点的最终用户展示它。我们用JSP和WLPS内容管理标记做这项工作。从WebLogic的前端，JSP将用下列代码来访问WLPS内容管理器。这些例子使用来自WLPS的自定义标记库的"cm"和"es"标记。
String contentQuery = "keyword"= '4q2000commentary' &&
contentlevel like '*A*' && ((expirationDate >=now) || expirationDate='0'")";
<cm: select contentHome="com.beasys.commerce.axiom.document.Document"
query="<%=contentQuery%>" sortby="priority ASC, postedDate DESC"
id="contentList" />
上述的代码为了得到一些特殊的记录查询meta数据，然后将结果排序，按照优先级升序排列以及提交的时期降序排列。
查询类似标准的SQL，并且，选择标记很好的文档化。基本上，你告诉选择标记你的查询，我们把它抽象成分离的字符串对象。另外，告诉选择标记将你所要的结果集按照升序或降序排列。告诉选择标记内容管理的EJB的"Home"接口的内容；这是我们执行的标准，并且使EJB方便地在WLPS的安装上配置。因为"优先"和"滞后"数据代表着数据库中与特定的页面或内容片断相关的meta数据，所以选择标记将自动的取回那个内容。对选择标记的最后一个配置属性是"id"，它将在后面的代码中用于结果集的引用。
现在我们有一个结果集我们可以把它当作对静态内容超链接的一个动态索引页显示出来就像Listing2。
我们使结果集由我们的元数据驱动查询创建，并且分析出页面标题和链接并且作为一个索引页上的超链接列表发布他们。这对于一个Java程序设计者是相当容易的。 它也假定了 meta标识在 TeamSite模板中是严格需要的。 如果那里没有meta标记,内容就不能被找到, 至少不能通过这种类型的查询找到。
一些建议
以下是关注任何BEA/Inerwoven 集成时的五件事。
1． 使数据获取模板从内容描述中尽可能的分离出来――也就是说保持内容类型与写分离。这是基本的，但是当编辑器想要特殊的WYSIWYG（What you see is what you get所见即所得）HTML编辑工具时就困难了。如果你允许编辑器通过HTML标记用描述逻辑处理内容入口系统，那么当你想要改变描述时，你的内容也将不得不修改。那将花费很多内容编辑的时间。相反，把那些时间和努力放在开发粒状的数据获取模板上，并且在发送方关注在你的JSP中的终端用户的表达。
2． 如果你的发送服务器是聚簇的，关于该在哪里使事物像图像的策略。你的BEA WebLogic服务器要共享一个文件系统以便所有的内容都能放在相同的驱动器上吗？如果不，那就可能需要内容复制软件。 你可以为这使用 OpenDeploy,虽然一个服务器大约需要要 ,000，这可能变得相当昂贵。 我推荐在Solaris（SUN微系统公司开发的一种网络操作系统）上使用的 rsync软件(免费来自samba.org)以及在Windows上使用的Opalis RendezVous ( 一个几千元的更健壮的解决方案)。 像 OpenDeploy，这些产品不保证内容复制通过你的企业或者聚簇Web以及应用服务器。文件复制软件保证了复制。
3． 很多必要条件：聚集和分析需要被慎重协商meta标识的方案。Meta数据可以进行或打断你的长期的内容目标。如果你集合足够的meta数据，你的应用程序可能看起来在几个月之内都无用，因为你不能创建一个新的查询。如果你试图集合过多的meta数据，你的内容获取方法也许会过于笨重，而且你的作者将在面对他们认为是没有意义的地方提出反对意见。要在大量的meta数据方面找到一个微妙的平衡以同时满足短期和长期目标。
4． 全部来自WCM（Web Content Management Web内容管理）的meta数据都将被部署和装载到数据库中，更明确的是在一个表中。在数据库里的很多新行将开始降低你的Web站点的性能。为了增加数据库的速度，你可以安装一个数据库的镜像并使用BEA 多连接池选项。这将允许数据库包括相同的数据，并且允许BEA WebLogic集群可以从一个集群数据库中进行查询。
5． 如果你有一个将有很多页（大约5,000页）内容的站点，BulkLoad处理完成将花费很长的时间。每个页用5-10个元数据项，5,000页要求大约2.5小时用于数据库同步。一个替换OpenDeploy部署的选项是被称为基于文件部署的一种特殊类型的部署，如果在文件系统上有很多的文件时它非常有用。用这种方法，OpenDeploy执行配置包括你在一个单独的配置文件中列出的文件。那个文件列表可以被包括在部署中。部署后，OpenDeploy可以初始化一个deployNRun脚本，他包括文件列表配置文件以及依靠最近的配置文件初始化BulkLoader。这增加你的发送引擎的准确性和保存处理的能力。这种方法的最后是文件列表必须要你自己来创建、编辑、维护和删除，虽然Teamsite工作流能在这里帮助你。另一个不利条件是从发送服务器上任何东西都不被删除；删除文件不是一个基于文件部署的自带功能。当你移动这种类型的部署时复杂性水平大大的增加，性能的回报能证明这个增加了的部署工作。
|
