CSDN博客

img chensheng913

漫谈EJB

发表于2004/7/6 20:41:00  290277人阅读

     Java语言

    Java语言最早被称为Oak,它是为了实现嵌入式的消费类电子产品应用而产生的,它的作者是James Gosling。Ed Frank, Patrick Naughton, Jonathan Payne, Chris Warth在随后的几年时间中为Java语言加入了大量的特性,并把Java语言的目标做了一个重新的定位,定位于适合Internet的语言。

    Java语言是一种多用途的语言、并发的语言、以类为基础,面向对象的语言。它的设计尽可能的做到和操作系统是无关的,也就是Java所宣传的那句话:“一次编写,到处运行。”Java的设计参考了C和C++语言,因此熟悉C和C++的程序员对Java语言上手很快,而Java设计的原则是能够利用Java语言快捷的编写应用,所以我们可以发现,在Java语言中,并没有那些C和C++中的复杂的机制。最明显的就是C中被大量使用的指针,由于它的随意性,被Java以引用来代替了。而C++中的操作符重载、模板、泛型的特性也因为使用比较复杂,Java也不予采用。但是目前Java仍然不断的推出新的特性,以满足应用的发展。例如在新推出的JDK1.4中,Java语言就能够支持Assertment机制和Perl语言中最有用的正则表达式机制。

    Java语言主要由以下五种元素组成:标识符、关键字、文字、运算符和分隔符。这五种元素有着不同的语法含义和组成规则,它们互相配合,共同完成Java语言的语意表达。

    1:标识符。变量,类和方法都需要一定的名称,我们将这种名称叫做标识符。

    2:关键字。关键字是Java语言本身使用的标识符,它有其特定的语法含义。所有的Java关键字将不能被用作标识符。

    3:数据类型。Java有着不同的数据类型。比较值得一提的是字符串数据类型,字符串数据类型是用一对双引号括起来的字符序列,字符串数据实际上是由String类所实现,而不是C语言中所用的字符数组。每一个字符串数据将产生一个String类的新的实例,用户不必对字符串与类这个概念发生关系而感到担心,由于类的特性,你不必担心如何去实现它们,它们会自己照顾好自己,需要说明的是字符串在Java里作为类只是出于安全的考虑。

    4:运算符。任何语言都有自己的运算符,Java语言也不例外,如+、-、*、/等都是运算符,运算符的作用是与一定的运算数据组成表达式来完成相应的运算。对不同的数据类型,有着不同的运算符。 

    5:分隔符。分隔符用来使编译器确认代码在何处分隔。‘’‘’‘;’‘:’都是Java语言的分隔符。

    学习 Java 语言很简单,毕竟 Java 语言也只包含五十多个关键词(keyword)与几十个算符(operator),再加上 Java 语法(syntax)也很简单,所以一般人可以很快就学会 Java 语言。危险的是,很多人认为已经完全掌控 Java 语言,但其实对于内部的运作机制仍不能掌握,这些盲点有时候会让你无法完全掌控 Java 语言。克服这些盲点的方式是看「The Java Language Specification, 2nd Ed.」(没有中文版)来彻底弄懂 Java 程序语言,并看「Inside the Java Virtual Machine, 2nd Ed.」来彻底掌握 Java 虚拟机器的运作方式。学会了语言,并不代表就可以设计出好的对象导向系统架构。想要成为对象导向的专家,往往需要:(1) 多看相关的书,特别是 Design Pattern 和 Refactoring 的书。(2) 多观摩别人的程序(例如 Java API 的 design 与 implementation)(3) 多写程序。学会 Java 语言之后,还需要学会一些 API 才能写出有用的程序。Java 的 API 非常多,必须规划好一个学习路径,才不会在浩瀚的 API 大海中迷失。必备的 API 包括了:IO、New IO、Collection Framework、Network、RMI、JAXP... 等。至于其它的 API,就看你的需求而定,大致上分成:

* GUI 类:JavaBean -> Swing -> JavaHelp -> Java2D -> Image IO -> JAI -> Java 3D ...
* Enterprise 类:JDBC -> JDO -> Servlet -> JSP -> EJB -> JMS -> JTA/JTS...
* J2ME 类(这一类不是我的专长,无法提供学习顺序建议)

    Java语言通常都是根据Java虚拟机规范(The Java Virtual Machine Specification)中的定义,编译为字节码指令集和二进制格式。因此我们接下来就讨论Java虚拟机(JVM)

JVM

    我们已经谈过Java语言的语法类似于C和C++,但是摒弃了C和C++中复杂、疑惑和不安全的特性。Java语言最早是用来构建消费类网络设备的软件的,因此它要支持多主机的架构,并要求能够提供安全的软件组件。为了满足这些需求,编译好的代码就必须能够通过网络来传播,能够在任何客户端上运行,同时还要保证客户端是足够安全的。

    Java虚拟机是Java和Java 2 平台的基石。它能够保证Java语言和硬件、操作系统无关,保证编译后的代码最小,并保护用户不受恶意程序的攻击。Java虚拟机到底是什么呢。其实它就是一台不实际存在的计算机。和真实的计算机类似,它也有自己的指令集,并可以在运行环境中分配内存区域。使用虚拟机机制来实现编程语言并不是Java的创举,这已经是非常普遍的做法了,最著名的许你就莫过于UCSD Pascal的P-Code机。

    只要浏览器检测到目前所处理的Web文件内容含有一个Java Applet,浏览器将会为这个Java小程序另外开一个JVM,执行这个Java应用小程序。在JVM中执行的Java小程序可以得到充分安全的保护。如同我们上面所说,JVM是一个自给自足的作业环境,就像是一台独立的计算机一样。例如,在JVM运作的Applet,无法存取主机操作系统。优点是:

    1. 系统中立。Java应用程序可以在任何JVM中运作,不论该系统使用何种硬件、软件。

    2. 安全。正因JVM跟操作系统没有任何接触,Java程序很难损害到其它档案或应用程序。

    缺点是,由于在JVM运作的程序独立在操作系统之外,也就无法享受操作系统各项特殊功能。

    Java技术之所以在今天得到了如此广阔的应用,其中它的安全性是不能不提的。不同于其它技术(例如Microsoft的ActiveX)中安全性作为附加设计和补丁,Java从设计之初便考虑到了安全性。因此Java的安全性是在语言层次实现的。Java的安全性由下列三个方面保证:

    1、 语言特性(包括数组的边界检查、类型转换、取消指针型变量)。

    2、 资源访问控制(包括本地文件系统访问、Socket连接访问)。

    3、 代码数字签名(通过数字签名来确认代码源以及代码是否完整)。

    Java的源代码是先编译成为一种字节码的中间代码,存放这种代码的文件就是.class的文件。真正执行的时候是将class文件装载到JVM(虚拟机)中,然后由JVM解释执行的。所以数组的上下界检查及合法的类型转换是通过JVM得到保证的。Java通过一个类装载器类(ClassLoader)将虚拟机代码文件(即class文件)装载到JVM中,当完成装载后,一个被称做安全管理器(SecurityManager)的类开始运行,例如当一个Applet的class文件被缺省的类装载器装载到JVM中后,JVM会立即为它装载一个SecurityManager的子类AppletSecurity,由这个管理器来验证操作。代码的所有动作(例如文件读写)都要先经过验证,只有被该安全管理器接受的动作才能完成,否则就会抛出SecurityException异常。

    对于JDK1.0,权限被笼统的划分为两大块。一是拥有所有的权限,一个是仅拥有"沙箱//"(sandBox)权限,这也是普通的Applet所拥有的权限。这时本地文件读写或是与源主机(Orignal Server)以外的主机连接都是被禁止的。这种划分的最大问题就是缺乏灵活性。例如我们希望一个Applet在用户信任的情况下能够对本地文件系统的某个目录进行读写,但并不要通过Socket与其它主机连接。这是JDK1.0的权限划分就不能达到要求。JDK1.1后改进了权限的划分,引入了权限集(PermissionSet)的概念。

    由于我们的文章并不是讨论JVM,因此,我们只是对JVM做一个简单的介绍。如果需要详细了解的,可以参考『The JavaTM TMVirtual Machine Specification』。

