您当前的位置：首页 > 阅读中心 > 软件学习

解析J2EE应用体系

时间：2014-05-04 10:05:30 来源：不详作者：佚名

　本文比较全面地介绍了
各种组件及其适用场合、J2

与J2EE应用开发有关的各种基本
EE基础服务、J2EE客户端类型等

概念，包括多层应用体系、容器、
。

　　J2EE多层应用体系

　　J2EE可以理解为一个企
接起来，为构造和管理、运
境。从物理上看，J2EE环境
式组件的形式部署到网络上

业级的中间件体系或平台，它把
行可伸缩的企业级业务应用提供
可分布驻留到一个以上的服务器
的一个或者多个服务器。

多种分散到网络上的资源和应用连
了一系列的应用组件和一个运行环
，单一的业务应用能够以一组分布

　　要理解J2EE，就必须掌握下面几个支撑起J2EE体系的核心概念：

　　· J2EE n-tier应用体

系：或称为J2EE多层应用体系，

J2EE平台提供的基本应用架构。

　　· J2EE应用组件：构造J2EE应用的基本软件单元。

　　· J2EE企业服务：可被J2EE应用组件调用的公共服务功能。

　　· J2EE容器：J2EE组件的运行环境。

　　J2EE中间件体系定义了四个独立的层，应用软件就构造在这个框架上，它们是：

　　· 客户层（Client tier）。

　　· 表现逻辑层（Presentation logic tier）。

　　· 业务逻辑层（Business logic tier）。

　　· 企业信息系统层（EIS，Enterpri

se information systems tier）。

　　如图一所示:

　　图一

　　表现逻辑层和业务逻辑层属于应用服
现。这四层中的每一层都可以在物理上分
辑层和业务逻辑层，也可以驻留在不同的
辑的容器可以使用Sun公司的J2EE应用服
J2EE应用服务器Weblogic。

务器领域。所谓应用服务器，也即J2EE平台的具体实
布到多个机器，即使同属于应用服务器领域的表现逻
应用服务器上。例如，在一个应用中，HTTP和表现逻
务器iPlanet，部署业务逻辑组件可以用BEA公司的

　　按照习惯，表现逻辑层
解，可以把J2EE多层体系中
计；与此相对，把容器理解
。

总是与JSP容器相关，业务逻辑
的“层”理解为一种概念实体，
为一种物理性的软件实体，容器

层总是与EJB容器相关。为便于理
引入“层”这个概念是为了简化设
的目标是为应用组件提供运行环境

　　不同层次的J2EE应用组件驻留在它们
的容器。容器是遵从一定接口标准的产品
标准编写好应用组件之后，还要用厂商专
准定义了四种不同的容器：

各自的运行环境中，这些运行环境就是J2EE术语所谓
，为J2EE组件提供了必需的底层基础功能。按照J2EE
有的部署工具把它们分别部署到各自的容器。J2EE标

　　· Applet容器：运行和管理Applet。

　　· 应用客户端容器：运行和管理标准Java应用客户程序，包括Swing应用。

　　· Web容器：运行和管理表现逻辑层的Servlet和JSP组件。

　　· EJB容器：运行和管理业务逻辑层的EJB。

　　为了提供静态HTML页面
前几乎所有流行的J2EE应用

服务，随同Web容器提供一个HTT
服务器都有内建的HTTP Web服务

P Web服务器是很典型的做法，目
器。

　　一般地，容器提供的基
缩性、负载平衡和故障转移
实现完全由容器厂商自己决
厂商的专有代码留下了自由
，容器功不可没。

础功能包括内存管理、线程/同
等。容器必须实现的基本接口和
定。因此，J2EE既确保了不同应
空间。实际上，在中间件产业，

步机制、垃圾收集、可用性、可伸
功能由J2EE规范定义，但具体如何
用服务器之间的兼容性，又为各个
各路厂商之所以得以施展各自神通

　　J2EE多层体系的思想在
Model-View-Controller，
围的设计模式。在MVC设计
的部分；View即视图，主要
设计模式认为这些不同的部
器）协调。

