jms源码

‘壹’ ejb到底是什么东东就是一些java bean吗

尽供你参考!
EJB是sun的服务器端组件模型，最大的用处是部署分布式应用程序，类似微软的.com技术。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。

EJB (Enterprise JavaBean)是J2EE的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。

在J2EE里，Enterprise Java Beans(EJB)称为Java 企业Bean，是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。

1.Session Bean用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个Session Bean来为客户端服务。Session Bean可以直接访问数据库，但更多时候，它会通过Entity Bean实现数据访问。

2.Entity Bean是域模型对象，用于实现O/R映射，负责将数据库中的表记录映射为内存中的Entity对象，事实上，创建一个Entity Bean对象相当于新建一条记录，删除一个Entity Bean会同时从数据库中删除对应记录，修改一个Entity Bean时，容器会自动将Entity Bean的状态和数据库同步。

3.MessageDriven Bean是EJB2.0中引入的新的企业Bean，它基于JMS消息，只能接收客户端发送的JMS消息然后处理。MDB实际上是一个异步的无状态Session Bean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。

EJB实际上是SUN的J2EE中的一套规范,并且规定了一系列的API用来实现把EJB概念转换成EJB产品.EJB是BEANS,BEANS是什么概念,那就是得有一个容纳她,让她可劲造腾的地方,就是得有容器.EJB必须生存在EJB容器中.这个容器可是功能强大之极!她首先要包装你BEAN,EJB的客户程序实际上从来就不和你编写的EJB直接打交道,他们之间是通过HOME/REMOTE接口来发生关系的.它负责你的BEAN的所有的吃喝拉萨睡,比如BEAN的持续化,安全性,事务管理...

一.什么是 EJB?

一个技术规范：EJB 从技术上而言不是一种"产品"
EJB 是一种标准描述了构建应用组件要解决的:
可扩展 (Scalable)
分布式 (Distributed)
事务处理 (Transactional)
数据存储 (Persistent)
安全性 (Secure)

二.Sun 对 EJB 的期望

提供一个标准的分布的、基于 OO 的组件架构
屏蔽复杂的系统级功能需求
Write once, run anywhere
与非 Java 应用之间的互操作能力
兼容 CORBA 标准

三.为什么选择 EJB?

EJB 服务器完成"繁杂"的工作：应用开发人员关注于业务逻辑的实现而不是底层的实现机制(类似于 4GL 语言设计的目标)
支持事务处理
多个业务操作同时成功，或全部失败
可以通过在代码外的描述来定义事务处理级别
可扩展性
EJB 可以根据您应用的增长而扩展
EJB 服务器往往还提供了负载均衡和
安全性：由 EJB 服务器提供资源的访问权限控制

四.EJB 架构

为了满足架构的目标，规范中描述了
服务器 (Server)
容器 (Container)
类 (Class) 和实例 (Instance)
Home 和 Remote 接口
客户端 (Client)

五. 简化的编程模型

关注于业务逻辑实现：EJB 负责生命周期 (lifecycle), 数据存储 (persistence), 事务处理语义 (transactional semantic), 安全(security), ...
通用的编程模型：各种服务的高层 API
Java 是其编程语言

EJB( 业务逻辑代码 ) 表示了与特定商业领域（例如银行、零售等行业）相适应的逻辑。它由
运行在业务逻辑层的 enterprise bean 处理。一个 enterprise bean 可以从客户端接受数据，对
它进行处理，并将其发送到企业信息系统层以作存储；同时它也可以从存储器获取数据，
处理后将其发送到客户端应用程序。
有三种类型的 enterprise beans：session beans、entity beans 和 message-driven beans。
Session bean 描述了与客户端的一个短暂的会话。当客户端的执行完成后，session bean 和
它的数据都将消失；与之相对应的是一个 entity bean 描述了存储在数据库表中的一行持久
稳固的数据，如果客户端终止或者服务结束，底层的服务会负责 entity bean 数据的存储。
Message-driven bean 结合了 session bean 和 Java 信息服务（JMS）信息监听者的功能，它允
许一个商业组件异步地接受 JMS 消息。

EJB3.0的介绍
[编辑本段]

由于EJB2.0的复杂性，在Spring和Hibernate等轻量级框架出现后，大量的用户转向了，在大家的呼声中，EJB3.0规范终于发布了。
期待已久的EJB3.0规范在终于发布了。在本文中将对新的规范进行一个概要性的介绍，包括新增的元数据支持，EJBQL的修改，实体Bean模型访问 bean上下文的新方法和运行时环境等等。作者还讨论了EJB在未来要作出的调整以及EJB3.0与其他开发规范之间的关系。

