学习分布对象技术，看这篇笔记...

中间件 分布对象 软件构件

本博客是本人学习分布对象技术的笔记，在这里与大家分享。

 

第一部分 构件与中间件

随着网络与通信技术的发展，分布式软件的应用越来越广泛，分布式软件在计算机 软件应用领域扮演着非常重要的角色。

分布式软件：

分布式软件一般比集中式软件规模大、复杂，是软件开发复杂性的集中体现。 简单地讲，分布式软件指运行在网络环境中的软件系统，而网络环境是一群通过网络互 相连接的处理系统，每个处理节点由处理机硬件、操作系统及基本通信软件等组成

主要用于改进某些应用程序的运行性能，使它们比单进程的集中式实现更具有效率，如利用互联网上的大量计算机实现海量数据的科学计算或分析，此时软件系统的分布性并不是现实世界中分布性的映射，而是为利用额外的计算资源而人为引入的。

分布式软件通常基于客户机/服务器（Client/Server）模型。

两层结构中软件开发的主要工作量在客户层。数据层基本没有什么程序代码，主要就是建好数据库，可能利用存储过程实现一些基本的业务逻辑。开发人员所编写的代码几乎全部 都在客户端，一般可以把客户端的代码分为用户界面相关的代码和业务逻辑相关的代码，在客户端的代码中要访问数据库中的数据，可以执行一些 SQL 语句或调用存储过程。

一般的两层结构（服务器层+客户层）有以下缺陷：

第一，客户端的负担比较重。一般认为，客户端程序只要为使用该系统的用户提供一个人机交互的接口就行了，但是在两层结构下，客户端仍然需要进行比较复杂的数据处理，因为客户端从数据库中得到的仅仅是一些原始的数据，必须按照业务逻辑的要求对这些数据进行一定的处理后才能呈现给用户，所以客户端的负担比较重。

第二，客户端的可移植性不好。处理复杂必然牵涉更多的移植性问题，另外在两层结构 下，每个客户端上都要安装数据库驱动程序，移植至少需要重新安装数据库驱动。

第三，系统的可维护性不好。因为客户端包含过多的业务逻辑，并且业务逻辑与人机交互界面交织在一起，无论是用户界面需要修改，还是业务逻辑需要修改，都很麻烦。

第四，数据的安全性不好。两层结构下，数据库必须为每一个客户端机器开放直接操作数据库的权限，这时就很难防止一个恶意的用户在某个客户端机器上利用该权限执行其不应该执行的操作。

三层结构：客户层，中间层，服务器层。服务器提供数据库和存储过程，中间层提供业务逻辑处理，客户层提供用户界面代码。

1、更好的性能和可伸缩性。

2、大量的中间层中间件平台提供丰富的 系统级服务，使得开发人员可以以更少的工作量开发出更复杂、可靠、高效的软件系统。

3、降低了客户端的负担、改善了其可移植性，又提高了系统的数据安全性；同时业务逻辑代码与用户界面代码相对独立，也在很大程度上提高了系统的可维护性，较好地解决了两层结构的上述问题。

 

面向对象的精髓之一就是在于对象维护自身状态并进行通信，这对于分布式计算环境时非常理想的。

构件/分布式对象：

一般地讲，构件指系统中可以明确辨识的构成成分，而软件构件指软件系统中具有一定意义的、 相对独立的构成成分，是可以被重用的软件实体。由于本书关注分布式系统，对应软件构件也关注分布式构件，因此除非特别声明，以后论述中不区分构件与分布式对象这一对概念，一般提到的构件均指分布式构件，即分布式对象，反之亦然。

容器：

通常 的做法是设置容器来为构件一个运行环境，容易是一种特殊的应用程序，构件在容 器中运行和管理。当有客户端要访问某个构件时，实际是向容器发起了一个请求， 容器再去判断构件的具体实现语言、实现方式以及构件的具体物理位置，然后帮助 请求者与构件进行交互。

编组和解组：

网上传输的数 据只能是串行化的流数据，所以需要把程序员熟悉的有类型的数据转化成便于网络 传输的流数据发送出去，并且需要把网络上接收到的流数据转化成程序员容易处理 的有类型数据，这就是编组与解组的过程。

中间件：

与操作系统、数据库管理系统类 似，中间件是在操作系统（数据库管理系统）与应用系统之间的一层软件，通常为分布式应 用的开发、部署、运行与管理提供支持。

常见的中间件：

终端仿真/屏幕转换中间

数据访问中间件

远程过程/方法调用中间

消息中间件

事务（交易）中间件

构件中间件

 

中间件产生原因：

不断从应用系统中提取共性、降低高层复杂性，导致中间件的诞生。

中间件越来越多，开发时安装配置各种复杂，亟需一种集成的中间件。

集成中间件在应用中的表现形式主要为应用服务器。

目前应用最广泛的集成中间件有

远程过程调用（Remote Procedure Call，RPC）：

RPC 是第一个得到广泛应用的高层通信 协议，使用 RPC，客户应用程序可以像调用本地过程那样调用在远程计算机上执行的 C语言函数。由于是结构化的，因此目前已经基本被面向对象的通信协议取代。

 

高层通信协议的通信模型为Stub/Skeleton结构：

①：客户程序将调用请求发送给客户端桩，对于客户程序来说，桩就是服务程序在客户端的代理。

②：客户端桩负责将远程调用请求进行编组并通过通信总线发送给服务端。

③：调用请求经通信总线传送到服务端框架。

④：服务端框架将调用请求解组并分派给真正的远程对象实现（服务程序）。

⑤：服务程序完成客户端的调用请求，将结果返回给服务端框架。

⑥：服务端框架将调用结果编组并通过通信总线发送给客户端桩。

⑦：调用结果通过经通信总线传送到客户端桩。

⑧：客户端桩将调用结果解组并返回给客户程序。

Stub/Skeleton 结构的支持使得开发人员从繁杂的底层通信工作中解脱出来，开发人员可以不用编写底层通信代码即可实现客户端与服务端的远程交互，从而将主要精力集中到业务逻辑的实现上。

 

互操作：

接口：

在 Java RMI 中分布式对象的接口用 Java 语言的 interface 定义，并且要求所有分布式对象的远程接口必须继承 java.rmi.Remote 接口，还要求其中的每一个方法必须声明抛出 java.rmi.RemoteException 异常，因为网络通信或服务程序等原因 均可能导致远程调用失败。

