频道栏目
读书频道 > 数据库 > Oracle > Oracle Fusion Middleware 11g架构与管理
2.2.1 应用程序容器
2012-12-13 10:05:18     我来说两句
收藏   我要投稿
本书定位于初级和中级读者。从Fusion Middleware产品知识的角度来看,内容是初级的;但从一般基于Java的企业软件开发知识的角度来看,内容则是中级的。例如,本书假设读者知道Java Enterprise Edition概念,但...  立即去当当网订购

如图2-1所示,在最高层次,WebLogic Server的应用程序容器可分为如下类别:

● Web容器

● Enterprise Java Beans(EJB)容器

● Web Services容器

● Java Connector Architecture(JCA)容器

应用程序开发人员依据与这些容器相关的规范来构建自己的应用程序,当将这些应用程序部署到WebLogic Server时,将在其关联的运行时服务里执行它们。本节将介绍前3个应用程序容器,讨论它们支持的接口、部署组件生命周期和事务管理功能。本节还将讨论各容器的关键部署时配置形参,在构建和管理其依赖应用程序时需要考虑它们。关于WebLogic Server的JCA容器的讨论超出了本书的范围,虽然允许将它部署到WebLogic Server的Java EE应用程序与外部系统通信(通常基于非标准)。而Oracle Fusion Middleware Service-Oriented Architecture(SOA)Suite与JCA适配器打包在一起,并可以开箱即用,第5章将详细讨论它们。

1. Web容器

HTTP servlet和Java Server Pages(JSP)是主要的Java EE规范,用于开发在Web应用程序容器里调整运行的应用程序。对于Web应用程序开发人员来说,JSP可以使他们更方便地关注Model-View-Controller(MVC)基于Web的应用程序的视图元素,再将它们编译到servlet(伺服小程序)用于运行时执行。框架和规范还有一个变体可以简化MVC基于Web应用程序的开发(例如Oracle应用程序开发框架,第6章将详细讨论),但最终从运行时执行的角度来看,这些框架的最终构造都是一组HTTP servlet,它们处理基于HTTP的请求和响应。

Servlet本身是无状态的,Web应用程序管理客户端状态的方法是通过HTTP会话对象,给它分配一个初始ID,并通过HTTP缓存保存在客户端,其默认名称是JSESSIONID。对于所有余下的请求,客户端—— 在大多数情况下是Web浏览器—— 传递请求里的ID,servlet代码再用它来查找关联的会话状态。HTTP会话状态由Web容器管理,其行为由许多参数在域和部署描述符层控制。WebLogic Server也具有群集会话复制性能,以提高部署到它的Web应用程序的可用性和可靠性。但讨论WebLogic Server会话复制功能超出了本书的范围。通过weblogic.xml部署描述符来控制Web容器的HTTP会话管理配置的主要类别。最常修改的部署描述符属性是那些设置客户会话合法时长的属性和控制会话持续功能的属性。

Servlet的默认生命周期由创建servlet的单个实例的WebLogic Server组成,该servlet用于并行处理所有传入的请求。虽然这种情况不常见,但是也可能开发一个Web应用程序,这样每个传入的请求都将实例化新的servlet对象。在这种情况下,WebLogic Server在启动时将启动一批servlet实例,用来传入为请求服务,如果池内的实例全部用完,则开始启动新的servlet。weblogic.xml <single-threaded-servlet-pool-size>元素的值用来控制servlet池的初始大小。最后还需要注意的是,servlet不知道事务,因为没有为它们提供容器事务处理功能。

2. Enterprise Java Bean容器

Enterprise Java Bean(EJB)是主要的Java EE规范,用于在Java EE应用程序服务器上下文中创建安全可扩展的事务业务逻辑。WebLogic Server同时提供EJB 2.1和EJB 3容器功能。提供EJB 2.1容器功能主要出于兼容性考虑,本书不再进一步讨论。作为EJB 2.1的替代品,WebLogic Server的EJB 3容器功能主要包括以下方面。

● 作为Pitchfork项目的一部分,与SpringSource联合开发的EJB 3 Stateless/Stateful Session Beans和Message Driven Beans容器。

● 通过两种不同的Java Persistence API(JPA)实现方式,支持Java对象关系映射:Kodo和TopLink。在WebLogic Server中Kodo是默认的JPA提供者;而TopLink是Oracle的战略JPA实现方式,是WebLogic Server默认JPA提供者的替代方式。本节只讨论标准的JPA配置方面(实现方式不讨论)。

下面将详细讨论WebLogic Server EJB容器的各种功能。

Stateless、Stateful和Message Driven Beans   Stateless Session Beans(SLSB)和Stateful Session Beans (SFSB)提供一个接口,能够用来配置本地调用和远程调用。本地调用只能由模块在EJB的相同部署存档(本章稍后将详细讨论部署存档文件和结构)中实现,因此不需要考虑任何系统级或部署时配置。但如果这种EJB提供客户在存档文件之外使用的接口—— 不管该客户本身是部署到相同服务器/群集还是完全在域之外—— 就要考虑远程调用以及下面两个部署时。

