J2EE 和分布式处理技术

第 4 章 JSP 与 J2EE 分布式处理技术

在Java 平台上 有三大分布式处理技术 其一就是我们前两章所介绍的 EJB 组件技术 除此之外 就是CORBA 技术(for java)和 RMI 技术 在本章中 我们将简要介绍 CORBA 和RMI 应用的基础知识及开发方法 并试图把它们和 JSP 技术结合起来 编写功能强大的 应用程序

本章需要重点掌握的内容有

z J2EE 平台的结构

z RMI 模型的开发方法和应用

z CORBA 的结构模型 开发方法和应用

z JNDI 技术简介

4.1 J2EE 和分布式处理技术

4.1.1 J2EE 体系结构

近来的一段时间 J2EE 这个词似乎十分热门 相信有很多读者都对 J2EE 技术不甚了 了 那么什么是J2EE J2EE 是 Java 2 Enterprise Edition 的缩写 意为 Java 2 平台企业版 J2EE 是一种利用 Java 2 平台来简化诸多与多级企业解决方案的开发 部署和管理相关的复 杂问题的体系结构 J2EE 技术的基础就是核心 Java 平台或 Java 2 平台的标准版(简称为 J2SE) J2EE 不仅具有了 J2SE 中的许多优点 例如“编写一次 到处运行”的特性 访问数 据 库 存 取 数 据 的 JDBC API CORBA 技术等等 同 时 还 提 供 了 对 EJB Enterprise JavaBeans JMS JTS Java Servlet API JSP 以及 XML 技术的全面支持 J2EE 平台的 Servlet RMI JDBC 和 Java IDL 等强大的分布式计算技术使 Java 具备了在企业计算中一 展身手的能力 一般认为 现代的企业计算解决方案除了企业的业务逻辑 business logic 外 还需要提供对8 种基本服务的支持 这些服务分别是

1 命名/目录服务 Naming and Directory Service 在企业范围内的信息共享 包 括计算机 用户 打印机 应用程序等所有资源 过程中 名/目录服务扮演着重要的角色 它维护着名字和实际资源之间的连接关系 以便使用者能通过名字实现对实际资源的透明 访问 在一个大型的企业中可能有多种命名/目录服务并存 如何将所有的命名/目录服务在 现有的计算架构完整地统一起来 以便让应用程序透明地访问所有的命名/目录服务 就成 了企业计算解决方案必须解决的问题之一

2 数据访问服务(Data Access Service) 大部分的应用都需要访问数据库 企业计算 解决方案必须提供一种统一的界面对所有的数据库进行访问

3 分布式对象服务(Distributed Object Service) 在一个分布式的环境中 构成整个 应用的所有组件可能位于不同的服务器上 这些组件通常通过CORBA 进行互联 在企业 计算环境里必须提供一种统一的方法访问这些组件 以保护企业的投资



第 4 章 JSP 与 J2EE 分布式处理技术

4 企业管理服务(Enterprise Management Service) 在任何分布式环境中 管理都是 一个关键的需求 需要应用程序提供远程管理的能力 以防止出现非法操作和访问以及对 设备 应用程序状态的管理

5 事务处理服务(Transaction Processing Service) 一些关键部门在日常工作中有大 量的事务处理 事务处理的开发是一件极其复杂的工作

6 消息服务(Messaging Service) 在一些企业 特别是一些对同步传输要求不高的 企业通常采用消息机制在应用程序之间进行通讯

7 安全服务(Security Service) 应用程序的安全性是任何企业都关心的焦点之一 任何企业计算解决方案都不能回避

8 Web 服务(Web Service) 大部分企业级应用都以 Web 服务器为中心 Web 服务 成为企业计算解决方案的重要组成部分之一

为了实现上述服务 在J2EE 平台中 包含了若干个新的 API 与这些服务一一对应 J2EE 的重要组成部分如下所示

z JDBC(Java Database Connectivity)提供了连接各种数据库的统一接口

