缓存是对象的缓存，中间件是什么？本质上就是对象拿到中间来了，中间是什么东西？是内存，是缓存，所以EJB本质是一种分布式集群 分布式事务的缓存，现在JBoss开始走向细分，你研究一下JBossCache就知道对象缓存多么复杂，它为不断增长的互联网大访问量计算提供了高度的可伸缩性。所谓可伸缩性，就是你可以通过增长服务器来提供系统运算能力。Weblogic/Websphere10个CPU的运算能力可以看看这个网址：

http://dev2dev.bea.com/blog/estahl/archive/2005/09/analysis_of_spe_1.html

如果你不使用缓存，不将计算拿到中间服务器上运行，全部负荷集中在数据库服务器端，这是一种老式集中式的主机系统，面对Internet巨大的互动访问，你只能买中型机 大型机，可是你没看到这个硬件市场在萎缩吗？

我看到一个Oracle国内高手DBA由于长期面对数据库性能调试，研究出从linux线程跟踪这样技巧，这种技巧能够被推广吗？难道软件科研是这种无法被普及的高手级别的科研吗？国人的聪明才智耗费在这种错误方向研究上，恐怕我们要跳出科研之外看看吧？

在J2EE中性能调试非常方便，可以跟踪到具体代码行，有大量成熟产品和开源产品如Optimizeit，如果我们把系统的计算负载集中在Java中间件上，那么DBA不是轻松多了吗？鸡蛋放在一个篮子里的决策为什么总是在软件人员当中发生，更应该从技术之外为自己找些原因。

嘿嘿~~~偶可不是故意用这种语气……

另外，对于商业项目而言，企业最重视的是数据。一个公司可能每三五年换个应用系统，比如JAVA，如果2015年JAVA还象今天这么流行那就太恐怖了。可是数据库的平均寿命要远远超过应用系统。所以这种从数据库开始设计的设计过程恐怕很长时间会保留下去。

这个现象的最本质原因是当前计算机的架构决定的。只要计算机硬件架构不出革命性变化，尤其是存储体系，关系数据库在应用系统中的地位就很难动摇。从这个意义上看，缓存的确是一种不得已而为之的work-around，而不是根本的设计出发点。可能改变这种情况的一个新技术是永久化RAM，也就是说调电不失数据的RAM。试想，要是整个关系数据库都搬到内存里，有点象ORACLE和SQL-SERVER正在做的内存数据库那样，关系就是对象，对象就是关系，那还要吃饱了撑的整个缓存干吗？

至于分布性，历史证明，关系数据库社区对分布数据的分割融合，分布数据事务处理的理论和经验要远胜于面向对象社区。甚至，面向对象技术里的分布事务模型，本来就是来自关系数据库的。EJB3 里 彻底抛弃 ENTITY BEAN 而采取 PERSISTENCE MANAGER、OR映射架构，基本上是原来搞分布式OO起家的那伙人 被 TOPLINK/HIBERNATE搞关系数据库起家的那伙人 彻底打倒批臭并踏上一只脚的结果。 这是关系数据库严密的，基于数学的理论体系的必然优越性的体现。相比之下，面向对象体系到现在为止还在讨论一些“模式”“框架”之类没有严格定义，没有办法运算，没有数学证明的模糊概念。

GOF开篇就讲，“模式”者，经验之总结也。什么叫经验，经验就是：是感性而不是理论，是总结而不是抽象，能实践但无法推演，似是而非但不能运算。 靠经验吃饭，那叫术，靠数学做事，才是道。

一个程序员，写个SQL，DBMS能给你优化并保证和你的原查询功能等价； 写个逻辑线路，EDA能给你优化并保证与原逻辑等价；写个JAVA HASHMAP.put()，打死JVM它也不知道你是不是又泄漏listener了。

