J2EE交易框架

核心提示：J2EE交易框架：构建框架by Dibyendu Baksi04/26/2001 绪论廉价的计算能力和不断增加的网络带宽促进了以组件为基础的分布式计算程序的发展，以组件为基础的分布式程序是一个服务架构，J2EE交易框架，它由物理上独立的计算机上的不同的应用组件构成，对用户来说，这个结构是一个值得推荐的完整的架构，这种应

J2EE交易框架：构建框架by Dibyendu Baksi
04/26/2001
绪论
　　　　廉价的计算能力和不断增加的网络带宽促进了以组件为基础的分布式计算程序的发展。以组件为基础的分布式程序是一个服务架构。它由物理上独立的计算机上的不同的应用组件构成。对用户来说，它们就像是运行在一台机器上的单一应用程序。有几个因素促进了分布式系统的应用，而不是传统的集中式系统。
·　　　　分布式应用：一些任务本身就是分布的。这个特性决定需要多个agent合作工作。在这种情况下，定位和获取有效的和最需要的计算能力及数据具有优先权。
·　　　　可靠性：因为系统的共享、合作和分布的特性，系统中不存在一个单个的失败点。使用新的容错、恢复和分布同步技术，更好的可靠性可以得到满足。
·　　　　可扩展性：对应用的需求日益繁多，正确的设计系统，就可以通过增加新的服务和硬件来处理更多的负载。
·　　　　性能：由于处理涉及到更多的应用范围，这些难题从本质上讲越来越复杂。为了解决日益复杂的问题，我们需要更快的计算机，这些计算机在可以接受的价格下具有更高的计算能力。
·　　　　经济性：获取相同等级的计算能力，使用分布在多台机器的系统其费用可以更低一些
　　　　对于用户来说，通过网络互连的异构计算机上的异构应用系统就像是在单台物理机器上的标准的应用系统。要达到这样的透明度，分布是系统需要在如下方面做到透明。
·　　　　数据定位：对于系统用户来说，他们不需要知道数据位于网络中的哪一个地方
·　　　　失败：对系统用户来说，他们不需要关注数据的一致性
·　　　　复制：系统用户不需要知道数据是如何被复制的
·　　　　分布：系统用户不需要知道计算能力和数据如何通过系统被分布的
　　　　分布式系统允许用户透明的保存、存取和操作来至多个计算机的数据，能在系统发生故障的时候维持数据的完整性。对分布式数据和交易的管理分成本地和全局两个级别。本地数据管理者或资源管理者能够访问和操作本地数据和资源。资源管理者提供了数据的透明定位，数据模型和数据库的安全与授权控制。本地的交易管理器负责处理计算系统交易的初始化、监控和终止。分布式交易系统将网络中相关的交易视为单一交易从而扩展了本地交易系统的范围。
交易是一组语句的集合表示一个工作单元，他们必须作为一个单元被执行。交易是位于资源上的操作的一个序列比如读、写或是更新。这些操作序列将系统由一个稳定态转化为新的稳定态。为了真实的反映系统中的实体，一个交易应该具有下面的特性：
·　　　　原子性：这个特性指全部都做或是全部都不做。操作序列或者是成功或者是失败。一个交易应该被认为是一个单一的操作单元。完成的交易应该被提交，没有完成的交易应该被回滚或是恢复为它的开始状态。绝不可能只有部分工作被提交。
·　　　　一致性：一个交易反映了资源之间的一种连续性。一致性关心的是正确反映资源状态的事实。一致性的例子有数据库的完成性、表格中主键的唯一性等。
·　　　　独立性：一个交易在它提交前不应该将自己的结果暴露给其它并发的交易。独立性确保不会去访问正被更新的数据。独立性的另一个名字是序列化。
·　　　　持久性：一个完成的交易的结果应该被保存下来，不能因为系统错误而从数据库中清除掉。资源管理者应该确保系统失败的时候交易的结果不会被改变。

