我想知道标准的真正意义在于??

         
bloodrate
09-07-11 34 1425

在JAVA企业级应用中仿佛JCP就像一个旗帜一样,前一阵无事,便对JCP中的900多条jsr浏览了一遍,总结有以下几种情况:

1、JSR包含规范的描述,以及提供这个规范的标准接口API,一个仅仅由接口和部分具体类组成的jar包,比如说Servlet规范,这点很好理解,不同厂商的服务器对Servlet相关接口都有自己的实现,这样可以让开发人员让开发的代码不依赖于具体的容器。

2、与第一种情况不同的是,第二种规范提供绝大多数具体类和一小部分spi由厂商实现,比如jax-ws规范。

3、第三种规范提供完全的具体类组成的jar包,其中没有任何厂商自己实现的内容,比如jaxb规范。

如果所有规范都是第一种情况,那么我还好理解,就像是工业部门定义螺丝帽必须直径五厘米,然后所有螺丝钉厂商都要按照这个规格制造,这样就能让产品选择不依赖于厂家。但是第二甚至第三种情况就让人纳闷,规范组织定义一个完全不需要厂商实现什么的东西作为规范有什么意义么?这就像洗发水规范组织定义“用洗发水必须用飘柔牌”的一样,人家凭什么只用jaxb阿?

如今开源框架比比皆是,最盛行的就算SSH,但是SSH本身并不是规范,很多人也因此认为ejb比SPRING有更长的生命周期,即便这个人本身很讨厌EJB也会下如此结论,那么规范真的有那么大魔力么?一个根本不需要别人实现的规范意义有在哪里?那顶多算做一个优秀的实现又怎能算作一种规范呢?

banq
2009-07-11 16:25

规范标准这玩意前几年我也比较推崇,但是现在明白它阻碍创新。标准总是落后现实,一般最多是对现实进行名义上的追认,如果超于现实,有可能条条框框太多,把本来有一点的先进性给扼杀了,比如EJB。

EJB的先进性在于一步到位,一揽子方案都在里面,由于设计有先进性,迫使很多厂商高手在短时间内要拿出产品了,牺牲了透明性可切分性,结果到现实中,很多场合并不是事务集群两个都要,总是有侧重点,但是由于不可切分或不透明,只好两个都要,反而成了包袱,这个道理和数据库是个盒子道理是一样的。

打个比喻,你请一个保姆,她做饭做得很好,但是打扫卫生并不让你满意,但是她和你说:要么辞了她,要么两个都接受,这就是打包的坏处。

而且,EJB还没有彻底标准化,比如JPA,有Hibernate和TopLink实现,这使得GlassFish和JBoss之间的EJB移植总有些区别。

现在,技术发展很快,各种动态语言带来的新设计理念也冲击,单靠一个框架或一个标准横行天下很难,因为这些框架标准如果走到一半,脑子出问题,走向另外一个方向了,这就带着我们偏离主流方向,因为没有谁可以准确预料下一个Big Thing是什么。


[该贴被admin于2009-07-11 16:29修改过]

bloodrate
2009-07-11 17:51

我以前一直持有的想法是"标准是根源",因为框架那么多,如果挨个学习到死也学不完,但是其中囊括的思想是有限的,是可以学完的,我以为这些思想在标准中得以体现,我一直以为,看JPA官方文档比学习Hibernate技术手册有意义,因为如果标准不变,未来无论用什么持久层架构,掌握了标准,剩下的实践无非就是api换个别的名字而已。
可是我后来发现不是这个样子。。。很多常用的框架不是标准,很多标准也滥死在胎中,这使我疑惑现在标准是不是还本着最开始的初衷,是不是已经变味了
[该贴被bloodrate于2009-07-11 17:52修改过]

banq
2009-07-11 17:59

是这样,这就要看标准制定是给谁把持,这有点技术政治味道,标准制定是不是真正为用户服务,还是为少数厂商利益服务的,如果是后者,那么就让标准变得很臭。

所以,标准就象是一个美丽童话,只不过用来诱骗天真者或一些初入门者,因为他们在浩瀚的框架技术面前,失去方向,需要稻草,其实标准不是稻草,只有用架构设计武装自己的脑袋,才是真正解决之道。

所以,架构师就非常重要,他要在众多自称是Big Thing的技术中为所在产品选择一个方向,必须照顾普及程度和难易程度,以及重量轻量的衡量,还有可伸缩性可扩展性的考量,试想想,如果标准真那么灵,那么我们就不需要架构师,采取标准方案就可以了,事实上并非如此,这就是很多公司技术决策者没有注意到细节,从而付出相当的代价。


bloodrate
2009-07-11 18:06

恩,我是觉得jcp一直被SUN控制着,JCP里面的东西有一些是非常有用的但是多数是垃圾,JCP的唯一优势是打着便准化的旗号,让人觉得权威。但是已经崛起的一些社区apahe,springsource,objectweb已经达到同样权威的效果了。

7Go 1 2 3 4 ... 7 下一页