- 浏览: 124836 次
- 性别:
- 来自: 重庆
-
文章分类
最新评论
-
sunxiangfei91:
引用[*][url][/url]
Spring使用MimeMessageHelper -
lhb3015:
lz, Coder 这个类的代码呢??
Java RSA算法加密 -
b_lee:
顶顶顶 加两个字,再顶
Facelets是JSF更好的外衣 -
zhuqing08:
楼主 Coder 这个类的代码呢?
Java RSA算法加密 -
evajhhot:
貌似不行 有异常
BlazeDS 与Spring集成指南之一
这个系列的文章是EJB3.1专家小组正在开发的下个版本JavaEE规范的预览。EJB3.0去掉了沉重的编程模型而带给Java EE 5一个更简单的编程环境。EJB3.1目标是在EJB3.0带来的成功之上,将简单开发深入下去并增加一些急需的特性。
在这第一篇文章中,我将涵盖已经讨论的很深入的两个特性——选择性的为EJBs和Singleton Bean创建接口。同时,我也将提到一些已经开始考虑的可能出现的新特性。记住,所有的这些都不是最终版本。
EJB 接口是可选择的
首先得一个改变是把Session Bean 接口变成可选的了——让EJBs真正像是POJOs——去掉了最后遗留的障碍。
基于接口的编程确实是书写松耦合,单元可测试的应用的一个有用的技术。这正是EJB2.1和Spring推崇组件接口的原因。事实上,就算是EJB3.0 Session Beans 也至少需要一个接口。
这样做的麻烦是组件接口在很多情况下其实并不需要。在更多的情况下,一个简单的Java对象正是你最需要的,尤其是在你不需要做过多的单元测试和松耦合并不是应用的最核心要求的时候。
EJB3.1允许你这样做。现在,Session Beans不需要任何的接口,就象JPA Entity 和Message Driven Beans。所有你需要做的就是给一个POJO标记上@Stateless或者@Stateful来得到所有的EJB功能。下面是一个根据《EJB 3 in Action》中Session Bean章节的一个列子修改的:
@Stateless public class PlaceBidBean {
@PersistenceContext
Private EntityManager entityManager;
public void placeBid (Bid bid) {
entityManager.persist(bid);
}
}下面为这个bean添加了一些新的特性:
@Stateless @WebService
public class PlaceBidBean {
@PersistenceContext
private EntityManager entityManager;
@WebMethod public void placeBid (Bid bid) {
entityManager.persist(bid);
}
}在上面的例子中,我们使用JAX-WS 2.0吧placeBid方法发布为一个web service。同时我们使用JPA来持久化一个Bid entity。PlaceBidBean拥有了所有无状态Session Bean的功能,包括在后端的对象池、线程安全、组件生命周期、拦截器、安全和声明事务。比如,如果你对EJB3.0熟悉的话,你会想placeBid方法是默认的被一个容器管理的JTA包装起来的。该bean同时也可作为RMI基础的远程端。
除了能和简单的bean类型一起工作,去掉接口也让EJB3.1 beans在WebBeans中简单实用。WebBeans(JSR 299),在JBoss Seam中得到大量灵感。WebBeans无缝的集成了JSF,JPA和EJB3.1,从而让Java EE 6整整的变成了一个整体。
Singleton Beans
EJB3.1 Singleton Beans 是何GOF Singleton 模式相等的组件。在Java EE 上下文中,他们被用来保存应用级别的共享数据。想象你需要缓存一些数据在内存中而不是重复的从数据库中反复的查询。Stateless Session Beans和Stateful Session Beans 都不能达到这种需求。虽然Stateful Session Beans可以拥有session级别的缓存,但它的数据不能再整个应用级别其他的组件轻松访问。
有很多种方法可以满足这种需求,一种简单的办法就是使用static 属性或者GOF Singleton模式的POJOs。一种稍微复杂的解决思路是使用Servlet容器的Applcation级别空间,JBoss Cache,OSCache,JCS和SwarmCache等。商业的解决方案包括Tangosol Coherence和Terracotta。虽然这些方法在大部分情况下很有用,但是他们也存在很多的不足。一些不是线程安全的(static fields,Singleton POJOs),一些不支持事务的(Singleton POJOS,Servlet application scope,OSCache,JCS,SwarmCache),这些都不支持远程并且没有任何安全机制。除了这些通用的解决方案之外,现在可以使用Enter EJB3.1 Singletons来解决。
容器用来保持对一个EJB3.1 Singleton实例的唯一性。这意味着Singletons可以保存应用层中的状态。因为是一个EJB,所以,Singleton拥有所有的中间服务——声明事务管理,安全,远程,线程管理,依赖注入,组件生命周期回调,拦截器等等。和其它的EJBs一样,Singleton也是标注性POJO。下面是一个例子:
@Singleton
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
@PreDestroy
private void destroy() {
entityManager.merge(rate);
}
public void setRate(Rate rate) {
this.rate = rate;
}
public Rate getRate() {
return rate;
}
}在这个列子中使用了JPA和bean生命周期回调在启动阶段加载数据,并在bean销毁的时候保存其值。所有的调用getRate和setRate的方法都是直接连接到DiscountRateBean的唯一实例的共享数据。你将会发现一个有趣的问题——如果容器没有调用pre-destroy回调方法的机会,任何一个修改都可能丢失。我们将在下面的文章中介绍怎么通过一个类似于Corn的定时器(cron-like timers)来减小这种问题。
默认的,所有的Singleton方法都是现成安全的并且支持事务。这意味着多线程的调用这个bean是有序列的,并且所有的方法都假设带有一个REQUIRED的事务属性。你可以通过使用@TransactionManagement和@TransactionAttribute标签来改变事务的类型——就像你在Stateful或者Stateless Session Bean中那样。如果你在现实中接触过大规模应用的话,你会知道吧getRate和setRate方法都列队的访问,是很大的一个性能瓶颈。现实中,我们会在getRate方法上使用一个只读锁并且在setRate方法上使用一个读-写锁。你可以使用@ConcurrencyAttribute实现:
@Singleton
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
@PreDestroy
private void destroy() {
entityManager.merge(rate);
}
@ConcurrencyAttribute(READ_WRITE_LOCK)
public void setRate(Rate rate) {
this.rate = rate;
}
@ConcurrencyAttribute(READ_LOCK)
public Rate getRate() {
return rate;
}
}熟悉Doug Lea's工作的人都知道,READ_LOCK和READ_WRITE_LOCK术语来自于java.util.concurrent。一些应用的共享数据确实是只读的,任何锁其实都不是必要的。在这种情况下,你只需要创建unsynchronized Singleton:
@Singleton
@ConcurrencyAttribute(NO_LOCK) // READ_LOCK would also work...
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
public Rate getRate() {
return rate;
}
}
@ConcurrencyAttribute(READ_LOCK),@ConcurrencyAttribute(READ_WRITE_LOCK)和@ConcurrencyAttribute(NO_LOCK)的一个改变是这几个标签将更改为@ConcurrencyReadLock,@ConcurrencyReadWriteLock和@ConcurrencyNoLock。为了结合这种基础的标签格式,@TransactionAttribute会分成@TransactionRequired,@RequiresNewTranscation,@TransactionNotSupported等等。不过有些意见认为这样会增加代码的复杂度。
同样,你可能不希望容器来管理Singleton的并发,下面是一个bean manage concurrency的例子:
@Singleton
@ConcurrencyManagement(BEAN)
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
@PreDestroy
private void destroy() {
entityManager.merge(rate);
}
public synchronized void setRate(Rate rate) {
this.rate = rate;
}
public synchronized Rate getRate() {
return rate;
}
}注意这个例子中我们同步的关键字(synchronized keyword)来管理并发。因为容器不需要接口了,所以你可以使用任何你喜欢的同步管理机制,包括但并不仅仅限制为java.util.concurrent包。目前,新的concurrency管理特性仅仅限制于EJB3.1 Singleton.不过可能会扩展到其他的bean上。
Singletons 同样也能通过加载顺序提供延迟/迫切加载,和Singleton的依赖管理。这里我们暂时不讨论这些话题。虽然规范没有提到集群的支持,但因该是集群安全的。
EJB3.1更多的特性
以上提到的两个特点只是冰山一角。还有很多有趣的特性列在JSR议案中,下面是其中一些:
1,在Servlet容器中支持EJBs,包括简单打包选项。目前的想法是允许EJBs放在WEB-INF/classes目录下面,吧ebj-jar.xml放在WEB-INF同级。就象web.xml。同样,你可以把EJB JAR
包放在WEB-INF/lib下
2,EJB Timer服务增强类似CRON的作业调度机制,开发时时间对象创建,Stateful Session Bean使用调度对象标记等。
3,通过Stateful Session Bean web service终点提供有状态的web service。
在这第一篇文章中,我将涵盖已经讨论的很深入的两个特性——选择性的为EJBs和Singleton Bean创建接口。同时,我也将提到一些已经开始考虑的可能出现的新特性。记住,所有的这些都不是最终版本。
EJB 接口是可选择的
首先得一个改变是把Session Bean 接口变成可选的了——让EJBs真正像是POJOs——去掉了最后遗留的障碍。
基于接口的编程确实是书写松耦合,单元可测试的应用的一个有用的技术。这正是EJB2.1和Spring推崇组件接口的原因。事实上,就算是EJB3.0 Session Beans 也至少需要一个接口。
这样做的麻烦是组件接口在很多情况下其实并不需要。在更多的情况下,一个简单的Java对象正是你最需要的,尤其是在你不需要做过多的单元测试和松耦合并不是应用的最核心要求的时候。
EJB3.1允许你这样做。现在,Session Beans不需要任何的接口,就象JPA Entity 和Message Driven Beans。所有你需要做的就是给一个POJO标记上@Stateless或者@Stateful来得到所有的EJB功能。下面是一个根据《EJB 3 in Action》中Session Bean章节的一个列子修改的:
@Stateless public class PlaceBidBean {
@PersistenceContext
Private EntityManager entityManager;
public void placeBid (Bid bid) {
entityManager.persist(bid);
}
}下面为这个bean添加了一些新的特性:
@Stateless @WebService
public class PlaceBidBean {
@PersistenceContext
private EntityManager entityManager;
@WebMethod public void placeBid (Bid bid) {
entityManager.persist(bid);
}
}在上面的例子中,我们使用JAX-WS 2.0吧placeBid方法发布为一个web service。同时我们使用JPA来持久化一个Bid entity。PlaceBidBean拥有了所有无状态Session Bean的功能,包括在后端的对象池、线程安全、组件生命周期、拦截器、安全和声明事务。比如,如果你对EJB3.0熟悉的话,你会想placeBid方法是默认的被一个容器管理的JTA包装起来的。该bean同时也可作为RMI基础的远程端。
除了能和简单的bean类型一起工作,去掉接口也让EJB3.1 beans在WebBeans中简单实用。WebBeans(JSR 299),在JBoss Seam中得到大量灵感。WebBeans无缝的集成了JSF,JPA和EJB3.1,从而让Java EE 6整整的变成了一个整体。
Singleton Beans
EJB3.1 Singleton Beans 是何GOF Singleton 模式相等的组件。在Java EE 上下文中,他们被用来保存应用级别的共享数据。想象你需要缓存一些数据在内存中而不是重复的从数据库中反复的查询。Stateless Session Beans和Stateful Session Beans 都不能达到这种需求。虽然Stateful Session Beans可以拥有session级别的缓存,但它的数据不能再整个应用级别其他的组件轻松访问。
有很多种方法可以满足这种需求,一种简单的办法就是使用static 属性或者GOF Singleton模式的POJOs。一种稍微复杂的解决思路是使用Servlet容器的Applcation级别空间,JBoss Cache,OSCache,JCS和SwarmCache等。商业的解决方案包括Tangosol Coherence和Terracotta。虽然这些方法在大部分情况下很有用,但是他们也存在很多的不足。一些不是线程安全的(static fields,Singleton POJOs),一些不支持事务的(Singleton POJOS,Servlet application scope,OSCache,JCS,SwarmCache),这些都不支持远程并且没有任何安全机制。除了这些通用的解决方案之外,现在可以使用Enter EJB3.1 Singletons来解决。
容器用来保持对一个EJB3.1 Singleton实例的唯一性。这意味着Singletons可以保存应用层中的状态。因为是一个EJB,所以,Singleton拥有所有的中间服务——声明事务管理,安全,远程,线程管理,依赖注入,组件生命周期回调,拦截器等等。和其它的EJBs一样,Singleton也是标注性POJO。下面是一个例子:
@Singleton
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
@PreDestroy
private void destroy() {
entityManager.merge(rate);
}
public void setRate(Rate rate) {
this.rate = rate;
}
public Rate getRate() {
return rate;
}
}在这个列子中使用了JPA和bean生命周期回调在启动阶段加载数据,并在bean销毁的时候保存其值。所有的调用getRate和setRate的方法都是直接连接到DiscountRateBean的唯一实例的共享数据。你将会发现一个有趣的问题——如果容器没有调用pre-destroy回调方法的机会,任何一个修改都可能丢失。我们将在下面的文章中介绍怎么通过一个类似于Corn的定时器(cron-like timers)来减小这种问题。
默认的,所有的Singleton方法都是现成安全的并且支持事务。这意味着多线程的调用这个bean是有序列的,并且所有的方法都假设带有一个REQUIRED的事务属性。你可以通过使用@TransactionManagement和@TransactionAttribute标签来改变事务的类型——就像你在Stateful或者Stateless Session Bean中那样。如果你在现实中接触过大规模应用的话,你会知道吧getRate和setRate方法都列队的访问,是很大的一个性能瓶颈。现实中,我们会在getRate方法上使用一个只读锁并且在setRate方法上使用一个读-写锁。你可以使用@ConcurrencyAttribute实现:
@Singleton
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
@PreDestroy
private void destroy() {
entityManager.merge(rate);
}
@ConcurrencyAttribute(READ_WRITE_LOCK)
public void setRate(Rate rate) {
this.rate = rate;
}
@ConcurrencyAttribute(READ_LOCK)
public Rate getRate() {
return rate;
}
}熟悉Doug Lea's工作的人都知道,READ_LOCK和READ_WRITE_LOCK术语来自于java.util.concurrent。一些应用的共享数据确实是只读的,任何锁其实都不是必要的。在这种情况下,你只需要创建unsynchronized Singleton:
@Singleton
@ConcurrencyAttribute(NO_LOCK) // READ_LOCK would also work...
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
public Rate getRate() {
return rate;
}
}
@ConcurrencyAttribute(READ_LOCK),@ConcurrencyAttribute(READ_WRITE_LOCK)和@ConcurrencyAttribute(NO_LOCK)的一个改变是这几个标签将更改为@ConcurrencyReadLock,@ConcurrencyReadWriteLock和@ConcurrencyNoLock。为了结合这种基础的标签格式,@TransactionAttribute会分成@TransactionRequired,@RequiresNewTranscation,@TransactionNotSupported等等。不过有些意见认为这样会增加代码的复杂度。
同样,你可能不希望容器来管理Singleton的并发,下面是一个bean manage concurrency的例子:
@Singleton
@ConcurrencyManagement(BEAN)
public class DiscountRateBean {
@PersistenceContext
private EntityManager entityManager;
private Rate rate;
@PostConstruct
private void init() {
rate = entityManager.find(Rate.class, 1);
}
@PreDestroy
private void destroy() {
entityManager.merge(rate);
}
public synchronized void setRate(Rate rate) {
this.rate = rate;
}
public synchronized Rate getRate() {
return rate;
}
}注意这个例子中我们同步的关键字(synchronized keyword)来管理并发。因为容器不需要接口了,所以你可以使用任何你喜欢的同步管理机制,包括但并不仅仅限制为java.util.concurrent包。目前,新的concurrency管理特性仅仅限制于EJB3.1 Singleton.不过可能会扩展到其他的bean上。
Singletons 同样也能通过加载顺序提供延迟/迫切加载,和Singleton的依赖管理。这里我们暂时不讨论这些话题。虽然规范没有提到集群的支持,但因该是集群安全的。
EJB3.1更多的特性
以上提到的两个特点只是冰山一角。还有很多有趣的特性列在JSR议案中,下面是其中一些:
1,在Servlet容器中支持EJBs,包括简单打包选项。目前的想法是允许EJBs放在WEB-INF/classes目录下面,吧ebj-jar.xml放在WEB-INF同级。就象web.xml。同样,你可以把EJB JAR
包放在WEB-INF/lib下
2,EJB Timer服务增强类似CRON的作业调度机制,开发时时间对象创建,Stateful Session Bean使用调度对象标记等。
3,通过Stateful Session Bean web service终点提供有状态的web service。
发表评论
-
EJB3的XML Schema第十四讲
2010-06-25 21:24 885result-type-mappingType 用在query ... -
EJB 3.1五大模式改进令Java EE 6更好用之二
2010-04-10 16:34 1026异步会话Bean调用 EJB 3.1引入了一个强大功能, ... -
EJB3的XML Schema第十三讲
2010-03-28 13:24 974<xsd:complexType name=" ... -
EJB 3.1五大模式改进令Java EE 6更好用之一
2010-02-05 22:20 938EJB 3.0是Java EE 5平台的一部分,相对前面的版本 ... -
EJB3的XML Schema第十二讲
2010-01-17 11:24 838method-intf 元素可以和方法元素的三种用法一起使用。 ... -
EJB3的XML Schema第十一讲
2010-01-09 09:49 742紧接上文: 在method 元素中,methodType 元素 ... -
EJB3的XML Schema第十一讲
2009-12-24 13:18 818紧接上文: 在method 元素中,methodType 元素 ... -
EJB3的XML Schema第十讲
2009-12-12 14:14 737紧接上文: <xsd:attribute name=&q ... -
POJO与Spring和EJB 3.0的对比
2009-11-15 16:31 662简化企业级软件开发的关键是提供一个隐藏了复杂性(例如事务、安全 ... -
EJB3的XML Schema第八讲
2009-11-07 10:50 774紧接上文: <xsd:group r ... -
EJB3的XML Schema第七讲
2009-10-24 08:02 912紧接上文: <xsd:selector ... -
EJB3的XML Schema第六讲
2009-10-02 07:36 1013紧接上文: <xsd:selector xpath=&q ... -
EJB3的XML Schema第五讲
2009-09-26 12:06 903紧接上文: <xsd:sequence> < ... -
EJB3的XML Schema第四讲
2009-09-06 14:31 828紧接上文: <xsd:sequence> < ... -
EJB3的XML Schema第二讲
2009-08-27 13:41 896紧接上文: <xsd:key name= ... -
EJB3的XML Schema第一讲
2009-08-25 09:37 1164在XML Schema 中的注释规定了XML Schema 机 ... -
EJB3部署文件中使用拦截器元素语法
2009-08-13 12:21 951拦截器元素语法有四种可能的风格: 风格1: <inter ... -
EJB3在部署描述中声明环境条目
2009-08-09 11:24 868Bean 提供者必须声明从企业bean 代码中访问的所有环境条 ... -
Java EE 6新特性尝鲜:EJB 3.1重要变化总览
2009-07-23 15:39 1285移除了本地事务接口:EJB 3.0移除了复杂的本地和远程接口, ... -
EJB3中Bean管理的事务分隔
2009-07-16 08:18 1332注意,只有会话和消息 ...
相关推荐
因此,在EJB 3.1中,Sun继续推进改革的步伐,针对EJB 2.1中的一些遗留问题进行了改进,并引入了一系列新的特性和技术。 #### 二、EJB 3.1 的主要特点 ##### 1. **No-Interface View (非接口视图)** EJB 3.1 引入...
EJB 3.1是其一个重要的版本,相较于3.0,它引入了许多改进和新特性,使得EJB更加易用且更接近轻量级框架的开发体验。这个压缩包中的源代码是《EJB 3.1 Cookbook》一书的配套实例,可以帮助读者深入理解和应用书中...
- **标题**:“EJB3.1_JSR 318-EJB3.1” - **描述**:此文档是EJB 3.1规范(JSR 318),与EJB 3.0相比,新增的功能包括: - 取消接口要求。 - 引入单例会话Bean(Singleton session bean)。 - 支持异步调用。 -...
#### EJB3.1的新特性 EJB 3.1作为EJB 3.0的更新版本,引入了一些新的特性和改进,以提高开发效率和增强功能性: - **简化注解**:EJB 3.1进一步简化了注解的使用,使得开发者能够更加直观地定义组件。 - **异步...
EJB 3.1不仅对EJB组件的功能进行了扩展,还引入了一些新的要求和限制条件,以确保组件的一致性和可维护性。 ##### 3.1 组件类型 EJB 3.1支持三种类型的EJB组件:会话Bean、消息驱动Bean和实体Bean。每种类型都有其...
3. **高级特性讲解**:介绍了 EJB 3.1 中新增的特性,如异步调用、RESTful 服务支持等。 4. **安全性管理**:探讨如何利用 EJB 3.1 的安全机制保护应用程序免受攻击。 5. **性能优化技巧**:分享了一系列提高 EJB ...
EJB 3.1在此基础上进一步强化了这些特性,使企业级开发变得更加友好和高效。 1. **注解增强**: - EJB 3.1扩大了注解的使用范围,使得开发者无需编写XML配置文件,通过在类或方法上直接添加注解,就能声明bean的...
EJB 3.1是EJB规范的一个重大改进,引入了许多简化开发的特性,如注解驱动的编程模型,使得EJB更加易用。 在EJB 3.1中,主要有三种类型的EJB组件: 1. **会话bean(Session Beans)**:代表业务逻辑,可以是无状态...
EJB 3.1的重要特性包括: 1. **注解驱动的开发**:与EJB 2.x相比,EJB 3.1大量使用了Java注解,使得开发者无需编写大量的XML配置文件即可声明组件的生命周期和行为。例如,`@Stateless`、`@Stateful`、`@Singleton`...
EJB 3.1通过引入新的特性和对现有功能的改进,极大地提升了开发效率和应用性能。对于那些希望构建稳定、高效的企业级应用的开发者来说,EJB 3.1是一个值得深入研究的技术。通过对EJB 3.1的学习和实践,开发者能够更...
Enterprise JavaBeans (EJB) 3.1 是一项重要的企业级应用开发技术规范,它在 EJB 3.0 的基础上进一步简化了应用程序的开发流程,并引入了一系列的新特性来提高开发效率和降低复杂度。 #### 发展历程与定位 EJB 3.1 ...
EJB 3.1引入了许多简化开发的特性,如无XML配置、注解驱动的编程模型和轻量级会话bean。在本例中,我们将使用Session Bean处理业务逻辑,而Message-Driven Bean则用于处理消息队列,以实现异步通信。 Java ...
- **EJB3.1特性支持**:说明了TongWeb6.0中EJB3.1规范的支持情况。 - **EJB实例管理**:介绍了如何在TongWeb6.0中管理和监控EJB实例。 - **查看/编辑EJB配置属性**:提供了编辑EJB配置的方法。 - **EJB远程调用**:...
EJB3.0是EJB规范的一个重要版本,它引入了许多简化开发的特性,使得EJB更加易用。 EJB3.0的核心概念包括: 1. **Session Bean**: - **有状态Session Bean(Stateful Session Bean)**:每个客户端会话对应一个...
2. **创建实体Bean**:在新创建的EJB模块中,右键单击“src/main/java”目录,选择“New” -> “Other” -> “Java” -> “EJB” -> “Entity Bean”。输入Bean的类名和对应的数据库表名,然后点击“Finish”。 3. ...
1.0 [JEE7 + EJB 3.1 + JPA 2.1 + JSF 2.2]" 是一个基于Java Enterprise Edition (JEE) 平台开发的医疗信息化系统,特别针对病理诊所的管理需求。这个系统集成了多个关键的技术组件,包括Enterprise JavaBeans (EJB...
11. **EJB 3.1和以上版本的新特性** - 自动化的注解驱动编程降低了EJB的复杂性,如@Stateless、@Stateful、@Singleton等。 - EJB 3.1引入了无接口视图,简化了客户端调用。 - Asynchronous方法调用允许异步执行...