WebSphere Application Server 常见问题及解答(一)

WAS 简介

IBM WebSphere Application Server，即 IBM 的 WebSphere 应用服务器，是 Java EE 和 Web 服务应用程序平台，是 IBM WebSphere 软件平台的基础。WAS 交付了安全、可伸缩、具有弹性的应用程序基础架构，帮助构建、运行、集成和管理动态、随需应变的业务应用程序。这些基础架构是实现面向服务体系结构（SOA）所需要的。

不同的业务应用场景要求不同级别的应用服务器功能，WAS V6 提供了几种不同的产品包。每个产品包针对不同的解决方案和需求。业务增长时，您可以根据迁移指导升级到 WAS 产品家族中支持更高级别需求的产品包:

WebSphere Application Server Community Edition V1
WebSphere Application Server - Express V6
WebSphere Application Server V6.1
WebSphere Application Server Network Deployment V6.1
WebSphere Application Server for zOS V6.1
WebSphere Extended Deployment V6



产品功能

1. WAS V6.1 中的新增功能有哪些？
2. WAS 中附带的开放源码项目有哪些？
3. WAS 是否支持动态增加服务器，即在原业务系统不停机的情况下动态增加服务器？
4. WAS 是否支持目录服务 LDAP？请列举所支持的 LDAP 服务器。
5. WAS 可以实现Load Balance功能， 这与 WAS Network Deployment 的实现有什么区别？
6. WAS Network Deployment 支持运行混合版本的单元吗？
9. WebSphere Application Server 中附带的某些开放源码实现是什么版本的？
10. 什么是 WAS 的功能部件包？具体包含哪些内容？



1. WAS V6.1 中的新增功能有哪些？

答： WebSphere Application Server V6.1 进一步扩展了 WebSphere Application Server V6.0 中提供的功能，在多个关键领域增加了许多旨在提高可用性的功能：

· 系统管理：

o 控制台已重新设计，导航更加方便，并且添加了许多指导任务和快速路径对话框，可以更加快捷地配置和管理通用操作。

o 在管理控制台（现在使用 Portlet 实现）和 wsadmin 脚本语言中，都有许多管理方面的改进。

o 还可以使用命令帮助，该帮助详细解释了wsadmin 命令。这使得创建管理脚本比以前任何时候都更加方便。

· 安全性：

o 缺省情况下，现在使用基于文件的注册中心启用安全性。此外，还可以将多个独立的注册中心映射为单个联合注册中心，称为 Virtual Member Manager。可以使用这些注册中心替换基于文件的注册中心或者将其添加到基于文件的注册中心。

o 密钥管理现在已集成到 WebSphere Application Server 管理（控制台和 wsadmin）中并与其关联。DummyKeyRing 不再随产品一起提供，而是在创建概要期间生成唯一密钥（即使不启用安全性也是如此）。

o 基于实例的管理可用于计算单元、节点、服务器和应用程序，从而支持将所有这些范围的命令行管理限制于某个特定角色或组（在控制台中还没有实现基于实例的管理）。

o 对于需要 Windows 单点登录（SSO）解决方案的情况，现在有基于 SPENGO 的 TAI（Trust Association Interceptor），它允许基于 Windows 的 Web 客户端使用 Windows 登录，当其访问 WebSphere Application Server 中运行的应用程序时无需再次登录。

· Portlet 容器：

o 除了可以将 Portlet 用于管理控制台实现之外，JSR-168 兼容的 Portlet 容器现在已是 WebSphere Application Server V6.1 的一部分。

o 不仅 Portlet 是受支持的编程选项，会话启动协议（Session Initiation Protocol，SIP）Servlet 也同样受支持——此外还有熟悉的 HTTP Servlet。所有这三个 API 都已在聚合的容器中实现，从而允许应用程序中的这些 API 之间共享应用程序状态。

o Java™ 2 Standard Edition 5（J2SE 5 或 JDK 5）支持对编程模型的另一项重要 developerWorks 中国站点：ibm.com/developerworks/cn/ 8 IBM WebSphere Application Server 常见问题及解答增强，它不仅提供了附加的 Java 语言 API（如 Generic、Annotation、Enumeration 和 AutoBoxing），而且大大提高了 J2SE 5 上的 WebSphere Application Server 运行时实现的性能。 还增加了许多 Web 服务增强功能。

o

· Application Server Toolkit：

