级别： 高级
Jonathan Brunn (jbrunn@us.ibm.com), 软件工程师, IBM
Clayton Coleman (claycole@us.ibm.com), 软件工程师, IBM
2005 年 11 月 24 日
在本文中，门户管理员看到了另一种能够帮助您规划公司个性化门户部署的服务器拓扑。通过阅读文中的示例发布方案，您将学会如何使用 IBM WebSphere Portal V5.1 的 Personalization 组件所提供的发布功能。
开发人员和公司用户通过创建个性化的业务规则、电子邮件活动和基于 Web 的活动，从而使 Web 内容更加针对于特定站点的访问者。他们使用基于 portlet 的用户界面（它是 IBM® WebSphere® Portal 的 Personalization 组件的一部分）创建这些构件。Portal 和 portlet 的开发人员使用 Rational® Application Developer 或 WebSphere Studio Application Developer 创建其他的个性化构件，例如资源收集实现类。
本文描述了如何使用 WebSphere Portal Personalization 的发布功能将各种个性化构件从开发和生产的编写环境移动到登台和生产的环境中。
除非特别指明，否则您都可以使用 WebSphere Portal V5.1 执行本文所描述的任务。少数任务被标明需要使用 WebSphere Portal V5.1.0.1。
本文的目标读者是在 WebSphere Portal 的安装中使用了 Personalization 组件的管理员。我们假定您熟悉 WebSphere Portal 和 WebSphere Portal Personalization。本文不仅描述了支持的服务器拓扑，同时也有助于您规划自己的部署。
  |
