探索 WebSphere Application Server V6.1 Portlet 容器，第 4 部分: 在 WebSphere Application Server 和 W

引言

目前，门户开发人员已习惯于使门户拥有大量特性和丰富的功能。这些平台的两个主要功能是支持 Portlet 编程模型的扩展 Portlet 运行时环境，以及聚合和管理门户构件（例如，Portlet 和页面）的成熟门户框架。

WebSphere Portal 提供了丰富的门户功能，其中许多功能支持 Portlet 编程模型并通过扩展 Portlet 运行时丰富了 Portlet 体验。而 WebSphere Application Server V6.1 门户相关功能则集中于 Portlet 运行时，它仅提供最小的门户功能集。

在本文中，您将了解这两种产品在提供 Portlet 运行时和门户功能方面的差别。为了开发在部署运行时可以充分利用这些功能的 Portlet，您需要理解扩展编程模型。在运行时支持不同功能集的情况下，通过了解每种平台所支持的模型部分，可以实现适当缩减功能的 Portlet（当在两种运行时之间进行迁移时）。

回页首

关于示例

本文附带的 World Clock 示例代码将 WorldClock Portlet 从 IBM Portlet API 转换到 JSR 168 Portlet API 是 JSR 168 Portlet 的一个很好的例子，仅能在 WebSphere Portal 上运行，它使用属于扩展门户编程模型的 bidi 标记，超出了标准 Portlet API 的范围。有关详细信息，请参阅 WebSphere Portal 信息中心中的 JSP tags for standard portlets 主题。虽然简单的 World Clock Portlet 不需要使用此扩展功能，但是其对于需要适当缩减功能的项目也是一个很好的例子。

您可以消除这种依赖关系，或者添加一个智能 Java 类来适当地缩减功能，从而使该 Portlet 也可以在其他平台上运行。本文附带的 World Clock 示例 Portlet 进行了相应的改写，可以在两种平台上运行。

回页首

Portlet 编程模型

所有支持 JSR 168 Portlet 规范的 IBM 产品都基于同一技术。然而，根据相应的环境所提供的门户框架和插接点，这些产品嵌入了不同的技术堆栈并提供不同的扩展支持。

在其门户框架所提供的功能方面，WebSphere Portal 和 WebSphere Application Server 有所不同。WebSphere Application Server 的重点在于执行单个 Portlet 的 Portlet 运行时，而 WebSphere Portal 则完全支持对简单和复杂页面聚合的控制和管理，并且支持集成到多个后端系统，如用于持久性存储的数据库。

此外，WebSphere Application Server 的编程模型允许您使用 Portlet 组件，而 WebSphere Portal 允许您使用组合应用程序。它包括一个成熟的应用程序框架，可让业务用户方便地将相关应用程序和流程组件组装到组合应用程序中并进行自定义。

为了理解 WebSphere Portal 的扩展 Portlet 编程模型和 WebSphere Application Server 的 Portlet API 编程模型之间的差别，我们将对它们提供的用于支持 JSR 168 Portlet 的门户功能进行比较。

WebSphere Application Server 中的 URL（Uniform Resource Locator，统一资源定位符）Addressability 是最简单的门户框架形式。它使您可以在页面上呈现简单的 Portlet；它非常易于使用并且最适合用于开发。您可以自定义门户聚合，以充分利用 URL Addressability 并在一定程度上加以扩展，从而增强其功能。（请参阅本系列文章的第 2 部分。）

WebSphere Portal 提供了功能丰富的门户框架，包含许多扩展。解释所有功能超出了本文的范围。（请参阅 WebSphere Portal 信息中心）。本文讨论对 Portlet 编程模型有影响的那些功能，并将其与 WebSphere Application Server 的功能进行比较。

表 1 显示了我们进行比较的功能。您将看到它们在各种环境中的工作方式，以及它们之间的差异如何影响那些您期望同时在两种运行时中运行或进行迁移的 Portlet。

表 1. 在迁移中产生差异的功能清单。

处理 URL Handling 的页面聚合