开始

无论如何由于EJB的复杂性使之在J2EE架构中的表现一直不是很好。EJB大概是J2EE架构中唯一一个没有兑现其能够简单开发并提高生产力的组建。EJB3.0规范正尝试在这方面作出努力以减轻其开发的复杂性。EJB3.0减轻了开发人员进行底层开发的工作量，它取消或最小化了很多(以前这些是必须实现)回调方法的实现，并且降低了实体Bean及O/R映射模型的复杂性。

在本文中，我首先会介绍EJB3.0中几个主要的改变。它对进一步深入了解EJB3.0是非常重要的。随后，我会从更高的层面来描述已经被提交到EJB3.0规范中的细节，并一个个的讲解新的规范中的改变:实体Bean,O/R映射模型，实体关系模型和EJB QL(EJB查询语言)等等。

背景

EJB3.0中两个重要的变更分别是:使用了Java5中的程序注释工具和基于Hibernate的O/R映射模型。

Java5中的元数据工具

Java5(以前叫J2SE1.5或Tiger) 中加入了一种新的程序注释工具。通过这个工具你可以自定义注释标记，通过这些自定义标记来注释字段、方法、类等等。这些注释并不会影响程序的语义，但是可以通过工具(编译时或运行时)来解释这些标记并产生附加的内容(比如部署描述文件)，或者强制某些必须的运行时行为(比如EJB组件的状态特性)。注释的解析可以通过源文件的解析(比如编译器或这IDE工具)或者使用Java5中的APIs反射机制。注释只能被定义在源代码层。由于所有被提交到 EJB3.0草案中的注释标记都有一个运行时的RetentionPolicy，因此会增加类文件占用的存储空间，但这却给容器制造商和工具制造商带来了方便。

Hibernate

目前Hibernate非常受欢迎，它是开发源代码的Java O/R映射框架，目的是把开发人员从繁琐的数据持久化编程中解脱出来。它也有一个标准的HQL(Hibernate 查询语言)语言，你可以在新的EJB QL中看到它的影子。Hibernate在处理如数据查询、更新、连接池、事务处理、实体关系处理等方面非常简单。

概览

在已经提交的EJB3.0规范中主要涉及两个方面的改变:

1. 一套以注释为基础的EJB编程模型，再加上EJB2.1中定义的通过部署描述符和几个接口定义的应用程序行为。
2. 新的实体Bean持久化模型，EJBQL也有许多重要的改变。

还有一些有关上述的提议，比如:一个新的客户端编程模型，业务接口的使用以及实体Bean的生命周期。请注意EJB2.1编程模型(包括部署描述符和home/remote接口)仍然是有效的。新的简化模型并没有完全取代EJB2.1模型。

EJB注释

EJB规范组织一个重要的目标是减轻原始代码的数量，并且他们为此给出了一个完美而简介的办法。在EJB3.0的里，任何类型的企业级 Bean只是一个加了适当注释的简单Java对象(POJO)。注释可以用于定义bean的业务接口、O/R映射信息、资源引用信息，效果与在 EJB2.1中定义部署描述符和接口是一样的。在EJB3.0中部署描述符不再是必须的了;home接口也没有了，你也不必实现业务接口(容器可以为你完成这些事情)。

比如，你可以使用@Stateless注释标记类把Java类声明为一个无状态回话bean。对于有状态回话bean来说，@Remove注释可以用来标记一个特定的方法，通过这个注释来说明在调用这个方法之后bean的实例将被清除掉。

为了减少描述组件的说明信息，规范组织还采纳了由异常进行配置(configuration-by-exception)的手段，意思是你可以为所有的注释提供一个明确的缺省值，这样多数常规信息就可以据此推断得出。

新的持久化模型

新的实体bean也是一个加了注释的简单Java对象(POJO)。一旦它被EntityManager访问它就成为了一个持久化对象，并且成为了持久化上下文(context)的一部分。一个持久化上下文与一个事务上下文是松耦合的;严格的讲，它隐含的与一个事务会话共存。

实体关系也是通过注释来定义的，O/R映射也是，并提供几种不同的数据库规范操作，在EJB2.1中这些要通过开发人员自己的设计模式或者其它技术来完成的(比如，自增长主键策略)。

深入研究

