|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-08
技术与方案其实也没有什么明显的界限，产品设计、领域建模我认为也是技术。有规范的可以称之为技术，没有规范自成体系的可以称之为方案。方案通常是与产品相联系的。我所理解的层次关系如下：
技术 -> 业务 -> 产品 -> 解决方案 这些大厂对于保护自己私有的核心技术是非常谨慎的。EJB 象大锅饭，私有技术象小灶，小灶烧出来的饭一般比大锅饭要好吃的。盲目跟风的公司是不可能形成自己的核心技术的。 to lithium： 家家有本难念的经。我在这里只是为了表达自己长期以来的一种观点。不是为了学 xx 大师预测未来。BEA 自己的问题不在我的讨论范围之内。 |
| 返回顶楼 | |
|
发表时间：2004-09-08
要达到同样的性能，单CPU的成本，要高于两个慢一点的低成本的CPU的总成本。
要达到同样的性能，单服务器的成本，要高于N台慢一点的服务器的总成本。 所以，如果一个应用的性能需求和数据量太大时，用一台服务器来实现，是不经济的，用多台便宜一点的服务器来实现，是更加节约成本的做法。 IBM、SUN不是傻子，他们想多赚钱，但是那些超大型的公司也不是傻子，他们更想节约成本。 分布式不是骗人的东西，只是不适用于很多低端用户。骗那些只花十几万、几十万做项目的国内公司用EJB的人，才是可耻的。 |
| 返回顶楼 | |
|
发表时间：2004-09-08
jeffrey_he 写道 我一直对EJB的使用感到迷惑，以前也在这里发过帖子询问有关EJB、分布式和集群的问题。
我曾经的领导是EJB的支持者，坚持要在项目中采用EJB，我写了一长篇的报告论述当前项目不需要EJB技术。领导们觉得有道理，但依然不能放弃EJB，因为这在产品中是个卖点（显得产品比较上档次），对此我真是无语了。我想这都是那些EJB的鼓吹者造成的恶果。 我当时总结了一下EJB的应用场合：服务器在物理位置的分布上不在同一区域内，这时可以考虑使用EJB。 例如以下的情况： 1.国际性的大公司，分公司遍布全球，分公司需要同总公司的服务器进行交互。 2.出于职权与安全原因，有的服务器必须由专门的部门或人来管理。 当时领导说访问量大，我们需要分布式，一个WEB SERVER和N个EJB SERVER（据说很流行？）。这样真能解决问题么？请求还是那么多，不管EJB SERVER有多少台，WEB SERVER同它们之间的交互依然那么多，我不明白这样的架构能解决什么问题。并且这里产生一个问题，通过服务器之间的交互我们在程序效率上的损失很大，真是得不偿失。 很多门户网站在ASP、PHP年代怎么解决访问量大的问题？用集群啊。准确的说是负载均衡集群（集群分三种，有一种科学集群是采用分布式计算的。）负载均衡集群需要EJB吗？不需要。 我怀疑自己一辈子都可能不会做需要使用EJB技术的项目，但现在却不得不去了解EJB。那些EJB的鼓吹者（大多都是一些学术派的或者是以公司利益为出发点的人），他们并不会赔偿我为此付出的时间，我恨！ 简单。在顶上搞一个session facade，底下该咋做还咋做。 |
| 返回顶楼 | |
|
发表时间：2004-09-08
庄表伟 写道 要达到同样的性能，单CPU的成本，要高于两个慢一点的低成本的CPU的总成本。
要达到同样的性能，单服务器的成本，要高于N台慢一点的服务器的总成本。 所以，如果一个应用的性能需求和数据量太大时，用一台服务器来实现，是不经济的，用多台便宜一点的服务器来实现，是更加节约成本的做法。 IBM、SUN不是傻子，他们想多赚钱，但是那些超大型的公司也不是傻子，他们更想节约成本。 分布式不是骗人的东西，只是不适用于很多低端用户。骗那些只花十几万、几十万做项目的国内公司用EJB的人，才是可耻的。 集群不是做这个事情的么？跟EJB的分布式也没啥关系啊。 |
| 返回顶楼 | |
|
发表时间：2004-09-08
分布不是骗人的，但分布有很多种嘛。比如说应用服务器完全撑得住，但数据库撑不住了，那么需要分布的就是数据库服务器。这么一细想呢，恐怕适用EJB那种分布的场景又得打个折扣。
|
| 返回顶楼 | |
|
发表时间：2004-09-08
jeffrey_he 写道 集群不是做这个事情的么？跟EJB的分布式也没啥关系啊。
应该说集群也是做这个事情的。 而且据说在Rod Johnson的书里，就比较推崇用集群来代替分布式对象。 但是我认为，针对特定的事务，分布式对象、分布式计算有其不可替代的优势，但是他应该是类似于Web Services或者某种P2P协作计算这样的形式。而不是EJB现在这样的实现形式。 |
| 返回顶楼 | |
|
发表时间：2004-09-08
gigix 写道 简单。在顶上搞一个session facade，底下该咋做还咋做。
呵呵，当时我也这么想，不是要EJB么，我就弄一个SLSB也是EJB啊。后来正巧看了Spring，可以把本地调用和远程调用屏蔽掉，现在我只管写本地的实现，以后要扩展EJB再去扩吧。 |
| 返回顶楼 | |
|
发表时间：2004-09-08
gigix 写道 BEA难过又不是从今天开始的。但是如果J2EE朝着现在这种更开放、更组件化、更轻量级的方向发展，BEA或许又有一次新的机会。
不明白，大家都用Spring、struts、hibernate等，bea有什么机会？也开发类似的framework？ |
| 返回顶楼 | |
|
发表时间：2004-09-08
本来就是这样的嘛。EJB——在最好的情况下——只应该是一种可选的实现策略，我们要做的是一个OO的应用，而不是“EJB应用”，所以应该让EJB融入我们的架构，而不是为了EJB做架构。session facade确实是满不错的一个模式，我们现在不也在用Hessian做远程接口吗。
|
| 返回顶楼 | |
|
发表时间：2004-09-08
gigix 写道 分布不是骗人的，但分布有很多种嘛。比如说应用服务器完全撑得住，但数据库撑不住了，那么需要分布的就是数据库服务器。这么一细想呢，恐怕适用EJB那种分布的场景又得打个折扣。
有N种分布的需求都是实实在在的。 但是EJB一出来，就是一口能吃个天一样的，号称能够做什么什么...... 事实上呢，我们还是应该确切的区分EJB的使用范围 不要骗自己、不要骗人、不要被别人骗了 就是这样。 |
| 返回顶楼 | |