o Application Server Toolkit（AST）为创建面向 WebSphere Application Server V6.1 的新应用程序提供了基本的支持。其中包括用于创建新的 Web 应用程序、Web 服务、Portlet、EJB 组件的各种向导和工具，以及基于注释的编程支持、新的管理工具、用于编辑 WebSphere 特定绑定和扩展的工具，等等。

o AST还包括了 J2EE 透视图和 Web 透视图、Eclipse 3.1 和 Eclipse Web Tools Platform（WTP）Version 1.0。它本身是一个完整的 J2EE 开发环境，因此您可以使用它构造、调试并直接将新的应用程序部署到 WebSphere Application Server V6.1。


有关 WAS 6.1 新特性的更多资源，请参阅 developerWorks 中国站点的文章：

· WebSphere Application Server V6.1：Version 6.1 中的新特性

· WebSphere Application Server V6.1：安全新功能

· WebSphere Application Server V6.1：Web 服务方面的新特性



2. WAS 中附带的开放源码项目有哪些？

答： WAS 6.1中附带有以下的开放源码项目：

· XDoclet
XDoclet 是一个开放源代码项目，它简化了自动的部署描述符的生成。XDoclet 不以独立文件的方式维护配置信息，而是允许使用特殊的 Javadoc 标签在 Java 源代码中嵌入配置信息。然后，它使用额外的元数据来生成类似部署描述符和源代码的相关文件。这个概念被命名为面向属性编程（attribute-oriented programming）。使用 XDoclet，可以将配置信息与源代码保存在一起，这样需要跟踪的事情就都在一个地方了。 XDoclet 实际上不只是擅长生成配置文件。它最初的设计目标是用于 EJB，除了实际的配置文件之外，对于每个 bean，EJB 还需要多个样板文件。XDoclet 可以根据基本的 bean 源代码（受特殊的 Javadoc 标签控制）替 EJB 生成这些样板文件。随着 XDoclet 已经扩展成可以处理许多 EJB 之外的其他应用，这个代码生成功能也得到了扩展。在需要样板代码的地方，它是极为有用的工具，可以帮助源代码树消除那些对应用程序的操作毫无用处的混乱。
目前 WAS V6.1 中所支持的 XDoclet 的版本包括 V1.2.1, V1.2.2, V1.2.3，XDoclet 可以为 web（web.xml）、ejb、struts（struts-config.xml）、webwork、hibernate（mapping file）、jdo、jmx 等等生成描述文件、源码等。此外，XDoclet 附带了使您能够创建 web.xml 文件、ejb-jar.xml 文件和许多其它文件的 Ant 任务，可以完全通过 Ant 来完成任务。
更多关于XDoclet 的信息，请访问：http://xdoclet.sourceforge.net/xdoclet/。


· Axis
Apache Axis 是 Apache SOAP 实施的第三代，其最初起源于 IBM的“SOAP4J”，属于最早的一批用于构造基于 SOAP 应用的Framework。 它使得 SOAP 引擎更灵活、更容易配置，借助于 W3C 开放式源代码，它还能够同时处理 SOAP 和将要实施的 XML 协议规范。Axis 基于 JSR 101 Java（TM）API for XML based RPC（也称为 JAX-RPC）。JSR 101 向任何基于 XML 的 RPC 机制（包括 SOAP）提供单个接口。 IBM 为 Apache Axis 项目提供了资源和代码，并在 WebSphere Application Server 和 Rational Application Developer 中以运行时的方式为 Axis 提供环境支持。您可以在 WebSphere Application Server 中作为一个客户端或服务器运行 Axis，但是 IBM 不支持 Axis 成为生产环境，也不提供对 Axis 的支持和修改。在生产环境中，请使用 WebSphere SOAP Engine，IBM 对此提供 7*24 的完全产品支持。
有关 Apache Axis 的更多信息，请参阅：

o http://xml.apache.org/axis

o http://ws.apache.org/axis



· XML
WAS使用的XML包的位置：[WASInstallDir]/java/jre/lib/xml.jar

xalan：Version XSLT4J Java 2.7.4

xerces：Version XML4J 4.4.5

XML Serializer Java 2.7.4

xmlcommons： IBM JAXP 1.3.5