注意程序中远程对象 callManager 必须声明为远程对象接口 CallManagerInterface 的实例，而不是远程对象实现类 CallManager 的实例，因为客户程序只能看到远端分布式对象（构 件）的接口。

Java 字节码（.class）由 JDK 提供的 javac 编译器生成，而远程对象在客户端的桩与 服务端的框架必须另由 rmic 编译器生成，rmic 的输入是 Java 字节码文件而不是 Java 源程序 文件

分布运行：

跨机器运行，我们需要修改客户端程序中查找分布式对象的代码，使其查找运行在服务 端机器上的分布式对象，而不是本机上的分布式对象。具体的修改就是将调用命名服务的 lookup 方法时将对应的主机名改为服务程序运行的机器的主机名或IP地址。

 

第二部分 CORBA规范与CORBA中间件

 

第二章 CORBA基本原理

OMG对象管理组织

术语：

OMA对象管理体系结构

ORB对象请求代理：是基于分布式对象构建应用程序的基础，保证对象在异类网络中可移植性可互操作性。

IDL接口定义语言：定义CORBA对象的接口提供标准

POA对象适配器

 

OMA参考模型：

有应用程序接口，领域接口，公共设施接口，对象服务接口，中间的ORB类似于通信总线，提供互操作的基本支持。

 

应用程序接口需要程序员自己实现。

ORB将请求分派给对象实现也有两种方式：

ORB屏蔽了客户端发送请求与服务端接收请求的不同方式。从客户程序的角度看，使用 DSI的对象实现与使用IDL框架的对象实现行为相同，客户程序不必提供特别的处理去与使 用DSI的对象实现通信

POA：

在 CORBA 服务端程序中，对象适配器负责管理服务端的分布式对象。在 ORB 结构中，分布式对象与 ORB 内核之间的通信由对象适配器完成，对象适配器负责对象引用的生成与解释、方法调用、交互的安全性、对象实现的激活与冻结、将 对象引用映射到相应的对象实现、对象实现的注册等。

在CORBA中实现可互操作性：

实现可互操作性的方法通常可分为直接桥接和间接桥接两种方式。

通信协议：GIOP、IIOP 与 ESIOP

1． 不同平台与语言之间的可互操作性：如操作系统，指定ＩＤＬ标准，以及IDL到不同语言的映射。

2． 不同厂商 ORB 产品之间的可互操作性：CORBA２.０引入了GIOP和IIOP，从而实现了不同供应商…

3． 不同体系结构之间的可互操作性：OMG通过引入ESIOP来解决之一问题，但不能解决所有问题。

 

作为一个 ORB 平台，VisiBroker 支持可移植对象适配器、值类型、RMI/IIOP、具有集群和容错特性的命名服务、属性管理、服务质量、 拦截器等，并扩充了位置服务、对象包装器等功能。

 

CORBA 的大特点：

在于提供了在异类分布式环境中对象之间高度的可互操作性，这种高度可互操作性使得运行于异类环境的分布式对象之间可以方便地通信，异类环境包括不同供应商的不同硬件平台、操作系统、网络系统、程序设计语言或其他特性。

 

优缺点

在人机界面支持、持久化支持等方面的欠缺，CORBA 中间件在支撑以数据库为核心的 Web 信息系统开发时显得支 撑不够全面，而 Java 企业版或.NET 中间件的优势更为明显。

 

第三章 基于CORBA开发过程

 

利用伺服对象激活器处理请求时，POA 首先查找活动对象映射表；如果找到对象标识则调用伺服对象的合适操作并将结果返回给客户程序，否则以对象标识与 POA 作为参数调用伺服对象激活器的 incarnate 操作，由伺服对象激活器查找并返回一个合适的伺服对象，然后将该伺服对象登记到 活动对象映射表中；最后调用伺服对象的合适操作并将结果返回给客户程序。

伺服对象激活器会在对象激活一段时间后将其冻结，这样仅在内存中保留那些正在被使用或者刚刚 被使用过的对象，而暂时不用的对象不会占用系统内存，从而有效提高系统内存利用率，同时伺服对象激活器可以保证所有对象的可用性，在下次调用冻结的伺服对象时，可将其激活 。

 

在 CORBA 中，分布式对象提供的服务的调用方式可有三种：

图 CORBA应用程序开发过程

1、面向对象分析与设计：以面向对象的分析方法进行系统分析与设计。

2、用IDL编写对象接口：分布式对象对外提供的服务的规格说明。

3、编译IDL文件生成桩于框架：用idl2java编译IDL文件，生成客户端桩stub和服务器端框架skeleton

4、编写客户端代码：初始化ORB，然后绑定需要使用的服务对象，调用服务对象提供的服务。

5、编写服务端程序：编写对象实现，创建POA，伺服对象，激活对应管理器。

6、编译客户端程序：使用vbjc编译stub和编写的客户端程序。

7、编译服务端程序：使用vbjc编译skeleton和编写的服务端程序。

8、部署运行应用程序：系统管理员规划如何在终端用户的桌面系统安装客户程序，以及如何在数据库安装服务程序。

 

CORBA 中对象接口中定义的核心内容和 RMI 例子中用 Java interface 定义的接口类似，但它们有一点明显区别，那就是 CORBA中对象接口是由 OMG  IDL 定义的， 而这种 IDL 是独立于程序设计语言的，正是有了这种中性的接口约定，才使得分布式对象和客户端的跨语言得以实现。web services则是使用WSDL定义接口。

 

IDL 是一种独立于具体程序设计语言的说明性语言，IDL 编译器的作用是将 IDL 映射到具体程序设计语言，产生客户程序使用的桩代码以及编写对象（服务端）实现所需的框架代码。

 

编写客户程序/服务程序

与 Java RMI 例子中类似，在 CORBA 服务端，除了编写对象实现代码后，还要编写一个服务程序来将分布式对象准备好。服务程序利用可移植对象适配器（POA）激活伺服对象供客户程序使用。服务程序通常是一个循环执行的进程，不断监听客户程序请求并为之服务。

 

创建客户程序时，应将程序员编写的客户程序代码与 IDL 编译器自动生成的客户程序桩代码一起编译；

创建服务程序时，应将程序员编写的对象实现代码与 IDL 编译器自动生成的服务程序框架代码一起编译。

 