● 使用WebLogic的私有T3协议或者通过标准的IIOP协议,可以实现EJB接口的远程调用。WebLogic Server的默认协议是T3,WebLogic Server默认配置为处理T3请求。然而,如果是IIOP客户,就需要将部署EJB的服务器配置为管理传入的IIOP请求,如表2-3中“IIOP访问”这一行所示。一般情况下T3协议效率更高,但如果需要与在其他环境(不同于WebLogic Server)中运行的客户进行互操作,IIOP协议则可能是更好的选择。

● 远程客户通过查找服务器的JNDI树来访问EJB。EJB的服务与其客户的集成要求EJB客户使用的JNDI查找名称和EJB提供的JNDI名称同步。因此重要的是知道如何配置这些参数,如表2-3中“JNDI映射”和“JNDI引用”这两行所示。

SLSB的实例化由WebLogic Server汇集(pooling),以便节省为每个实例实例化新对象的性能开销。WebLogic部署描述符提供一组参数,用于配置SLSB汇集行为。而SFSB则无法汇集,因为每个客户都与保存客户状态的SLSB的特定实例相关联,因此每个对SFSB的新请求都将创建新的SFSB实例和相关客户会话。WebLogic Server提供SFSB缓存功能,允许SFSB实例在内存中保存一段时间,之后将bean的状态钝化到内存之外的桌面上。这些WebLogic服务器会话bean汇集和缓存参数如表2-3中“SLSB汇集”和“SFSB缓存”这两行所示。

Message Driven Beans(MDB)是一种Java EE机制,它通过在JMS目标上实现异步消息来实例化容器托管的业务逻辑。因此MDB无法提供任何远程接口。MDB与其依赖的JMS目标的映射通过JNDI实现,表2-3中“JNDI引用”这一行所列的配置考虑因素同样适用。MDB的汇集方式与SLSB相同。

最后,本节介绍的EJB的这3种类型都可以参与WebLogic Server容器托管的事务。事务划分点是,对于SLSB和SFSB,它们是bean的接口方法;对于MDB,则是接收来自其目标的消息。因为MDB在现有事务上下文中不提供客户能够调用的操作,因此它们的事务模型仅限于为每个接收到的消息(或者通过WebLogic Server MDB事务批处理机制配置的一组消息)实例化新事务。RJB的事务配置功能如表2-3“事务管理”这一行所示。
表2-3  EJB容器主要配置参数

配 置 类 别 描    述
IIOP访问 要允许远程客户IIOP访问,服务器的Listen Address属性必须设置为有效IP地址或者DNS属性,不能设置为默认的空值,它表示服务器监听“所有配置的网络接口”。该限制不适用于使用T3协议访问服务器的远程客户
JNDI映射 EJB可以通过注释(在EJB类代码内)或weblogic-ejb-jar.xml <business-interface- jndi-name>元素映射服务器JNDI树。 注释方法不能为不同环境修改JNDI名称,而部署描述符方法通过使用部署计划能够提供这种灵活性,该功能本章稍后将详细讨论
 (续表)   
配 置 类 别 描    述
JNDI引用 远程EJB客户应该使用ejb-jar.xml部署描述符里的<ejb-ref>元素和weblogic- ejb-jar.xml部署描述符里对应的<ejb-reference-description>元素在服务器的JNDI树里查找引用。对于客户和EJB不在相同域的情况,则需要配置外部JNDI提供者。外部JNDI提供者允许WebLogic Server实例的JNDI树包含对位于本地域之外的JNDI服务器的引用。对外部JNDI提供者的详细讨论超出了本书的范围。请参考Fusion Middleware文档库内的“Programming JNDI for Oracle WebLogic Server”文档,详细了解对该主题的讨论
SFSB缓存 weblogic-ejb-jar.xml <cache-type>、<idle-timeout-seconds>和<max-beans-in-cache>控制容器的SFSB缓存管理设置
SLSB汇集 weblogic-ejb-jar.xml <initial-beans-in-free-pool>控制容器的SLSB池管理设置
事务管理 weblogic-ejb-jar.xml<trans-attribute>控制容器的EJB事务管理设置
 Java Persistence API容器    Java Persistence API(JPA)规范可用作Java对象关系(OR)映射框架基于标准模型的基础。在JPA之前,EJB 2.1通过EJB 2.1实体beans包含自己的OR映射功能。虽然由EJB 3工作组设计的JPA在某种程度上被作为EJB 2.1实体beans的替代品,但该规范是独立的,其实现方式也可由独立的Java SE应用程序使用。JPA其实由两类API组成。第一类是一组Java注释,由开发人员将某个Plain Old Java Objects(POJOs)—— 称为JPA实体—— 的字段映射到对应的数据库表。第二类是一组控制API,它们通过应用程序代码控制JPA实体的管理,例如实例的创建和修改。