现在是时候详细了解EJB3.0草案了。让我们开始探讨所有EJB中四种企业级bean，并看看他们在新的规范中是什么样子。

无状态回话bean

在EJB3.0规范中，写一个无状态回话bean(SLSB)只需要一个简单的Java文件并在类层加上@Stateless注释就可以了。这个bean可以扩展javax.ejb.SessionBean接口，但这些不是必须的。

一个SLSB不再需要home接口，没有哪类EJB再需要它了。Bean类可以实现业务接口也可以不实现它。如果没有实现任何业务接口，业务接口会由任意public的方法产生。如果只有几个业务方法会被暴露在业务接口中，这些方法可以使用@BusinessMethod注释。缺省情况下所有产 生的接口都是local(本地)接口，你也可以使用@Remote注释来声明这个接口为remote(远程)接口。

下面的几行代码就可以定义一个HelloWorldbean了。而在EJB2.1中同样的bean至少需要两个接口，一个实现类和几个空的实现方法，再加上部署描述符。

import javax.ejb.*;

/**
* A stateless session bean requesting that a remote business
* interface be generated for it.
*/
;@Stateless
;@Remote
public class HelloWorldBean {
public String sayHello() {
return "Hello World!!!";
}
}

有状态回话bean

除了几个SFSB的特别说明之外，有状态回话bean(SFSB)和SLSB一样精简:

一个SFSB应该有一个方法来初始化自己(在EJB2.1中是通过ejbCreate()来实现的)。在EJB3.0的规范中建议这些初始化操作可以通过自定义方法完成，并把他们暴露在业务接口中。在使用这个bean之前由客户端来调用相应的初始化方法。目前规范组织就是否提供一个注释来标记某个方法用于初始化还存在争议。

Bean的提供者可以用@Remove注释来标记任何SFSB的方法，以说明这个方法被调用之后bean的实例将被移除。同样，规范组织仍然在讨论是否要有一种机制来处理这种特殊的情况，即当这个方法出现异常的情况下bean的实例是否被移除。

下面是对以上问题我个人的观点:

是否应该有一个注释来标明一个方法进行初始化呢?我的观点是――应该有，这样容器就可以在调用其他方法之前至少调用一个方法来进行初始化。这不仅可以避免不必要的错误(由于没有调用初始化方法)而且可以使容器更明确的判断是否可以重用SFSB实例。我暂且把这个问题放一放，规范组织只考虑为一个方法提供一个注释来声明它是一个初始化方法。

对于第二个问题我的观点也是肯定的。这有利于Bean的提供者合客户端程序对其进行控制。只有一个遗留的问题:那就是一旦调用这个方法失败，是否能移除这个bean 的实例?答案是不能，但是它将会在回话结束的时候被移除。

消息驱动Bean

消息驱动Bean是唯一一种必须实现一个业务接口的Bean。这个接口指出bean支持的是哪一种消息系统。对于以JMS为基础的MDB来说，这个接口是javax.jms.MessageListener。注意MDB业务接口不是一个真正意义上的业务接口，它只是一个消息接口。

实体Bean

实体Bean使用@Entity注释来标记，所有实体bean中的属性/字段不必使用@Transient注释来标记。实体bean的持久化字段可以通过JavaBean-style机制或者声明为public/protected字段来实现。

实体bean可以使用助手类来描述其状态，但是这些类的实例并没有持久化唯一性(persistent identity)的特性(即，唯一标识这个bean的字段等)，实际上这些助手类与他们的实体bean实例是紧密结合的;并且这些对象还是以非共享方式来访问实体对象的。

实体关联

EJB3.0同时支持Bean之间双向的合单向的关联，它们可以是一对一、一对多、多对一或者是多对多的关联。然而双向关联的两端还要分为自身端 (owning side)和对方端(inverse side)不同的端。自身端负责向数据库通告关联的变更。对于多对多的关联自身端必须明确的声明。实际上对方端通过isInverse=true进行注释 (由此自身端就不必说明了而是由另一段推断出)。看来上面的描述，规范组织还能说让EJB变的简单了吗?

O/R映射

EJB3.0中的O/R映射模型也有了重要的改变，它从原来的abstract-persistence-schema-based变成了现在的Hibernate-inspired模式。尽管目前规范组织还在就此进行讨论但是一个明确的模型将会出现在下一个版本的草案中。