交易处理的基本原理
为了反映实体的真实状态，每一个交易都应该具有上述四种特性。集中式计算环境的应用组件和资源被定位到一台单个的机器上，交易管理仅仅包括一个运行在单一机器上的本地的数据管理者。与此不同，分布式计算环境中所有的资源被分布在多个系统中。在这种情况下，交易管理包括两个级别本地和全局。一个本地交易包括单个本地资源管理中的活动。一个分布式或是全局的交易在多个系统中被执行。它执行需要全局交易管理系统和所以涉及到的系统的本地数据管理者协同工作。资源管理者和交易管理者，也是作为交易处理监控者是一个交易系统的两个主要的元素。在一个集中式系统中，交易处理监视器和资源管理者被集成到DBMS服务总。为了支持以组件为基础的分布式系统更高级的特性，将TP监视器从资源管理者中分离出来是必要的。

交易管理分类
交易性企业系统的最通常的结构如下：
·　　　　小模式TP：这种结构不需要任何独立的交易管理中间件。每一个SQL语句都被认为是一个单独的交易
·　　　　这种方式使用数据库的存储过程来处理更新。由于多数的RDBMS提供商提供一些集成的TP工具，每一个交易都被定义为一个存储过程。这种方式带有一个复制服务器。主服务器数据通过存储过程来更新，第二份数据通过使用复制服务器来被复制。
·　　　　大模式TP：这种方式被用于企业级别的交易系统。它需要对原有系统提供一个接口。它使用一个分布式的交易管理器来处理交易更新。它分为两个子类，一种，使用一个独立的交易管理器，例如CICS，Encina，Tuxedo或是TopEnd.第二种，TP监视器被放入到应用服务器中像Websphere或iplanet应用服务器或是微软的交易服务器。

有两种方式用来说明交易。
·　　　　计划式：在计划式交易规范中，一组或是一个操作序列被定义成一个交易。最通常的方式是标记那些执行交易处理操作的线程。交易可以通过取消标记被挂起。通过明确的复制交易上下文（丛挂起点到重新启动点）稍后重新启动交易。提交请求指挥所有参与的资源管理器永久记录交易操作产生的影响。回滚请求让资源管理器撤销交易操作的影响。
·　　　　宣称式：以组件为基础的交易处理系统，像基于EJB的应用服务器和微软的交易服务器的COM，支持declarative交易规范。这种方式，在配置的时候，组件被标记为一个交易。这有两方面的含义。首先，交易的职责从应用程序转移到组件的宿主容器。第二，交易的有效时间从应用程序的构建延后到了组建配置的时候。

交易繁殖(PRopagation)
　　　　一个全局或是分布式交易由一些子交易组成，它被作为一个单一的可重获取的原子单元。全局交易管理器的责任是通过调整不同的资源管理器来访问在不同系统中的数据从而管理分布式交易。由于在一个交易中有多个应用组件和资源参与，所以交易管理器应该在交易发生的时候建立和记录下交易的状态。这个功能可以通过使用交易上下文来取得。交易上下文是资源上的交易操作和调用这些操作的组件间的一个纽带。在交易发生过程中，所有参与交易的线程共享相同的交易上下文。在一个交易过程中，交易上下文的范围逻辑上包裹了所有执行在交易资源上的操作。交易管理器需要分析交易请求并将交易分解成多个子交易，复制交易上下文，并将他们发送给相关联的资源管理者。在资源管理者的控制下，交易上下文通常来说是透明存在的。

资源管理器依靠称之为资源服役这一过程来通知交易管理器自己加入了交易。交易管理器保持了交易中加入的所有的资源的轨迹，通过两段式提交和恢复协议调整资源管理者的交易工作表现。在交易的最后，无论是提交还是回滚，所有被使用的资源都要被删除掉。交易管理者必须要监控交易的执行决定提交还是回滚交易的变化以确保交易的原子性。

