WebSphere Application Server V7 中的新特性

IBM® WebSphere® Application Server V7 中包括一些功能强大的新特性和显著的增强功能，以帮助您实现更高的工作效率、更强的安全性、更紧密的集成和简化的管理。了解这个新版本中的关键特性，这些特性使得该版本可以为您的面向服务的体系结构提供灵活而可靠的基础。

引言

IBM WebSphere Application Server 为面向服务的体系结构（Service Oriented Architecture，SOA）应用程序交付敏捷、可靠的基础，以使应用程序与业务和 IT 方面的创新保持一致。WebSphere Application Server 支持应用程序和服务的重用和创建，这些应用程序和服务可促进业务敏捷性，并对帮助企业在市场上竞争中获胜的任务关键型问题作出预测和调整。

WebSphere Application Server V7 构建在早期版本的强大和稳定的核心之上，并具有若干新特性和增强功能。除了支持最新的标准和编程模型以外，V7 还包含系统管理、安装和安全性方面的重要改进。总而言之，这些特性进一步扩展了 WebSphere Application Server 平台的覆盖范围、运行时管理功能和应用程序部署选项，以帮助您降低成本和进一步发展企业。

本概述将向您介绍这个新版本中的一些关键特性，这些特性使得该版本可以为您的 SOA 环境提供更加灵活和可靠的基础。

立即获得 WebSphere Application Server V7 的试用版！

回页首

标准

加入该访谈！ 10 月 16 日，WebSphere Application Server 专家在实时在线交流中回答了有关 Version 7 的新特性和功能的问题。您可以访问该访谈页面了解更详细的信息。

WebSphere Application Server V7 包括对以下技术的支持：

• Java EE 5

  WebSphere Application Server V7 中最值得注意的支持标准是 Java™ Platform, Enterprise Edition (Java EE) 5。WebSphere Application Server V7 提供了对 Java EE 5 规范的完全支持，包括以前在 V6.1 中作为功能包提供的 Web 服务和 EJB 3.0 功能。

  如果您不熟悉 Java EE 5，这个最新版本的标准代表了 Java 企业编程模型的重大发展，在应用程序开发人员体验方面带来了可观的改进，从而又在应用程序开发人员工作效率方面带来了重大改进。经常用于描述 Java EE 5 编程模型的短语是逐渐披露 (progressive disclosure)，这意味着迄今为止 Java EE 开发所必需的大部分“样板”代码已经消除。取而代之的是，最常用的应用程序上下文作为缺省行为提供，然后通过使用注释 (annotation)，您可以根据需要覆盖缺省行为，从而获得所需的实现。通过这种方式，应用程序将逐渐地仅构造至所需的程度。

  WebSphere Application Server V7 还引入了对 Java Platform, Standard Edition (Java SE) 6 的支持。

• 依赖项注入

  就覆盖缺省行为而言，开发人员的工作效率得到进一步提高，因为可以使用注释而不是编写代码来方便快捷地完成缺省行为覆盖。注释与称为依赖项注入或反向控制（Inversion of Control，IoC）的编程模式结合使用，在该模式中，应用程序代码只需声明变量，并对它们进行注释以表示所需的任何内容，然后容器将“注入”指定的对象或资源引用。

  图 1 显示了一个简单示例，以帮助说明依赖项注入。左侧的代码片段取自某个 EJB 2.1 应用程序。右侧的代码片段取自某个 EJB 3.0 应用程序，此代码片段有一个注释 @EJB，用于告诉容器这是一个 EJB；然后容器将用所需的包装（或样板）“注入”该 EJB 3.0 应用程序。

  
  
  图 1. 依赖项注入
  
  
  
• Java Persistence API

  Java EE 5 中的编程模型简化的另一个方面是能够将 EJB 组件作为传统 Java 对象（Plain Old Java Object，POJO）来开发。Java Persistence API (JPA) 进一步简化了 EJB 开发，它支持使用带注释的 POJO 来创建实体。除了进一步简化 EJB 开发和使用以外，这还使得 Java SE 开发人员可以快速学习 Java EE 并开发企业应用程序。图 2 将 EJB 2.1 实体 Bean 的代码与 EJB 3.0 实体 Bean 的代码进行了比较。与如图 1 所示的比较一样，注释在简化 EJB 3.0 开发中起作关键作用。在图 2 中，注释 @Entity @Table (name ="CUSTS") 指示这是一个使用表 CUSTS 的 EJB，该表的键通过注释 @ID 定义为 ID 字段 。

  
  
  图 2. 带注释的 POJO
  
  
  
