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版本的高层架构。

    使用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编程规则?D?D特别是在编写接口的代码时。接口比其他东西更能促进更好的协作，因为可以减轻依赖性，而且实现的变化被隔离开来。从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版本的高层架构图。