WebSphere Portal 门户页面聚合框架使您可以轻松地在页面上组织 Portlet，从而使最复杂的页面结构变得容易处理。使用 WebSphere Application Server，您可以轻松地在一个页面上显示一个 Portlet；因此，它不需要对多个 Portlet 和页面进行特别处理。即便如此，在这一部分中，我们仍然需要解决一些难题。例如，尽管在两种环境中导航状态处理在概念上相似，但其处理方式仍存在一些细微的差异。

每个 Portlet 可以在其标记中呈现多个引用同一页面上的 Portlet 的 Portlet URL。这一功能通常是通过调用 createRenderURL 或 createActionURL 实现的。

通常，向 Portlet URL 添加呈现参数（作为 Portlet 的导航状态的组成部分）的目的在于使 Portlet 的特定视图支持书签，并支持前进和后退按钮操作。然而，此操作不是 JSR 168 Portlet 规范强制要求的。通过将这些参数附加到 Portlet URL，用户可以将特定视图直接定向到某个 Portlet。这样做的好处受到 URL 最大可用长度的限制。

为了支持书签和直接定向功能，我们建议每个 URL 都包含导航状态信息，至少包括所请求页面上的所有 Portlet 的全部呈现参数。不难想象，包含此类信息的 URL 容易变得很长。

由于页面聚合产生长 URL 的风险很高，因此，WebSphere Portal 利用各种高级功能（例如压缩）和其他存储方式（例如 HttpSession）来处理过长的 URL。因此，WebSphere Portal 创建的所有 URL 都是有效的，但是它们并非都支持书签。您可以通过高度可配置的 URL 处理方式来改变结果。

WebSphere Application Server 与 WebSphere Portal 不同，它并未提供配置 URL 处理方式的高级功能。WebSphere Application Server 将所有呈现参数附加到 Portlet URL，而不管 URL 是否过长。因此，由基于 WebSphere Application Server 的 Portlet 创建的所有 URL 都支持书签；但遗憾的是，这种做法有负面影响，即那些使用长呈现参数或大量呈现参数的 Portlet 可能导致无效的 URL。然而，与那些每个页面上通常都包含多个 Portlet 的门户框架相比，其风险较低。

通常，我们建议 Portlet 尽可能使呈现参数的数量和长度保持最小，从而降低产生无效 URL 的风险。由于在参数处理方面存在差异，URL 很长时的风险在于，在 WebSphere Portal 上运行良好的 Portlet 在 WebSphere Application Server 上运行可能失败。

在 WebSphere Application Server 上运行时，Portlet 可能由于 URL 过长而导致超出浏览器限制和出错。例如，包含 80,000 个字符的 Portlet URL 可以使用 Mozilla Firefox 呈现，而 Microsoft® Internet Explorer 不会对引用如此长 URL 的链接作出反应。

安全方面的用户管理

WebSphere Portal 对用户管理和扩展安全性概念提供完全支持。登录到门户的用户仅能查看和处理该用户拥有必要访问权限的 Portlet 的内容。Portlet 可以根据 JSR168 Portlet 规范 (PLT17) 中指定的用户信息编程模型检索有关当前用户的信息。

WebSphere Portal 用户管理基于 WebSphere Member Manager (WMM)，它使您可以轻松地集成第三方用户管理系统。由于与 WMM 紧密集成，Portlet 可以根据通过下列方式提供的数据请求有关用户的详细信息：

• 由此后端用户管理系统提供；
• 映射到可用于 Portlet 的某个用户信息属性名称（JSR 168 Portlet 规范 1.0，PLT.D）；
• 在 Portlet 部署描述符中根据 JSR 168 Portlet 规范 1.0 对特定 Portlet 进行配置。

WebSphere Application Server 提供了一个名为 Virtual Member Manager (VMM) 的用户管理系统。目前未将 Portlet 容器与 VMM 集成，因为这种类型的复杂功能需要通过门户框架提供。