两段式提交
交易管理者和所有交易有关的资源中的两段式提交协议确保了资源管理者或是提交或是放弃交易。如下图所示，当应用程序发送交易提交请求的时候，交易管理者发送PREPARE_TO_COMMIT请求给所有被调用的资源管理者。所有的资源管理者顺次发送一个应答表明自己是否做好提交的准备。仅仅当所有的资源管理者都准备好提交，交易管理者发送一个提交请求COMMIT给所有的资源管理者。或者，交易管理者发送一个回滚请求(ABORT)给资源管理者，交易被回滚。
　　　　虽然2PC保证了交易的自治，但必需的处理负载太重，经常产生更新冲突，特别是存在重复数据的时候。数据复制是减少冲突的一个方式，仅仅在基于交易的更新繁殖不是必需的时候有用。多数分布式系统平行的采用这两种方式相应匹配应用程序的需求。

　　　　在两段式提交(2PC)和复制服务器方法间是品衡的。两者基本不同之处在于交易级上的一个操作和另一个操作是周期性的更新。指导方针是1）尽可能小的保持数据复制2）如果数据作为一个交易需要同步，拷贝数量少并使用2PC，3）4）如果网络和节点不可靠，使用复制服务器。
同步控制是另一个至关重要的功能。它允许多个用户同时访问数据，增加了系统的吞吐量和执行。在取得同一个逻辑结果的时候，系统允许交易同步进行好像他们是连续地执行的。合作控制同意多个交易同时读和更新数据，它包括交易调度和交易执行期所需资源的管理。大多数交易的串行化都是依靠锁机制，比如两段式锁方法，时间磋方法。两段式锁算法是最通常的应用在分布式交易系统中的技术可以取得同步更新和合作控制。通常，供应商结合合作控制技术比如2PL，一致性控制技术如2PC，超时控制为了解决死锁，结合成一个单一的实现为全局分布式交易管理。

队列式交易处理
　　　　直接交易过程是同步的，起初交易创建者被阻塞直到交易管理器开始运行为止。不幸的是，交易的客户端或是服务端通信有时候会失败。有时候，有些交易的请求等级有很高，需要优先处理。这种同步交易处理模式无法很好的处理这些情况。这导致了使用队列的异步交易处理模式的发展。队列是一种交易资源，队列上的操作包括入队和出队。在J2EE平台定义了两种机制处理队列。一种是使用原生JMS API，另一种是利用消息Bean，它被定义在EJB2.0中。
交易中的JMS API
应用组件的开发者不应该在单一交易里使用JMS请求-应答范例。直到交易被提交，一个JMS消息不会被投递给它的最终目标，在同一个交易里应答的接受决不会发生。因为一个容器管理着一个代表bean的JMS会话的交易。createQueuesession(boolen transacted, int acknowledgeMode)和createTopsession（booleantransacted, int acknowledgeMode）方法的参数被忽略。我们建议组件开发者指定一个被处理过的会话提供0作为acknowledgement的值。记住JMS的acknowledge()方法无论是在一个交易里还是在一个没有指明的交易上下文都不该使用，这一点很重要。在一个未确定的交易上下文消息的确认是通过带有JMS AUTO_ACKNOWLEDGE符号的容器来处理的。

