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

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

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

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

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

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

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

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

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

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

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

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

各个层面上都需要标准（或规范或协议）的。
1）零件级
楼主说了螺丝，就是一个很好的例子。甲厂做的5mm螺丝肯定可以和乙厂做的5mm螺帽配用。没标准就不行了。
2）总成级
冰箱压缩机有标准。一些厂专门生产压缩机，冰箱厂向他们采购。只需要关心其质量与价格，买来肯定装得上，肯定和蒸发器、冷凝器等其它部件配得上。
3）整机级
也得有标准。你生产100V60Hz的冰箱，我家里就不能用，你只能出口到美国去。
J2EE的各层之间必须有关于接口的标准，没标准各层无法对接。J2EE里的各种容器，必须得有标准，否则怎么放代码？与DB的接口也必须有标准，譬如ODBC。
组件必须有标准，有标准，才体现组件的威力。公司里，张三做的组件，李四做的，兄弟公司帮助做的，向外面买的商品组件，都可以轻轻松松地组合在一起。
J2EE也是一个标准，一个J2EE应用（即符合J2EE标准的应用代码）肯定可以安装在J2EE应用服务器（符合J2EE标准的应用服务器）上。没这标准，那换个服务器，就得重写代码。
banq说的EJB问题，是EJB本身的设计思想问题，它是大而全。譬如，它包括了分布式机制，可现在多数应用并没分布需求。如果把它砍掉，肯定能提高效率。EJB必须得有标准，这个EJB本身特点决定了的。没标准，这EJB一点用也没有。
标准是有保守性，这个没错，同意banq。不过这个代价是标准必须付出的，而且是利远大于弊。
其实，世上最具保守性的东西，恰恰是我们引以为傲的软件。这个被公认为世上最先进的东西，其实也是世上最具保守性的东西。

是啊，SUN一直把持Java标准，从Java5/6/7引起的争议来看，SUN这头犟驴已经越来越显示固执了，把愚顽当作创新，这就是SUN目前自我感觉良好的原因，特别是被Oracle收购后，两者简直是臭味相投：重量级别臭味。

怎样在平台Stack和轻量之间有一个选择平衡，是非常体现设计技巧的，就像老子的无为而治道理一样，无为不是不为，而是无所不为，但是如何做个平衡，就是大智慧体现了。

to beepbug:

我也同意标准的重要，但是考虑一个现实问题——当在进行企业级应用设计的时候，这些存在的JAVAEE标准并没有给设计人员带来“哇~我买螺丝帽不在需要考虑哪家螺丝帽能匹配我的螺丝钉”这样的惊喜，甚至设计人员无需关注标准就开始进行设计。考虑如果你是一个房屋设计师，你负责设计门窗，在设计螺丝钉的时候，你肯定优先考虑螺丝钉要符合什么规格，要国标xxxx的，然后才选择哪家的质量过关，这说明工业级标准在工程中根深蒂固。可是软件呢，有多少人在设计过程中“这里作javabean映射的工具要jsrXXX标准的，以便能够支持xxxx的扩展”。

to bloodrate
组件技术，是为了使软件生产能像搭积木那样。显然，必须用标准对组件绳之以法，否则就没法组装。
JavaBean是用Java语言编写的可重用组件。既然是可重用的，那相关的标准肯定需要更强势。
如果你在生产过程中没有感觉到标准的存在，可能是由于所用工具的缘故。
同样以螺钉生产为例，如果你是用车床加工，你必须控制好螺钉的外径在某个范围内，必须控制螺距在某个范围内。你得成天拿着卡尺量着。不符合标准的，是废品，即使让商家卖出去，还是要退回来。
如果你用全自动的螺钉机生产，你一开机器，就可以打毛衣。你从参加革命开始，直到退休为止，你可以一点也不知道有螺钉标准这回事，照样月月拿工资。
同样，如果让你只拿记事本写代码，你就必须通读SUN的那个JavaBean规范。这个可不是几句话或是一页两页。很厚的一本，你必须时时处处按它说的做，一点也马虎不得。

to beepbug:

你还是没理解我的意思，我的意思是说，“标准”这东西如果大家人人都遵守那么它是有价值的，如果不是则价值下降。就像如果你设计一个软件，中间某个过程需要javabean与xml之间映射，其实有标准的jaxb组件，但是更多人喜欢去apache-common中寻找非标准的解决方案，因为它更大众更好用。你说工具让你感觉到了标准不存在，是不假，但是讨论标准需要站在你是个工具设计者的角度上，而非工具使用者，如果此时标准还是很透明，是不是就有问题了？如果设计门窗不用标准的螺丝那是找死，如果设计软件你可以心安理得的使用apache的东西而不用理会JCP的存在，一样可以制作出好东西来。