Portlet 可以引用用户信息，以针对每个用户的特点作出不同的反应。虽然 WebSphere Application Server 中的 Portlet 容器无法访问功能丰富的用户管理，但是在两种平台上，Portlet 都可以通过 PortletRequest 中的 getRemoteUser() 或 getUserPrincipal() 访问用户信息。正如 JSR168 Portlet 规范 (PLT.11.1.6) 中所描述的，Portlets 还可以根据 Portlet 部署描述符中定义的 user-in-role 映射访问安全属性 isUserInRole。

在 Portlet 和页面特定访问控制管理方面，WebSphere Portal 提供全面的安全性管理，允许您控制用户操作。例如，只有拥有足够访问权限的用户才能使用 Portlet 的编辑模式，以自定义 Portlet 首选项。

WebSphere Application Server 中的 Portlet 安全模型与 Servlet 安全模型保持一致，这是因为与 Servlet 类似，只能通过 URL Addressability 对 Portlet 进行寻址。由于 Servlet 安全模型不允许聚合情况，因此，WebSphere Application Server 中的 Portlet 运行时未提供用户或访问控制管理来处理 Portlet 或页面。

只要 Portlet 不是基于 Portlet 部署描述符中定义的安全角色引用，就可以在两种平台上运行。这些安全角色引用目前仅受 WebSphere Application Server 支持。

总之，通过关联编程模型，您可以创建能够在两种平台上运行并根据用户信息采取行动的 Portlet。此外，WebSphere Portal 还提供成熟的 Portlet 和页面访问控制管理，用于管理用户对 Portlet 的调用。

Portlet 首选项和模式

接下来，让我们看看 Portlet 首选项和模式。

首选项保持层状结构，可以基于 Portlet 模式对其进行修改。例如，有一个由 Portlet 部署描述符定义的缺省首选项层。该层在 WebSphere Portal 支持的 CONFIG 模式下可修改。在 WebSphere Application Server 中，Portlet 部署描述符的值是只读的。

WebSphere Portal 提供一个额外的首选项层，允许门户管理员为每个 Portlet 窗口指定不同的缺省值。此功能由 Portlet 模式 EDIT_DEFAULTS 提供支持，并适用于所有使用相同 Portlet 窗口的用户。在 WebSphere Application Server 中没有类似的首选项层。

两种产品都支持标准模式：VIEW、EDIT 和 HELP。当用户在任意标准模式下自定义一个页面上的 Portlet 时，该用户可以更改其个人 Portlet 首选项。在任何标准模式中都不能基于每个页面或基于每个 Portlet 设置缺省首选项；可能需要使用定制 Portlet 模式来实现。

在 WebSphere Application Server 中，最终用户可以为任意自定义 Portlet 模式调用 Portlet 方法。除非某个自定义的聚合框架更改了行为，否则只有标准 Portlet 模式按 JSR 168 Portlet 规范 (PLT.A) 所预期和指定的方式执行。也就是说，在自定义模式下调用 Portlet 时，所有首选项都存储在与标准模式下（VIEW、EDIT 和 HELP）相同的范围中。因此，可以在 CONFIG 或 EDIT_DEFAULTS 模式下调用该 Portlet，但是该 Portlet 模式不会对首选项层产生影响。因此，不能修改任何缺省首选项的值。

总之，这两种产品支持所有标准 Portlet 模式。只有 IBM WebSphere Portal 完全支持 Portlet 模式 EDIT_DEFAULTS 和 CONFIG，这两个模式允许修改某个页面或 Portlet 范围中的缺省首选项的值。

Portlet 片段缓存

Portlet 片段缓存是基于 WebSphere Application Server 的动态缓存功能 (Dynacache)。因此，可以使用 cachespec.xml 对在 WebSphere Application Server 中运行的 Portlet 的缓存键进行详细配置。有关详细信息，请参阅 WebSphere Application Server 信息中心中的 Configuring cacheable objects with the cachespec.xml file 主题。

相反，WebSphere Portal 允许使用 ibm-portlet-portal-ext.xmi 文件进行有限的配置。目前，cachespec.xml 对于在 WebSphere Portal 上运行的 Portlet 没有作用。

