|
锁定老帖子 主题：论Spring与EJB的组件架构
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2004-09-20
raimundox 写道 帮助林星贴一下，他刚注册发不了贴：
语义和重用 我认同庄表伟的重用在业务级别价值才最大的说法。不过，我觉得技术层面和业务层面的重用都是存在的。只不过，两者的目的和标准都不同。技术层面关注的是如何保证组件的各种不同维度的特性的分离，例如持久化、事务支持等。如果我们能够分离这些特性，并用同样一种描述形式来描述某一种特性，特性的替换就成为可能，重用度也就增大了。而这里就是语义的关键了。在任何一个设计中，如果要支持不同的持久化机制，当然需要设计共同的接口，接口其实就是一种语义，当然，我们还可以用配置文件来说明，这也是一种语义，而且比接口更加的灵活。而在jsr175出来之后，我们还可以使用annotation，这个就更加方便了。这就是一种语义了，这种语义可以为人所理解，也可以为机器所理解。Raimundox提到spring是贫语义，可能的一个想法就是spring对特性的标准化仍然不够，但我倒是觉得spring在这一点上已经做的不错了，他把各种特性都组织为bean的形式。不过，因为spring是从实践开始整合的，而不像EJB是从规范开始整合的，在语义的统一上，spring做的还是不够，但这个是双方的角色决定的，而不是设计的问题。因此，我们也可以想象，当EJB3和annotation普及之后，这种情况会发生变化。 但是业务层面，更重要的重用是针对领域的。业务模式已经为此做了很多的工作，但是否足够呢？我觉得还远远不够。目前大家试图把领域方面的模型统一在MDA之下，但这个目标也是相当困难的。黑箱重用的组件是否能够一统天下呢？这个目前看来也是相当困难的。不同的领域适合于采用不同特点的模型，那么，如何划分领域？领域划分到何种程度？数据为中心、流程为中心的设计模型之间是否能够统一。这些都是业务层面需要考虑的问题。 谢谢你的赞同。 我的看法是：组件和框架是相对的。 java语言，可以说是一个广义的框架。 在java语言下，实现的J2SE，也可以认为是一种框架。 在J2SE上，实现一个EJB容器，也可以认为是一种框架。 然后可以用一组EJB，搭建一个业务框架 在业务框架的基础上，我们还可以再进一步往下分解。 关键在于，一个框架，相对于他所处的环境，他是一个组件。 而相对于他所的包容的组件来说，他是一个框架。 可重用性，不能抛开具体的层次，来谈论。只能比较：在同等的层面上，不同的设计，可重用性如何。技术的重用性，和业务逻辑的重用性，本来就不能简单比较的。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
庄，我从98年左右开始一直在从事ERP的研发工作，当时我的目标是构造一个类似于Sanfrancisco一样的框架和组件库，当然希望更深入一点。后来实现了一部分，但最终发现黑箱复用的组件库非常困难.（包括IBM的Sanfransisco)
我引用这篇贴子的目的是表示我理解的复用分为两种，白箱和黑箱，以及组件的形成过程（组件一定是从框架发展而来，经过多次白箱复用，最后成为黑箱组件） 至于黑箱复用能不能成为提高生产效率的最佳手段，我现在是持否定态度的，也就是说白箱还是最重要的手段。也就是说，真正即时可用的组件还是不多的，也是非常困难的。 我讲的框架是一个有严格定义的东西，EJB和Spring对组件业务本身来说，不能叫做框架，称他们为容器或许更好一点。组件对业务框架的依赖不再我们这里的讨论范围之内，因为这是必须的。我们现在讨论的是从Java语言本身的角度，对Java对象的限制和约束。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
robbin 写道 agilecat 写道 我的看法:
1. ejb3 是模仿spring建立的体系结构,ejb3跟spring的关系就像jdo跟hibernate的关系,老的ejb体系已经垂死,ejb3使轻量级容器有了更多选择. 2. 到了ejb3时代,有可能spring修改符合ejb3,也有可能部分中间件厂商拿spring作内核来实现ejb3. 就像hibernate和entity bean的关系一样. 3. ejb3仍然会是j2ee的核心模块,但由于spring的开放性,用户不再会对ejb3的需求付费,用户付费的核心是分布式事务. 4. 纯中间件服务器的利润会暴跌,因为许多应用不需要分布式事务,主流中间件厂商会把业务核心转向portal,eai,数据仓库等方向. 我同意这样的观点。我本来想写一个帖子阐述这样的观点的。 其实在中国，把关注力转向商业逻辑元件和商业逻辑框架，显得意义更加重大。因为中国在全球IT产业链处于底层，在技术层面上无法改变追随者的地位。就算有人能够做出来优秀的开源技术框架，但是如果英文水平不足够好的话，还是没有办法普及到全球。但是商业逻辑框架就不同，中国的软件公司和外国的软件公司站在同一起跑线，本土的公司甚至还有很多优势。我的主张就是采用流行的可靠的开源技术框架，例如Hibernate/Spring/Webwork2之类的就可以了，没有必要非在技术上较真，而把资源投入到钻研行业业务上，要做到比客户还精通业务，把业务抽象出来好的商业逻辑框架。这才是软件公司的核心竞争力。 对，同时我认为做行业元模型也不错，就像iec61970，国内也开始推了，电力eai也开始用了，因此就算mda不成功，mof也会成功。 起码数据库未来会大面积支持cwm，ETL工具已经有很多支持cwm，webSphere也有自己的j2ee mof model。钻到行业我想元模型比框架的价值大，但是也更难，竞争也更激烈. |
| 返回顶楼 | |
|
发表时间：2004-09-20
potian 写道 庄，我从98年左右开始一直在从事ERP的研发工作，当时我的目标是构造一个类似于Sanfrancisco一样的框架和组件库，当然希望更深入一点。后来实现了一部分，但最终发现黑箱复用的组件库非常困难.（包括IBM的Sanfransisco)
我引用这篇贴子的目的是表示我理解的复用分为两种，白箱和黑箱，以及组件的形成过程（组件一定是从框架发展而来，经过多次白箱复用，最后成为黑箱组件） 至于黑箱复用能不能成为提高生产效率的最佳手段，我现在是持否定态度的，也就是说白箱还是最重要的手段。也就是说，真正即时可用的组件还是不多的，也是非常困难的。 我讲的框架是一个有严格定义的东西，EJB和Spring对组件业务本身来说，不能叫做框架，称他们为容器或许更好一点。组件对业务框架的依赖不再我们这里的讨论范围之内，因为这是必须的。我们现在讨论的是从Java语言本身的角度，对Java对象的限制和约束。 黑箱的复用恐怕得依赖于行业标准（工业标准）的出台，我想只有在这样一个标准的前提下才可能产生“真正即时可用的组件”。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
potian 写道 庄，我从98年左右开始一直在从事ERP的研发工作，当时我的目标是构造一个类似于Sanfrancisco一样的框架和组件库，当然希望更深入一点。后来实现了一部分，但最终发现黑箱复用的组件库非常困难.（包括IBM的Sanfransisco)
我引用这篇贴子的目的是表示我理解的复用分为两种，白箱和黑箱，以及组件的形成过程（组件一定是从框架发展而来，经过多次白箱复用，最后成为黑箱组件） 至于黑箱复用能不能成为提高生产效率的最佳手段，我现在是持否定态度的，也就是说白箱还是最重要的手段。也就是说，真正即时可用的组件还是不多的，也是非常困难的。 我讲的框架是一个有严格定义的东西，EJB和Spring对组件业务本身来说，不能叫做框架，称他们为容器或许更好一点。组件对业务框架的依赖不再我们这里的讨论范围之内，因为这是必须的。我们现在讨论的是从Java语言本身的角度，对Java对象的限制和约束。 potian，我现在在走你的路，我的方法是MOP + 语义，希望可以得到好的结果，我相信黑箱复用还是可能，前提是约定，以及约定的可配置。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
jeffrey_he 写道 potian 写道 庄，我从98年左右开始一直在从事ERP的研发工作，当时我的目标是构造一个类似于Sanfrancisco一样的框架和组件库，当然希望更深入一点。后来实现了一部分，但最终发现黑箱复用的组件库非常困难.（包括IBM的Sanfransisco)
我引用这篇贴子的目的是表示我理解的复用分为两种，白箱和黑箱，以及组件的形成过程（组件一定是从框架发展而来，经过多次白箱复用，最后成为黑箱组件） 至于黑箱复用能不能成为提高生产效率的最佳手段，我现在是持否定态度的，也就是说白箱还是最重要的手段。也就是说，真正即时可用的组件还是不多的，也是非常困难的。 我讲的框架是一个有严格定义的东西，EJB和Spring对组件业务本身来说，不能叫做框架，称他们为容器或许更好一点。组件对业务框架的依赖不再我们这里的讨论范围之内，因为这是必须的。我们现在讨论的是从Java语言本身的角度，对Java对象的限制和约束。 黑箱的复用恐怕得依赖于行业标准（工业标准）的出台，我想只有在这样一个标准的前提下才可能产生“真正即时可用的组件”。 对，这也是我强调ejb语义的目的，没有统一的语义环境，复用就无从谈起，举一个在我以前blog里的例子： 复用它关键不是看侵入性或是别的什么，而是看重建一个复用的语义环境是否很容易，比如我说“玄牝”，很多人都不会理解，我要引证道德经，才能很好的解释，那么这个词的复用性就很差，因为语义没有标准的理解，相反，“苹果”因为语义相对通用就很好理解。 统一的语义，或者在一个统一规范机制下的语义（这个机制需要定义如何对语义进行扩展），是复用的前提。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
to:potian
组件、框架、复用的问题，我已经在脑子里想了大约半年了，一直没有写出东西来，本来是打算到你们杭州，参加聚会的时候，作为一篇论文来发表的。（如果你的打算是一个学术研讨会的话） 现在既然这个话题这么合适，我也就先说说自己的一些思路吧。 1、软件复用，一直在思考组件如何复用，其实还应该包括框架的复用。甚至可以说，没有可复用的框架，可复用的组件也无从谈起。（是可复用的框架，不是支持复用的框架） 2、复用（无论是组件还是框架）都必须在一个更大的框架范围内讨论，才会有意义，因此：泛泛而谈POJO的复用，是没有意义的。 3、软件分层，同时也是框架和复用的分层。抛开要讨论的代码或者设计所处的具体的层次，来讨论他的复用性，是没有意义的。 你说：“真正即时可用的组件还是不多的，也是非常困难的。” 而在我看来，可以理解为，越是具体层面的组件，可复用的范围就越狭窄，这是必然的，无论你是黑箱复用，还是白箱复用。 4、一个企业的竞争力就在于，在他所生产的这个软件，所处的层面上，相对于其他同类产品的可复用性如何。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
这样的话，还不如一开始就明确：ejb相比于spring,最大的优点就是规范。
如果这么说，我想这里在跟帖的绝大部分人都不会表示异议。 |
| 返回顶楼 | |
|
发表时间：2004-09-20
raimundox 写道 对，同时我认为做行业元模型也不错，就像iec61970，国内也开始推了，电力eai也开始用了，因此就算mda不成功，mof也会成功。 起码数据库未来会大面积支持cwm，ETL工具已经有很多支持cwm，webSphere也有自己的j2ee mof model。钻到行业我想元模型比框架的价值大，但是也更难，竞争也更激烈. 我觉的你有点太过强调标准了， 大家都知道统一标准会减少重复开发， 节省成本， 但不合适的标准反而会导致更大的浪费， EJB就是一个例子， 他不是由长期实际项目积累的产物， 而基本上是由committee的一帮专家坐在一起讨论出来的。 所以有不少东西在实际项目里很难用起来， 而hibernate则是community在实际项目中不断总结修改的产物， 所以推广的很好. 设计标准就象设计interface， 在你对某个method不很有把握的时侯， 最好不要加到里面去。你大可在class里先写出来， 如果感觉好的话再放到interface. 还有cwm, 我们公司是做data warehouse的， 有美东最大的database, 我也对cwm标准看过一下， 发现不少地方不太适用， 据我所知， 连SAS, 很成熟的数据分析公司， 也是按自己的标准来做的， |
| 返回顶楼 | |
|
发表时间：2004-09-20
yyanghhong 写道 raimundox 写道 对，同时我认为做行业元模型也不错，就像iec61970，国内也开始推了，电力eai也开始用了，因此就算mda不成功，mof也会成功。 起码数据库未来会大面积支持cwm，ETL工具已经有很多支持cwm，webSphere也有自己的j2ee mof model。钻到行业我想元模型比框架的价值大，但是也更难，竞争也更激烈. 我觉的你有点太过强调标准了， 大家都知道统一标准会减少重复开发， 节省成本， 但不合适的标准反而会导致更大的浪费， EJB就是一个例子， 他不是由长期实际项目积累的产物， 而基本上是由committee的一帮专家坐在一起讨论出来的。 所以有不少东西在实际项目里很难用起来， 而hibernate则是community在实际项目中不断总结修改的产物， 所以推广的很好. 设计标准就象设计interface， 在你对某个method不很有把握的时侯， 最好不要加到里面去。你大可在class里先写出来， 如果感觉好的话再放到interface. 还有cwm, 我们公司是做data warehouse的， 有美东最大的database, 我也对cwm标准看过一下， 发现不少地方不太适用， 据我所知， 连SAS, 很成熟的数据分析公司， 也是按自己的标准来做的， 恩，这里有我的片面，因为我学东西先看规范（会了java之后，其他技术也都是这么学的，我认为看书接受某专家的观点前，看一看设计者怎么说是很必要，起码可以有我自己的思考），然后再用，然后发现很多是理想和实现的差距，而不是本身理论不完备。我欣赏ejb的理论和努力，但是也不喜欢他现在的实现，因此我期待ejb3。 至于cwm，目前还没有真的成为数据的基础，但是oracle里多维度建模已经在用它作了，大厂不用有两个因素，第一cwm比较新，是否要投资还值得观望，第二目前没有特别强烈的对cwm的需要，但随着eai和intergration的深入，元数据集成不可避免。 cwm模型很完备，isc理论也很迷人。其实他的模型蛮有趣的，比如mapping包里有o/r mapping的元模型，或者说是conceptual/persistence mapping吧，从这个角度上讲，jdo是目前比较完备的持久实现，当然这一点大家可以讨论，我也自己想的。 |
| 返回顶楼 | |