运行 CORBA 应用程序时，必须首先启动服务程序，然后才可运行客户程序。例如 VisiBroker for Java 的 ORB 内核是一个名为 osagent 的独立运行进程（又称智能代理，smart agent），可以在启动服务程序之后才启动 osagent，但必须在运行客户程序之前让 osagent 启动完毕。

 

IDL 编译器(idl2java)为 IDL 文件中定义的每一个接口自动生成 7 个.java 文件，这 7 个文件中包含了 CORBA 对象与客户端交互时用到的负责服务端和客户端底层通信的两个支撑类，这两个类分别是：xxxStub 、xxxPOA  

 

对象实现代码所在的类名字可由程序员自由掌握，只要不与IDL编译器自动产生的Java 类产生名字冲突即可，例如我们为例子程序中的两个对象实现分别命名为 AccountImpl 和 AccountManagerImpl。

 

使用C++语言实现的话：

编译与运行：VisiBroker for C++（4.5.1 for Linux）并不提供类似 vbjc 与 vbj 的辅助编译与运行工具，而是直接利用 Linux 平台上的 gcc 编译器和 make 指令完成编译； 而 C++语言不是解释性语言，因此编译后得到的可执行程序直接运行。利用 make 指令编译程序时开发人员通常需要编写一个 makefile 来指示编译器具体的编译链接工作。

 

第四章 编写对象接口

 

OMG IDL

客户程序仅仅依赖 于对象的接口，而不是对象实现。客户程序甚至可以采用与对象实现完全不同风格的程序设 计语言来编写。将对象接口与对象实现分离后，对象接口成为向外公布对象行为的唯一途径。

OMG IDL 具有如下特点：

具有面向对象的设计风格。

可用于定义分布式服务的规格说明。

可用于定义复杂的数据类型。

独立于具体的程序设计语言。

独立于特定的硬件系统。

 

OMG IDL 是一种说明性（declarative）语言，而不是一种程序设计语言，程序员的编程工作仍然采用传统的面向对象或过程式程序设计语言编写客户端代码和服务端代码。

 

由于用 IDL 编写的对象接口担当了中间角色，客户程序无法（也无需）知道服务端代码采用什么程序设计语言编写，程序员编写服务端程序也不必预测访问服务对象的客户程序 由什么程序设计语言编写。这时，同一接口、多种实现的目标可轻而易举地达到。

 

IDL中只能出现声明，但不允许出现任何具体的数据表示（如变量或对象实例的声明）和操作实现（如算法、 控制结构、构造与析构函数等）。 理解 IDL 语义 的佳途径是掌握 IDL 到某一门程序设计语言的映射规范，在现有程序设计语言中 Java 语言拥有接近于 OMG IDL 的构造，因而 IDL 到 Java 语言的映射规则也是简单的。

IDL有六种：

模块、类型、常量、异常、接口以及值

 

在 OMG IDL 中，关键字是大小写敏感的，但标识符却是大小写无关的，在实际代码中尽量保持大小写一致。

 

模块

一个 IDL 模块被映射为一个同名的 Java 程序包，该模块中的所有 IDL 类型被映射到相应程序包中的 Java 类或接口。不包含在任何模块之中的 IDL 声明被映射到一个无名的 Java 全局作用域程序包。

 

 注意 IDL 没有 C/C++语言中那种 int 类型，这避免 了数据类型对具体机器的依赖性。

 

OMG IDL 声明形式参数表时不同于大多数程序设计语言，它要求每一个形式参数都必 须包含一个标明参数传递方向的关键字 in、out 或 inout。关键字 in 表明参数从客户程序传向对象实现；out 表明数据从对象实现返回给客户程序；inout 表明数据从客户程序传给对象实现，然后返回给客户程序。

 

 

即使在 IDL 文件的接口定义中使用了继承机制，对象实现也未必一定要有继承。IDL 支持多继承，可直接映射到 C++这类支持多继承的程序设计语言，也可映射到 Java 这类仅 支持单继承的语言，甚至可映射到 C 这类非面向对象程序设计语言。

 

值类型：

什么是值类型？

值类型是一种特殊的类型声明。值类型主要用于网络中传递对象的状态信息。

当一个对象的主要目的是为了封装数据，或者一个应用程序需要显式地对某个对象进行复制时，对象应使用值类型（valuetype），这时的对象实例通常简称为值（value）。

 

账户由接口（interface）变为了值类型（valuetype），因此客户端使用的“账户”已经不再是远端的分布式对象，而是远端账户对象在本地的副本（即本地对象），尽管从代码上看账户管理员的 open 操作返回的仍然是 Account，但是返回值的性质发生了根本变化，原来返回 的是远端对象的引用，现在返回的是一个对象副本。

 

服务端执行 open 方法时，调用 Account 的构造方法创建了一个名为 account 的实例， 客户程序调用 open 方法获取的不是 account 的对象引用，而是在客户端生成的一个 account 的副本。实例 account 及其副本分别在服务端和客户端且都是本地的。

 

客户程序通过ORB获取账户管理员的远程对象引用manager后，调用该对象引用的open 方法开设一个账户。注意由于 Account是一种 IDL 值类型，调用open 方法返回的实例 account 是客户端本地的局部对象，而不是通常的 CORBA 对象引用，客户端的实例从服务端的实例 复制了状态后，它们两者之间就是相互独立的。客户程序的对返回的对象存款 200 元后，再次调用账户管理员的 open 操作重新打开同样的账户，查询其余额。

将本小节的例子程序拿去编译并运行的读者会发现，客户程序控制台输出的存款操作已经完成，余额已经变化，但是再次打开同样的账户，却显示帐户的余额未发生变化，仍为存 款之前的余额。

 

我们有意设计成这种效果以反映值与对象引用的区别：由于 open 方法的返回值是值类型，因而客户端操纵的只是服务端对象的副本，当然不会对服务端的帐户余额产生影响。

 

我们设计IDL接口时，常见的对象接口为：

1、操纵型接口

2、工厂型接口

3、查找与选择接口

4、管理型接口

 

第五章 编写服务端程序

 

对象适配器POA是一个重要的 ORB 组件，它负责 将抽象的 CORBA 对象映射到具体的伺服对象。

 

CORBA对象和伺服对象之间的区别

 

对象适配器的作用：

对象适配器负责决定在收到客户请求时应调用哪个伺服对象，然后调用该伺服对象上的 合适操作。CORBA 支持多种不同类型的对象适配器，但所有对象适配器的主要作用都是创建对象引用，并将对象引用与真正执行服务的程序设计语言伺服对象相关联。

 