to bloodrate
你说到这旮沓，就涉及到关于标准的一个老早就存在的有趣现象：事实标准。
标准的本义，是由某个独立的有权威的组织为某种具有公共性的东西制订的具有公正性的规范文本。颁布后，大家都照着做。
但是，有时侯，某机构（也可能是个人）推出一个东西，很有价值也很有普遍意义，大家一窝蜂地照着做，这就形成了一个事实上的标准。譬如，PC机，全世界这么多的厂商在做，有做板子的，有做部件的，有做零件的，拿到整机厂，一装就成。个人也能DIY。这里面有无数标准，都是不成文的标准。
又如某公司是在该领域里的技术领头羊，它所制订的内部企业标准，就常常成为整个行业的事实标准。譬如，桥与路的结合处是个技术难点。原先是德国某公司技术领先，全世界按它的企业标准做产品。前几年，宁波一家企业急速远远超过了它，它就来向中国企业要企业标准。
还有，某个国家的工业标准，也可能成为世界级标准。譬如，关于C语言，很早以前，美国就有个国家标准ANSI C。计算机技术一直由美国垄断着，C也是美国发明的，因此，全世界都以这ANSI C为事实标准。直至国际标准化组织ISO和IEC制订出C标准。
很多事实标准，流行了很多年，仍然是事实标准，这可能有许多种原因。最多的有两种：一是具垄断地位公司（如PC依循的是IBM）提出的，基于反垄断，难以进入世界级标准机构；二是不入流公司甚至个人提出的，大公司抵制，也难以成为真正的标准。
都说SUN掌控着Java的标准，其实是底层的标准，上层的，还是八仙过海各显神通。在Java世界，真正成文的只占标准的一个零头，主要还是事实上的标准。这就是开源的特点。
如果你发明了某一Java技术，有很多人认为好，都学着做，你也就成了事实标准。谁力气大，谁就是王。
如果说保守，标准这东西算好的了，和自主创新捆绑在一起的专利才是保守党。专利的反动性比标准强得多。

你说“标准这东西如果大家人人都遵守那么它是有价值的，如果不是则价值下降”，这是对的。
标准必须跟住形式发展，必要时就得修改。GB12345-2009，表示国家标准，第12345号，2009年修订的。
国际标准组织也不止一家，譬如与IT有关的，至少有ISO、IEC、IEEE等。竞争也激烈，以减少标准的负面。
如果多数人以为，SUN制订的某个Java标准，不如bloodrate所做的，那个标准就被bloodrate废了。

说的有道理，而且我还认为标准应该是抽象的东西，不应该是具体的东西，具体到软件中，标准应该是关于接口（interface）的描述而不应该是一个API文档。比如你可以这样规定“无论你制造什么，你用的变压器必须具备xxx的功能，电压在xx到xx之间。。才能保证你制造的产品与其他产品兼容”，但是规定成“无论你制造什么，你用的变压器应该是xxx制造的”这样榜定一个具体的东西就不是标准了。而JCP大量的标准都是由具体实现类组成，比如java5中Annotation。

JCP指的是Java Community Process吧？
如果你开发了一个Java产品（应用服务器、应用软件、开发工具等）或组件，你希望向全世界宣称，你的东西是符合J2EE规范的，你得向JCP申请TCK兼容性测试（要付钱），通过后，向SUN缴纳J2EE商标使用费。
它提供的或提出的东西，并不是标准，只是范本。
你看见的Annotation，可能也是范本。网上充斥着许多如何自制Annotation的文章。
没有一个标准会去规定具体内容的。标准规定的，一般是接口、功能、性能、质量等。

现在标准这玩意我发现成了干扰视线的障碍，就以集成方案来讲，就有两套思路，按照标准思路走的，EJB/Web服务/ESB/JBI等等；还有一种就是根据需要不断定制的，比如RESTFul Mule Jgroups等等。

就集成方案而言，SOA则是在服务器后端的大规模武器，是业务层的伸缩性体现，而REST等则是面向资源ROF的解决方案，侧重在表现层这里做文章，从这里一看，两者思路就不一样。

对于有钱的主，可以选择标准，因为标准后面都是虎视眈眈的厂商，你如果怕承担责任或出了问题找不到人解决，就选择厂商标准(标准概念已经异化为厂商标准)。但是这是一个无底洞啊，除非你的企业是依靠垄断获取利润的。

选择厂商标准，光有钱还是不够的，需要有掌握这套标准的人才，招聘是招聘不到的，那就请他们培训，以为靠培训就能解决技能掌握？太幼稚了，根本没有意识到这些标准太重量级别了，没有几个天才程序员能够短时间内掌握这么重量的开发武器。

所以，有时选择标准，就和上了贼船一样。

[该贴被banq于2009-07-13 15:20修改过]