摘要
BEA WebLogic Server 9.0是对Sun Microsystems的J2EE 1.4平台的领先实现。然而，WebLogic Server的核心价值主张则体现在J2EE规范中没有的领域――增强的管理、易用性、高可用性、可伸缩性、可靠性和性能。实际上，WebLogic Server的价值并不与任何特定的编程模型关联，所以很自然地，它也适用于新出现的非J2EE编程模型。近年来出现的最激动人心的事物莫过于基于反向控制（Inversion of Control，IoC）的模型，而Spring Framework正是此类模型的领先实现。本文介绍了Spring Framework、WebLogic Server以及二者的集成的一些特性。我们将看到，整体大于部分之和。
文章结构
在前两节中，我们将概览Spring和WebLogic Server，并介绍它们各自的特性。熟悉Spring Framework的读者可以跳过第一节。因为本文的主要目的是介绍两种技术的集成，所以本文余下的部分都会集中在这一点上。为了提供一个上下文，我们首先剖析了MedRec――与WebLogic Server一起发行的一个示例应用程序――首先是以原始的J2EE形式，然后再使用Spring Framework重构。此后，我们将围绕特定的集成点进行详细的阐述。如果您打算在WebLogic Server上开发Spring应用程序，那么您肯定能从本文中找到对您有所帮助的细节。如果您只是想进行大概的了解，那么先阅读标题，以后再了解其具体内容。最后，我们展望了一些正在考虑的未来开发工作。
Spring简介
在本节中，我们将简要概括Spring Framework的一些特性。
Spring 是一个分层的Java/J2EE应用框架，它基于Rod Johnson所著的《Expert One-on-One J2EE Design and Development》（Wrox，2002年）一书中所公布的代码。Spring之所以存在，是因为我们相信，J2EE应该更加易用，而且我们可以使用更简单的方法进行J2EE开发，同时又不牺牲平台的性能。
Spring支持灵活的J2EE开发，并允许使用POJO开发J2EE应用程序。
改进的Spring开发体验
Spring在其核心部分提供了一个易于配置的、XML驱动的反向控制（IoC）容器。IoC基于所谓的“好莱坞原则”――不要给我们打电话，我们会找你。在这种方案中，应用程序中Java对象之间的关系是由容器注入的，而不是通过直接编程实现的。注入分两种形式――构造函数注入和setter注入，这取决于容器是通过其构造函数还是通过mutator方法把信息注入一个已创建的Java对象。
在Spring中，注入的属性――或到其他bean的引用――是通过一个XML文件进行配置的，这使得配置变得非常直接。Spring与一个AOP框架耦合在一起，而该框架支持非侵入性地添加诸如事务和安全这样的属性，这意味着开发人员可以集中精力创建用于解决业务问题的解决方案，而不会为J2EE开发或配置的复杂性而头痛。因为该容器是非侵入性的，所以您不必担心业务代码会被特定于供应商（此处也包括Spring）的工件所污染。
Spring应用程序的组件
正如我们所提到的那样，Spring提供了一个轻量级的容器，用于提供集中式、自动化的配置和编写应用程序对象。该容器是非侵入性的，能够以一种一致而透明的方式，通过IoC把一组松散耦合的组件（POJO）组装为一个复杂的系统。因为该容器允许首先独立地开发和测试各软件组件，然后在任意环境（J2SE或J2EE）中进行扩展部署，所以它具有灵活性和高利用率，并提高了应用程序的可测试性和可伸缩性。此外，Spring还提供了大量其他的对开发人员友好的特性，如下：
一个用于事务管理的通用抽象层：支持可插入的事务管理器，并使得划分事务更加容易，同时无需处理底层的问题。该层中还包括JTA策略和一个JDBC DataSource。与普通的JTA或EJB CMT不同，Spring的事务支持并不依赖于J2EE环境。
一个JDBC抽象层：提供一种很有意义的异常层次结构（不用把供应商代码从SQLException中抽取出来），简化了错误处理，而且大大减少了必须编写的代码数量。不再需要编写另一个finally块来再次使用JCBC。面向JDBC的异常符合Spring的一般DAO异常层次结构。
与行业领先的对象-关系映射解决方案的集成：主要在资源管理、DAO实现支持和事务策略等方面。Spring对大量IoC方便特性的一流支持，解决了许多典型的O-R映射集成问题。所有这些都符合Spring的一般事务和DAO异常层次结构。
AOP功能：完全集成到Spring配置管理中。您可以对Spring所管理的任何对象启用AOP，添加像声明性事务管理这样的方面。借助于Spring，您可以拥有没有EJB的声明性事务管理――甚至也可以没有JTA。
一个灵活的MVC Web应用框架：构建在核心的Spring功能之上。该框架是高度可配置的（通过策略接口），并能适用多种视图技术，比如JSP、Velocity、Tiles、iTexth和POI。注意，Spring中间层可以很容易地与基于其他任何Web MVC框架（如：Struts、WebWork或Tapestry）的Web层结合在一起。
您可以在任何J2EE服务器中使用Spring的所有功能，也可以在非托管环境中使用其中的大部分功能。Spring的一个重心是支持可重用的业务和不依赖于特定的J2EE服务的数据访问对象。这些对象可以不费事地跨J2EE环境（Web或EJB）、独立应用程序和测试环境进行重用。
Spring的分层架构提供了很多灵活性。它所有的功能都构建在较低的层次上。例如，您可以在不使用MVC框架或没有AOP支持的情况下使用JavaBean配置管理。但是，如果您要使用Web MVC框架或AOP支持，您会发现它们构建在配置框架之上，所以您可以马上用上有关它的知识。
BEA WebLogic Server简介
在本节中，我们将简要概括BEA WebLogic Server的特性，重点强调它所提供的底层基础架构，而不是编程模型。
WebLogic Server是一个可伸缩的企业级的J2EE应用服务器。WebLogic Server基础架构支持多种分布式应用程序的部署，是构建任何种类的应用程序的理想基础。
WebLogic Server实现了Sun Microsystems的J2EE 1.4规范，提供了一组标准的API，用于创建可以访问多种服务（如：数据库、消息传递服务）的分布式Java应用程序和到外部企业系统的连接。终端用户客户使用Web浏览器客户端或Java客户端访问这些应用程序。因为J2EE已经为大家所熟悉，这里我们不再详细讨论。更多信息，请参见WebLogic Server文档中关于编程模型的部分。
除了实现J2EE之外，WebLogic Server还使企业能够在一个健壮、安全、高度可用和可伸缩的环境中部署任务关键型应用程序。这些特性允许企业配置WebLogic Server实例集群，以便分布负载，并在发生硬件或其他故障时提供额外的容量。新的诊断工具允许系统管理员监控和调优已部署应用程序和WebLogic Server环境本身的性能。您还可以配置WebLogic Server以自动监控和调整应用程序吞吐量，无需人工干预。广泛的安全特性保护了对服务的访问，保证了企业数据的安全，并阻止了恶意攻击。
WebLogic Server增强后的服务质量
和其他许多BEA产品一样，WebLogic Server就像冰山，浮在水上的不过是很小一部分而已。具体来说，WebLogic Server提供了大量特性和工具来支持高度可用和可伸缩的应用程序的部署。
WebLogic Server集群通过将工作负载分布在多个WebLogic Server实例之间，为应用程序提供可伸缩性和可靠性。根据要处理的工作量，可以把传入的请求发送给集群中的某个WebLogic Server实例。在出现硬件或其他故障时，会话状态对其他节点是可用的，这些节点可以恢复故障节点的工作。此外，您可以实现集群，使服务驻留在这样的单个机器上：如果出现故障，该机器可以选择把服务迁移到集群中的另一个节点上。
除了跨一个集群中的多个服务器复制会话状态之外，WebLogic Server还可以跨多个集群复制HTTP会话状态，从而在多个地理区域、网格和Internet服务提供者中扩展可用性和容错性。
Work Manager基于用户所定义的规则对工作划分优先级，并监控实际的运行时性能统计信息。这些信息随后被用于优化应用程序的性能。Work Manager可以以全局方式应用于一个WebLogic Server域或一个特定的应用程序组件上。
过载保护使WebLogic Server能够检测、避免过载情况并从其中恢复。
网络频道基于流量类型把网络流量分散到各个频道中去，有利于网络资源的有效使用。
WebLogic Server持久性存储是一个性能卓越的内置存储器解决方案，用于需要持久性存储的WebLogic Server子系统和服务。例如，它可以保存持久性的JMS消息，或者暂时保存使用存储－转发特性发送的消息。持久性存储支持到基于文件的存储器或到支持JDBC的数据库的持久性。
存储-转发服务使WebLogic Server能够在跨WebLogic Server实例分布的应用程序之间可靠地交付消息。如果发送消息时消息目的站不可用，或者出现了网络问题或系统故障，那么消息就会被保存在本地的服务器实例上，然后一旦远程目的站可用就转发给它。
企业级就绪部署工具方便了从开发阶段到生产环境的应用程序部署和迁移。
生产环境重新部署使企业能够部署应用程序的新版本，而不会中断老版本上正在进行的工作。
现在，让我们来看一看这两个系统之间的协作。
在J2EE和Spring环境中开发应用程序
为比较J2EE和Spring开发方法的不同，我们使用Spring Framework重新编写了MedRec示例应用程序。在接下来的一节中，我们将简要地概览MedRec的一般架构，然后依次看一看它的J2EE和Spring形式。
Medical Records应用程序
Avitek Medical Records（或MedRec）是一个WebLogic Server示例应用程序套件，它简明地演示了J2EE平台的各个方面。MedRec的设计目的是用作对各个层次的J2EE开发人员进行培训的工具。它展示了如何使用每个J2EE组件，并说明了组件交互和客户端开发的设计模式。MedRec还阐明了使用WebLogic Server开发和部署应用程序的最佳实践。
MedRec背后的现实框架是一个患者、医生和管理人员的框架，该框架使用各种不同的客户端来管理患者数据。对于患者，MedRec为用户提供了一个基于Web的应用程序，用于查看他们的医疗记录和维护档案文件。对于管理人员，MedRec提供了一个基于Web的应用程序，用于管理传入的注册、医疗记录上传和一般性的应用程序监控。MedRec还包含用于与独立医疗机构接合的资源。为了演示这种通信，MedRec包含了一个医生应用程序，用于请求和提供数据给MedRec的系统。
MedRec J2EE版本架构概览
MedRec的J2EE和WebLogic Server版本是按照传统的3层架构模型来设计和实现的，在该模型中，客户端、服务器和数据存储器都是相互独立的：
表示层：该层负责所有的用户交互，有时也称为客户端层。
服务层：该层是封装了应用程序的业务逻辑的中间层。它处理来自异构客户端的请求，同时与各种后端系统进行交互，包括数据存储器。该层有时也称为服务器层。
企业信息系统（Enterprise Information System，EIS)层：该层代表那些提供和/或保存数据的系统，比如遗留应用程序和数据库。EIS层有时也称为数据存储器。
针对MedRec的患者管理应用程序，我们开发了一些Web应用程序（webapp），用于把服务公开给它们各自的用户。webapp符合模型-视图-控制器（Model-View-Controller）模式，Java Server Page呈现视图给用户，模型封装要呈现给用户和从用户处捕捉而来的数据，而控制器机制则管理除与服务层的交互之外的组件交互。MedRec采用Jakarta Struts来实现该模式。
服务层提供服务给发出请求的客户端，并管理与后端应用程序和资源的交互。MedRec的服务层采用Session Facade模式来封装业务逻辑和业务数据。Session Facade通过提供一个到分布式服务的接口，简化了应用程序的复杂性。在MedRec中，Session Facade的首要责任是提供数据吞吐量。在MedRec的J2EE和WebLogic Server版本中，Session Facade被开发为无状态的会话Enterprise JavaBean，而数据则是由实体Enterprise JavaBean来管理的。
为了与外部实体相连接，MedRec通过Web服务公开应用程序功能，这允许不同系统之间使用一系列开放标准进行动态交互。通过使用Web服务公开服务，MedRec能够为独立的各方提供数据，或接受来自各方的数据，从而实现了集中式医疗记录管理的首要目标。
图1说明了MedRec的J2EE与WebLogic Server版本的高层架构。
图1. J2EE版MedRec架构示意图
使用Spring重新表示MedRec
为了使Spring能够利用WebLogic Server的企业级特性，我们重新设计了MedRec的架构，以便使用Spring组件来代替相应的J2EE组件。我们把MedRec原始版本中的功能完全复制到了基于Spring的MedRec版本（MedRec-Spring）中。
引入Spring的IoC是MedRec-Spring中最重要的变化。IoC机制功能强大，通过一个容器把依赖性注入到配置好的组件中而应用。IoC解除了应用程序代码和其配置之间的耦合。例如，对象与它们的依赖性没有关联，所以它们可以专注于其职责。对于MedRec-Spring，企业资源（比如DataSourc、JMS服务、MBean连接和对等服务）在运行时被提供给MedRec-Spring的对象。此外，通过迁移资源配置和在已编译代码之外进行引用，在从特定于开发的资源转移到位于中间的生产资源和环境时，应用程序更加易于管理。
我们发现，要正确使用IoC，应用程序代码需要遵守更加严格的Java编程规则――特别是在编写接口的代码时。接口比其他东西更能促进更好的协作，因为可以减轻依赖性，而且实现的变化被隔离开来。从IoC的角度看，接口支持依赖注入的可插入本性。为了利用IoC，我们对MedRec-Spring进行了重构，这样就可以基于接口对业务对象进行编码。
在MedRec-Spring中，无状态会话EJB被无格式普通Java对象（Plain Old Java Object，POJO）所代替。无状态会话EJB的长处在于它们的远程控制和事务管理功能。因为MedRec-Spring通过Spring的HTTP Invoker架构公开了服务bean，所以它能够满足远程控制的要求。事务管理是由Spring的事务抽象层提供的。MedRec-Spring的事务管理精确地映射了MedRec的事务管理，因为Spring事务管理器被配置为把责任委托给WebLogic Server的JTA事务管理器。
MedRec-Spring包含了原始MedRec的大部分消息收发功能。我们使用Spring的JMS包来简化一些一般性的任务，比如连接工厂和目的站查找。Spring提供了一个代表消息收发目的站的对象，而不是通过编程获得队列句柄。和所有的Spring bean一样，这些对象表示（JNDI名称、连接工厂关联，等等）是在已编译代码之外进行配置的。
MedRec-Spring包含应用程序管理特性。这些特性对WebLogic Server的域配置和它的运行时域有影响。MedRec-Spring必须按照WebLogic Server的MBean Server行事，而Spring提供了连接管理来简化MBean Server的可访问性。
最后，MedRec-Spring使用Web服务导出它的服务。Spring提供一个JAX-RPC工厂，该工厂为Web服务生成一个代理。类似于其他的Spring bean，工厂bean也是在已编译代码之外进行配置的，这使得应用程序更加灵活。
图2显示了基于Spring的MedRec版本的高层架构图。
图2. 基于Spring的MedRec版本的高层架构图
WebLogic Server上的Spring最佳实践
比较了J2EE和Spring环境中的MedRec架构之后，现在，我们要介绍一些在实现MedRec-Spring应用程序的过程中，我们所发现的一些宝贵经验：
使用延迟初始化。为了实现IoC容器，Spring加载了一个application context文件，并创建和缓存了每个已配置bean的实例。Spring bean引用的每项资源都必须可以实例化或查找，了解这一点很重要。例如，Spring的JMX支持提供到WebLogic Server的MBean服务器的连接。因为并非所有的MBean服务器都是在部署期间激活的，所以用户应该在部署资源时，一启动就使用Spring的延迟初始化和查找服务。
基于功能分离出Spring配置。这允许应用程序组件只加载那些与它们的工作职责有关的上下文。在实践上还允许测试人员修改应用程序的行为，具体方法是使用特定于测试环境的上下文来替换应用程序上下文――例如DataSource配置。
通过JndiObjectFactoryBean封装JDBC DataSource连接入池。然后，需要数据库交互的bean可以引用这个bean，以便利用WebLogic Server的DataSource入池功能。
对会话和消息驱动Enterprise JavaBean使用Spring的org.springframework.ejb.support。Spring的org.springframework.ejb.support提供Enterprise JavaBeans (EJB)可以对其进行扩展的抽象类。通过把EJB生命周期方法的标准实现包括进来，这些抽象EJB类可以辅助开发工作。更重要的是，这些类提供了加载Spring的应用程序上下文的机制，包括跨多个EJB和客户端共享上下文，因此减少了EJB初始化期间的复制工作和负载。
利用热部署和WebLogic Server的拆分开发目录环境。这极大地改善了集成测试期间的Spring开发体验。热部署允许在不重新启动服务器的情况下重新加载应用程序。拆分目录开发环境通过尽量减少不必要的文件复制，支持更快的开发和部署。拆分开发目录Ant任务可以帮助用户快速重新编译和重新部署，无需首先生成可部署的存档文件或展开的存档目录。
把Spring库打包为应用程序库、可选扩展或服务器扩展。这允许几个Spring应用程序共享Spring Framework，从而减少了应用程序所占用的内存。除了降低内存占用量外，这还提高了部署次数。
Spring on WebLogic Server工具包
为了帮助客户使部署在WebLogic Server上的Spring应用程序发挥最大的功效，我们已经发布了一个经过认证的BEA发行版，其中包括Spring 1.2.5、MedRec on Spring应用程序以及其他的一些很不错的工具。您可以从BEA的发行版Web站点上免费下载这个工具包。
企业Spring
Spring Framework的非侵入性IoC开发模型不但依赖于对J2EE应用服务器可用的特性集，而且旨在补充该特性集。事实上，在苛刻的生产环境中，底层应用服务器基础架构所提供的服务质量对于Spring应用程序的可靠性、可用性和性能非常重要。WebLogic Server 9.0所提供的企业级特性可以增强Spring应用程序的所有方面。在本节中，我们将详细讨论这些特性，以及如何在Spring应用程序中利用它们。
集群管理和部署
一个WebLogic Server集群包括多个WebLogic Server服务器实例，这些服务器实例同时运行并一起工作，从而提高了可伸缩性和可靠性。对客户端来说，集群就像单个的WebLogic Server实例一样。构成集群的服务器实例既可以运行在同一台机器上，也可以位于不同的机器上。可以通过在现有的机器上向集群添加另外的服务器实例，或者向集群添加机器以驻留增加的服务器实例，来提高集群的容量。WebLogic Server集群为Spring应用程序提供了一个企业级的部署平台，虽然其他的技术产品也支持类似的特性，但是它们不具有WebLogic Server所提供的丰富性和易用性。参见Understanding Cluster Configuration and Application Deployment，其中有对WebLogic Server集群的配置和管理的全面讨论。
Spring应用程序通常都被打包为web应用程序，这种情况下，要利用WebLogic Server集群就无需修改应用程序。只要把应用程序部署到集群中的服务器上，就可以获得增强的可伸缩性和可用性。
Spring会话复制
Spring Web应用程序习惯在HTTP会话中保存信息，比如订单ID和用户信息。为了支持集群中servlet和JSP的自动复制和故障恢复，WebLogic Server支持几种用于保持HTTP会话状态的机制。只要为应用程序提供正确的weblogic.xml部署描述符，Spring Web应用程序就可以非侵入性地使用这些机制。参见配置各类会话持久性，可以获得有关WebLogic Server 9.0的更多可用信息。
集群化的Spring远程控制
Spring提供功能强大的远程控制支持，允许用户轻松导出和使用远程服务，同时仍然可以利用基于POJO的一致编程模型。通过一个接合到适当的Spring bean的RMI接口，Vanilla Spring支持代理POJO调用。然而，这种支持仅限于JRMP（Sun的RMI实现），或者通过JndiRmiProxyFactoryBean使用特定的远程接口。借助于Spring 1.2.5 on WebLogic Server 9.0认证，我们已经扩展了JndiRmiProxyFactoryBean和相关的服务导出程序――这样它就能支持任何J2EE RMI实现的POJO代理，包括RMI-IIOP和T3。这方面的支持还包括一个WebLogic RMI部署描述符，它支持代理RMI接口上的集群化，所以POJO调用可以跨一个WebLogic Server集群进行负载均衡：<bean id="proProxy"
class="org.springframework.remoting.rmi.JndiRmiProxyFactoryBean">
<property name="jndiName" value="t3://:/order"/>
</property>
<property name="jndiEnvironment">
<props>
<prop key="java.naming.factory.url.pkgs">
weblogic.jndi.factories
</prop>
</props>
</property>
<property name="serviceInterface"
value="org.springframework.samples.jpetstore.domain.logic.OrderService"/>
</bean>
服务导出程序如下：
<bean id="order-pro" class="org.springframework.remoting.rmi.JndiRmiServiceExporter">
<property name="service" ref="petStore"/>
<property name="serviceInterface"
value="org.springframework.samples.jpetstore.domain.logic.OrderService"/>
<property name="jndiName" value="order"/>
</bean>
集群化的描述符是自动包含在内的，只需要以适当方式配置集群和将Spring应用程序部署到所有集群成员中。参见故障恢复支持，可以获得更多相关信息。
对Spring组件的控制台支持
Spring on WebLogic Server工具包中包含一个WebLogic Server控制台扩展，它显示了定义在应用程序中的Spring bean、属性和操作。它构建在WebLogic控制台扩展门户框架之上，该框架可以变换WebLogic Administration控制台的外观、功能和布局，而无需修改服务器或控制台代码。将控制台扩展复制到yourdomain/console-ext目录下，则重新启动服务器时就部署了控制台扩展。想要了解有关部署控制台扩展的更多信息，可以参考Spring on WebLogic Server工具包。
自动为不是MBean的Spring bean（大多数Spring bean）创建（JMX）管理接口，然后在applicationContext.xml中配置一个MbeanExporter，并指定哪些bean要通过汇编程序公开，这样控制台扩展就运行了。这项特性是Spring和WebLogic Server进行无缝和非侵入性合作的一个良好例证。要使应用程序支持JMX，只需修改应用程序上下文部署描述符。要使控制台支持Spring，只需将一个简单的jar部署到现有的域即可。
Web服务支持
Spring远程控制功能的另一个方面是它对RPC风格Web服务的支持。WebLogic Server提供基于Ant的工具，用于基于Web服务的WSDL描述生成JAX-RPC存根。Web服务客户端使用这些生成的存根来获取代表服务器端操作的一个远程接口。Spring提供了一个JaxRpcPortProxyFactoryBean来简化了这个过程。我们发现，在WebLogic Server环境中配置JaxRpcPortProxyFactoryBean有些棘手，所以为了节约客户的时间，我们给出下面这个代码片断，演示如何为一个包含复杂类型的Document Literal包装的Web服务配置代理生成。
大部分属性都是自解释的。其中有一些属性比较有名：
serviceInterface是Spring的setter注入的副产品。这个类将表示Web服务操作。
customProperties属性支持定制的WebLogic Server Web服务存根属性。
jaxRpcService值被设置为WebLogic Server生成的JAX-RPC实现服务。JAX-RPC服务负责验证Web服务和加载复杂的类型映射。为了实现后者，必须把WebLogic Server的JAX-RPC服务实现配置为Spring bean。这确保了JAX-RPC服务构造函数的执行，这也是加载类型映射文件的地方。
把JaxRpcPortProxyFactoryBean上的lookupServiceOnStartup设置为false，可以关闭启动期间的JAX-RPC服务查找。这样，查找将在首次访问时进行。这对于与WebLogic Server的可靠请求/响应Web服务通信的客户端来说是必需的，而且此处的客户端也必须是一个Web服务。通常在这些情况下，始发客户端是与Web服务客户端一起部署的。因为直到应用程序部署完成才会激活Web服务，所以客户端Web服务对于Spring的上下文加载是不可用的。<!-- reliable asynchronous Web service for sending new
medical records to medrec -->
<bean id="reliableClientWebServicesPortType"
class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean"
lazy-init="true">
<property name="wsdlDocumentUrl"
value="http://:/ws_phys/PhysicianWebServices?WSDL"/>
<property name="portName" value="PhysicianWebServicesPort"/>
<property name="jaxRpcService">
<ref bean="generatedReliableService"/>
</property>
<property name="serviceInterface"
value="com.bea.physician.webservices.client.PhysicianWebServicesPortType"/>
<property name="username" value="medrec_webservice_user"/>
<property name="password" value="weblogic"/>
<property name="customProperties">
<props>
<prop key="weblogic.wsee.complex">true</prop>
</props>
</property>
</bean>
<!-- allows the jaxRpcService class to execute its
constructor which loads in type mappings -->
<bean id="generatedReliableService"
class="com.bea.physician.webservices.client.PhysicianWebServices_Impl">
</bean>
参见WebLogic Server的调用Web服务概览和通过Spring使用远程控制和Web服务，可以获得进一步的信息。
安全性
WebLogic Server安全系统支持和扩展了J2EE安全性，同时提供一组丰富的安全提供程序，您可以对它们进行定制，然后使用它们来处理不同的安全性数据库或安全性策略。除了使用标准的J2EE安全性之外，应用程序程序员还可以使用很多专有扩展，这些扩展使应用程序可以与安全系统紧密集成。WebLogic Server带有几个安全提供程序，例如，可以选择包含大部分流行LDAP服务器的身份验证数据库、Active Directory、本地Windows和一个内置的身份验证解决方案。可以使用定制的提供程序对内置的提供程序进行扩充，从而几乎可以与任意身份验证数据库、授权机制和凭证映射服务相集成。因为部署为webapp的Spring应用程序使用的是J2EE安全性，所以无需修改应用程序就可以获得WebLogic Server的安全性优点。
经验丰富的Spring用户还会熟悉Acegi――Spring自身的安全框架。目前，可以在应用程序中使用Acegi、WebLogic Server安全性，或同时使用二者，因为它们是相互独立的。稍后我们将讲述与此相关的更多信息。
分布式事务
Spring为事务管理提供了基础架构。除了对各家数据库供应商提供支持之外，Spring还通过一家J2EE供应商的JTA实现支持分布式事务。通过WebLogicJtaTransactionManager，可以把Spring的JTA管理器配置为与WebLogic Server的JTA实现一起工作。
WebLogicJtaTransactionManager把责任直接委派给WebLogic Server的Java Transaction API。WebLogic Server的JTA TransactionManager接口可以通过JNDI为客户端和bean提供者所用，而由Spring来管理这种交互。事务管理器还支持事务的作用域；事务可以作用于集群和域内部或二者之间。
WebLogicJtaTransactionManager最强大的特性是管理分布式事务的能力和用于企业应用程序的两阶段提交协议。通过采用WebLogicJtaTransactionManager，应用程序可以通过WebLogic Administration Console来进行事务监控。WebLogicJtaTransactionManager还支持按数据库(per-database)隔离级别，这种级别支持复杂的事务配置。<!-- spring's transaction manager delegates to WebLogic
Server's transaction manager -->
<bean id="transactionManager" class="org.springframework.transaction.jta.WebLogicJtaTransactionManager">
<property name="transactionManagerName"
value="javax.transaction.TransactionManager"/>
</bean>
<!-- base transaction proxy for which medrec spring beans inherit-->
<bean id="baseTransactionProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
abstract="true">
<property name="transactionManager" ref="transactionManager"/>
<property name="transactionAttributes">
<props>
<prop key="activate*">
PROPAGATION_REQUIRED</prop>
<prop key="create*">
PROPAGATION_REQUIRED</prop>
<prop key="compose*">
PROPAGATION_REQUIRED</prop>
<prop key="deny*">
PROPAGATION_REQUIRED</prop>
<prop key="getRecord*">
PROPAGATION_REQUIRED,readOnly</prop>
<prop key="getPatient*">
PROPAGATION_REQUIRED,readOnly</prop>
<prop key="getLog*">
PROPAGATION_NOT_SUPPORTED</prop>
<prop key="process*">
PROPAGATION_REQUIRED</prop>
<prop key="save*">
PROPAGATION_REQUIRED</prop>
<prop key="send*">
PROPAGATION_REQUIRED</prop>
</props>
</property>
< /bean>
<!-- single point of service for all medrec clients -->
<bean id="medRecClientServiceFacade"
parent="baseTransactionProxy">
<property name="target">
<bean
class="com.bea.medrec.service.MedRecClientServiceFacadeImpl">
<property name="adminService">
<ref bean="adminService"/>
</property>
<property name="patientService">
<ref bean="patientService"/>
</property>
<property name="recordService">
<ref bean="recordService"/>
</property>
<property name="recordXmlProcessorService">
<ref bean="recordXmlProcessorService"/>
</property>
</bean>
</property>
</bean>
想要了解更多信息，请参见Overview of Transactions in WebLogic Server Applications 和 在Spring中实现事务挂起。
Java Management Extension
Java Management Extension（Java管理扩展，JMX）是用于监控和管理Java应用程序的规范。它使一般的管理系统能够监控应用程序，当应用程序需要注意时发出通知，并修改应用程序状态来补救问题。Spring提供广泛的JMX支持，包括通过Spring的MBeanServerConnectionFactoryBean公开WebLogic Server的MBeanServer的能力。MBeanServerConnectionFactoryBean是一个使用方便的工厂，它附带了一个MBeanServerConnection。在应用程序部署期间，连接被建立并缓存，以便稍后由引用bean对其进行操作。
可以配置MBeanServerConnectionFactoryBean，使其返回WebLogic Server的Runtime MBean Server，它会公开特定WebLogic Server实例的监控、运行时控制和活动配置。这包括对WebLogic Server的Diagnostics Framework的访问。此外，Runtime MBean还为当前服务器提供对运行时MBean和活动配置MBean的访问。]
还可以配置MBeanServerConnectionFactoryBean，获得一个到WebLogic Server的Domain Runtime MBean Server的连接。Domain Runtime MBean Server提供对域范围内服务的访问，比如应用程序部署、JMS服务器和JDBC数据源。它还是访问域中所有服务器的所有运行时MBean和活动配置MBean层次结构的单点。这个MBean Server还用作访问位于托管服务器上的MBean的单点。
此外，可以配置MBeanServerConnectionFactoryBean，获得一个到WebLogic Server的Edit MBean Server的连接。Edit MBean Server为管理当前WebLogic Server域配置提供入口点。
注意，WebLogic Server的Domain Runtime MBean Server在部署期间不是活动的。因此，需要使用延迟初始化来配置bean，它会在调用bean时获取该bean。
下面给出了一个使用WebLogic的MBean Server配置Spring的MBeanServerConnectionFactoryBean的例子：<!-- expose WebLogic Server's runtime
mbeanserver connection -->
<bean id="runtimeMbeanServerConnection"
class="org.springframework.jmx.support.MBeanServerConnectionFactoryBean">
<property name="serviceUrl" value="service:jmx:t3://:/jndi/weblogic.management.mbeanservers.runtime"/>
<property name="environment">
<props>
<prop key="java.naming.security.principle">
</prop>
<prop key="java.naming.security.credentials">
</prop>
<prop key="jmx.remote.protocol.provider.pkgs">
weblogic.management.remote</prop>
</props>
</property>
</bean>
想要了解更多信息，请参见Understanding WebLogic Server MBeans 和Spring的 JMX支持。
支持
从WebLogic Server 9.0和Spring 1.2.5开始，BEA为Spring Framework on WebLogic Server提供了可用的支持和认证。这种支持不仅仅是对WebLogic Server上的Spring库进行健全的测试，而且还涉及到BEA与Interface 21――Spring Framework的创建者和维护者之间的共同努力和协作。我们不仅测试了上述的所有Spring 1.2.5的特性和配置，一些新特性还是直接作为BEA和Interface 21的协作成果引入Spring 1.2.5中的。有一些特性需要对WebLogic Server本身进行调整，将来可以以Spring组合补丁的形式得到。
下载
Spring Open Source Framework Support 1.2.5 download包括Spring 1.2.5（已在WebLogic Server 9.0上得到认证）、Spring JMX控制台扩展以及使用Spring Framework重新编写的WebLogic Medical Records示例应用程序。
未来的工作
以后，我们计划提供WebLogic Server与Spring Framework的更深层次的集成。我们已经有了一些想法，其中比较有意思的是：
Spring部署单元：Spring应用程序通常被部署为webapp，但是为Spring应用程序提供一个专门的部署单元是可能的。
Acegi和WebLogic Server安全性集成：Acegi是Spring的安全框架，我们计划将它与WebLogic Server的企业级安全框架进行集成。
使用EJB 3.0实现持久性：因为一般情况下，Spring操纵的是POJO，您很可能需要某种对象-关系映射技术，以便持久化Spring bean。随着EJB 3.0的出现，WebLogic Server将为实现这个目标提供一个标准化的机制。
结束语
我们已经花了一些时间来考察Spring、WebLogic Server以及这两种技术的集成。正如我们所说的那样，Spring可以提高开发人员的效率，而WebLogic Server可以提高应用程序的服务质量。这两种技术都是高度非侵入性的，因此用户可以把精力集中在开发应用程序的业务功能之上，而不是纠缠于特定于技术的API的错综复杂性。