POA 管理器（POA Manager）是一个对象，它将一个或多个 POA 组织在一起，为其中 的 POA 提供共同的操作。

 

POA 策略是一个对象，负责控制相关 POA 的行为以及这些 POA 所管理的对象，使用POA 前应仔细考虑应用程序所需的策略集。

 

一个 POA 管理器创建后可以有 4 种状态：持有状态（holding）、活动状态（active）、非 活动状态（inactive）以及丢弃状态（discarding）。

 

活动对象映射表：

每一个 POA 中都有一个活动对象映射表（Active Object Map，缩写为 AOM），表中保 存了活动对象的对象标识以及与之关联的伺服对象，其作用是将活动对象通过对象标识映射 到伺服对象。在一个特定的 POA 中，对象标识唯一地标识了一个 CORBA 对象。 为

 

伺服对象管理器：

程序员自己编写的代码，主要作用是查找并返回伺服对象。

两类伺服对象管理器：伺服对象激活器和伺服对象定位器。要

使用伺服对象管理器， 必须为 POA 设置 USE_SERVANT_MANAGER 策略，并结合伺服对象保持策略决定使用哪 一种类型的伺服对象管理器。

采用 RETAIN 表示使用伺服对象激活器，常用于激活持久对象；采用 NON_RETAIN 表示使用伺服对象定位器，常用于查找瞬时对象。

 

伺服对象定位器与伺服对象激活器的一个重要区别:

即如果连续两次以对象标识 Zhang3 绑定对象引用并调用该对象引用的操作，伺服对象激活器只调用一次 incarnate 方法，而伺服对象定位器则会调用两次 preinvoke 方法。当伺服 对象处理请求完毕后，POA 还将调用伺服对象定位器的 postinvoke 方法

 

BOA vs. POA

POA本身利用IDL定义，比BOA更强调如何处理复杂问题。

BOA不足以处理大规模系统，POA为实现系统提供了更多的功能。

POA能保持保持再不同进程和同一进程的语义一致性。

 

第三部分 Java企业版规范与Java企业版中间件

 

第六章 Java企业版基础

 

由于 Java 是一种解释性语言，因此 Java 2 平台的底层是面向不同环境的 Java 虚拟机 （Vitural Machine），为相应环境下的 Java 应用程序提供基本的解释执行 Java 目标码的运行 支撑。

 

开发、管理基于不同环境的 Java 应用：

 

J2EE 为开发人员提供的是一种工业标准，而不是某个厂商自己的 产品，尽管 J2EE 规范是由 Sun 负责制定和发布的，但它确实是一套业界普遍支持和采纳的开放标准，规范本身也是由很多个大型厂商，比如 BEA、IBM 等来共同推动的。

 

遵循一致的工业标准开发的应用可移植性好，产品质量有保证。

 

J2EE 平台为开发企业级应用提供三个方面的技术支持：

应用构件

J2EE 中的应用构件可分为两大类：客户端构件和服务端构件。客户端构件又包含 Applets 和 Application Clients；服务端构件又包含 Web 构件（JSP、Servlets）和 EJB（Enterprise Java Bean） 构件，本章第 2 节将对每种 J2EE 构件进行简要的解释。

 

公共服务

就是 J2EE 中除了像 CORBA 中那样以 API 的方式提供的服务外，还提供了丰富的运行时服务

通信

支持构件之间的交互

 

客户端构件：

现在大多不使用applet。

 

很多 J2EE 应用中均不使用 application client 或 applet 作为客户端程序，客户 端的用户界面一般由 web 页面来提供，要么是静态的 html 页面，要么是服务端的 web 构件动态生成的页面。这其中除了胖客户端需要在每个客户端机器上布署客户端程序的原因外， 页面设计的快捷与美观也成为越来越重要的原因。

 

服务端构件——servletServlet

也是一种特殊的 Java 类，和 applets 不同，servlet 是运行在服务端的，因此它不需要图形用户界面。Servlet 在 J2EE 应用中的主要作用是接收客户端的 HTTP 请求（如通过 浏览器发出的请求），动态生成 HTTP 响应（如一个页面）。

 

服务端构件——JSP

是一类特殊的 HTML 文档，它通过在 HTML 文档中嵌入 JSP 特定的标签来允许程 序员在页面中加入 java 代码，通过 Java 代码的执行动态生成页面的内容。

 

EJB是Enterprise Java Bean的缩写，通常是构成 J2EE 应用系统的核心构件，是用来支 持大型的企业级应用开发的。可以编写三种构件：

实体Entity Bean

1、Entity Bean 的主要作用是封装数据库操作，将数据库操作转嫁到 Entity Bean 对应的 Java 类/对象上，从而简化数据库相关应用的开发。

2、使用者调用 CMP（容器维护的持久性）类型 Entity Bean 的 Home 接口中 create 操作会导致在数据库中插入记录。

会话session bean

Session bean 又可分为两类:

 

EJB是服务端构件。

 

J2EE中的公共服务：

JNDI：

 J2EE 平台提供的命名服务接口。JNDI 是 Java Naming and Directory Interface 的 缩写，他为开发人员提供的主要功能是在程序中查找/定位构件或系统资源。

 

开发人员按照标准的接口来使用， 厂商按照自己的方式来实现接口中的功能。

 

JDBC：

JDBC 为应用提供与厂商无关的数据库连接，它通常提供一种通用的方法用来查询、更新关系型数据库表，并且把数据库操作的结果转化成 Java 的数据类型resultSet。 一个 JDBC 驱动支持应用跨数据库平台完成以下三件事情：

1）建立与数据库的连接； 2）向数据源发送查询和更新语句； 3）处理结果。

 

JDBC连接池：

JDBC2.0 包含了一个内嵌的数据库连接池，数据库连接池是 J2EE 构件访问数据库的常用方式。在传统的 Java 程序中，应用需要访问数据库时，通常首先加载一个驱动程序，然后建立数据库连接，进行数据库操作，操作完成后再释放数据库连接。在这个过程中，建立 和释放数据库连接的过程是非常耗时的，有时甚至比真正的数据库操作所占用的时间还多。 而数据库连接池则为应用提供了一种更为快捷的数据库访问方式，在这种模式下，平台把数据库连接当作是一种系统资源来存放在数据库连接池中，平台初始化时会自动建好一些数据 库连接，当应用需要操作数据库时，直接从池中获取一个建好的连接，用完后再把连接放回 连接池供后续使用，这就为应用节省了建立数据库连接和释放数据库连接的过程，从而达到 一个较高的访问数据库的效率。

 