很大程度上受到了MVC设计模式
它是一种在复杂的应用系统中划
模式中，Model即模型，是处理
与用户界面有关，例如把处理结
分应该尽可能地相互独立，它们

的启发和影响。所谓MVC，即
分和界定各个组件的职能和作用范
核心数据模型或实现核心应用功能
果提供给客户端或其他应用。MVC
之间的交互则由Controller（控制

　　例如，考虑一个在Internet上传输银
可以分割成四个独立的任务：

行帐户信息的过程。按照MVC的设计思想，这个过程

　　· 任务1：从浏览器启动传输过程（View）。

　　· 任务2：发出对帐户传输操作的调用（Controller）。

　　· 任务3：实际完成帐户传输操作（业务过程或Model）。

　　· 任务4：把传输状态（成功或失败）显示给浏览器（View）。

　　MVC认为核心业务过程（任务3）不应
端是一个浏览器，因为除了浏览器之外，
；所有与客户端直接相关的操作应当由Vi
则专门由Controller部分负责。

该做任何有关客户端的假设，例如，它不能假定客户
其他的应用程序也应当能够顺利地调用核心业务过程
ew来完成。至于业务逻辑和表现逻辑的联系和协调，

　　J2EE体系建立在MVC设
分离出来，属于Controller
设计思想，J2EE为重用业务

计思想的基础上。很自然地，J2
性质的代码可以放在这两个层的
逻辑组件打开了广阔的空间。

EE体系也鼓励把业务逻辑从表现层
任意一个（或全部）。依赖于这种

　　J2EE应用组件

　　J2EE标准定义了一个完
在这个框架之上。几乎所有
都可以在此基础上构造。

善的应用组件框架，作为企业应
的业务应用，从简单的Web门户

用系统基本构造模块的组件就建立
到复杂的企业级分布式事务应用，

　　J2EE组件框架只是一个以库、类和接
表现/控制逻辑要由建立在这个框架上的
为例，为具体的业务应用构造的Servlet
者可以调用各种Servlet包提供的基本库
例如操作HTTP输入流读取数据和写入数据
基础架构叫做应用框架（Application Fr
应用组件（Application Component）。

口形式提供的基础架构，最终构成应用的业务逻辑和
应用组件实现。以J2EE提供的标准应用组件Servlet
总是建立在J2EE提供的基本Servlet接口之上，开发
和服务。许多系统级的服务都已经在这些库中提供，
，只需直接调用即可。因此，我们把J2EE提供的组件
amework），把建立在应用框架之上的代码叫做J2EE

　　如图一所示，无论是客户层、表现层还是业务逻辑层，都有相应的J2EE应用组件：

　　· 客户层：Applet，Javabean

　　· 表现逻辑层：Servlet，JSP，Javabean

　　· 业务逻辑层：EJB

　　必须指出的是，除了上
好地运行。在许多场合，我
EIS即Enterprise Informat
对于EIS资源，我们要做的
EIS层没有应用组件的位置
到各自的容器。

述J2EE组件之外，标准的Java类
们可以找到代码以普通Java类而
ion System，它包含所有的企业
只是从组件访问它们，访问细节
。开发J2EE应用就是开发一种或

和Jar包也可以在所有这些层上很
不是J2EE组件状态存在的情形。
后端资源，例如数据库等。显然，
则由J2EE企业服务解决，所以在
者多种上述组件，然后把它们部署

　　组件的接口确保组件遵
J2EE环境提供了基础。应用
可重用性。对于给定的业务
富有艺术性的工作。由于组
富的知识和经验来确定组件
中应当担负的角色，从而为
务器领域，各种组件的主要

从一定的标准并向外界提供公用
组件在各个层之间宽松结合，确
情形，适当地选用和搭配各种应
件的种类繁多，要想得到优质的
的最佳搭配方案。对于每一种应
合理设计应用体系提供了坚实的
特点，请参见图二。