说啥？JAVA没有内存泄漏？嘿嘿。打开 PERFMON 看看你的 J2EE 程序吧。命好的，程序恰好是你自己写的，想想也就明白问题在哪了。要是你碰巧薄命，非得猜别人的程序，那就趁早准备跳槽得了。JAVA的内存泄漏，理论上是完全没有可能象C/C++那样写个Purify来找BUG的。工具最多只能告诉你那个类一大堆胖胖的对象看着讨厌象嫌疑犯，找证据还得靠程序员你自己明白程序。

老外说话(IEEE Software Magazine 主编, Ohio State Univ. 计算机系主任说的，不是我说的)，逻辑线路设计是科学，关系数据库是科学，面向对象，软件工程，那是艺术而不是科学。可别以为他是在夸面向对象和软件工程呢。

为啥？没有数学基础的东东，本来先天不良，后天又被一堆走江湖的带坏了。到了今天，想靠些“模式”“框架”从良也难。也许，只有等HASKELL来拯救芸芸众生了。

最惨不忍睹的，是有些后生，一踏入社会，就碰上歹人们挟持着本来还不错的JAVA在江湖上横行霸道，于是就想：人生当如此啊。从此万劫不复，其不知JAVA帮的帮主和帮中长老们，自己压根就是披着狼皮的LISP程序员。

所以啊，有些同学兄台一开口说“设计模式”，“应用框架”，“依赖注射”。。。我就只好嘿嘿笑。

初中生要跟你讨论人生苦短什么的，就是这个感觉。

还有那个chinapay.com号称支付之王，经常转到他那里付账时，查无此页，你说这不增加用户负担吗？不知道钱是否被你划走，上次我在春秋航空网上购票，碰到几次，从四川打长途到上海，电话才解决问题，真是垃圾啊,chinapay.com是以前一帮搞传统软件系统出身依据上海政府的庇护搞的，垄断思维下没有革新。

2.再谈谈银行账户查询，也是和话费查询一样，使用缓存可以防患于未然，谈到海量查询，莫过于google，你不要告诉我他们使用了世界上最大巨型机，安装了性能机器优化的Oracle！

所以，缓存为什么使用比较难，因为它不是纯数学，没有一个固定的公式，需要根据业务特殊情况决定策略，这种灵活的方式遭遇僵硬思维程序员时，就被弃之不用，然后象鸵鸟将头向地下钻一下，只能向软件下层操作系统甚至硬件求援钻研了。

关于lin的问题，Lin的谈话主要表现在不信任OO，这个已经不用我来批驳，历史上老外应该有很多争论，我个人是一向设计和性能两手抓，国内还有比我在设计上更极端的高人在，也会偶尔来这个论坛看看，我想如果他们看到lin想法，也许会有兴趣讨论一下。

这就是典型的科学极端主义，抢了话语权，就用科学代表一切，他不知道那句话：人类一思考，上帝就发笑。

当今的科学标准和方法论只能解决过去的问题，未来的未知远不是现在科学能力所能解决，飞碟现象 中医 都说明这样问题，

我们做软件的，是和实际现实最接近的，面对的是最复杂 最灵活的问题，需要我们采取更加灵活的策略来对待，同样的现象反应在金融经济领域，美国人最聪明的人去搞金融经济，你的严格数学逻辑在面对金融 汇市 股票等经济问题时，是非常苍白的。当然中国人最聪明的人是搞理工，所以搞理工的国人和搞理工的老外争辩时，根本无需怕它，那是他们的二等兵。

目前Java软件领域OO发展日新月异，框架 模式不断翻层出新，一些跟不上发展的人面对疾驰而去的火车背影，只能靠过嘴隐了。

极端情况：'基本无重复操作的海量查询' google是代表，它不知道我们查google时是会是什么内容。

走域模型、框架、缓存方向必须走对，完全用对象化思路去分析 设计考虑，业务非常清晰，近期我在重新设计Jivejdon3，以后开源出来相信你会看到，正因为基本业务清晰，性能不用担心，我会在JiveJdon3中塞入很多功能，互相不会纠缠在一起。