z EJB(Enterprise JavaBeans)使得开发者方便地创建部署和管理跨平台的基于组件的 企业应用

z Java RMI(Java Remote Method Invocation)用来开发分布式 Java 应用程序 一个 Java 对象的方法能被远程Java 虚拟机调用 这样 远程方法激活可以发生在对等的两 端 也可以发生在客户端和服务器之间 只要双方的应用程序都是用Java 写的

z Java IDL(Java Interface Definition Language) 提 供 与 CORBA(Common Object Request Broker Architecture)的无缝集成 这使得 Java 能够集成异构的商务信息资 源

z JNDI(Java Naming and Directory Interface)提供从 Java 平台到系统的无缝连接 这 个接口屏蔽了企业网络所使用的各种命名和目录服务

在一个企业内部往往多种命名/目录服务并存 如何将它们统一起来 以使企业在 开发应用程序时能忽略各命名 目录服务之间的区别而透明地访问这些命名 目 录服务 成为企业需要考虑的问题 JNDI 技术解决了这一难题 JNDI 技术命名 目录服务本身的特性出发提出了一些统一的访问名 目录服务的界面 由各命 名 目录服务开发商对这些界面加以实现 使用者就可以通过这些统一的界面去 访问底层的各种服务 因此在JNDI 技术中其实存在两种角色 一个是 JNDI API 另一个是JNDI SPI( Service Provider Interface) SPI 是各命名 目录服务开发商对 JNDI API 的实现 以便用户通过 JNDI API 访问他们所提供的服务

通过JNDI API 开发人员只要了解 JNDI 就可以开发适用于所有实现了 JNDI 的命 名/目录服务的应用 保证了应用程序的可移植性 且免去了大量的学习精力

z JMAPI(Java Management API)为异构网络上的系统 网络和服务管理的开发提供一 整套丰富的对象和方法 JMAPI 是一组与协议无关的 API 开发的应用不但可以 在不同的硬件平台上运行 而且适用于多种网管协议

z JMS(Java Message Service)提供企业消息服务 如可靠的消息队列 发布和订阅通 讯 以及有关推拉(Push/Pull)技术的各个方面



第一部分 JSP 技术与 J2EE 技术

消息机制在一些异步传输系统中被普遍使用 同JNDI 服务相似 市场上有许多命 名 目录服务产品实现这种应用 如Tibco MessageQ 等 JMS 将这些所有的产 品统一于一个界面 且获得了大量的中间件厂商的支持 包括BEA System Etsee Soft IBM MQSeries Novell 和 Sybase 等在内的中间件厂商都已宣称要实现 JMS 有的如Etsee Soft BEA WebLogic 已经实现

z JTS(Java Transaction Service)提供存取事务处理资源的开发标准 这些事务处理资 源包括事务处理应用程序 事务处理管理程序

短短的几年多时间 Java 已经从当初只能开发 applet 等小小的应用 发展到今天 在企业计算中的大量运用 相信随着Java 技术的进一步发展 一定会有越来越多 的企业受益于Java 技术革命带来的好处

z JSA(Java Security API) 企 业 计 算 的 安 全 性 主 要 体 现 在 4 个 方 面 认 证 Authentication 授权(Authorization) 信息在传输过程中的完整性(Integrity)和私 有性(Privacy) Java 2 平台提供了包括公钥 public key 加密 数字签名 DSA 等功能在内的加密框架 实现各加密功能 以保证Java 计算的安全性

综合JTS JMS JNDI 等 API 的特点可以发现 J2EE 平台所包含的 Java Enterprise API 不是自己去重新开发实现这些应用系统 而只是在这些产品之上又增加了一个抽象层 以 此来提升Java 和各类应用软件在企业中的应用 保证了用 Java 开发的企业计算应用能够在 多种平台上运行

4.1.2 目前流行的分布式计算解决方案

目前市场上流行的分布式计算解决方案除了EJB 技术之外 还有 CORBA 技术 RMI 技术 微软的COM/DCOM 技术了 在这一小节中 我们就对这 3 种解决方案做一个简单 的对比 首先是CORBA 技术

