分布式系统模式读后记（二）

 

近链接与远链接

 

考虑分布式系统的另外一种方式就是将每个系统视为通过链接连在一起的处理节点的集合。

系统内的链接分成两个部分：

近链接和远连接。

 

近链接：将驻留在同一信任区域中、同一企业内，它们可以以可靠方式连接而且不涉及互操作性。最好使用基于实例的协作。

远链接：包括所有其它连接。最好使用基于服务的协作。

以下都是近链接模式：

 

使用代理（Proxy）：代理是与客户端对象通信的对象本身。当客户端创建远程对象的实例时，基础结构就会创建一个代理对象，该对象在客户端看来与远程类型完全相同。当客户端调用该代理对象上的一个方法时，该代理就会调用远程处理的基础结构。远程处理基础结构将请求路由到服务器进程，然后调用服务器对象，并将结果返回给客户端代理，最后客户端代理将结果传递给客户端对象。由于所有这些操作都是在后台进行的，因此客户端对象可能完全不知道另一个对象驻留在其他计算机上。

 

Broker （代理程序）模式描述如何查找远程对象并调用它的一个方法，而不会将通过网络进行通信的复杂性引入应用程序。此模式为大多数分布式体系结构（包括 .NET Remoting）奠定了基础。

 

本地调用：最简单的远程处理模型涉及到按值将对象的副本传递给客户端。以后针对该对象进行的所有方法调用都是真正的本地调用。

 

服务器激活的对象

您拥有对远程对象的引用时，才能调用其上的方法。获取对远程对象的引用要求首先实例化该对象。客户端要求服务器提供该对象的实例，然后服务器返回对远程实例的引用。在无状态服务中，每个请求都会使对象继续保持此前所处的状态。（note:是否保存状态以及如何保存状态还需要和推理机的设计相关啊！！）

 

 

有状态的会话：（服务器激活的对象为实例生命期管理仅提供两个替换选项：）

针对每次调用创建对象的新实例。

对于所有客户端仅使用远程对象的单个实例（使该对象有效地成为 Singleton)。

（感觉这两个解决方案都不能很好的解决我们的对象的生命周期管理的问题。现在的主要问题是，我们需要什么样的生命周期管理？？？？！！）

 

客户端激活的对象

客户端激活的对象使客户端能够控制远程对象的生存期。客户端几乎可以像实例化本地对象那样实例化远程对象，在客户端删除对该对象实例的所有引用之后，垃圾回收器会删除远程对象。但是，这种级别的控制成本较高。要使用客户端激活功能，必须复制可由客户端进程访问的程序集。这与各种客户端应该无需进一步设置即可访问远程对象的想法存在冲突。

但是，您可以通过创建一个服务器激活的对象（作为服务器对象的工厂对象）来达到最佳平衡。此工厂对象创建其他对象的实例。工厂本身是没有状态的，因此，您可以很方便地将它作为服务器激活的 Singleton 来实现它。随后，所有客户端请求都共享该工厂的同一个实例。因为该工厂对象在远程运行，所以它所实例化的所有对象都是远程对象，但是客户端可以决定在何时以及在何处实例化它们。（这样就能在有状态和无状态服务中取得折中了：））

 

粗粒度接口：

 

跨进程和网络边界调用方法比调用同一操作系统进程中对象上的方法慢得多。如果使用公开细粒度接口的对象，则会大大影响应用程序的性能，（看来我们有必要重新设计推理机的接口了！！多次提供初始数据的接口调用方法需要重新修正了。）这是由于细粒度接口要求跨进程和网络边界进行多次方法调用。为了改善性能，远程对象必须公开一个粒度更大的接口。粗粒度接口公开一组相对较小的独立方法。每种方法通常都代表一段高级功能（如下订单或更新客户）。因为某个方法所需的全部数据都以参数形式传入该方法中，所以这些方法都被视为独立方法。（这样看来，我们许多设定参数的接口需要整合成一个。定出一个XML的接口标准来。）

 

 

DTO（Data Transfer Object）：

The Data Transfer Object 模式将粗粒度接口概念应用于如下问题：在由进程和网络边界隔开的组件之间传递数据。它建议将许多参数替换为一个对象，在该对象中存储远程方法所需的全部数据。该技术对于远程方法返回的数据也非常适用。

三种方案：

1、为解决方案所需的每种不同类型的 DTO 分别定义一个单独的类。针对所包含的每种数据元素，这些类通常有一个强类型的公共字段（或属性）。为了跨网络或进程边界传输这些对象，这些类都要序列化。此方法的主要优点是性能和类型安全。此方法的缺点是需要为每个 DTO 创建一个新类。

 

 

2、是使用一般容器类来保存数据。此方法的常见实现是将类似于 ADO.NET DataSet 的类用作一般容器类。此方法需要两次额外转换。。第一次转换发生在发送端，它将应用程序数据转换为适用于 DataSet 的形式。第二次转换发生在接收端，它将数据从 DataSet 中提取出来以用于客户端应用程序。在某些应用程序中，这些额外的转换可能会影响性能。此方法的另一个不足之处是缺乏类型安全性。如果将客户对象放在发送端的 DataSet 中，则在接收端上尝试提取顺序对象时会导致运行时错误。此方法的主要优点是不必编写、测试或维护任何额外的类。

 