|
WebSphere Portal Personalization 支持在一个系统上编写规则和活动，然后再将它们发布到其他系统上。编写规则的系统被称为编写系统，执行这些规则的系统称为运行时系统。
让我们从 WebSphere Portal V5.1 开始，编写界面包含了在 IBM Content Manager 运行时编辑库中创建规则的工具，以及一套显示该库视图的 portlet。运行时系统包括了一套执行规则的 Java 库，以及一个用于存储规则的 IBM Content Manager 运行时编辑库。编写服务器和运行时服务器的区别现在仅仅在于这些服务器在您机构内的用途如何，而不在于哪台服务器上安装了哪些组件（或规则存储于哪台服务器之中）。
图 1 展现了 Document Manager (PDM)、Personalization 的编写 portlet (PZN UI)、Personalization 运行时 (PZN) 和个性化应用程序间的相互关系。Personalization 的用户界面和运行时系统使用相同的存储库。
|
|
因为编写界面和运行时系统使用了相同的存储库，所以规则一旦保存便开始发挥作用，因而您也不需再去发布它们。如果您很乐意于直接为正在运转的产品门户修改规则，那么本文的大部分内容可能并不适用于您。但绝大部分机构并不希望直接在生产系统上修改规则，其中许多机构都建立了质量保证流程，以阻止无意或错误的业务规则发布到正在运行的站点之中。您可以将开始和结束日期应用到规则映射之上，以确定规则开始发挥作用的时间，从而阻止这些规则立即开始发挥作用。
在 WebSphere Portal 的上一个发布版本中，用户在规则发布后束手无策，他们在运行时系统上既不能查看规则也不能编辑规则。但现在，无论系统是运行时系统还是编写系统，所有构件都以相同的格式存储，因而您可以轻松地将这些规则从一个系统移动到其他系统上。
在 WebSphere Portal 的早期版本中，您曾使用 Personalization Resource Console（也称 PersAdmin）配置资源收集和活动的某些方面（在它们被发布到运行时系统后）。从 V5.1 开始不再需要使用单独的 Personalization Resource Console，因为您现在使用相同的 portlet 来编写和管理规则。
Personalization 曾与 WebSphere Portal 的内容发布功能相结合，但在 V5.1 中这两种功能被分离开来。虽然 V5.1 不再继续支持 WebSphere Portal 的内容发布功能，但 WebSphere Portal Personalization 却仍继续得到开发和支持。Personalization 不再管理类文件，它不在自己的库中存储资源收集类或内容点类。因此，您必须确保这些类已置于任何一个引用它们的应用程序（包括 Personalization 自己的用户界面）的类路径当中。实现这点的最简单方法是把这些资源收集类放入某个 WebSphere Application Server 的共享库中（请参阅下面的资源收集类部分）。
此外，在实现将内容点映射到规则之前，您必须立刻为每个内容点创建一个引用（通过在 Personalization Navigator Portlet 中选择 New => Content Spot）。在 Personalization Navigator Portlet 中创建的内容点的完整路径应该与您在使用 Rational Application Developer Content 或 User Resource 向导创建该内容点时所输入的显示名称相匹配。在您发布规则和活动的同时，这些内容点的引用也被发布。
现在您已经了解了 WebSphere Portal Personalization 功能的发展过程，让我们看看几种典型的个性化发布配置。请您考虑哪种配置更适合自己的门户环境。
|
|
在这个最简单的发布方案中只有两台服务器，我们在其间移动规则。通常情况下，公司用户在一台服务器上创建并测试规则，然后公司用户或门户管理员会再把这些规则发布到一台生产服务器上。在图 2 中，箭头表示发布的可能性。蓝色的箭头表示了通常的发布步骤（将规则从公司的编写环境移动到生产环境中）
另一个箭头也代表一种可能的发布步骤，但它不会在日常使用中遇到。客户偶尔会要求能够将规则从生产门户向回发布到自己的编写环境中。但这在用户生产门户发生某些问题（无法在编写或登台环境中复制）时非常有用。在这种情况下，您可以使用“向后发布 (back-publish)”来确保您的编写或登台环境中包含与生产环境中相同的构件。虽然理想情况下，所有构件都在生产环境之外被完全备份，但您在“编写系统”的灾难恢复中可能需要使用“向后发布”。
|
|
您可能决定保留一个生产系统的完整副本，以便在对生产系统进行任何改变之前，执行最后的验证测试。为实现该目标，您可以引入一台登台服务器。在对登台服务器进行验证后，交换登台和生产环境是在登台服务器和生产服务器间移动的一种方法。您的网络可以重新将来自生产系统的流量路由到位于某个期望点上的登台系统中，并同时把过去的生产环境变成现在的登台环境，再把过去的登台环境变成现在的生产环境。
当规则改变非常频繁且需要对规则进行最高级的控制时，重新将您的生产流量路由到登台机器是明智之选。当规则改变频繁时，或者当不同的计划有不同的规则改变时，或者规则根据不同的计划而不是二进制文件进行改变时，这种方法会显得比较笨重，因为它需要频繁地与网络管理员协调。
图 3 显示了另一种开发、编写、登台和生产的典型配置。在这种方案中，您引入了两台以上的服务器。开发人员可能会使用自己的沙箱门户（也称门户单元测试环境）中的一个或多个。这种测试环境也可在开发人员机器上本地运行。登台门户完全将质量保证测试与开发人员和公司用户分离开来。开发、编写、登台和生产的安装就是 WebSphere Portal 的完全安装，它同时具有编写和运行时功能。开发门户可以是一个 Rational Unit Test Environment。
许多机构会很满意方案 1 中的两台服务器的设置，因为不需要考虑引入一台登台服务器。从另一个角度看，如果您的机构已经为其他门户应用程序规划使用一台登台服务器，那么方案 2 中的配置将支持为个性化使用该环境。
图中的蓝色箭头代表了将一个构件从编写移动到生产所需的发布步骤。通过直接从登台门户发布到生产门户，您可以确定生产门户中的哪些构件始终通过登台门户。您可以使用由不同凭证保证安全的 servlet 和防火墙来阻止直接从编写门户到生产门户的发布。
这些发布步骤可以从用户界面启动，或从命令行执行脚本启动。可以导出一个 XML 文件，然后使用命令行发布。用户首先导出文件夹、规则和其他需要发布的构件。导出的 XML 被移交到部署小组，该小组将 XML 发布到一台登台服务器上，以进行最后的验证和质量保证测试。在完成最后的测试后，相同的 XML 文件被发布到生产门户。使用中间 XML 文件和受控的部署过程，保证了您生产门户之上的一切都已通过登台门户，也保留了用于稍后重新发布的导出的 XML 的备份。您可以通过为导出的 XML 文件调用命令行发布工具（称为 PznLoad），从而在您的部署脚本中包含对 Personalization 发布功能的调用。在部署脚本中使用命令行工具，可以协调门户的发布和其他变更。您在稍后的部分中将看到如何使用命令行发布。
|
|
在第三种方案中，您不需在同一台服务器上的编写门户和运行时门户间使用发布步骤移动构件。所有构件在存储的同时开始发挥作用。为了更好地控制部署规则，您可以引入一台登台服务器。您可能希望将构件隔离，以使它们在特定的服务器上发挥作用之前必须首先被发布。该方案非常适用于某台完全独立的服务器不可用的情况。在这种情况下，您可以使用独立的工作区来代替独立的服务器。
在方案 1 和方案 2 中，您安装了独立的编写（或开发）和生产门户（如图 2 和图 3 所示）。然后，您能够控制规则和活动的发布，以确保它们在正确的时间发挥作用。规则映射的开始和结束日期是控制规则何时生效的另一种备选方案。您可以使用活动和规则映射的开始和结束日期来控制规则在某一点生效。您可以在内容点和规则映射上通过设置访问控制来管理哪些用户可以改变开始和结束日期。
为了分离同一台服务器中的规则，您可以在单个库中使用多个工作区。您可以为 Java 开发人员指派一个工作区，让他们创建用于测试其资源收集代码的规则。您还可以为规则的编写者指派另一个工作区，让他们创建规则并将这些规则从编写工作区发布到生产工作区。
WebSphere Portal 的 5.1.0.1 修复包支持该方案。在 V5.1 中，您只能使用一个单一的工作区。
在该方案中，不存在登台环境。由于运行时规则引擎一次只能配置运行在一个工作区中，所以您应用程序中的规则始终从生产工作区执行。Personalization 也提供一个预览页面，在一条规则或一个访问点打开的情况下可以访问该页面。您在该页面上唯一能看到的是从开发或编写工作区执行的规则。
如果您需要一个能够精确复制生产环境的登台环境，请设置一台单独的服务器。编写（或开发）和生产可以在同一台服务器上进行，而登台在第二台服务器上进行。
|
|
要配置第二个工作区，您需要第二个 Personalization Navigator portlet。WebSphere Portal V5.1 为每个指定的工作区配置一个 Personalization Navigator portlet，缺省名称是 ROOTWORKSPACE。您可以将 portlet 参数 cm.workspace 设置为新工作区的名称。
- 在 WebSphere Portal 的管理 portlet 中，导航到 Portlet Management => Portlets 并搜索
pers。您将看到三个 Personalization portlet，如图 6 所示。
图 6：三个缺省的 Personalization portlet
- 单击 Copy portlet 按钮，复制一份 Personalization Navigator portlet。
- 为该 portlet 输入一个唯一的名称，例如
Authoring Workspace、Development Workspace或Production Workspace。 - 单击 Configure portlet 按钮配置刚刚创建的 portlet，添加一个名为
cm.workspace的参数和符合该工作区名称的值，例如authoring、development或production。 - 单击 OK 保存对该参数的更改。在您首次导航到新的 portlet 时，程序将创建一个使用 cm.workspace 的值作为名称的工作区。
- 选择 Portal User Interface -> Manage Pages 并创建一个新页面。将您刚刚创建的导航 portlet 的副本和现存的 Personalization Editor portlet 添加到该页面中。例如，在 Personalization 页面上创建一个称为 Development Workspace 的页面。
- 注销后再登录，对 portlet 参数的改动将生效。
- 在您创建的页面和原有的 Personalization Workspace 页面间导航。在同一个页面中创建的规则、活动和其他对象在首次发布前都不会显示在其他页面中。
|
|
WebSphere Portal Personalization 通过 HTTP 将发布对象发送给驻留在每台个性化服务器上的 servlet。该 servlet 不仅可以接收发布数据，也可以启动新的发布作业。当一名用户从个性化编写服务器上开始发布作业时，程序将提供一个具有完成该作业所必需的信息的本地 servlet。这个本地 servlet 将联系目的端点的 servlet（可能是相同的 servlet）并将数据发送给目的 servlet。然后，目的 servlet 报告成功或失败。
要着手发布个性化对象，您需要在编写环境中创建一个描述目标端点的对象，如图 7 所示。该端点的定义被称为发布服务器，该服务器的创建和管理方式类似于对规则与活动的创建和管理。
该服务器需要一个字段，该字段是与端点的发布 servlet 相关联的 URL。该发布服务器也定义了哪个工作区将接收发布数据。Personalization 和 Document Manager 在安装后都运行在缺省的 Content Manager 运行时编辑工作区中。如果该目标工作区字段为空，那么该发布服务器将使用缺省的工作区。如果您正在配置上述方案 3，那么您需要设置该工作区字段。
最后一个选项是，无论如何请删除与本地系统已删除的对象相对应的远程对象。缺省设置是 Smart Delete，它只是简单地删除那些不再呈现的条目。如果您没有远程服务器上的删除权限，您可以选择“Leave deleted resources on server”选项。
图 8：发布到同一服务器不同工作区的 Publish Server
在您创建一个发布服务器后，您可以在其内部发布整个工作区或一组对象。您可以通过选择 More Actions -> Publish 的子菜单（图 9）来指定发布整个工作区还是发布一组对象。Publish Selected 选项只在您选择单一条目时启用。选择任意一个选项后将打开类似图 10 的页面。
该 Publish 页面显示了即将发布的内容。该页面需要用户选择一个目的发布服务器和所有必要的身份验证信息。如果远程系统受到保护，并且也不是当前服务器单一登录 (Single Sign-On) 域的成员，那么您可以在提供的字段中输入用户名和密码。用户名和密码存储在 WebSphere Portal 的凭证保险库中，其他任何用户都无法访问。
最后，请单击 Publish 按钮启动该发布作业。
如果本地系统不能使用远程发布服务器进行定位和身份验证，您将回到主导航视图并看到该 portlet 顶端的 Personalization 消息 EJPVP20001I。该发布作业将作为本地服务器上的后台进程运行。请单击“View the details of this job”链接，打开发布状态窗口查看关于该进程的信息，以及该发布作业是成功还是失败。
|
|
要查看所有当前发布作业的状态，请选择 More Actions => Publish => View Status，或单击发布作业成功启动后出现的相应链接。然后，所有当前运行的作业或完成的作业都将显示出来。在某一作业完成后（无论成功与否），界面的右上角都会显示一个关闭图标，您可以通过单击该图标将相应的作业从监控作业列表中删除。（如果单击该图标，您将无法查看该作业的状态。）
|
|
您可以使用 WebSphere Portal Personalization 提供的可执行命令行工具，把导出的 Personalization 构件加载到本地或远程服务器中。因此，您可以通过编写脚本把规则和活动从登台传送到生产，或编写脚本在两个未连接的系统间（例如在防火墙后的生产服务器）进行脱机发布。您可以使用该功能快速地将生产服务器还原到早期的某个状态。
通过命令行发布有两个步骤。第一，导出希望从编写环境传输到远程系统中的个性化对象。当您在 Personalization Navigator portlet 中选择 More Actions => Export 时，程序将提示您为一个 .nodes 文件选择一个位置进行保存。该文件包含了所有当前选定的个性化对象的 XML 表示。您可以导出整个文件夹。
在导出并保存期望的对象后，您可以使用可执行的 pznload 把该对象发送到期望的服务器中。可执行的 pznload 位于 WPS_HOME/pzn/v5.1/publish 目录中。Windows 用户调用 pznload.bat 文件，UNIX 系统用户使用 pznload.sh。该程序使用许多命令行选项和一组 .nodes 文件进行发布。使用 --help 选项调用 pznload 来查看包含所有选项的列表。下面描述了最重要的参数：
-
serverUrl
- 远程发布 servlet 的 URL。如果您不为该参数指定一个值，该程序将试图连接到一个运行在本地机器上的 WebSphere Portal 服务器。 targetWorkspace
- 发布到的工作区名称。所有 IBM Content Manager 运行时编辑安装上的缺省工作区名称是 ROOTWORKSPACE targetPath
- 目标工作区的位置，它将是发布节点的父节点。目标路径必须先于发布而存在。例如：如果对文件夹 /Projects/HR Website 使用 Export 功能，则目标路径应指定为 /Projects，这样该发布资源被重新定位于 /Projects/HR Website。 username
- 目标系统上拥有足够访问权的合法用户。 password
- 用户密码
一旦发布启动，您会看到命令控制台中的状态信息。如果发生错误，为获取相关信息，请打开客户机系统中跟踪 WebSphere 的 Java 运行时环境，或检查该服务器系统中的错误日志和跟踪日志。
|
|
WebSphere Portal Personalization 使用 WebSphere Application Server V5.1 的内置 SSL 功能为整个未受保护的网络提供安全的发布。您的个性化门户可以获益于 WebSphere Application Server 安全性所支持的所有身份验证库。
要通过 SSL 进行 Personalization 发布，请参阅 Personalization Navigator 的联机帮助：请单击该 portlet 右上角的问题标记，并向下滚动到该页面底部以查看有关发布的帮助主题链接。当您在两台 Personalization 服务器间启用 SSL 后，您可以为特定的发布服务器使用 SSL（通过调整发布 servlet 的 URL 使用 HTTPS 协议）。如果远程服务器不使用缺省的 HTTPS 端口（443 端口），请修改 URL——在主机名后按顺序添加一个冒号和一个端口号。
要启动一个发布作业，portlet 将发送请求给本地服务器上的发布 servlet，然后与目的发布服务器上相对应的 servlet 通信。
如果一台 Personalization 服务器被配置为使用非标准的 HTTPS 端口或上下文根，或者如果您在从编写环境发布时看到类似的消息“EJPVP20002E: The local publish service was not available”，那么本地发布 servlet 的 URL 可能不正确。
为本地服务器指定正确的 URL：
- 在 Portal Administration 页面中，选择 Portlet Management => Portlets。
- 在列表中查找 Personalization Navigator portlet。
- 单击 Configure portlet 按钮来配置该 portlet。
- 添加一个名为
pzn.publishServlet.url的新 portlet 参数，并指定合适的值 。
要确定特定 URL 是否有效，请让您的浏览器指向该位置并输入该系统的用户名和密码。如果您看到消息 Publish servlet available，并且所有 SSL 证书已正确导入，那么您应该可以发布。您可以改变该 URL，以通过一个特定的集群成员重定向所有发布作业。
在某些环境中，即使 SSL 发布也还是不够安全。pznload 命令行程序使您能够完全控制发布期间的规则和活动的传输。您可以加密输出的 .nodes 文件并使用电子邮件发送出去，或者您也可以使用另一种安全通道，例如在登台和生产服务器间传输的物理媒体。
|
|
发布到集群（或从集群发布）不需要进行特别的配置。特定的集群成员将执行应用于传入 Web 请求的相同规则所选择的发布任务（因为发布功能使用了 HTTP 消息）。在成功发布作业的最后，Personalization 会刷新相应工作区的缓存，从而确保任何随后的个性化内容尽可能地提前。
当您首先在某个集群上使用 Personalization 编写 portlet 来发布对象时，Publish Status 对话框（通过 More Actions => Publish => View Status 访问）只显示该集群成员启动的发布作业的信息。要使所有发布作业可见，请将上面描述的参数 pzn.publishServlet.url 设置为一个特定的集群成员。请设置该 URL 指向位于 WebSphere 内部 HTTP 端口上的一台单独机器，HTTP 的缺省端口是 9081，HTTPS 的缺省端口是 9043。
例如，假定该集群头在 http://intranet.yourco.com 可见，则该集群成员在 http://intranet01.yourco.com 和 http://intranet02.yourco.com 可访问。如果您设置公共 servlet 的 URL 参数为 http://intranet01.yourco.com:9081/wps/pznpublish/pznpublishservlet，那么您必须强制所有发布请求在这台单独的机器上运行。
|
|
您可以在 Personalization 中使用资源收集类访问 SQL、LDAP、IBM Content Manager、Portal 用户对象或其他自定义的数据源。
DB2 Content Manager 运行时编辑和 WebSphere Portal 用户的资源收集类安装在 Personalization 的共享库中。因此，您不必在系统间移动这些类，因为它们已经和 Personalization 一起安装了。
对于 SQL 和 LDAP 资源，Rational Application Developer 提供了一个向导用来生成实现该资源收集接口的类。
要使用编写 portlet，所有资源必须置于 Personalization 编写 portlet 的类路径中。规则编辑器使用这些类显示属于该收集的属性列表。如果规则编辑器找不到资源收集类，您可以在 JavaScript 的警报中看到以下信息。
资源收集类必须存在于调用 Personalization 规则的应用程序的类路径之中。Personalization 规则引擎使用调用这些规则的应用程序的类路径找到这些资源收集类。如果您使用 Personalized List portlet 显示规则结果，该应用程序是 Personalization 的 Lists.ear 中的 Personalized List 应用程序 pznruleportlet.war。
因此，规则编辑器和个性化应用程序应该都可以访问该类。完成该目标的最简单方法是共享某个应用程序服务器的库。您可以使用 Application Server Administrative Console 配置该共享库。想了解更多信息，请参阅 WebSphere Application Server version 5.1 InfoCenter 中的共享库部分 (http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tcws_sharedlib.html)。
您对资源收集类的更新和添加就像更新任一应用程序的二进制文件或 JSP 一样。这些类不受 Personalization 发布影响。资源收集的定义（Personalization 用于关联资源收集及其类）存储于 Content Manager 的库中。最初由 .hrf 文件表示，该定义随规则和活动一起发布。
|
|
在没有 WebSphere Portal 的情况下安装和使用个性化
您可能会希望在 WebSphere Portal 之外的环境中使用 Personalization 规则引擎。例如，您可以在提供个性化 XML 内容流的 Web 服务中使用 Personalization 。换句话说，您可以使用它来生成 RSS 源。在这些例子中，Personalization 作为一个由其他服务器上的其他软件组件消耗的一种服务。WebSphere Portal 的完全安装会带来一些管理和基础设施的开销。当 portlet 不需要调整时（例如当服务的输出为 XML 或 RSS 源），您可以在 WebSpher Portal 外的环境中安装 Personalization 规则引擎。您若要配置一台独立的 Personalization 服务器——使用 Personalization 规则引擎的应用程序服务器（没有 WebSphere Portal），请使用 WebSphere Portal V5.1 CD # 3 中的安装程序。
接收发布请求的 servlet 也可以运行在 WebSphere Portal 之外。除包括 WebSphere Portal 用户资源收集的 pznwpsruntime.jar 外,所有 Personalization 运行时库都可以运行在 WebSphere Portal 之外。
您可以在 WebSpher Portal 之外安装存储了规则和活动的库。在该配置中，DB2 Content Manager 运行时编辑库不使用 WebSphere Portal Access Control。
在 Portal 系统外运行时，唯一不安装的组件是 Personalization portlet——包括编写 portlet 和 Personalized List portlet。因而，一旦构件发布到一个没有安装 WebSphere Potal 的 Personalization 规则引擎上，就没办法直接查看该系统上的那些构件。您需要安装 WebSphere Portal——安装一个测试环境或安装完整的 Portal，以编写规则和活动。
发布到一台没有安装 WebSphere Portal 的服务器与发布到一台安装 Portal 的服务器是有所不同的。
|
|
WebSphere Portal Personalization V5.1 提供了一个健壮的解决方案——在开发中的登台和部署过程间，移动规则、活动和其他构件。Personalization 运行时和编写服务器的组合简化了 V5.1 中的发布。您可以为发布使用图形、基于 portlet 的用户界面和命令行工具。Personalization 发布功能的灵活性可以让您轻松适应现有的部署过程和环境。
学习
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- 当您所使用的规则引用了 Web Content Manager 所管理的内容时，IBM Workplace Web Content Management V5.1.0.1 InfoCenter 中的相关资料可以帮助您协调处理规则发布和内容复制。Personalization 经常同 Web Content Management 一起使用，Personalization 提供了一些自己的复制功能。
- IBM Workplace Web Content Management：Web Content Management for Portal 5.1 and IBM Workplace Web Content Management 2.5。文中讨论了个性化和 Web Content Management。
- 网站个性化白皮书：不仅介绍了网站实现个性化的当前技术和未来技术，还讨论了最大限度提高个性化网站性能的技术，例如内容缓存。
- WebSphere Portal 专栏：找到更多帮助您开发门户和 portlet 的资源。
- WebSphere Portal 产品文档：包括 WebSphere Portal 所有版本的 InfoCenter、发行说明和自述文件。
- IBM WebSphere Portal Primer，第二版。由 Bby A. K. Iyengar、V. V. Gadepalli 和 B. R. Olson 共同撰写（IBM Press，2005）。本书概述了门户开发和管理，其中包括一些核心的个性化概念，例如规则和活动。
获得产品和技术
- Rational Application Developer V6：从 developerWorks 下载试用版。其中包括一些门户工具，以及一个测试运行时的门户副本，您可以使用该副本开发原型。
讨论
| ||
|
| | Jon Brunn 是 Portal Personalization 的首席架构师。他有 6 年以上的 Personalization 及其他业务规则引擎的工作经验。他现已投身于 IBM 内部 Content Management 的标准化工作当中，并继续致力于 IBM Workplace Web Content Management (IWWCM) 的工作。 |
| ||
|
| | Clayton Coleman 曾经是 Portal 5.1 中 Portal Personalization 发布功能和用户界面的主要开发人员之一。在 2002 年，他加入了美国北卡罗来纳州三角研究工业园 (Research Triangle Park) 的 IBM Software Group。他目前的工作任务是降低基于 portlet 的应用程序的构建和扩展难度。Clayton 于 2001 年毕业于凯斯西储大学 (Case Western Reserve University)，并获得该校的 |
4592
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