JTA Java Transaction API的缩写，支持应用中的分布式事务控制标准API。

事务的特性：

原子性

一致性

隔离性

耐久性

 

JCA Java connector Architecture

基于 JCA 访问不同系统时，通常通过连接不同类型系统的适配器（Adapter）来屏蔽不 同系统的差异。

 

安全服务：

 

J2EE 中的安全性控制分为两个级别：

第一级是认证（authentication），就是首先要验证 访问者的身份。经过身份认证后。

第二级就是授权（authorization）控制，所谓授权就是判断特定的访问者是否具有在特定资源上执行某种操作的权限，比如，是否有权限访问系统中 的某个 JSP 页面，是否有权限调用系统中某个 EJB 提供的特定方法

 

持久性服务：

数据库操作，J2EE 中的实体构件主 要用来实现数据库的访问，基于容器提供的持久性服务，开发人员可以实体构件相关的数据 库操作交给容器和开发人员来完成。

 

资源管理：

线程池、数据库连接池，J2EE负责维护管理应用所用到的系统资源。好处：

1、提高资源利用率和效率

2、程序和具体的资源相对无关

 

J2EE应用开发：

 

在打包过程中，需要应用组装者编写一种 特殊的组装配置文件——布署描述符（Deployment Descriptor，简称 DD）。 一个布署描述符是一个XML格式的文件，该文件中描述了当前模块中所包含的内容（构 件或模块）和模块所需要的环境，J2EE 平台的丰富的源代码以外的可定制性大部分都体现 在部署描述符中。

 

J2EE平台上的目标文件主要有以下三种类型：

1. ava 目标文件（Java Archive）：Java 语言的目标程序（.class 文件）包，对应磁盘 上后名为.jar 的文件，在 J2EE 应用中用来打包 EJB 构件、Application Client 以及 它们需要的辅助 Java 目标文件。
2. Web 目标文件（Web Archive） ：Web 构件目标程序包，对应磁盘上后名为.war 的 文件，在 J2EE 应用中用来打包 Web 构件（Servlet、JSP）以及静态页面相关的文 件（如 HTML 文档、图片等）。
3. 企业目标文件（Enterprise Archive）：J2EE 应用目标程序包，对应磁盘上后名为.ear 的文件，在 J2EE 应用中用来打包完整的 J2EE 应用。一个完整的 J2EE 应用中可以 包含若干个 Java 目标文件和若干个 Web 目标文件。

EJB 模块的布署描述符——ejb-jar.xml

同一 EJB 模块中的所有 EJB 构件 共享该模块的布署描述符，可以不修改 EJB 的源程序，而仅通过修改部署描述符就可以使得 EJB 去适应新的环境。

Web 模块的布署描述符——web.xml

通常在 Web 模块中完成对用户身份的认证。

J2EE 应用的布署描述符——application.xml

描述了当前 应用中包含的所有模块，此外还可能定义应用使用的安全性角色。

 

J2EE应用中的MVC设计模式：

模型（Modeling），即系统的模型或系统基本的业务功能，通常由 EJB 构件实现；

视图（View），即系统的人机交互界面，通常由 JSP 构件实现；

控制器（Controller），即分发客户请求，决定每次客户端请求调用哪个 EJB 构件完成、结果由哪个 JSP 构件呈现的控制器通常由 Servlet 构件实现。

 

在 MVC 模式下， J2EE 应用呈现更为清晰的四层结构：客户层、Web 层、EJB 层与数据层，客户通过浏览器发出的请求通常被 Servlet 构件接收，Servlet 调用合适的 EJB 构件完成客户请求，然后再将处理结果利用 JSP 呈现。此时，客户端只能访问 Web 构件，Web 构件不会直接访问数据库， J2EE 应用呈现出典型的四层结构。

 

第七章 EJB构件基础

 

EJB 规范采用的主要构件技术包括：

分布对象技术

所有的分布式对象技术都会使用某个特定的远程方法调用协议，EJB 中常用的远程方法调用协议是 RMI/IIOP。采用 Stub/Skeleton 结构来支持客户端与分布式对象之间的交互。

 

服务端构件技术

用于中间层应用服务器，支持分布式商业对象的开发

 

CTM（Component Transaction Monitor）技术

CTM 是一个应用服务器， 它为分布式商业对象提供公共服务框架，CTM 公共服务框架支持大量的系统级服务，如事 务（Transaction）管理等。

 

EJB构件的特点：

公共服务框架

平台独立性

封装特性

可定制性

协议无关性

通用性

 

EJB和Java Bean的比较：

EJB 与 JavaBeans 都是基于 Java 语言的构件模型，开发应用时，可以选择 EJB 模型， 也可以选择 JavaBeans 模型。EJB 与 Java Bean 的区别主要包括以下几点：

 

EJB体系结构中的构件：

 

基于 Stub/Skeleton 结构与客户端直接交互的 并不是 EJB 构件，而是容器自动生成的实现 Home 接口中操作的 类（Home Bean）和实现 Remote 接口中操作的类（Remote Bean），由于这两个类是容器自 动生成的

 

每个EJB构件通常都有对应的一个Home接口与一个Remote 接口，这三种构件在 EJB 应用中通常作为一个整体出现，在开发时，EJB 构件的实现类与 对应的两个接口之间必须符合 EJB 规范所约定的对应关系与相关的设计原则。

 

第八章 EJB构件开发

 

有状态会话构件的生命周期包含三个状态：

1、方法就绪状态。表明对应有状态会话构件对象已被创建并处于就绪状态，可以为客户端提供服务；

2、不存在。表明 EJB 容器中不存在对应有状态会话构件的实例，处于不存在状态的实例还未被创建；

3、钝化状态。表明对应有状态会话构件对象已被转移至持久存储介质，暂时不能使用

 

Java 持久化实现方案主要包括：

 

第九章 EJB高级特性

 

事务控制：可以保证事务所包含的一系列操作要么全部执行成功，要么一个都不会执行，从而为应用 提供数据一致性的保障，并不提供安全性保障。

CMT

J2EE 平台为 EJB 构件提供 CMT（Container Managed Transaction，容器维护的事务）与 BMT 两种事务控制方式。

 