功能，从而为具有良好互操作性的
保了组件互操作的灵活性和组件的
用组件是J2EE应用体系设计中一项
代码和表现出色的应用，就要有丰
用组件，J2EE明确定义了它在应用
基础。下面我们就来看看在应用服

　　图二

　　注意以下几点：

　　· Web容器和EJB容器是不同的，两
器都可以使用企业服务。也就是说，无论
email服务、目录服务和消息服务。组件
的企业服务访问EIS资源。

者相对独立，可以是来自不同厂商的产品。这两种容
是Web容器的组件还是EJB，都可以访问数据库连接、
只能通过一个或者多个以驱动程序或适配器形式实现

　　· 最好把所有应用组
J2EE模型中，用户自定义的
属于标准J2EE应用服务器的
文件工具库就是一个很好的
符串的形式返回指定的配置

件频繁调用的用户自定义服务和
服务和库被合并到“自定义组件
一部分，一般它们会随着软件项
例子：它根据指定的配置文件名
选项。

库集中到一个独立的层。在图二的
库”。这些库由用户自己开发，不
目的成熟而日渐丰富。例如，配置
字，打开该文件，然后以整数或字

　　· 另一种常见的现象是，开发者在J
例程。把这些自定义的服务访问例程组织
设我们在一个项目中用IBM的MQ Series作
问MQ Series服务的简单API，例如给所有
些服务整理成“服务访问库”层的公用AP
之，服务访问库提供了J2EE API上的一层

2EE提供的核心企业服务的基础上编写自定义的访问
成一个单独的“服务访问库”层是值得的。例如，假
为消息系统。通常，我们会编写一些在JMS基础上访
外发的消息加上企业标准的消息头。这时，最好把这
I，并让它们可被企业平台的所有应用调用。简而言
抽象，它们总是与特定的企业应用平台密切相关。

　　如前所述，在复杂的企
来看看具体情况。

业计算环境中，不同的J2EE组件

应当担负不同的角色。下面我们就

　　Web容器组件:

　　· Servlet

　　Servlet是服务器端面
的功能，Servlet扩展了Web
生成动态内容的功能。

向表现逻辑的组件，驻留在Web
服务器的功能——除了提供静态

容器内。正如Applet扩展了浏览器
HTML之外，Servlet还提供编程和

　　Servlet能够处理来自客户端浏览器
式发送到客户端浏览器上显示出来。例如
户端浏览器接收用户名字和密码，处理请

的请求，处理输入参数，把处理结果以HTTP应答的形
，Servlet可用来开发基于Web的简单认证系统，从客
求，再发回认证通过或不通过的应答。

　　除了接受来自客户端浏
Servlet本身也能够生成发
长一些。

览器的请求之外，Servlet还能
送给客户端的HTTP应答流，但是

够响应其他Servlet的调用。虽然
，就显示处理结果来说，JSP更擅

　　· JSP

　　JSP即Java Server Pages，它也是面
之内。但无论在适用场合还是功能方面，
混合物，即，JSP页面既能够包含HTML代
直接发送给客户端浏览器，而Java则被抽
签引入程序逻辑。

向表现逻辑的组件，与Servlet一样，驻留在Web容器
JSP与Servlet都有所不同。JSP页面是HTML和Java的
码，也能够包含Java代码。JSP页面中的HTML代码被
取出来由服务器处理。因此，JSP最适合于为HTML标

　　在JSP页面中，有一种结构化的、可
。JSP标记库开发方便，能够更清楚地隔

重用的引用Java代码逻辑的途径，即使用JSP标记库
离Java代码和HTML代码。

　　JSP是对Servlet的补充
计中，只使用JSP（并充分

和完善，经常用来显示Servlet
有效地结合运用Javabean）而不

的处理结果。但是，在一些应用设
使用Servlet的情形也很常见。

　　· Javabean

　　Javabean是基本的数据
Javabean常常驻留在客户端
Java代码如要成为Bean组件
并为这些变量定义了get_at
Javabean组件。