客观的看待Java

    相对于其他编程语音,Java有一个无庸置疑的优点:用户以及编译器第一次不必了解生成可执行代码的特定CPU细节。Java引入了一个编译代码中间层,叫做字节代码,并使用一个虚拟抽象的机器,而不是一个真实的机器。当Java编译器结束了一个源文件的编译后,你所得到的不是可以立即在一个给定平台上运行的代码,而是可以在任何真实的平台上运行的字节代码,唯一的条件就是这个平台要理解和支持Java。这些发展包含着一个文化的变革。作为一个开发人员,你只需要确定Java虚拟机(JVM)提供的抽象层,不同的OS销售商负责执行代码层,从而将中立于平台的字节代码映射到主机平台的机构中。在这种情况下,Java似乎是统一分布式计算机世界的领袖候选人了。“编写一次,永远运行”(并且无论在哪里)就成为Java诱人但却真实的口号。

    但我们平心而论,Java的跨平台并不是一个非常诱人的特性?跨平台理论的发展很好地证明了这一点。我们看到,将Java代码从一个平台移植到另一个平台—Java这个语言最重要和最受吹捧的特点—并不象宣传的那样容易。任何Java平台都有其自己的虚拟机,它可以理解通用的字节代码,并且及时地将其编译为本地代码。矛盾由此产生,不同虚拟机的执行也很不相同,这一点足以使代码的移植比预期耗费多得多的时间,而且基本上不是自动的。在企业用户的角度上来说,也很少会有企业会频繁的更换平台,因此这个特性是否能够带来高价值是很难评价的。

    那么,Java模型的好处在哪里呢?首先,Java是一种先进的、面向对象的语言,包含了预防常见错误的内置功能,并在仅仅一两个对象中携带了许多经常需要用到的功能。与C++相比,Java更易于读写,不容易出错,而且更加美观,但是它速度较慢也不太灵活。想实现在任何软件和硬件平台上都可虚拟移植,Java尽可能少地使用了公分母模型,也就是说放弃了将每个平台开发到极限的能力。第二,虚拟机的概念本身就是可移植和可共用的,因此对于分布式环境来说是理想的。Java对于为非Windows平台开发代码是最好的语言。

    那么对于Windows平台来说,Java又怎么样呢?让Java适应Windows是不可能的,这是由于Sun的许可约束问题。但是Java实在是太吸引人了,Microsoft比谁都能更清楚这一点。Microsoft在以前推出的Visual J++证明了这一点,但是可惜的是,Microsoft又犯了霸权的老毛病,Visual J++并不好用。因此,Microsoft又一次采取了“拿来主义”的手法,很好地利用了Java 的众多特性,隆重推出了Windows平台的新锐力量,它就是相当简单但十分强大的面向对象的C#编程语言。C#超过了C++,它天生就包含了.NET框架类库中的所有类,并使语法简单化。说到这里已经有一些离题了,不过Java也不是说在Windows平台上就不能够使用,JDK和大部分的IDE都支持Windows平台。