• Web 服务

  对 Java EE 5 编程模型的改进并不仅限于 EJB 开发。Web 服务开发也通过注释得到了极大的简化。在图 3 中，左侧描绘了一个 Java EE 1.4 JAX-RPC 应用程序，右侧描绘了对应的 Java EE 5 JAX-WS 应用程序。

  
  
  图 3. Web 服务开发
  
  
  

  WebSphere Application Server V7 中的 JAX-WS 实现还提供了对 SOAP 1.2 的支持，并支持使用通用 XML 或 HTTP 作为协议绑定，从而允许创建不对线级别 (wire level) 消息格式使用 SOAP 的 Web 服务客户端和 Web 服务提供者。

  WebSphere Application Server V7 中的另一个重要新增功能是支持消息传输优化机制（Message Transmission Optimization Mechanism，MTOM），这是一种用于发送二进制附件的改进方法。MTOM 是非基于 Java EE 的 Web 服务的首选附件机制，因此对 MTOM 的支持改进了 Java EE Web 服务与非 Java EE Web 服务之间的互操作性。

• Portlet 2.0 API

  WebSphere Application Server V7 还引入了对 Portlet 2.0 API（也称为 Portlet JSR 286 规范）的支持。

回页首

系统管理

系统管理是在 WebSphere Application Server V7 中得到增强的另一个主要领域，并有许多新的管理和维护选项可帮助您实现灵活、可伸缩和异步的管理拓扑，以及帮助您降低成本和提高效率：

• 智能预置

  其中最重要的是 WebSphere Application Server 运行时执行的智能预置，智能预置仅选择应用程序需要的运行时功能，从而减少内存占用空间和应用程序服务器启动时间。WebSphere Application Server 在应用程序安装时检查每个应用程序以生成激活计划；在运行时，服务器仅启动激活计划所必需的组件。

  WebSphere Application Server V7 包含对 Web/JDBC 应用场景的支持，并在这些场景中仅启动 Web 容器和核心运行时组件。这与在 V6.1 中相反，在 V6.1 中，EJB 容器、SIP 容器和 Web 服务运行时也会启动，如图 4 所示。固定功能服务器（例如，WebSphere Application Server 代理服务器）中也使用此功能来帮助减少内存占用空间，并旨在由运行于 WebSphere Application Server 之上的其他 WebSphere 产品进行扩展。

  
  
  图 4. 运行应用程序
  
  
  

  附加的运行时内存占用空间减少是以 WebSphere Application Server V7 附带的 Java SE 6 实现的形式交付的。IBM 的 Java SE 5 实现引入的共享类缓存已经过改进，使得该缓存现在能够持久。因此，当服务器上的所有 WebSphere 进程关闭并重新启动后，该缓存可以存活下来。在应用程序开发人员运行单个 WebSphere Application Server 实例的情况下，共享类缓存的内容可在应用程序服务器启动时重新加载，并且在独立使用——或与智能预置结合使用——的情况下，其结果是应用程序服务器的启动时间显著更快。

  IBM 的 Java SE 6 中的另一个改进是在 64 位 WebSphere Application Server JVM 中使用压缩引用 (compressed reference)（或指针压缩）。与以前的 32 位 JVM 相比，使用压缩引用可以非常显著地减少 64 位 JVM 的进程内存占用空间。在 IBM 推出 Java SE 6 实现以前，64 位堆的大小为等效的 32 位堆的 1.7 至 2 倍的情况并不鲜见。

