大道至简,简单就是美.

其实相对于实际的使用性来说,用什么技术其实不重要.你想想,为什么要用技术?还不是能解决实际问题,让你我的生活更美好,或者能做原来不能做额工作?你我又不是贩卖技术的所谓专家或者是学者.干吗抱着某某技术一起Sink?如果用一个冬冬有那么多的烦恼,不用也罢.

反过来想想,最出名的科学家还不是解决的什么实际问题才出名的,管你是机器证明(吴文俊)的还是种水稻的(袁隆平),都得了国家的最高奖,就档次来说,搞数学的总比务农的泥腿子要高多了吧,对社会来说,有什么差别(有差别也是袁的社会价值高的多)?学术界尚且如此,更何况商业世界!

另外,对一个大系统来说,没有简单规律,如果真的什么烦恼都没有了,虾米公司都能干,要那么多人干什么,中小型技术公司还有什么存在的必要吧?

另外,missxkl你的困惑不孤独,许多Fortune 500公司都是采用TopLink或者Hibernate作为数据中间层的,这点你可以在<<J2EE Core Pattern>>的作者(SUN公司的)的访谈(www.theserverside.com)当中他也承认的.

相信自己吧,有的时候存在并不合理,但是肯定有其合理性.

总之,对复杂的事情没有简单规则.但是对于特别(particular)的问题却有存在简单解,但是有时候需要的是耐心和时间.

其实想想怎样用JDBC,SP,SQLJ的发出更好的程序也许更有意义!我就在考虑是否有或者可以为MS SQL server或者Interbase写一个SQLJ的Precompiler.
或者,发明一套基本的Store Procedure的框架,再做若干的Translators,可以be based on hibernate.反正,这样的想法其实更有意义.

BOSS系统（Business＆OperationSupportSystem，业务运营支撑系统）
新一代的ＢＳＳ／ＯＳＳ系统最关键的特性是要有高度的系统集成化，把各式各样的分离业务系统融合起来、串联起来，形成统一的整体，实现内部业务流程和外部业务流程的顺畅通达和统一协调，从而实现企业管理水平、运营效率、服务能力等方面的整体提升。

从集成技术上分析，ＢＯＳＳ可以分为系统平台、应用集成平台、业务框架／平台和应用解决方案四层。其中，最关键的是应用集成平台和各应用功能模块的开发。

从系统构成上来看，ＢＳＳ／ＯＳＳ系统一般包括以下一些部分：

计费及结算系统。狭义的计费系统是指处理计费数据采集和批价两个过程的系统。结算系统是电信企业间的行为，它包括两种情况： 一种称为漫游结算，另一种称为互联结算。

营业、账务系统。营业系统通常完成的是受理和处理用户的业务请求，而账务系统是将用户使用电信网络的情况汇总形成账单。

客户服务系统。随着业务的发展，客户服务系统有了全新的定义和功能。 客户服务系统一方面能保证为客户提供快速方便的服务；另一方面保证在未来新业务开放的情况下，系统能及时提供相应的功能。

决策支持系统。决策支持系统的主要任务是通过动态、有选择性地采集和更新数据源的有效信息及企业外部相关信息，进行智能化地分析、处理、预测、模拟等，最终向各级决策管理者或专业人员提供及时、科学、有效的分析报告，做好信息、智力支持工作。

我觉得吧,很多时候我们过多考虑了技术问题,缺忽略的如何解决实际问题是最重要的,个人认为J2EE的发展还是初级阶段,很多时候不完善

目前很多开发基于WEB-BASED的系统,很多东西更复杂一些
一, 一个良好的客户端东西,例如像STRUTS这种的东西,但是实际上STRUTS也使用不方便,其实DISPLYTAG这种发展模式应该更值得学习
二,就是和DB打交道关系,如何真真的使用和DB打交道.例如嵌套查询,子查询,多表联合查询等等等等,其实这种功能在WEB-BASED的系统中更重要一点
三也就是如何使各个模块很容易整合起来,例如一个系统,订单系统独立设计,用户权限也是独立设计等等,各个模块相互联系等等

java 对付企业的各种灵活多变的软件需求还是很不错的，但是对于大企业的核心数据库应用，还是力不从心！