3、类型化 DataSet。ADO.NET 提供一种自动生成包装 DataSet 的类型安全包装器的机制。此方法存在与 DataSet 方法同样的潜在性能问题，但是应用程序可以受益于类型安全这一优点，并且开发人员不必为每个 DTO 都开发、测试和维护一个单独的类。

一份简洁、权威的EJB 2.0介绍(zz地址忘了，汗啊，有知道的麻烦告诉一下，谢谢)

 

引言：

 

本文对EJB 2.0做了极为简洁的介绍。预期的读者为，那些有分布式对象技术背景、但不熟悉EJB的开发者和项目经理。

 

两种技术的联姻：

 

EJB规范阐述了这样两种技术的结合：传统的TP monitors和分布式组件服务。TP monitors是强有力、可靠并富有弹性的平台，这种平台主要用于运行过程式语言，比如用COBOL、PL/1写的应用。平台管理完整的应用环境，其中包括事务、安全、资源管理、负载均衡和容错。常见的TP monitors，比如CICS、TUXEDO和Encina，是许多企业级、关键性(mission-critical)应用的基石。TP monitors采用先进的三层体系机构，并将三层具体划分为，表示层、商业逻辑层和后端资源层。

分布式组件系统给这样的三层体系结构提供了更为优秀的方式。在该类系统中，运行在中间层上的对象、组件可以通过其自身的远程代理（remote proxies）使得其他进程可以访问自己的目的。这些远程代理通过网络将请求发送给分布式组件。

分布式组件服务，比如Java RMI,、CORBA,和DCOM，在业界已经得到了广泛的应用。分布式组件和在传统TP monitors中基于过程的应用相比，提供了更好的重用性和灵活性，因为在开发商务应用中，可以将分布式组件集成成各种各样的组合。但另一方面，这些分布式组件的开发较为困难，因为缺少TP monitors所提供的健壮的基础架构。

组合TP monitors和分布式组件的优点，EJB服务器为分布式组件提供了类似TP monitors的环境。一方面，EJB平台中的TP monitors自动管理完整的应用环境（其中包括，事务、安全、并发控制、持久性、负载均衡和容错机制）的特征减少了开发应用程序的复杂程度。梁一方面，EJB平台中的分布式组件特征使得开发者可以将有富有弹性、可重用的组件集成起来，从而提高开发效率。

在EJB中的分布式组件称之为，企业beans（简称，enterprise beans）。EJB用Java开发，并可以用于建模应用的商业逻辑。一旦一个企业beans开发成功，我们就可以将这个企业beans和其他的企业beans打包到应用程序中，并发布到EJB服务器上。在EJB的发布过程中，配置人员可以通过修改配置描述文件达到修改企业beans的事务性、持久性和安全性。最终的结果是，EJB使得开发健壮、三层的企业应用变得很简单。软件公司在分发用CORBA, DCOM, 或者Java RMI开发的分布式系统时，往往是一种复杂的过程，但如果用EJB开发分布式应用会更简单、有效率。

 

EJB规范

 

EJB规范定义了组件开发者和EJB服务器厂商各自的职责。组件开发者遵循规范中定义的编程模型来开发商业组件（即，企业beans），符合规范的EJB可以在所有的EJB服务器中移植。因为EJB服务器遵循规范，它们可以运行任何的EJB，并且自动管理EJB的完整环境。

 

EJB体系结构

 

EJB服务器运行在三层构架的中间层。架构的表示层由Java客户组成，并且通过JNDI 和Java RMI-IIOP访问EJB。资源层由一个或多个后端资源构成，通常都包含数据库。这只是展示EJB如何配置在应用架构中的逻辑视图，并没有描述出层的物理位置。比如，表示层可以是桌面Java应用程序、Servlets、其他的EJB。

EJB一般由4部分组成：home 接口、remote接口、bean类和XML配置描述文件。home 接口申明Java开发人员用于创建新EJB、定位现存EJB、销毁EJB的方法。remote接口申明EJB在运行时Java客户所调用的商务方法。bean类封装EJB的应用逻辑并实现了remote接口中申明的商务方法。配置描述文件是以XML形式存在的文件，用于描述EJB，并给出EJB运行时属性，其中这种属性依赖于目标服务器。EJB开发者需要完成这4部分的工作，并把它们打包成一个.jar文件用于发布到目标服务器上。