基金买卖不是实时的，是委托，第二天才人工处理，典型的信息系统，网址这里：https://etrade.efunds.com.cn/etrading/trade/index.jsp

当我们面对数据都在内存里时，而且内存足够大时，我们就开始鸡生蛋和蛋生鸡的问题争论，Lin认为内存里的数据是从数据库来的，因此说明数据库是其父亲；我倒认为缓存是其父亲，缓存从以前我们的几十K小缓存发展到现在足够大，可以把数据库都吃进来了。

有一点必须注意的是：缓存的数据不是关系数据库的数据，关系数据库的数据是一种关系性质的数据，而缓存是对象缓存，是带有对象性质和关系的数据，用对象思路解决数据关系，这是O/RMapping Hibernate/Toplink包括实体Bean（EJB3还叫实体Bean CMP）之类的主要设计思路，可惜Lin提了这两个名词，看出他并没有理解他们的真谛，因为有数据库这个包袱在他思维里，当然也可能有和我较劲的思维。

如果你经常关心软件业发展，Oracle重点放在发展中间件J2EE这块上你不可能不知道。

现存的以数据库为核心的应用很多，不是因为这些系统的设计者都是老脑筋，而是没有更优的方案。要不然banq的咨询业能打入电信和银行领域了

老板，首先声明啊，说得兴起，鸡鸡鸭鸭往外讲，不是针对哪个个人，纯粹是为了这么说着过瘾有杀伤力。本来，修辞是为了在辩论中打击别人。我这人正好相反，放狠话较劲完全是为了修辞，说着好玩，当不得真。呵呵。技术讨论就好比小孩玩打仗。玩完还是要一起玩撒尿和泥的。

首先，缓存恰恰就有很多数学模型。缓存在计算机科学里大概是最容易搞课题的领域了。这方面的学术文章多如牛毛。学生时代，在下曾对体系架构痴迷过，关于缓存的东西读了不少也做了一些。缓存方面的研究别说经典的基于统计的模型，花里胡哨的连PERCEPTRON都有人往上套。要说中间件，OO缓存，可千万别以为WEBLOGIC, WEBSPHERE, ORACLE APP SERVER的缓存是拍拍脑袋，套什么“模式”写出来的。在美国专利局的网站上查查这几家公司的专利，关于缓存的可不少啊～～

第二，老板的论点好像是“系统设计应该围绕OO，而不应该基于RDBMS”。本来这个论点稍加适用范围（象任何命题一样），也有一定道理。不过老板的论据有点不上路。尤其那个ORACLE的。

地球人都知道，ORACLE 自打通过收购弥补了中间件的缺陷以后，几年来的屡次收购，peoplesoft, siebel, 还有其他一把半大不小的公司，都是做应用的，而最近的一次收购做的是内存数据库，哪里有一笔买卖是做中间件？ ORACLE的应用服务器10g，如果你花时间仔细看看ORACLE 10G的文档，就会发现数据库的痕迹无处不在，无孔不入，无缝不钻。比如，从PL/SQL直接导出WEB SERVICE，有趣吧？持久化层直接到服务层，没有中间件啊. 并且从财务方面看，ORACLE的主要收入仍然来自数据库，ORACLE的中间件和ORACLE自己原来的应用（除去PEOPLESOFT, JDEDWARDS, SIEBEL等遗留产品外。指ORACLE FORM之类的东东），基本上是套送，买一送一的。

要是非说 ORACLE 的方向是渐渐脱离单一的数据库产品线，追求产品多样化，倒也无可厚非。不过 LARRY 和 PHILLIPS 两个当家人自己都说了，今后的发展方向是商业应用，可不是J2EE。可别告诉我 PEOPLESOFT, SIEBEL，JDEDWARDS 的商业应用是基于J2EE的。要不我又得费劲一一解释他们的架构有COBOL, 有C/C++, 就是没有半个EJB，仅有的一点JAVA是用来做表现层的。