模型组件，在J2EE出现很久之前
或表现逻辑层，作为对Applet或
必须符合的条件。例如，一个简
tribute()方法和set_attribute

就已经被引入。在J2EE体系中，
JSP的补充。Javabean规范定义了
单的Java类如果定义了几个变量，
()方法，就可以认为是标准的

　　Javabean与EJB除了名称相似之外，
级Java应用组件。

没有任何其他相似之处。EJB是一种完全不同的企业

　　EJB容器组件:

　　EJB是分布式可伸缩的业务逻辑组件
型元素。EJB驻留在称为EJB容器的特殊环
了开发者编写的应用EJB与容器环境的关

，它们封装了企业Java工程的核心业务逻辑和数据模
境之内，EJB容器由应用服务器提供。J2EE规范定义
系（contract）。

　　开发EJB必须符合一定
EJB容器提供者（或应用服
求看成一种隔离业务逻辑实
径。

的接口要求，这些接口中的一部
务器厂商）实现。从某个方面来
现（开发者编写的方法）与应用

分方法由开发者实现，一部分由
看，我们可以把EJB的这种接口要
基础结构（容器实现的方法）的途

　　EJB组件可以与任意其
程服务器的不同容器之内。
库和服务访问库。

他EJB交互——不管对方是位于
EJB不仅可以调用所有的企业服

同一个容器之内，还是位于一个远
务，还可以调用所有的自定义组件

　　针对不同的应用情况，
态会话Bean、实体Bean、消

EJB规范定义了几种不同的EJB类
息驱动的Bean。

型，包括：无状态会话Bean、有状

　　结合运用EJB、 Servle
的应用体系。

t和JSP，可构造出一个具有高度

灵活性和可重用性的符合MVC特征

　　J2EE企业服务

　　J2EE环境以企业服务的
息和事务处理等。这些最基
操作系统一样，J2EE提供了
不尽相同，可能存在细微的
。

形式提供了支撑企业应用的各种
本的服务以接口、类库、驱动程
在各种服务之上的一个公共的Ja
差别，公共的Java接口使得应用

基石，例如邮件、数据库连接、消
序、适配器等形式提供。就像一个
va接口。各个底层服务的实现细节
的代码完全脱离了细节问题的纠缠

　　Web容器和EJB容器之内的应用组件通
和服务。这类资源和服务的范围相当广泛
大型主机访问，应有尽有。

过调用J2EE企业服务，来访问企业系统内可用的资源
，从简单的数据库访问到通过消息/CICS环境执行的

　　J2EE服务API在厂商私
录访问等，从应用的角度来
标准的API集，无需依赖于
间迁移。例如，从一个J2EE
常相似，只要按照数据库类
程序员根本不必进行任何代

有的服务之上提供了一层标准化
看，有效地隐藏了与实现有关的
面向具体资源、厂商的API，从
应用组件的角度来看，访问Syba
型改用相应的JDBC驱动程序和访
码级的修改工作，就能够方便地

的Java接口，例如数据库连接和目
细节。因此，应用开发者只需考虑
而方便了在多种不同的服务实现之
se数据库和Oracle数据库的方式非
问数据库的URL即可。也就是说，
访问不同的数据库。

　　JDBC

　　JDBC即Java DataBase
。JDBC API为所有公共的数
更新数据库。这些接口的具

Connectivity。通过JDBC API能
据库功能提供了一组标准化的接
体实现则由JDBC驱动程序负责。

够访问范围广泛的关系数据库系统
口，J2EE组件利用这组接口查询和

　　因此，应用程序的代码不牵涉到与具
种数据库通常可以很方便地完成。

体数据库类型有关的调用，从一种数据库切换到另一

　　JNDI

　　在分布式环境中，要寻
。网络上的各种资源用唯一
录服务获取一个指向目标资

找和识别分散到整个网络上的各
的名字绑定到分布式的分层树形
源的句柄。

种资源，就要用到名称和目录服务
目录结构中，客户程序通过访问目

