ejb、spring，这不是java界最有名的两大冤家，何以把它们扯在一起。其实spring乃是ejb1.x、2.x的继承者，正如ejb之前的com、corba。他们的思想一脉相承，那就是企业级的组件化思想，也可称之为理想！
一、非组件化的国内软件行业
各个行业的企业总有一些核心业务，长久保持不变，新时期的新业务基本上都是围绕核心业务展开。很长时间以来，it技术的变化与企业业务的扩展存在着很大的矛盾。当企业的新业务开展之后，如何保证原有业务稳定运行的同时，新业务能够得到it的支持与扩展？当it技术有重大进展后，如何保证原有业务的同时进行新技术改造？在以上两种运动中，如何重用原有的技术成果？这是每一位负责任的系统管理员、cio与及开发商所关心的事情。遗憾的是，组件化思想及实践产生以前，这个矛盾基本上是极难解开的死结。绝大多数的做法就是重写。
譬如dos时代，很多单位都使用了单机foxbase版的财务系统，界面虽简但稳定实用；到了windows时代，流行vb、pb，于是系统重写；再到b/s时代，系统再次重写；到最近热炒的ria，系统是不是要再次重写？对于很多小产商的作品而言，答案肯定是yes。
很多同道可能会说，这样正好啊？我们才可以不断地赚钱。错！
这样的状况叫“低水平重复”，这个术语经常被国人用来痛斥社会经济领域的很多不合理现象。可惜我们这个自认为高智力的行业，很多时候就是在干这种愚事。每到技术革新，各企业要重花一次钱、重学一次操作、重转一次数据，折腾得半死；而适应不了新技术的产商，随被淘汰的代码一同退出市场；适应不了新技术的程序员，只能转行。要想不被淘汰，就必须紧跟时代风潮，不停地把精力放在新技术上，在领会业务上花的时间太少，最后导致我们的系统与企业的业务总是差半拍。因为原先快把业务搞清楚的程序员大多升官或离职了。
笔者以为这是软件界，尤其是国内软件界混乱的根本技术原因。由于技术长期得不到积累，我们不得不一次又一次吃外国的人剩饭。
那我们终究需要怎样的软件才能解决这些问题。
其实答案早就在我们身边晃了太多年，偏偏我们视而不见。大家接个新外设，要不要换主机？加根内存条、换块显卡、声卡要不要换主板？os是不是只能用几个特定的硬件，跑几个特定的程序？而大家在os下写的程序，是不是在系统新版本运行不了？答案基本上是否定的。
os可以适应全世界数以万计的程序及其发展，为什么我们的应用程序不能适应哪怕一个特定单位的变化和发展。为什么我们的应用系统到了新环境下就要重写？
原因就在于我们大多数应用程序规范性太低、耦合度太高。
要提高规范性、降低耦合度，就要不断地设计、不断地分层、不断地抽象、不断地重构。当我们终有一日把有用和成熟的代码封装成jar或是dll，不仅自己能重用，别人也能重用的时候，代码其实才算合格。
现在大家都习惯用开源产品了，外国人热衷的就是不断地制造这样的零件（组件）或技术。而我们中国人，热衷的却是组装人家的零件和技术（一如其它涉及技术的产业）。很多外国人十多岁就做出了了不起的组件，而我们中国人却把“不重复发明轮子”这种搬来的话挂在嘴在，结果是既不制造旧轮子，更没有能力发明新轮子。很多人从业十多年都写着乱糟糟代码。
项目，不是说东西扔到客户手上套足了钱，拍拍屁股就走人。成功的项目，要对客户负责任。就算自己退了，也该把工作交接好。前面的工作成果后面用不上，只能说前面的工作不合格。
国内应用软件界一直在走rad的道路，一开始吃着爽，越到后面越不是滋味。不是说rad不能用，而是说，一上来就rad，注定被养成懒汉，早晚沦落成编码机器。rad诱使我们逃避思考，诱使我们逃避设计，最终让我们被早早淘汰！
二、ejb、spring的组件化实践
在ejb之前，大家所知的com和corba已然火过一头了。这说明国外企业在经过长时间的信息化实践后，已经深受上面所说“低水平重复”的非组件环境之苦。com和corba的确解决了一些问题，但还没有成为那种完整、成熟的体系。所以当初ejb出来的时候，业界疯狂热炒。这一方面是商业原因，更重要的是企业及开发者对组件化的热切理想。其实ejb的确是成功地解决了很多问题，但由于一开始就定位在高端，技术上相当复杂，导致众多开发者真正未能掌握，由此而产生了很多失败的项目。
这个时候，ms的.net开始热了起来。.net其实整个思想体系都是参照j2ee的。不过沿袭了ms产品一贯的易用风格，中小系统实现比较容易。但凡事有利有弊，ms为了迎合初学者偷懒的心理，架构上的rad风格是相当明显的。很多人不知不觉中又被养成了懒汉。这导致很多开发者拿着.net这种oop的企业级技术，继续做过去那些高耦合的系统。最终结果，不论是开发者还是公司，都将重蹈以上笔者所说的覆辙。
应该说，j2ee一上来就强制开发者考虑oop、分层、解耦、重用，这些很复杂但最重要的事情，最终必然后落得个“曲高和寡”的结果。但如果开发者真能以程序设计作为自己的毕生事业，就一定可以在java的世界里经过痛苦摸索，掌握软件的精髓。
而后，火热的spring运动开始了。rod集多年企业级开发的功力，创造性地开创了简化版的ejb：spring framework。这里有个前提，那就是rod多年企业级开发的实践，包括ejb的实践。正是这个精通ejb的天才人物，才可能对ejb进行简化和发挥。国内很多人自此运动后，把ejb以至于sun形容得一文不值，却忘了自己每天都在用java这一伟大的语言，并实践ejb这一技术所传承的组件化思想。而初学者在不明就里的阶段，只记住了spring的简化，却不知实践组件化的根源所在。也就是说，不是spring不好，而是说大家应该充分领会spring所一脉相承的组件化解耦思想，而不只盯住spring的简化。
自此，java界开始了无尽的混乱。人们每天都在考虑如何“简化”j2ee，以至于把j2ee简化到web+db，简化到php那样高耦合的程度，或者骑墙式的ror。历史再度倒退，组件化面临严重危机，甚至于坚持组件化的java也被殃及池鱼。
这里不得不称赞一下jdon和当家人banq。其实有一阵笔者也是spring运动的热心拥护者，对banq的ejb论调相当不感冒。待自己晕头转向了两年，重回jdon，这才体会到banq的苦心。
正如众所周知的英语学习无捷径，好的程序设计同样没有捷径。
banq这几年冒天下之大不韪，一再坚持重申这个世间最简单的真理，的确是值得敬佩的。
三、坚持组件化，打造真正的软件工业
软件发展到今天，其实应该并且能够进入到工业时代了。
前面所说的企业软件危机，既是技术问题，也是产业问题。
今天，地球人的各种产业都是大分工、大合作的工业化产业链。生产效率提高了，就业人群也随之增加。在封建时代，大家都搞小作坊和行会，总觉得如果放开了，分工后大家会没饭吃。但资本主义的实践表明，越是分工合作程度高的产业，规模越大。原因很简单，在生产效率提高的同时，消费被极大地刺激，以至于产业膨胀的速度仍赶不上消费。像现在的汽车，分工合作程度极高，使发达国家的人们买了一辆再买一辆，换了一辆再换一辆，结果是整个汽车产业的繁荣。
我们软件业（尤以国内为甚）其实也一样，表面上是没事可做，事实上是由于软件业整体的低效率，导致人们用不起软件，或不敢用软件。成天忙于低水平重复导致的低水平局部竞争，企业真正关心的很多需求得不到满足。长久之后企业在信息系统得到的回报太小，自然不愿意花钱在信息系统上。
其实大多数开发人员和开发商，都想充分满足客户的需求。可惜你几十号人，打个比方，如果从种橡胶、挖铁矿、到设计车型，焊接，推销。什么都要做，只怕是连小推车也造不出来的。
所以我们一定要分工合作。
现在电脑有了，os有了，db有了，编程语言有了，这些最难做的基础工作外国人都做了。但进入企业级领域仍有无数的工作在等着你。国人在这一点上缺乏合作精神的劣习暴露无遗。明明只是精通业务，非要对设计指手划脚；不过是分析专家，非要对不熟的技术挑三捡四；明明可以沿用原系统的精华部分，非要替换以示高明；更有不懂事的毛孩子，自以为可以用rad搞定一切。很多国人的牛人都一种普遍的“超人”意识，老子天下第一，其他人都是垃圾。殊不知软件业太大太复杂了，再新手的同道，也有很多你不知道的重要知识和奇思妙想；再高的所谓大虾，也有无数的盲点和愚见。
所以要分工合作，一定要学会尊重他人，实事求是。
至于技术上的问题，其实以笔者愚见。至少spring已经基本上解决了“解耦”的重大难题。大家只要不偷懒，把自已写的、别人写的、书上看的，网上下的，好好琢磨透了，以spring这种大体上“无侵入”的框架装配起来，即可基本上解决组件化的难题。
至于ejb，包括现在相当简化了的ejb3，由于笔者所知甚浅，不便多述。望高手指点。
每一个程序员，不要想偷懒，努力实践解耦自己的代码。
每一个开发商，不要太急功近利，要努力提炼产品的类库，尽力与其他产商互通互联。
每一个系统管理员、cio和企业领导更要谨记：高耦合的系统不能要、无类库封装的系统不能要，无测试的系统不能要、无类库文档的系统不能要。
这样才可以杜绝国内急功近利的低水平软件横行市场，早日迎来中国软件的组件化时代，形成健康、有秩、高效的软件行业。
新闻热点
疑难解答