• 管理代理

  灵活的管理是一项改进，能够以多种方式帮助降低管理大型部署的成本。要说明这个新功能，最容易的方法是将 WebSphere Application Server（基本）V6.1 运行时模型与 V7 中的灵活管理所提供的运行时模型做一下比较。在 V6.1 中，管理运行时承载在 WebSphere Application Server 中，意味着管理控制台在应用程序服务器中运行。当针对某个应用程序服务器运行 wsadmin 脚本时，每个应用程序服务器进程都因此而具有管理开销。这还无法管理多个“基本”应用程序服务器概要；每个应用程序服务器概要必须单独进行管理，如图 5 所示。

  
  
  图 5. 多个基本概要
  
  
  

  灵活的管理通过将大多数管理组件与应用程序服务器运行时分离，从而改变了这一情况。现在，每个应用程序服务器不再是单独的管理点。这是通过称为管理代理的单独（基本）WebSphere Application Server 管理进程实现的，如图 6 所示。

  
  
  图 6. 管理代理
  
  
  

  您可能想知道，将管理功能从应用程序服务器转移到管理代理是否可以提供更多的功能。答案在于这样一个事实，即管理代理可以管理单台计算机上的多个 WebSphere Application Server（基本）实例，如图 7 所示。当使用管理代理时，随着应用程序服务器实例的增加，用于管理每个应用程序服务器的重复内存占用空间就被消除了。此外，由于管理代理可以管理一台计算机上的所有应用程序服务器实例，因此只需记住一组远程管理端口（管理代理的管理端口），而不是尝试管理与每个应用程序服务器相关联的所有单独管理端口。

  在使用管理代理时，请记住：

  • 管理代理只能管理与该管理代理在同一台计算机上的应用程序服务器。
  • 尽管管理代理可以管理多个应用程序服务器，但是每个应用程序服务器是单独地进行管理的。换句话说，您将登录管理代理去更改服务器 1 的配置，注销，然后登录服务器 2，以此类推。
  • 管理代理仅提供了这些应用程序服务器（及其应用程序）的管理——而没有提供集群和故障转移的管理。对于集群和故障转移以及集中的应用程序管理，您仍然需要 WebSphere Application Server Network Deployment。
  
  
  图 7. 管理多个应用程序服务器的管理代理
  
  
  
• 作业管理器

  作业管理器是 WebSphere Application Server Network Deployment V7（以下称为 Network Deployment）中提供的灵活管理的另一个方面。与管理代理一样，可能最适合通过检查 V6.1 的运行时模型来描述管理器是如何工作的，如图 8 所示。

  
  
  图 8. V6.1 运行时模型
  
  
  

  Network Deployment 中存在紧密的耦合：

  • 应用程序服务器与节点代理之间。
  • 节点代理与部署管理器之间。

  如果运行时组件没有近距离地定位在一起，则这种紧密耦合会影响管理运行时的可伸缩性。可能的示例也许是分支机构部署，其中在中央位置使用部署管理器管理分散在每个远程分支机构的节点。即使在最好的情况下——中央位置与分支机构之间存在冗余、高容量、低延迟网络，等等——由于广域网（Wide Area Network，WAN）很少像局域网（Local Area Network，LAN）那么可靠，并且已知这两者都会偶尔发生故障，仅只是由于这个原因，这样的分支机构部署也会很成问题。

  Network Deployment 中的作业管理器通过采用松散耦合的管理体系结构，从而解决了当前管理体系结构中所固有的局限性。与同步控制许多远程端点（节点代理）不同，作业管理器通过在许多节点之间提供异步作业管理功能，从而在一组端点之间协调管理。该管理模型依赖于向这些远程端点提交管理作业，这些端点可以是 WebSphere Application Server（基本）管理代理或 Network Deployment 部署管理器。反过来，实际执行作业的是管理代理或部署管理器，这些作业可以是更新配置、启动或停止应用程序，或者执行各种各样的其他常见管理任务。

  作业管理器提供的管理模型如图 9 所示。务必要知道，作业管理器不是对部署管理器的取代；而是一个用于远程管理 Network Deployment 部署管理器或（更可能是）多个部署管理器的选项。回想一下上面尝试从单个部署管理器管理多个远程节点的示例；使用作业管理器，可以将每个分支机构转换为自己的 Network Deployment 单元，有一个部署管理器在每个分支机构本地运行，并且可以使用作业管理器远程管理这些远程单元中的每一个单元。

  
  
  图 9. 作业管理器管理模型
  
  
  

  这个新功能为许多更高级的部署和管理拓扑奠定了基础，如图 10 所示。

  
  
  图 10. 高级拓扑
  
  
  

  同样，作业管理器不是对 Network Deployment 单元或部署管理器的取代。表 1 进一步阐明了作业管理器与部署管理器提供的功能。可以看到，Network Deployment 提供的运行时功能与灵活的管理所提供的管理功能之间很少有重叠，反之亦然。换句话说，灵活的管理不是对 Network Deployment 提供的企业级运行时服务质量的取代或替代；相反，灵活的管理同时扩展了 WebSphere Application Server V7 和 WebSphere Application Server Network Deployment V7 的管理功能。

  
  
  

  应用程序服务器管理功能	部署管理器	作业管理器
  远程管理	是	是
  通过控制台进行的细粒度管理	是	否
  管理进程终止时的管理（本地连接）	是	否
  集群：工作负载管理	是	否
  集群：故障转移	是	否
  基于插件的 HTTP 请求路由	是	否
  数据复制（基于内存的会话复制）	是	否
  集中的配置备份/还原	是	否
  服务器性能监视	是	否
  管理功能调度	否	是

  
  
  