举例来说，O/R映射模型将通过bean类中的注释来声明。而且此方法还会指出对应的具体表和字段。O/R映射模型提供了一套自有的SQL; 而且除了提供一些基本的SQL外还支持某些高层开发的功能。比如，有一个通过@Column注释声明的字段columnDefinition，那么可以写这 样的SQL:columnDefinition="BLOB NOT NULL"

客户端程序模型

一个EJB客户端可以通过@Inject注释以一种“注入”的方式获得一个bean的业务接口引用。你也可以使用另一个注释 @javax.ejb.EJBContext.lookup()来完成上面的操作，但是规范中没有告诉我们一个普通的Java客户端怎样获得一个Bean 的实例，因为这个普通的Java客户端是运行在一个客户端容器中，它无法访问@javax.ejb.EJBContex对象。现在还有另外一种机制来完成上面的工作那就是使用一个超级上下文环境对象:@javax.ejb.Context()。但是规范中没有指出该如何在客户端中使用这个对象。

EJB QL

EJB QL可以通过@NamedQuery来注释。这个注释有两个成员属性分别是name和queryString.一旦定义了这些属性，就可以通过 EntityManager.createNamedQuery(name)来指向这个查询。你也可以创建一个标准的JDBC风格的查询并使用 EntityManager.createQuery(ejbqlString)或EntityManager.createNativeQuery (nativeSqlString)(这个方法用于执行一个本地查询)来执行查询。

EJB QL有两个地方可以定义其参数。javax.ejb.Query接口提供了定义参数、指向查询、更新数据等等方法。下面是一个EJBQL指向查询的例子:

查看复制到剪切板打印

. ..
;@NamedQuery(
name="findAllCustomersWithName",
queryString="SELECT c FROM Customer c WHERE c.name LIKE :custName"
)
.. ..
;@Inject public EntityManager em;
customers = em.createNamedQuery("findAllCustomersWithName")
.setParameter("custName", "Smith")
.listResults();

下面列出了一些EJB QL的增强特性:

支持批量更新和删除。

直接支持内连接和外连接。FETCH JOIN运行你指出关联的实体，Order可以指定只查询某个字段。

查询语句可以返回一个以上的结果值。实际上，你可以返回一个依赖的类比如下面这样:

SELECT new CustomerDetails(c.id, c.status, o.count)
FROM Customer c JOIN c.orders o
WHERE o.count > 100 l 支持group by 和having。

支持where子句的嵌套子查询。

在提交的EJB3.0草案中，EJB QL与标准SQL非常的接近。实际上规范中甚至直接支持本地的SQL(就像我们上面提到的那样)。这一点对某些程序员来说也许有些不是很清楚，我们将在下面进行更详细的讲解。

多样性

方法许可(Method permissions)可以通过@MethodPermissions和@Unchecked注释来声明;同样的，事务属性也可以通过 @TransactionAttribute注释来声明。规范中仍然保留资源引用和资源环境引用。这些一样可以通过注释来声明，但是有一些细微的差别。比如，上下文(context)环境要通过注入工具控制。容器根据bean对外部环境引用自动初始化一个适当的已经声明的实例变量。比如，你可以象下面这样获得一个数据源(DataSource):

;@Resource(name="myDataSource") //Type is inferred from variable
public DataSource customerDB;

在上面的例子中如果你不指定引用资源的名称(name)那么其中的customerDB会被认为是默认值。当所有的引用属性都可得到时侯@Injec注释就可以这样写:

查看复制到剪切板打印

1. ;@Inject public DataSource customerDB;

;@Inject public DataSource customerDB;

容器负责在运行时初始化customerDB数据源实例。部署人员必须在此之前在容器中定义好这些资源属性。

更好的消息是:那些以前必须检测的异常将一去不复返。你可以声明任意的应用程序异常，而不必在再抛出或捕获其他类似 CreateException和FinderException这样的异常。容器会抛出封装在javax.ejb.EJBException中的系统级异常或者只在必要时候抛出IllegalArgumentException或IllegalStateException异常。

EJB文件处理模式

在我们结束本节之前，让我的快速的浏览一下容器提供商在EJB处理模式方面可能的变更。规范中对此并没有明确的表态，但我可以想到至少两种模式。

一种办法是首先利用EJB文件生成类似于EJB2.1部署模式的文件(包括必要的接口和部署描述符)然后再用类似于EJB2.1的方式来部署这个EJB组件。当然，这样产生的部署描述符可能并不标准但是它可以解决同一个容器对EJB2.1和EJB3.0兼容的问题。下面这幅图描述了这一过程。

