|
锁定老帖子 主题：一个可能比SOA更好的思路
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2006-11-21
aardvark 写道 complystill 写道 EJB的出发点是为这些Bean提供 "组件服务", 然后为它设想一套普适的规范. 同时核心目标就是为了把一个组件以Bean的形式, 让它的方法怎么样包装起来可以不管远程还是本地的都一样调用. 我觉得从目标和手段上都是面向服务的. 你也看出来TOB的紧耦合倾向了, 那么你没有察觉利用TOB写持久类和基于EJB规范写EJB类的差别么? 写TOB持久类, 你就是直接定义你的拓扑结构和逻辑, 别人的可执行对象被 "传递" 到你的TOB服务器环境下也可以直接调用这些逻辑. EJB是这样么? 不把EJB看作面向服务的话, 多半是因为它基于RMI而不是WebService. 好像非XML, 非WS的就不是SOA似的. 你理解错了。我说你的方案和EJB很像，说的是HOI，而不是TOB。 这就是你还没有真正理解你正在批评的东西了. EJB还是 Invocation Based Interfacing, HBI正是against 这种模式的, 是从TOB到WoW一直都存在的一种新思路的总结探索. aardvark 写道 complystill 写道 我前面说的很清楚了, HBI不是去解决client调用server(发request得response)的问题的. 本质上来说，只要网络上的两台电脑有交互，要么是client/server，要么是p2p。你的Host本质上就是server；另一方，不管你把它叫什么，就是client。他们之间是紧耦合的，一如EJB和Container。这不是改个称呼就能改变的。 这样看来你的观念真的还局限在 request/response 的范围. aardvark 写道 complystill 写道 作为一个技能相对出色的程序员来说, 往往非常容易低估软件开发成本, 因为这对自己是手到擒来的, 小菜一碟. 但是其实这个问题很严重. 我有些朋友做软件开发生意, 但是自己不搞技术, (从商业角度讲)简直是太难了. 你觉得从一种DAO移植到另一种DAO不难, 通过Hibernate, 从Oracle移植到DB2不难, 确实从写代码的角度不难. 但是这里的风险因素很大. 而中间件产品就是开发了去降低这些风险, 解决移植问题的. 应用程序员去了解底层的细节, 学会多种产品的开发技巧, 对自己是有利的, 但对企业来说不是很好的事情. 中间件产品看起来有些是通过Vendor-Lockin获利的, 不过它的核心价值在于系统级的问题解决, 尽量的剥离应用逻辑与系统逻辑. 每个程序员都是多面手, 能顺利的从Hibernate向iBatis或者Castor移植, 这也是好事, 但这不是一个把IT作为工具来用的企业的关注点. 中国的应用程序员都有系统程序员情结, 这个也是现状. 你没明白我的重点。我并不是说从Oracle移植到DB2是多么painless，我是说我保留了这种可能，以备不时之需。而基于TOB的系统是无法至少是很难移植的。 好的中间件在消除系统对产品的依赖的同时，是不会引入系统对中间件的过多的依赖的。spring作为一个小小的opensource的产品能够抗衡EJB，靠的就是这个。 把IT作为工具的企业关注什么？不管你认为是什么，大的企业一定会关注vendor lock-in的。或许他们不关注我是用iBatis还是Hibernate，但是他们一定关注他们会被锁定在哪个厂商身上。DAO很好地解决了这个问题，而TOB简直就是反面典型。 TOB的代码量很少, 你花1000美元, 我可以卖给你一份, 自己随便改写, 保证比你在DAO方案之间移植的成本低得多. 提到过多的依赖, TOB只依赖于两个东西, Java5 和 Freemarker, 而且只是编译时才需要Freemarker, 编译好的应用只要有5.0以后的JVM就可以跑,你想用和TOB依赖的FreeMarker版本不兼容的任何库都不会出问题. Hibernate/Spring需要有多少第三方库才能跑? 去解决你打算用的多个第三方库之间的版本互相牵制就有可能搞得很头大. 作为商业应用, TOB的依赖绝对比Hibernate/Spring更有竞争力. 对程序员学习来说这些开源框架是成本很低的, 但对关键商业应用来说, 总体拥有成本却很高. 不过这样也造就了一块基于开源软件的第三方服务市场, 提供了一些软件公司低入门机会, 有利竞争. aardvark 写道 另，请不要用这种居高临下的口气谈论中国的应用程序员。
这个我无意褒贬, 既然有人不舒服, 那么我在此道歉! 我会注意不再这样说话. 其他就不多说了. |
| 返回顶楼 | |
|
发表时间：2006-11-21
越搞越复杂，我实在看不懂了，走人喽。
|
| 返回顶楼 | |
|
发表时间：2006-11-21
function(int arg)
这传进去的是数，不可执行。 function(function arg) 这传进去的是函数，可执行。 把javascript从服务器上下载下来，然后再在客户端执行这个javascript与服务器交互，就象函数式编程中的高阶函数一样。根本就是要让数据可执行。 但是在分布式系统中用这样的高阶函数的思想来设计行不行呢？未必不可。 希望楼主说“可能更好”的思路就是应用函数式编程的思想到分布式系统中。 |
| 返回顶楼 | |
|
发表时间：2006-11-23
taowen 写道 function(int arg)
这传进去的是数，不可执行。 function(function arg) 这传进去的是函数，可执行。 把javascript从服务器上下载下来，然后再在客户端执行这个javascript与服务器交互，就象函数式编程中的高阶函数一样。根本就是要让数据可执行。 但是在分布式系统中用这样的高阶函数的思想来设计行不行呢？未必不可。 希望楼主说“可能更好”的思路就是应用函数式编程的思想到分布式系统中。 函数式编程我迄今确实还没有好好研究过, 所以一下子也没办法理出其中的关系. 回头仔细研究一下. |
| 返回顶楼 | |
|
发表时间：2006-11-23
dongbin 写道 引用 刚看到. 这个是何时何人说的? 我是第一次见到, 还有其他什么法则? 背后的机理呢? Martin Follower在《企业应用架构模式》里面说的。我也没仔细看过，只记住这一句话，呵呵。 仔细想了一下, 他这么说大概是反对把分布于多个运算节点的资源抽象封装到一个对象之内. 这个我也很赞同他的观点, 因为基于节点互联(网络)的不稳定性, 这样分布了以后你很难维护这么一个对象内部状态的一致性(难免要去执行牵涉多个状态的原子操作), 纵使理论上可行, 实际应用也会带来不可避免的问题. 不过HBI不是去分布对象, 而是在一个软件组件的环境下构造好可执行对象, 再把它发送到另一个组件的环境下去执行. 发送操作也是一个原子操作, 如果中间出错, 整个对象就会被废弃了, 所以应该不会犯Martin所列的这个忌讳. dongbin 写道 复杂问题简单化是大智慧，简单问题复杂化是小聪明。
高內聚，松耦合是复杂问题简单化的手段。我实在想不出紧耦合程序有什么好处。 复杂性超过了原本的简单理论所能适用的范围后, 为了追求昔日的简单之美放不掉已经苍白的方法, 去封装套用老方法的复杂程度可能造就超过了它能带来的好处. 简单化的方法也要与时俱进的, 可能方法本身比原来变复杂了, 但这是因为要解决的问题复杂性已经发生了质的变化以后, 解决方法也要跟着作些革命性的演进才能适应新环境新问题. CGI和Servlet规范就是紧耦合的一个现代例证, 还是松耦合的话你打算怎样? 自己解析HTTP请求, 自己设置一大堆必要的HEADER给response发送回去么? Apache/Servlet容器现在是特殊的应用服务器概念, 今后的复杂软件组件也会有类似的容器特性的. 特别是中间件. 试想为什么 RoR 能把基于CRUD的Web应用简化到如此程度, 是因为它不是像J2EE那样先定义一套层层封装的普适规范, 考虑与老系统和老方法学的互联, 再定义好公允的角色和行为, 然后再去实现. RoR可以说是就是给它的代码直接提供一个约定好的运行环境, 这个环境不是通过服务接口以及什么调用规范定义的, 而是通过程序语法,约定和逻辑结构关系表达出来的. 这个过程就是HBI的一种思路. 当然Ruby的灵活语法让这种思路的实现更容易得多. |
| 返回顶楼 | |
|
发表时间：2006-11-24
complystill 写道 庄表伟 写道 怎么觉得像是：“欢迎来我们家玩，一切请自便”
问题在于，你们家里有些什么可以给我玩呀？这些可以玩的东西，我要怎么玩，才不会把你们家搞得一团糟呢？ 公开它们的内部环境，难道不也是一种API说明吗？ 是这样的. 不过差别也可以这样描述. 你到我家来玩, 原来的情况是: 我给你三张纸的说明书, 上面写着: 欢迎到我家:
如果想喝水, 请: getWater(double litre);
如果想大便, 请装袋以后: sendShhit(ShhitBag b);
...
-=填满三张纸=-
...
如果你要走了, 别忘了: exit(int status);
现在呢, 我直接告诉你: 饮水机在客厅里, 你去看看里面有没有杯子, 自己倒水喝吧. 厨房在那边, 里面有冰箱, 冰箱里有吃的, 你自己去看都有哪些, 捡喜欢的吃吧. 厕所在那边, 里面也可以洗澡. 还有不明白的, 每个房间都有什么东西自己去找好了. 各种设施(Local API)已经摆在那里了, 不想让你用的就藏起来或者锁上; 用的人直接去看那个东西是干什么用的, 怎么用; 而不是由主人总结一个说明书, 事事按照说明书喊口令; 当然各种设施自己也都要说明, 不过就省得再抽象包装到全局的唯一界面了. 就像使用hibernate查询一样,一般都是在dao层封装了很多查询方法,然后调用的时候使用具体的某个查询方法,而我更倾向于直接封装一个Criteria发送到dao完成所有的查询,这样就不需要在dao层为每个具体的查询都写一段代码,把代码下放到web层也就是调用方,我想楼主的思路大概也是这样,也就是前面有人说的Template,这也是某种意义上的控制反转吧 |
| 返回顶楼 | |
|
发表时间：2006-11-26
现有的各种聚合本身就是一种SOA
楼主没必要受SOA*皮书的思路闲置 非要实现哪些莫名其妙复杂的调用 我认为现在的ws规范和ejb一样是个庞大复杂的理想产物. 而非现实可用的工具和框架. |
| 返回顶楼 | |
|
发表时间：2006-11-26
winterwolf 写道 现有的各种聚合本身就是一种SOA
楼主没必要受SOA*皮书的思路闲置 非要实现哪些莫名其妙复杂的调用 我认为现在的ws规范和ejb一样是个庞大复杂的理想产物. 而非现实可用的工具和框架. EJB也能用来实现SOA吧, SOA本身是个很大且没有统一说法的概念, 但是总体来说, 各种途径都没有摆脱 Invocation Based Interfacing 的传统思维方式. 我这里就是提出与之相反的 Hosting Based Interfacing, 是希望找到一条新的更高效的复杂组件接合模式. |
| 返回顶楼 | |
|
发表时间：2006-11-26
taowen 写道 function(int arg)
这传进去的是数，不可执行。 function(function arg) 这传进去的是函数，可执行。 把javascript从服务器上下载下来，然后再在客户端执行这个javascript与服务器交互，就象函数式编程中的高阶函数一样。根本就是要让数据可执行。 但是在分布式系统中用这样的高阶函数的思想来设计行不行呢？未必不可。 希望楼主说“可能更好”的思路就是应用函数式编程的思想到分布式系统中。 http://www.xml.com/pub/a/2005/12/21/json-dynamic-script-tag.html http://developer.yahoo.com/maps/ajax/index.html google map api 已经有现成例子了。 to:complystill complystill 写道 描述为"单一层次"是因为它们是一个设计来被调用的一些 method/function 列表. 对于这类需求，现有的技术SOA,web service够了。 complystill 写道 但是现在的软件组件其本身逻辑和调用它们的逻辑都复杂了很多, 而且相当一部分是 "多维" 的 - 结构化的对象和结构化的逻辑. 如此一来, 把多维的逻辑 压缩/抽象 成为单层的公开接口的必需工作量增长很快. 有些情况下, 这些抽象过程和为组合API设计规范的工作甚至有可能超过去理解和解决本来问题的成本. 我到是认为这类需求很少。arcgis server， www.esri.com 我们用的个产品，分步式对象，确实如你说说，分布式节点之间是地图的处理过程，结果等。平面API很难描述。 |
| 返回顶楼 | |
|
发表时间：2006-11-27
zkj_beyond 写道 complystill 写道 但是现在的软件组件其本身逻辑和调用它们的逻辑都复杂了很多, 而且相当一部分是 "多维" 的 - 结构化的对象和结构化的逻辑. 如此一来, 把多维的逻辑 压缩/抽象 成为单层的公开接口的必需工作量增长很快. 有些情况下, 这些抽象过程和为组合API设计规范的工作甚至有可能超过去理解和解决本来问题的成本. 我到是认为这类需求很少。arcgis server， www.esri.com 我们用的个产品，分步式对象，确实如你说说，分布式节点之间是地图的处理过程，结果等。平面API很难描述。 嗯, GIS是一开始就比较复杂的一类应用. 不过一般Web应用也有向复杂方向发展的大趋势, AJAX应该就是客户端功能多维化的一个例证. 另外请看 http://www.webofweb.net 这个虽然刚起步, 但是我相信这种结构化的信息存在和表达形式会逐渐普遍起来, 让Web环境能进一步接近日常的数据关联模型, 比如各种分类信息, 按地域, 从大到小的品种划分出来的分类树. HTML还是平面二维媒体, 表达这些信息就不如WoW这种网状媒体自然有力. 以后很有可能加强成网络结构的MindMap与HTML平分Web展现界面的秋色. |
| 返回顶楼 | |
