资讯频道 → 编程语言
阅读更多

18顶
0踩

编程语言

原创新闻 JavaEE6的进化——开始迈向轻量级？？？

2008-02-26 22:29 by 资深记者 kyo100900 评论(12) 有8834人浏览
Bean JSF

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

Roberto Chinnici最近写了一些关于围绕当前JavaEE6轮廓的建议。现有的6名JavaEE专家组成员更愿意从web开发应用方面收集反馈信息。因为时间关系，他们也不可能完成更多的要求。

 

基本的web应用程序轮廓包括以下API：Servlet3.0，JSP2.2，JSR-45(讨论是否支持其它语言)，EL1.2，JSTl1.2以及JSR-250(Java平台的通用Annotation).

 

颇具争议的内容如以下：EJB3.1(Lite)（注：Lite是指清淡的意思，这里应该表示成轻量级吧），JTA1.1，JPA2.0，JSF2.0以及Web Beans1.0。Reberto指出两个最具争议的争议的焦点：

  1. Web Beans和JSF2.0的加入
  2.  EJB3.1
  

“EJB3.1(Lite)的想法是将其实现为EJB3.1的一个子集。目前这个’lite’子集还没有完全定下来，但可能会包含由EJB3.0引入的基于Annotation的编程模型，并且session bean可能仅仅限制于local interfaces。换句话说你可以使用标注(Annotated)过的session bean来协同local interface在满足条件的Web容器下开发了。但如果你这就无法使用EJB2.1风格的session bean，EJB3.0的message-driven bean以及带有remote interface的EJB3.0 stateful bean了。

 

很重要的一点是刚才仅仅只是一个假设，实际上真正的EJB3.1(Lite)还要完全取决于专家组成员(JSR-318)。因此就算真要出EJB3.1，其最终的特性还得等专家组们一致通过才行。”

   

通过刚才Roberto Chinnici的言行，我们可以看到“兼容性”就是一个问题。

 

JSF/Web Beans的争议是可以理解的。不管怎么说，JSF算不上极其笨重，但也不轻快。考虑到很多人不用JSF。因为说将JSF/Web Beans做为JavaEE6中的一部分的做法有点武断。

 

你怎么看待这些呢？应该还像以前那么提供重量级的EJB, transaction以及JPA，还是使用人们通常考虑的“更纯的”servlet技术呢？如果确实应该扩展API，JSF应该包含进来吗？(如果JSF是“笨重”的，为什么不说JSP也是“笨重”的呢？因为二者都要编译才能运行嘛。)

    BTW：

以下是JavaEE6最热门的两种配置轮廓，我们简称为A,B。 最后一列是完整的JavaEE6平台

(A)

(B)

Full platform

Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250

Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250

Servlet 3.0
JSP 2.2
JSR-45
EL 1.2
JSTL 1.2
JSR-250

 

EJB 3.1 (Lite)
JTA 1.1
JPA 2.0
JSF 2.0 *
Web Beans 1.0 *

EJB 3.1
JTA 1.1
JPA 2.0
JSF 2.0
Web Beans 1.0

  

JAX-RS 1.0
Connectors 1.6
JAX-WS 2.2
JAXB 2.2
JSR-109 1.2
JSR-181 1.1
JMS 1.1
JAF 1.1
JavaMail 1.4
JSR-115
JSR-196
JSR-88 1.2
JSR-77 1.1
JAX-RPC1.1
JAXR 1.0

 
来自: theserverside
18
顶
0
踩
评论 共 12 条 请登录后发表评论
12 楼 lonvea 2009-12-25 09:57
javaEE6已经发布了,需要大家用崭新的目光去看待javaEE6中的一些新特性.
A还是B并不重要,关键是你在做或者计划做什么样的项目.

A完全就是web站点开发,谈不上企业级应用.如果用A开发企业级应用,至少还需要N中附属技术.

B是轻量级企业级架构的端倪.JSF2.0完全不像JSF1.x那样了,就像struts1和struts2一样.只是JSF本身的思想并没有改变..但是开发效率还是不错的.

webbeans,大家可能不够熟悉,那么你可以暂时认识一下seam..

EJB3.1中lite版本的思想值得推广,但是很遗憾我们不是JCP..
11 楼 Joo 2008-05-19 10:02
感觉lite的方向是对的阿 很多情况下remote interface都是鸡肋
10 楼 beyondsky 2008-03-06 09:41
我对上面的看法都有些偏见吧 可能不同的环境 需要不同的 组合吧 我对版本不兼容真的愁死了 上次能了个 hibernate2 升级成hibernate3 麻烦死了 本版的不兼容 但是最后还是解决了 嘻嘻 （有人帮忙）
9 楼 phoenixup 2008-03-03 12:23
引用
。 我也选A。Rod应该也在JavaEE6专家组里吧，早年他就说EJB是一个过时的技术。不仅落后，还臃肿。不相信的话，再看一看Full platform那一列吧。能真正用上的不并不多。 而A完全可以运行在轻量级的容器上，可以很方便的采用主流的开源框架。

早年的EJB我理解应该是2.0吧，现在的EJB和早年的EJB已经完全是两回事了，现在的EJB 3.0已经可以完全可以在项目中良好使用了，在使用过现在的EJB模型后，你会完全改观的，关于EJB落后臃肿等等论调，真的不应该再说了！

8 楼 打倒小日本 2008-02-27 19:43
我选(B)
JSF是一定需要的 相信2.0版会更加完善
7 楼 jsyx 2008-02-27 12:25
请注意，数据源不等于数据库
多数据源在所谓的企业级应用中并不是很罕见的情况
即使只有一个数据库，也会有希望把jms服务也放入事物的时候
6 楼 kyo100900 2008-02-27 12:09
jsyx 2008-02-27 10:17
选B
至少JTA还是需要的


如果只有一个数据源，本地的JDBC事务支持就足够了。没有必要绑定在JTA上吧。JTA是应该是可选的。
5 楼 qichunren 2008-02-27 11:11
我会选择A啊
4 楼 jsyx 2008-02-27 10:17
选B
至少JTA还是需要的
3 楼 kyo100900 2008-02-27 09:09
。 我也选A。Rod应该也在JavaEE6专家组里吧，早年他就说EJB是一个过时的技术。不仅落后，还臃肿。不相信的话，再看一看Full platform那一列吧。能真正用上的不并不多。 而A完全可以运行在轻量级的容器上，可以很方便的采用主流的开源框架。
2 楼 zhouzhao21 2008-02-27 09:00
A too ......
1 楼 saturn 2008-02-27 08:50
我选择A

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

Global site tag (gtag.js) - Google Analytics