Java技术的架构--J2ME、J2SE和J2EE

    通常我们以 JDK(Sun 所开发的一套 Java 开发工具)的版本来定义 Java 的版本。JDK 1.0 版于 1996 年初公开,JDK 1.1 版于 1997 年初公开,JDK 1.2 版于 1998 年底公开。基于市场行销的考量,Sun 在 JDK 1.2 版公开后旋即将 Java 改名为「Java 2」,将 JDK 改名为「Java 2 Software Development Kit(以下简称 J2SDK)」。J2SDK(原称 JDK)1.3 于 2000 年 4 月公开,此版本仍称做「Java 2」。目前 J2SDK 1.4 也已经公开了,大家可以到Sun的官方Java站点上查阅到大量的JDK1.4的信息。

    Java 技术根据硬件平台与适用环境的差异,分成几个分支。JDK 1.1 的时代,适用于一般消费性电子产品等,嵌入式系统的 Java 平台是 PersonalJava 与 EmbeddedJava,此二者并无明确的界线,大致上来说,运算资源、内存、以及显示装置比较丰富者,使用 PersonalJava,例如 Set-Top Box、视讯电话 ... 等;反之,资源较有限者使用 EmbeddedJava,例如呼叫器、行动电话 ... 等。除了 PC 使用的 Java 平台、IA 使用的 PersonalJava 与 EmbeddedJava 平台之外,JavaCard 也是一个 Java 平台,使用于 Smart Card(IC Card)上。

    Java 2 出现后,推翻了先前的 PersonalJava 与 EmeddedJava 的分法,改分成 Java 2 Platform Enterprise Edition(简称 J2EE)、Java 2 Platform Standard Edition(简称 J2SE)、Java 2 Platform Micro Edition(简称 J2ME)。J2EE 适用于服务器,目前已经成为企业运算、电子商务等领域中相当热门的技术;J2SE 适用于一般的计算机;J2ME 适用于消费性电子产品。除了这三者之外,JavaCard 依然是独立的一套标准。

    目前,Java技术的架构包括三个方面:

    J2EE(Java 2 Platform Enterprise Edition )—企业版 (J2EE) 是为面向以企业为环境而开发应用程序的解决方案。
    J2SE(Java 2 Platform Stand Edition)—标准版 (J2SE) 为桌面开发和低端商务应用提供了可行的解决方案。
    J2ME(Java 2 Platform Micro Edition )—小型版(J2ME)是致力于消费产品和嵌入式设备的最佳解决方案






    J2EE

    J2EE已经成为开发商创建电子商务应用的事实标准。正是认识到J2EE平台作为一种可扩展的、全功能的平台,可以将关键的企业应用扩展到任何Web浏览器上并可适合多种不同的Internet数据流、可连接到几乎任何一种传统数据库和解决方案、使企业经理根据多家企业所提供的产品和技术开发和部署最佳的解决方案进而降低开发网络化应用的费用和复杂性这一巨大优势,很多厂家都表示将对J2EE给予支持,并将J2EE技术作为大型BtoB市场和海量交易处理的安全稳定的端到端平台。J2EE技术的基础就是J2SE标准版,它巩固了标准版中的许多优点。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。它为灵活配置各种多层企业应用软件,特别是B2B、B2C等电子商务应用,提供了强大的服务功能。最近又新加了Connector API服务,使企业应用的开发和部署有了一系列成熟的技术。

    J2SE

    J2SE是Java 2平台的标准版, 它适用于桌面系统,提供CORBA标准的ORB技术,结合Java的RMI支持分布式互操作环境。它运行在Java虚拟机上。在引入了Java IDL后, J2SE支持IIOP通信。它是高可移植性、异构性的实现环境和健壮平台,也是实现可伸缩性、可移植性、分布式异构互操作应用软件开发的标准平台。 

    J2ME

    J2ME提供了HTTP高级Internet协议,使移动电话能以Client/Server方式直接访问Internet的全部信息,不同的Client访问不同的文件,此外还能访问本地存储区,提供最高效率的无线交流。J2ME是Java 2平台的微型版,它分成CDC(connected device configuration)和CLDC(connected limited device configuration)两部分。CDC运行在连接虚拟机上,为手提式计算机一类较复杂的移动设备提供应用平台;CLDC运行在核心虚拟机(KVM)上,它实现MIDP(Mobile Information Device Profile)移动信息设备应用平台,即针对手机之类的设备建立移动计算平台。 

    在小型的J2ME(Java 2 Micro Edition)方面,主要是应用在内存容量小、体积也较小的电子装置上。小至智能卡、行动电话,个人数字助理都是运用J2ME的最佳平台。Java在Palm的应用上,PalmOS 4.0内含KJava,Sun也推出针对PalmOS使用的J2ME版本。所以,以既有的Java程序设计知识,就可以在Palm PDA上开发出Palm的各式各样应用系统。Java和Palm这两个标准平台的结合,将是下一波PDA应用的趋势。Java在手机的应用上,Nokia、Motorola、Ericsson 都将推出利用J2ME技术的新手机,所以Java程序设计师有更多的平台可供施展。此种结合J2ME及无线通讯技术的无线开放应用平台,将提供行动商务极佳的解决方案。

    在中型的J2SE(Java 2 Standard Edition)方面,Sun推出一个新的解决方案,称为Java Web Start。原先的Java Applet是在WebBrowser 中间开出一块方形区域来执行Java程序,但是这样在执行效能和兼容性上都受限于原有的 Web Browser。现在新推出的Java Web Start则是在操作系统上直接执行的Java Application,但是可以在网页上激活。如此一来既可和网页结合,在执行上也更快、更有效率。并且,Sun和IBM都将推出支持64位运算的Java版本,这对一般计算机上执行的客户端Java应用系统的开发将会是一大利器。

    另外在大型的J2EE(Java 2 Enterprise Edition)应用上,可以说"J2EE"已经成为服务器运算环境的标准。Java Servlets、JSP(Java ServerPages)、EJB(Enterprise JavaBeans)、JavaMail、JDBC、JMS等,都是各家厂商产品开发的重点方向。J2EE兼容的是一般Intel个人计算机(Linux、Windows.....)、麦金塔以及各家高效能高稳定度的UNIX伺服主机,未来必定成为服务器运算市场上的主要选择之一。

    除了以上这三大Java组合之外,Java和XML的整合也是未来的重点。Sun公司已经推出Java处理XML的标准延伸API - Java API for XML Parsing (JAXP),可以让各家所制作的XML解析器有接口上的标准。所以在Java程序中,只要了解一套API(JAXP)就可以完全处理XML文件,让XML的应用更加方便。Java这个跨平台的开发环境,加上XML这个跨平台的资料格式,此种跨平台优势组合势将成为未来讯息传递及资料交换的主要应用技术,如虎添翼地结合成一个最佳的跨平台解决方案。

    藉由J2SE (Java 2 Standard Edition)可以开发在PC上的应用软件,藉由J2ME (Java 2 Micro Edition) 可以跨足更广大的家电、智能卡、电子装置等市场,再藉由J2EE (Java 2 Enterprise Edition ) 可以整合伺服主机运算环境。Java技术的应用范围几乎已经无所不在,Java技术更可以在网际网络及电子商务各领域中,提供全方位的解决方案。

    随着应用领域的不同,Java 有许多 API(Application Programming Interface),这些 API 分成三大类:

    · Java Core API:由 Sun 制定的基本 API,任何 Java 平台都必须提供。 

    · Java Standard Extension API (javax):由 Sun 制定的扩充 API,Java 平台可以选择性地提供或加装。

    · 厂商或组织所提供的 API:由各家公司或组织所提供。 

    其中 Core API 和 Standard Extension API 已经逐渐涵盖了大部份的信息应用领域,例如多媒体、数据库、Web、企业运算、语音、实时系统、网络、电话、影像处理、加解密、GUI、分布式运算 ......。如果你有某项需求尚未有标准的 Java API 可遵循,你可以向 Sun 提出制定新 API 的请求。经过审核之后,你的要求可能会通过、驳回 ...... 等。如果通过,就会开始进入制定 API 的程序。Java API 的制定过程因为公开,且经过许多业界技术领先公司的共同参与,所以相当完善而优异。


EJB的生态环境