· Apache Struts
Struts 是一个开放式源代码框架，用于构建使用“模型－视图－控制器”（MVC）体系结构的 Web 应用程序。Struts 框架具有控制器组件并且结合了其他技术以提供模型和视图，它把 Servlet、JSP、自定义标签和信息资源（message resources）整合到一个统一的框架中，开发人员利用其进行开发时不用再自己编码实现全套 MVC 模式。Struts 为 Web 应用程序提供了控制层，这会减少构造时间并帮助维护成本。目前 WAS V6.1 中所支持的 Apache Structs 的版本是1.2.4。有关 Apache Struts 的更多信息，请参阅 http://struts.apache.org/。

· Apache Commons Logging
Apache Jakarta Commons Logging 为多个日志记录系统提供了一个简单的日志记录接口和多个瘦包装器。日志记录接口使应用程序日志记录简单化并且与应用程序使用的日志记录系统无关。您无须更改应用程序日志记录代码就可以更改已部署应用程序的日志记录实现。但是，由于日志记录记录这种简单性，将使得应用程序无法利用日志记录系统的所有功能 WebSphere Application Server V6.1 通过为 WebSphere Application Server 日志记录工具提供一个记录器和瘦包装器来支持 Jakarta Commons Logging。记录器可以处理 Java 日志记录（JSR-47）和公共基本事件日志记录对象。日志记录对象是一个用来保存日志记录条目信息的对象。Jakarta Commons Logging 的 WebSphere Application Server 支持不会更改由 Jakarta Commons Logging 定义的接口。目前 WAS V6.1 中所支持的 Apache Commons Logging 的版本是1.0.3。
最佳实践： Jakarta Commons Logging 的缺省配置存储在 commons-logging.properties 文件中。要指定在应用程序中与 Jakarta Commons Logging 配合使用的工厂类，请提供位于 META-INF/services 目录中的文件 org.apache.commons.logging.LogFactory，该文件的第一行包含工厂类的名称。就像 JDK 1.3 及以上版本中定义的那样，这是 JAR 文件服务提供程序的配置机制。
要更好地理解 Jakarta Commons Logging，请参阅 http://jakarta.apache.org/commons/ 以及 Java 记录的规范和公共基本事件的规范。
要了解如何在 WAS 6.1 中配置应用程序以使用 Jakarta Commons Logging，请参阅：http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/org.eclipse.jst.ws.axis.ui.doc.user/tasks/tsklwsdla.html。


· Apache Ant
Apache Ant 是一个基于 Java 的开放式源代码构建工具。Ant 现在几乎已经是任何 IDE 都集成的编译工具了。为了编译一大堆java 源代码文件，需要一次次的在命令行敲重复的命令，Ant 可以让您编写命令脚本，然后让 Ant 自动完成复杂的编译工作，类似于Makefile，但 Ant 脚本是标准的 XML 格式，更容易编写和阅读。事实上，巧妙地使用 Ant，您可以让 Ant 自动完成编译，测试，输出文档，生成 Release 版本等一系列任务，使得整个项目流程自动化。由于 Ant 是基于 java 编写的，因此具有很好的跨平台性。它非常适合构建 Java 应用，同时也能被很好地用来构建其他的任务。其中一个重要的特性是您可以使用 Java 创建新的 Ant 任务来扩展产品的构建能力。目前 WAS V6.1 中所支持的 Apache Ant 的版本是1.6.5。
有关Apache Ant 的更多信息，请参阅 http://ant.apache.org。


· Apache Derby/Cloudscape
Apache Derby 是一种高质量的、纯 Java 的嵌入式关系数据库引擎，该项目是从 IBM 捐献给 Apache Software Foundation [ASF] 的一个基于 Java 的 Cloudscape 关系数据库发展而来的。IBM Cloudscape 是开放源代码 Apache Derby 关系数据库的商业版本，以Derby 代码为基础。 Cloudscape 是一种基于 Java 的、具有全面事务支持能力的关系数据库技术。它是一种纯嵌入式数据库，基于文件系统，具有高度的可移植性，可以用在应用程序中，也可以作为更传统的客户机-服务器应用程序的数据库。它体积小，而且不需要数据库管理员；您只需编写应用程序。在需要时直接调用数据库，Cloudscape 就可以为您服务。
WebSphere Application Server V6.1.x 要求运行的 Cloudscape 的版本至少为 V10.1.x。（请注意，Cloudscape V10.1.x 包含 Derby 代码库）在 Application Server V6.1.x 升级期间，迁移工具会自动升级由一些内部组件（例如，UDDI 注册中心）通过嵌入式框架访问的数据库实例。该工具还会尝试升级应用程序通过嵌入式框架访问的 Cloudscape 实例。必须验证这些后端数据库的迁移结果。
注：请勿将 Cloudscape V10.1.x 用作生产数据库。请仅将它用于开发和测试目的。
有关 Apache Derby 的更多信息，请参阅：

