Question

WebSphere Application Server V8.5 带来了哪些新特性

Answer 1

WAS V8.5 的提供了以下三个方面的新特性：
应用程序和服务的快速交付
改进操作效率和可靠性
增强的安全性和操控性
接下来，将从以上三个方面，分别向您介绍 WAS V8.5 的新特性。

应用程序和服务的快速交付
WAS
能够协助企业通过快速创新性的应用程序提供给用户丰富用户体验。开发者可以利用 WAS
支持的广泛的开源编程模型并利用现有的开发技能来快速开发应用程序。该功能使得开发者能够将项目求与编程模型和开发者技能相匹配。WAS
还能够通过鼓励复用和延长现有应用程序模块来加速应用程序的交付。
下面的这些 WAS V8.5 的新特性能够帮助快速交付析的应用程序和服务：
Liberty profile
扩展的工具及工具包
OSGI 编程模型的增强
支持 Java 7
Migration toolkit 的增加
Web 2.0 和 Mobile 工具集
Service Component Architecture OASIS 编程模型实现
回页首
Liberty Profile
WAS
V8.5 中包含了 Liberty Profile，它是一款模块化、动态性的应用服务器概要文件。Liberty Profile
是两种特定用例来设计的：开发者和轻量级生产运行时环境。对于开发者来说，它专注于开发者最经常进行的工作，使得开发者能够尽可能快速且简单地完成这些工
作。对于具有 Liberty Profile 可支持特性的生产环境来说，它提供了一个动态，低运行时内存消耗的，能够使系统资源最大化的生产环境。
Liberty Profile 具有如下特点：
可以看作是开发文件的这样的简单可共享的配置，它使一个单独的 XML 文件，或是通过引用的形式使用多个 XML 文件，通过它能够在开发团队中简单地共享和复用配置信息；
动态运行时环境，填加特性或是更新配置，不需要重启应用服务器；
轻量级运行时环境，只需占很小的内存，开发者和管理员能够根据应用程度的需要来细粒度的定义需要哪些特性，去除了由于不需要或未使用的特性所带来的开销；
可以通过 IBM Installation Manager 来安装或者简单地通过解压一下压缩文件来安装；
简化的布署方式，包括解压一个包含了服务器、应用程序和配置文件的压缩包的方式来布置，通过托拽的方式来安装应用程序，大大简化了开发和测试流程；
与 WAS full profile 环境具有高度的保真性，它们具有同样的容器和服务质量，这使得应用程序很容易的就可以从开发环境迁移到具有高服务质量的生产环境；
与 Network Deployment 作业管理器集成，您可以选择通过作业管理器来进行服务器的生命管理。
使用
WebSphere Developer Tools，您创建这样的一个轻量级的应用务器配置就是简单的几个鼠标操作。这个简单灵活的配置存储于
server.xml 文件中，它包含了服务器运行时的配置。您可以使用 XML 编辑器或是 Eclipse-based 编辑器来直接对
server.xml 进行编辑。
这个简单的配置列出来服务器中安装的特性。通过仅指定需要的特性，Liberty Profile
提供了应用程序所需的最小的运行时消耗。您可以通过集成开发工具（IDE）或者命令行来管理服务器的生命周期，您可以通过客两种方式简单快速地创建、启动
以及停止服务，或是获取服务器装态。
对于团队开发来说，Liberty Profile
提供对共享配置片断的支持，这使得您能够将应用程序与配置一起来维护，并共享给开发团队。这种共享式配置减少了由于单一修改并将访修改复制整个开发团队所
带来的开销。例如，如果您有一个 50
人的开发团队，现在您需要对一个数据源的定义进行行修改，这样一个对于共享配置文件的改动，能够自动的被所有的程序员获取，而不是需要所有 50
个开发者手动地将这一变化在他们各自的配置中进行修改。您也可将一个配置好的 Liberty
服务器与应用程序和配置文件一起打包，然后分发给团队中其它程序员或者直接交给测试团队或生产环境。
Liberty Profile
提供了多种应用程序的布署方式。您可以将应用程序的定义填加到 server.xml
文件中或者直接将应用扔到“监控”目录中。服务器自动的获取取这些改动并将新加入的应用程序布署到运行时环境中。卸载应用程序，就是简单地将应用程序的定
义从 server.xml 中去除或是从监控目录中删除。
您可以选择通过 WAS ND 中的作业管理器来集中管理 Liberty Profile 服务器的生命周期。作业管理器以无代理的方式通过系统用户账号来管理服务器，包括启动和停止服务器实例。
Liberty Profile 不需要任何修改是就一个安全的服务器。所有开放的端口都是本机，默认不开启任何的远程管理。Liberty Profile 支持下面的安全特性：
ssl-1.0，包含在 SSL 特定代码中；
appSecurity-1.0，包括了所有的安全服务，认证注册、授权，以及基于 Web 的安全代码；
zosSecurity-1.0，包括了 SAF 注册和授权代码。
通过添加 ssl-1.0 特性就能启用
SSL，SSL 在 sever.xml 中提供了 keyStore 密码。在服务器启动时就会生成证书。您可使用安全工具来生成自签署证书。更高级的
SSL 配置通 endpoint SSL 配置来实现。应用安全性，appSecurity-1.0，能够使用简单的基于 XML 的注册，LDAP
注册或是系统授权（SAF）注册。
Liberty Profile 还能够与 Webphere eXtreme Scale 和
IBM DataPower XC10 无缝的集成来提供弹性缓存功能。单独的 Liberty Profile 服务器就能够通过 WebSphere
eXtreme Scale Grid 来维持 HTTP Session Failover 和高可用性。
关于 Liberty Profile 的更多内容，请参考 WAS V8.5 新特性专区中 《新一代轻量级应用服务器 — WebSphere Liberty Profile Server 介绍》、 《 WebSphere Application Server V8.5 之 Liberty 安全特性》、 《利用 Liberty 构建高可用环境》 中的具体介绍
回页首
扩展的工具和工具包
IBM
Rational Application Developer （以下简称 RAD）仍然是开发团队在 WAS
上进行软件开发时最受欢迎且功能丰富的开发解决方案。RAD 为开发者提供了单一的开发环境，有助于简化和加速设计和编写，以及测试 WebSphere
应用程序，和，维护这些用程序的核心工作。RAD 和 WAS 在技术和标准的定位策略是同步的，包括 Java EE 标准、SOA、Web 和
Web 2.0、Portal，和 OSGi 编程模型。
除了 RAD 以外，开发人员现在还可以使用 WebSphere
Application Server for Developer 作为测试将来会布署到 WAS 上的应用程序的运行时环。WAS for
Devloper 是免费的开发者桌面版。WebSphere Application Server Developer Tools for
Eclipse 使得在 Eclipse 开发环境构建和布署应用程序到 WAS 运行时环境进行测试变成了一件很容易的事情。
回页首
OSGi 编程模型的增强
WAS V8.5 中 OSGi 应用程序的管理控制台补充了之的的命令行控制台。通过管理控制台，您可查看应用程序，包，服务，以及依赖关系。除此之外，您还可以查看 shared bundle space 以及查看 content bundles。
在
WAS V8.5 中，可以在 OSGi 应用程序中使用 EJB。EJB 打包布署到 EAR 文件或是 WAR 文件中，然后可以作为 OSGi
应用程序中的一部分来使用。每一个模块都有它自己的 classloader，而且，默认地使用 parent-first
授权模型。该模型提供了模块性，是现有技术的补充，与 OSGi 联合使用 EJB 容器来进行类加载和生命周期管理。OSGi
生命周期管理允许原地更新和扩展。EJB 能够在 OSGi Service Registry 中作为服务来发布，客户端不需要了解该服务是由 EJB
来实现的。
现在您能够在 OSGi 应用程序的 Blueprint XML 文件中配置 bean 安全性，这样这个 bean
的方法就只有被赋予某个角色的用户才能够访问。您可配置 bean 级别的安全性以便某一个角色能够被赋予访问访 bean 的所有方法。您可以配置
method 级别的安全，这样不同的角色会被赋予访问特性方法的权限。
关于 WAS V8.5 中 OSGi 新特性的更多内容，请参考 《 WebSphere Application Server V8.5 中 OSGi 新特性》 中的具体介绍。
回页首
支持 Java 7
应用程序开发者现在能够布署于 WAS V8.5 上的应用程序中使用 Java 7 的特性了。这使得无论是开发环境，还是生产环境都选择最适合的 Java 版本。
WAS
V8.5 默认的底层 JVM 与 WAS V8.0 一样，都是 Java
6。这有利于保持企业应用程序在应用服务器版本间保持稳定性。然而，您可以通过 WAS v8.5 的可选择 JDK 特性来选择使用 Java
7，以便使用 Java 7 的新特性。
回页首
Migration Toolkit 增强
WAS
V8.5 使得应用程序的在 WAS 版本间，或是其它的 Java EE 应用服务器的迁移变得容易。Application Migration
Toolkit 能够帮助您将应用程序从 WAS 的旧版本迁移到新的版本，也能够将应用程序从 Tomcat，Oracle 和 JBoss 向
WAS 进行迁移。
Application Migration Toolkit
分析应用程序源代码，找出其中潜在的迁移问题，包括已去除或不推荐使用的特性、行为变化、JRE 5 和 JRE 6 的差别，以及 Java EE
规范的改进和增强。您可以查看这些潜在的迁移问题，在某些地方，Application Migration Toolkit
能够帮您进行快速修改。Application Migration Toolkit
在不能提供快速修改的地方，会提供修改的建议，帮助您进行代码的修改。
Application Migration Toolkit 能够作为插件安装到 Eclipse 或是 RAD 中，可以在 IBM 的网站上免费下载得到：
http://www.ibm.com/developerworks/websphere/downloads/migtoolkit/
回页首
Web 2.0 和 Mobile Toolkit
使
用 Web 2.0 和 Mobile Toolkit，WAS 开发人员能够构建和部署使用如，HTML5、CSS3 和 Java Script
这样的标准 Web 技术开发的移动应用程序。这些应用程序能够运行于多种移动平台，包括
iOS，安卓，以及黑莓。在这些平台上的用户体验基本一致，并且支持触碰操作。
2.0 和 Mobile Toolkit 简化了向
Java Web 应用程序中填加 Ajax 桌面和移动用户接口以及 REST web services。Web 2.0，如 Ajax 和
REST 技术能够帮助开发者开发出更加互联和互动的应用程序，能够带来更大的客户满意度，提高用户生产率，和改善的用户决策。
回页首
改进的操作效率和可靠性
WAS 提供了业界领先的性能，操作灵活性和可靠性。客户可以利用 WAS 的高性能来整合工作负载，降低管理开销，这样可在损失系统性能的前提下降低 TCO。WAS 传统的支持能够帮助客户维持交易的一致性和整体的可靠性，降低由于系统宕机带来的业务损失的可能性。
WAS V8.5 下面的特性能够改进操作效率和可靠性：
智能管理
弹性的消息架构
回页首
智能管理
管
能管理的功能被引入到了 WAS V8.5 中，它提供了一套虚拟架构，该架构重新定义了 Java EE
资源和应用程序的传统定义以及它们之间的关系。这个应用程序的架构虚拟化有助于产品以最优化的方式来自动运行，提高了服务质量。通过这套带有工作负载管理
的自操作环境的引入，您能使用更少的硬件来完成更多工作，降低 TCO。
智能管理提高了您的中间件环境能够提供的服务质量。可配置的操作策略管理着应用程序的健康和性能。总之，智能管理能让您体验到这种自配置、自保护、自愈以及自优化的自动的中间件环境的优势。
接下来，将向您介绍由 WAS V8.5 所提供的智能管理的概述。
应用程序版本管理
应
用程序版本管使得您能够在不间断对外服务的前提下，进行应用程序的更新。访特性使得您能够以一种不间断的方式来布署产品应用程序。使用该特性，您可在生产
环境验证新的应用程序而不会影响到终端客户，这样您就可以在不影响客户访问的情况下来对应用程序进行升级了。您也可以同时运行同一个应用程序的不同版本，
并把不同的用户转发到不同的版本。
应用程序版本管理有如下的优势：
更新应用程序或环境不间断对外服务；
同时运行同一应用程序的不同版本；
在将用户请求转发到应用程序的新版本之前，能够在生产环境中对它进行验证；
减少生产环境硬件花销和降低宕机时间；
不间断服务地轻松的地进行操作系统和 WebSphere 环境进行更新；
批量的进行应用程序更新。
在 WAS V8.5 中，您可以安装同一应用程序的多个版本，它们叫做应用程序版本，定义哪一个版本是激活状态并处理请求。一个应用程序版本，可以是以下三种状态的任一种：
非激活状态，意思是该版本目前已安装但是不可用。
激活状态，意思是该版本已安装并且在运行应用服务器上处于活动状态处理请求。
验证状态，用于测试用途，请求可以选择性发到该应用程序版本上来。
智能路由
智
能路由通过确保关键业务能够被保证最高优先级的方式来提高服务质量。发送到应用程序的请求是按优先级排序的，而且是按照管理员事先定义的规则来进行转发
的。定义规则的一种方式是采用服务策略。服务策略定义了如何根据请求的属性，如 URI，客户端名字，或是 HTTP
头，来对进入的请求进行分类。您也可以通过这些属性来对请求的重要性进行区分。
当进入的请求被处理时，用务策略被用于根据目标服务器的需求和资源使用情况来决定将请求放入队列以及在队列中停留多久。通过这种方式，您可以给在您网站上购买商品的客户更高的权限，而给只是浏览商品的客户稍低些的权限。
通过服务策略，您可以分类、按优先顺序地、智能地路由工作负载。您也可以按需的调整资源以便能够达到服务策略的定义。服务策略可以看作是运行应用在业务和 IT 之间达成服务级别协议的技术实现。
应用服务器健康管理
您
可以通过健康管理来根据预先设定的健康条件来自动的监控应用服务器的健康状况，当系统的健康状况违返的健康条件，系统就会自动的采取措施。您可以监控应用
服务器的状态、感知问题，然后在系统出现宕机之前采取措施。健康管理监控和管理子系统根据用户定义的健康策略来不断的监控服务器的运行状态，来发现由于用
户应用程序问问题导致的系统恶化。
健康策略设计用于发现潜在问题，并在问题发生时采取纠正措施。它可以帮助在发生严重问题之前发现问题，或
者通知管理员或者主动采取纠正措施。智能管理带有一些预先定义的健康条件，如内存过量使用和请求或响应时间过长等等，来定义健康策略。您也可以根据服务器
通过 PMI ， MBean Opertation 所收集到的性能条件，来自己定义定制的健康策略。
当
健康策略被违返时，纠正措施就能够自动生效。纠正措施用于避免问题或是帮助进行问题诊断。预定义的措施包括了通知管理员，发送 SNMP
邮件，重启服务器，将服务器置成维护模式，以及生成 Java Core 文件或是 Heap Dump
文件以用于问题诊断。您也可以定义自定义的的措施。纠正措施可以自动执行，也可以以一种
受同监控的模式来触发。受同监控的模式需要管理员允许才可进行。
性能管理
性能管理是通过一套自优化的中间件架构来实现的。动态集群能够根据用户的响应期望来自动地、动态地增加或减少集群成员来为集群扩容或减容。您可以利用过载保护来限制随需应变路由器向应服务器转发请求，以避免内存耗尽或 CPU 耗尽，或者两者同时被耗尽。
在
静态集群环境中，每一个应用程序都有确定数量的应用服务器，整个环境要能够处理在高峰访问时期望的工作负载。这样环境意味着，在非高峰时段，系统是没有被
充分利用的。通常情况下，企业都有不只一个重要的应用程序。很有可能有多个应用程序，是在一天中的不同时候达到高峰访问。通过动态集群，您可以通过将非高
峰时候的应用程序的系统资源转移给高峰时候应用程序使用的方式，来使您的系统更有效率。
过载保护通过监控应用服务器的内存和 CPU 的使用情况，然后调整发到应用服务器上的请求，以避免内存或处理器被过度使用。内存载载保默认是禁用的。启用该特性需要配置 autonomic request flow manager (ARFM)。
对
于动态集群来说，您可以指定最大堆使用百分比，以避免出现内存溢出错误。对于 CPU 过载保护，您可以指定最大 CPU 使用率，以避免由于 CPU
耗尽造成的各种各样的错误。您也可设定一个拒绝策略用，访策略可以拒绝不是已有会话的 HTTP 和 SIP 请求，用于防止 CPU 过载。
消息架构的弹性
WAS V8.5 在消息引擎方面（bus）提供了如下的关键性增强：
当遇到不能恢复的故障时，智能消息引擎会尝试停止而不是让整个 JVM 崩溃。
在一段可配的时间断后，智能消息引擎能够再次自启用。在故障修复之后，智能消息引擎可以根据需要再次启动以备后用。
智能消息引擎将用于记录消息传递数的 re-delivery count 持久化到数据库中，这样即使消息引擎重新启动，消息数也不会丢失，可以避免应用再次处理同一条消息。
回页首
增强的安全性和操控性
WAS V8.5 带来了良好的安全性或操控性，帮助企业降低运营成本，提高敏捷性。WAS 支持安全规范和细粒度的安全控制来帮助管理员高效地根据业务的需要来保护应用环境。
WAS V8.5 提供了如下的增强的安全性和操控性：
可选择的 JDK
批处理的增强