在sun公司提供的EJB规范中,我们一个完整的基于EJB的分布式计算结构由六个角色组成,这六个角色可以由不同的开发商提供,每个角色所作的工作必须遵循Sun公司提供的EJB规范,以保证彼此之间的兼容性。


    EJB组件开发者: 开发并销售 EJB。
    应用组合者: 将不同的 EJB 搭建成应用。
    部署者: 使用相应工具在运行环境下配置 EJB。
    EJB 服务器提供者: 开发并销售 EJB 服务器 
    EJB 容器供应商: 开发并销售 EJB 容器 
    系统管理员: 监视运行时情况/r

    1、EJB组件开发者(Enterprise Bean Provider)

    EJB组件开发者负责开发执行商业逻辑规则的EJB组件,开发出的EJB组件打包成ejb-jar文件。EJB组件开发者负责定义EJB的remote和home接口,编写执行商业逻辑的EJB class,提供部署EJB的部署文件(deployment descriptor)。部署文件包含EJB的名字,EJB用到的资源配置,如JDBC等。EJB组件开发者是典型的商业应用开发领域专家。

    EJB组件开发者不需要精通系统级的编程,因此,不需要知道一些系统级的处理细节,如事务、同步、安全、分布式计算等。

    2、应用组合者(Application Assembler)

    应用组合者负责利用各种EJB组合一个完整的应用系统。应用组合者有时需要提供一些相关的程序,如在一个电子商务系统里,应用组合者需要提供JSP(Java Server Page)程序。

    应用组合者必须掌握所用的EJB的home和remote接口,但不需要知道这些接口的实现。

    3、部署者(Deployer)

    部署者负责将ejb-jar文件部署到用户的系统环境中。系统环境包含某种EJB Server和EJB Container。部署者必须保证所有由EJB组件开发者在部署文件中声明的资源可用,例如,部署者必须配置好EJB所需的数据库资源。

    部署过程分两步:部署者首先利用EJB Container提供的工具生成一些类和接口,使EJB Container能够利用这些类和接口在运行状态管理EJB。 部署者安装EJB组件和其他在上一步生成的类到EJB Container中。 部署者是某个EJB运行环境的专家。

    某些情况下,部署者在部署时还需要了解EJB包含的业务方法,以便在部署完成后,写一些简单的程序测试。

    4、EJB 服务器提供者(EJB Server Provider)

    EJB 服务器提供者是系统领域的专家,精通分布式交易管理,分布式对象管理及其它系统级的服务。EJB 服务器提供者一般由操作系统开发商、中间件开发商或数据库开发商提供。

    在目前的EJB规范中,假定EJB 服务器提供者和EJB 容器提供者来自同一个开发商,所以,没有定义EJB 服务器提供者和EJB容器提供者之间的接口标准。

    5、EJB 容器提供者(EJB Container Provider)

    EJB 容器提供者提供以下功能:

    提供EJB部署工具为部署好的EJB组件提供运行环境 。EJB容器负责为EJB提供交易管理,安全管理等服务。

    EJB 容器提供者必须是系统级的编程专家,还要具备一些应用领域的经验。EJB 容器提供者的工作主要集中在开发一个可伸缩的,具有交易管理功能的集成在EJB 服务器中的容器。EJB 容器提供者为EJB组件开发者提供了一组标准的、易用的API访问EJB 容器,使EJB组件开发者不需要了解EJB服务器中的各种技术细节。

    EJB容器提供者负责提供系统监测工具用来实时监测EJB容器和运行在容器中的EJB组件状态。

    6、系统管理员(System Administrator)

    系统管理员负责为EJB服务器和容器提供一个企业级的计算和网络环境。

    系统管理员负责利用EJB 服务器和容器提供的监测管理工具监测EJB组件的运行情况。

    将责任分离的另一个好处是在代码级上,可以将基于EJBs的系统逻辑的分派给更适合的专家。SUN的EJB规范建议使用几个独立的角色,对于确定运作环境的责任链是非常重要的。举例说,EJB提供者是由商业专家和分析人员扮演的角色,他们确定一个组织内的最佳信息流程。但是仍旧有Second Domain Expert,如应用程序汇编人员,他们集成不同的EJB组件并确保它可以确保满足应用程序的需求。

    还有两种角色归入到系统级的部分,第一个是配置人员,他们负责实际的安装和配置基于EJB的系统。这需要有设置目录服务和集成现有应用程序的经验。第二个是系统管理员,他们要提供全天的监视和支持,确保应用程序正常运作。尽管系统管理员这个角色不需要是Java编程专家,但是他需要能够应付以下问题:

    设置Java Virtual Machine (JVM)并关联系统环境参数(如:CLASSPATH) 
    使用Java Archive (jar)命令保存类文件 
    懂得WEB服务器和Servlet的工作原理。 
    要能通过监视运行中程序的状态确定优化方法。 

    很明显,有些角色是可以交叉的,比如系统管理员和配置人员。尽管配置人员可能是将类文件复制到服务器而系统管理员需要确定配置人员是否复制到了正确的位置。

      EJB技术的基础是另外两种技术:RMI-IIOP和JNDI。要想了解EJB,一定要先了解RMI-IIOP和JNDI。因此,我们在介绍EJB细节之前,先了解这两项技术。我们的介绍比较基本,因此大多数组织只要了解这些就已经够了。

Java RMI-IIOP

    Java RMI-IIOP(Java Remote Method Invocation over the Internet Inter-ORB Protocol)是J2EE的网络机制。Java RMI-IIOP允许你编写分布式对象,使得对象的通信范围能够在内存中,跨Java虚拟机,跨物理设备。

Remote Method Invocation

    RPC(remote procedure call)是一台机器的进程调用另一台机器的进程的过程。而remote method invocation则比RPC的概念更进一步,允许分布式对象间的通信。RMI-IIOP允许调用远程对象的方法,而不仅仅是过程。这有利于面向对象编程。Java RMI (Remote Method Invocation 远程方法调用)是用Java在JDK1.1中实现的,它大大增强了Java开发分布式应用的能力。Java作为一种风靡一时的网络开发语言,其巨大的威力就体现在它强大的开发分布式网络应用的能力上,而RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案之一。其实它可以被看作是RPC的Java版本。但是传统RPC并不能很好地应用于分布式对象系统。而Java RMI 则支持存储于不同地址空间的程序级对象之间彼此进行通信,实现远程对象之间的无缝远程调用。

    remote method invocation决不简单,需要考虑几个问题:

    marshalling和unmarshalling.在不同机器间通过网络传递变量(包括Java基本类型和对象),如果目标机器表示数据的方式和原机器不同该怎么办?例如二进制库不同。因此marshalling和unmarshalling就是传递变量的过程。

    变量传递方法.变量有两种传递方法:pass-by-value和pass-by-reference。对于前者,你的目标方法只需使用一份copy,但对于后者,远程方法对变量的任何修改都会影响到源数据。

    网络和机器的不稳定.需要有一种机制保证一个JVM崩溃之后,不会影响系统的正常运作。

    在 Java 分布式对象模型中,remote object 是这样一种对象:它的方法可以从其它 Java 虚拟机(可能在不同的主机上)中调用。该类型的对象由一种或多种 remote interfaces(它是声明远程对象方法的 Java 接口)描述。远程方法调用 (RMI) 就是调用远程对象上远程接口的方法的动作。更为重要的是,远程对象的方法调用与本地对象的方法调用语法相同。