并且，ORACLE的商业发展战略，和你的论点好像没有直接关系吧？
BEA 还号称JAVA中间件已经过气了呢，人家已经继WEBLOGIC之后推出了AQUALOGIC。IBM 还要把中间件通通开源拉到，转收咨询服务费呢。这两家在J2EE领域可比ORACLE鲁棒多了。你咋办？再写篇“中间件时代的终结”？

还有那个关于美国什么人学金融经济什么的例子。美国那个经济学和中国大学里教的那个文科“数学5类”的经济学可不是一回事。随便GOOGLE个经济学的文献看看，大概不会比缓存的数学模型简单。清华北大中科大多少物理博士电机博士都在华尔街搞金融数学模型，在下的同门里就有人成天用神经网络模型给保险公司做预测的。从他们的收入看，这个数学模型不但不苍白，而且还很滋润，容光焕发的。呵呵。

第三，关于“模式”啊，“框架”啊啥的。这些东西，打个比方，就好像“射雕”的电视剧。演员换来缓去，剧本还是那一个。AOP至少十年前已经有人在搞搞。IOC更是好笑，用过C/C++框架的（比如 MOTIF, MFC，ATL）看到这个IOC大概都奇怪这个控制反转有什么新鲜。所谓框架，当然控制要反转，要不那不叫框架，叫API。还好Martin Fowler也看不下去了，给换了个名字叫依赖注射，要不还继续混淆视听，贻笑大方呢。

这些东西，属于“效率工具”的范畴，不是说它们没有，而是说它们只是个“器”，不能替代“道”。 把这些“器”层面的东东甘之如贻，对算法和数学这样的“道”层面的精华嗤之以鼻，这就叫“买椟还珠”，“一叶障目，不见泰山”。

最后，关于EJB和JAVA：
ORACLE 的EJB首席大拿，MICHAEL KEITH，前TOPLINK的架构师，EJB3的SPEC专家组成员，俩礼拜前自己刚刚在科罗拉多说了，EJB3里那个ENTITY，不是个EJB的。SUN 的大拿某某，MUSTANG/DOLPHIN的设计者之一（名字忘了），也讲JAVA要是再撑 10 年他就很吃惊了。老板，赶紧准备“OO时代的终结”草稿吧。

> 当然，有些想法和Lin虽然从不同角度考虑，但是还是不谋而?
> 的。数据库搬到内存这一说，Lin认为：“要是整个关系数据?
> 都搬到内存里，有点象ORACLE和SQL-SERVER正在做的内存数据
> 饽茄叵稻褪嵌韵螅韵缶褪枪叵担腔挂员チ顺诺恼
> 缓存干吗？”
>
> 当我们面对数据都在内存里时，而且内存足够大时，我们就开
> 技ι昂偷吧Φ奈侍庹郏Lin认为内存里的数据是从数据
> 饫吹模虼怂得魇菘馐瞧涓盖祝晃业谷衔捍媸瞧涓盖祝
> 存从以前我们的几十K小缓存发展到现在足够大，可以把数据?
> 都吃进来了。
>
> 有一点必须注意的是：缓存的数据不是关系数据库的数据，关
> 凳菘獾氖菔且恢止叵敌灾实氖荩捍媸嵌韵蠡捍妫
> 带有对象性质和关系的数据，用对象思路解决数据关系，这是
> /RMapping
> Hibernate/Toplink包括实体Bean（EJB3还叫实体Bean
> CMP）之类的主要设计思路，可惜Lin提了这两个名词，看出他
> ⒚挥欣斫馑堑恼孚校蛭惺菘庹飧霭ぴ谒嘉铮
> 然也可能有和我较劲的思维。
>
> 如果你经常关心软件业发展，Oracle重点放在发展中间件J2EE
> 饪樯夏悴豢赡懿恢馈?
>