另一种方法是一种类似于JSP托放的部署模式。你可以把一个EJB文件放到一个预先定义的目录下，然后容器会识别这个EJB并处理它，然后部署并使之可以使用。这种方法可以建立于上面那种方法之上，在支持反复部署时有很大的帮助。考虑到部署的简单性也是EJB3.0规范的目的之一，我真诚的希望在下一个草案出来时能够确定一个模式(至少能有一个非正式的)。

你有什么想法?

EJB3.0规范的制定正在有序的进行，为了使EJB的开发变得更加容易，EJB规范组织作出的努力是有目共睹的。就像他们说的那样，一切对会变得简单，但做到这一点并不容易。目前已经定义了50个注释标记(还有几个将在下一个草案中发布)，每一个都有自己的缺省规则和其他的操作。当然，我真的不希望EJB3.0变成EJB2.1的一个翻版"EJB 3.0 = EJB 2.1 for mmies"(希望这个等式不要成立)。最后，我还是忍不住要提一些我自己的观点:

首先，规范确实使反复部署变得容易了，并且有一个简单的模式来访问运行时环境。我还是觉得home接口应该放弃。

在早期的EJB规范中，实体bean用于映射一个持久化存储。理论上(也许只是理论上)可能需要把实体bean映射到一个遗留的EIS (enterprise information system)系统中。出于将来扩展的考虑这样作是有好处的，并且可以使更多的业务数据模型采用实体bean。也因此其伴随的复杂性使得实体bean不被看好。在本次提交的草案中，一个实体bean只是一个数据库的映射。并且是基于非抽象持久化模式和简单的数据访问模式的更加简单开发。

我对模型变更持保留态度，我认为在EJB中包含SQL脚本片断并不是个好注意。一些开发人员完全反对包含某些“SQL片段 (SQLness)”(比如@Table 和 @Column注释)。我的观点是这些SQLness是好的，据此我们可以清楚的知道我们到底要数据库作些什么。但是某些SQL段我看来并不是很好，比如 columnDefinition="BLOB NOT NULL"，这使得EJB代码和SQL之间的耦合太过紧密了。

尽管对于本地SQL的支持看似很诱人，其实在EJB代码中嵌入SQL是一个非常糟糕的主意。当然，有些办法可以避免在EJB中硬编码SQL，但是这应该在规范中说明，而不能是某些开发人员自己定义的模式。

假设@Table注释只用于类。在运行时通过@Table注释的name属性定义的表名称将必须对应一个实际的数据库表。规范对此应该给予清楚的说明和一致的模式。

规范还需要更清楚的说明客户端编程模型，尤其是普通java客户端。规范中所有的参考都假设或者隐含的使用EJB客户端。而且规范中对客户端的向后兼容方面也没有给出明确的说法。

Transient注释应该重新命名以避免和已有的transient关键字发生冲突。事实上，在这一点上我们更乐于稍微的背离一下 configuration-by-exception原则并且定义一个@Persistent注释来明确的定义持久化字段 @Persistent注释 可以仅仅是一个标记注释或者它可以有几个属性来关联O/R映射注释。

与其他规范的关联

目前可能影响到EJB3.0的JSR有JSR175(java语言元数据工具)和JSR181(Java Web服务元数据)

JSR175已经初步完成并且不会和EJB3.0有太大的冲突;但是JSR181与EJB3.0有两个关联的地方:

Web service接口:EJB规范将采用一种机制适应JSR181以便可以把一个bean实现为一个Web service并告诉Web service如何被客户端调用。

JSR 181计划采用不同的机制来处理安全问题。在早期的规范中EJB建议使用一个一致的机制(MethodPermissions)，但是JSR 181计划使用一个稍微不同的方式(SecurityRoles和SecurityIdentity注释)。同样的RunAs注释的定义也存在这些许差别。这一问题还在解决中最终会在J2EE层的规范中维持其一致性。

在J2EE 1.5中的一些开发规范可能与EJB3.0有关联。除了上面说到的几个关联之外现在没有其他的开发规范与EJB3.0有冲突。

结束语

在使EJB的开发变得简单高效之前，我们还有很长一段路要走。规范组织在降低EJB的开发难度方面起了个好头。O/R映射模型的提议还处在早期阶段，规范组织正在完善它。我希望它不要太复杂也不要与SQL过分的耦合。

‘贰’ 搭建集群服务器tomcat,weblogic,jboss哪个性能最好