Remote Interface

    RMI-IIOP遵循了接口和实现的原则。你写的所有网络代码都是应用于接口,而不是实现。实际上,你必须使用RMI-IIOP中的范例,没有其它的选择。直接在你的对象实现上执行远程调用是不可能的,你只能在对象类的接口上单独进行这一操作。

    所以我们在使用RMI-IIOP时,你必须建立一个客户接口,叫做remote interface。这个远程接口应该扩展java.rmi.Remote接口。

Remote Object Implementation

    远程对象和客户机的物理位置并不是很重要。可以运行在同一地址空间或是跨Internet运行。

    为了使对象成为一个远程对象,你需要执行一下步骤:

    继承javax.rmi.PortableRemoteObject。PortableRemoteObject是进行远程调用的基类,当你的远程对象调用构造器时,PortableRemoteObject对象的构造器也会自动被调用。

    不继承javax.rmi.PortableRemoteObject。如果你的远程对象需要继承其它的类,而Java不允许多重继承,因此你不能继承PortableRemoteObject。这时,你需要手动调用javax.rmi.PortableRemoteObject.exportObject()。

Stub和Skeletons

    我们来看看在RMI-IIOP背后隐藏的网络架构。RMI-IIOP的一个好处就是你可以不用管你要调用的对象是本地的还是远程的。这就叫做local/remote transparency。

    RMI应用程序通常包括两个独立的程序:服务器程序和客户机程序。典型的服务器应用程序将创建多个远程对象,使这些远程对象能够被引用,然后等待客户机调用这些远程对象的方法。而典型的客户机程序则从服务器中得到一个或多个远程对象的引用,然后调用远程对象的方法。RMI为服务器和客户机进行通信和信息传递提供了一种机制。






    在与远程对象的通信过程中,RMI使用标准机制:stub和skeleton。远程对象的stub担当远程对象的客户本地代表或代理人角色。调用程序将调用本地stub的方法,而本地stub将负责执行对远程对象的方法调用。在RMI中,远程对象的stub与该远程对象所实现的远程接口集相同。调用stub的方法时将执行下列操作:(1) 初始化与包含远程对象的远程虚拟机的连接;(2) 对远程虚拟机的参数进行编组(写入并传输);(3) 等待方法调用结果;(4) 解编(读取)返回值或返回的异常;(5) 将值返回给调用程序。为了向调用程序展示比较简单的调用机制,stub将参数的序列化和网络级通信等细节隐藏了起来。在远程虚拟机中,每个远程对象都可以有相应的skeleton(在JDK1.2环境中无需使用skeleton)。Skeleton负责将调用分配给实际的远程对象实现。它在接收方法调用时执行下列操作:(1) 解编(读取)远程方法的参数;(2) 调用实际远程对象实现上的方法;(3) 将结果(返回值或异常)编组(写入并传输)给调用程序。stub和skeleton由rmic编译器生成。

    要实现local/remote transparency可没有那么简单。为了屏蔽你调用的是远端主机上的对象,RMI-IIOP需要模拟一个本地对象供你调用。这个本地对象叫做stub。它负责接受本地的方法调用请求,把这些请求委托给真正实现它们的对象(可以通过网络定位)。这样就使得远程调用看起来就和本地调用一样。

    利用RMI编写分布式对象应用程序需要完成以下工作:(1) 定位远程对象。应用程序可使用两种机制中的一种得到对远程对象的引用。它既可用RMI的简单命名工具rmiregistry来注册它的远程对象,也可以将远程对象引用作为常规操作的一部分来进行传递和返回。(2)与远程对象通信。远程对象间通信的细节由RMI处理,对于程序员来说,远程通信看起来就像标准的Java方法调用。(3)给作为参数或返回值传递的对象加载类字节码。因为RMI允许调用程序将纯Java对象传给远程对象,所以,RMI将提供必要的机制,既可以加载对象的代码又可以传输对象的数据。在RMI分布式应用程序运行时,服务器调用注册服务程序以使名字与远程对象相关联。客户机在服务器上的注册服务程序中用远程对象的名字查找该远程对象,然后调用它的方法。

    定位远程对象。应用程序可使用两种机制中的一种得到对远程对象的引用。它既可用 RMI 的简单命名工具 rmiregistry 来注册它的远程对象;也可将远程对象引用作为常规操作的一部分来进行传递和返回。 

    与远程对象通讯。远程对象间通讯的细节由 RMI 处理;对于程序员来说,远程通讯看起来就象标准的 Java 方法调用。给作为参数或返回值传递的对象加载类字节码因为 RMI允许调用程序将纯 Java 对象传给远程对象,所以 RMI 将提供必要的机制,既可以加载对象的代码又可以传输对象的数据。服务器调用注册服务程序以使名字与远程对象相关联。客户机在服务器注册服务程序中用远程对象的名字查找该远程对象,然后调用它的方法。RMI 能用 Java系统支持的任何 URL 协议(例如 HTTP、FTP、file 等)加载类字节码。

    stub只是解决了一半的问题。我们还希望远程对象也不用考虑网络问题。因此远程对象也需要一个本地的skeleton来接受调用。skeleton接受网络调用并把调用委托给远程对象实现。

    你的J2EE服务器应当提供一种方法来产生必须的stub和skeleton,以减轻你的对网络问题考虑的负担。典型的是通过命令行工具来完成,例如sun的J2EE参考实现包就使用了一个名为rmic(RMI compiler)的工具来产生stub和skeleton类。你应当把stub部署在客户机上,并把skeleton部署在服务器上。

对象序列化和变量传递

    在RMI分布式应用系统中,服务器与客户机之间传递的Java对象必须是可序列化的对象。不可序列化的对象不能在对象流中进行传递。对象序列化扩展了核心Java输入/输出类,同时也支持对象。对象序列化支持把对象编码以及将通过它们可访问到的对象编码变成字节流;同时,它也支持流中对象图形的互补重构造。序列化用于轻型持久性和借助于套接字或远程方法调用(RMI)进行的通信。序列化中现在包括一个 API(Application Programming Interface,应用程序接口),允许独立于类的域指定对象的序列化数据,并允许使用现有协议将序列化数据域写入流中或从流中读取,以确保与缺省读写机制的兼容性。

    为编写应用程序,除多数瞬态应用程序外,都必须具备存储和检索 Java对象的能力。以序列化方式存储和检索对象的关键在于提供重新构造该对象所需的足够对象状态。存储到流的对象可能会支持 Serializable(可序列化)或 Externalizable(可外部化)接口。对于Java对象,序列化形式必须能标识和校验存储其内容的对象所属的 Java类,并且将该内容还原为新的实例。对于可序列化对象,流将提供足够的信息将流的域还原为类的兼容版本。对于可外部化对象,类将全权负责其内容的外部格式。序列化 Java 对象的目的是:提供一种简单但可扩充的机制,以序列化方式维护 Java对象的类型及安全属性;具有支持编组和解编的扩展能力以满足远程对象的需要;具有可扩展性以支持 Java 对象的简单持久性;只有在自定义时,才需对每个类提供序列化自实现;允许对象定义其外部格式。