大企业的核心数据库并发量非常大，性能要求很高，一般运行在专有的大型机上面，例如各银行的核心系统。在大机上，似乎除了 cobol + cics，别无选择吧？看ibm 的介绍是 EJB 再与 cisc 连结，完成与传统系统的连结，这样一来，java 完全成了一个 web 服务器。商业逻辑组件仍然在大机上。

刚刚看到一篇文章

Simple Java

http://www.theserverside.com/resources/article.jsp?l=SimplerJava

不要因为自己不会开赛车，就说法拉里的 F1 赛车不好，
如果EJB性能很差，那 SUN 的那些工程师不都是白痴吗？？？？

The serverside 最近又在讨论了

http://www.theserverside.com/home/thread.jsp?thread_id=22481
其实和我们一样,国外对于J2EE有很多不同的看法

> 因为有开源代码的那些Web高手反对，他们以所谓轻量级的思?> 引导一批人向和EJB导向相反的方向走下去。
>
> 但是实践中，以一两个开发高手为主开源开发模式并不适合工
> 倘砑?>
> 这是两种方向，所以有人说Java的危险失败是可能来自于Java

回复一下banq,有些开发来看软件工程的一些东西也许在目前看来不适合,因为现在的开发体系更快,迅速,所以有Angle方法的提出,也许这也是一种软件行业的进步,那么随着进步,必然某些人认为轻量级思想更容易实现Angle方法.

那么提出这些问题的人都是白痴嘛?Fortune 500大公司搞开发的人都是白痴嘛?干吗要用TopLink和Hibernate?

SUN工程师不都是白痴,至少James Gosling不是,但是Spec掺杂了太多的非技术因素,too much politics.

让数码赫在上海或者北京的道路交通情况下全速开开F1试试看(是有其他车的情况下,不是像Monte Carlo周末封路),不车毁人亡才怪!更何况CMP还不算是F1,F1有速度,那CMP有虾米?

现实中有好多东西不光是靠喊两句口号就能解决的,对复杂问题不总是有简单的解决方案.

=======================================================
不要因为自己不会开赛车，就说法拉里的 F1 赛车不好，
如果EJB性能很差，那 SUN 的那些工程师不都是白痴吗？？？？
=======================================================

去这里看看http://www.softwarereality.com/programming/ejb/index.jsp
"EJB's 101 Damnations"
超级优秀的EJB问题,尤其是conceptual问题,太值得一读了.

=================================================
The serverside 最近又在讨论了

http://www.theserverside.com/home/thread.jsp?thread_id=22481
其实和我们一样,国外对于J2EE有很多不同的看法

好文,里面的建议真是值得SUN好好看看.

也许现在重新设计一下J2EE也是不错的选择.

==============================================
The serverside 最近又在讨论了

http://www.theserverside.com/home/thread.jsp?thread_id=22481
其实和我们一样,国外对于J2EE有很多不同的看法

不要因为自己不会开赛车，就说法拉里的 F1 赛车不好，
如果EJB性能很差，那 SUN 的那些工程师不都是白痴吗？？？？

首先你要明白 EJB 规范是几个公司一起定制出来的，这种制定就像 3G 标准的制定一样，有利益的权衡在里面的，每个公司都希望让自己的东西成为标准，而不希望让自己成为标准的跟从者，在这种情况下定出来的东东，从技术上来看，未必是好东东，最少我认为 OpenEJB 的 IntraVM设计思想就比 EJB 2.0 的 local EJB 好很多。

其次，标准的实现与规范是两回事，能定规范，并不代表能做好的实现。SUN 在软件方面其实没有什么优势~~

电信上的项目最好还是用Tuxedo了，其实Tuxedo的体系结构相当的简捷，又没有J2EE那么多的理论和概念，在两端的开发上又非常容易，兄弟我最近就在慢慢研究它了。好象编程的接口仅有二三十个而已，给我的感觉Tuxedo真是大巧不工啊！怪不得那么多高性能的系统采用呢。

tuxedo给你感觉那么好其实有一个很大的原因，呵呵，包括cics等等
因为写的是纯粹业务逻辑了
如果谁和我说，写ejb只需要写业务逻辑，我看也是很顺心的事情
但是一般写了ejb了，就有人来说，是不是能把权限也管了，和mvc什么的结合，前台都做了，什么什么的
但是写tuxedo、corba的，就只要关心业务，再关心业务，其他什么都不管，自然是爽，呵呵～