当完成EJB的发布后，发布者可以用EJB服务器提供的工具（译者注：比如，WebLogic提供的Builder工具）来打开.jar文件，并且可以查看XML配置描述文件。在XML配置描述文件中的信息用于配置EJB的运行时属性，使得EJB可以在EJB服务器上正确的运行。EJB运行在EJB容器中，这种容器是EJB服务器中宿主EJB实例哪一部分。容器管理EJB的运行时事务、安全、并发性、持久性和资源。另外，容器生成EJBHome 和 EJBObject 代理（proxies），这些代理分别实现了home 和remote接口。这些分布式组件代理给位于表示层的Java客户提供了访问中间层上的EJB的能力。对于每一个EJB配置，都有一个EJBHome 和 一个EJBObject以用于引用EJB。（这个代理在我们的平台上就是我们的对象池和生命周期管理所做的工作。将对象资源进行管理和分配。）

位于表示层上的Java客户通过Java命名目录服务得到对EJB的EJBHome的远程引用（proxy）。JNDI是独立于厂商的Java应用编程接口，可以和任何的命名或者目录服务，比如CORBA 命名或者轻型目录访问协议（LDAP），使用。EJB服务器必须实现某种JNDI兼容的命名或目录服务以支持对EJBHome的访问。一些EJB服务器有自己开发的JNDI兼容的命名或目录服务，另一些用第三方提供的。

客户使用EJBHome以产生或者查找宿主在EJB容器总特定的EJB。如果该EJB存在，则返回对EJBObject的远程引用。EJBObject实现了EJB的远程接口，并将客户的请求转发给EJB实例。

Java客户不是直接访问EJB，而是通过EJB提供的EJBHome 和EJBObject远程代理来访问。EJB容器截获远程代理产生的每一个方法调用，这样一种方式使得容器可以管理和该调用相联系的EJB运行环境。对EJBHome的方法调用引起EJB容器创建，或查找EJB，并提供EJBObject代理给该客户。对EJBObject的方法调用被委派给bean类，该bean类含有响应该请求的商业逻辑。EJB容器可能实例化多个bean类以支持多个客户。从而使得EJB服务器可以负荷大的客户负载。

目前在EJB 2.0中有3种EJB类型：会话、实体和消息驱动。消息驱动EJB 是EJB 2.0新加入的成员，会话、实体EJB是在1998年发布的EJB 1.0中介绍的。会话、实体EJB类似于典型的分布式组件：宿主在中间层并处理客户产生的同步远程方法调用。（类似Remoting机制）另一方面，消息驱动EJB不是一个分布式组件，它借助于JMS处理异步消息。（MSMQ机制）

会话EJB是一种非持久性、支持事务、服务器端的组件。这种类型的组件用于建模过程、服务、客户和服务器端的会话。会话EJB包括有状态、无状态两种。

每个stateful会话EJB只能给创建它的Java客户服务。stateful会话EJB的类定义实例变量，以用于保存会话过程中的会话数据，从而使得方式之间是相互关联的。该特性使得stateful会话EJB作为客户的扩展、在EJB服务器上维护会话数据并为客户完成所要的任务。stateful会话EJB用于建模代表代理、角色之类的商业概念，其中这里的代理、角色是针对特定客户的。比如，银行出纳员处理货币交易、在线购物的购物车、或者旅行代理商所要完成的机票、旅店和汽车租润过程都是stateful会话EJB可以采用的情景。

stateless 会话EJB可以在多个客户之间共享。这种机制给stateless 会话EJB实例更多的弹性，但同时也不可以在EJB服务器中维护Session数据。stateless 会话EJB中，方法调用之间没有什么关系。每个方法调用是无状态的、类似于Java类中的static方法。stateless 会话EJB用于建模无状态服务，比如，信用卡处理、财务计算和库存查找。

实体Beans是持久的、事务性的、服务器端组件。(与我们的容器中间件的对component 的定义是相同的)

这类Beans用于建模商业领域中的对象，比如银行账号、订单和产品。这些Beans具有数据和行为信息，一般情况下会储存在数据库中。

根据如何管理持久性可以把实体Beans分为两种。其中一种，Bean管理持久性（BMP）的实体Beans，这种Beans需要Beans自己管理数据库中的关系和持久状态。BMP开发者需要把数据库访问逻辑直接写到bean类中。另外一种，容器管理持久性（CMP)的实体Beans，相比之下，EJB容器完成管理数据库中的关系和持久状态。CMP开发者不需要些数据库访问代码，在配置阶段自动会生成。EJB 2.0种，CMP有很重要的改动。

消息驱动Beans是无状态、服务器端组件。主要用于接收、处理Java客户通过JMS发送的消息。这种Beans用于建模企业内部消息中的过程、路由。开发者可以用消息驱动Beans集成遗留系统和EJB系统，或者完成B2B交互。然而，消息驱动Beans只是由bean类和XML配置描述文件构成，没有home或者remote接口。消息驱动Beans不是分布式组件，没有EJBOject和EJBHome引用。他们仅仅对来自JMS的异步消息作出响应。

 

结论：

 

EJB规范为分布式计算定义了强有力的平台。规范不仅定义了应用开发者使用的组件模式、而且还定义了应用服务器厂商实现的基础框架。这样一种规范给开发者提供了一个健壮、灵活、可移植于不同厂商产品的商业解决方案平台。