java.rmi.Remote 接口 

    在 RMI 中,远程接口是声明了可从远程 Java 虚拟机中调用的方法集。远程接 
口必须满足下列要求: 

    远程接口至少必须直接或间接扩展 java.rmi.Remote 接口。 
    远程接口中的方法声明必须满足下列远程方法声明的要求: 
    远程方法声明在其 throws 子句中除了要包含与应用程序有关的异常(注意与应用程序有关的异常无需扩展 java.rmi.RemoteException )之外,还必须包括 java.rmi.RemoteException 异常(或它的超类,例如java.io.IOException 或 java.lang.Exception )。 
    远程方法声明中,作为参数或返回值声明的(在参数表中直接声明或嵌入到参数的非远程对象中)远程对象必须声明为远程接口,而非该接口的实现类。

    java.rmi.Remote 接口是一个不定义方法的标记接口: 

public interface Remote 

    远程接口必须至少扩展 java.rmi.Remote 接口(或其它扩展java.rmi.Remote 的远程接口)。然而,远程接口在下列情况中可以扩展非远程接口: 

    远程接口也可扩展其它非远程接口,只要被扩展接口的所有方法(如果有)满足远程方法声明的要求。 
    例如,下面的接口 BankAccount 即为访问银行帐户定义了一个远程接口。它包含往帐户存款、使帐户收支平衡和从帐户取款的远程方法: 

public interface BankAccount extends java.rmi.Remote 

public void deposit(float amount) 
throws java.rmi.RemoteException; 
public void withdraw(float amount) 
throws OverdrawnException, java.rmi.RemoteException; 
public float getBalance() 
throws java.rmi.RemoteException; 


    下例说明了有效的远程接口 Beta。它扩展非远程接口 Alpha(有远程方法)和接口 java.rmi.Remote: 
public interface Alpha 

public final String okay = "constants are okay too"; 
public Object foo(Object obj) 
throws java.rmi.RemoteException; 
public void bar() throws java.io.IOException; 
public int baz() throws java.lang.Exception; 


public interface Beta extends Alpha, java.rmi.Remote { 
public void ping() throws java.rmi.RemoteException; 


RemoteException 类 

    java.rmi.RemoteException 类是在远程方法调用期间由 RMI 运行时所抛出的异常的超类。为确保使用 RMI 系统的应用程序的健壮性,远程接口中声明的远程方法在其 throws 子句中必须指定 java.rmi.RemoteException(或它的超类,例如 java.io.IOException 或 java.lang.Exception)。 

当远程方法调用由于某种原因失败时,将抛出 java.rmi.RemoteException 异常。远程方法调用失败的原因包括: 

    通讯失败(远程服务器不可达或拒绝连接;连接被服务器关闭等。) 
    参数或返回值传输或读取时失败 
    协议错误 

    RemoteException 类是一个已检验的异常(必须由远程方法的调用程序处理并经编译器检验的异常),而不是 RuntimeException。 

RemoteObject 类及其子类 

    RMI 服务器函数由 java.rmi.server.RemoteObject 及其子类java.rmi.server.RemoteServer、java.rmi.server.UnicastRemoteObject和 java.rmi.activation.Activatable 提供。 

    java.rmi.server.RemoteObject 为对远程对象敏感的 java.lang.Object方法、hashCode、 equals 和 toString 提供实现。 

    创建远程对象并将其导出(使它们可为远程客户机利用)所需的方法由类UnicastRemoteObject 和 Activatable 提供。子类可以识别远程引用的语义,例如服务器是简单的远程对象还是可激活的远程对象(调用时将执行的远程对象)。java.rmi.server.UnicastRemoteObject 类定义了单体(单路传送)远程对
象,其引用只有在服务器进程活着时才有效。类 java.rmi.activation.Activatable 是抽象类,它定义的 activatable远程对象在其远程方法被调用时开始执行并在必要时自己关闭。 

实现远程接口 

    实现远程接口的类的一般规则如下: 

    该类通常扩展 java.rmi.server.UnicastRemoteObject,因而将继承类java.rmi.server.RemoteObject 和java.rmi.server.RemoteServer 提供的远程行为。
    该类能实现任意多的远程接口。 
    该类能扩展其它远程实现类。 
    该类能定义远程接口中不出现的方法,但这些方法只能在本地使用而不能在远程使用。 

    例如,下面的类 BankAcctImpl 实现 BankAccount 远程接口并扩展java.rmi.server.UnicastRemoteObject 类: 

package mypackage; 

import java.rmi.RemoteException; 
import java.rmi.server.UnicastRemoteObject; 

public class BankAccountImpl extends UnicastRemoteObject implements 
BankAccount 


private float balance = 0.0; 

public BankAccountImpl(float initialBalance) 
throws RemoteException 

balance = initialBalance; 


public void deposit(float amount) throws RemoteException 

... 


public void withdraw(float amount) throws OverdrawnException, 
RemoteException 

... 


public float getBalance() throws RemoteException 

... 




    注意:必要时,实现远程接口的类能扩展除java.rmi.server.UnicastRemoteObject 类以外的其它一些类。但实现类此时必须承担起一定的责任,即导出对象(由 UnicastRemoteObject 构造函数负责)和实现从 java.lang.Object 类继承的 hashCode、 equals 和toString 方法的正确远程语义(如果需要)。 


远程方法调用中的参数传递 

    传给远程对象的参数或源于它的返回值可以是任意可序列化的 Java 对象。这包括 Java 基本类型, 远程?Java 对象和实现 java.io.Serializable 接口的非远程 Java 对象。有关如何使类序列化的详细信息,参见 Java“对象序列化规范”。本地得不到的作为参数或返回值的类,可通过 RMI 系统进行动态下载。 

传递非远程对象 

    非远程对象将作为远程方法调用的参数传递或作为远程方法调用的结果返回时,是通过复制传递的;也就是使用 Java 对象序列化机制将该对象序列化。因此,在远程对象调用过程中,当非远程对象作为参数或返回值传递时,非远程对象的内容在调用远程对象之前将被复制。从远程方法调用返回非远程对象时,将在调用的虚拟机中创建新对象。 

传递远程对象 

    当将远程对象作为远程方法调用的参数或返回值传递时,远程对象的 stub 程序即被传递出去。作为参数传递的远程对象仅能实现远程接口。 

引用的完整性 

