z*******3
发帖数: 13709 | 1 抛砖引玉
吃饱了看文茜世界财经周报，看得昏昏的想睡，睡觉前赶紧写，写完睡觉去了
这样，先不从dto说起了，说tiers
一个j2ee经典的tiers最早提出来的时候，是三层，所谓的三层说的是sever side三层
不包括client side和database
三层里面分别有一层专门跟以上两个东西打交道
一个是presentation tier，这个跟client side打交道
一个是persistent tier，这个专门跟database打交道
中间还剩下一个叫做business tier，这么三层，这都很熟悉了
那么当初提出这个构想的时候
是基于以下一个方式
client side是applet＋browser
presentation tier是servlet+jsp，servlet是controller，jsp是viewer
model需要你自己去提取，去包装
business tier则是ejb，尤其是session bean，stateful和stateless
persistent tier也是ejb，是entity bean
database用jdbc连接
这五个层面都可以放在不同的物理机器上单独运行（至少理论上是这样滴）
不能不说这是一个非常成功的模式，这个模式构建出整个j2ee的基础
到今天所有用的jave ee都是这个模式演变而来的
这种模型的理论依据其实很简单，就是完全配合软件工程里面的各种理论
其中非常强调分工和协作，理论上
client side的applet，presentation tier的servlet, jsp, html, javascript
business tier的ejb，都是分开独立部署的实体，需要各自继承不同的接口
比如appletClass extends japplet
比如servletClass extends httpServlet
比如ejb implements ejbHome
applet的部署是jar，presentation tier的部署是war，然后ejb的部署也是jar
然后war和jar包合在一起可以单独打包成ear
这是理论，但是实际上，ejb往往直接打包成ear
然后再辅助以xml，交给专门的部署人员去部署
同时虚拟机由专门的人员调试，安装，同样的，ejb的调试和安装也应该由专门的人完成
这一批人加上各个tier的开发人员，再加上database的工作人员
理论上，记住了，一个j2ee小组里面，应该有至少 6 个不同职能的工作人员，甚至更多
但是实际上，狗屁～！！！！！！！！！！！！！
经常是一个人从头写到尾，搞不好连database都是这个人在维护
这是其中一个问题
另外一个理论上的致命缺陷是
tier与tier之间的接口，都暂时只能是primitive datatype的
也就是只定义了String, int之类的原始数据类型
那么这一套实际上是有足够的方式支持的
client side -> presentation tier，我们用http和html
presentation tier -> business tier，我们用ejb对rmi的封装，remote接口
business tier->integration tier，还是ejb，还是用remote接口
integration tier->database，用jdbc，jdbc有专门的api
但是实际上，java开发一般方法返回值，很少是这么简单的东东
至少都是一个包装好的java entity bean，也就是我们常见的那个
setter/getter+private variables的普通java bean，下文就统一叫做实体bean了
那么这个时候，每一层之间的通信，都是个问题，就是java的实体bean怎么传递到另外
一层去？
那么这个时候进化，spring跳了出来，说你们不要那么瞎搞了
把中间三层部署在不同的物理机器上是愚蠢的，你们没有必要这么干
因为大多数时候，这些东西都是在一个机器上运行的
所以你们不用去搞ejb那么麻烦的东西，听我的，按照我说的做
于是痛恨ejb＋学不会ejb的人们就赶紧转向spring了
同时在另外两个层面，也分别出现了其他的框架
这就是当时非常流行的struts和hibernate
struts是presentation tier的框架，这个框架的好处其实是帮你自动封装model到实体
beans中去
写过struts的人都记得那个private + setter/getter的年代
另外一个就是hibernate，实现了object-relational-mapping的同时
对不同数据库之间的差异实现了统一接口
这就是那个时候最流行的ssh框架，struts+spring+hibernate
到了这个时候，sever side的三个tiers分别对各自的tier实现了实体bean的封装
但是在不同层次的实体bean之间的转换还是一个大问题
继续进化，spring开始统一struts
因为在同一台虚拟机上，在不同层面搞出不同的实体bean有意义么？
聪明的人开始想到了，发明了一个dto设计模式，data transfer object
这个模式的特点就是在不同的tiers之间传递相同的dto
这个dto就是前面说的实体bean，只不过有一个约定俗成就是
无论struts还是spring还是hibernate，都用这个实体bean
然后struts封装好form扔过来的数据，塞给spring，spring再拿到hibernate的
sessionfactory
塞到database里面去，一捅到底，湿得一塌糊涂，然后查找的时候再从database里面拔
出来
然后修改完再查进去，再拔出来，再插进去……
后来spring觉得老搞这个太无聊了，于是开始搞spring mvc，大获成功
同时struts自宫了一把，升级到2.0版本之后居然跟1.0版本相去甚远，群众表示很难接
受新尺度
于是spring利用其在business tier的优势渗透到presentation tier，逐渐取代了
struts
并且积极配合hibernate的sessionfactory，封装出了spring的sessionfactory
就这么着，一统中间三层，成为最流行的框架
但是这么做湿有问题的，就是dto的存在，使得所有的框架，对dto都产生了依赖
那么这些dto就像一条又一条的锁链，把中间三层给捆了起来
使得中间三层的耦合度骤然增加，软件工程里面对于模块划分的建议是
耦合度越低越好，内聚性越高越好，你倒好，用一群dto，把所有的tiers全部捆了起来
这么做，在一台虚拟机上，不会有太大问题，但是如果是不同的机器呢？
你要保证不同的机器上都有相同的类，这个就很明显是一个严重的问题
那怎么办？
其实ejb做过尝试，就是提供entity bean的remote接口
就是不仅提供方法的接口，还提供实体bean的远程接口
但是群众完全不能接收，遂被迫deprecate ejb里面的entity bean
其实今天回过头去看，会发现ejb其实远走在时代的前面
只不过群众永远都是不能理解复杂的东西
后面说到的web service也差不多，当然这也跟定义的人不考虑群众感受有关
他们总是想把所有情况都考虑进去，但是当一种相对简单的情况就能解决大部分问题的
时候
群众会抛弃那种繁琐复杂的方式，而去选择那种相对简单的解决方案
但是时间一久，群众又会觉得相对简单的方式不够用，又会寻求额外的补充
那么这个时候原先复杂的定义就会跟这种相对简单的解决方案做一个妥协
折中出来一个理想状态，ejb3.0和rest就是这么一种妥协的产物
替代原先的ejb2.0和soap
回头，看看其他层是怎么做的再说，前面说了，从client side开始到database
其实除了中间三层，还有另外两层，一里一外，也就是浏览器和数据库是怎么跟java互
动的？
很简单，协议，浏览器通过http协议定义传输格式，同时默认html为返回text的语言
数据库则是通过sql来查询，同时返回一个resultset
那么不管是http,html还是sql，都是一种协议，约定，契约，所有人都遵守的契约
那既然在不同的软件之间可以有这种契约，为什么java自己内部不遵守契约呢？
这个时候搞出了一个东西叫做xml，xml是html的延伸，但是远比html要规范
同时要容易扩展，可以扩展成任何一种语言，并用这种语言定义数据格式
最常见的一个应用就是把xml扩展成为xhtml，尽量在语法上贴近html
但是它是xml，同时用xhtml来取代html，成为client side跟presentation tier的默认
交流语言
这是第一步，同时hibernate完成了对sql的封装也完成了对数据库的映射
因为做得是如此之好，所以被邀请去搞jpa规范，这是第二步
当这两步都实现了之后，其实服务器软件对于数据库和浏览器的整合已经接近完成
也就是第一层和最后一层跟中间层的通信都已经逐步稳定规范下来了
那么唯一要处理的就是，如何规范，presentation tier和business tier之间的通信？
这个时候诞生了一个东西叫做web service
web service本意是暴露web层服务的
所以一开始搞得尤其复杂，uddi, wsdl和soap，那么现在回头看
uddi已经基本上可以说是失败了，soap也快玩完了
因为soap要求发送request的时候也用xml封装，吃饱了撑着
有一个人借鉴了client side跟presentation tier的通信方式
发明了了一个叫做rest的东西，尽可能复用了http协议
用一个类似client side发送http request一样的东西，发送web service的request
同时像client side接收html一样接收xml文件
同时把这一套应用到presentation tier和business tier之间
你会陡然发现，我乐个去，这两层之间的通信原来跟前面那两层的通信是如此的相似
所以ejb2.1之后很快就把web service给加到ejb规范里面去了
同时通过web service，使得ejb暴露接口给php等其他web服务变得可行
又同时ejb因为遵循了jpa规范，使得hibernate一样的orm在所有的ejb容器提供商中
成为一个硬性要求，就是你必须提供这种东西，否则不发执照给你
所以ejb的位置越来越清晰，就是成为一个完全的中间件，回到它本来的位置
它本来就应该做的那个角色，同时打算用esb对这两层的通信做一个消息面的优化
类似跟数据库连接时候搞的connection pool一样的东西
不过实现起来这两个又有太大的区别，而且esb现在也只是一个概念
包括web service，ejb现在也只支持到wsdl1.0，wsdl2.0也还没有完全支持
但是这是一个远景，应该是可以预期的
这个问题一旦解决，所有层与层之间的通信将会被完全规范化
使得真正的层与层之间的低耦合，高内聚，不互相依赖的模型成为现实
不再像以前一样，被一堆dto捆住了所有tiers，使得真正的分工和协作成为可能
所以现在已经出现了front end和back end的招工广告，其实就在预示着这种走势
front end对应的就是presentation tier吧
back end对应的就是ejb对应的business tier和integration tier吧
不过新版本的ejb已经去掉integration tier的内容，完全仍给jpa了
但是不管是ejb还是jpa，这都是java ee5,6,以及以后版本的组成部分
只要是java ee容器，这几个都是必须实现的，标准要遵守
说了这么多，不知道理解没有，下面通过一个实例来具体说说spring和ejb的区别 |
z*******3
发帖数: 13709 | 2 spring的普通bean，尤其是无状态的bean
什么controller, service, repository, component啊
scope无非两种，singleton和prototype
ejb有三种，singleton, stateless, stateful
这里，singleton是spring和ejb都有
ptototype和stateful是差不多的
但是不是一个东西
spring的singleton和ejb的singleton都是无节制的访问方法
任何线程可以在任何时间访问这个类的方法
同时因为这个类只有一个在内存中，所以不允许其保存任何状态
所谓状态就是private variable
否则这个状态会引发并发的异常
同时spring的prototype和ejb的stateful
都确保在访问这些bean的时候，新生一个bean
所以每一个线程拿到的都是新的bean
所以保证了线程与线程之间的独立，所以可以寄存状态
比如在线商店的购物车
所不同的是，ejb的stateful还提供了一个ejbPassive和ejbActive方法
当这个购物车滞留时间太久的时候，这个ejb会先passive掉
然后在这个方法里面寄存当前状态
等到这个购物车又活了的时候，再取出寄存状态使用
这就很像web sever的那个session
最后要说的是stateless session bean
这个是ejb独有的，实际上，ejb一直建议使用stateless session bean
而不是singleton session bean
因为stateless session bean是线程安全的
也就是说，每一个线程拿到的bean，都是独占的，不允许同时访问，就是并发
但是一旦使用完了之后，就会把这个bean放回对象池
然后下一个线程可能还会拿到这个bean
所以寄存状态不是不可以，但是推荐你不要这么做
同时也不提供ejbPassive和ejbActive方法，所以不能像stateful那样真正寄存状态
同时由于不允许同时访问，所以可以通过控制stateless session bean的数量
来控制某一种访问暴涨的情况，这个在对付某种无节制访问的攻击时候显得尤为重要
考虑以下这种情况，我们都知道creational patterns有
simple factory, abstract factory, singleton, prototype, builder
这几种堆吧？
其实ejb实现了以上所有的模式，恩，或者prototype没有吧
single factory，ejb2.1的local接口
abstract factory，ejb2.1的entity bean和session bean接口
但是群众表示太复杂，拒绝接受
singleton用@singleton
prototype这个是spring的prototype更接近其理论，stateful session bean不太像
最后一个builder
builder模式，我要建一个房子，那么我先把房子拆成几个部分
单独建好之后，再组装起来
那么当我用一个stateless session bean建房子的时候
我需要把这几个部分单独建好，建好之后再组装起来
那么要怎么做呢？
很简单，用stateless session bean
然后用这一个同时调用其他n个stateless session bean的asynchronous方法
然后等待，其他方法执行完了之后，可能一时组装房子那个session bean还在等待
所以需要寄存状态，这个时候由于是线程安全的，所以寄存状态不会有其他线程访问
等到组装房子的session bean访问到的时候
再把这个状态交还，再完成线程，所以通过这种方式可以很好滴实现builder模式
ejb真是一个伟大的设计，简简单单的一个创建对象，就有n多讲究
几乎实现了所有的设计模式，所以ejb本身也有性能调优的角色
只不过，这个角色从来没有真正实现过而已
当然spring web还有scope，那是给spring mvc用的
ejb没有对应的东西，不说了
扩展
对于ejb来说，我把ejb单独暴露成为一个web service
给php调用也是一个不错的主意，因为php从web hosting的价格来说
那是要比jsp要便宜太多了，如果只是web的话
同样的，也可以把ejb暴露给.net等其他系统
从而通过这种方式，完成其真正中间件的使命，而不是介入web server的各种操作 |
B*****g
发帖数: 34098 | 3 顶，慢慢读。另外你又被封全站了？
完成
更多
【在 z*******3 的大作中提到】
: 抛砖引玉
: 吃饱了看文茜世界财经周报，看得昏昏的想睡，睡觉前赶紧写，写完睡觉去了
: 这样，先不从dto说起了，说tiers
: 一个j2ee经典的tiers最早提出来的时候，是三层，所谓的三层说的是sever side三层
: 不包括client side和database
: 三层里面分别有一层专门跟以上两个东西打交道
: 一个是presentation tier，这个跟client side打交道
: 一个是persistent tier，这个专门跟database打交道
: 中间还剩下一个叫做business tier，这么三层，这都很熟悉了
: 那么当初提出这个构想的时候
|
z*******3
发帖数: 13709 | 4 最后一个可能没说清楚
这么说
ejb三种session bean
singleton, stateless, stateful
singleton适用这种
public class Test{
public Object test(Object o){
Map m = new HashMap();
m.put(...);
...}
}
stateless适用这种
public class Test{
private Map m = new HashMap();
public Object test(Object o){
m.clear();
m.put(...);
...
}
}
stateful适用这种
public class Test{
private Map m = new HashMap();
public Object test(Object o){
//m.clear();
//不需要clear，因为每次都是新的对象，然后可以实现ejbPassive和ejbActive方法，
不展开了
m.put(...);
...
}
} |
z*******3
发帖数: 13709 | 5 没有，马甲太久没用，拿出来晒晒
【在 B*****g 的大作中提到】
: 顶，慢慢读。另外你又被封全站了？
:
: 完成
: 更多
|
J*******n
发帖数: 2901 | 6 哇，好多内容啊，Beijing要不要邀请zhaoce在CINAOUG给大家来一场java ee发展史、
现状和趋势的讲座啊
【在 B*****g 的大作中提到】
: 顶，慢慢读。另外你又被封全站了？
:
: 完成
: 更多
|
l*******G
发帖数: 1191 | 7 Ding! And support!
【在 J*******n 的大作中提到】
: 哇，好多内容啊，Beijing要不要邀请zhaoce在CINAOUG给大家来一场java ee发展史、
: 现状和趋势的讲座啊
|
B*****g
发帖数: 34098 | 8 ding
【在 J*******n 的大作中提到】
: 哇，好多内容啊，Beijing要不要邀请zhaoce在CINAOUG给大家来一场java ee发展史、
: 现状和趋势的讲座啊
|
|
e*****t
发帖数: 1005 | 9 这篇是好文，讲的历史沿革,还有层次都很清晰。
吹毛求疵一点点：
1. ejb刚出来的时候，persistence tier主流不是hibernate，应该是jdbc,至于ORM，
应该最热的是iBais。当然hibernate是在ejb2年代热起来的，所以ejb3搞jpa就直接弄
来Gavin King，照搬了hibernate
2. Spring当初是lightweight,现在整个spring一点也不light，应该是比javaEE整个标
准加起来都庞大，只不过大家平日只是用到其中一部分而已：Spring core, Spring
security, Spring MVC, and etc...
3. Entity bean还是JavaEE的概念，Spring那帮人就是不好那个，所以搞POJO.所以提
到data object时，对于spring,还是说pojo来的比较好。
4. Hibernate是red hat的,jboss也是red hat的。不过hibernate至少现在不是jboss的。
5. Spring最初也不过是从POJO, IoC，和transaction搞起来的，以此replace最常用到
的JavaEE功能，再此之上搭配Struts,往下搭配jdbc or ibatis. 现在的spring真是今
非昔比，所有你能想到的，不能想到的，spring几乎无所不包了。如果你所在的是个
spring shop,其实整体的集成也是非常之方便简单的。
6. 同意Struts 2.0是自废武功，从此一蹶不振，让Spring MVC捡了便宜
7. 不能说data object (pojo)就把Server side 的几层给tightly couple起来了。所
有的business logic最终都是服务于data manipulation的。所以提供相同的data
scheme是必须的。只不过区别是怎么来提供这个data scheme，可以是database scheme
, xml scheme, json, 等等。对于jvm，这个就可以直接由pojo来提供了。我不觉得让
不同的机器上都有相同的类对于jvm based的机器是个多严重的问题。但是对于非jvm平
台，这就的确是个问题，这也就是现在为什么喜欢用json和webservice来解决
communicate问题。
8. transaction和serialization都是很重要的东西。由于ejb开始时完全distributed
的设计思想，把serialization和transaction management也是搞得极其复杂。这也是
spring流行起来的一个重要原因。
9. ejb的设计的确是远远走在时代的前面，可这不是什么值得骄傲的事情。over-
design其实就是为了design而design，而不是为了requirement而design. 在大学、研
究院所里搞搞这些是必须的，但是作为一个大规模推广的工业标准，还是得立足于应用
。这是java当年流行起来的原因，也是sun最后作为一整个公司把自己搞垮的原因之一。
10. 个人觉得，REST的思想是伟大的，远远超出web service的范畴 http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf. web service只是这个思想的一个应用而已。而且in reality，很少有真正符合REST思想的web service，现在其实大都只是披着REST外衣的REST-ful或者-ish的http web service，使用xml或者json作为data scheme.
11. 如果structs, Spring MVC是presentation tier的话，这些是不会直接使用到web
service的。所以说webservice不能说是presentation tier和business tier之间的东
西。web service本身是business tier和client side （自己的直接client或者别的
servers)通讯的手段。
12. Spring的prototype和singleton仅仅控制bean的数量，并不限制bean的state。但
prototype既然每次给你不同的bean,不同的object的state就没有任何关系。但是
singleton bean可能就会keep一些state，使得不同的consumers来共享，这个和你说的
不同。至于到concurrency的问题，是另外的问题。
13. JavaEE spec是个非常好学习design pattern和software architecture的东东。建
议有志于此的都好好研读一下它的design和其后的philosophy.
Zhaoce是大牛，能花时间写这么长，赞！
【在 z*******3 的大作中提到】
: 抛砖引玉
: 吃饱了看文茜世界财经周报，看得昏昏的想睡，睡觉前赶紧写，写完睡觉去了
: 这样，先不从dto说起了，说tiers
: 一个j2ee经典的tiers最早提出来的时候，是三层，所谓的三层说的是sever side三层
: 不包括client side和database
: 三层里面分别有一层专门跟以上两个东西打交道
: 一个是presentation tier，这个跟client side打交道
: 一个是persistent tier，这个专门跟database打交道
: 中间还剩下一个叫做business tier，这么三层，这都很熟悉了
: 那么当初提出这个构想的时候
|
g*****g
发帖数: 34805 | 10 你俩都是大牛。JavaEE最令人遗憾的是在presentation tier框架太多，
易用性不够，标准的jsf又太垃圾。
从分层的角度讲，所谓的client也是presentation tier。跟web比无非是thick
client和thin client的区别。web service则通常视为business tier的子层。
ejb提供了ejb remoting, spring 支持RMI，spring http invoker，Hessian,
burlap。Web service是相当的一个remoting模式。
ajax web client 通过web service访问business tier也是常见的部署模式之一。
分层通常以部署来区分，web service通常跟service bean在一块，而大型的
项目web tier常常放在另外一个cluster上。
【在 e*****t 的大作中提到】
: 这篇是好文，讲的历史沿革,还有层次都很清晰。
: 吹毛求疵一点点：
: 1. ejb刚出来的时候，persistence tier主流不是hibernate，应该是jdbc,至于ORM，
: 应该最热的是iBais。当然hibernate是在ejb2年代热起来的，所以ejb3搞jpa就直接弄
: 来Gavin King，照搬了hibernate
: 2. Spring当初是lightweight,现在整个spring一点也不light，应该是比javaEE整个标
: 准加起来都庞大，只不过大家平日只是用到其中一部分而已：Spring core, Spring
: security, Spring MVC, and etc...
: 3. Entity bean还是JavaEE的概念，Spring那帮人就是不好那个，所以搞POJO.所以提
: 到data object时，对于spring,还是说pojo来的比较好。
|
|
|
p*a
发帖数: 592 | 11 有意思。.net的WCF也有类似的概念。
InstanceContextMode有PerSession, PerCall和Single.
【在 z*******3 的大作中提到】
: 最后一个可能没说清楚
: 这么说
: ejb三种session bean
: singleton, stateless, stateful
: singleton适用这种
: public class Test{
: public Object test(Object o){
: Map m = new HashMap();
: m.put(...);
: ...}
|
l*******G
发帖数: 1191 | 12 对于 stateful 的例子，总是不停的new Map m, 系统不是会崩溃？啥时候m 被destroy
? 如果是自动destroy的，那系统如何实现的？
【在 z*******3 的大作中提到】
: 最后一个可能没说清楚
: 这么说
: ejb三种session bean
: singleton, stateless, stateful
: singleton适用这种
: public class Test{
: public Object test(Object o){
: Map m = new HashMap();
: m.put(...);
: ...}
|
z*******3
发帖数: 13709 | 13 persession可不是stateful
persession是spring里面web的scope=session
percall是spring里面web的scope=request
singleton是常用模式，并不是只有business tier才有
我这里说的跟.net没有必然联系
今天稍微快速扫了一下.net
发现没有business tier这个概念
你还在尝试用web层的概念去理解business tier的东西
这会出问题的，而且business tier本身有很多讲究
等下我再展开，其实web service是web层也就是presentation的概念
以前ejb时代，presentation tier和business tier用的是iiop协议
至于rest的推广是我的个人的一个观点，并不代表一定可行
但是我认为将来这么做是有可能的
【在 p*a 的大作中提到】
: 有意思。.net的WCF也有类似的概念。
: InstanceContextMode有PerSession, PerCall和Single.
|
z*******3
发帖数: 13709 | 14 stateful在调用的thread结束之后，就可以被gc了
你说得没有错，无论是spring还是ejb
对于stateful和prototype都是不推荐使用的
在web层，也就是presentation层，推荐你使用HttpSession
google session tracking
然后在business层，无论是spring还是ejb
都推荐你使用无状态的singleton和stateless
当然stateless不是无状态，但是理论上最好不要加入如何状态的寄存
然后ejb推荐使用stateless，因为ejb认为singleton这种方式
是有一定风险的，尤其是当@Lock(write)的时候，会瞬间变为瓶颈
更有意思的是，这个@Lock(write)居然是缺省设置，所以当你使用singleton的时候
一定记住加上@Lock(read)，否则就是真的一个线程访问的单子
同时还有一种可能就是当这个bean坏掉了，怎么办？会同时导致其他线程受阻
所以一般来说，用ejb的人还是习惯使用stateless session bean
而ejb容器对于stateless session bean的支持也是最佳的
一般来说我的经验，5个stateless session bean可以对付100个人同时访问
当然不是在时间上绝对的同时，但是平均过去，一个时间点，只会有5个人在执行线程
而其他95个人在看，并不是处于连接状态
另外，web层的servlet本身就是一个stateless的bean，但是它不叫做session bean了
所以其实我们老早就在用这种东西了
destroy
【在 l*******G 的大作中提到】
: 对于 stateful 的例子，总是不停的new Map m, 系统不是会崩溃？啥时候m 被destroy
: ? 如果是自动destroy的，那系统如何实现的？
|
z*******3
发帖数: 13709 | 15 你们才是大牛，我是凑热闹的
我觉得thin client说的是html的那个browser
thick client是游戏客户端这种
当然ejb本身也可以作为ejb的client
这也不稀奇，只要对方有jvm，就可以被调用
rmi是底层的java实现，只要有java的地方，就可以实现rmi
但是rmi不好用，ejb的remote接口在rmi-iiop上实现了一层封装
好很多了
同时从另外一个角度说，web service虽然最早源起于web
但是应用在web server和app server的通信上也不是不可以
而且理论上效率不应该太差
因为rest是在tcp之上用http实现request,用xml封装response
而传统的rmi是在tcp之上用iiop实现request和response
再用serializable实现不同jvm上的类重现
唯一的区别就在于，rest需要用xml解码，把类里面的value给提取出来
其实这两个都是用tcp协议，实际传送的都是io stream
然后再从stream到具体的class，不应该有太大差距
所以只要这个网络条件相同，rmi，ejb的remote和web service的rest
应该是能够实现差不多效率的，可能会有细微差别，但是理论上不应该太大
【在 g*****g 的大作中提到】
: 你俩都是大牛。JavaEE最令人遗憾的是在presentation tier框架太多，
: 易用性不够，标准的jsf又太垃圾。
: 从分层的角度讲，所谓的client也是presentation tier。跟web比无非是thick
: client和thin client的区别。web service则通常视为business tier的子层。
: ejb提供了ejb remoting, spring 支持RMI，spring http invoker，Hessian,
: burlap。Web service是相当的一个remoting模式。
: ajax web client 通过web service访问business tier也是常见的部署模式之一。
: 分层通常以部署来区分，web service通常跟service bean在一块，而大型的
: 项目web tier常常放在另外一个cluster上。
|
z*******3
发帖数: 13709 | 16 其实一直以来，我觉得很多人，对于business tier这一层有很大误解
很多人至今还认为，这一层要么是presentation tier也就是web层的依附
要么是integration tier也就是跟db打交道那一层的依附
这是绝对错误的，从我学习j2ee的那一天起，我就坚持认为
business tier才是真正的核心，既不是web也不是db层的依附
所以每当看到别人说，ejb是web或者是db相关，我就觉得有点问题
因为web和db都有专门独立的tier与之配套并封装起来
而只有business tier这一层，无论是spring core也好，ejb的session bean也罢
都是不依附与其他外界的东西的存在，唯一需要的就是下面需要支撑的平台
也就是os和jvm，除此以外，他们是可以独立存在的核心
因为最早j2ee理论提出来的时候，就假设，现有的业务逻辑
是非常复杂的，也就是说定义了input/ouput之后
中间那一个，是假设是可以写很多很多的
所以以ejb为核心，定义其他的组件，所有组件以ejb为核心，围绕着ejb服务
而ejb本身可以打包成jar包，然后在不同的jvm上随意部署
当然ejb还需要额外的一个ejb容器，不象纯粹的jar，随便找个jvm就可以跑了
也就是说，j2ee的这个ejb的jar包的概念，就是最初java一次编译，到处运行的一个延伸
只不过它要求额外的容器配合，不仅仅是jar包
所以我始终坚持认为，business tier才是核心，而不是database和web
任何的业务逻辑，剥离依赖之后，要全部放到business tier中去
一方面利用容器管理这些乱七八糟的逻辑
同时也利用这种封装剥离业务逻辑之间的联系
因为要被容器所接纳，需要的就是decoupling的封装
而decoupling本身又对防止内存泄漏有明显帮助
当然不能绝对保证内存不泄漏，但是已经尽量了
你看上文说的stateful session bean，里面有一个map
我们知道，最简单的内存泄漏，就是map.put();无限循环下去
内存不爆掉才有鬼，但是如果你认真研究一下上面三种session bean
无论是singleton还是stateless还是stateful
都不存在有这种方式的内存泄漏
singleton不允许定义state，当然你非得写上一个state也行
但是这就变成core java的东西了，需要自己控制state
stateless虽然可以定义，但是推荐你不要这么做
你不按照规定做，那风险要自己控制，所以我加了一行m.clear();
stateful每一次调用都会new一个新对象
然后用过的就可以被gc掉，所以只要你按照标准做
各种风险可以被降到最低，但是你不按照标准做
那就不太好说了 |
z*******3
发帖数: 13709 | 17 拿破仑说过，不想当元帅的士兵不是好士兵
软件工程和cs最大的区别在于
cs更在乎数学逻辑上的对错
而软件工程则更在乎如何实现人与人之间的差异化合作
所以学习软件工程的时候，很多课程跟管理相关
而工作的时候，这一行需要一定的沟通能力
举个通俗点的例子
cs高手很有可能是一个黑客，而软件工程的大师，多半是架构师
从我学习java的那一天起，就被告知
你最先需要了解的，就是为什么要用这个工具，而不是你多会用这个工具
你需要了解各个工具之间的优缺点，而不是告诉别人，你这个工具用得有多好
固然用好工具很重要，但是你听说过狙击手和爆破专家出身的元帅么？
作为一个元帅，你需要了解的是你手下这批人的优点和缺点
而不是跟手下的狙击手比谁狙得更准
所以对于这一行而言，你需要了解的东西很多很多
不仅仅是java和framework还有各种相关的软件产品
比如browser，比如database，比如operating system
而这几个往往跟java没有直接的联系，甚至你不用java一样搞定他们
但是java是一个很好的glue，能够很好滴跟他们连接并驾驭他们
同时java世界内部，也有不同的派系，规范的和不规范的
自己的近卫队和雇佣军，等等
如果你要打仗，第一步肯定是选将，因为每个人的特征不一样
不同的将领在不同的战场上有不同的职能，如果把隆美尔派到大西洋上去
我看他也够呛，但是你把他放到沙漠，放到法国的土地上去，他就能一马平川
所以我们首先要选的是，统军大将
候选有spring core, jboss, websphere和weblogic
从战斗力上说
spring core擅长的是轻量级的战役，它本身虽然有一定的扩展性
但是这些扩展都依赖spring本身，而非标准化流程，所以太过于重量级的战役，建议你
换人
websphere擅长的是跟它同一系列的家臣（产品）的协作
比如它跟lotus，它跟rational，它跟aix的关系就很不错，可以额外优化
但是它跟非它家臣的产品，就不是那么关系铁了
为了防止websphere带领ibm家臣搞一个黄袍加身，我建议你最好慎用它
weblogic本身性能是这几个中最好的，但是它也有家臣，或者说它有些惧内
这个内就是oracle db，因为它结婚之后就入赘了，改姓oracle了
所以这种软骨头是否堪担重任很值得商榷，而且这个内可不是什么省油的灯
jboss是个不错的东西，但是它本身也是重量级的将领
在你派它出征的时候，先想想是否需要这么重量级的将领出马
然后是副官，历史上的好的副官都是后勤大师
我们的后勤就是database
database里面oracle是不错的人选，但是前面说了，这个女人不太好驾驭
动不动向你要粮要钱，这军饷一大半充到她的口袋里去了
男人有多好色，女人就有多爱财，所以要选她的话，先看看自己的粮草金钱是否充足
mysql一度是贤内助的不二人选，但是这个贤内助已经到oracle家当小妾去了
建议你也不要用
db2是ibm家的家臣，在没有其它ibm家臣在场的时候，化学反应十分有限
postgresql是一个有理想的进步女青年，满腔热血报国
但是她的这份热情是否有些过于理想了？
firebird则长得一幅小三样，动不动就跟你眉来眼去的倒贴，但是有道是好货不便宜
这么容易就送上门的，你是否放心？
近卫队，os
近卫队的作用总是被人忽视，多数时候在演义故事里起作用
就像斯巴达克斯小说里面斯巴达克斯的贴身骑兵卫队一样，对统帅总是绝对忠诚
赵云也总是在关键时刻救主，但是必要时候，这个亲卫队也随时可以砍了统帅
所以os虽然很重要，但是建议统帅还是跟他们保持距离
最好的方式就是不依赖近卫队的作用，而在大场面上灭掉对手
近卫队就让它们旅行最基本的保安职能就好了，真正战场上的冲杀，没他们什么事
正规军
ejb，servlet，jsp，jsf，jms……
这些部将的能力各有各的特色，不可或缺的组件，无论什么战场
你还都离不开他们，必要时候选择正确的将领攻城拔寨
民兵
各种开源的framework和产品
struts，hibernate, spring mvc etc.，tomcat……
民兵里面有的很强，就像华盛顿的大陆军一样，打跑了英国龙虾兵
加拿大的民兵还一把火烧了白宫，但是问题是
这些民兵质量参差不齐，有很强也有很烂的
没有验证过他们实力的时候，不要太过于相信他们
游击队，browsers
游击队游弋在敌军阵地后方
没有他们的配合，这边也很难打胜战
但是如何跟游击队通信，则需要一定的协议
.net
魏延一样的将领，脑后有反骨
总是盘算着砍了统帅的脑袋取而代之
可与之合作，但是无论如何提防着它
php
一个不错的友军，必要时候可与之合作竞争，实现双赢 |
z*******3
发帖数: 13709 | 18 spring当时提出来的pojo有很大的误导性
因为entity bean也是pojo，普通的stateless bean也是pojo
什么都是pojo，那到底说的pojo是哪一种呢？
一直到后来有了@Component等注释之后，这个才逐渐清晰起来
【在 e*****t 的大作中提到】
: 这篇是好文，讲的历史沿革,还有层次都很清晰。
: 吹毛求疵一点点：
: 1. ejb刚出来的时候，persistence tier主流不是hibernate，应该是jdbc,至于ORM，
: 应该最热的是iBais。当然hibernate是在ejb2年代热起来的，所以ejb3搞jpa就直接弄
: 来Gavin King，照搬了hibernate
: 2. Spring当初是lightweight,现在整个spring一点也不light，应该是比javaEE整个标
: 准加起来都庞大，只不过大家平日只是用到其中一部分而已：Spring core, Spring
: security, Spring MVC, and etc...
: 3. Entity bean还是JavaEE的概念，Spring那帮人就是不好那个，所以搞POJO.所以提
: 到data object时，对于spring,还是说pojo来的比较好。
|
z*******3
发帖数: 13709 | 19 java这一行牛人实在太多
随便说几个
jboss创始人marc fleury
本科和phd毕业于école Polytechnique，硕士在巴黎高师读的
专业是理论物理和数学，这两个学校在法国大学里面的档次
就相当于中国的清华北大，可能还要高一点
因为收的人数实在是很少，一共加起来在校生不过几百人
而且这两个学校在历史上都是培养出无数杰出数学家的学校
巴黎高师更是当今世界上数学第一大牛校
五分之一还多一点的菲尔兹奖获得者都毕业自这个学校
bea创始人是美籍华人庄司浩，他的学历并不突出
但是硕士毕业论文的引用率相当高，关于db的
red hat创始人是cmu的名人Marc Ewing
在cmu的时候，以戴着一个红帽子到处给人解答linux难题出名
一度在cmu里面有人遇到linux困难了
就说，去找那个戴着红帽子的人
spring的创始人是rod johnson，这家伙是澳大利亚人
悉尼大学cs本科，然后是music的phd……
sun是斯坦福大学网络的意思
而james gosling本身是加拿大人，o，canada
毕业于university of alberta和cmu
java本身是很伟大的东西，但是记住
真正在历史上留名的，都是理论提出者，而非实践者
james gosling是实践者，但是图灵奖发给了smalltalk的作者
因为smalltalk是第一个oo language，虽然java是最流行的oo language
但是理论不是james gosling提出的，他只是一个实践者
以上这些人和公司，大部分都是jcp也就是制定java相关规范的组织
的成员，包括spring的rod johnson，jcp里面赫然写着interface21
也就是后来springsource的前身的名字，包括jee6的specification
都是在interface21以及ibm, oracle, apache等投票下通过的
所以当你在考虑不遵循j2ee规范的时候
你也先想想，这么聪明的人在制定规则，就算你打算自己搞一套
你觉得你会比他们搞得更好么？或者说
去参与他们的讨论是一个更好的主意？
另外，上述的大部分创始人，在公司被收购之后，都离开了
比如james gosling离开了sun
rod johnson离开了spring
marc fleury离开了jboss
庄思浩也离开了bea
所以今天你看到的这些产品，已经多少不再是当初那些创始人创造的原型了
所以多数产品会逐渐趋同也是一个可以预见的趋势
因为普通人能给jboss打工也就可以给spring打工，木有区别的 |
w****u
发帖数: 3147 | |
|
|
w****u
发帖数: 3147 | 21 支持，来个讲座吧！
【在 J*******n 的大作中提到】
: 哇，好多内容啊，Beijing要不要邀请zhaoce在CINAOUG给大家来一场java ee发展史、
: 现状和趋势的讲座啊
|
A***g
发帖数: 1816 | |
e*****t
发帖数: 1005 | 23 多说一句，对于大规模部署的application(clustered).趋势是no http session or
minimal http session，这样使得application可以easily scale.
放到session里去是很简单，但一点一个session可以route到不同的node，就一大堆烦
心事了。
对于大一点的web application，concurency是一定要考虑的问题，performance很容易
被坏的design或者implementation影响。
【在 z*******3 的大作中提到】
: stateful在调用的thread结束之后，就可以被gc了
: 你说得没有错，无论是spring还是ejb
: 对于stateful和prototype都是不推荐使用的
: 在web层，也就是presentation层，推荐你使用HttpSession
: google session tracking
: 然后在business层，无论是spring还是ejb
: 都推荐你使用无状态的singleton和stateless
: 当然stateless不是无状态，但是理论上最好不要加入如何状态的寄存
: 然后ejb推荐使用stateless，因为ejb认为singleton这种方式
: 是有一定风险的，尤其是当@Lock(write)的时候，会瞬间变为瓶颈
|
e*****t
发帖数: 1005 | 24 虽然remote method invocation和web service有其相似之处:都利用network,都run在
TCP之上，并且可以实现类似的功能，但我觉得还是把他们分开来提比较好。
remote method invocation (remoting)是tightly coupled，一般限于java or jvm 平
台，通讯上双方一般不使用plain text，而是传送的binary. 平台提供正常以及异常(
exception)处理，乃至transaction处理。
web service是loosely coupled, 可以用于任何平台之间，通讯上一般使用plain text
(xml or json),没有直接的异常处理机制。
performance wise, remoting肯定会更好无疑，但是正如你所说，web service用在web
server和app server之间不是不可以，不过我想应该不会很普遍。为什么？因为没有
必要。没人直接搞rmi，肯定也是建立在某些framework之上的，如果framework给我非
常简单的异常处理，支持transaction，我为什么要去舍近求远的搞web service? 开发
效率上会强不少。
但是webservice 就非常之flexible了，你可以和任何client （as long as they
support http)通信。
【在 z*******3 的大作中提到】
: 你们才是大牛，我是凑热闹的
: 我觉得thin client说的是html的那个browser
: thick client是游戏客户端这种
: 当然ejb本身也可以作为ejb的client
: 这也不稀奇，只要对方有jvm，就可以被调用
: rmi是底层的java实现，只要有java的地方，就可以实现rmi
: 但是rmi不好用，ejb的remote接口在rmi-iiop上实现了一层封装
: 好很多了
: 同时从另外一个角度说，web service虽然最早源起于web
: 但是应用在web server和app server的通信上也不是不可以
|
e*****t
发帖数: 1005 | 25 同意business tier是一个application最终最重要的部分。
之所以说最终，是因为能不能卖出去，还是靠的是user experience (UI).卖不出去，
一切都是白搭。
不过business tier也不是什么都要大包大揽。presentation tier是变化非常快的，所
以如果不是真的跟business logic有关，最好还是别放到business tier来。不过
persistence tier变化就小多了，而且很难说变DAO不影响businese tier，所以常见这
些就放到一起了。
【在 z*******3 的大作中提到】
: 其实一直以来，我觉得很多人，对于business tier这一层有很大误解
: 很多人至今还认为，这一层要么是presentation tier也就是web层的依附
: 要么是integration tier也就是跟db打交道那一层的依附
: 这是绝对错误的，从我学习j2ee的那一天起，我就坚持认为
: business tier才是真正的核心，既不是web也不是db层的依附
: 所以每当看到别人说，ejb是web或者是db相关，我就觉得有点问题
: 因为web和db都有专门独立的tier与之配套并封装起来
: 而只有business tier这一层，无论是spring core也好，ejb的session bean也罢
: 都是不依附与其他外界的东西的存在，唯一需要的就是下面需要支撑的平台
: 也就是os和jvm，除此以外，他们是可以独立存在的核心
|
e*****t
发帖数: 1005 | 26 喜欢这篇的风格。
加一句，也是当年的一个面试题。选择technology的时候，还要考虑整个team的skill
set.
如果大家都是搞spring那一套的，就算ejb更合适，也还是接着搞spring吧。呵呵。
另一方面就是business requirements和budget，对于startup来说，很少会一来就上
jboss,weblogic，websphere.tomcat可以解决的问题就不用上ejb了，反正也不会真把
application跑在不同的node上。
我个人偏好是spring + tomcat，不过ejb3也进化的不错了。
db oracle肯定是enterprise级RDBMS的首选。当然大多数startup是会选mysql的。
ORM不用说，肯定是hibernate了，但也不是所有的application都适合。
NoSQL选择就更多了，具体选择要看requirments。
至于正规军和民兵的analogy，我不太同意。其实都是正规军，哪一个popular open
source framework/tools后面不站着个big name (including Apache Foundation)?
【在 z*******3 的大作中提到】
: 拿破仑说过，不想当元帅的士兵不是好士兵
: 软件工程和cs最大的区别在于
: cs更在乎数学逻辑上的对错
: 而软件工程则更在乎如何实现人与人之间的差异化合作
: 所以学习软件工程的时候，很多课程跟管理相关
: 而工作的时候，这一行需要一定的沟通能力
: 举个通俗点的例子
: cs高手很有可能是一个黑客，而软件工程的大师，多半是架构师
: 从我学习java的那一天起，就被告知
: 你最先需要了解的，就是为什么要用这个工具，而不是你多会用这个工具
|
e*****t
发帖数: 1005 | 27 Pojo就是个提法\concept，不能literally的理解。
【在 z*******3 的大作中提到】
: spring当时提出来的pojo有很大的误导性
: 因为entity bean也是pojo，普通的stateless bean也是pojo
: 什么都是pojo，那到底说的pojo是哪一种呢？
: 一直到后来有了@Component等注释之后，这个才逐渐清晰起来
|
e*****t
发帖数: 1005 | 28 高人是不用googl就能写下这些的。
errata: James Gosling毕业于University of Calgary,不是alberta
惭愧，刚刚wiki了他。
【在 z*******3 的大作中提到】
: java这一行牛人实在太多
: 随便说几个
: jboss创始人marc fleury
: 本科和phd毕业于école Polytechnique，硕士在巴黎高师读的
: 专业是理论物理和数学，这两个学校在法国大学里面的档次
: 就相当于中国的清华北大，可能还要高一点
: 因为收的人数实在是很少，一共加起来在校生不过几百人
: 而且这两个学校在历史上都是培养出无数杰出数学家的学校
: 巴黎高师更是当今世界上数学第一大牛校
: 五分之一还多一点的菲尔兹奖获得者都毕业自这个学校
|
t******h
发帖数: 120 | |
c*********w
发帖数: 65 | |
|
|
S****h
发帖数: 558 | 31 For legacy DBs with existing schema, which is almost always the case for our
firm, hibernate is not necessarily the easiest thing to deal with. One
group uses iBates which is simpler, even spring's jdbctemplate is not bad.
skill
【在 e*****t 的大作中提到】
: 喜欢这篇的风格。
: 加一句，也是当年的一个面试题。选择technology的时候，还要考虑整个team的skill
: set.
: 如果大家都是搞spring那一套的，就算ejb更合适，也还是接着搞spring吧。呵呵。
: 另一方面就是business requirements和budget，对于startup来说，很少会一来就上
: jboss,weblogic，websphere.tomcat可以解决的问题就不用上ejb了，反正也不会真把
: application跑在不同的node上。
: 我个人偏好是spring + tomcat，不过ejb3也进化的不错了。
: db oracle肯定是enterprise级RDBMS的首选。当然大多数startup是会选mysql的。
: ORM不用说，肯定是hibernate了，但也不是所有的application都适合。
|
t*******e
发帖数: 684 | 32 bean的lifecycle是由caller决定的。只要reference还存在就不会被gc。
【在 z*******3 的大作中提到】
: stateful在调用的thread结束之后，就可以被gc了
: 你说得没有错，无论是spring还是ejb
: 对于stateful和prototype都是不推荐使用的
: 在web层，也就是presentation层，推荐你使用HttpSession
: google session tracking
: 然后在business层，无论是spring还是ejb
: 都推荐你使用无状态的singleton和stateless
: 当然stateless不是无状态，但是理论上最好不要加入如何状态的寄存
: 然后ejb推荐使用stateless，因为ejb认为singleton这种方式
: 是有一定风险的，尤其是当@Lock(write)的时候，会瞬间变为瓶颈
|
l*******G
发帖数: 1191 | 33 同意这个观点。presentation/web tier 是在客户端， integration tier是和DB打
交道的。 这两层对于不同的行业来说有很大共性。而business logic 对不同行业来
说会差别很大，比如银行的business logic，和学校的business logic 和医院的
business logic差别是很大的，工厂就更加跟行业有关。不过许多J2EE教材都把着重点
放在presentation tier 和integration tier，因为那些教材的材料容易得到又比较统
一和类似。要着重business tier就难多了因为你可能只熟悉一个行业，如果你只讲银
行，那面向其他行业的读者就不爽了甚至会跳过。
【在 z*******3 的大作中提到】
: 其实一直以来，我觉得很多人，对于business tier这一层有很大误解
: 很多人至今还认为，这一层要么是presentation tier也就是web层的依附
: 要么是integration tier也就是跟db打交道那一层的依附
: 这是绝对错误的，从我学习j2ee的那一天起，我就坚持认为
: business tier才是真正的核心，既不是web也不是db层的依附
: 所以每当看到别人说，ejb是web或者是db相关，我就觉得有点问题
: 因为web和db都有专门独立的tier与之配套并封装起来
: 而只有business tier这一层，无论是spring core也好，ejb的session bean也罢
: 都是不依附与其他外界的东西的存在，唯一需要的就是下面需要支撑的平台
: 也就是os和jvm，除此以外，他们是可以独立存在的核心
|
l*******G
发帖数: 1191 | 34 如果是distributed system,caller 和bean不在一台机器上或者中间隔着好几个caller
，那这个gc 就非常危险了。
【在 t*******e 的大作中提到】
: bean的lifecycle是由caller决定的。只要reference还存在就不会被gc。
|
H*******d
发帖数: 2394 | |
z****e
发帖数: 54598 | 36 stateful可以passive，而一旦call的客户端不是原来那个，就一定是new
passive之后，内存中的bean就消失了，如果active被revoke的话
理论上是新的一个bean，但是这个bean会自动读取passive方法中寄存的状态
所以理论上用户可以自己override ejbpassive和ejbactive方法
对于stateless的session bean来说，每一个线程对于这个bean的lifetime
只存在于调用的这个方法，方法完成之后，再发请求
得到的可能是完全不同的stateless session bean
另外sessionbean是有时效的
一旦过时，就跟session一样，会失效
跟web.xml一样，ejb可以在ejb-jar.xml里面定义idle-timeout-seconds
在每一个bean可以添加annotation
不过这个一般是给stateful用的，默认是600秒
这也是一个很好的理由为什么要搞web service
因为web service理论上不应该存在有stateful的连接
因为soap和http本身没有状态要求的定义
所以所有的连接理论上都是无状态的
也就是说客户端的lifetime都仅仅存在于一个方法执行期间
方法执行完成，这个lifetime就结束了，session bean放回pool
同时对于大型项目而言，tier和tier之间的连接次数要尽量减少
这是系统优化的一个主要途径
【在 t*******e 的大作中提到】
: bean的lifecycle是由caller决定的。只要reference还存在就不会被gc。
|
z****e
发帖数: 54598 | 37 me对alberta不太熟
这两个名词加上edmonton在我眼里没有太大区别
找时间去一下banff估计会好很多
【在 e*****t 的大作中提到】
: 高人是不用googl就能写下这些的。
: errata: James Gosling毕业于University of Calgary,不是alberta
: 惭愧，刚刚wiki了他。
|
z****e
发帖数: 54598 | 38 难道你没发现，spring如果不搞web service的话
又不用ejb的接口的话，就只能自己实现rmi么？
text
web
【在 e*****t 的大作中提到】
: 虽然remote method invocation和web service有其相似之处:都利用network,都run在
: TCP之上，并且可以实现类似的功能，但我觉得还是把他们分开来提比较好。
: remote method invocation (remoting)是tightly coupled，一般限于java or jvm 平
: 台，通讯上双方一般不使用plain text，而是传送的binary. 平台提供正常以及异常(
: exception)处理，乃至transaction处理。
: web service是loosely coupled, 可以用于任何平台之间，通讯上一般使用plain text
: (xml or json),没有直接的异常处理机制。
: performance wise, remoting肯定会更好无疑，但是正如你所说，web service用在web
: server和app server之间不是不可以，不过我想应该不会很普遍。为什么？因为没有
: 必要。没人直接搞rmi，肯定也是建立在某些framework之上的，如果framework给我非
|
z****e
发帖数: 54598 | 39 我个人觉得
tier划分清晰
对于整个系统的扩展以及将来跟其它系统做集成
有很重要的关系
所以强调web service
因为基于web service
发展出了很多理论，或者说构架
比如esb，比如bpel
这都是基于web service的实现
当然也支持有其它技术，但是相对少
所以层次之间的通信协议，是一个大topic
不同层次，用什么通信都有可能，但是趋势是xml的大统一
也就是将来不管跟什么系统搞，对方极有可能要求你发xml
同时会给你发一个xml文档
xml之后发明的绝大部分协议，都是xml的扩展
所以应该主动拥抱xml，拥抱web service
的确，这种tier通过这种方式连接，是一种比较松散的连接
但是松散的连接正是我所期望的，我认为一个好的分布式操作系统
就应该实现这种像组件一样，少了谁，系统一样转
同时来者不拒，只要愿意加入，系统就能接纳
这样才是一个健康或者说健壮的系统
比如说，我要设计一个系统
我还是首选用ejb做核心，提供主要的web service
剥离database上所有的业务逻辑要求，因为db本身负担已经很重了
随着系统规模的增加，db里面数据量一大，没有index的查询几乎是无法使用
所以留出足够的内存之类的给index，把所有业务逻辑塞给ejb
包装ejb之后，用内网跟其它外层 server对联
所谓内网就是内部网络，对于这种连接，因为是内网
不暴露给外网访问，所以假设所有来自外层server的访问都是安全的
所谓外层的server，就是需要跟internet上客户端做交流的server
比如常见的web server，对于这种server上的服务
如果只是单机的，用http session，但是如果是跨几台机器的
用ejb来管理，这个时候可以考虑用前面说的singleton
其它人也说了，这个singleton可以共享数据，所以用上singleton的属性
也就是状态，也就是private变量，同时用上java.util.concurency包里面的那些类
来管理这些session，这样外层的server就可以通过跟ejb通信来获取这些session的信息
同时客户端寄存sessionid，也就是说，这个session寄存在哪里
对于客户来说是透明的，其实到了ejb这层，多少还是要了解一下线程
最后说一下spring，其实我个人觉得，spring core这个东西
对于core java那批人，其实用处更大
比如什么网游服务器的，这种，用spring core其实更好用
而不是j2ee这票人，因为j2ee有的是工具，而core java的工具并不是那么多
而spring是少数的最流行的东西里面，又不完全依赖其它东西的一个框架
如果你有心的话，自己写一个main都可以轻松跑起来spring core
只要依赖的那些spring jar和配置xml能找得到就行
spring以前版本做这些，那是实在是非常轻松啊
因为一，它把所有依赖的class都统一到一个jar里去
相比之下，hibernate是典型的到处乱放
二，它的xml配置文件默认在classpath下
只要把配置的xml跟class放在一起就行
现在稍微有些复杂，系统一做大，这种易用性就容易降低 |
z****e
发帖数: 54598 | 40 其实我觉得web service之上的建筑已经很健壮了
不知道你听说过esb和bpel没有
这个我最近感觉越来越多的公司在用这些东西
这两个大规模系统集成层面的pattern都是基于web service
当然esb也兼容一些jni之类的，但是主要还是web service的soap和rest啊
所以其实我觉得这个对于系统集成来说，不应该是很少使用的
至少在我这个地理位置来看，有愈烧愈旺的趋势
然后对于系统的集成，我个人还是比较传统的
认为一个良好设计过的大型系统，应该是一个同心圆，或者说是一个伞形
最里面是我们的db，次外层是中间件，再外层是对外暴露的server，最外层是客户机
然后安全级别逐层降低，最里面的db安全级别最高，最外层的客户机，安全级别最低
机器数量逐层增加，单个机器性能，逐层降低
这样一个结构，但是如果做不到，变形成为esb那种多对多的对接也是很有可能的
但是我认为，同心圆这种设计适用于某一个单一领域的大型系统
而如果把这些系统看成一个个原子，那么要处理好这些原子之间的关系
esb等上吧，我感觉现在senior一点的职位，web service是必需的
然后esb之类的，那个是highly desirable
贴个广告样本，参考，懒人直接跳过前面看desirable的部分
Java/J2EE Developer
……
Requirements
Minimum 2-5 years commercial experience in Java/J2EE and related
technologies (ESB, RMI, SOAP, XML, XSL, JMS, Spring, Hibernate, Junit,
Eclipse)
Good understanding of Web service and distributed architecture
Experience with integrating different technologies with J2EE and ESB
Good knowledge of J2EE design patterns, SOA, Enterprise Integration patterns
(EIP) and their applications
Relational database experience
Experience with Software Development Processes (e.g. RUP or FDD)
Experienced in UML design and associated tools
Experience in all aspects of the full Software Development Lifecycle
Experience with UNIX/Linux based development environments.
Desirable:
Experience in jBPM (JBoss), and Drools Flow is highly desirable.
Experience in Fuse ESB, Oracle, Eclipse, Unix, Maven, OSGi
Commercial experience in distributed, high availability architecture
Experience in dealing with existing and extensive code bases that have been
de
text
web
【在 e*****t 的大作中提到】
: 虽然remote method invocation和web service有其相似之处:都利用network,都run在
: TCP之上，并且可以实现类似的功能，但我觉得还是把他们分开来提比较好。
: remote method invocation (remoting)是tightly coupled，一般限于java or jvm 平
: 台，通讯上双方一般不使用plain text，而是传送的binary. 平台提供正常以及异常(
: exception)处理，乃至transaction处理。
: web service是loosely coupled, 可以用于任何平台之间，通讯上一般使用plain text
: (xml or json),没有直接的异常处理机制。
: performance wise, remoting肯定会更好无疑，但是正如你所说，web service用在web
: server和app server之间不是不可以，不过我想应该不会很普遍。为什么？因为没有
: 必要。没人直接搞rmi，肯定也是建立在某些framework之上的，如果framework给我非
|
|
|
t*******e
发帖数: 684 | 41 XML主要还是用在integration。web front end偶尔消费一下xml可以，如果加个remote
layer with XML-to-entity data binding，就很难实现on-demand Hibernate lazy
loading。后果就是处理数据低效。bpel也有明显局限，逐渐被BPMN2.0取代。任何技术
都有个适应范围，高手就是要找到最cost-effective的solutions.
【在 z****e 的大作中提到】
: 我个人觉得
: tier划分清晰
: 对于整个系统的扩展以及将来跟其它系统做集成
: 有很重要的关系
: 所以强调web service
: 因为基于web service
: 发展出了很多理论，或者说构架
: 比如esb，比如bpel
: 这都是基于web service的实现
: 当然也支持有其它技术，但是相对少
|
e*****t
发帖数: 1005 | 42 spring有个简单的spring remoting,hehe...
【在 z****e 的大作中提到】
: 难道你没发现，spring如果不搞web service的话
: 又不用ejb的接口的话，就只能自己实现rmi么？
:
: text
: web
|
t*******e
发帖数: 684 | 43 印象中要call ejb.remove()来结束一个ejb instance.
【在 z****e 的大作中提到】
: stateful可以passive，而一旦call的客户端不是原来那个，就一定是new
: passive之后，内存中的bean就消失了，如果active被revoke的话
: 理论上是新的一个bean，但是这个bean会自动读取passive方法中寄存的状态
: 所以理论上用户可以自己override ejbpassive和ejbactive方法
: 对于stateless的session bean来说，每一个线程对于这个bean的lifetime
: 只存在于调用的这个方法，方法完成之后，再发请求
: 得到的可能是完全不同的stateless session bean
: 另外sessionbean是有时效的
: 一旦过时，就跟session一样，会失效
: 跟web.xml一样，ejb可以在ejb-jar.xml里面定义idle-timeout-seconds
|
e*****t
发帖数: 1005 | 44 您老考虑问题还是站的高，实在enterprise architect这个级别的。而且一看就是sun
教育出来的那种。
【在 z****e 的大作中提到】
: 其实我觉得web service之上的建筑已经很健壮了
: 不知道你听说过esb和bpel没有
: 这个我最近感觉越来越多的公司在用这些东西
: 这两个大规模系统集成层面的pattern都是基于web service
: 当然esb也兼容一些jni之类的，但是主要还是web service的soap和rest啊
: 所以其实我觉得这个对于系统集成来说，不应该是很少使用的
: 至少在我这个地理位置来看，有愈烧愈旺的趋势
: 然后对于系统的集成，我个人还是比较传统的
: 认为一个良好设计过的大型系统，应该是一个同心圆，或者说是一个伞形
: 最里面是我们的db，次外层是中间件，再外层是对外暴露的server，最外层是客户机
|
t*******e
发帖数: 684 | 45 只要是stateless的beans，而且没有引用任何web API的都可以搞到business tier去。
【在 e*****t 的大作中提到】
: 同意business tier是一个application最终最重要的部分。
: 之所以说最终，是因为能不能卖出去，还是靠的是user experience (UI).卖不出去，
: 一切都是白搭。
: 不过business tier也不是什么都要大包大揽。presentation tier是变化非常快的，所
: 以如果不是真的跟business logic有关，最好还是别放到business tier来。不过
: persistence tier变化就小多了，而且很难说变DAO不影响businese tier，所以常见这
: 些就放到一起了。
|
t*******e
发帖数: 684 | 46 JSF2.0还是很不错的。本身html编程和RIA都要兼顾就不容易了。
【在 g*****g 的大作中提到】
: 你俩都是大牛。JavaEE最令人遗憾的是在presentation tier框架太多，
: 易用性不够，标准的jsf又太垃圾。
: 从分层的角度讲，所谓的client也是presentation tier。跟web比无非是thick
: client和thin client的区别。web service则通常视为business tier的子层。
: ejb提供了ejb remoting, spring 支持RMI，spring http invoker，Hessian,
: burlap。Web service是相当的一个remoting模式。
: ajax web client 通过web service访问business tier也是常见的部署模式之一。
: 分层通常以部署来区分，web service通常跟service bean在一块，而大型的
: 项目web tier常常放在另外一个cluster上。
|
s******e
发帖数: 493 | 47 I do not think that you want to compare spring to ejb, they are different
animals. |
z****e
发帖数: 54598 | 48 那是容器用的方法
一般不需要override
就是ejbpassive和ejbactive，都可以不要override
提供给你，唯一的目的就是问问用户
你有没有额外需要寄存或者销毁的东西，比如在构造器里面打开一个jdbc连接并寄存为
状态
在remove的时候，最好关闭连接，因为有些时候
用户会主动申请关闭不了的资源，尤其是涉及到io的时候
但是这个都是不提倡的，一般没人这么用，这种容器用的方法，大多数时候不推荐
override
如果是以前版本，就是有home接口的话，override后方法体留空就可以了
如果没有什么需要关闭的话
用ejb最好的地方就是容器托管，如果连销毁ejb都要自己手动编码
那不成写core java了
随手google的，参考
Re: Should i call EJB′s remove?[ GO TO TOP ]
POSTED BY: Jeryl Cook POSTED ON: June 22 2007 10:56 EDT in response to sawan
parihar
Never used it..in most cases u don't need to.
http://www.theserverside.com/discussions/thread.tss?thread_id=4
【在 t*******e 的大作中提到】
: 印象中要call ejb.remove()来结束一个ejb instance.
|
z****e
发帖数: 54598 | 49 这两对比n年了都
spring的作者rod johnson还特意写过一本书叫做j2ee without ejb
【在 s******e 的大作中提到】
: I do not think that you want to compare spring to ejb, they are different
: animals.
|
z****e
发帖数: 54598 | 50 你这个integration是db那一层还是系统集成？
front end跟client的打交道就是xhtml啊
然后hibernate跟db的处理，可以通过建立连接池来优化
而且db跟java的衔接在tcp协议上已经比较成熟了
所以这一层反而可以不要xml
现在唯一的问题就是ejb这一层跟web server之间的通信
只要效率接近，没有理由不上xml
而iiop跟http本身都是建立在tcp上的连接
无非就是虚拟机转换xml这种东西效率的问题
我个人感觉，这种差距不应该太大，而效率上如果差距被缩小
那么xml显然是一个更好的解决方案，而非rmi
实际上这么多年，rmi并不是很成功，倒是xml有愈烧愈旺之势
bpel是有局限，本身是工作流的升级，所以有
bpel vs esb一说，看情况决定整体结构
remote
【在 t*******e 的大作中提到】
: XML主要还是用在integration。web front end偶尔消费一下xml可以，如果加个remote
: layer with XML-to-entity data binding，就很难实现on-demand Hibernate lazy
: loading。后果就是处理数据低效。bpel也有明显局限，逐渐被BPMN2.0取代。任何技术
: 都有个适应范围，高手就是要找到最cost-effective的solutions.
|
|
|
z****e
发帖数: 54598 | 51 因为我从来就没有那种从无到有造轮子的机会
每次不管国内国外，都是直接拿过别人的系统就开始用
所以一次又一次被垃圾代码折磨过之后，看问题就不能不稍微高一点
一个系统代码好坏，到后期，尤其是让我这样的人开始处理的时候
都能明显感觉出来，代码本身质量倒是小问题了，结构一旦错
写起来那个叫一个痛苦
sun
【在 e*****t 的大作中提到】
: 您老考虑问题还是站的高，实在enterprise architect这个级别的。而且一看就是sun
: 教育出来的那种。
|
z****e
发帖数: 54598 | 52 老中有时候对于一些依赖啊之类的不敏感
其实我也是在stackoverflow和theserverside上看鬼子的回答
逐渐培养起这种意识的，经常就是老外评价一个代码的好坏
下面最常见的一个回答就是根据依赖程度来判断好坏
依赖越少越好 |
t*******e
发帖数: 684 | 53 我是指EAI。EAI和web application的处理还是相当不同的。一个针对的是B2B，一个是
B2C。 XML和其他EDI规范一样，很适用于batch data processing。但是EAI处理数据的
灵活性不如web applications. 同样的数据在不同页面上处理不同，validation rules
也会不同， object graph的fetch深度也不一样。当使用hibernate lazy loading和
JSR-303 bean validator时候，实现起来效率很高。用xml或EJB remoting就导致lazy
loading很难实现，（有个家伙搞了个remote lazy loading，但IO的cost很惊人)。后
果就是，要么针对不同web screen写不同的sql，或者就是一律返回整个object graph
，不管有的数据是否用的上。 而且hibernate auto dirty check也用不上，由brower
返回后，不知道那个entity被改动了。
其实返回整个object graph对EAI倒是很合适。After all, ESB也就是EAI的一个
solution。我很反对为用esb而esb，有时更本没有integration requirement。EAI
products从commerical到现在opensource，有越来越多的Java programmers变成了EAI
developers, integration architects。
【在 z****e 的大作中提到】
: 你这个integration是db那一层还是系统集成？
: front end跟client的打交道就是xhtml啊
: 然后hibernate跟db的处理，可以通过建立连接池来优化
: 而且db跟java的衔接在tcp协议上已经比较成熟了
: 所以这一层反而可以不要xml
: 现在唯一的问题就是ejb这一层跟web server之间的通信
: 只要效率接近，没有理由不上xml
: 而iiop跟http本身都是建立在tcp上的连接
: 无非就是虚拟机转换xml这种东西效率的问题
: 我个人感觉，这种差距不应该太大，而效率上如果差距被缩小
|
t*******e
发帖数: 684 | 54 多谢指正，ejb很多年不用了。看了你的帖子想到当年ejb考证的经历了。
【在 z****e 的大作中提到】
: 那是容器用的方法
: 一般不需要override
: 就是ejbpassive和ejbactive，都可以不要override
: 提供给你，唯一的目的就是问问用户
: 你有没有额外需要寄存或者销毁的东西，比如在构造器里面打开一个jdbc连接并寄存为
: 状态
: 在remove的时候，最好关闭连接，因为有些时候
: 用户会主动申请关闭不了的资源，尤其是涉及到io的时候
: 但是这个都是不提倡的，一般没人这么用，这种容器用的方法，大多数时候不推荐
: override
|
w*******s
发帖数: 940 | 55 我就是特别不理解为什么spring就有depend，而EJB就没有？
如果你不打算自己实现一个server，一样会依赖于jboss, websphere, weblogic
甚至于，标准不兼容怎么办？算不算依赖？
我是认为只要开源，就没有那么可怕，最起码，你可以自己改
【在 z****e 的大作中提到】
: 老中有时候对于一些依赖啊之类的不敏感
: 其实我也是在stackoverflow和theserverside上看鬼子的回答
: 逐渐培养起这种意识的，经常就是老外评价一个代码的好坏
: 下面最常见的一个回答就是根据依赖程度来判断好坏
: 依赖越少越好
|
s******e
发帖数: 493 | 56 as said before, spring started eying ejb, but later it evolves to an
application framework. Comparing ejb to spring is just like comparing ejb
container to application server, for example, comparing tomcat to full scale
application servers such as glassfish, weblogic, websphere, or even jboss.
【在 z****e 的大作中提到】
: 这两对比n年了都
: spring的作者rod johnson还特意写过一本书叫做j2ee without ejb
|
z****e
发帖数: 54598 | 57 这个很难理解吗？
因为ejb是标准化的组件，从诞生的那一天起，所有的规范都需要讨论后投票表决
而spring是私人的产品，现在是一家公司的产品，只要是公司的产品
说变就变，这是它的权力，就跟.net是微软的东西一样
ejb本身并不是impl，而是一个interface，就跟其他所有的j2ee组件一样
都不过是一个标准，你愿意你也可以自己去实现你的ejb容器
就跟jboss一样，而spring本身并不是一个标准，是一个产品的名字
就跟.net没有太大区别，只不过它更兼容其他标准化的组件
所谓的依赖就是要摆脱某一家公司的产品，就是换其他家公司的东西
照用不误，这才叫不依赖，不兼容标准的产品很多，但是你有选择标准的权力
你完全也有不选择标准的权力，我就是要跟定spring了，这也是你的权力
但是这就是依赖，就这么简单的一个定义，有什么很难理解的么？
不要以为开源了之后就万事大吉了，mysql也是开源的
现在在oracle的胯下呻吟，只要有大公司愿意，收购spring不过是钱的问题
事实上spring早已经被收购了，这跟apache是完全不同
apache是非赢利组织，而springsource是公司
这就是区别，另外开源有很多限制，你可以改，但是你如果用来赚钱
人家就可以找你麻烦，开源本身并不意味着给你版权，你没有版权的时候
你改后用，就跟你抄或者说用盗版没有什么两样
很多软件都开源，但是人家没有授权给你做商业使用，你改的时候你要想清楚
那如果不能做商业使用，那你要么跟着一起开源，要么就别用
那雇用你的公司写代码还赚什么钱呢？
【在 w*******s 的大作中提到】
: 我就是特别不理解为什么spring就有depend，而EJB就没有？
: 如果你不打算自己实现一个server，一样会依赖于jboss, websphere, weblogic
: 甚至于，标准不兼容怎么办？算不算依赖？
: 我是认为只要开源，就没有那么可怕，最起码，你可以自己改
|
z****e
发帖数: 54598 | 58 ear包的确会依赖容器
但是这个容器有多个实现
你所说的依赖jboss，websphere等等
没错，但是注意两点
第一，强依赖在j2ee标准化产品中同样存在，就像你说的例子
用了seam，就依赖了jboss，这没错，但是你可以不用非标准化的组件
只要你不用非标准化的组件，至少你的选择就比上面说的强依赖要多得多
依赖一个跟依赖三个比，显然还是依赖三个比较好，更何况还不止三个
每个版本都有一堆的公司让你选择
第二，我们从最起码的说，我们还可以指望非赢利组织，比如apache
这也是为什么apache要搞tomee等项目的原因
哪怕有了jboss，jboss也是开源的，但是这是个公司
当年就差点被oracle收拾掉，要不是fleury最后宁为玉碎，不为瓦全
一头倒向red hat的怀抱，今天就没有jboss这个免费的产品了
或者说jboss就跟今天mysql一样了
商业利益决定了一个公司的产品，本身是不值得信赖的
哪怕这个公司说得再好听，我多么多么nice
但是资本来到人间，从头到脚，每个毛孔都流着血和肮脏的东西
一个商业公司本身是利益驱动的，以最大化股东利益为终极目标
所以资本不作恶，那都是暂时的，将来会不会作恶
鬼才说得清楚，更何况创始人能活多久？公司是理论上永恒存在的
随时都有变脸的可能
所以拥抱apache还是值得提倡的，但是spring和jboss，没有什么太大区别
为了降低风险，一定要减轻依赖，这个应该很容易理解
更何况要谈“最起码”的话，最起码你还可以动手实现一个ejb容器
还没有风险，比改spring强多了
【在 w*******s 的大作中提到】
: 我就是特别不理解为什么spring就有depend，而EJB就没有？
: 如果你不打算自己实现一个server，一样会依赖于jboss, websphere, weblogic
: 甚至于，标准不兼容怎么办？算不算依赖？
: 我是认为只要开源，就没有那么可怕，最起码，你可以自己改
|
z****e
发帖数: 54598 | 59 哦，您在说这个啊
scale
【在 s******e 的大作中提到】
: as said before, spring started eying ejb, but later it evolves to an
: application framework. Comparing ejb to spring is just like comparing ejb
: container to application server, for example, comparing tomcat to full scale
: application servers such as glassfish, weblogic, websphere, or even jboss.
|
z****e
发帖数: 54598 | 60 这个话题不错，值得展开，我先去洗澡，回头说
rules
lazy
graph
brower
【在 t*******e 的大作中提到】
: 我是指EAI。EAI和web application的处理还是相当不同的。一个针对的是B2B，一个是
: B2C。 XML和其他EDI规范一样，很适用于batch data processing。但是EAI处理数据的
: 灵活性不如web applications. 同样的数据在不同页面上处理不同，validation rules
: 也会不同， object graph的fetch深度也不一样。当使用hibernate lazy loading和
: JSR-303 bean validator时候，实现起来效率很高。用xml或EJB remoting就导致lazy
: loading很难实现，（有个家伙搞了个remote lazy loading，但IO的cost很惊人)。后
: 果就是，要么针对不同web screen写不同的sql，或者就是一律返回整个object graph
: ，不管有的数据是否用的上。 而且hibernate auto dirty check也用不上，由brower
: 返回后，不知道那个entity被改动了。
: 其实返回整个object graph对EAI倒是很合适。After all, ESB也就是EAI的一个
|
|
|
z****e
发帖数: 54598 | 61 本来想码字的，但是明天要去看拿破仑的展览，累了，算了
明天再说了 |
t*******e
发帖数: 684 | 62 我发现自己写的东一榔头西一棒。EAI可以写的东西很多。不过integration在大公司里
面都是单独一块，和app/web完全分开了。完全可以再开个EAI的版面。
【在 z****e 的大作中提到】
: 这个话题不错，值得展开，我先去洗澡，回头说
:
: rules
: lazy
: graph
: brower
|
a****i
发帖数: 1182 | 63 很难理解，现在springframework的license是2.0 of the Apache License.
如果你不觉得apache的东西是一种依赖，为什么spring就是？
而且apache，比如struts，1和2的区别基本上就是两个东西
1死了，2半死不活
这个和你担心的公司说变就变有什么大区别？
open source的东西随意性更大
【在 z****e 的大作中提到】
: 这个很难理解吗？
: 因为ejb是标准化的组件，从诞生的那一天起，所有的规范都需要讨论后投票表决
: 而spring是私人的产品，现在是一家公司的产品，只要是公司的产品
: 说变就变，这是它的权力，就跟.net是微软的东西一样
: ejb本身并不是impl，而是一个interface，就跟其他所有的j2ee组件一样
: 都不过是一个标准，你愿意你也可以自己去实现你的ejb容器
: 就跟jboss一样，而spring本身并不是一个标准，是一个产品的名字
: 就跟.net没有太大区别，只不过它更兼容其他标准化的组件
: 所谓的依赖就是要摆脱某一家公司的产品，就是换其他家公司的东西
: 照用不误，这才叫不依赖，不兼容标准的产品很多，但是你有选择标准的权力
|
t*******e
发帖数: 684 | 64 相对而言，springsource私有化了，就有了vendor lock-in的可能性。不过大部分
spring beans可以做到真正POJO，只要不用spring annotations而用JSR-250 common
annotations.
【在 a****i 的大作中提到】
: 很难理解，现在springframework的license是2.0 of the Apache License.
: 如果你不觉得apache的东西是一种依赖，为什么spring就是？
: 而且apache，比如struts，1和2的区别基本上就是两个东西
: 1死了，2半死不活
: 这个和你担心的公司说变就变有什么大区别？
: open source的东西随意性更大
|
a****i
发帖数: 1182 | 65 spring 以前也不是公有的吧，要是哪天spring的人说我干够了，不干了，spring4不出
了，怎么办？
难道说你以前写的用到spring的都死翘翘？
另外，实际的项目，有多少是全用标准，一点第三方都不用的？
有没有？
哦，Java还有个最大的依赖，就是JVM，以前是Sun的，现在是oracle，
是不是换个语言算了？
【在 t*******e 的大作中提到】
: 相对而言，springsource私有化了，就有了vendor lock-in的可能性。不过大部分
: spring beans可以做到真正POJO，只要不用spring annotations而用JSR-250 common
: annotations.
|
z****e
发帖数: 54598 | 66 struts不是标准化的组件啊
所以说改就改，所以被搞死了
servlet就是标准化的组件，到现在还不是照样坚挺？
spring的license是公司自由选择的结果
就按你说的，哪天spring的人说，老子不干了，spring以后版本不出了
你就over了，这就是依赖的恶果
如果你用了ejb，jboss说老子不干了，jboss 8不出了
我换，换成其他的ejb容器，一样用
你好像已经理解了为什么不能用强依赖
怎么说的例子都是在论证不要强依赖呢？
【在 a****i 的大作中提到】
: 很难理解，现在springframework的license是2.0 of the Apache License.
: 如果你不觉得apache的东西是一种依赖，为什么spring就是？
: 而且apache，比如struts，1和2的区别基本上就是两个东西
: 1死了，2半死不活
: 这个和你担心的公司说变就变有什么大区别？
: open source的东西随意性更大
|
t*******e
发帖数: 684 | 67 同意你说的“实际的项目，有多少是全用标准，一点第三方都不用的？”
JVM本身也有规范，最起码还有hotspot, jrockit两个implementations. IBM的那个据
说bug太多。说到IBM，发现在软件销售手法上很恶。东西都是收购过来拼凑出来的大杂
烩，骗不懂IT的管理层的。
【在 a****i 的大作中提到】
: spring 以前也不是公有的吧，要是哪天spring的人说我干够了，不干了，spring4不出
: 了，怎么办？
: 难道说你以前写的用到spring的都死翘翘？
: 另外，实际的项目，有多少是全用标准，一点第三方都不用的？
: 有没有？
: 哦，Java还有个最大的依赖，就是JVM，以前是Sun的，现在是oracle，
: 是不是换个语言算了？
|
T****U
发帖数: 3344 | 68 IBM早就是专搞服务的大忽悠了
【在 t*******e 的大作中提到】
: 同意你说的“实际的项目，有多少是全用标准，一点第三方都不用的？”
: JVM本身也有规范，最起码还有hotspot, jrockit两个implementations. IBM的那个据
: 说bug太多。说到IBM，发现在软件销售手法上很恶。东西都是收购过来拼凑出来的大杂
: 烩，骗不懂IT的管理层的。
|
t*******e
发帖数: 684 | 69 说到JVM，曾经有个日本人凭一己之力在window CE上面写了个full JVM for Java5.0。
超级牛逼。可惜现在mobile programming天翻地覆了。JavaME整个淘汰了。 |
T****U
发帖数: 3344 | 70 android不是用jvm吗？
【在 t*******e 的大作中提到】
: 说到JVM，曾经有个日本人凭一己之力在window CE上面写了个full JVM for Java5.0。
: 超级牛逼。可惜现在mobile programming天翻地覆了。JavaME整个淘汰了。
|
|
|
t*******e
发帖数: 684 | 71 android用Dalvik.
【在 T****U 的大作中提到】
: android不是用jvm吗？
|
z****e
发帖数: 54598 | 72
对啊，所以不能把鸡蛋放在它的篮子里，危险
有啊，我写的项目就尽量减轻依赖，其实标准化的j2ee的组件技术
完全可以应付大部分需求，servlet+ejb+jpa，我用得好好的
其他帖子里面也有人说了
google也是大部分自己写，越大公司，就越有能力自己搞
不仅自己搞，不少公司还包装成产品出去卖钱，比如ibm就是这样干的
而且很多金融集团，自己有自己的it部门，而不是完全去购买ibm的产品
为的是什么？就是这个考虑，金融集团要是有强依赖
要不然哪天ibm什么要修理他们，那个后果是很可怕的
不惜花钱养着一班人，意思就是告诉别人，我随时可以换
实际上系统之间的迁移是可能存在的
只不过说这有可能是一个浩大的工程而已
对，所以有openjdk，sun在被收购前做了一件最伟大的事情
就是把java给开源了，java的商标还是oracle有，这个没错
但是实际上jvm本身也是一个标准化接口
以前每个公司都有自己的jvm，bea有jrocket
ibm有J9什么的，apple也有自己的jvm
所以java本身也是一个接口，并不是一个产品的代名词
只要你愿意，随时可以换成另外一个jvm
不过这样其实有问题，就是不同jvm本身有可能有自己的bug
那么各种实现就需要各种调试，那么oracle后来做了一件事情很伟大
就是说服了ibm和apple等公司，放弃了他们自己的jvm，转向统一支持openjdk
所以到今天，大部分jvm都死了，就剩下两个主流，一个是openjdk
另外一个是oracle自己的hotspot，hotspot就是当年sun的官方产品
然后再往前说，其实java本身被完全贡献出来，不是不可以
一直都有人这么要求sun，但是sun的考虑是这样
就是一旦这个商标被完全公开了，被彻底地公有化了之后
所有人都可以随意更改的话，那么如果有人不按标准做出自己的一套jvm的话
你怎么办？就是出现你说的那种，你改了，不仅改了，还不按标准改了
还商业化了，拿出去卖钱了，那这个时候怎么办？没有办法修理你
因为如果要制止这种行为，最好的方式就是控制版权
没有版权是没有办法修理你的，apache这种非赢利组织是没有能力去打官司的
因为这种公益组织本身并不负责监督，这不是他们的职责所在
而java又不可能成立一个官方的非盈利组织来监督，不象w3c等其他组织
因为其重要性，官方组织是可以存在，到今天java没有一个像样的官方组织
或者说，如果有某个什么类似联合国一样的官方组织来制定java标准
那就太可笑了，这不过是一门语言，所以为了监督这种恶意破坏的行为
以前的sun，现在的oracle必须控制版权，并授权给jcp制定规则
保证java的特性就是一次编译，到处运行，否则这是不可能的
实际上也做得不行，google搞的android跟正统的java是一回事么？
不是一回事，它的api不一样，而且oracle还没有告赢
当年sun告m$，那可是赢了的，迫使m$放弃vj++
不过区别在于google没有说它这个是java
也有好处，通过这种方式告诉oracle，你不要乱搞
如果你乱搞，我有办法跟你对着干，其实oracle也知道
ibm什么，说他们没有能力自己搞一个java出来，那是笑话
所以java能走到今天，说到底是，各方妥协的结果
是政治智慧的体现，当然本身java语法有很多优点
但是java后来大规模流行，跟sun当初一直用一种比较民主的方式管理java
并且控制版权，监督java不被滥用有很大关系
当时一脚把m$踢出去就是一个例证，宁可不要m$这种公司参与
也要维护java的统一，这就是sun监督的好处，否则今天java早混乱了
说什么是标准，jcp就是制定标准的组织，他们制定了这么多标准
http://en.wikipedia.org/wiki/Java_Community_Process
里面啥都有了，完全按照标准做，能应付大部分需求，而且还可以比较高效地开发
完全不依赖，这是一个理想状态
但是并不代表说，理想状态达不到，就不需要去逼近这个理想状态
【在 a****i 的大作中提到】
: spring 以前也不是公有的吧，要是哪天spring的人说我干够了，不干了，spring4不出
: 了，怎么办？
: 难道说你以前写的用到spring的都死翘翘？
: 另外，实际的项目，有多少是全用标准，一点第三方都不用的？
: 有没有？
: 哦，Java还有个最大的依赖，就是JVM，以前是Sun的，现在是oracle，
: 是不是换个语言算了？
|
z****e
发帖数: 54598 | 73 如果是full jvm的话，那应该是jse啊
jme是被淘汰了，以前官方就一直在说要淘汰jme
因为觉得现有的机器完全有能力支持jse
所以那个日本人如果搞的是jse的话，不应该被淘汰啊
【在 t*******e 的大作中提到】
: 说到JVM，曾经有个日本人凭一己之力在window CE上面写了个full JVM for Java5.0。
: 超级牛逼。可惜现在mobile programming天翻地覆了。JavaME整个淘汰了。
|
t*******e
发帖数: 684 | 74 winCE还健在吗？
【在 z****e 的大作中提到】
: 如果是full jvm的话，那应该是jse啊
: jme是被淘汰了，以前官方就一直在说要淘汰jme
: 因为觉得现有的机器完全有能力支持jse
: 所以那个日本人如果搞的是jse的话，不应该被淘汰啊
|
z****e
发帖数: 54598 | 75 嗯，api不行
早点做ios版本的，估计现在就大红大紫了
【在 t*******e 的大作中提到】
: winCE还健在吗？
|
a****i
发帖数: 1182 | 76 如果没有JBoss，没有Glassfish，就是websphere和weblogic两家
在我觉得那比spring一家要危险得多
虽然spring只有一个篮子
别的不说，就想M$那样，给java加点料，你要遵守标准
我偏偏给你提供非标准的api，性能更好，用着更方便
你用不用？
不用就是重新造轮子；用就是依赖
而且这种依赖你还不容易摆脱，什么都被别人控制
别看好像有两个篮子，比spring那一只篮子要危险得多
问题的核心不在于你有几只篮子，而是你对那些篮子有多大的控制力
所以我会选择开源的
标准不标准，其实更多的影响是对外的部分，象rest这样的
EJB这样偏底层的，标准没有那么重要，反而把问题弄复杂了
【在 z****e 的大作中提到】
: 嗯，api不行
: 早点做ios版本的，估计现在就大红大紫了
|
z****e
发帖数: 54598 | 77 才两家？
你确定么？
http://www.oracle.com/technetwork/java/javaee/overview/compatib
看看多少家
javaee6因为对jsp做出了调整，有大改动，所以小公司需要时间调整
这个名单随着时间的流逝会逐渐变多
看javaee 5有多少家
http://www.oracle.com/technetwork/java/javaee/overview/compatib
你说的m$，我不用啊
jboss什么都有提供额外的api
我可以选择不用，所以对标准的了解非常重要
而且性能更好这个很值得商榷
非标准的东西是不是性能更好，这个从来没有定论
只有可能是跟某一个产品的协作性能更好
因为内部会优化，但是一般这种优化的程序我觉得是有限的
现在这种环境，硬件日新月异，没有什么软件是能够保证性能更好的
所以兼容性反而更值得重视
就你说的篮子，你对spring有什么控制力
jcp对ejb有很大的控制力，每一个版本的javaee都需要投票表决
其中就有apache，ibm, oracle, interface21 etc.
struts的例子很好，spring哪天要是头脑发热
瞎搞，把自己搞死不是没有可能
【在 a****i 的大作中提到】
: 如果没有JBoss，没有Glassfish，就是websphere和weblogic两家
: 在我觉得那比spring一家要危险得多
: 虽然spring只有一个篮子
: 别的不说，就想M$那样，给java加点料，你要遵守标准
: 我偏偏给你提供非标准的api，性能更好，用着更方便
: 你用不用？
: 不用就是重新造轮子；用就是依赖
: 而且这种依赖你还不容易摆脱，什么都被别人控制
: 别看好像有两个篮子，比spring那一只篮子要危险得多
: 问题的核心不在于你有几只篮子，而是你对那些篮子有多大的控制力
|
a****i
发帖数: 1182 | 78 重点根本不在于有几家做j2ee
我提M$只是说所有公司和M$都没什么区别，他们能独占市场加自己的料的时候，绝对不
会手软
什么标准不标准？他们就是要搞自己的一套，让你用了他们的东西就只能一直用下去
把别的那些标准公司都搞死才好
spring，如果把自己搞死了，起码我有它没死时候的代码，可以自己弄
这就是控制力
jcp对ejb有控制力，跟你有什么关系？
你对ejb还是一点控制力也没有
再说，jcp要是把ejb搞死了呢？
你觉得投票就不会搞死了？
【在 z****e 的大作中提到】
: 才两家？
: 你确定么？
: http://www.oracle.com/technetwork/java/javaee/overview/compatib
: 看看多少家
: javaee6因为对jsp做出了调整，有大改动，所以小公司需要时间调整
: 这个名单随着时间的流逝会逐渐变多
: 看javaee 5有多少家
: http://www.oracle.com/technetwork/java/javaee/overview/compatib
: 你说的m$，我不用啊
: jboss什么都有提供额外的api
|
g*****g
发帖数: 34805 | 79 Regarding vendor lock-in. Spring has two advantages.
1. It's Apache license, so someone can branch it if there's no continued
support. Think of how Amazon takes on Google's Android code.
2. Spring is an embedded container, which makes it more flexible than
standalone ejb container. Say if Spring becomes legacy code and everybody is
using ejb, you can put that piece of legacy code in your ejb 10.0 container
. You can't do it the other way around. i.e. Spring has less dependency. It'
s like comparing Jetty to Tomcat. |
z****e
发帖数: 54598 | 80 jcp是一个你可以参与的社区
jcp所有标准都是一个凡人可以讨论并积极参与的东西
区别在于你说的有可能别人不接受而已，这是一个民主投票的过程
我觉得你知道这两个程度上的差别
但是你不愿意承认罢了
无非就在99％和1％之间强调100％和0％的差别
只要不是100％或者0％，那么99％和1％就没有差别
这就是你要说的，无非你要说的就是一家控制跟n家控制没有区别
那行吧，那你赢了，1跟13都是无差别的，那我能说什么呢？
另外感觉你对标准太过于轻视，压根就不想去了解
说了n个破绽了，前面说只有两个是你，现在说jcp完全跟凡人无关的也是你
实际上这都是错的，无非就是故意混淆程度上的差异
把1％等同于99％，因为都不是0％或者100％
我承认0％是一个理想状态，永远实现不了
但是我认为，1％的耦合也要远好于10％的耦合
1％的依赖，也要远好于10％的依赖
还是老话，达不到并不代表不要去做
世界上做不到的事情很多，但是追求一种理想境界的努力永远都不会停止
【在 a****i 的大作中提到】
: 重点根本不在于有几家做j2ee
: 我提M$只是说所有公司和M$都没什么区别，他们能独占市场加自己的料的时候，绝对不
: 会手软
: 什么标准不标准？他们就是要搞自己的一套，让你用了他们的东西就只能一直用下去
: 把别的那些标准公司都搞死才好
: spring，如果把自己搞死了，起码我有它没死时候的代码，可以自己弄
: 这就是控制力
: jcp对ejb有控制力，跟你有什么关系？
: 你对ejb还是一点控制力也没有
: 再说，jcp要是把ejb搞死了呢？
|
|
|
z****e
发帖数: 54598 | 81 当年我在上课的时候
教我微积分的老师，鼓励我去投票
因为人们花了几百年的努力，才争取来投票的权力
你完全可以说，这跟你有屁关系，你以为你投票了右翼份子就不会上台了？
是，我投票了，它还是可能上台，但是至少我可以阻止它一点点
哪怕这一点点微不足道，但是我相信
我相信群众的力量，一点一滴的努力都可以改变这个世界
那就看你是否愿意去贡献这一点一滴的努力了
实际上java就是靠着这一点一滴的努力才有了今天
老早就有人总结过了
java之所以流行，跟其语法没有太大关系
是因为它是一个民主的语言，正是因为它允许所有人自由参与
所以才使得它更容易让人接受，而不是什么控制力
控制什么呀？所谓的控制跟开源的精神本身就相悖
凭什么控制别人？spring有说过自己有控制力么？
开源什么时候强调过控制力，那是垄断资本说的那一套
奥尼尔可以横行篮下，所以说控制力，实际上控制力这个概念是它吹牛的
要不是裁判照顾，湖人三冠去掉两个，一次输给国王一次输给开拓者
足球场上就毫无控制力可言，哪个球王敢说控制力？
因为东西一旦做大，人一多，所有东西都需要配合，那么配合的基础就是规则
而这个规则是人们商量出来的，而不是随心所欲地蹂躏规则，也就是所谓的控制力
蹂躏规则的人最终会被规则所蹂躏，我相信多数人的力量，而不是什么控制力
控制什么呀？spring能控制谁啊？连个悉尼它都控制不了，还控制states？
商业化了之后，连母公司都控制不了，更不要说整个世界了
标准的东西一在于你可以参与，二标准的东西提供了更多的产品支持
spring的所谓的扩展，都是spring自己提供的，其他公司什么提供了支持？
hibernate有提供过spring版的sessionfactory么？没有啊，是spring自己搞的
ide的支持有么？那也是通过spring自己提供一个ide的插件来帮助开发
而ejb完全不需要任何的插件，一路向导点下去，搞定
各个ide的版本都提供支持，eclipse juno下下来，每次按new project
里面就有选择，web project, ejb, java ee project etc.
有见到spring project吗？没有啊
为什么？标准的东西，很多东西都会支持
非标准的，那就不太好说了
【在 a****i 的大作中提到】
: 重点根本不在于有几家做j2ee
: 我提M$只是说所有公司和M$都没什么区别，他们能独占市场加自己的料的时候，绝对不
: 会手软
: 什么标准不标准？他们就是要搞自己的一套，让你用了他们的东西就只能一直用下去
: 把别的那些标准公司都搞死才好
: spring，如果把自己搞死了，起码我有它没死时候的代码，可以自己弄
: 这就是控制力
: jcp对ejb有控制力，跟你有什么关系？
: 你对ejb还是一点控制力也没有
: 再说，jcp要是把ejb搞死了呢？
|
T****U
发帖数: 3344 | 82 好像技术讨论上升到哲学高度了阿
【在 z****e 的大作中提到】
: 当年我在上课的时候
: 教我微积分的老师，鼓励我去投票
: 因为人们花了几百年的努力，才争取来投票的权力
: 你完全可以说，这跟你有屁关系，你以为你投票了右翼份子就不会上台了？
: 是，我投票了，它还是可能上台，但是至少我可以阻止它一点点
: 哪怕这一点点微不足道，但是我相信
: 我相信群众的力量，一点一滴的努力都可以改变这个世界
: 那就看你是否愿意去贡献这一点一滴的努力了
: 实际上java就是靠着这一点一滴的努力才有了今天
: 老早就有人总结过了
|
y***y
发帖数: 224 | |
l*******G
发帖数: 1191 | 84 为什么M$连XML 都要搞自己的一套啊，会把自己玩死。 |
T****U
发帖数: 3344 | 85 垄断的本性
【在 l*******G 的大作中提到】
: 为什么M$连XML 都要搞自己的一套啊，会把自己玩死。
|
M***0
发帖数: 1180 | 86 prototype和stateful不相同吧？
比如
public class A
{
private int i=0
public int foo()
{
return ++i;
}
}
如果是stateful，同一个client session调用2次，分别返回1和2
如果是prototype， 两次都返回1
不是吗？
【在 z*******3 的大作中提到】
: java这一行牛人实在太多
: 随便说几个
: jboss创始人marc fleury
: 本科和phd毕业于école Polytechnique，硕士在巴黎高师读的
: 专业是理论物理和数学，这两个学校在法国大学里面的档次
: 就相当于中国的清华北大，可能还要高一点
: 因为收的人数实在是很少，一共加起来在校生不过几百人
: 而且这两个学校在历史上都是培养出无数杰出数学家的学校
: 巴黎高师更是当今世界上数学第一大牛校
: 五分之一还多一点的菲尔兹奖获得者都毕业自这个学校
|
t*******e
发帖数: 684 | 87 client session就是指thread吧。这个都会返回1，2。除非你inject A两次，否则第一
次返回一个instance后，第二次还是reference同一个instance，不管是stateful ejb
还是prototype spring bean.
【在 M***0 的大作中提到】
: prototype和stateful不相同吧？
: 比如
: public class A
: {
: private int i=0
: public int foo()
: {
: return ++i;
: }
: }
|
M***0
发帖数: 1180 | 88 Yes, you are right. I just tested it.
如果调用者是prototype controller，其实是inject A两次了
ejb
【在 t*******e 的大作中提到】
: client session就是指thread吧。这个都会返回1，2。除非你inject A两次，否则第一
: 次返回一个instance后，第二次还是reference同一个instance，不管是stateful ejb
: 还是prototype spring bean.
|
M***0
发帖数: 1180 | 89 可不可以这么说：如果application的访问量在高峰和低谷差别非常大，出于server和
application的健壮性考虑，是不是选用EJB而不用Spring (因为可以控制stateless
session bean的数量)? |
t*******e
发帖数: 684 | 90 stateless singleton spring bean和pooled stateless session ejb在scalability上
应该没有什么区别。否则spring framework就活不下去了。
具体看为什么method local variables是thread safe就可以了。
【在 M***0 的大作中提到】
: 可不可以这么说：如果application的访问量在高峰和低谷差别非常大，出于server和
: application的健壮性考虑，是不是选用EJB而不用Spring (因为可以控制stateless
: session bean的数量)?
|
|
|
g*****g
发帖数: 34805 | 91 As long as you don't need exclusive access to the singleton, I don't see why
the bean needs to be pooled.
【在 t*******e 的大作中提到】
: stateless singleton spring bean和pooled stateless session ejb在scalability上
: 应该没有什么区别。否则spring framework就活不下去了。
: 具体看为什么method local variables是thread safe就可以了。
|
t*******e
发帖数: 684 | 92 A solution based on exclusive access to a singleton won't work across
classloaders, suggesting it doesn't scale.
why
【在 g*****g 的大作中提到】
: As long as you don't need exclusive access to the singleton, I don't see why
: the bean needs to be pooled.
|