o http://db.apache.org/derby

o http://incubator.apache.org/projects/derby.html


此外在WebSphere Application Server Toolkit中用到的其它开源项目：

· JUnit
JUnit 是用于 Java 的开放式源代码单元测试框架。Junit 测试是程序员测试，即所谓白盒测试，因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。Junit 是一套框架，继承 TestCase 类，就可以用 Junit 进行自动测试了。在WebSphere Application Server Toolkit 中可以使用 JUnit 测试框架来编写并运行测试。目前 WAS V6.1 中所支持的 JUnit 的版本是3.8.1。有关 JUnit 的更多资源，请参阅 http://www.junit.org。
下载 JUnit：http://download.eclipse.org/eclipse/downloads/。



3. WAS 是否支持动态增加服务器，即在原业务系统不停机的情况下动态增加服务器？

答：

IBM WebSphere Application Server支持应用服务器的动态增加或去除，并且可以根据需要通过自动复制应用程序到新增群集成员来响应增长的企业应用程序的使用。这让您可以在群集上部署应用程序而不是在单个节点上部署，且无需考虑工作量。
WebSphere Application Server能够在不中断系统运行的情况下，修改系统配置，增强了系统的可管理性和灵活性。例如，管理员可以添加或除去群集成员来处理客户机负载的变化，更改服务器属性并将更改自动复制到其群集成员，暂时停止服务器进行维护等等。



4. WAS 是否支持目录服务 LDAP？请列举所支持的 LDAP 服务器。

答：
IBM WebSphere Application Server完全支持LDAP，并内置IBM Directory Server（LDAP服务器），同时可以兼容市场上其它的LDAP服务器，包括：

· Sun ONE Directory Server 5.1 / 5.2

· Lotus Domino Enterprise Server 6.0.3 / 6.5.1

· Windows Active Directory 2000 / 2003

· Novell eDirectory 8.7.3

· IBM Directory Server 5.1 / 5.2

· z/OS Security Server LDAP Server 1.4 / 1.5 / 1.6


在应用开发时，WebSphere允许应用程序通过JNDI访问LDAP服务器的目录数据。
有关 LDAP 设计和实现方面的更多资源，请参阅 IBM 红皮书《Understanding LDAP - Design and Implementation》。



5. WAS 可以实现 Load Balance 功能，这与 WAS Network Deployment 的实现有什么区别？

答：
WAS的负载均衡功能（Load Balance）和 WAS 的部署管理器（Deployment Manager），这两个概念常常被初学者混淆。其实要区分它们，有一个很简单的方法，即 Load Balance 是针对运行时的；Deployment Manager 是针对 WAS 环境管理的，在运行时没有太大用处。 详细描述如下：

1. Deployment Manager（DM）对 WAS 提供集中式的管理，这在复杂环境（例如，多台服务器、异构的平台）中尤其有用。要在上述复杂的环境中创建和管理可以用来做 Load Balance 的 WAS 集群，非 Deployment Manager（DM）莫属。此外还有类似参数配置、应用发布等工作，都是靠 DM 来进行。但是当环境配置的工作完成，WAS 投入运行时，DM 的任务就光荣地暂告一个段落。在运行时，DM 是否启动都不重要，只有当您需要更改某些配置或发布新的应用是，DM 才需要启动起来。 2. Load Balance 是 WAS 在运行时非常重要的一个功能。在 WAS 的集群前面，通常都有一个负载均衡器（通常是 IBM HTTP Server + Plugin，也可能是其它软件或者硬件的负载均衡器），有这个负载均衡器来决定把请求分发给哪个 WAS 集群成员。WAS 集群成员之间可以实现各种数据的复制/共享，包括：session, 有状态 session bean，dynamic cache replication。 有关 WAS Network Deployment 高可用性的更多资源，请参阅 IBM 红皮书《WebSphere Application Server Network Deployment V6: High Availability Solutions》。



6. WAS Network Deployment 支持运行混合版本的单元吗？

