自从WebLogic 9.0发布以来，很多人都这样说：“给我3个升级到WebLogic 9.0的理由先。”由于WebLogic 9.0具有非常丰富的特性，且又是性能驱动的，因此我们能很容易地给出10个主要理由。 理由之 10 ：增强的 Web 服务和进入黄金时期的 SOA 架构　　WebLogic 9.0交付了完整且全面集成的Web服务堆栈。BEA在Web服务领域的一些重要技术方面占据了领先的地位，像基于注释的Web服务编程和会话Web服务等。Web服务服从所有的基本J2EE规范和大多数的重要WS-*规范。对于异步、会话式、可靠且安全的Web服务的支持也得到了增强。
　　简而言之，在新增的Web服务方面，用户可以获得：

• 下一代Web服务编程模型
• 会话式Web服务的性能提升
• 更灵活、安全和可靠的异步Web服务
• 对长期运行的异步可靠消息交换的支持
• 降低了复杂性
• 借助于JSR-181基于JWS的Web服务而实现的最新型基于标准的编程模型
• 简化的Web服务编写

理由之 9 ： JMS -- WebLogic 9 中值得骄傲的增强　　WebLogic Server 9.0在WebLogic JMS的配置、部署和动态管理方面引入了重要的改进。它对JMS 1.1规范提供官方支持。此外，在系统中添加了人们期待已久的消息排序高级特性。XML API的XML消息处理功能得到了增强。在WebLogic 9.0平台上使用JMS非常轻松有趣、可靠且迅速。下面是现有新特性中的一些亮点。
自动化的 JMS 故障恢复　　自动化的JMS故障恢复是业内期待已久的特性。JMS利用“Automatic WebLogic Server Migration”特性来提供自动化的JMS故障恢复。在整个WebLogic Server实例进行故障恢复时，JMS也将自动从故障中恢复过来。尽管其他的一些JMS服务器提供商已经利用一些复杂装置提供了这样的功能，但WebLogic 9.0的实现是最直观而清晰的。
排序单元　　消息排序是大多数消息处理应用程序的一项基本要求。WebLogic Server JMS即使在集群环境中也能确保消息的顺序处理。它甚至可以定义多个组来将消息分组，这样每个组都拥有自己的处理顺序（如图1所示）。
存储转发 (SAF)　　WebLogic存储转发(store and forward, SAF)服务使WebLogic Server能在通过WebLogic Server实例部署的应用程序间可靠地交付信息。SAF的强大功能使得我们可以很容易地将多个消息服务链接在一起（如图2所示）。
理由之 8 ： 并行部署 -- 美梦成真　　每个J2EE开发人员都经历过发布产品新版本的痛苦。经过无数开发周期和QA周期后，最后发现已经到了在应用服务器上部署新版本的时候。预定在一个周末关闭服务器，换上产品新版本，然后祈祷周一不会出问题。如果足够幸运，只会出现一些小问题。然而如果不够幸运的话，就不得不重新使用以前的应用程序，这甚至比部署新版本更痛苦，因为有时并不能恢复所有的改动（如图3所示）。
　　我们希望可以在应用服务器上使用多个版本，并且能在不中断系统的情况下在版本之间进行切换。
　　现在我们的梦想成真了。并行应用程序部署能在无需中断服务的情况下，控制基于Web的应用程序新版本的部署过程。应用程序的新版本与现有版本部署在一起 -- WebLogic将逐步移植交互。旧版本在当前所有客户端完成工作之后解除部署。管理员显式解除旧版本的部署，或者会达到配置好的超时。
　　回滚新版本很简单：如果在新的应用程序版本中检测出问题，只需停止重新部署过程即可。
　　对于新应用程序来说，管理员能以“管理模式”部署应用程序，这种模式对于非管理客户端来说是不可访问的，其目的是进行健全性检查，以确保应用程序按照预期状况正常运行，然后才对客户端开放。
　　以下是WebLogic 9并行部署方面的特性列表：

