 |
欢迎使用BEA WebLogic Server 9.0 Beta版!WebLogic Server 9.0是迄今为止最重要的BEA应用服务器版本。这个版本与J2EE 1.4完全兼容，从正面解决了当今企业网络面临的最大挑战：在缩减管理和运营的总体成本的同时，交付高度的可靠性，连续的正常运行时间，可伸缩性，以及任务关键型的集成解决方案。 警告:严禁将WebLogic Server 9.0的Beta版用于生产环境。不保证WebLogic Server 9.0 Beta版与WebLogic Server 9.0的General Availability版或者其他WebLogic Server 版本兼容。WebLogic Server 9.0的这个Beta版和General Availability版可能在配置文件格式、配置数据和永久性数据方面有所不同。 以下各节描述了WebLogic Server 9.0中新的和已变化的功能：
新功能一览WebLogic Server 9.0与J2EE 1.4规范完全兼容。这个版本实现并扩展了最新的J2EE标准——企业Web服务1.1、JMS 1.1、JMX 1.2、JDBC 3.0、Connector Architecture 1.5、EJB 2.1，等等——以便跨企业交付前所未有的服务质量。以下各节概要介绍了关键功能领域中的革新。 系统管理WebLogic Server 9.0主要简化了生产系统的日常管理，同时把对生产环境的破坏降到最低。一个全面的集中式诊断服务使管理员可以实时识别和解决问题，并提供第三方分析工具的集成。WebLogic Server的这个版本引入了一个可扩展性更强、“门户化”的Administration Console（管理控制台），以及一个用于管理域配置变化的、紧密控制的、可预测的流程，而不管您使用的是何种配置工具。新的脚本工具、简化了的域目录结构和模块化部署功能自动化并方便了应用程序配置和部署的过程。 参见系统管理。 性能和可用性对WAN和MAN故障转移的开箱即用支持可以解决灾难性的数据中心故障问题。在WebLogic Server 9.0中，通过使服务器迁移、服务提供、政策驱动的处理、自调整功能、增强的过载保护、跨群集的故障转移等变为自动化，总体的服务器性能得到了极大提高。 企业Web服务现在，通过提供一个通用运行时环境和对Java注释和Web服务扩展的行业标准支持，基于J2EE标准的Web服务提高了开发人员的灵活性，并扩大了他们的选择范围。Web Services 1.1的WebLogic Server实现让开发人员能够更有效地对业务需求的变化做出响应，为会话式应用程序提供真正的异步消息收发支持；为企业面向服务的架构（service-oriented architecture，SOA）而设计的互操作功能；以及改进后的XML处理。开发人员可以利用WebLogic Web Service快速创建、部署和改编安全的、可完全互操作的企业Web服务。 参见J2EE标准Web服务。 企业就绪的企业消息基础架构WebLogic Server 9.0实现了跨域通信；企业信息系统中的双向事务；具有高可用性的自动目的地迁移；提高了可靠性的消息存储和转发；紧密控制的消息传送顺序。另外，这个版本还提高了企业和消息密集型应用程序的管理效率和性能。 参见Java消息服务(JMS) 和资源适配器。
系统管理以下各节描述了WebLogic Server 9.0中新的、增强的和不鼓励使用的功能，这些功能会影响总体的服务器管理。
服务器操作以下各节描述了对WebLogic Server核心操作的关键修改和改进。 服务器生命周期状态隔离管理操作 一个新的生命周期状态，即 了解服务器的生命周期。 工作上下文使实现和维护更轻松开发人员可以把属性定义为工作上下文，然后在没有在远程调用中显式包含属性的情况下传递它们。工作上下文是通过每次远程调用进行传播的——这允许被调用的组件添加或修改定义在工作上下文中的属性。类似地，调用组件可以访问工作上下文来获得新的或者更新后的属性。 工作上下文使实现诊断监控、应用程序事务和应用程序负载平衡变得更加方便，因为它们都需要与远程组件进行通信。它们还提供信息给第三方组件。 客户端和服务器可以同时使用工作上下文，也可以各自单独使用它。 网络通道可以管理服务器实例之间的通信除了管理外部网络通信之外，网络通道现在还可以管理服务器实例之间的网络通信。其他针对网络通道新的和改进的配置和控制选项包括： 影响核心功能的配置永久性变化
系统范围内的默认持久性存储器WebLogic Persistent Store是一个内置的、高性能的存储解决方案，用于要求持久性的WebLogic Server子系统和服务，特别是需要创建和删除短期数据对象的子系统，比如JMS服务器的事务性消息。域中的每个服务器实例都有一个不需要配置的默认持久性存储器，而且不需要显式地选择特定存储器，但是可以使用系统的默认存储器的子系统可以同时使用这些存储器。这些子系统包括JMS服务器、Web 服务、EJB计时器服务、存储和转发服务，以及JTA Transaction Log (TLOG)。另外，管理员可以配置基于文件的专用存储器或者可通过JDBC访问的存储器，以便适用于他们的环境。 参见设计和配置WebLogic Server环境中的使用WebLogic持久性存储器。 用于实现高度可用消息收发的存储和转发服务WebLogic存储和转发（Store-and-Forwar，SAF）服务使WebLogic Server能够在分布在WebLogic Server实例上的应用程序之间可靠地传递消息。例如，借助SAF服务，运行在或者连接到一个本地WebLogic Server实例上的应用程序可以可靠地发送消息给位于某台远程服务器上的目的地。如果该目的地在发送消息时不可用，那么消息将被持久地保存在一个本地服务器实例上，然后当远程目的地变为可用时被转发给该目的地。 WebLogic JMS使用SAF服务，使本地的JMS消息生产者能够可靠地发送消息给远程的JMS队列或主题。WebLogic Web服务在SAF服务的基础上构建Web Services Reliable Messaging (WSRM)的实现。 参见“配置和管理WebLogic存储与转发服务”，以便获得有关WebLogic存储与转发服务的优点和使用的更多信息。 控制台的新观感和新功能在当前版本中，WebLogic Server Administration Console（管理控制台）已经得到了完全的重新设计。现在，管理控制台构建在WebLogic Portal Framework之上，这使得它更加开放，更加容易扩展。其他的新功能包括：
管理控制台中的门户应用程序支持管理控制台的新架构基于WebLogic Portal Framework，而且管理控制台使用构建在Structs之上的模型-视图-控制器方法，这使得控制台更加开放，更加易于扩展。现在，可以以常用于扩展门户应用程序的方式来扩展管理控制台。控制台扩展可以包括现有页面、新页面和小节，以及JSR 168或WSRP portlet的简单改写。 就像前面的版本一样，控制台扩展可以添加或删除控制台功能。控制台扩展还可以修改控制台外观的各个方面，比如颜色或者标志图片。然而，新的架构需要用于扩展管理控制台的新过程。在以前版本的WebLogic Server上构建的管理控制台扩展在新的控制台基础架构上不起作用。在这个版本中，体系和结构变化的范围使兼容性和迁移变得不能实现。 域配置变化的可预测发布无论您使用的是管理控制台、新的WebLogic Scripting Tool、JMX还是其他API，变化管理中的改进使您能够在整个域中安全地、一致地和可预测地发布配置变化。 为了保护您的修改并防止其他人进行修改，管理控制台中引入了一个新的区域，称为Change Center，在您开始修改域配置之前，它将会要求您锁定管理控制台。 当您完成修改时，您保存这些修改并将它们发布到域中的所有实例（或者，您可以回滚修改并释放锁定）。每台服务器自行决定它是否接收修改。如果所有的服务器都接受修改，它们将更新它们的工作配置树，修改完成。如果有一台或多台服务器不接受修改，那么所有的服务器都不会使修改生效，因此避免了出现未完成的中间状态。这种功能有助于确定WebLogic Server配置信息总是正确和一致的。 通常WebLogic Server以同样的方式控制配置更改，而不管这些修改是使用管理控制台、WebLogic Scripting Tool还是配置管理器服务和JMX API实现的。
WebLogic Scripting Tool自动化域配置任务WebLogic Scripting Tool （WLST）是一个新的命令行接口，您可以使用它来配置WebLogic Server实例和域，并管理和持久化WebLogic Server配置变化。
基于Java脚本解释器Jython, WLST 解释命令的方式有两种，要么使用命令提示一次交互式地解释一个命令，要么使用文件（脚本）或嵌入在您的Java代码中进行批处理解释。您可以在线（连接到运行的服务器）或离线（没有连接到运行的服务器）使用脚本工具。
不鼓励使用weblogic.Admin实用工具，但是WebLogic Server的当前版本仍然支持它。建议使用WebLogic Scripting Tool（WLST）中的等价功能。 可见性更好、运行时控制程度更高的集中式诊断服务新的WebLogic诊断服务（Diagnostic Service）把所有诊断功能集成到一个集中而统一的框架中，该框架使您能够创建、收集、分析诊断数据，并以标准格式将这些数据存档。诊断服务为服务器及其应用程序提供更好的可见性和运行时性能控制，这允许您在故障出现时诊断并找出它们。 以下各节进一步描述了WebLogic诊断服务功能。想要了解更多详细信息，请参见了解WebLogic诊断服务。
增强的可见性WebLogic诊断服务为量度、数据事件和日志及调试信息提供一种动态的视图。它还在服务器范围内公开了以前未曾公开过的新诊断数据。 以标准格式记录日志WebLogic Server的以前版本包含大量独立的日志记录功能，比如标准的服务器和域日志、JDBC日志和访问日志。这些日志依赖于不同的实现，因此无法使用与标准日志相同的服务和工具（比如旋转）。现在，这些日志记录解决方案已经与为所有服务器日志记录提供相同服务质量的一种实现统一。您可以配置WebLogic诊断服务，以便收集、分析WebLogic日志记录服务生成的所有事件并将它们存档。 动态的定制检测您可以有选择性地对运行环境中Weblogic Server和用户编写的应用程序添加和删除诊断代码。您可以收集和分析运行时数据事件的特定类型。此外，在特定的情况下，您可以在服务器运行时动态改变在特定位置上执行的诊断代码的行为，具体方法是改变在这些位置上活动的诊断操作。 用于重构和事件相关的诊断上下文诊断上下文是一种重构事务性事件，以及基于出现的时间选择或逻辑关系关联事件的方法。您可以从请求到响应重构或拼凑一个执行线程，或者只在诊断上下文中的上下文信息满足某种条件时生成诊断信息。这种功能把所生成信息的数量和开销保持在可以管理的水平。 针对单个请求或单个客户端的事件捕捉大多数事件收集是通过在应用程序流中指定关键点，然后监控通过这些点的每个请求来实现的。然而，为了最小化收集量并促进事件孤立，有时候，只针对来自单个客户端的单个请求或多个请求捕捉事件是更可取的做法。WebLogic诊断服务允许您对特定的请求做标记或着色，这样WebLogic诊断服务就能够确定是否应该监控它。WebLogic诊断服务在请求进入系统时标记它们，具体方法是在上面讨论过的诊断上下文中设置标志。 从服务器和应用程序收获数据可以对Harvester组件进行配置，以便收集包含在服务器Mbeans中的量度。另外，因为WebLogic诊断服务使您能够从您提供的定制Mbeans获得量度，您还可以从您自已的应用程序收集量度。 用于故障后分析的服务器图片捕捉WebLogic诊断服务的Server Image Capture组件会按照需要或者自动创建一个来自服务器的诊断快照。服务器状态的最常用资源——配置，Log Cache, WorkManager, JNDI状态, 和可收获的数据——被捕捉到，以及来自JMS、JDBC、EJB、JNDI和其他服务器子系统的图片。 当服务器在短时间内重复出现故障和恢复——例如，在由于暴风雨造成的电源故障中——系统管理员还可以指定一段图片封锁期，这可以防止服务器重复性地捕捉和持久化类似的诊断图片，因为这只会不必要地消耗系统资源。 通知提供与遗留监控软件更紧密的集成已经在企业中开发过用于陷入、路由和处理系统事件的软件的客户，可以把诊断服务配置为分析这些定制应用程序事件，并自动生成通知来警告系统管理员。这种功能支持与较大型客户环境中的遗留监控框架更紧密地集成。 为了监控WebLogic Server，可以配置监视程序来检测特定的条件，并分析日志和调试日志记录、数据事件和所获得的量度。监视程序还可以触发各种类型的通知监听器，包括简单邮件传输协议（Simple Mail Transfer Protocol，SMTP）,简单网络管理协议（Simple Network Management Protocol，SNMP）, Java管理扩展（Java Management Extensions ，JMX），以及Java消息服务(Java Message Service，JMS)。 对当前和历史的数据进行动态和离线的访问从服务器以及运行在该服务器上的应用程序收集而来的所有数据都被永久保存到持久性存储中。Data Accessor组件提供对由WebLogic诊断服务收集而来的当前和历史数据的访问，包括数据事件、日志记录和所获得的量度。您可以以在线模式（在运行的服务器上）和离线模式（在服务器关闭之后）访问这些已存档的数据。 第三方分析工具的标准集成WebLogic诊断服务为第三方监控和分析工具提供标准的集成功能:
WebLogic诊断服务与现有的诊断工具和功能相互兼容，比如BEA合作伙伴开发的测试工具。WebLogic诊断服务使合作伙伴与它们的工具集成更加容易，而BEA Systems取得了集成接口的所有权，并提供相应的支持、文档和经过改进的服务质量。 WebLogic日志服务控制日志量LogMBean接口的增强让您可以控制日志输出，具体方法是设置严重性级别，并过滤日志记录器和处理器。 在WebLogic Server的早期版本中，系统管理员和开发人员只能通过编程访问日志记录器和处理器。在这个版本中，您可以通过使用Mbeans来配置处理器，从而根除了为大多数基本的日志记录配置编写代码的需要。管理控制台和WebLogic Scripting Tool（WLST）提供一个可以与日志Mbeans交互的接口。只能通过API配置日志记录器。 对Log4J的支持WebLogic Server支持Jakarta项目Log4j。，您可以在管理控制台中指定Log4j或者默认的Java
Logging实现。另外，您还可以使用CODE style="font-family: courier">LogMBean.isLog4jLoggingEnabled属性通过 对Commons API的支持Jakarta Commons Logging API提供一个抽象层把用户和底层的日志记录实现隔离开来。WebLogic
Server提供Commons 新的日志文件目录和位置
日志内容增强Web应用程序和资源适配器日志记录 在这个版本的WebLogic Server中，您可以使用特定于WebLogic的部署描述文件来配置Web应用程序和资源适配器日志记录行为。日志记录配置部署描述文件定义了用于通过 类似地，也为
服务器的可靠性、可用性、可伸缩性和性能WebLogic Server 9.0极大地改进了服务器和群集RASP:
自动和手动迁移服务器到另外的计算机上现在，WebLogic Server支持自动和手动把集群化的服务器实例和以它为宿主的所有服务从一台计算机上迁移到另一台计算机上。这种功能是为要求高度可用性的环境而设计的。使用服务器迁移功能可以： 参见使用WebLogic Server集群中的服务器迁移。 对CommonJ Timer和Work Manager API 规范的支持WebLogic Server 9.0支持部分BEA 和IBM 联合规范 (CommonJ)，http://dev2dev.bea.com/technologies/commonj/index.jsp上描述了这个规范。特别地，这个版本还实现了Timer和Work Manager 1.1 规范，您可以在http://dev2dev.bea.com/technologies/commonj/twm/index.jsp上面找到这个规范。 Timer API提供一个简单的API，应用程序可以使用这个API创建和使用应用服务器中管理的计时器，建议使用这个计时器代替 Work Manager API使应用程序能够把一个请求分为多个工作项，并指派使用WebLogic Server中配置的多个Work Manager并发地执行这些工作项。（不需要执行并发的工作项的应用程序也可以使用配置好的Work Manager，具体方法是在它们的部署描述文件中引用或创建Work Manager，或者对J2EE Connector使用JCA API。）还可以参见针对生产环境的服务器自调整 ，以便获得有关新的Work Manager 调整策略的更多信息。 跨广域网或城域网的HTTP会话复制和故障转移运行在一个集群中的服务器实例上的HTTP会话的状态，可以被复制到另一个WebLogic Server集群中的服务器实例上。集群可以位于同一个城域网（metropolitan area network，MAN）中的不同LAN上，或者位于广域网（wide area network，WAN）中地理上相隔很远的位置，比如不同的城市或省。首要的服务器实例出现故障之后，相同集群中的另一个成员可以从远程实例（位于另一个集群中）恢复会话数据，并使其在首要的集群中可用。如果在首要服务器出现故障的集群中，没有其他成员可用，请求可以通过故障转移传递到作为会话复制宿主的远程集群中。 下面给出两个示例环境，WebLogic Server的跨集群会话复制功能在其中很有用处：
针对生产环境的服务器自调整新的自调整功能简化了针对生产环境配置WebLogic Server的过程，这里的生产环境的服务等级需求是随着时间的推移或应用程序的不同而变化的。自调整功能有助于防止请求高峰期间的死锁情况。此外，如果您的WebLogic Server环境是多个应用程序的宿主，而这些应用程序具有不同的性能和可用性要求的话，自调整功能就可以发挥作用了——例如，允许您为面向用户的订单处理应用程序分配的资源比为后端库存管理应用程序分配的资源多。 新的队列策略使管理员能够更加有效地分配处理资源和管理性能，具体是通过消除在配置、监控和调整定制执行队列过程中涉及的开销和复杂性。
Node Manager（节点管理器）增强
参见设计和配置WebLogic Server环境中的使用Node Manager控制服务器 为每个请求动态生成集群地址在这个版本中，您仍然可以显式地定义集群地址，但是如果您没有，WebLogic Server将为每个请求动态生成集群地址。这项功能简化了配置过程，并确保启动时集群地址正确地反映集群成员。参见使用WebLogic Server集群中的集群地址。 新的过载保护提高了可用性新的过载功能可以保护服务器免于出现内存耗尽（out-of-memory，OOM）的异常，执行队列过载，提高服务器或集群的可用性。
J2EE标准Web服务现在，Web服务已经成为一个J2EE标准，这导致了8.1和9.0 WebLogic Web服务之间出现了很多变化。 WebLogic Server 9.0包括以下新的Web服务功能：
想要了解更多有关8.1和9.0 Web服务之间差别的信息,请参见WebLogic 8.1和9.0 Web服务之间的差别。 WebLogic 8.1和9.0 Web服务之间的差别J2EE 1.4引入了一个标准的Java组件模型，用于使用新的规范编写Web服务，比如实现企业Web服务（JSR-921、JSR-109的1.1维护版本）和用于XML注册的Java API (JAX-R)，以及已经更新的JAX-RPC和SAAJ规范。 结果，用于创建WebLogic Web 服务的9.0编程模型也出现了变化。现在，该模型使用了JDK 5.0版本中引入的功能强大的元数据注释新功能（由JSR-175)指定）。另外，WebLogic Web服务运行时使用的运行时环境现在支持实现企业Web服务 规范。 参见8.1和9.0 WebLogic Web服务之间的差别。 基于JWS注释的编程模型用于创建9.0 WebLogic Web服务的编程模型基于新的JDK 5.0元数据注释功能 (由JSR-175)指定)。在这个模型中，您的Web服务的实现是一个使用JWS注释的Java文件，这由java平台的Web服务元数据规范(JSR-181)所定义。 注意:尽管使用JWS注释是创建WebLogic Web服务的首选编程模型，您还是可以手动创建WebLogic Web服务，具体方法是对实现Web服务的EJB或Java类进行编程，并创建所有必需的组件，比如Web服务部署描述文件和WSDL文件。 参见对JWS文件进行编程。 J2EE 1.1实现的Web服务Web Services for J2EE规范的1.1版本为使用Java实现Web服务定义了标准的J2EE运行时架构。 JSR-921是JSR-109的1.1维护版本，而JSR-109是Web服务的1.3规范。JSR-921目前在JCP（Java Community Process）的最后一个版本中。 松散耦合的异步Web服务
数字签名和加密调用Web服务时，WebLogic Web服务支持对生成的请求和响应SOAP消息进行数字签名和加密。这项功能来自与OASIS Standard 1.0 Web Services Security规范的一致性： 正如WS-Policy规范指定的那样，消息级别的安全性是使用安全策略语句进行配置的。 参见配置安全性。 XML和Java之间的数据绑定和以前版本一样，WebLogic Web服务支持一整套内置的XML模式、Java和SOAP类型，这一点在JAX-RPC 1.1规范中已有描述。您可以在您的Web服务操作中使用这些类型，而 无需执行任何额外的编程步骤。 另外，您可以使用各种用户定义的XML和Java数据类型，包括XMLBeans，作为您的Web服务的输入参数和返回值。WebLogic Web服务Ant任务自动生成在XML和Java表示之间转换用户定义的数据类型所需的数据绑定组件。 参见数据类型和数据绑定。 使用策略文件WebLogic Web服务9.0实现了WS-Policy规范，此规范提供了一个通用模型和相应的语法来描述和传递Web服务的策略。在这个版本中，策略文件只能用于配置可靠的消息收发和安全性功能。 参见针对消息级别的安全性配置使用WS-Policy文件和 针对可靠的SOAP消息配置使用WS-Policy文件，以便了解关于如何使用WS-Policy文件分别配置安全性和可靠的消息收发的更多信息。 处理JWS文件的Ant任务有一组Ant任务用于处理JWS注释文件，并把它们集成到WebLogic分裂开发目录环境中。这个开发环境包括一个目录布局，以及帮助您重复性地构建、修改和部署J2EE应用程序的相关Ant任务，包括Web服务。 参见Web服务Ant任务参考。 与标准Web服务相关的Java规范的实现WebLogic Server 9.0中的Web服务实现了以下标准的Java规范：
与标准Web服务规范的一致性WebLogic Server 9.0中的Web服务与以下标准Web服务规范保持一致:
Java消息服务(JMS)WebLogic Server 9.0在WebLogic JMS的配置、部署和动态管理方面发生了很多较大的变化。
想要了解有关这些与其他新功能，以及WebLogic JMS方面变化的更多信息，请参见配置和管理WebLogic JMS中的“这个版本中新的和发生变化的JMS功能”。 JMS 1.1规范对生产环境的支持在生产中使用时，WebLogic Server 9.0与新的JMS 1.1规范 兼容，因此也支持用于队列和主题的统一API。参见Sun Web站点http://java.sun.com/products/jms/上的Java JMS技术页面。 JMS资源的模块化配置和部署 在WebLogic Server 9.0中，JMS配置被保存为模块，由符合新的 借助JMS资源的模块化部署，您可以把您的应用程序和必需的JMS配置从一个环境迁移到另一个环境，比如从测试环境迁移到生产环境，同时无需打开EAR文件和大范围地手动重新配置JMS。 参见配置和管理WebLogic JMS中的了解JMS资源配置。 用于生产高度可用消息的存储和转发功能JMS存储和转发（Store-and-Forward）功能构建在WebLogic存储与转发(SAF)服务之上，提供高度可用的JMS消息生产。例如，连接到本地服务器实例的JMS消息生产者可以把消息可靠地转发给远程JMS目的地，即使当发送消息时远程目的地可能暂时不可用。JMS存储和转发对于JMS应用程序是透明的；因此，JMS客户端代码仍然使用现有的JMS API访问远程目的地。 参见“配置和管理WebLogic存储与转发服务”。 增强的运行时消息管理大范围的消息管理改进，极大地增强了JMS管理员使用管理控制台或新的公共运行时API查看和操纵运行JMS服务器中消息的能力。这些消息管理增强包括消息浏览（用于排序），消息操纵（比如移动和删除），消息导入和导出，以及事务管理，持久的订阅者和JMS客户端连接管理。 暂停和恢复目的地上的消息操作新的WebLogic JMS配置和运行时API使管理员能够在给定的JMS目的地上，或者在通过编程或管理方式以一台JMS服务器为宿主的所有目的地上，暂停和恢复消息生产、消息插入（动态消息）和消息消费操作。这项功能使管理员能够在外部资源故障事件中控制JMS子系统行为。 消息生命周期记录带来的更多透明性消息生命周期是JMS消息被JMS服务器接受之后，它所经过的基本事件的外部视图。从JMS服务器的角度来说，消息生命周期日志记录（Message Life Cycle Logging）功能将会给JMS消息带来更多透明性，特别是在基本的生命周期事件中，比如消息生产、消费和删除。日志记录可以连续发生，也可以很长时间才发生一次。当JMS服务器运行时，可以以实时模式使用它，或者当JMS服务器停机时通过离线的方式使用它。 参见配置和管理WebLogic JMS中的这个版本中新的和发生变化的JMS功能。 更加易用的调试和诊断信息JMS子系统使用新的WebLogic诊断系统服务来集中调试访问和日志记录。调试和诊断信息更加易于使用，所以您可以轻松诊断并修复问题。 借助Unit-of-Order对消息进行严格排序Unit-of-Order功能已经超出了JMS 1.1规范中的消息传送排序要求，因为它使JMS消息生产者能够把消息分组排序为一个单元。这个单元称为Unit-of-Order，它保证从该单元创建的所有消息都会依次被同一个消费者处理，所依照的顺序是创建它们的顺序，直到消费者对它们做出应答或者被关闭为止。例如，如果一个队列有具有很多消费者的消息，而且每条消息都有一个编号作为Unit-of-Order，那么两个消费者将不会同时处理具有同样帐号的消息。 参见WebLogic JMS编程使用消息Unit-of-Order。 统一分布式目的地统一分布式目的地（uniform distributed destination）是一种新类型的分布式目的地，它极大地简化了分布式目的地应用程序的管理和开发工作。使用这项功能，管理员不再需要创建或指派目的地成员，而只要依赖于系统统一在JMS模块以其为目标的JMS服务器上创建必需的成员。这些功能确保一致地配置所有分布式目的地参数，特别是关于加权、安全性、持久性、分页和限额时。 在C程序中访问JMS应用程序Weblogic JMS C API使使用“C”语言编写的程序能够参与JMS应用程序。JMS C API的这种实现使用了JNI，以便访问Java虚拟机（Java Virtual Machine，JVM）。 参见WebLogic JMS编程中的WebLogic C API 。 JMS的消息驱动Bean（MDB）增强MDB增强支持事务批处理（通过在一个事务中处理多条消息），也支持跨不同集群或域中的成员目的地对分布式目的地实现负载平衡，不论MDB和目的地是位于同一个集群中还是不同的集群或域中。 参见消息驱动Bean增强。 对XML消息的文档对象模型（DOM）支持WebLogic JMS API得到了增强，目的是为XML消息传输过程中的文档对象模型（Document Object Model，DOM）提供本地支持。这项功能可以提高已经使用DOM的实现的性能，因为这些应用程序不必在发送XML消息之前使DOM变得规则。 参见WebLogic JMS编程中的发送XML消息。 不鼓励使用的JMS特性、方法和接口在WebLogic Server 9.0中，JMS子系统发生了很多变化，包括删除了一些类和不鼓励使用许多Mbean。想要查看不鼓励使用JMS API的完整清单，请参见配置和管理WebLogic JMS中的这个版本中新的和发生变化的JMS功能。 遗留JMS配置接口用于配置JMS资源的、基于描述文件的新方法使用Java Descriptor Bean接口创建可部署的JMS资源模块。这个基本的变化要求不鼓励使用大多数JMS配置MBean接口，但JMSServerMBean接口除外。 JMS帮助APIs用于配置JMS模块资源的、基于描述文件的新方法要求不鼓励使用JMSHelper类，这个类是用于定位JMS运行时和配置JMS Mbeans的。这个类被新的JMSModuleHelper所代替，这个新类也有用于在给定模块中定位JMS运行时Mbean和管理JMS模块（包括JMS Interop模块）配置实体的方法。 参见the JMSModuleHelperJava文档。 JMS会话池和JMS连接消费者MBean 接口JMSSessionPoolMBean（及其JMSServerMBean上的相关方法）和JMSConnectionConsumerMBean接口已经不被鼓励使用。这些接口用于自动创建JMS会话池和启动服务器端的JMS消费者。ConnectionConsumer和ServerSessionPool API仍然被支持，但是BEA强烈推荐使用消息驱动bean（MDB），后者更加简单、易于管理且功能更加强大。 JMS 文件存储和JMS JDBC存储Mbean接口新的WebLogic Persistent Store要求不鼓励使用JMSStoreMBean、 JMSFileStoreMBean和JMSJDBCStoreMBean接口。不鼓励使用的还包括JMSServerMBean接口上任何相关的JMS Store方法。 参见设计和配置WebLogic Server环境中的使用WebLogic持久性存储。
资源适配器现在，WebLogic Server完全支持J2EE 1.5连接器架构和基于J2EE 1.0 连接器架构的资源适配器。1.5版本的部署描述文件是基于模式的，而1.0版本的部署描述文件是基于DTD的。除了已经指出的地方之外，以下各节也描述了1.5版本适配器的新功能：
多个出站连接现在，J2EE 1.5连接器架构支持带有多个出站连接的资源适配器。出站资源适配器允许应用程序连接到EIS系统，然后进行工作。所有的通信都由应用程序进行初始化。资源适配器充当用于连接到EIS并在应用程序线程上下文中执行的被动库。参见WebLogic资源适配器编程中的了解资源适配器。 入站-出站部事务以前版本中的资源适配器支持对外的消息收发。现在，1.5版本的资源适配器还可以从EIS获取事务，包括消息。EIS可以发送事务性上下文，在这个上下文中，可以传送消息或者以Work Request的形式执行工作。消息端点应用程序（消息驱动bean和其他可能的J2EE组件）通过资源适配器从EIS接收入站消息。这项功能使通过J2EE标准接口使用WebLogic Server专有的InterposedTransactionManager成为可能，这允许J2EE应用程序完全参与到由外部事务管理器控制的企业环境中。在EJB 2.1之前，消息驱动bean (MDB)只支持Java消息服务（JMS）消息收发。参见WebLogic资源适配器编程中的消息收发和事务流入。 连接代理不再必要现在，1.5版本的资源适配器在无需使用连接代理的情况下，支持后期事务征用和空闲连接检测。参见WebLogic资源适配器编程中的连接管理。 对外部应用程序组件的RAR可见性Connector规范禁止应用服务器提供对由EAR外部的应用程序组件定义在EAR中的资源适配器的访问。然而，WebLogic Integration持续要求提供这种访问。weblogic-ra.xml部署描述文件的enable-access-outside-app元素为显式地启用这类访问提供一个配置参数。参见WebLogic资源适配器编程 中的weblogic-ra.xml模式。 资源适配器生命周期管理应用服务器调用新的start()和stop()方法，并把它们当作其在1.5资源适配器上部署和取消部署动作的一部分。参见WebLogic资源适配器编程中的打包和部署连接器。 Suspend( )和Resume( )加速动态事务新的suspend()和resume()方法使1.5资源适配器能够关闭所有传入的消息，同时允许动态事务完成，然后恢复常规操作。参见WebLogic资源适配器编程中的配置。 自调整Work Manager避免直接创建线程J2EE 1.5 连接器架构规范建议不要让资源适配器创建线程。为了使资源适配器能够在不直接创建线程的情况下执行工作，特别加入了一个能够自调整的、可配置的Work Manager，用于在应用服务器的控制之下创建WorkRequests 。Work Manager是可配置的，而且允许您对资源进行管理。参见WebLogic资源适配器编程中的消息收发和事务流入。 资源适配器安全身份现在，可以通过weblogic-ra.xml部署描述文件的元素配置新的安全身份。参见WebLogic资源适配器编程中的安全性。 JNDI树中作为独立对象的适配器1.0版本的资源适配器是由它们在JNDI树中的ConnectionFactory对象来标识的。现在，1.5版本的资源适配器作为独立对象存在于JNDI树中，这使得它们可以用作系统资源或MDB的消息资源。参见WebLogic资源适配器编程in 连接管理。 特定于连接工厂和适配器范围内的属性所有事务和安全属性设置都适用于所有出站连接工厂。BEA已经扩展了这项功能，以支持每个连接工厂的设置和资源适配器范围内的属性。这包括每个连接工厂都有的凭证映射。参见WebLogic资源适配器编程中的安全性。 针对单个池化连接的可见性测试（ping）现在，您可以针对特定的ManagedConnectionFactory测试特定的出站连接或整个出站连接池。测试整个池将单独测试池中的每个连接。参见WebLogic资源适配器编程中的连接管理。 1.0适配器的可配置连接代理生成如果您已经知道资源适配器中是否使用连接代理，通过把weblogic-ra.xml的WebLogic Server 8.1版本中的use-connection-proxies 元素显式地设置为true 或false，您可以避免测试代理。这适用于基于J2EE 1.0 连接器架构的资源适配器（这个版本中仍然支持）。参见WebLogic资源适配器编程中的连接管理。 不鼓励使用link-ref机制link-ref机制是1.0版本的资源适配器的一项功能，已经不鼓励使用，但是当前版本仍然支持。该功能允许子资源适配器引用基础的资源适配器，使子资源适配器可以访问基础资源适配器的类和配置。对于1.5版本的资源适配器来说，这种机制被联合应用程序所取代，联合应用程序是一个可以被任何应用程序访问的单独模块。参见WebLogic资源适配器编程in 配置。
JDBC下面几节描述了在WebLogic Server 9.0中JDBC的新特性和变化：
有关WebLogic JDBC中这些特性和变化及其他新的特性和变化的更多信息，参见配置和管理WebLogic JDBC中的“WebLogic JDBC中的新的和变化的特性”。 JDBC 3.0支持WebLogic Server 9.0是符合JDBC 3.0规范的。有关JDBC 3.0特性的更多信息，请参见Sun Web站点上的Java JDBC技术页：参见http://java.sun.com/products/jdbc/。有关WebLogic JDBC的更多信息，请参见配置和管理WebLogic JDBC。 RowSet扩展WebLogic RowSet实现符合并扩展了新的JDBC RowSet实现规范（JSR-114）。请参见Sun Web站点上的Java JDBC技术页：http://java.sun.com/products/jdbc/。 WLCachedRowSets扩展了几个标准RowSet类型，并可以与他们交换使用。它还包括一些用于设置乐观并发选项和数据同步选项的方法。SharedRowSet扩展了CachedRowSets，以便可以创建其他的CachedRowSets，基于原始CachedRowSet中的数据用在其他线程中。SortedRowSets扩展了CachedRowSets，以便CachedRowSet中的行可以在内存中排序，而不是取决于数据库管理系统进行排序处理。SharedRowSets和SortedRowSets通过减少应用程序所需的数据库往返的次数来提高性能。 参见WebLogic JDBC程序设计“在WebLogic Server中使用Rowsets”。 J2EE管理模型的支持（JSR-77）WebLogic Server 9.0 JDBC完全支持定义J2EE管理模型的JSR-77。您访问J2EE管理模型以监视资源，包括整个WebLogic JDBC系统、加载到内存的JDBC驱动程序和JDBC数据源。 JDBC资源的模块化配置和部署 WebLogic Server 9.0中的JDBC配置现在存储在符合新 在WebLogic Server 9.0中，为了支持JDBC应用程序模块的新的部署模型，BEA现在为WebLogic JDBC模块提供了一个模式。您创建的每个JDBC系统模块或应用程序模块必须符合模式。IDE和其他工具可以根据模式验证JDBC模块。 有关WebLogic JDBC资源的更多信息，请参见配置和管理WebLogic JDBC。 较少的资源类型用于更简单的JDBC配置较少的JDBC资源类型简化了JDBC配置，并减少了配置错误的可能性。不是配置资源池，然后配置数据源或事务性（tx）数据源来指向连接池，并绑定到JND树，您配置了包括连接池的数据源。 另外，MultiDataSources替换了MultiPools。MultiDataSource不要求另外的数据源来把它绑定到JNDI树。如果您使用Administration Console（管理控制台），您就可以在一个步骤中配置MultiDataSource和所有包括的数据源。 JDBC监视和诊断增强功能新的JDBC资源的监视和配置信息新的数据源使用信息可以通过Administration Console（管理控制台）和JMX使用：
用于监视驱动程序级统计的回调在JDBC驱动程序上调用的方法的回调让您能够监视和分析JDBC驱动程序使用，包括正在执行的方法、抛出的异常及花在执行驱动程序方法上的时间。 JDBC调试增强功能JDBC子系统使用新的系统级WebLogic诊断服务来进行集中的调试访问和日志记录。 在全局事务中针对非XA资源的优化性能您可以启用数据源的Logging Last Resource (LLR) 事务优化，这使得一个非XA资源能够参与全局事务，并且具有提高的性能和与XA相同的ACID（原子性、一致性、隔离性和永久性）保证。
参见配置和管理WebLogic JDBC中的“了解Logging Last Resource（LLR）事务选项”。 WebLogic和数据库用户ID的凭证映射JDBC数据源的凭证映射让WebLogic Server能够在数据库连接上把映射的数据库用户ID作为轻量级客户端ID设置。这可以减少使用特定数据库用户ID创建新连接的需要，或者可以让您的应用程序利用连接池化性能的优点。 参见配置和管理WebLogic JDBC“ 为数据源配置凭证映射”。 支持XA事务的多数据源如果您配置多数据源使用的数据源来使用XA JDBC驱动程序，您就可以为包括全局事务的应用程序利用多数据源中的故障转移特性。 参见配置和管理WebLogic JDBC中的“多数据源中的XA支持”。 MySQL支持WebLogic Server 9.0支持与MySQL数据库一起使用（MySQL是一种流行的开源生产就绪数据库管理系统）。MySQL Connection/J JDBC驱动程序是与WebLogic Server一起安装的。MySQL被认证可以与JMS、JDBC和EJB容器管理持久性一起使用。MySQL不支持XA或JTA。 更新的WebLogic Type 4 JDBC驱动程序更新到WebLogic Type 4 JDBC驱动程序解决了一些重要问题，并包括了一些值得注意的增强功能。有关更多信息，请参见WebLogic Type 4 JDBC驱动程序。 不鼓励使用的JDBC特性、方法、接口和MBeans
企业JavaBeansWebLogic Server 9.0符合EJB 2.1规范，并包括了许多EJB可用性改进，如下面几节所描述。 有关所有这些特性的更多信息，请参见WebLogic Server EJB程序设计。 支持EJB 2.1规范的新特性下面几节描述了符合J2EE EJB 2.1规范的新的WebLogic Server特性。 用于建模业务流程的EJB计时器服务为了兼容EJB 2.1，WebLogic Server EJB计时器服务让您能够在特定的时间，在消逝时间周期的结束或以重复的时间间隔计划通知。 EJB-QL变化为符合EJB 2.1规范，在WebLogic Server 9.0中已经添加了下面的企业JavaBeans查询语言（EJB-QL）功能，或对其进行了更改： 消息目的地引用WebLogic Server 9.0满足了EJB 2.1的需求，逻辑消息目的地可以在部署描述文件中声明，并可以把它们映射到实际的消息目的地，比如JMS队列。EJB可以通过使用逻辑消息目的地名称执行JNDI查询来查询消息目的地。 无状态会话bean作为Web服务公开WebLogic Server 9.0符合与声明和访问外部Web服务并把无状态会话EJB作为Web服务公开有关的EJB 2.1需求。这些特性使得容易开发和维护访问Web服务的EJB。Java和非Java客户端可以把无状态会话bean作为Web服务访问。 消息驱动bean增强功能
改进的EJB缓存和池化管理员可以对EJB如何进行缓存及汇集施加更多的控制。有关下面所有特性的更多信息，请参见WebLogic Server EJB程序设计. 匹配需求的动态实体缓存和EJB池管理员可以配置实体缓存以在需求增加时释放未使用的内存，及在需求减少时释放汇集入池的内存。 按需进行EJB缓存和池初始化和再初始化在匹配需求的动态实体缓存和EJB池中描述的这一特性和可配置选项，让客户能够提前享受缓存和池提供的响应时间好处，而不用随负载的增加而继续消耗内存。 在事务期间钝化TEJB容器可以在抛出 应用程序开发人员可以用 查询缓存只读实体EJB可以在查询级进行缓存，或者可以在缓存中通过任何查询程序进行访问。这种功能通过避免数据库访问来提高了性能。 查询缓存是通过EJB容器隐式完成的；不需要任何应用程序代码。该行为可以针对bean级或应用程序级缓存，使用 用于乐观bean的并发选项使用乐观并发的容器管理持久性（CMP）实体EJB具有一些新的配置选项：
自动重试回滚的事务在事务期望不定期或定期回滚的环境中，自动重试容器管理的事务可以提高运行时性能。对于使用的容器管理事务划分的会话和实体bean，自动事务重试是受到支持的。 SQL查询支持 除了EJB-QL查询外，EJB开发人员现在可以在 当查询逻辑不能在EJB-QL中表示，或者如果数据库供应商特定的查询不被EJB-QL支持，编码SQL查询是有用的。开发人员可以把EJB-QL和SQL结合起来使用，利用大多数查询的EJB-QL可移植能力的优点，及把SQL用于不能用EJB完成的那些查询。 截除字符串类型值EJB容器截除了主键和其他容器管理持久性字段中字符串类型值结束的尾随空白。以这种方式截除字符串类型值避免了在其他情况下可能产生的比较错误和可移植能力问题。 改进的CMP实体的操作排序当进行批操作和排序数据库操作时，EJB容器在容器管理持久性（CMP）实体之间检测对称和循环关系。 在以前版本的WebLogic Server中，在对称或循环关系中实体上的批数据库操作可能导致外键约束或非空异常。
Web应用程序、JSP和Servlet下面几节描述了Web应用程序、JSP和Servlet中的新特性： Web应用程序
Servlet 2.4实现WebLogic Server现在支持来自Sun Microsysms的Servlet 2.4规范，该规范可以从以下网址下载： http://java.sun.com/products/servlet/download.html#specs。下面对WebLogic Server 9.0的更改支持新的规范。
JSP 2.0实现WebLogic Server现在支持来自Sun Microsystems的JSP 2.0规范。下面对WebLogic Server 9.0的更改支持新的规范。
不鼓励使用和过时的Web应用程序特性
应用程序开发下面几节描述了在WebLogic Server的应用程序开发中的新特性和功能。 J更加易于共享J2EE模块的J2EE库支持在WebLogic Server 9.0中的J2EE库支持使得更加易于在多个应用程序之间共享J2EE模块。J2EE库是一个J2EE模块或打包在企业应用程序（EAR）中的模块的集合，该应用程序首先进行部署，然后在J2EE应用程序容器中进行注册。在向容器注册库后，您可以部署引用库的企业应用程序。引用J2EE库的每个已部署企业应用程序可以使用库模块，就像它们被打包在特定的EAR中。 例如，您可以部署和注册单独的Web应用程序模块作为J2EE库，该库在域的多个企业应用程序中使用。如果Web应用程序需要更新，您就可以在一个地方修改代码，并重新部署J2EE库。然后如有必要，可以重新部署引用应用程序，以使用Web应用程序的最新版本。 有关在J2EE应用程序中创建和引用库的信息，请参见为WebLogic Server开发应用程序中的创建应用程序库和可选包。有关注册库和部署引用应用程序的信息，请参见部署应用程序到WebLogic Server中的部署应用程序。 共享JAR文件的可选包支持如J2EE 1.4规范，第8.2节“可选包支持“中所描述，WebLogic Server使用可选包版本控制中描述的版本控制支持可选包。可选包允许您与作为独立模块或作为企业应用程序一部分部署的多个J2EE模块共享JAR文件的内容。例如，多个Web应用程序需要的第三方Web应用程序框架类可以在一个JAR文件中进行打包和部署，并在域中的多个应用程序之间共享。 通常，在您需要在不同的企业应用程序之间共享一个或多个J2EE模块时使用J2EE库支持，当您需要在不同J2EE模块之间共享一个或多个JAR文件时使用可选包。参见为WebLogic Server开发应用程序中的创建应用程序库和可选包及把应用程序部署到WebLogic Server中的部署应用程序。 部署计划的分裂开发目录支持WebLogic分裂开发目录环境和相关的Ant任务现在支持部署计划和新的应用程序安装根，如“部署应用程序”一节所描述。 Medical Records示例应用程序中的新特性Avitek Medical Records示例应用程序现在通过WebLogic诊断服务、JDBC RowSets、Struts SSL、DBA身份验证、使用JMS的安全域扩展和XMLBeans，实现了EJB实体关系缓存、Log4j集成、自定义诊断日志记录和日志访问。 有关这些特性如何实现的更多信息，请参见WebLogic Server代码示例文档中Avitek
Medical Records示例应用程序的“新特性”主题。该文档是作为一组HTML文件提供的，这些文件安装在WebLogic
Server安装目录中： 不鼓励使用的启动和关闭类在WebLogic Server 9.0中，WebLogic Server启动和关闭类不鼓励使用了，以利于响应应用程序生命周期事件的应用程序。参见在WebLogic Server中开发应用程序中的应用程序生命周期事件程序设计。
应用程序部署下面几节描述了WebLogic Server的新的应用程序部署功能：
WebLogic部署API实现和扩展了JSR-88在J2EE 1.4中，JSR-88规范定义了标准API应用程序配置及部署到目标应用服务器环境。WebLogic Server 9.0实现了JSR-88 Service Provider Interface (SPI) 插件及建模插件，以符合J2EE 1.4部署规范。您可以把基本的JSR-88部署工具与WebLogic Server插件（不带扩展）一起使用，以配置、部署和重新部署J2EE应用程序和模块到WebLogic Server。 WebLogic Server的新的部署API实现和扩展了JSR-88，以支持下面几节描述的高级部署能力。所有的WebLogic
Server部署工具，包括Administration Console（管理控制台）、 有关JSR-88部署规范的更多信息，参见J2EE v1.4文档 关JSR-88部署扩展的信息，请参见部署 WebLogic Server应用程序中的Deploying WebLogic Server Applications和WebLogic Server 9.0 API参考。 有关为部署配置应用程序的信息，请参见“部署WebLogic Server应用程序”中的“为部署配置应用程序”。 可部署到多个域的应用程序配置 基本的JSR-88配置流程不支持把应用程序配置从一个环境迁移到组织中的另一个环境。WebLogic
Server用命令行工具 在把应用程序部署到另一个环境前，您选择您知道将需要更改的WebLogic Server部署描述文件属性，比如全局资源名称和调优参数。导出过程在部署计划中创建了变量定义，以充当选定描述文件属性的占位符。通过Administration Console（管理控制台），部署人员可以容易地把这些值赋给不同服务器域的那些描述文件属性，而不用修改应用程序本身当中的实际部署描述符文件。 参见为WebLogic Server开发应用程序中的导出部署配置和为WebLogic Server开发应用程序中的weblogic.Configure命令行参考。 用于更加简单的产品部署的新目录结构新的应用程序目录结构把生成的配置文件同核心应用程序文件分开，以便配置文件可以容易地进行更改或替换，而不用干扰到应用程序本身。图1-1展示了用于存储可部署应用程序或模块的目录层次结构。 您可以通过只指定安装根来容易地部署应用程序。另外，Administration Console（管理控制台）自动为在目标服务器上分段的部署创建上面的目录结构，以便部署配置文件在某个已知的位置可用。BEA为所有的产品部署推荐该目录结构。 产品重新部署和维护可用性您可以重新部署较老版本应用程序旁边的产品应用程序的修订版本，而不影响现有的应用程序客户端，不干扰新客户端请求的应用程序的可用性。WebLogic Server自动管理客户端连接，以便现有的客户端继续使用较老的应用程序，同时新的客户端请求被发向较新的应用程序。较老版本是在所有当前客户端完成它们的工作后取消部署的；管理员显式取消较老版本的部署，或达到配置的超时。（例如）如果问题在较新的应用程序版本中检测到，那么回滚能力允许您终止重部署过程。 产品重新部署可以与管理模式一起使用（参见在产品中没有干扰到客户端的sanity检查），以便出于测试的目的在产品环境中隔离新应用程序。 参见把应用程序部署到Weblogic Server中的在产品环境中重新部署应用程序。 支持产品重新部署的版本指定 要支持产品重新部署策略，WebLogic Server现在在Enterprise
Application 如果应用程序支持产品重新部署，并且它的部署配置是用对资源绑定的更改进行更新的，那么产品重新部署就会自动执行。即使在应用程序的清单文件中没有指定版本字符串，这也发生。参见部署应用程序到Weblogic Server中的在产品环境中重新部署应用程序 在产品中没有干扰到客户端的sanity检查使用管理模式，您现在可以把应用程序部署到产品环境中（或者重新部署应用程序的新版本，如产品重新部署和维护可用性中所描述），同时把应用程序从外部客户端连接隔离开来。管理模式把对应用程序的访问限制到配置的管理通道。 您可以在产品环境中直接执行应用程序的final（“sanity”）检查，而不干扰客户端。 参见部署应用程序到WebLogic Server中的把产品重新部署与管理模式一起使用。 JMS和JDBC可重部署资源配置 WebLogic Server 9.0中的JMS和JDBC配置现在存储在XML文档中，这些文档符合资源的适当WebLogic
Server模式： JMS或JDBC应用程序模块可以作为独立的资源进行部署，在这种情形中，资源对于在部署过程中针对的服务器或集群可用，它也可以作为企业应用程序的一部分进行部署。作为Enterprise Application一部分部署的应用程序模块只对于封闭的应用程序（应用程序作用域资源）可用。使用应用程序作用域资源确保了应用程序始终可以访问所需的资源，并简化了把应用程序部署到新的环境的过程。 与系统模块比较，应用程序模块是由创建的打包模块的开发人员，而不是部署模块的管理员所拥有。这表明管理员对JDBC和JMS应用程序模块有更多有限的控制。当部署应用程序模块时，管理员可以更改在模块中指定的资源属性，但不能添加或删除资源。系统模块是由管理员通过WebLogic Administration Console（管理控制台）创建的，并可以根据需要由管理员进行更改或删除。 WebLogic Server 9.0中的部署目标WebLogic Server 9.0引入了新的JMS Server部署目标，当把应用程序模块部署到域时，您可以选择该目标。下面的表描述了所有有效的部署目标，并列出了您可以部署到它们的模块的类型。 新的部署配置工具
增强的部署配置编辑扩展了JSR-88在WebLogic Server 9.0以前，在Administration Console（管理控制台）中，您可以动态编辑为应用程序选定的部署描述文件，这些应用程序是使用展开的存档目录进行部署的。对部署配置的更改被直接保存在应用程序的WebLogic Server部署描述文件中。 WebLogic Server 9.0中的Administration Console（管理控制台）让您能够为任何部署的应用程序或模块编辑WebLogic Server部署配置，而不管应用程序是使用存档文件或展开的存档目录进行部署。对部署配置的更改现在被保存到WebLogic Server部署计划中，而不触及原始的部署描述文件。使用部署计划保持了原始的部署文件，并利用了对J2EE 1.4中引入的JSR-88部署规范的WebLogic Server扩展。 参见把应用程序部署到WebLogic Server中的为部署配置应用程序。 不鼓励使用和不被支持的部署特性WebLogic Server 6.x单阶段部署协议在版本7.x和8.x中不鼓励使用了，在WebLogic Server 9.0中不再被支持了。所有的部署现在使用两阶段部署协议。
把备用的部署描述文件用于部署应用程序模块在这版本中不鼓励使用了。使用JSR-88样式部署配置和部署计划，而不是备用的部署描述文件来维护打包应用程序外部的自定义配置。 在部署中使用 |