答：
是的，WebSphere Application Server Network Deployment（和WebSphere Extended Deployment）支持混合版本单元，但是这被认为是一种临时性的方案，意味着仅使用几周或几个月。这种适应能力使得您可以轻松地从一个版本迁移到另一个版本，但是这并不是一个长期的解决方案。 建议是不要长期运行混合版本单元，因为运行两个（或更多）不同版本的时间越长，碰到问题的可能性就越大。当从 WebSphere Application Server 的一个版本迁移到另一个版本时，建议将新版本与当前已经安装的版本安装到同一台计算机上（这称为共存），在相同的硬件中运行两个单元（一个是旧的版本，一个是新的版本），然后在迁移过程中调整每个单元中的 WebSphere Application Server 实例，例如，减去一个 WebSphere Application Server V5.x 实例，添加一个 WebSphere Application Server V6.x 实例。 对于 Version 6.1 来说有点特殊，它具有一种“缺省安全”的新的安全基础结构，并且包括了证书的生成（使用主机名）。如果您需要将单元迁移到 Version 6.1，那么迁移的单元在缺省情况下是不安全的，除非您已经实现了旧版本 WAS 环境下的安全操作。 有关 WAS Network Deployment 高可用性的更多资源，请参阅 IBM 红皮书《WebSphere Application Server Network Deployment V6: High Availability Solutions》。



7.问题：WebSphere Application Server 中附带的某些开放源码实现是什么版本的？

答：
经常有人问，“WebSphere Application Server 中附带什么版本的 Xerces（或 Xalan）？”，人们通常会担心因为 WebSphere Application Server 运行时所使用的版本与他们自己的应用程序所使用的版本不同而产生冲突。实际上这根本不是问题，因为 WebSphere Application Server（V5 和更高版本）中的类加载器允许您对应用程序中希望使用的版本进行打包，然后指定您希望使用的类的版本。这时将加载您希望使用的类（而不是运行时所使用的类）。可以通过将应用程序或 Web 应用程序的类加载模式指定为“PARENT_LAST”来实现这项任务。这样做可以确保您的应用程序使用 EAR（或共享库）中的实现，并且可以防止当 WebSphere Application Server 维护更改版本时出现破坏。在 Integrating Jakarta Commons Logging 一文中对这个问题进行了深入的讨论。

当然，如果您只是感到好奇的话，有一种比较简单的机制可以用来确定 WebSphere Application Server 中附带的版本。在每个 JAR 中都包含了一个“Version”类。执行 WebSphere Application Server V6.1.0 中的这个类，可以得到如下的输出：



C:\WAS61\AppServer\java\jre\bin>java -cp .\lib\xml.jar org.apache.xalan.VersionXSLT4J Java 2.7.4
C:\WAS61\AppServer\java\jre\bin>java -cp .\lib\xml.jar org.apache.xerces.impl.VersionXML4J 4.4.5



8.问题：运行应用程序所需 CPU 的最小数量和最大数量是多少？

答：
现代操作系统通常在进程调度方面表现得很出色，从而最大程度减少了上下文切换。上下文切换是在操作系统调度程序用另一个进程替换 CPU 上正在运行的一个进程时发生的，而且是各种因素作用的结果，例如作业（或进程）优先级、是否等待其他资源（如 I/O）、进程是否将用完所有分配给它的 CPU 周期（时间片）等。但是，在执行上下文切换时，虽然现代操作系统表现很“出色”，却并非“完美无缺”，因为进程在每次进行上下文切换时，它都将停止运行——这将导致吞吐量出现延迟（和性能下降）。如果我们确实不希望出现任何上下文切换，则系统中的 CPU 数要大于该系统中运行的进程数。而这完全不切合实际，因为在一个系统中安装这么多的 CPU，几乎没有任何组织能负担得起，而且也没有必要，因为大多数进程都不要求对 CPU 进行持续访问。因此，我们应该转而研究一些最重要的进程，这些进程在本文中即指系统中应用服务器运行时所使用的JVM。

起初，我们假定每个应用服务器 JVM 应该采用至少一个 CPU；这样就有可能最大程度减少发生上下文切换的次数——至少就将用完时间片这一因素而言是如此（如上所述，导致上下文切换还有其他因素）。但是除非您在运行所有服务器时占用了全部 CPU 资源，否则，在应用程序请求（该请求随即被转换为对操作系统资源的请求）到达应用服务器时，很可能存在可用的 CPU 周期。因此，运行的应用服务器数量有可能大于 CPU 数量。