CORBA 技术

CORBA 构件模型的底层结构为 ORB 一个 CORBA 构件采用 IDL 进行描述 CORBA 提供了IDL 到 C C Java COBOL 等语言的映射机制 IDL 编译器 IDL 编译器 可以生成 Server 方的 Skeleton(框架) 和 Client 方的 Stub(存根)代码 通过分别与客户端和 服务端程序的联编(指的是 Stub Skeleton 代码分别与客户端程序 服务端程序的联编) 即 可得到相应的Server 和 Client 程序

CORBA 提 供 了 一 系 列 的 公 共 对 象 服 务 规 范 COSS(Common Object Service Specification) 其中包括名字服务 永久对象服务 生命周期服务 事务处理服务 对象事 件服务和安全服务等 它们相当于一类用于企业级计算的公共构件 此外 CORBA 还针 对电信 石油等典型的应用行业提供了一系列的公共设施

CORBA 是一种语言中性的软件构件模型 可以跨越不同的网络 不同的机器和不同 的操作系统 实现分布对象之间的互操作

CORBA 有几个基本的优点 与开发语言无关的独立性 与开发者无关的独立性和与 操作系统无关的独立性 CORBA 的 ORB 在当前每一种主流操作系统上均有实现 (仅就 Microsoft 的各种操作系统来说 CORBA 获得的支持甚至超越了微软自己推荐的 DCOM 模



第 4 章 JSP 与 J2EE 分布式处理技术

型) 除此之外 CORBA ORB 可以访问多种语言实现的对象 包括 C++ COBOL Smalltalk 和Java 借助于CORBA 的 IIOP 协议(CORBA’s Internet Interoperability Protocol) 某一开 发者 比如说我 开发的CORBA ORB 能够获取并操作存在于远程机器上的由其他的开发 者 比如说你 开发的分布式对象 Java ORB 允许客户端在没有安装任何特别软件的情况 下实现Java 客户端应用程序 Java ORB 的类可以像 Java Applet 一起动态下载 也可能与 浏览器捆绑在一起

DCOM 技术

目前 Microsoft 的分布式组件对象模型 DCOM Distributed Componont Object Model 仅运行于Windows 操作系统之上 Microsoft 正在与第三方开发商协作 以将 DCOM 移植 到其它的操作系统上(包括 MVS 和几种 UNIX 操作系统) 像 CORBA 一样 DCOM 是独立 于语言的 它用Microsoft 的对象描述语言 ODL)通过接口对对象加以描述

与CORBA 相比 DCOM 有三个重大缺点 首先 它由单一开发者(微软)定义并控制 这大大限制了DCOM 使用者的选择范围(比如 DCOM 开发工具) 其次 DCOM 缺乏众多 的平台支持 这极大程度地制约了代码的可重用性和 DCOM 应用的可扩展性 最后 与 CORBA 相比 DCOM 是一种相对不十分成熟的技术 尽管微软目前正为 DCOM 加入消 息和事务支持 但这些功能在1994 年的 CORBA 2.0 就已经实现了 并且正由几家不同的 CORBA 软件开发商所发行

为了使得应用程序能够访问服务端的DCOM 对象 开发者不得不使用 Internet Explorer 浏览器和 Windows 平台 只有这样才能支持 DCOM 的客户端程序 这样的限制当然削弱 了 DCOM 客户端应用程序的可用性 而另一方面 DCOM 的一个重大优势在于 对 Microsoft Windows 的用户是免费的 DCOM 的发展经历了一个相当曲折的过程 DCOM

为了使得应用程序能够访问服务端的DCOM 对象 开发者不得不使用 Internet Explorer 浏览器和 Windows 平台 只有这样才能支持 DCOM 的客户端程序 这样的限制当然削弱 了 DCOM 客户端应用程序的可用性 而另一方面 DCOM 的一个重大优势在于 对 Microsoft Windows 的用户是免费的 DCOM 的发展经历了一个相当曲折的过程 DCOM