在 WebSphere Portal 中，缓存内容的作用范围缺省是每个用户。为了使所有用户可以使用反向代理共享相同的 Portlet 输出，您可以将 remote-cache-scope 设置为共享：

<portlet href="RemoteCacheSettingsTestPortlet">
   …
    <remote-cache-scope>SHARED</remote-cache-scope>
   …
</portlet>

这与在 cachespec.xml 中指定缓存键不将 sessionid 作为键的一部分相对应。当您将 sessionid 定义为缓存键的一部分时，Portlet 内容是在每个用户的基础上进行缓存。对于在 WebSphere Application Server 上运行的 Portlet 来说，共享 Portlet 缓存内容是缺省行为，因此，当 Portlet 开发人员希望按用户界定缓存内容的作用范围时，必须明确地指出。

假设您希望将原本为 WebSphere Portal 编写的 Portlet（其内容按用户缓存）迁移到 Application Server。为了支持按用户缓存，Application Server 管理员需要指定 cachespec.xml 中的缓存键使用 sessionid。

<cache-entry>
   <class>portlet</class>
    <name>/CacheTestPortlet</name>     
    <property name="consume-subfragments">true</property>
    <cache-id>
       <component id="" type="sessionId"/>
       <timeout>0</timeout>
    </cache-id>
</cache-entry>

与共享缓存相反，由 Portlet 部署描述符指定的 expiration-cache 通常为缓存的 Portlet 输出配置独立于环境的过期时间。

Portlet 包含的子片段（例如，JSP）在 WebSphere Portal 中作为 Portlet 内容进行缓存。这一项对于在 WebSphere Application Server 上运行的 Portlet 是可配置的。为了启用子片段缓存，您可以将 cachespec.xml 中的属性 consume-subfragments 指定为 true。WebSphere Application Server 在缺省情况下不缓存子片段。

<property name="consume-subfragments">true</property>

从 Portlet 编程的角度来看，Portlet 可以按照 Portlet 规范 (PLT.18.1) 中指定的方式配置缓存。Portlet 部署描述符可以定义 expiration-cache 时间，并且可以允许以编程方式在运行时通过设置预定义的响应属性 javax.portlet.PortletResponse.EXPIRATION_CACHE 来更改此配置。

您可以在两种环境中更精确地配置 Portlet 片段缓存，但是这些扩展是特定于门户的，并且在 WebSphere Portal 和 WebSphere Application Server 中有所区别。因此，根据所处的环境，缓存配置在某种程度上需要进行个别设置。

总之，两种环境都允许您在 Portlet 部署描述符中指定缓存设置。扩展缓存设置是特定于门户的；对于 WebSphere Portal，可以在 ibm-portlet-portal-ext.xmi 文件中配置缓存设置；对于在 WebSphere Application Server 上运行的 Portlet，可以在 cachespec.xml 中配置。

回页首

扩展编程模型

在前面的主要部分，您了解了实现 JSR 168 Portlet 规范的 Portlet 环境的区别。在这一部分，您将了解除 JSR168 Portlet 规范提供的功能之外还封装了其他所有功能的扩展编程模型。

WebSphere Portal 和 WebSphere Application Server 在所提供的 Portlet 运行时环境方面存在差别；该环境通常称为门户框架 或门户引擎。为了理解 WebSphere Portal 和 WebSphere Application Server 在扩展编程模型方面的差别，我们将对它们包含的不同插接点和 Portlet 规范范围之外的门户功能进行比较。

WebSphere Application Server 编程模型

本系列文章首先说明了为 WebSphere Application Server 上运行的 Portlet 提供的编程模型和扩展。如第 3 部分中所述，WebSphere Application Server 的一些扩展功能是为 Portlet 提供的，例如，性能监视基础结构或请求度量。

其他 WebSphere Application Server 功能经过扩展以支持 Portlet 特定的需求。例如，Remote Request Dispatcher 也可用于 URL 可寻址 Portlet。这意味着 Portlet 可以在不同的 JVM 上运行，并可以通过远程调用来引用。