WebLogic Server使用的默认JPA实现方式称为Kodo,该产品与另一种称为TopLink的实现方式打包在一起。Oracle已经将TopLink确定为WebLogic Server的战略JPA实现方式。如果应用程序只使用标准的JPA API,那么JPA提供者从Kodo到TopLink的转换只是将元素
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
添加到应用程序的persistence.xml标准部署描述符文件。否则就需要在将提供者转换到TopLink之前移植应用程序的Kodo独有API用法。这两种实现方式提供一些实现方式特有的配置参数,如Fusion Middleware文档库中“Programming Enterprise JavaBean”文档所述。

从部署时配置的角度来看,唯一标准的JPA参数是数据源配置,通过JPA应用程序的persistence.xml部署描述符来提供。在JPA应用程序使用容器托管事务的情况下—— 对于Java EE JPA应用程序来说就是这种情况—— 则需要由该文件为应用程序使用的每个持续单元引用两个JDBC数据源。这些数据源通过<jta-data source>和<non-jta-data source>元素来标识,并且必须包含合法WebLogic Server数据源的JNDI名称。

<jta-data source>元素必须指向配置的数据源,以便能够参与全局事务(本章后面将详细讨论WebLogic JDBC数据源的架构和事务配置),并被用作传递所有应用程序查询的数据源。<non-jta-data source>元素必须指向数据源,该数据源不允许其他资源参与事务(通过非XA数据源实现,该数据源禁用Supports Global-Transactions设置,或者如果启用该设置,则将值设置为One-Phase Commit),并被JPA实现方式用来通过应用程序的实体管理查询独立访问数据库

除了本节讨论的少数几个参数之外,JPA应用程序复杂性主要在于其开发或者提供者特有的设置。

3. Web服务容器

由于通过Web Services Definition Language(WSDL)接口定义的标准化,以及大批WS-*规范提供通用机制来实现分布式集成功能,Web服务已经成为研究远程调用业务逻辑的优先选择。Web服务最常用的传输协议是HTTP,但WebLogic Server容器也允许通过JMS/IIOP传输协议提供Web服务。Web服务的消息格式通常由Simple Object Access Protocol(简单对象访问协议,SOAP)定义,但通过提供REST样式的Web服务也可以使用纯XML格式的消息。

Web服务以实现为POJO(通过名为Java Web Services [JWS]文件的Java类)或SLSB EJB。Web服务对象(基于接收新的HTTP请求)的生命同期取决于其实现类型。如果Web服务实现为SLSB EJB,则EJB容器的SLSB生命周期管理和实例汇集功能则适用,如本小节“2.Enterprise Java Bean容器”所述。如果Web服务实现为POJO,则Web服务容器将创建Web Services JWS类的新实例,并调用请求的操作。将Web服务实现为EJB的好处是,在这种情况下所有容器的SLSB管理功能(事务管理、汇集、容器托管安全)都有效。

WebLogic Server Web服务容器能够执行JAX-RPC和基于JAX-WS的Web服务,推荐后者作为开发新Web服务的首选,因为它是JAX-RPC的替代品。WebLogic的Web服务容器提供的功能随着Web服务类型的变化而变化。表2-4简要描述了WebLogic Server Web服务容器支持的各种Web服务类型的功能。
表2-4  JAX-RPC与JAX-WS Web服务的功能

功    能 JAX-RPC Web服务 JAX-WS Web服务
安全性 支持基于WS-Security的消息级安全,用于加密SOAP消息内容以及传播用户名令牌和基于SAML的身份识别。在WebLogic Server Web服务端点上启用WS-Security需要应用程序级编码,但使用Fusion Middleware Oracle Web Services Manager(OWSM)的WS-Security可以保护基于JAX-WS的Web服务。第3章将详细讨论OWSM
异步Web服务调用 通过一组WLS特性实现,以支持SOAP/JTTP的Web服务会话缓冲和可靠消息发送。通过将Web服务作为SOAP/JMS服务实现,也可以提供异步调用。需要编码 不支持
事务管理 基于EJB的Web服务支持启动新JTA事务;但不支持事务传播—— 即能够确保将客户事务上下文传递到服务器 通过WS-Atomic Transaction规范,与容器托管事务和传入请求的事务传播完全集成。交互行为不需要开发时编码,通过weblogic-webservices.xml的<wsat-config>元素可以控制交互行为

(续表)   

 

功    能 JAX-RPC Web服务 JAX-WS Web服务
Stateful Web Services 通过专门的WebLogic Server Web服务会话协议实现。需要编码 通过JAX-WS标准会话传播功能实现,它允许使用HTTP会话管理会话。需要编码
RESTFul Web Services 不支持 通过JAX-WS HTTPBinding.HTTP_电路BINDING绑定类型实现。需要编码

如表2-4所示,WebLogic Server Web容器的许多行为都通过Web服务代码里的逻辑进行控制,并且在部署时不可配置;但可配置的元素在表中进行了专门介绍。

关于支持这些功能以及与它们相关的WebLogic Server Web服务容器配置的更多信息,可参考Fusion Middleware文档库里的JAX-WS and JAX-RPC Advanced Features Guides。

您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:2.2 应用程序容器和部署
下一篇:2.2.2 应用程序部署
相关文章
图文推荐
排行
热门
最新书评
特别推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站