　　JNDI（Java Naming and Directory
准，它在LDAP、Novell Directory Servi
上，建立了一个标准的服务层，使得J2EE
目录服务。

Interface）建立了访问企业级名称和目录服务的标
ce和Active Directory Service等具体的目录服务之
组件能够以一种一致的、标准的形式访问各种底层的

　　JMS

　　在异种系统的集成中，
服务扮演着至关重要的角色
双方分别安装一个消息服务
异步的形式通过网络把消息

例如把大型主机系统和其他传统
。在这些截然不同的异构系统之
进程。应用软件与消息服务进程
传递给其他消息服务进程。

系统连接到J2EE中间件组件，消息
间，建立通信链的关键就在于通信
交互，消息服务进程再以点对点或

　　JMS（Java Messaging
Rendezvous之类的消息服务
义了一个标准服务层，使得

Service）在诸如IBM的MQ Serie
系统之上，建立了调用标准，即
J2EE应用不再被绑定到实际执行

s、Microsoft的MSMQ和TIBCO的
在这些私有的消息API调用之上定
消息服务的私有实现上。

　　Javamail/JAF

　　顾名思义，Javamail API是为J2EE组
如SMTP和POP3）之上，统一对各种可能用
收邮件、附件处理等。

件提供e-mail服务的。它在具体的邮件服务实现（例
到的公共服务的访问形式，例如邮件格式、发送/接

　　JavaMail 要求 Java
数据类型，例如MIME。

激活框架（JAF，Javabean Acti

vation Framework）来处理复杂的

　　 RMI-IIOP/Java IDL

　　这两种技术支持J2EE组件和CORBA组
Broker Architecture的缩写，是OMG（对
经有多年历史。

件的相互通信。CORBA即Common Object Request
象管理组织）定义的一种著名的分布式应用框架，已

　　Java IDL是从J2EE环境访问现有CORB
供给CORBA客户程序。

A对象的推荐方法，但RMI-IIOP也能够将J2EE组件提

　　JAX

　　JAX即Java API for XM
提供的服务包括XML解析（
JAX API是以Web服务的形式
Web服务的基础。

L，是一种简化J2EE领域内XML文
包括SAX和DOM）、XML与Java对
提供J2EE业务逻辑组件的基础，

档使用的Java XML API。JAX API
象的绑定、XML消息和XSLT转换。
也是调用其他各种不同环境提供的

　　JCA

　　JCA即Java Connector Architecture
息系统的无缝集成，例如ERP、主机系统
就像其他服务API一样，JCA为各个厂商提
用服务器建立系统级连接协议，与访问EI

（Java连接器体系），支持J2EE中间件与现有企业信
、事务处理系统、数据库以及其他传统应用系统等。
供了开发资源适配器的空间，由资源适配器与J2EE应
S资源的应用组件建立应用级连接协议。

　　J2EE客户端

　　对于J2EE环境，客户访问的类型可总结如下：

　　访问EJB中的业务逻辑服务：这也许
的业务逻辑规则能够封装成宽松结合的EJ
。有的企业甚至专门制定了构造J2EE组件
识库或公用的EIS访问网关），由富有经
最佳的可重用性和表现。例如，银行的资
果这个服务以EJB的形式实现，就可以供
、Web银行、移动银行，等等。

是所有J2EE环境中最常见的客户访问形式。如果核心
B或其他Java组件，它们就可以在多个应用之内重用
和服务的长远规划（例如发展出全局性的业务逻辑知
验的分析师负责精心设计和监管业务逻辑模块，确保
金转移服务把资金从一个帐户划转到另一个帐户，如
不同类型的客户端重用——例如银行的内勤服务系统

　　访问表现逻辑服务：表现逻辑服务与
一般比较困难。但是，利用某些技术和设
离开来。典型的方案是使用XML和XSLT，
考虑前述资金转移服务，假设现在要在成
不论客户端是什么类型，要显示的数据都
体的显示方式则因客户端的不同而不同，
移动设备上肯定要用另一种简化的显示方
义信息）在分开的XSLT页面中定义，例如
容在服务器端或客户端以某一种方式结合