• 多个应用程序版本可以共存
• 在向用户开放前测试版本
• 回滚以前的版本
• 自动引退：流畅、超时、即时
• 创建可识别版本的应用程序工件/资源
• 降低硬件、软件、维护和支持成本

　　JSR-88是J2EE 1.4规范的一部分，JSR-88指定了一个标准API，用于J2EE应用程序的配置和部署。WebLogic 9不但实现了JSR-88，而且在J2EE的规定之外还提供了很多附加值。
理由之 7 ： WebLogic 诊断框架：降低 总拥有成本　　WebLogic诊断框架(WebLogic Diagnostics Framework,WLDF)旨在通过显著的诊断增强来降低客户的总拥有成本(Total Cost of Ownership,TCO)。WLDF串连了所有的BEA WebLogic Server 9.0容器，从而创建了一个对数据集合进行有序控制的统一框架，这对于企业应用程序的良好运行是非常重要的。这个框架将跟踪并存档有意义的诊断数据，这些数据可用于监视和诊断运行中的服务器所出现的问题。WLDF是一个统一框架和公共API，因此可以轻易地把应用程序嵌入到框架中，以利用服务器的诊断功能。
　　WLDF由很多组件构成，这些组件协作起来收集、存档并访问有关其宿主服务器和应用程序的诊断信息。所有的框架组件都运行在服务器级别，并只识别服务器范围。除Manager之外的所有组件一概都存在于服务器进程中，并参与到标准服务器生命周期中。框架的所有工件都在每个服务器的基础上进行配置和保存。WLDF Manager提供了一个配置和控制界面，用于管理诊断框架。除此之外，WLDF Image Capture实用工具提供了一个模型，用于捕捉关键服务器状态的诊断快照。它提供了一种侵入性最低的服务器诊断和故障排除方法。
　　以下是WLDF的特性列表：

• 引入了一个统一的诊断框架，该框架为后续的BEA增强提供了蓝本
• 提高了WLS和堆栈产品的总体可视化效果，以减少监视和诊断中的盲点
• 改进了对（诊断专家可用的）诊断数据的数量和质量的控制和实时可调性
• 引入了附加的诊断工具，以帮助理解和解决系统故障
• 提供了定义更清晰的界面和工具，用于帮助对客户应用程序进行诊断
• 可跨WL平台使用
• 有助于不依赖于支持团队地发布客户工具补丁
• 应用程序和WLS类的工具
• 监视和通知功能，用于触发警报
• 请求着色（跨JVM）：用于事件重建和关联的诊断上下文
• 细粒度控制 -- 将容量调高或调低
• 借助于控制台扩展实现数据可视化：https://codesamples.projects.dev2dev.bea.com/servlets/Scarab?id=s96
• 借助于JMX而实现的编程式访问

理由之 6 ：基于门户的可扩展管理控制台：可扩展控制台！　　WebLogic 9.0管理控制台提供了一个完全经过重新设计的用户界面，该界面是标准化的，并且其所有子系统都改善了外观和导航体验。它是构建在WebLogic Portal Framework之上的。尽管使用门户放慢了管理控制台的启动过程，但也使其更加开放和易于扩展 -- 如果需要的话，应用程序能将扩展嵌入到控制台。
　　其中的新特性包括：

• 改进的导航和用户界面设计。
• 新增的用于控制域配置修改的“修改中心”。使用控制台，管理员可以将修改“批处理”到WebLogic Server配置，从而可以进行可预料且可靠的修改。在管理员的命令下，一批中所有的配置修改被跨域分布，并被应用到所有的服务器；如果有任何服务器不能接受这些配置，就将在整个域中进行回滚！然后它们就保持为挂起状态，等待来自管理员的进一步操作。
• 新增的应用程序部署和配置工具，包括对应用程序安装、包含更多配置的界面以及用于生产应用程序的新部署和重新部署控件等的支持。附加的控制台更新使用户可以更轻松地在部署导出应用程序时为部属计划变量赋值。
• WebLogic诊断服务，它具有很多在运行时环境下进行配置、收集和查看诊断信息的新特性。可以通过控制台访问此服务。参见包含更多可视性和运行时控件的集中式诊断服务（如图4所示）。
• 管理控制台如今能以类似于通常扩展门户应用程序的方法进行扩展。除了添加和替换内容外，控制台扩展还可以向导航树添加节点并修改控制台的外观元素，例如颜色或商标图片等（如图5所示）。