BMT （Bean 维护的事务）方式下，用户可以自定义发生回滚的异常， 程序员在 EJB 的源程序中控制事务边界控制（如事务开始、回滚、提交 等），并在部署描述符中指定由 Bean 控制事务的边界。与 CMT 方式相比，Bean 维护的事务可以跨越方法的边界，因此通常具有更好的灵活性。

 

读者应注意使用 BMT 控制事务时，应保证程序中的所有控制流出口均将事务结束（提交或回滚userTrx.begin();userTrx.rollback();userTrx.commit();），因为如果事务未成功结束往往导致数据库中的数据被加锁，从而使得应用无法 继续访问被锁定的数据。

 

开发EJB构件:

该 EJB 构件实现币值换算的功能，由于该构件的实例（对象）不需要保存与特定客户 端相关的会话状态，因此设计为无状态的会话构件

1、定义Remote接口

Remote接口继承了EJBObject接口。

Remote 接口包含 EJB 构件实现的商业方法的声明，客户端只能通过 remote 接口访问构 件实现的商业方法，不能直接调用。

 

2、定义Home接口

Home 接口中包含 EJB 构件生命周期管理的相关方法，客户程序使用 Home Interface 创 建、查找或删除 EJB 的实例。继承了EJBHome接口。该接口中仅声明了一个 create 方法，其返回值为上个程序 中定义的 Remote 接口（名字自拟，并不是叫Remote）。按照 EJB 规范的约定，create 方法抛出 RemoteException 和 CreateException 异常。

3、定义 Enterprise Bean 类

账户 EJB 的 Enterprise Bean 类首先要按照 Remote 接口的约定实现商业方法，就是在Remote接口中自己声明但是没有实现的方法，其次要实现 Home 接口中 create 方法对应的 ejbCreate()【这里必须要写成ejbCreate()】 方法与会话构 件生命周期相关的方法（ public void ejbRemove() {}  public void ejbPassivate() {}  public void ejbActivate() {}  public void setSessionContext(SessionContext Context) {}）。此类实现SessionBean或者EntityBean或者消息Bean之一。

 

【银行系统例子pdf教案P180】

读者应注意 withdraw 方法执行错误时抛出的异常是 RuntimeException，属于系统级异 常，因此容器会自动将 withdraw 方法对应的事务回滚，如果执行过程中抛出的异常不是系 统（如将程序 9-7 中 RuntimeException 改为 BankFailureException），则容器会认为事务的执 行是成功的，从而将事务提交。

 

安全性控制：

 

J2EE 中的安全性控制分为认证与授权两个级别，实现安全性控制的常用方式是声明的 方式。声明方式的安全性控制完全由容器自动控制，开发人员主要通过配置安全性角色与授 权规则来定制安全性控制的规则。

 

 

EJB3.0概述:

从前面的讨论可以看出，EJB 构件的开发需要开发人员遵循很多 EJB 规范的细节，这 给开发人员带来了不小的负担，有一种观点认为“EJB 大概是 J2EE 架构中唯一一个没有兑 现其能够简单开发并提高生产力的组件”，EJB3.0 规范正尝试在这方面作出努力以减轻其开 发的复杂性。

 

与旧规范相比，EJB3.0 的主要变化包括：

1、基于程序注释的新 EJB 模型

3.0中，EJB 构件是一个加了适当注释的简单 Java 对象——POJO （plain-old-Java-object，或 plain-original-Java-object）。

 

可以看出，开发人员可以不用再定义 Home 接口和 Remote 接口（平台可以自动生成它）， 而且打包时的基本配置信息可以以注释的方式（@Stateless 与@Remote 等）直接写在 EJB 的源代码中，需要使用的生命周期管理相关的方法可以以注释的方式在程序中进行标记

2、改进的实体构件及 O/R 映射模型

 

EJB 与 CORBA 对比

 

J2EE/EJB 与 CORBA 均采用 Stub/Skeleton 结构对分布式对象提供了良好的支持，基于 Stub/Skeleton 结构，开发人员不需编写底层通信代码即可实现分布式对象与客户端之间跨越 网络的交互。

 分布式应用程序的开发过程：

基本过程为首先定义分布式对象的接口，然后分别 完成服务端与客户端的开发，后布署运行应用程序。下面对开发过程中 J2EE/EJB 与 CORBA 的不同之处进行简化分析。

 不同之处：

第四部分 Web Service规范

 

第十章 web service规范

 

体系结构

 

是近几年提出的分布式计算模型。Web Service 是一系列标准的集合，包括 SOAP、UDDI、WSDL、WSFL/BPEL 等，Web Service 利用这些标准提供了一个松散耦合的分布式计算环境。

 

Web Service 使用 SOA（Service Oriented Architecture，面向服务架构）架构。

SOA 架构中包含三个主要参与者：服务提供者（Service Provider）、服务请求者（Service Requester）与服务代理（Service Broker）。涉及发布（Publish）、查找（Find）与绑定/调用 （Bind/Invoke）三个基本操作。

 

1、服务提供者将所提供的服务发布到服务代理的一个目录上，Publish；

2、服务请求者首先到服务代理提供的目录上搜索服务，得到如何调用该服务的信息，Find ；

3、根据得到的信息调用服务提供者提供的服务，Bind/Invoke ；

 

Web 服务通常具有以下特征：

 

 

Web Service 追求的第一目标是简单性，首先 Web Service 使用的协议本身是简单的；另 外一个可以使用的 Web Service 可以按照需要选择若干层次的功能，而无需所有的特性。

例 如，一个简单应用可能只要使用 WSDL/SOAP 就可以架构一个符合规范的 Web Service

 

SOAP：

SOAP 本身并不定义任何应用语义，如编程模型或特定语义实现，它只定义了一种简单的以模块化的方式包装数据的机制。

 

SOAP消息是Web Service 架构中不同结点间传送信息的基本数据单元。一个 SOAP 消息是由 XML 消息头和一个 SOAP 封装（SOAP Envelope）组成的 XML 文档。SOAP 封装描述了该消息所包含的基本信息，SOAP 封装中包括一个可选的 SOAP 消息头（SOAP Header）和必需的 SOAP 消息体（SOAP Body）。

 

SOAP的基本思想是将数据/对象打包成XML格式的数据在网络环境中交换以达到服务调用的目的。SOAP 可以简单理解为“HTTP+XML+RPC”，即使用 HTTP 作为底层通信协议，XML 作为数据传输的格式，实现 Web 环境下的远程服务调用（RPC） 。

 