    如果一个对象的两个引用在单个远程方法调用中以参数形式(或返回值形式)从一个虚拟机传到另一个虚拟机中,并且它们在发送虚拟机中指向同一对象,则两个引用在接收虚拟机中将指向该对象的同一副本。进一步说就是:在单个远程方法调用中,RMI 系统将在作为调用参数或返回值传递的对象中保持引用的完整性。 

类注解 

    当对象在远程调用中被从一个虚拟机发送到另一个虚拟机中时,RMI 系统在调用流中用类的信息 (URL) 给类描述符加注解,以便该类能在接收器上加载。在远程方法调用期间,调用可随时下载类。 

参数传输 

    为将 RMI 调用的参数序列化到远程调用的目的文件里,需要将该参数写入作为java.io.ObjectOutputStream 类的子类的流中。ObjectOutputStream 子类将覆盖 replaceObject 方法,目的是用其相应的 stub 类取代每个远程对象。对象参数将通过 ObjectOutputStream 的 writeObject 方法写入流中。而ObjectOutputStream 则通过 writeObject 方法为每个写入流中的对象(包含所写对象所引用的对象)调用 replaceObject 方法。RMIObjectOutputStream子类的 replaceObject 方法返回下列值: 
如果传给 replaceObject 的对象是 java.rmi.Remote 的实例,则返回远程对象的 stub 程序。远程对象的 stub 程序通过对java.rmi.server.RemoteObject.toStub方法的调用而获得。如果传给 replaceObject 的对象不是 java.rmi.Remote 的实例,则只返回该对象。 

    RMI 的 ObjectOutputStream 子类也实现 annotateClass 方法,该方法用类的位置注解调用流以便能在接收器中下载该类。有关如何使用 annotateClass的详细信息,参见“动态类加载”一节。因为参数只写入一个 ObjectOutputStream,所以指向调用程序同一对象的引用将在接收器那里指向该对象的同一副本。在接收器上,参数将被单个ObjectInputStream 所读取。 

    用于写对象的 ObjectOutputStream(类似的还有用于读对象的ObjectInputStream )的所有其它缺省行为将保留在参数传递中。例如,写对象时对 writeReplace 的调用及读对象时对 readResolve 的调用就是由 RMI的参数编组与解编流完成的。 

    与上述 RMI 参数传递方式类似,返回值(或异常)将被写入ObjectOutputStream的子类并和参数传输的替代行为相同。 

定位远程对象 

    我们专门提供了一种简单的引导名字服务器,用于存储对远程对象的已命名引用。使用类 java.rmi.Naming 的基于 URL 的方法可以存储远程对象引用。客户机要调用远程对象的方法,则必须首先得到该对象的引用。对远程对象的引用通常是在方法调用中以返回值的形式取得。RMI 系统提供一种简单的引导名字服务器,通过它得到给定主机上的远程对象。java.rmi.Naming 类提供基于统一资源定位符 (URL) 的方法,用来绑定、再绑定、解开和列出位于某一主机及端口上的名字-对象对。 

      J2EE的十三种技术/r

Java数据库连接(JDBC)

    JDBC API以一个统一的方式访问各种数据库。与ODBC类似,JDBC将开发者和私有数据库之间的问题隔离开来。由于它建立在Java上,因此JDBC可以提供平台无关的数据库访问。

    JDBC定义了4种不同的驱动,具体来说,包括有:

    类型1:JDBC-ODBC桥

    在JDBC刚产生时,JDBC-ODBC桥是非常有用的。通过它,开发者可以使用JDBC来访问一个ODBC数据源。缺点是,它需要在客户机器上安装有一个ODBC驱动,该机器通常是应该运行微软Windows系统的。使用这一类的驱动器,你就会失去JDBC平台无关的好处。此外,ODBV驱动器需要客户端的管理。

    类型2:JDBC-native驱动桥

    JDBC-native驱动桥提供了一个建筑在本地数据库驱动上的JDBC接口--没有使用ODBC。JDBC驱动将标准的JDBC调用转变为对数据库API的本地调用。使用类型2的驱动也会失去JDBC平台无关性的好处,并且需要安装客户端的本地代码。

    类型3:JDBC-network桥

    JDBC-network桥不需要客户端的数据库驱动。它们使用网络-服务器中层来访问一个数据库。这会引出诸如负载均衡、连接池等技术,数据缓冲也是可能的。由于类型3的驱动通常可带来相对小的下载时间,它是平台无关的,并且不需要客户端的安装和管理,因此很适合用作Internet的应用。

    类型4:纯Java驱动

    类型4使用纯Java数据库驱动来提供直接的数据库访问。由于类型4驱动运行在客户端,并且直接访问数据库,因此运行在这个模式暗示要使用一个两层的体系。要在一个n层的体系中使用类型4的驱动,可以通过一个包含有数据访问代码的EJB,并且让该EJB为它的客户提供一个数据库无关的服务。

Java命名和目录接口(Java Naming and Directory Interface,JNDI)

    JNDI是Java Naming and Directory Interface 的简写,中意为:Java命名及目录接口,它是为了对高级网络应用开发中的使用的目录基础结构的访问。实际上这个目录是一个特殊的数据库,提供了对存储数据的快速访问,不象传统的目录服务访问方式-你必须提供不同的API接口去访问不同的目录服务(如:LDAP,NIS,ADS等),而它提供了一种标准的API来访问类型不同的目录。据说,使用完整的SDK可以开发那些JNDI还不支持的目录服务提供者。

    JNDI是J2EE的一个API,提供了一套标准的接口,以定位用户、机器、网络、对象、以及服务。例如,你可以使用JNDI来定位内部网中的一台打印机,你也可以使用它来定位Java对象或连接到一个数据库。JNDI可以用于EJB、RMI-IIOP、JDBC中。它是网络查找定位的标准方法。    JNDI API被用来访问命名和目录服务。它提供一个相容的模式来访问和操作企业范围大的资源,例如一个应用服务器中的DNS、LDAP、本地文件系统或者对象。

    在JNDI中,一个目录结构中的每一个节点被称为context。每一个JNDI的名字都是与一个context相对的,没有一个绝对名字的概念。一个应用可以使用InitialContext类来得到它的第一个context:

      Context ctx = new InitialContext(); 

    通过这个初始的context,应用就可以经过目录树定位到需要的资源或者对象。例如,假定你已经在WebLogic Server中配置了一个EJB,并且在myApp.myEJB中绑定了home接口。EJB的客户端,在得到这样一个初始的context后,然后就可以使用以下的代码来定位到home接口:

      MyEJBHome home = ctx.lookup( "myApp.myEJB" ); 

    一旦你得到你所需对象的一个引用--在这个例子中,就是EJB的home接口--然后你可以调用它上面的方法。为了在一个context中查找到一个对象,JNDI还提供方法可以做到:

    插入或者绑定一个对象到一个context中。在你配置一个EJB时,这是非常有效的方法;
    
    从一个context中移去一个对象/r

    列出一个context中的所有对象/r

    创建和删除subcontexts

企业Java Beans(Enterprise Java Beans,EJB)

    J2EE其中一个引人注目的技术是EJB。它提供了一个架构来开发和配置到客户端的分布式商业逻辑,因此可以明显减少开发扩展性、高度复杂企业应用的难度。EJB规范定义了EJB组件应该如何及何时与它们的容器交互。由容器来负责提供普通的服务,例如目录服务、事务管理、安全、资源池和容错。

    EJB规范定义了三类基本的bean:

    会话beans(session beans):会话beans为业务流程建模,由于他们通常表示执行某个动作,因此可以把它们当作是动词。这个执行的动作可以是任何事情,例如增加数量,访问数据库,调用其它系统,调用其它企业Bean。我们可以举出很多的例子,包括一个计价引擎,一个工作流引擎,一个目录引擎,一个信用卡认证中心,或一个网上证券交易引擎。

    实体beans(Entity beans):这是持久保存数据的代表--典型的是存储在数据库中--因此在服务器崩溃后数据仍然存在。多个客户端可以使用EJB来表示同样的数据。实体beans为企业数据建模,由于它们表示数据对象(就是缓存数据库信息的Java对象),因此可以把它们当作名词。实体beans的例子包括一种产品,一项订单,一个雇员,一张信用卡,或一支股票。会话beans典型的方式是通过实体beans来实现业务目标的,例如一个证券交易引擎(会话beans)处理股票(实体beans)。

    Message-Driven beans:Message-Driven beans也表示动作,这一点上它类似于会话beans。它们之间的不同点在于你只能够通过发送消息给Message-Driven beans的方式来调用它们。Message-Driven beans的例子包括了接受股票交易消息的beans,信用认证消息,或工作流消息。这些Message-Driven beans也可以调用其它的企业beans。

    接着,我们讨论无状态和有状态

    无状态的beans(Stateless beans):这是一个单一使用的服务,不维护任何的状态,在服务器崩溃时也不再存在,而且生存期也相对地短。例如,一个无状态的session bean可能用作执行温度转换。

    有状态的bean:它提供了一个传统的与客户端交互的方法,存储客户端的状态。在线购物车就是这样一个有状态session ean的典型例子。有状态session beans在服务器崩溃时也不再存在,而且生存期也相对地短,并且每个实例只可以用在一个单一的线程中。

JavaServer Pages (JSPs) 

    或许你已经对微软的Active Server Pages (ASPs)非常熟悉;JSP也是类似的技术,不过它是平台无关的。它们都是设计来帮助web内容开发者使用相对较少的代码就可以创建动态的网页。web设计者即使不懂得编程,也可以使用JSP来创建动态的网页。JavaServer Page是HTML代码和Java代码的混合。在客户请求页面的时候,服务器就会处理Java代码,然后返回HTML页面给浏览器。

    你可以也听过JHTML,它是一个旧的标准,现在已经被JSP取代了。WebLogic Server不但支持JSP,还支持JHTML。不过,在默认设置下,WebLogic Server是不支持JSP的(对于5.1版本)。你必须编辑weblogic.properties来激活web服务器,对于JSPServlet来说,也是这样。

Java servlets 

    servlets提供的功能大部分JSP相同,它采用的是一个有点不同的方法。JSP中大部分是HTML代码,其中只有少量的Java代码,而servlets则相反,它完全使用Java编写,并且产生HTML代码。

    servlet是一个在服务器上运行的Java小程序,它可以扩展Web服务器的功能。这些服务器端的应用可以在被请求时动态执行,与传统Web服务器上的CGI Perl脚本差不多。CGI脚本和servlet的一个主要不同是:CGI脚本对于每次请求都启动一个全新的进程--需要额外的系统开销--而servlet的执行只要在servlet引擎内启动一个独立的线程就性了。因此Servlet的扩展性也更好。

    在开发servlet时,你通常都要扩展javax.servlet.http.HttpServlet类,并且覆盖它的一些方法。感兴趣的方法包括有:

    service(): 作为command-specific方法的一个调度程序/r

    doGet(): 处理来自一个客户的HTTP GET请求 

    doPost(): 处理来自一个客户的HTTP POST请求/r

    还有一些其它的方法来处理不同类型的HTTP请求--可参考HttpServlet API的文本来得到更多相关的信息。

Java IDL/CORBA

    通过Java的IDL支持,开发者可以将Java与CORBA集成。他们可以创建能配置在一个CORBA ORB中的Java对象,也可以创建作为配置在其它ORB内的CORBA对象客户端的Java类。对于通过Java将你的新应用和以前的系统集成,后者提供了一个另外的方法。

Java事务体系(JTA)/Java事务服务(JTS)

    JTA定义了一个标准的API,应用可以通过它来访问事务监控器。

    JTS是CORBA OTS事务监控器的一个基本实现。JTS指定了一个事务管理器的实现(Transaction Manager),这个管理器在一个高级别上支持Java事务API(JTA)规范,并且在一个低级别上实现了OMG OTS规范的Java映射。一个JTS事务管理器为应用服务器、资源管理器、standalone应用和通信资源管理器提供事务服务。

JavaMail和JavaBeans激活架构(JavaBeans Activation Framework,JAF)

    JavaMail是一个用来访问邮件服务器的API。JavaMail API提供了一套抽象类来模型化一个邮件系统。支持SMTP和IMAP服务器。

    JavaMail通过使用JavaBeans Activation Framework (JAF) 来处理MIME加密的邮件附件。MIME字节流和Java对象间可以互相转化。大多数的应用无需要直接使用JAF。

Java信使服务(Java Messaging Service,JMS)

    JMS是一个用来和面向信息的中层通信的API。它不但支持点对点的域,也支持发布/订阅域,并且提供对担保信息传送、事务信息传送、持久信息和durable subscribers的支持。对于将你的应用和以前的backend系统集成,JMS提供了另外一个方法。

扩展标记语言(Extensible Markup Language,XML)

    XML是一个用来定义其它标记语言的的语言。它可被用作商业之间的数据共享。XML的发展是与Java分开的;不过,它的目标和Java类似,都是为了与平台无关。通过将Java与XML结合,你可以得到一个完全平台无关的解决方案。多个公司都为在Java和XML间开发一个紧密的集成而工作。具体的信息,可浏览Sun站点的Java-XML部分(http://java.sun.com/xml),以及IBM的developerWorks的XML Zone部分(http://www.ibm.com/developer/xml/)。

0 0

相关博文

我的热门文章

img
取 消
img