不过，如果要获得可以在环境中运行的服务器的准确数量，则还得采用视情况而定之类的方式进行回答。这是因为该数量实际上取决于负荷、应用程序、吞吐量和响应时间要求等，确定这个准确数量的唯一方法是在环境中运行测试。

在开发环境（其中负荷可能是每个应用服务器只有一个用户）中，您会期望每个 CPU 运行的应用服务器实例数量是生产环境中的应用服务器数量的数倍，这种想法很合理。尽管如此，也很难确定具体的应用服务器数量，虽然为所有应用服务器添加足够的内存也是个相当重要的因素。根据经验，所有 WebSphere Application Server JVM 进程加在一起的大小不应超过服务器上未使用物理内存的 80%。在计算该数字可以达到的最大数目时，您必须考虑的不仅有最大堆大小，而且还有除最大堆大小之外的 Java? 字节码解释器的进程大小（这个大小在操作系统进程表中列出）。字节码解释器向进程表大约添加 65MB（除了最大堆大小 128MB 之外），并随最大堆大小的增加而增加。

在解决了 CPU 的最小数量后，您可能要问，最大 CPU 数量是多少？如果您了解到回答也是视情况而定，那不必感到惊讶。一个非常高效且经过精心编写的应用程序只通过一个应用服务器进程即可使用多个 CPU。事实上，WebSphere Performance Lab 在运行涉及 Trade 性能基准时，使用了 12 个 CPU（有时更多）。而期望大多数应用程序具有这种伸缩性可能是不合理的，但大多数经过精心编写的应用程序都应能通过应用服务器使用多个 CPU（实际上，只使用一个 CPU 通常表示存在应用程序瓶颈）。在任何情况下，由 Tom Alcott 在 WebSphere Scalability 一书讲述的确定最佳克隆（或应用服务器实例）数的指导原则仍然适用：

一般情况下，您应调整一个应用服务器的实例来观察吞吐量和性能，然后逐步增加克隆数量，在添加每个克隆时，对性能和吞吐量进行测试。通过这种方式，可以确定为环境提供最佳吞吐量和性能所需的克隆数。通常，在 CPU 利用率达到稍微低于 75% 时，可以通过另添加克隆来提高吞吐量。



⒐ 问题：WebSphere Application Server V6.1 在安全方面有哪些增强功能？

答：
A，缺省安全设置

在WAS V6.1 中，很多基本安全配置步骤现在已设置为缺省设置--这样做是为了符合缺省安全 原则。其中的一些例子包括：

· 在安装期间自动启用管理安全性。

· 缺省情况下，会对所有内部传输进行身份验证。

· 缺省情况下，会对大部分内部传输进行加密。缺省情况下，DCS（通常在计算单元内运行）保持未加密状态，但可以为其启用加密。

· 不使用缺省加密密钥，会自动创建计算单元特定的密钥集。

· 缺省情况下，JNDI 对所有人都是只读的（而不是读/写）。

· 缺省情况下，消息传递将连接仅限制于授予了总线连接角色的经过身份验证的用户。缺省情况下，AllAuthenticated 不再具有此角色。


B，证书、私钥和加密密钥管理

信任存储区和密钥存储区的管理现在作为第一类构造进行处理。这包括管理密钥存储区中的证书和密钥，以及管理整个计算单元内这些密钥的复制。提供了大量小增强功能，这些功能在易用性方面得到了很大的提高。

C，更为复杂的注册中心配置支持

包括支持文件注册中心、可以将多个 LDAP 目录组合为一个逻辑注册中心、直接支持 LDAP 故障转移等。

D，隔离各个管理员

在 V6.1 前，管理授权是在整个计算单元范围内进行的。如果针对个体授予了管理权限，则对计算单元中的每个节点、服务器和应用程序都有管理权限。而通过使用 V6.1，现在可以更精细地对管理权限作用范围进行划分。

E，提供从 Windows 桌面到内部网应用程序的单点登录

WebSphere Application Server V6.1 支持 SPNEGO 信任管理解释器（Trust Association Interceptor，TAI），该解释器允许将 Windows 桌面的 Kerberos 凭据从浏览器发送到 WebSphere Application Server，然后将其作为标识访问 WebSphere 资源。以前发布的 IBM Software Services for WebSphere 提供了一个稍有些不同的 SPNEGO TAI 版本，但现在通过使用 V6.1，我们可获得受到全面支持的产品解决方案。