WSDL：

WSDL 是一种用 XML 文档来描述 Web 服务的标准，是 Web 服务的接口定义语言。

 

UDDI：

UDDI 是一套基于 Web 的、分布式的并为 Web 服务提供注册的信息注册中心的实现规范，同时也包含了一组使企业能将自身提供的 Web 服务进行注册以使其它企业能够发现的问协议实现标准。

 

WSFL/BPEL：

用来将分散的、功能单一的 Web 服务组织成一个复杂的有机应用的标准。

 

（A）UDDI（Universal Description, Discovery and Integration）  

（B）WSDL（Web Service Description Language）  

（C）SOAP（Simple Object Access Protocol）  

（D）WSFL（Web Service Flow Language）/ BPEL（Business Process Execution Language）

• 在 Web Service 体系结构中，用来实现 Web Service 调用的协议是（C） ， 用来描述 Web Service 的标准是（B），用来发布、查找 Web Service 的标准是（A），用来将分散的、功能单一的 Web 服务组 织成一个复杂的有机应用的标准是（D）。（各选 1，4 分） 
• 完好的封装性；
• 松散耦合；
• 使用标准协议规范；
• 高度可互操作性：可以跨越平台、语言进行调用。
• 高度可集成能力；
• 动态性：可以自动发现服务并进行调用
• 编写对象接口：
  • 在 CORBA 中，对象接口是用 OMG IDL 定义的，而 IDL 可以映射到不 同的程序设计语言，因此 CORBA 应用的服务端与客户端可以使用不同程序设计语言实现；
  • 在 J2EE/EJB 中，EJB 构件的接口是用 Java 语言的 interface 定义的，因此 EJB 构件及其客户 端均必须用 Java 语言实现。
• 编写服务端程序：
  • 在 CORBA 中，服务端除了需要按照接口的约定实现分布式对象外， 开发人员还需编写一个服务程序来将分布式对象准备好（创建并激活）；
  • 而在 J2EE/EJB 中， 开发人员不需编写类似的服务程序，容器会根据运行与客户端请求状况自动创建或删除构 件。但是将构件生命周期管理交给容器自动管理同时也意味着开发人员丧失了对服务端程序 的更多控制力。
• 编写客户端程序：
  • 在J2EE/EJB和CORBA中，编写客户端的工作非常相似，只是在EJB3.0 之前，EJB 的客户端需要首先利用 Home 的 create 方法获取一个可用的 EJB 引用，过程比 CORBA 客户端要复杂。
• 布署应用程序：
  • 与 CORBA 相比，J2EE/EJB 提供了丰富的源代码以外的可定制性，其 应用的布署过程通常比 CORBA 应用的布署要复杂，但是随着复杂的布署过程，应用也获得 了丰富的可定制性支持。
  • 总地来说，按照作者的观点，J2EE/EJB 规范比较适合基于 Web 的分布式应用的开发， 而 CORBA 则在支持可互操作要求高的分布式系统开发方面有更大的优势。
• 对公共服务的支持
• 开发过程
• 工业标准特性
• 对分布式对象的支持
• 部署描述符不在是必须的了（配置通过注释直接写到 Bean 代码中）
• Home 接口没有了
• Bean 类可以实现 Remote 接口也可以不实现它 也就是说，简单情况下，EJB 构件可以只包含一个 Java 类
• CMT 方式下，事务由容器自动控制，开发人员只需在打包 EJB 构件时为 EJB 上的操作选择合适的事务属性即可。
  • 容器维护的事务（CMT）只有在事务执行过程中发生系统级异常（用户代码不捕获）时，才会自动将事务回滚，否则会认为事务执行成功而将其提交。 
• BMT 方式下，开发人员在 EJB 的源代码中 利用 JTA 来编程控制事务。
• 基于 DAO 和 JDBC 实现：这种方案通过 DAO（Data Access Object，数据访问对象） 来实现数据的持久化操作，具体实现时，DAO 通过 JDBC 来完成对数据库的访问。 这种方案要求开发人员对 JDBC 的底层信息要比较熟悉。
• 基于 ORM 实现：ORM 的全称为 Object Relational Mapping，其基本思想将关系型 数据库中的数据利用某种机制映射为 Java 对象，在业务逻辑构件看来，数据库中 的数据以 Java 对象的形式出现，通常每个对象对应数据库中的一条记录，因此数 据库操作也就转换成了对 Java 对象的操作。而这种数据与 Java 对象之间的映射通 常可以获得自动化机制的支持，从而将开发人员从基于 JDBC 的复杂开发中解脱出 来。EJB 中的实体构件提供的持久化实现方案就属于这一种，其它比较常用的还有 Hibernate 方案等。
• Enterprise Bean 所谓 Enterprise Bean 就是开发者实现的核心构件 EJB，是 EJB 客户端所调用的操作的真 正实现者，可以被部署到 EJB 应用服务器上。
• Home 接口（Home Interface）包含 EJB 生命周期管理的相关的方法，客户程序使用 Home 接口创建或删除 EJB 的实例。
• Remote 接口 Remote 接口中包含 EJB 实现的商业方法的声明，它实际上约定了 EJB 所提供的服务。
•  在大型的 Java 企业版应用中，EJB 构件通常用于服务端应用开发，而 Java Bean 构 件通常用于客户端应用开发或作为服务端 EJB 构件的补充。当然也可以用 Java Bean 构件进 行服务端应用的开发，但是与 EJB 构件相比，Java Bean 不能使用 Java 企业版平台提供的公共服务框架的支持，当应用需要使用关键的公共服务（如事务控制服务）时，使用普通的 Java Bean 构件显然不适合。
• EJB 构件是可布署的，即 EJB 构件可以作为独立的软件单元被布署到 EJB 应用服务器上，是应用构件（application components）；而 Java Bean 是开发构件，不能被部署为独立的单元。
• EJB 构件是布署时可定制的，开发人员可以通过布署描述符对 EJB 构件的运行时配 置进行定制；而 Java Bean 构件的定制通常仅发生在开发阶段，开发人员只能利用开发工具 创建并组装 JavaBeans 构件，部署时不能对其进行定制。
• EJB 构件是分布式对象，可以被客户应用或者其它 EJB 构件进行远程访问；而普通 的 Java Bean 构件只能在其构成的应用中使用，不能提供远程访问的能力。
• EJB 构件是服务端构件，运行在服务端，没有人机交互界面，对终端用户不可见； 而部分 JavaBeans 构件对终端用户可见，如 GUI 应用中使用的按钮构件等。
• Java 目标文件（Java Archive）：Java 语言的目标程序（.class 文件）包，对应磁盘 上后名为.jar 的文件，在 J2EE 应用中用来打包 EJB 构件、Application Client 以及 它们需要的辅助 Java 目标文件。
• Web 目标文件（Web Archive） ：Web 构件目标程序包，对应磁盘上后名为.war 的 文件，在 J2EE 应用中用来打包 Web 构件（Servlet、JSP）以及静态页面相关的文 件（如 HTML 文档、图片等）。
• 企业目标文件（Enterprise Archive）：J2EE 应用目标程序包，对应磁盘上后名为.ear 的文件，在 J2EE 应用中用来打包完整的 J2EE 应用。一个完整的 J2EE 应用中可以 包含若干个 Java 目标文件和若干个 Web 目标文件。
• 有状态的 Session Bean（Stateful Session Bean）
  • 而有状态的 Session bean 要跨方法调用保存会话状态，一个有状态的 Session Bean 实例同时只处理一个客户应用的请求，典型地如网上购物系统中提供购物车功能的 Session Bean