　　通过管理控制台，用户能执行以下操作：

• 配置、启动和关闭WebLogic Server实例
• 配置WebLogic Server集群
• 配置WebLogic Server服务，例如数据库连通性(JDBC)和消息处理(JMS)
• 配置安全性参数，包括管理用户、组和角色等
• 配置和部署应用程序
• 监视服务器和应用程序性能
• 查看服务器和域日志文件
• 查看应用程序部署部署描述符
• 编辑选中的运行时应用程序部署描述符元素

理由之 5 ：新的零宕机时间架构：城域网 / 广域网集群？　　WebLogic 9.0通过引入城域网 / 广域网（MAN/WAN）集群，进一步扩展了零宕机时间的概念。它提供了增强的HTTP会话复制功能，这就使得在通过广域网或城域网连接的WebLogic Server集群中进行“灾难恢复”成为可能。
城域网中的 HTTP 会话复制　　应用程序能将HTTP会话副本的备份配置到另一个WebLogic Server集群中。一旦主WebLogic Server集群不可用，HTTP客户端就能转到辅助WebLogic Server集群（如图6所示）。
　　此特性假设两个WebLogic Server集群间可以进行高速连接，并严重依赖于全局和局部负载平衡器的正确配置。
城域网中的 HTTP 会话复制　　这对于灾难恢复中心（DR站点）来说十分理想。应用程序能将HTTP会话副本的另一个备份配置到另一个WebLogic Server集群中。WebLogic Server会异步将HTTP会话数据发送到另一个备份（可能保存在数据库中）。一旦主WebLogic Server集群不可用，HTTP客户端能够转到辅助WebLogic Server集群（如图7所示）。
　　假设到另一个备份的复制是异步的，故障恢复的HTTP客户端可能遇到过时的数据。此特性也同样严重依赖于全局和局部负载并衡器的正确配置。
理由之 4 ：整体服务器的迁移：确保集群化服务器的故障恢复　　在集群环境中如何使用单个的服务并确保故障恢复，这在J2EE领域中始终是一个难题。现在这个难题被解决了。
　　BEA WebLogic 9提供了对整体服务器进行迁移的特性。它支持集群的服务器实例从一台机器到另一台机器的自动和手动迁移。能被迁移的托管服务器被称为可迁移服务器。此特性专为需要高可用性的环境而设计。单个服务可装载于一台服务器上，并可能由于故障而被迁移。可迁移服务器提供了服务器级别而不是服务级别的自动和手动迁移。服务器迁移功能可用于：

• 在宿主服务器实例发生故障时，确保单个服务的连续可用性，在任何给定时间中，单个服务必须只运行在单个服务器上，例如JMS和JTA事务处理恢复系统。在发生故障时，为自动迁移配置的托管服务器将被自动迁移为另一台机器（如图8所示）。
• 简化重定位托管服务器及其驻留的所有服务的过程，将其作为计划中的系统管理过程的一部分。管理员能从管理控制台或命令行初始化托管服务器的迁移。
• 服务器迁移过程将彻底重定位托管服务器，包括将IP地址和驻留的应用程序重定位到一组预先定义的可用主机上。

理由之 3 ： WebLogic 脚本编写工具 (WLST) ：管理员的福音！　　WebLogic 9提供了令人印象深刻的基于标准的命令行管理工具(Jython)，还提供了强大的功能，例如：

• 对域（包括用户创建的以及非WebLogic Server MBean）配置的导航和编辑
• 获得有关域的运行时信息
• 执行各种管理任务，比如部署应用程序、通过节点管理器启动/停止服务器等