• Web 服务

  除了前面提到的编程模型改进之外，V7 中另一个重要的新系统管理功能是在 Web 服务方面。Web 服务策略集是 WebSphere Application Server V7 提供的机制，用于集中定义您可能希望应用于已经部署的 Web 服务的各种服务质量策略。共有两种类型的策略集：

  • 应用程序策略集用于业务相关的断言，例如 WSDL 文件中定义的业务操作。
  • 系统策略集用于非业务相关的系统消息，例如应用 QoS 策略的规范中定义的消息。示例包括 WS-Trust 中定义的安全令牌 (RST) 消息，或者 WS-Reliable Messaging 元数据中定义的序列消息的创建。

  与定义单独的策略并将它们单独地应用于每个 Web 服务不同，可以将策略集一次应用于所有适用的 Web 服务应用程序，从而保证给定类型的 Web 服务具有统一的服务质量。与此相关的是，WebSphere Service Registry and Repository 将会发现 WebSphere Application Server V7 JAX-WS 策略集，以及发现现有的关联，并将那些关联表示为策略附件。提供了许多缺省策略集：

  • LTPA WSSecurity Default
  • Kerberos V5 HTTPS default
  • SSL WSTransaction
  • Username SecureConversation
  • Username WSSecurity default
  • WS-Addressing default
  • WSHTTPS default
  • WS-I RSP ND
  • WS-ReliableMessaging persistent。

  此外还可以根据需要自定义或修改策略集。

• 消息

  WebSphere Application Server V7 中除了 Web 服务改进之外，还存在对一个相关的 SOA 组件的改进：消息。V7 提供了用于系统集成总线（System Integration Bus，SIBus）配置的新管理向导（用于配置集群总线成员和外部总线连接），以及用于 SIBus 授权、WebSphere MQ JCA 资源适配器配置和用于检查应用程序的 SIBus 资源使用情况的新面板。

  V7 还包括一个 WebSphere MQ JMS JCA 1.5 资源适配器，以及关联的新面板和管理命令。拥有 JCA 1.5 资源适配器还意味着，使用 WebSphere MQ 中的消息的消息驱动 Bean 现在可以使用激活规范而不是侦听器端口。

  WebSphere Application Server V7 还包括了改进的激活规范管理——停止、启动、消息重试限制（或“有害”消息筛选）。

• 集中的安装

  Network Deployment 还添加了从部署管理器执行到远程节点的集中安装的功能。这允许将针对部署管理器的单个安装作为安装包从部署管理器推送到一系列端点。端点可以是不属于 Network Deployment 单元的节点（在此情况下可以安装 Network Deployment），或者是可能需要修复程序包的现有 Network Deployment 节点。