• 无状态的 Session Bean（Stateless Session Bean）
  • 无状态的 Session bean 在方法调用中间不维护任何状态，一个无状态的 Session bean 实例可以同时处理多个客户应用的请求。典型地如网上证券系统中提供股票信息查询功能的 Session Bean。
• 消息驱动Message Driven Bean
• Java 2 Micro Edition（J2ME）：J2ME 就是 Java 2 平台针对基于消费电子设备（如手机、PDA、智 能卡等）的应用开发所推出的平台。
• Java 2 Standard Edition（J2SE）：用来支持开发小型的桌面应用的 Java 平台，也就 是通常所说的 JDK。
• Java 2 Enterprise Edition（J2EE）：即 Java 企业版，是用来支持大型企业级应用开发 与运行的平台，以下简称 J2EE。
• CORBA 对象是一个抽象意义上的对象，可看作一个具有对象标识、对象接口以及对象 实现的抽象实体。它之所以被称为抽象的，是因为并没有硬性规定 CORBA 对象的实现机制。
• 伺服对象（servant）则是指具体程序设计语言的对象或实体，通常存在于一个服务程序 进程之中。
• 一些 ORB 产品提供了专门的编译器以简化这一过程，例如 VisiBroker for Java 提供的编译器 vbjc 会自动调用 JDK 中的 Java 编译器 javac，指示 javac 在编译客户程序的同时编译相关的客户程序桩（stub）文件，在编译服务程序的同时编译相关的服务程序框架文件（skeleton）
• VisiBroker for Java 提供的 idl2java 编译器将 IDL 映射到 Java 语言，生成 Java 语言的客户端桩代码以及服务端框架代码，桩和框架可看作分别是服务对象在客户端和服务端的代理。
• 接口定义之间的区别：
• 同步方式：调用时调用者会阻塞直到被调用的服务完成并返回。
• 异步方式：调用者发起调用后不会阻塞，等待服务完成期间可以执行其它操作，调用者通过轮询方式或服务者发送的事件检测调用完成，服务完成后调用者检查并处理结果。异步方式通常依靠异步消息来实现。
• 单向方式：调用者只是发出调用请求，并不关心调用什么时候完成（以及完成的结果）。
• 当服务端对象数量很多时，在内存中保持所有对象会导致占用大量内存。给出一种合理的利用伺服 对象激活器有效管理大量对象的设计方案，实现服务端内存的有效利用？
• 说明伺服对象激活器如何与活动对象映射表协同工作。 
• CORBA 支持在可互操作性主要包括：
• 采用直接桥接方式时，需交互的元素直接转换为两个域的内部表示，这种桥接方式具有较快的传输速度，但在 分布式计算中缺乏通用性。
• 采用间接桥接方式时，需交互的元素在域的内部表示形式与各个域一致认可的另一种表 示形式之间相互转换，
• 静态方式通过由IDL生成的框架
• 动态方式 使用动态框架接口DSI（Dynamic Skeleton Interface）
• OMG 发布的有影响力的两套规范，一个是 UML（Unified Modeling Language），统一建模语言；
  • UML 是一套面向对象分析与设计阶段的表示技术规范
• 另一个就是 CORBA（Common Object Request Broker Architecture），通用对象请求代理体系结构。
  • CORBA 是一套面向分布式系统的中间件规范，一套开放式的规范，工业标准
• 中间层：分布对象实现，向客户端提供服务，创建并注册分布对象实例
• 服务程序：Java RMI，完成真正提供服务的分布对象的创建与注册，服务程序中的真正提供服务的对象实例通常又称为伺服对象（servant）
• 客户端程序，利用服务完成查询功能。
• 使用存储过程访问数据库还可带来其他好处，例如提高了 SQL 语句查询与更新数据库的效率，在网络环境下加强了数据库的安全 性等等。
• 基于 OMG（Object Management Group，对象管理组织）CORBA 规范的集成中间 件
• 基于 Sun JEE（Java Enterprise Edition，Java 企业版）规范的集成中间件
• 基于微软.NET 架构的集成中间件
• 中间件提供的支撑：
  • 提供构件运行环境 ：1、管理构件生命周期、实例、元信息
  • 提供互操作机制：1、开发人员在开发调用分布式对象时，不需要自己编写底层通信代码。2、高层通信协议屏蔽物理特性和异构性。
  • 提供公共服务（现有集成中间件将早期各种中间件中针对分布式软件的通用支持集成于一身，以公共服务的形式提供给应用程序）
    • ①命名服务；②事务服务；③安全服务；④持久性服务；⑤消息服务；⑥分布式垃圾 回收服务；⑦资源管理服务
• 抽取软件的共性成分
• 屏蔽系统低层的复杂度
• 在高层保持复杂度的相对稳定，往往导致新型系统软件的产生
• 三层结构中，中间层向数据库服务器请求，客户层向中间层发出服务器请求。将业务逻辑代码移到中间层来，改善可移植性和可靠性，业务逻辑代码和用户界面代码相对独立，提高可维护性，中间层变成了软件系统的核心。