　　WLST不赞成WebLogic 9中的weblogic.Admin，尽管它完全支持后者。
理由之 2 ： Work Manager 和线程自我调优：执行队列在哪里？　　所有资深J2EE开发人员都在某种程度上进行过性能调整。在WebLogic Server的前一个版本中，处理在多个执行队列中执行。不同种类的工作根据优先级以及排序和避免死锁的要求在不同的队列中执行。用户不得不通过改变执行队列中线程的数量来控制线程使用。而现在执行队列的概念已经被Work Manger取代了。WebLogic 9.0实现了Work Manager 1.1规范，在一个线程池中执行所有类型的工作。WebLogic Server根据用户定义的规则和运行时指标（包括执行请求的实际时间以及请求进入和离开线程池的比率等）对工作划分优先级，这将提供更大的吞吐量和更快的响应速度。Work Manager API能使应用程序将单个请求任务分为多个工作项，并使用多个在WebLogic Server中配置的Work Manager指派这些工作项同时执行。应用程序能配置调度指导原则（例如，模型A应该获得70%的CPU时间，如果线程拥挤，模型B可被关闭），这样WebLogic Server就能利用这些指导原则和所收集的实际运行时性能数据来安排应用程序的CPU资源。应用程序不必再为指定的组件配置单独的线程池了，因为可以利用WebLogic Serve来监视、调整并分配这些资源。
　　WebLogic Server中重要的自我调优特性包括：

• 工作负载管理 -- 管理员能定义调度策略并在域、应用程序和模块级别上加以约束。
• 自动线程计数调整 -- 线程池能根据吞吐量历史和队列大小自动修改其大小，从而使吞吐量最大化。
• 线程调度功能 -- WebLogic Server 9.0实现了通用的Work Manager API，将线程调度功能向开发人员公开。应用程序也能使用Work Manager API来异步执行工作，并能在执行时接收通知。

　　在这里我们要重点强调一个非常好的特性，即过载保护。BEA一直努力做到想客户之所想，过载保护就是这种努力的一个杰出代表。WebLogic 9.0在这方面提供了两种类型的保护。
类型 1 ：得体的降级 -- 过载保护

• 基于低内存和队列容量阈值的工作拒绝（如表1所示）
• 以非临界开销维护的临界系统
• 在过载时拒绝而不是降级

类型 2 ：得体的故障 -- 如果其它的一切都出现故障，那么就关闭服务器

• 出现致命故障（如死锁）时的关闭/挂起服务器选项，OOME
• 用于脚本编写的定义良好的现有代码
• 指定阻塞线程动作的能力

理由之 1 ：性能　　无疑，性能永远都是购买决心、迁移和升级的第一驱动力。
　　SPECjAppServer2004是评估J2EE应用服务器的基准。BEA WebLogic 9.0获得了SpecjAppServer2004在J2EE领域中的最佳性能结果。那么WebLogic 8.1又如何呢？ -- WebLogic 9.0是否比WebLogic 8.1及以前的版本更快呢？
　　BEA创建了服务器性能指数(Server Performance Index，SPI)来比较每个WLS版本。与道琼斯指数类似，WLS的SPI性能是参考了大量有代表性的性能基准（包括微基准和应用程序基准），然后计算这些基准的几何平均数而得出的。测试后的内部数据显示，WLS 9.0比WLS 8.1 SP4快17%。同样，借助于WebLogic 9支持新硬件、操作系统和数据库系统的新增能力，有可能获得更高的性能。显然，WebLogic 9会使用户在现阶段获得很大的收益，而且BEA永远不会停止实现更高性能的努力。
结束语　　由于WebLogic 9.0具有诸多新特性，迁移到此WebLogic Server版本的理由也就显而易见了，您还等什么？快行动吧！别忘了，无论何时，只要您需要，都会获得BEA的专业服务和技术支持，现在您还有什么理由不升级呢？