|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-09
dlee 写道 呵呵，我这个帖子的主要目的绝对不是为了清算 EJB 或者打破某些人的饭碗。大家注意了前半句，没有注意后半句。我的主要目的是希望大家能够把注意力多转向 OLAP、数据仓库、数据挖掘这些目前已经非常热门的新兴开发领域。在这些领域里付出的学习绝对是物有所值的，在我看来比花费大量时间去学习分布式开发回报要大的多。
不知道这里提到的"OLAP，数据仓库，数据挖掘"和偶接触到的是不是一码事。 俺们这里去年上了一套，主要是DBA们在搞这件事情。其步骤无外乎将业务系统的数据表导来导去，不断拆分，目的是要将这些数据规范化，转换成一系列的“星型表”(如果业务系统设计得规范，这步会很简单)。然后，就象使用报表设计工具一样，将业务规则塞进去，整出一系列报表来。使用者通过工具的界面可以对报表进行各种“数据钻取”动作(在我看来，那只是不同粒度的数据统计而已)。在这些成熟的工具面前，"OLAP，数据仓库，数据挖掘"似乎更偏重DBA，而不怎么需要程序人员的参与。 dlee提出希望大家关注，但作为开发系统的程序员，除了在设计之初多下一些功夫在数据设计上之外，如何切入这些环节呢？莫非是建议大家来做这样的OLAP系统？ |
| 返回顶楼 | |
|
发表时间：2004-09-09
jackyz 写道 dlee提出希望大家关注，但作为开发系统的程序员，除了在设计之初多下一些功夫在数据设计上之外，如何切入这些环节呢？莫非是建议大家来做这样的OLAP系统？
这样的 OLAP 系统我们已经做过了。我们的经验是，如果能够做好，客户对于应用系统的满意度会有非常大的提高。因此我才会说客户真正关心的其实并不是分布式，而是对于数据更有效的抽取和利用。 至于数据挖掘，那是另外一个更深的开发领域。我们暂时还不准备涉及这个领域。 |
| 返回顶楼 | |
|
发表时间：2004-09-09
dlee 写道 EJB 的模型（model）分成两部分：一个组件模型和一个基于 RMI 的远程访问模型（或者叫分布式模型）。
如果 EJB 能够把这两个模型分开，而不是象现在这样死死地绑在一起，EJB 将变得更好。实际上这个远程访问模型我们很多时候其实不需要（可能现在绝大多数 EJB 开发者都是在使用 local 接口了），或者我们需要的并不是基于 RMI，而是基于 Web Service 的远程访问模型。 我们来观察 EJB 3.0 如何解决好这个问题。Let's wait and see. 会话bean和实体bean本身也是两个概念，所以一开口就EJB概括而论也是不客观得。无状态会话bean有其优点，CMP也起码提出了一种不错得模型（不要用2004年得观点去判断2000年得技术），依靠JB得开发部署能力，起码在容器服务和分布式上让组件得思想深入人心，就好象C++一样，现在看来有一些其OO观点是并不合适得，但是C++在OO推广上得作用不可小视。据说EJB得规范在2。0得时候是想走轻量级得路子，但不知道为什么没有走下去，所以闹了个什么本地接口出来，这也只是权宜之计。EJB是很重得东西，最重得是因为它是规范，不是一个人安心得按着自己得心得体会设计出来得一个ORM，这个ORM可以设计得很完善同时一个标准得东西步子不可能和个人或者说三方框架比。 最后，我不赞同“EJB 完全引错了路”---因为这句话分量太重了。 |
| 返回顶楼 | |
|
发表时间：2004-09-09
to MyJavaRoad：
你完全没有看懂你引用的这段话的意思，你的回复同样与引用的这段话几乎没有任何关系。可以说你的反驳完全是打偏了，有点象美国在奥运会上打脱靶的那位老兄。 你引用的这段话实际上不是我的观点，而是完全转述 Rod Johnson 的观点。即使是 Session Bean，难道就没有在使用 remote 接口？所以 Rod Johnson 说 EJB 把两个模型绑的很死可以说是证据确凿，不容质辩。至于 local 借口，那只不过是对这个不完善设计的一次很小的改良而已（注：这句话同样是 Rod Johnson 的观点）。 |
| 返回顶楼 | |
|
发表时间：2004-09-09
admire
开发一个这样的系统，挑战不可谓不小。 不过，这一领域已有商业产品的成熟度已经非常高，如 MicroStrategy，Bussiness Objects， M$ 的 ReportingServices 也似乎相当不错。俺们的 DBA 当时就此做了系统研究，最后选型 MicroStrategy 。此外，OpenSource 领域 OLAP 的东西也已经出现了不少。 个人认为比起 OLAP 这个让人疑惑的名字，Reporting Services 似乎要更现实一些，我们这里的大部分情况下，只是拿来来做比较灵活的(可以钻取的，或者说粒度分级的) Report 而已。 甚至偶之前的一个同事自己还做了一套控件，如果要自己动手的，不妨关注一下。 |
| 返回顶楼 | |
|
发表时间：2004-09-09
to jackyz：
OLAP 做起来难度要小一些，小公司是完全有能力做好的。 OLAP 的展示是非常重要的方面，我们现在可以做到在 Web 页面上定义所有的分析配置。然后马上根据保存的分析配置生成图表（报表、柱状图、饼图、折线图），直接在 Web 页面上进行钻入钻出切片汇总。这一点比那些需要专门安装客户端软件的产品具有一定的优势。 另外单独的 OLAP 产品（实现通用的 Cube 操作，提供一些外围的定义和展示功能）竞争力不是很大，最好能与行业解决方案集成起来，作为行业解决方案的一部分来做。 Report Server 我们也有的。其实 Report Server 就是一种最典型的 OLAP 应用。 |
| 返回顶楼 | |
|
发表时间：2004-09-09
同意dlee单独的 OLAP 产品竞争力不是很大的观点,不知大家认为单独那种产品在国内较有竞争力:
portal 工作流 中间件 eai 建模工具 应用平台架构 开发管理工具 ... |
| 返回顶楼 | |
|
发表时间：2004-09-11
dlee 写道 EJB 规范承诺道，EJB 将使开发企业应用变得更加简单。这个承诺做到了吗？很遗憾，没有。而且 EJB 把分布式开发（注意，不是 TPMoniter，我要是不注明，某位兄台又要发火了）抬高到了一个不恰当的地位，使很多人对分布式开发趋之若鹜，误以为分布式开发就是企业应用这只皇冠上的明珠。有些人一提到企业应用，就开始高谈阔论什么分布式。这里我要指出的是：J2EE，特别是 EJB 把我们的方向完全引错了。
企业应用的核心从来都不是什么分布式，现在是而且永远都将是对数据更有效的抽取和利用。企业高层关心的永远都是数据，或者说是隐藏在庞大的数据之中的信息。 目前大多数 MIS 系统的一个最大的问题是面向的用户群层次太低，基本上就是面向底层的操作人员。所生成的数据过于琐碎，以至于对辅助企业高层制订决策几乎没有任何帮助。目前企业界对于普通 MIS 系统的需求即将呈现饱和状态，仅仅在办公自动化一类的传统 MIS 系统中已经几乎无法再玩什么花头。现在已经有很多公司把精力转向 OLAP、数据仓库、数据挖掘等领域，将来会有越来越多的公司把精力投向这些领域的。 那么这些大厂极力推崇 EJB 居心何在？ 鼓励所有的人把所有的应用都做成分布式。你不会脑子进水非要在一台服务器上做什么分布式吧？做分布式应用当然至少要两台服务器了。 分布式意味着什么？更多的服务器，更高的性能要求，更强的硬件。想想 Sun 和 IBM 是做什么的你就会明白他们为什么一定要让你把应用做成分布式。 这件皇帝身上的子虚乌有的新衣直到有一天有个叫做 Rod Johnson 的家伙喊了一声： 其实大多数情况下我们并不需要做分布式应用 才终于被大多数人看穿。 难道我们单独用 Spring 就做不好 OLAP 吗？ dear dlee. 這次我就不太同意您的論點了 OLAP, DataMining, Report 等等的企業應用 這和 EJB 應該沒有什麼關係 也和分散式系統也沒有什麼關係 當然 是不是用 SpringFramework 或等等技術 都沒有關係 雖然 老闆級看得是企業應用方面 而工程師要關心的是技術發展 如果你是工程師或資訊主管 是不是使用 EJB 就變得有關係了 當然 我們可以回到當年寫 COBOL 的系統來處理雜亂的資料 能不能產生出來各式各樣的企業應用呢 可能簡單更直覺的 4GL 畫面更會讓 key-in 人員覺得方便 為什麼大廠們要推廣 EJB 除了銷售 application server 之外 最重要的希望 產品元件化 之後 可以輕易地在不同廠商的平台上面執行 另外 是要減低工程師的開發技術, ( 然而, 我覺得這方面需要加強 ) 不過開發 EJB vs 使用 Hibernate 或其他等等的 OR-Mapping 技術 我覺得 EJB 的確有他的好處 甚至來說, 當該軟體公司都是一群笨蛋 J2EE spec 所定義的人員開發及部署模式 就明確規定出所有人該負責的事情 所以我認為大廠真正在做的是推廣一各工作平台 ( Platform ) 我不知道你們是否曾經有系統整合方面的經驗 在我的思路之中, 如果能夠採用共同的開發技術 對於整合方面, 是一件很快樂的事情 能不能使用 Spring 開發 OLAP... 如果開發出來的遵循正在制定的 jOLAP. 我想我會支持她的... 如果直接使用 J2EE 或許 未來會有相關的 EJB.. 這樣, 就可以簡化這方面的工作... 淺見.. 多包涵 |
| 返回顶楼 | |
|
发表时间：2004-09-11
jini 写道 為什麼大廠們要推廣 EJB
除了銷售 application server 之外 最重要的希望 產品元件化 之後 可以輕易地在不同廠商的平台上面執行 按照 Rod Johnson 的观点（注意，我这样说可以避免很多口水战，因为没有人认为我是专家，但是可能有不少人承认 Rod Johnson 确实是个专家），这正是 EJB 做的最失败的一个地方。这种可移植性的承诺实际上从来没有实现过，只存在于 EJB 规范中，所以到目前为止也只是一种愿景（expectation）。 详情请看 without EJB 第 5 章：EJB, Five Years On 以下是书中的原文： 引用 The Component Market That Didn’t Eventuate
One disappointment of EJB is its failure to generate a market for third-party components; one of the major hopes it promised. (Remember that the EJB specification envisaged beans provided by various vendors being “assembled” to form applications.) This component market hasn’t eventuated, and it’s questionable whether it ever will. The problem is partly the EJB model (with its portability shortcomings and deployment complexity); but, far more important, the fact that enterprise components are too complex and have too many dependencies to be shrink-wrapped. The relatively few supposedly reusable third-party EJB-based “components” I’ve seen in practice have had extensive dependencies—for example, on an elaborate database schema and proprietary database features. Most have depended on proprietary features of a particular J2EE application server. Such dependencies make a J2EE component market problematic. Successful markets have developed in the past for components such as ActiveX controls and (to a lesser extent) JavaBeans. However, the problems addressed by such components are much simpler than those of enterprise applications. 根据我对 WebLogic、WebSphere、JBoss 这 3 种主流的 J2EE 应用服务器的了解，对于那些复杂的企业级组件，在这 3 种应用服务器之间要做到完全的可移植性是相当困难的（XDoclet 当然可以起到一定的帮助，但是无法从根本上解决好这个问题），因为很多时候你很难拒绝那些应用服务器私有的然而强大特性的诱惑，更不用说你的组件可能还需要依赖某种特定的数据库设计了。 jini 写道 雖然 老闆級看得是企業應用方面
而工程師要關心的是技術發展 如果你是工程師或資訊主管 是不是使用 EJB 就變得有關係了 我觉得你确实是没有关心最近的技术发展。而且我认为工程师才应该更多地以商人的思路来思考问题，因为说到底你也不过是一个想要把技术卖出去的“技术商人”而已。如果你的技术卖不掉，你永远也无法成为一个可以为公司创造价值的人。 |
| 返回顶楼 | |
|
发表时间：2004-09-11
jini 写道 此外, 我強調的是, 當你們公司都是高手, 擁有自己的 Framework
可以完成各式各樣的專案, 甚至各式各樣的產品 可以完全不要使用 ejb, 但是並非所有公司都擁有你這樣的人才 jini 同学，你这里的逻辑有些奇怪。学习 EJB 的成本肯定在学习 Spring+Hibernate 之上。我到是觉得初学者学习这些东西更容易上手，成本更低廉一些。曹晓钢以及这里很多默默奉献的朋友们辛苦翻译出来的 Hibernate 和 Spring 中文文档是为了什么？ 我也并没有维护什么 without EJB。我只是说分布式并不是我们最应该关注的问题，因为绝大多数场合下它并不是客户真正关心的问题。 过一段时间我还会把 Rod Johnson 其它的一些观点透露出来，在某些人看来这些可都是些惊世骇俗的有害观点。 |
| 返回顶楼 | |
