NO.1 增强的 Web 服务和进入黄金时期的 SOA 架构
WebLogic 9.0交付了完整且全面集成的Web服务堆栈。BEA在Web服务领域的一些重要技术方面占据了领先的地位，像基于注释的Web服务编程和会话Web服务等。Web服务服从所有的基本J2EE规范和大多数的重要WS-*规范。对于异步、会话式、可靠且安全的Web服务的支持也得到了增强。
NO.2 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的实现是最直观而清晰的。
NO.3 并行部署 -- 美梦成真
每个J2EE开发人员都经历过发布产品新版本的痛苦。经过无数开发周期和QA周期后，最后发现已经到了在应用服务器上部署新版本的时候。预定在一个周末关闭服务器，换上产品新版本，然后祈祷周一不会出问题。如果足够幸运，只会出现一些小问题。然而如果不够幸运的话，就不得不重新使用以前的应用程序，这甚至比部署新版本更痛苦，因为有时并不能恢复所有的改动
NO.4 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实用工具提供了一个模型，用于捕捉关键服务器状态的诊断快照。它提供了一种侵入性最低的服务器诊断和故障排除方法。
NO.5 基于门户的可扩展管理控制台：可扩展控制台！
WebLogic 9.0管理控制台提供了一个完全经过重新设计的用户界面，该界面是标准化的，并且其所有子系统都改善了外观和导航体验。它是构建在WebLogic Portal Framework之上的。尽管使用门户放慢了管理控制台的启动过程，但也使其更加开放和易于扩展 -- 如果需要的话，应用程序能将扩展嵌入到控制台。
其中的新特性包括：
- 改进的导航和用户界面设计。
- 新增的用于控制域配置修改的“修改中心”。使用控制台，管理员可以将修改“批处理”到WebLogic Server配置，从而可以进行可预料且可靠的修改。在管理员的命令下，一批中所有的配置修改被跨域分布，并被应用到所有的服务器；如果有任何服务器不能接受这些配置，就将在整个域中进行回滚！然后它们就保持为挂起状态，等待来自管理员的进一步操作。
- 新增的应用程序部署和配置工具，包括对应用程序安装、包含更多配置的界面以及用于生产应用程序的新部署和重新部署控件等的支持。附加的控制台更新使用户可以更轻松地在部署导出应用程序时为部属计划变量赋值。
NO.6 新的零宕机时间架构：城域网 / 广域网集群？
WebLogic 9.0通过引入城域网 / 广域网（MAN/WAN）集群，进一步扩展了零宕机时间的概念。它提供了增强的HTTP会话复制功能，这就使得在通过广域网或城域网连接的WebLogic Server集群中进行“灾难恢复”成为可能。
城域网中的 HTTP 会话复制
应用程序能将HTTP会话副本的备份配置到另一个WebLogic Server集群中。一旦主WebLogic Server集群不可用，HTTP客户端就能转到辅助WebLogic Server集群
NO.7 整体服务器的迁移：确保集群化服务器的故障恢复
在集群环境中如何使用单个的服务并确保故障恢复，这在J2EE领域中始终是一个难题。现在这个难题被解决了。
BEA WebLogic 9提供了对整体服务器进行迁移的特性。它支持集群的服务器实例从一台机器到另一台机器的自动和手动迁移。能被迁移的托管服务器被称为可迁移服务器。此特性专为需要高可用性的环境而设计。单个服务可装载于一台服务器上，并可能由于故障而被迁移。可迁移服务器提供了服务器级别而不是服务级别的自动和手动迁移。服务器迁移功能可用于：
NO.8 WebLogic 脚本编写工具 (WLST) ：管理员的福音！
WebLogic 9提供了令人印象深刻的基于标准的命令行管理工具(Jython)，还提供了强大的功能，例如：
- 对域（包括用户创建的以及非WebLogic Server MBean）配置的导航和编辑
- 获得有关域的运行时信息
- 执行各种管理任务，比如部署应用程序、通过节点管理器启动/停止服务器等
NO.9 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来监视、调整并分配这些资源。
NO.10 性能
无疑，性能永远都是购买决心、迁移和升级的第一驱动力。
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永远不会停止实现更高性能的努力。