客户终端的类型关系密切，要在不同的应用之间重用
计方法，可以把“表现的内容”与“表现的方式”分
完全分离表现逻辑（XSLT）和内容（XML）。例如，
功执行该服务之后，发送一个回执和帐户余额信息。
是一样的（即资金划拨是否成功，帐户余额），但具
例如在Web页面上，可能要显示几幅装饰图形，但在
式。在这种场合，如果表现方式（图形、字体等的定
web.xsl、mobile.xsl等，然后让表现方式和表现内
，就可以成功实现两者分离的目标。

　　访问企业服务：有的时候，J2EE领域
在设计企业J2EE体系时考虑到了让外部应
们可以在J2EE企业email服务之上构造一
部的组件调用，还可以被所有其他需要发
据库访问调用可以集中到J2EE环境之内。
制和协调、利用。

之外的组件可能需要访问J2EE平台的企业服务。如果
用和组件访问，这种需求必然会更加明确。例如，我
个公共的网关，使得email服务不仅可被J2EE平台内
送和接收email的企业应用调用。类似地，所有的数
这种设计方案有助于改进对企业内各种基础服务的控

　　通过J2EE访问EIS服务：J2EE除了能
还能够作为一个中央控制器，支持对后端
者有许多应用不能直接访问EIS资源，通
端运行着Siebel CRM系统，客户通过消息
就可以在J2EE内利用JMS、EJB等技术，构
能够以一种一致的方式访问Siebel资源。

够把它自身的应用组件提供给不同类型的客户之外，
EIS资源的访问。如果后端的EIS系统庞大且复杂，或
过J2EE访问EIS服务更具有实用意义。例如，假设后
系统和Siebel适配器访问该系统提供的资源。这时，
造一个访问网关，使得各种Java客户程序和其他应用

　　能够调用J2EE服务的客
统的总体设计和构造。下面

户类型非常广泛。当然，实际可
列出了其中一部分：

支持的客户类型依赖于企业应用系

　　Web（HTML）客户端：
许多J2EE工程的最初阶段就
HTTP Web服务器。通过HTTP
Servlet最适合于接收客户

通过HTTP协议访问J2EE服务的客
是从Web门户的形式开始，所以J
协议将J2EE环境连接到Web/Inte
的请求并调用适当的业务逻辑，

户端。这是最常见的客户端类型，
2EE应用服务器常常带有内建的
rnet的组件包括Servlet和JSP。
JSP最适合于呈现处理结果。

　　· 设备客户端：利用J2ME、WAP等技

术，通过手持设备和移动电话访问J2EE服务。

　　· Applet客户端：浏览器或Applet
辑环境。与普通HTML页面相比，Java App
接调用EJB）。然而，把View和Controlle
有特别的原因，这种做法在实践中通常不
Model-View-Controller体系就越远，同
间开销也越大。在Applet内部，最好只执
到服务器端组件。

容器之内的Java Applet，能够直接访问J2EE业务逻
let要强大得多，能够调用描述业务逻辑的Bean（直
r的逻辑嵌入到Applet将使得Applet规模过大，除非
可取。嵌入Applet的代码越多，偏离
时，客户端下载Applet并在浏览器JVM内运行它的时
行一些客户端的验证工作，把其他所有处理工作转移

　　· 独立的Java应用客户端：和Apple
逻辑组件。独立的Java应用客户端能够通
的相互通信通过RMI实现，所以独立的Jav
需要访问EJB时，Java客户端首先通过JND
得句柄之后，客户端就可以开始调用业务
到不同J2EE服务器环境的不同EJB，访问

t一样，独立的Java应用客户端也能够直接访问业务
过Java RMI调用访问所有的业务逻辑组件。EJB之间
a应用客户端可以直接执行基于RMI的远程过程调用。
I查询分布式目录服务，获得一个指定EJB的句柄；获
逻辑代码了。由于EJB是分布式组件，即使对于分布
形式也是一致的。