tomcat服务器占用资源少，稳定且免费。是一个轻量级的服务器，主要是应用于中小型项目 ，当并发访问的用户比较少时，可以选用tomcat服务器。tomcat服务器是运行jsp和servlet的很好的容器，但是它不支持EJB等。项目在tomcat中的部署很方便。
weblogic服务器：
而相比之下，weblogic服务器则功能更强大了一些，它属于应用级服务器，它不尽支持jsp和servlet，而且还支持更多的java的规范。 他用于开发，集成，部署和管理大型的分布式web应用，网络应用和数据库应用。这种大型的服务器有着自己独特的优势，即标准领先（它的标准包括ejb，jsb，jms，jdbc，xml和wml），扩展性无限（它的体系架构具有高扩展性，主要包括哭户籍连接的共享，资源pooling以及动态网页和ejb组件集群），快速开发（凭借对ejb和jsp的支持，以及其对servlet组件的架构体系，可加速部署应用），部署灵活，可靠等。但是一般的系统部署基本不会用到它，因为一般非基于ejb等的分布式开发项目，仅仅用tomcat即可满足我们的需求，所以无需动用重量级的weblogic。

jboss服务器：
jboss是一个基于j2ee的开放源码应用服务器，它也是免费的。它是一个管理ejb的容器，jboss核心服务仅支持ejb服务器，所以是不包括jsp和servlet的web容器。当然了，它可以和tomcat等进行绑定使用来同时支持jsp，servlet以及ejb的规范。jboss有一个典型的特点：当有servlet的系统调用到jboss里面的ejb时不经过网络，因为jboss和web服务器在同一个java虚拟机中运行，这可以大大提高运行效率和安全性。
这三个只有weblogic是商业的软件，所以你希望性能好的话，就用weblogic最好。

‘叁’ JAVA与J2EE

随着Internet网络的迅速发展，基于互联网的企业应用要求软件平台具有开放性、分布性和平台无关性。于是就相继出现了RPC/COM/CORBA等技术，但这些技术在实际应用中存在着许多不足和局限。它们的特定协议难以通过防火墙，因而不适于Web上的应用开发。为了进一步开发基于Web的应用，出现了Sun公司的Sun ONE（Open Net Environment 开发网络环境）和Microsoft公司的.NET等Web 服务技术体系。

Sun ONE体系结构以Java语言为核心，包括J2SE/J2EE/J2ME和一系列的标准、技术及协议。它包括Sun独有的iPlanet软件系列，其中有在市场上受欢迎的LDAP目录服务器软件，以及Forte for Java——便于在任何环境下书写Java 语言的软件工具。我们很容易就能从网上免费获得和使用包括Java 集成开发环境、Java数据库和中间件（Application Server）服务器等产品，以及它们的源代码。Sun ONE更接近或能满足互联网在智能化Web服务方面对分布性、开发性和平台无关性的要求。

随着Java技术的不断发展，它根据市场进一步细分为:针对企业网应用的J2EE（Java 2 Enterprise Edition）、针对普通PC应用的J2SE（Java 2 Standard Edition）和针对嵌入式设备及消费类电器的J2ME（Java 2 Micro Edition）三个版本。本文就Sun ONE的Java核心应用——J2SE/J2EE/J2ME作一些介绍。

J2EE技术应用

J2EE是Sun公司推出的一种全新概念的模型，比传统的互联网应用程序模型更有优势。

J2EE模型

J2EE的应用编程模型（J2EE Blueprints）提供了一种用于实施基于J2EE多层应用的文档和实例套件的体系模型，简化了这项复杂的工作。它被开发人员用作设计和优化组件，以便开发人员从策略上对开发工作进行分工。

J2EE应用编程模型要求开发者将自己的工作分成两类：商业逻辑和表示逻辑，其余则由系统资源自动处理，不必为中间层管道进行编码。这样，开发人员就能将更多的时间花在商业逻辑和表示逻辑上。对重视缩短项目周期的公司来说，这种转变深受欢迎。

J2EE平台

J2EE平台是运行J2EE应用的标准环境，由J2EE部署规范（一套所有J2EE平台产品都必须支持的标准）、IETF标准集和CORBA标准组成。最新的J2EE平台还添加了JavaBean组件模型。开发人员可以利用JavaBean组件模型来自定义Java类实例，并可通过已定义的事件访问Java类。

