级别： 初级 Skyler Thomas (tskyler@us.ibm.com), STSM，客户解决方案首席门户架构师, IBM Software Group
2005 年 5 月 18 日 在这篇一问一答的文章里，我们邀请客户解决方案首席门户架构师 Skyler Thomas 来回答关于 WebSphere Portal 的问题。
引言
在本文中，Skyler 回答了关于 IBM® WebSphere® Portal（以下称为 WebSphere Portal）应用程序的架构与设计问题，包括硬件拓扑与开发和部署架构、安全与单点登录、内容管理与个性化，以及一般 WebSphere Portal 最佳实践。WebSphere Portal 是一种中间件平台，用于构建和管理安全的企业到员工 (B2E)、企业到企业 (B2B) 和企业到客户 (B2C) 门户应用程序。
问：决定一个门户项目成功与否的最关键因素是什么？
答：一个成功项目与对门户项目所做的负载测试的数量之间几乎存在着一一对应的关系。我还从未见过因为 Portlet 难于构建或者 WebSphere Portal 不能完成某一功能而导致项目失败。我曾遇到许多这样的情况：由于未能进行足够的压力测试而没有揭示 Portlet 中的问题、后台系统配置不正确，或者因缺少缓存而导致性能问题。这些问题仅在生产中被揭示出来，给每一个相关人员都带来了难以置信的痛苦。
在讨论门户时，我喜欢引用 Skyler 门户定律：
- 第一门户定律——所有的问题现在都是因为门户的错误。如果正确完成，那么门户最终将使组织的一切都居于前列。这意味着会将所有 IT 问题归咎于门户团队。
- 第二门户定律（第一定律的推论）——WebSphere Portal 将测试企业中的所有组织缺陷。由不同 IT 团队支持、项目之间存在很大隔阂的 IT 系统会导致不同团队之间产生关于门户项目的摩擦。
问题就在于此。门户是许多不同 IT 项目的粘接层。一个链条的强度取决于其最弱的一环，WebSphere Portal 与此不完全相同，但也有一些相似之处。如果不采取特殊措施，防止后台系统的崩溃、不可用、可伸缩性差或性能对门户产生影响，那么这些故障中的任何一个都会对了解企业的门户产生影响。而且还因为门户是其所用全部后台系统的一个联合，所以这些问题通常会在组织内引发一连串的相互指责。因此，我们建议进行以下压力测试过程。
甚至在编写任何门户代码或者将其连接到后台基础设施之前即开始压力测试。在添加新的后台系统（例如，连接到 Documentum 或查询 SQLServer）或创建新的 Portlet 时，要反复进行新的压力测试。这使您能够迅速隔离问题组件，还使您能够在生命周期的早期隔离问题（这时还有时间来解决这些问题）。我的许多客户在项目末期分配两到三周的时间来进行压力测试。结果是当他们发现一个子系统有问题时，他们不得不将其从门户中取出，在没有该组件的情况下重要配置测试。这样做会消耗大量时间，并且容易导致错误。通常，他们最终不得不取出所有组件，开始一个新的基准测试。这发生在生命周期的某一时刻，这时所有人都紧张不安、团队每周工作 120 小时。这样很难按时发布。
所以，我还引用第三定律：
-
第三门户定律——早期开始并连续进行压力测试是防止前两条门户定律破坏您的项目的唯一方式。
问：在实现 WebSphere Portal 时，我对整理需求感到非常棘手。是否有用于 WebSphere Portal 的预定义用例集？例如，登录、更新配置文件、管理授权等。如果我希望集成 Domino 或客户应用程序，每一集成点 (Portlet) 是否就是一个用例？
答：非常令人惊讶，需求阶段是门户项目中最富技巧性的阶段之一。不存在用于 WebSphere Portal 的预定义用例集。但是，确实有一些一次又一次出现的用例。登录、更新配置文件等，都是一些常见用例的例子。但是，在处理用例时，我并不相信门户与其他任何项目有什么不同，也不相信您需要遵循一般的最佳实践来决定什么值得用例分析。我相信用于每一集成点的单一用例不可能都具有正确的粒度级别。您应当尝试围绕功能领域组织用例，这可能意味着每一集成点有多个用例。
这就是说，我准备表达一个富有争议的观点。我见过很多门户项目仅仅依靠用例分析来收集需求，这些门户项目可能会存在许多问题。首先，因为门户全是关于用户界面的，所以创建需求的业务人员对这些需求的关心要多于传统项目。由于用例的非书面本质，以及它们主要关注于性能而不是外观，所以可能会导致许多对用户非常关键的需求被遗漏。因为用户关心这些未捕获的需求，所以他们通常会促使门户开发团队对门户进行许多重复修改。这些修改中有一些是简单的修饰性更改，有一些是对功能和内容的根本性重新组合。这并不是说不应当在您的项目中继续发挥用例的作用。它们仍然非常有用。但是，我推荐一种我称作 Portlet Sourcing 的附加练习。这一思想是以可视化方式收集来自用户的要求。既可以通过白板会话以一种低保真度的方式完成，也可以通过一组线框以高保真度的方式来完成。
这一可视化建模完成两件事情。第一，它强制企业尽早考虑外观问题，并为他们提供一个论坛来创建这些需求。第二，它使开发团队能够在一切都成定局之前确认棘手的用户界面需求。您经常会看到用户创建可视化需求需要做大量的开发工作。在许多情况下，需求的简单变化会极大地降低开发工作量。利用一种可视化设计方法，开发人员可以很容易地表达一个问题，并建议一个用户可接受的替代方式。在完全口头的方式中，可能会以一种几乎神圣的敬重方式来对待用户的话。而可视化设计可以看作是可扩展的。
在进行可视化建模之后，Portlet 采购方法转到第二练习。获取所创建的每一个页面，并将其分解为各个组件。对于每一个组件，开发人员和企业用户应当回答一长串具体问题。其中一些问题包括诸如“用于特定组件的后台数据归谁所有”之类的问题。我已经记不清有多少次看到用户需要一个新闻 Portlet，但却没有确认是由谁来创建新闻。理解后台所有权关系的其他原因包括：如果后台系统每星期只能用 6 天，而您需要该门户的可用性达到 99.999，那应当怎么办？如果后台系统失去了资金支持，应当怎么办？如果界面发生了变化，又应当怎么办？
如果您希望安排一个工作间来进行有关 Portlet 采购的讨论，请让您的软件销售代表联系我的小组
IBM Software Services for Workplace, Portal, and Collaboration。
问：当在 B2B 门户中共享客户数据时，客户机管理人员的一个常见要求就是在门户中能够看到的内容与客户机所看到的内容完全一致。可以通过什么最佳安全途径来满足这一要求？
答：您所描述的情况，我们称之为“用户模拟”。在我准备描述如何实现这一行为时，我想先以一个一般警告作为开始。任何实现这一行为的系统其本质都是不安全的。当然，我们可以做一些事情，将这些安全问题减轻至一定程度，事实仍然是我们正在显式地允许某个人来模拟用户。许多安全实现都进行一个基本假定，即与其进行交互的用户是一位真实用户（考虑到审核等）。WebSphere Portal 是这些做出此隐式假定的技术之一，当您准备违犯这一假定时，您必须清楚正在放弃什么。
用户模拟在概念上很简单。我们使 WebSphere Portal 把我们考虑为实际的被模拟用户。要正确进行用户模拟，最好拥有一个像 Tivoli® Access Manager 或 Netegrity® Siteminder 这样的 SSO 系统。大多数 SSO 系统允许您编写登录事件的脚本。您以客户机管理人员的身份登录，并选择您希望模拟的用户的姓名。接着登录脚本检查访问权限。假定一切都正常工作，那么 SSO 系统向 HTTP 头信息中写入三条信息：所模拟的用户 ID，一个表明为被模拟会话的标志，最后一个是“真正的用户是谁”。安装于 SSO 系统 WebSphere Application Server 中的 Trust Association Interceptor 取得所模拟的用户 ID，并创建一个该门户将使用的 WebSphere 标识。您还希望创建一些附加代码，以使用其他头信息值来警告 Portlet 不应当执行那些不可供客户机管理人员使用的操作，并允许审核实际用户的凭证记录。请注意，您正在依靠您的 Portlet 编写人员来执行可选行为。对于许多类型的应用程序来说，这样做并不安全。如果您正在编写一个联机银行门户，您是否真的愿意相信 Portlet 编写人员不会安装一个后门或者创建一个错误，使一个用户模拟者泄漏某个人的账户？诚然，这是一个有点极端的例子，所以在使用这一方法时要多加小心。
问：怎样才能使 WebSphere Portal 的安装变得容易？
答：从您的话中可以感觉到，您对 WebSphere Portal 的旧版本感觉不好。而我坚持认为，WebSphere Portal 现今已经成为最容易安装的产品之一。其中有几个原因。在 5.0 版本之前，我们采用了一种似乎比较好的安装方法，但结果却存在很多问题。我们尽力使安装变得更精巧些。我们的思想是应用自动尝试配置门户，以满足您的环境。因为所有的客户都是唯一的（请相信我，我已经见过 200 多种环境），门户安装程序几乎有无限多个变量需要我们修改。这导致两个主要问题。第一，如果在评估环境时犯了任何错误，就非常有可能破坏其安装。第二，为避免不明确的情况，它搜索了过多的第一手资料。在您可以完全安装 WebSphere Portal 之前，您必须了解自己环境的所有情况，例如 Oracle®、LDAP、Domino 等等。
在 WebSphere Portal 的 5.0 版本中，开发人员对安装过程进行了非常大的修改。首先，他们将安装分为两块：基础安装与配置。基础安装的目标是确保您在安装过程中绝对不会失败。我们希望确保安装 WebShpere Portal 的一个工作副本，您可以对其进行测试。采用这种方式，当您进入配置步骤时，对于您所做出的任何改变，可以立即识别出那些容易导致破坏的变化（将 DB 改为 Oracle，移至 LDAP，等等）。他们的第二个主要变化是使用户可以对配置步骤编写脚本。他们使用 ANT 进行配置。大多数 J2EE 开发中心都有一些 ANT 脚本编写经验和一些不能从书本中快速学习的知识。对于常用环境设置的许多情况，您不必修改配置脚本，但如果需要，能够对配置脚本进行修改则更好，第三个变化是极大地改进了安装记录。他们尽力使记录更为详细，并在最低级别捕获信息，而不是记录大量含义不清的消息。在这一领域，我们看到无问题安装从先前 5.0 版本的 20％ 用户上升到进行修改之后的 95％。
在 5.0 版之后并不会停止发展。在 5.1 中，他们增加了许多项目，使得安装过程变得更好。他们增加了存档安装（以帮助那些拥有大型门户集群的开发中心）、为那些环境复杂程度较低的 SMB 客户所提供的更多 GUI 选项，以及将组件更好地打包在一起。
问：我希望测试 Portlet 或页面。但为此，我需要拥有真实 URL。由于 WebSphere Portal 5.0 是动态生成 URL，所以我没有这些 URL。我怎样才能进行测试？
答：您已经注意到，在 WebSphere Portal 5.0 版和更低版本中，URL 的生成采用一种不常见的方式。一个门户 URL 包括有该门户状态的动态变化 (delta)，而不是对该门户资源的直接链接。这意味着不可能使正常的 5.0 URL 完成您希望完成的事情。不过，您的确还有几种选选择。在 WebSphere Portal 5.1 版中，URL 是以一种完全不同的方式进行处理的。5.1 版 URL 真正地直接链接至门户资源。这意味着您不会再遇到这些困难。但仅仅为了测试就移植到 5.1 版，显示得有点过激了。另一个选项是使用可以处理动态 URL 的不同测试软件。尽管这一方法对于其他原因是一个非常有用的选项，但可能不是您所寻求的答案。一个更好的想法是使用 WebSphere Portal 中的 Friendly URL 功能。利用友好的 URL，您可以为门户资源创建真实 URL。
问：我最近安装了 WebSphere Portal 5.1 并计划与我的客户一起合作开发一些 Portlet。我们如何在标准 Portlet 和
JSR-168 Portlet 之间做出判断？您对此有什么建议？
答：假定您正在使用 V5.1，我们对所有的新 Portlet 推荐使用 JSR-168 Portlet。如果您正在使用 WebSphere Portal 5.1 版之前的版本或移植到 5.1 中，答案可能就有所不同了。要指出的是，这里假定通过使用 JSR-168 Portlets，您可以在非 WebSphere Portal 服务器中使用它们。这一假定实际上并不是真的。在构建您的 Portlet 时，利用由 WebSphere Portal 服务器所提供的许多功能与服务，如一点即动 (click-to-action) 和人员识别 (people awareness)。看起来，使代码不要依赖于任何特定供应商的门户实现似乎更好一些。但这却是一种错误的经济方式。我们所处的门户世界里，J2EE 社区于 1999 年就存在了。我们现在拥有自己的 Servlet 规范版本，但是其他的许多东西还没有在供应商之间进行标准化。希望一段时间之后这一情况会有所改进。在此期间，如果在有更多的标准出现之前您试图防止受制于某个供应商，则无异于割喉自杀。您需要重新编写门户供应商为您提供的全部服务，这会严重耽搁您的项目进度。如果您是 Portlet 供应商，绝对不值得为此耗费时间或金钱。
问：进行 Portlet 单元测试的最佳实践或方法是什么？在部署过程中，我们需要对所有 Portlet 进行单元测试。我们应当能够运行类似于 Junit 的测试。目前，没有工具可用于对 Portlet 进行单元测试。在近期，是否有计划支持 Portlet 单元测试？
答：这是一个很好的问题，没有真正很好的答案。我本人极力主张进行单元测试，并一直非常喜欢 JUnit。当然，即使在 portal 世界里，JUnit 仍然有价值。您仍然希望利用 JUnit 为那些没有利用 Web 而调用的逻辑创建单元测试。对于需要利用 Web 的内容，有几种与 JUnit 类似的项目。它们并非门户所特有的。我最喜欢的是
Apache Cactus project。当然，Cactus 并非包治百病的灵丹妙药。我的确正在等待着第一位富有灵感的开发人员来创建 PortletUnit。
问：我们正尝试评估 WebSphere Portal 5.1 在 Solaris ® 平台上的硬件需求。您有什么建议吗？
答：是的，一个主要建议。请与您的软件销售代表进行讨论。他们可以帮您设置 Techline 规模。IBM Techline 将要求您填写一个简短的调查表，说明您所建议的门户及其预计使用量度。Techline 将输入这一信息，并根据您选择的硬件平台（包括 Solaris）输出大小调整建议。
问：我希望了解当用户在使用门户页面中的 Edit Layout 选项时，我们能否让他们只添加特定的 Portlet 集。是否有可能？如有可能，应当怎么做？
答：在页面的高级属性中，您可以指定一个所允许的 Portlet 列表。请参见
WebSphere Portal Information Center 中的“管理页面”。
问：目前，RAD 6.0 不允许开发能够运行于 WebSphere Portal 5.1 上的门户项目。什么时候将对 5.1 版启用这一功能？
答：您可以下载 RAD 6.0.0.1 fixpack。安装此 fixpack 之后，您就可以构建和测试 WebSphere Portal 5.1 项目了。
问：您能否共享一些与 Websphere Portal 服务器产品发展路线的一些详细信息？是否已经开始开发 WebSphere Portal 服务器 6.0 版？我们可以期望在 6.0 版中看到哪些新的功能，它将在什么时候发布？
答：这的确没有乐趣，但我们不能讨论还没有发布的未来产品。WebSphere Portal 今天已经是一个非常成熟并且拥有丰富功能的产品。您将感到非常惊奇，您只需做最少量的工作即可以对该产品进行大量的扩展。但是，我可以说开发实验室正在酝酿很多有趣的新功能。如果您需要发展路线，请与您的软件销售代表讨论，以提出一个简报。我还将说明，在下一个
Fixpack 出现时，就会展示许多新的功能。请随时关注它，很快就会发布。
参考资料
关于专家访谈
专家访谈是 WSDD 上的一个很有特色的每月专栏。我们可以让您接触到有关 IBM WebSphere 的最好思想以及随时准备回答您问题的产品专家。您来提出问题，我们将公布最受欢迎的问题的解答。
参考资料
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
关于作者
对本文的评价
| 