　　· 其他服务器上的EJB客户端：运行
Java类或EJB）能够直接访问J2EE环境内
用统一的J2EE中间件平台，它们就可以互
着优秀的验证和授权机制——包括方法级
服务的同时，可以建立完善的访问控制体
EJB才能够访问指定的业务逻辑或服务。

在其他J2EE服务器或容器上的业务逻辑组件（普通
的EJB。例如，如果一家企业和它的合作伙伴决定启
相许可对方跨平台访问自己的业务逻辑组件。EJB有
的安全机制，因而，在不同的平台之间相互交换EJB
系。在这种场合，应当密切注意只有那些经过授权的

　　· CORBA客户端：驻留
。J2EE促进了与驻留在CORB
）能够把EJB描述成CORBA客
件，则可以使用RMI-IIOP调

在CORBA ORB环境内的CORBA应用
A ORB之内的CORBA组件的全面交
户程序眼中的CORBA对象；与此
用。

客户端通过远程IIOP调用访问EJB
互。Java接口定义语言（Java IDL
对应，如果需要从EJB访问CORBA组

　　· 传统系统作为客户端（ERP/CRM/
的传统系统也能够访问J2EE环境内的资源
常见的途径是通过消息系统。从这个意义
成是JMS客户端。如果传统系统提供了相

大型主机系统）：诸如ERP/CRM和大型主机系统之类
和服务。当传统系统作为客户端访问J2EE环境时，最
上说，对于J2EE环境，作为客户端的传统系统可以看
应的连接器，Java连接器体系（JCA）可能很有用。

　　· JMS客户端：JMS客户端是通过一
问J2EE的应用或组件。由于J2EE领域内与
新的EJB类型，即“消息驱动的Bean”（M
JMS的消息系统进行同步或异步的交互；
也能够提供有效的支持。

种或多种支持JMS的消息系统（如IBM MQ Series）访
消息系统密切交互的需求很大，所以J2EE引入了一种
essage Driven Bean）。消息驱动的Bean支持与基于
对于其他消息应用访问EJB容器内的业务逻辑组件，

　　· Windows客户端：用
EJB直接显露给Windows应用
。但是，随着.NET的出现，
途径的焦点转移到了厂商中

VB/VC ++等构造的Windows应用
的本机调用，人们已经对Java客
重心已经稍微偏离了CAS。现在
立的标准和Web服务技术上。

。在.NET框架出现之前，为了把
户服务（CAS）进行了一定的努力
，人们把寻找这两种环境最佳交互

　　· Web服务客户端：通过非厂商私有
最近，各种与Web服务有关的技术，诸如S
的认可和欢迎。任何组件或应用，只要它
就能够以Web服务的形式提供其服务。Jav
Processing）、JAXR（(Java API for XM
）、JAXM（Java API for XML Messaging
Procedural Call）等，推动了J2EE和Web

的技术，例如SOAP/WSDL和UDDI等，访问J2EE资源。
OAP、UDDI以及WSDL等，在企业计算领域受到了广泛
理解SOAP调用并把它的服务发布到UDDI之类的目录，
a的XML API，例如JAXP（Java API for XML
L Registries)、JAXB（Java API for XML Binding
）以及JAX-RPC（Java API for XML-based Remote
服务这两个环境的全面交互。

　　综上所述，不同类型的
J2EE业务逻辑组件，而非Ja
的业务逻辑。然后，随着.N
再困难。

客户都可以访问J2EE环境提供的
va的客户则必须通过企业消息服
ET的出现和Web服务的发展，Win

各种服务。Java客户能够直接访问
务或其他途径才能访问J2EE环境下
dows客户访问J2EE业务逻辑服务不

来顶一下

返回首页

推荐资讯

后牧工业区厂房1500平	现实的童话公主艾米·
科比专为大场面而生	“最美清洁工”原是《

相关文章

无相关信息

栏目更新

栏目热门