• 业务级应用程序

  WebSphere Application Server V7 中的另一个新功能是超越 J2EE™ 的“应用程序”的概念，或业务级应用程序（business level application，BLA）。这是一个新的管理概念，扩展了以前由 J2EE 提供的功能。可应用此功能的场合包括如下，其中应用程序：

  • 由多个包组成。
  • 包含附加的库或非 Java EE 构件。
  • 包括在异构（WebSphere 和非 WebSphere）运行时上运行的构件。
  • 以递归的方式进行定义；例如，应用程序包括其他应用程序。

  本质上，BLA 是一个分组概念，用于在单个应用程序定义下管理 Java EE 和其他构件，如图 11 所示。BLA 可以跨越 WebSphere Application Server 以外的部署目标运行时，例如代理服务器、Web 服务器、WebSphere Application Server Community Edition 等等。此外，BLA 提供了完整的应用程序生命周期管理：安装、分发、激活、监视、更新和删除。

  
  
  图 11. 业务级应用程序
  
  
  
• 安全性

  安全管理和审核改进也是 WebSphere Application Server V7 中的新增特性的重要组成部分。也许最突出的更改是在单个 WebSphere Application Server 单元中创建多个安全域的功能。每个安全域可以具有自己的用户群体（以及基础存储库），此外，应用程序域可以与管理域分离。不仅每个域可以拥有自己的单独用户群体，而且除了当前应用程序服务器级别的安全配置选项以外，还可以使用单独的安全配置来自定义每个域——例如，JAAS 登录配置、TAI、授权提供者、JCA 身份验证数据，以及审核。域的范围是可变的，可以从单元、集群或节点，到节点组或应用程序服务器。因此，应用程序具有不同的用户群体和不同的安全配置，如图 12 所示。

  
  
  图 12. 新的应用程序安全性
  
  
  

  此外，在 WebSphere Application Server V6.1 中引入但仅限于 wsadmin 的细粒度管理安全功能现已在 V7 中扩展到包括管理控制台。在单元的管理安全域中，这允许将管理角色限制到特定的组件，例如集群、节点、应用程序服务器或应用程序。

• 审核

  另一个安全增强功能是可以选择生成 WebSphere Application Server 管理操作的安全审核记录。这些操作可以是安全配置更改、密钥和证书管理、访问控制策略更改、总线和其他系统资源管理等等。此功能使您可以让管理用户对配置和运行时更改承担责任。

  此外，审核记录和审核配置的检查和控制被委托给一个新的审核员角色，从而允许分离管理用户权限，因为管理员不能更改审核策略，并且不能查看审核记录，审核员也不能更改 WebSphere 配置和运行时状态。新的审核系统的输出示例如图 13 所示。

  
  
  图 13. 审核输出
  
  
  
• Kerberos

  WebSphere Application Server V7 提供了对 Kerberos 身份验证的支持，可以在各种各样的单点登录场景中使用该身份验证机制。V7 中的 Kerberos 支持扩展了 V6.1 中的 SPNEGO TAI，以提供与支持 Kerberos 身份验证的其他应用程序（例如 IBM DB2®、.NET® 等等）之间的互操作性和身份传播。

回页首

应用程序开发和管理

WebSphere Application Server V7 包括两个用于应用程序开发的工具选项，允许您利用此新版本中支持的标准：

• IBM Rational® Application Developer Assembly and Deploy V7.5 取代了 WebSphere Application Server V6.1 提供的 Application Server Toolkit (AST) 功能。此开发工具通过基于 Java EE 5 XML 表单的 DD 编辑器、Java EE 5 应用程序支持等对 AST 中的功能进行了扩展。
• IBM Rational Application Developer V7.5 for WebSphere 向 Rational Applicatiion Developer Assembly and Deploy 添加了功能，包括 EJB 3 应用程序开发工作效率功能、可视化的编辑域建模和 Web 开发、Web 服务工作效率功能，以及关系数据工具。

回页首

总结

IBM WebSphere Application Server V7 是一个主要发行版本，提供了引人注目的运行时改进，以及更简单和更容易的应用程序开发和部署方法。本文非常概括地介绍了使这些改进变得可能的许多新特性和增强功能。