因此，WebSphere Application Server 的编程模型包含 Portlet 规范 JSR168 的所有强制部分，以及本系列文章说明的编程模型扩展部分。

WebSphere Portal 编程模型

虽然 WebSphere Portal 为 Portlet 标准化编程模型提供了大量的扩展，但是这一部分仅描述其中的几个扩展。分析全部扩展超出了本文的范围。

WebSphere Portal 提供了有意义的 Portlet 服务集，以提供额外的功能，例如，凭据库和内容访问服务。PortletServices 概念使您可以使用自定义 Portlet API 扩展来对 Portlet 编程模型进行扩展。您也可以向 Portlet 编程模型添加功能。

此外，WebSphere Portal 还提供 Portlet 框架支持。利用其完整的聚合平台，WebSphere Portal 允许在一个页面上聚合多个 Portlet 框架。因此，一些 Portlet 框架得到支持，并且应该遵循一些最佳实践，例如，优秀的模型-视图-控制器 (Model-View-Controller) 设计。支持的 Portlet 框架的示例有 Java Server Faces (JSF) 和 Struts 框架。

表 2、3 和 4 列出了 WebSphere Portal 提供的超出 JSR168 Portlet 规范强制范围的额外功能。

表 2. 支持的可选规范部分功能

当使用这些门户扩展的任意功能时，如果这些功能不可用，请确保适当地对其进行缩减。如果 Portlet 开发人员遵循此指导原则，那么这些 Portlet 也可以在 WebSphere Application Server 上运行，即便是这些扩展不可用。以下代码片段显示使用 WebSphere Portal 的 Portlet 服务扩展的相应示例：

// check for extension availability
Object obj = null;
javax.naming.Context ctx = 
new javax.naming.InitialContext();
try {  
  obj = (Object) ctx.lookup("portletservice/com.mycomp.CalcService");
  } catch(javax.naming.NameNotFoundException nnfe) {
 ... error handling ...
 }
// service usage (best to move in own class)
if ( obj != null ) {
  PortletServiceHome psh = (PortletServiceHome) obj;
  CalcService service = (CalcService) psh.getService(CalcService.class);  
  service.calculate();
}

为了增加为 Portlet 提供的致力于在多个门户平台上运行的功能范围，IBM 正在帮助定义 Java Portlet Specification Standard JSR 286。WebSphere Portal 中已提供的许多有用的扩展将以更通用的形式标准化。例如，Portlet API 2.0 建议标准化 Portlet 之间的通信和 Portlet 筛选器扩展。

回页首

迁移主题

通过在 Portlet 编程模型和扩展方面对 WebSphere Portal 和 WebSphere Application Server 进行比较，您现在了解了它们之间的差别，以及会出现哪些迁移问题。

根据经验，Portlet 开发人员应该记住，只要独立于任何门户特定扩展开发 Portlet，那么该 Portlet 就可以在两种平台上运行。表 5 列出了本文描述的迁移主题。

表 5. 针对 Portlet 开发人员的迁移快速参考

回页首

结束语

这一部分以 WebSphere Application Server 中的 Portlet 容器作为本系列文章的结束。

在此系列文章的最后部分，您了解了 WebSphere Portal 和 WebSphere Application Server 在 Portlet 运行时方面的差异。尽管两种 Portlet 容器基于相同的技术，但是每种门户框架在目标和扩展方面有差别。

理解 WebSphere Portal 和 WebSphere Application Server 之间的差别可以帮助您解决 Portlet 应用程序的迁移问题。对两种编程模型的说明和比较讨论了您可以在两种环境中轻松使用的那些功能。如果注意到扩展功能，那么开发人员也可以实现根据可用的编程模型扩展以不同方式运行的 Portlet 应用程序。

通过很好地了解本文中讨论的两种产品，您可以正确地使用每种产品，并且创建能够在两种平台上运行的即时可用的 Portlet 应用程序，此外，当给定的运行时未提供指定功能时，可以充分利用已提供的功能集或适当地缩减功能。