message-driven beans
消息驱动beans
　　　　一个消息驱动bean是一个异步消息的消费者，当一个JMS消息到达时由容器来调用。从客户的角度看，消息驱动bean是一个JMS消息的消费者它在服务器端完成了一些业务逻辑。客户经由JMS通过发送消息给JMS目标（队列或是主题）来访问消息驱动bean，因为消息驱动bean类是一个消息监听者。消息驱动bean没有home和remote接口，它是无状态的。它们像无状态的session bean：当他们没有包括在服务一个客户端的消息中，所有的bean实例都是一样的。一个消息驱动bean实例由容器创建作为消费者处理消息过程。容器控制它的生命期。然而，实例消息驱动bean的实例的实例变量可以通过客户端的消息操作维持自己的状态。
　　　　这种情况包括一个开放的数据库连接和一个对EJB对象的引用。消息驱动的bean模式正发展成为一个企业bean，它被异步调用来处理接受的JMS消息。对它的开发工作如同其他的JMS消息监听器一样简单。依靠容器提供的消息驱动bean实例池，它也可以同时处理一串消息。
标准
　　　　分布式TP环境的透明目标要求交易管理者和带有资源管理者的TMs之间应该具有协同工作的能力。目前，有两个开放标准，即X/Open DTP模式和ISO TP模式。对一个开放环境中来至不同提供者的交易管理者可以通过ISO TP协议互相通信。ISO TP并没有太多的追随者。另一个方面，X/Open分布式交易处理模式是由一个开放组织提出的标准。目前多数商业化的交易处理和关系数据库解决方案提供商都遵循这个标准。这个模式主要原理：
·　　　　应用组件实现了交易操作
·　　　　资源管理器来控制资源
·　　　　交易管理者和资源管理者协同处理一个全局交易
下面是这个模式特别被提及的主要方面
·　　　　TX接口：这个接口位于请求和交易管理者之间由交易管理者实现。它通过将应用程序组件和交易操作绑定的方式来提供交易的划分服务。
·　　　　XA接口：这个接口位于资源管理者和交易管理者之间。当交易管理者（或TP监视器）和RDBMS或是EIS的资源管理器都支持XA接口时，他们能够被组织在一起被处理。这是标准中最重要的借口已经被业界所接受
Figure 3. X/Open DTP standard
X/Open DTP模式在工业界已广泛的使用。商业化的交易管理软件像TXSeries/Encina， Tuxedo，TopEnd和AT&T GIS都支持TX接口。大多数的商业化数据库如Oracle，Sybase，Informix和微软的SQL Server和消息中间件产品如IBM的MQSeries和微软的MSMQ Server都实现了XA接口。
Some J2EE configurations

一些j2ee结构
　　　　J2EE是一个基于架构的框架。对交易的支持是J2EE架构的主要方面。组件提供者能够利用java交易API(JTA)在组件代码中提供交易边界。另一方面，随着支持企业beans的交易规范的公布，交易能够由容器自动的开始和完成。J2EE服务器在低层实现了交易管理者和支持JDBC API的数据库系统的通信协议，包括交易上下文的复制机制和可选的分布式两段式提交。J2EE平台目前支持扁平式交易，这种交易中不能嵌套交易。存在这种可能性，一个交易请求使用serverlets和jsp页面在一个交易中访问多种EJB。每一个组件允许获得一个或多个连接以访问一个或多个资源管理器
Figure 4. Recommended J2EE configurations.
需要强调的是虽然对一个特定的应用可能有多个解决方案供选择。不同，在所有可能的配置方案中，我们强烈推荐以下几种
·　　　　Case I: Stand-alone Client <-> EJB Container <-> RDBMS/EIS Resources
这种结构是从两层客户服务器模式中变化而来。一般来说，存在一个利用Swing写成的胖客户端,它直接和EJB中的商业逻辑通信。这个EJB位于应用服务器中的某个EJB容器中。
·　　　　Case II: Browser <-> Web Container <-> RDBMS/EIS Resources
这种配置在一个小规模的web应用程序中很普遍。支持的用户数相对较少，对于一个组织中的内部企业互联网系统来说很适用
·　　　　Case III: Browser <-> Web Container <-> EJB Container <-> RDBMS/EIS Resources
对于一个有大量用户需要良好性能的系统来说，这个结构是一个值得推荐的完整的架构，这种应用具有鲁棒性和可伸缩性。
Dibyendu Baksi 是sun公司的一个J2ee交易系统和框架的设计者和开发者进入讨论组讨论。

（出处：http://www.cncms.com）