J2EE支持EJB，因此开发人员可以执行多用户交易功能。当在J2EE服务器上运行时，Enterprise JavaBeans将应用逻辑分成可再利用和可扩展的代码段。Enterprise JavaBeans并不是新特征，但是通过定义标准客户端和服务API，J2EE增强了它的能力和可移植性。

EJB在服务器的一个容器内运行，提供所有典型的中间层服务，如事务管理、安全、远程客户连接、生存周期管理和数据库连接缓冲。为了让事务系统在存在EJB容器的情况下运行，开发人员只需在部署描述文件中定义Beans的事务属性即可。

J2EE通过定义一组标准的结构来实现它的优势，例如：

1.J2EE Application Programming Model，是一种用于开发多层次、瘦型客户用户程序的标准设计模型；

2. J2EE Platform，是一个标准的平台，用来整合J2EE的应用程序，并指定一系列的接口和方法；

3. J2EE Compatibility Test Suite，是一套兼容测试组件，用来检测产品是否同J2EE平台兼容；

4.J2EE Reference Implementation，用来示范J2EE的能力。

J2EE服务器

Sun的J2EE服务器通过Java 命名和目录接口（JNDI）、认证、HTTP及与Enterprise JavaBeans兼容的能力，提供命名和目录服务。JNDI是Java平台的一种标准扩展版，向企业内的命名和目录服务提供具有Java功能的，带有统一接口的应用，包括LDAP。

J2EE服务器还利用了Java Servlet技术。Java Servlet可以看作是运行在服务器上的一个小程序，它向开发人员提供以组件为基础创建基于Web应用的、独立于平台的方法。它不像利用CGI那样具有性能局限。Java Servlet是一种扩展Web服务器功能的简单技巧。由于它是用Java编写的，因而能够访问整个Java API库，也包括用于访问企业数据库的JDBC API。

JSP是Java Servlet的一种扩展。Java Servlet提供开发和显示来自服务器的交互式Web页。如今JSP又有了进一步的改进，它使得创建和支持静态模板和动态内容相结合的HTML和XML页面更加容易。

安全性

J2EE平台定义了一种标准的公开存取控制规则，当程序在企业平台上开发时就已被程序师定义和解释了。J2EE也需要提供一个标准的注册机制，以便应用程序不会将这些注册机制和逻辑相混合，从而使相同的工作执行于大量的不同环境中时并不需要改变源代码。例如：J2EE应用程序开发人员可以指定几个安全级别，当用户访问数据时，他们可写出代码来检查当前用户权限的级别。在开发阶段，开发人员赋予多组用户适当的安全级，使应用程序在执行限制操作之前能够容易的判断限制级。

J2EE 平台是Java技术企业级应用的最佳平台，它可以让程序员迅速、快捷地开发和分布企业级应应用程序。以下便是它的相关技术：

1.Enterprise JavaBeans Architecture，企业级JavaBeans 定义了一个应用程序接口。它可以使程序员迅速开发、发布和管理跨平台的、基于组件的企业级应用程序。

2.JavaServer Pages，JSP 技术提供了一种简单、快速的方法来创建动态网页。通过它，可以快速地开发基于Web的应用程序，并且这些应用程序都是与平台无关的。因为JSP与ASP很相似，所以熟悉ASP的人学习它就很容易了。

3.Java Servlet，提供了应用程序接口。通过它可以简单快速地开发并扩展服务器功能。就发展趋势来看，它将来有可能取代CGI。

4.J2EE Connector，提供了一种标准结构来联接不同的企业信息平台。

5.Java Naming and Directory Interface(JNDI)，在Java 平台与商业信息之间，JNDI提供了统一、无缝的标准化连接。通过使用JNDI，程序员可以在企业多命名与目录服务之间传送Java 应用程序。

6.Java Interface Definition Language(JIDL),通过使用CORBA，可以提供协同工作的能力。JIDL包括一个IDL-to-Java 编译器和支持IIOP（Internet Inter-Orb Protocol）的ORB。

7.JDBC,几乎是为所有的数据库提供了统一的接口，同时可以创建高级工具和接口。

8.Java Message Service(JMS)，它几乎规范了所有企业级消息服务，如可靠查询、发布消息、订阅杂志等各种各样的PUSS/PULL技术的应用，并且为它们提供了一个标准接口。

9.Java Transaction API(JTA)，为分布式系统中可处理的应用程序规定了一个高级的管理规范。

10.JavaMail,JavaMail应用程序接口提供了一整套模拟邮件系统的抽象类。通过JavaMail，可以创建邮件或消息应用程序。