通过检查点来进行安全审计

跨组件跟踪
可选择 JDK
前面提到您可以通过特性扩展的方式来
将 Java 7 安装到现有的 WAS 之上。然后，您可以通过可选择 JDK 特性在 Java 6 和 Java 7
之间自由的切换。除此之外，在 IBM iSeries 和 IBM z/OS 平台上，您还可以在 32 位和 64 位的 JDK 之间进行切换。
您可以通过以下方式来为您的拓扑配置 JDK：
管理控制台
wsadmin AdminTask 命令
manageSDK 命令行工具
在您的拓扑中，可以某些结点使用默认的 SDK，而其它结点采用 Java 7。您可以通过命令行工具来为您的应用服务器或者集群来指定 JDK 的版本。
除了使用 RAD，您还可以使用 Apache Ant 或 Maven 来构建或测试 Java 7 应用程序。
批处理的增强
WAS 处理的传统的 Java EE 应用程序的类型多为处理短时少量的交易单元。大多数情况下，请求仅需要几秒的处理时间即可完成。但是，有很多应用程序要处理那种计算和资源密集型的批处理操作。
WAS 中的批处理功能扩展了应用服务器在处理传统 OLTP 应用程序的同时去适应那种需要批处理应用程序。批处理应用程序可能需要几个小时甚至几天来完成，运行时会使用大量的内存和处理器资源。
WAS 提供了一个基于 Web 的控制台，叫做作业管理控制台。通过这个控制台，你可以提交作业，监控作业的执行，对作业进行一些操作，和查看作业日志。
WAS V8.5 要现有批处理特性的基础上，通过集成了 WebSphere Compute Grid V8 的批处理功能来提供了一套完整的企业级的 Java 批处理解决方案。WAS V8.5 包括了如下的批处理特性：
能够与企业级调度器的集成
支持并行批处理作业
内存过载保护
Job Log SPI
混合批处理作业类型
在 z/OS 上支持 COBOL
支持 OSGi 批处理应用程序
支持自定义记录处理策略
记录统计
作业和作业步监控器
关于 WAS V8.5 中关于批处理的新特性，请参考 《 WebSphere Application Server V8.5 中 Batch 新特性》 中的具体介绍。
通过检查点来进行安全审计
在多应用服务器环境下保持环境的一致性，和在必要时对于出现的问题进行诊断，作为系统管理员来说，知道对系统和环境进行的每个更改对于 在多应用服务器环境下来是非常重要的。
Repository 检查点是在配置更改发生前对 Repository 进行快照。您可以在进行配置更改之前创建 Repository 检查点，这样在必要的时候可轻松的回退这些更改。您可以选择以两种 Repository 检查点：
完全检查点是对整个配置 Repository 的完整的快照，包含了应用程序和 connecters。使用完全检查点能够将配置回退到生成快照的这个时间点。
增量检查点是整个配置快照的一部分。它用于将配置回退到前一个在状态。这类检查点就是配置的小的，增量的版本。
在 WAS V8.5 中，您可以您想对配置变化进行审计，您就可以增量检查点中抽取进行变更过的文件之前和之后的版本，通过文件对比工具对比。
您可以配置每次配置变化时，自动生成增量检查点。您也可以指定生成增量检查点的个数。当达到这个限制后，新生成的检查点就会替换点旧的检查点。
跨组件跟踪
跟
组件跟踪日志中加入注释，以便服务于同一个请求的多个线程、进程，甚至是服务器都能够被标识为同一个工作单元。它用助于帮助发现问题的根源，使得管理员和
客户服务团队能了解到一个请求，当它跨越线程、进程边界，或者是跨越 WAS
和其上的堆栈产品的时候，这样一个端到端的流程，有助于定位到底是哪个组件导致请求失败的。
跨组件跟踪是 WAS 是日志和跟踪框架提供的一个功能。对于像 SOA 这种使用分布式应用支撑架构的应用程序来说跨组件跟踪是很有用的一个特性，因为它用助于在多服务跨系统的环境中定位问题。
跨
组件跟踪在每一条由 HPEL 生成的日志和跟踪条目上都添加一个 request ID。只要日志和跟踪属于同一个请求，它们就会被加上相同的
request
ID。跨组件跟踪通常还会为请求在日志里添加上开始和结束，它用标记请求从当前线程转移到其它的线程或进程上去了，或者由其它的线程或进程上返回了。这个
跟踪对于显示控制权从如何应用服务器转到了应用程序上是很有用的。
您可以使用 HPEL 的 logviewer 工具来查看和根据 reqest ID 来过滤日志和跟踪。您还可以通过 IBM Support Assistant 中的 Cross Component Viewer 来查看和过滤日志。