11.RMI-IIOP,使用它就可以只用Java 技术和Java RMI接口开发客户机与服务器的远程接口。

J2EE使用固定的文件格式捆绑某个模块：用.ear文件捆绑J2EE应用程序；用.jar捆绑Enterprise Bean。例如，一个.ear文件包含一个.xml文件作为其分布描述，还包含一个或多个.jar和.war文件；一个.jar文件除了包含它的分布描述外，还包含了作为Enterprise bean的.class文件。

J2EE应用程序的开发阶段分为四步：1.Enterprise Bean创建；2.Web Component创建；3.J2EE应用程序装配；4.J2EE应用程序分布。以下是J2EE兼容产品部分列表：

BEA WebLogic Server 6.0、Borland App Server、HP Bluestone Total-e-Server、IBM WebSphere Application Server、IONA iPortal Application Server、iPlanet Application Server、Macromedia JRun Server、Oracle 9i Application Server、SilverStrean Application Server、Sybase EAServer、TogetherSoft ControlCenter、Java 2 SDK Enterprise Edition。

J2ME技术的应用

J2ME（Java 2 Platform Micro Edition）是为无线电子市场所设计的，包括JVM规范和API规范。其API规范是基于J2SE（Java 2 Standard Editon)的。J2ME 定义了一套合适的类库和虚拟机技术。这些技术可以使用户、服务提供商和设备制造商通过物理（有线）连接或无线连接，按照需要随时使用丰富的应用程序。

J2ME又被称为Java 2 微型版，被使用在各种各样的消费电子产品上，例如智能卡、手机、PDA、电视机顶盒等方面。当然了，J2ME也提供了Java语言一贯的特性，那就是跨平台和安全网络传输。它使用了一系列更小的包，而且Javax.microedition.io 为J2SE包的子集。J2ME可以升级到J2SE和J2EE。

在J2ME出现之前，我们更多接触到的是Java卡（Java Card）、嵌入式Java（Embedded Java）和实时Java（Real Time Java）等。其中Java卡是针对SIM卡、智能卡等设备而定制的最小Java子集，比J2ME还要小，移植性也不强。嵌入式Java则针对特殊用户自行配置Java类库和VM（Virtual Machine，虚拟机）。它对资源需求极小，可运行在无图形用户接口和网络的设备上，可以添加用户专用的API，但是它就无法移植。实时Java是由IBM领导的实时定制Java专家组负责实施的，现在还在不断完善中。不过，从严格意义上来说，它们都不是真正的J2ME。

像其它版本一样，J2ME具有很多Java技术特性，主要有：

1.可以在各种支持Java的设备上运行；

2.代码短小；

3.充分利用Java语言的优势；

4.安全性好；

5.用J2ME实现的应用可以方便地升级到J2SE、J2EE。

J2ME的配置和框架

为了支持用户和嵌入式市场提出的灵活性和可定制性要求，J2ME被设计得更加模块化和可缩放化。J2ME在设备原有的操作系统上建造了3层软件来实现这种要求：

1.JVM层，这层基于宿主操作系统，按照某一种J2ME的配置，实现了JVM。

2.配置层，这层对于用户可见度要低一些，但对框架层非常重要。它针对“水平”市场的需求，定义了Java虚拟机的最小功能集和Java类库的最小集合。在某种意义上，配置层定义了开发者在所有设备上都可以使用Java特性和类库的“最小公分母”。

3.框架层，这层对于用户和应用程序提供者来说是最常见的。它针对“垂直”市场的需求，定义了Java虚拟

‘肆’ 消息队列(mq)是什么

是生产者先将消息投递一个叫队列的容器中，然后再从这个容器中取出消息，最后再转发给消费者。

消息队列是 Microsoft 的消息处理技术，它在任何安装 Microsoft Windows 的计算机组合中，为任何应用程序提供消息处理和消息队列功能，无论这些计算机是否在同一个网络上或者是否同时联机。

消息队列网络是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息，有些保存整个网络的重要信息，而有些只是发送和接收消息。

消息队列的类型介绍：

消息队列目前主要有两种类型：POSIX消息队列以及系统V消息队列，系统V消息队列目前被大量使用。每个消息队列都有一个队列头，用结构struct msg_queue来描述。队列头中包含了该消息队列的大量信息。包括消息队列键值、用户ID、组ID、消息队列中消息数目等等。

消息队列就是一个消息的链表，可以把消息看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以向消息队列中按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列是随内核持续的。