一个可能比SOA更好的思路

本文英文版发在: http://www.theserverside.com/discussions/thread.tss?thread_id=43148

在公开回答 (http://www.webofweb.net/manifesto/AppletAgainstAJAX.html) 为什么 WoW 当初选了Applet而不是AJAX的问题时, 我开始思考当前大规模软件组件相互集成的问题, 有了一些新想法.

概括来说, 我发现通常的 API(应用编程接口) 都是单一层次的, 即使是SOA中的服务定义也是. 描述为"单一层次"是因为它们是一个设计来被调用的一些 method/function 列表. 但是现在的软件组件其本身逻辑和调用它们的逻辑都复杂了很多, 而且相当一部分是 "多维" 的 - 结构化的对象和结构化的逻辑. 如此一来, 把多维的逻辑 压缩/抽象 成为单层的公开接口的必需工作量增长很快. 有些情况下, 这些抽象过程和为组合API设计规范的工作甚至有可能超过去理解和解决本来问题的成本.

所以我开始质疑这种通过公开接口来定义组件行为的方式, 还是这样最好? 别无他法? 我把这种方式叫做 基于调用的接合方式 (Invocation Based Interfacing), 这种方式下你都是通过调用去改变一个组件的状态或者获取它的结果.

然后我总结出一个截然不同的方式, 我称之为 基于东道的接合方式 (Hosting Based Interfacing). 在这种方式下 所谓的 特遣专员 被传递于软件组件之间, 各自完成预定的任务. 这样所带来的改变是软件组件不再需要定义公开的, 用来被反复调用/返回的 接口(服务), 而是公开它们的内部环境 (可能只需要把它们的部分内部逻辑直接公开出来, 无需再封装). 向接收到的 "特遣专员" 提供这样的环境以尽 "东道". 然后各种 "特遣专员" 就可以通过目标组件所提供的环境来完成自己的工作, 如果需要的话也可以构造新的 "特遣专员" 发送结果回去.

原始的想法已经在我设计 WoW 的 Traverser/Scener Architecture (http://www.webofweb.net/webstart?r=412) 时体现出来, 不过现在感觉看得更清晰一些了.

不知道大家怎么想这个问题.

评论

42 楼 jk88811 2006-12-29  

完全地看不懂!

唉, 没工作经验! 看来得好好学习了!

41 楼 helloworld 2006-12-29  

比喻为医生植入人体为人治病的小机器人更为恰当。满足以下几个条件：

1）人体的结构是已知的，但具体的参数不同

2）小机器人具有目的信息和收集信息的能力

3）医生可以根据小机器人收集的信息做相应的改变。

与SOA不同，如果同样比喻成病人，这个病人会说：我有一张表格说明我的各种功能。

40 楼 jeffreysky 2006-11-29  

不太明白！

39 楼 歆渊 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展现界面的秋色.

38 楼 zkj_beyond 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很难描述。

37 楼 歆渊 2006-11-26  

winterwolf 写道

现有的各种聚合本身就是一种SOA

楼主没必要受SOA*皮书的思路闲置 非要实现哪些莫名其妙复杂的调用 我认为现在的ws规范和ejb一样是个庞大复杂的理想产物. 而非现实可用的工具和框架.

EJB也能用来实现SOA吧, SOA本身是个很大且没有统一说法的概念, 但是总体来说, 各种途径都没有摆脱 Invocation Based Interfacing 的传统思维方式. 我这里就是提出与之相反的 Hosting Based Interfacing, 是希望找到一条新的更高效的复杂组件接合模式.

36 楼 winterwolf 2006-11-26  

现有的各种聚合本身就是一种SOA

楼主没必要受SOA*皮书的思路闲置 非要实现哪些莫名其妙复杂的调用 我认为现在的ws规范和ejb一样是个庞大复杂的理想产物. 而非现实可用的工具和框架.

35 楼 quaff 2006-11-24  

complystill 写道

庄表伟 写道

怎么觉得像是：“欢迎来我们家玩，一切请自便”
问题在于，你们家里有些什么可以给我玩呀？这些可以玩的东西，我要怎么玩，才不会把你们家搞得一团糟呢？

公开它们的内部环境，难道不也是一种API说明吗？

是这样的. 不过差别也可以这样描述. 你到我家来玩, 原来的情况是: 我给你三张纸的说明书, 上面写着:

  欢迎到我家:
    如果想喝水, 请: getWater(double litre);
    如果想大便, 请装袋以后: sendShhit(ShhitBag b);
    ...
    -=填满三张纸=-
    ...
    如果你要走了, 别忘了: exit(int status);

现在呢, 我直接告诉你:

   饮水机在客厅里, 你去看看里面有没有杯子, 自己倒水喝吧.
   厨房在那边, 里面有冰箱, 冰箱里有吃的, 你自己去看都有哪些, 捡喜欢的吃吧.
   厕所在那边, 里面也可以洗澡.
   还有不明白的, 每个房间都有什么东西自己去找好了.

各种设施(Local API)已经摆在那里了, 不想让你用的就藏起来或者锁上;
用的人直接去看那个东西是干什么用的, 怎么用; 而不是由主人总结一个说明书, 事事按照说明书喊口令;

当然各种设施自己也都要说明, 不过就省得再抽象包装到全局的唯一界面了.

就像使用hibernate查询一样,一般都是在dao层封装了很多查询方法,然后调用的时候使用具体的某个查询方法,而我更倾向于直接封装一个Criteria发送到dao完成所有的查询,这样就不需要在dao层为每个具体的查询都写一段代码,把代码下放到web层也就是调用方,我想楼主的思路大概也是这样,也就是前面有人说的Template,这也是某种意义上的控制反转吧

34 楼 歆渊 2006-11-23  

dongbin 写道

引用

刚看到.
这个是何时何人说的? 我是第一次见到, 还有其他什么法则? 背后的机理呢?

Martin Follower在《企业应用架构模式》里面说的。我也没仔细看过，只记住这一句话，呵呵。

仔细想了一下, 他这么说大概是反对把分布于多个运算节点的资源抽象封装到一个对象之内. 这个我也很赞同他的观点, 因为基于节点互联(网络)的不稳定性, 这样分布了以后你很难维护这么一个对象内部状态的一致性(难免要去执行牵涉多个状态的原子操作), 纵使理论上可行, 实际应用也会带来不可避免的问题.

不过HBI不是去分布对象, 而是在一个软件组件的环境下构造好可执行对象, 再把它发送到另一个组件的环境下去执行. 发送操作也是一个原子操作, 如果中间出错, 整个对象就会被废弃了, 所以应该不会犯Martin所列的这个忌讳.

dongbin 写道

复杂问题简单化是大智慧，简单问题复杂化是小聪明。

高內聚，松耦合是复杂问题简单化的手段。我实在想不出紧耦合程序有什么好处。

复杂性超过了原本的简单理论所能适用的范围后, 为了追求昔日的简单之美放不掉已经苍白的方法, 去封装套用老方法的复杂程度可能造就超过了它能带来的好处.

简单化的方法也要与时俱进的, 可能方法本身比原来变复杂了, 但这是因为要解决的问题复杂性已经发生了质的变化以后, 解决方法也要跟着作些革命性的演进才能适应新环境新问题.

CGI和Servlet规范就是紧耦合的一个现代例证, 还是松耦合的话你打算怎样? 自己解析HTTP请求, 自己设置一大堆必要的HEADER给response发送回去么? Apache/Servlet容器现在是特殊的应用服务器概念, 今后的复杂软件组件也会有类似的容器特性的.
特别是中间件. 试想为什么 RoR 能把基于CRUD的Web应用简化到如此程度, 是因为它不是像J2EE那样先定义一套层层封装的普适规范, 考虑与老系统和老方法学的互联, 再定义好公允的角色和行为, 然后再去实现. RoR可以说是就是给它的代码直接提供一个约定好的运行环境, 这个环境不是通过服务接口以及什么调用规范定义的, 而是通过程序语法,约定和逻辑结构关系表达出来的. 这个过程就是HBI的一种思路. 当然Ruby的灵活语法让这种思路的实现更容易得多.

33 楼 歆渊 2006-11-23  

taowen 写道

function(int arg)
这传进去的是数，不可执行。
function(function arg)
这传进去的是函数，可执行。
把javascript从服务器上下载下来，然后再在客户端执行这个javascript与服务器交互，就象函数式编程中的高阶函数一样。根本就是要让数据可执行。
但是在分布式系统中用这样的高阶函数的思想来设计行不行呢？未必不可。
希望楼主说“可能更好”的思路就是应用函数式编程的思想到分布式系统中。

函数式编程我迄今确实还没有好好研究过, 所以一下子也没办法理出其中的关系.

回头仔细研究一下.

32 楼 taowen 2006-11-21  

function(int arg)
这传进去的是数，不可执行。
function(function arg)
这传进去的是函数，可执行。
把javascript从服务器上下载下来，然后再在客户端执行这个javascript与服务器交互，就象函数式编程中的高阶函数一样。根本就是要让数据可执行。
但是在分布式系统中用这样的高阶函数的思想来设计行不行呢？未必不可。
希望楼主说“可能更好”的思路就是应用函数式编程的思想到分布式系统中。

31 楼 dongbin 2006-11-21  

越搞越复杂，我实在看不懂了，走人喽。

30 楼 歆渊 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 写道

另，请不要用这种居高临下的口气谈论中国的应用程序员。

这个我无意褒贬, 既然有人不舒服, 那么我在此道歉! 我会注意不再这样说话.

其他就不多说了.

29 楼 nihongye 2006-11-21  

看到一堆名词，但不知道你们在讨论什么，也不知道你们是否知道对方再说什么...

28 楼 aardvark 2006-11-21  

complystill 写道

EJB的出发点是为这些Bean提供 "组件服务", 然后为它设想一套普适的规范.
同时核心目标就是为了把一个组件以Bean的形式, 让它的方法怎么样包装起来可以不管远程还是本地的都一样调用.
我觉得从目标和手段上都是面向服务的.

你也看出来TOB的紧耦合倾向了, 那么你没有察觉利用TOB写持久类和基于EJB规范写EJB类的差别么?
写TOB持久类, 你就是直接定义你的拓扑结构和逻辑, 别人的可执行对象被 "传递" 到你的TOB服务器环境下也可以直接调用这些逻辑.
EJB是这样么? 不把EJB看作面向服务的话, 多半是因为它基于RMI而不是WebService. 好像非XML, 非WS的就不是SOA似的.

你理解错了。我说你的方案和EJB很像，说的是HOI，而不是TOB。

complystill 写道

我前面说的很清楚了, HBI不是去解决client调用server(发request得response)的问题的.

本质上来说，只要网络上的两台电脑有交互，要么是client/server，要么是p2p。你的Host本质上就是server；另一方，不管你把它叫什么，就是client。他们之间是紧耦合的，一如EJB和Container。这不是改个称呼就能改变的。

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简直就是反面典型。
另，请不要用这种居高临下的口气谈论中国的应用程序员。

complystill 写道

我发这个帖子也许就像在80年代谈网际互联的好处.

讲这种大话没有意义，不会为你赢得哪怕一点点的credit。

多说无益，就此散了罢....

27 楼 歆渊 2006-11-21  

aardvark 写道

我很诧异你会举出EJB的例子。不知道你对EJB有多熟悉？在我看来，你的那套想法恰恰如同EJB。你的宿主就如同EJB Container，封装的逻辑就如同EJB。我之所以说是致命的缺陷，就是因为它会有类似EJB和Container之间的紧耦合问题。EJB作为业界标准，被spring,hibernate逼到了墙根，还不就是因为这个缺陷？EJB3带来的进步，还不就是弥补了这个缺陷？

EJB的出发点是为这些Bean提供 "组件服务", 然后为它设想一套普适的规范.
同时核心目标就是为了把一个组件以Bean的形式, 让它的方法怎么样包装起来可以不管远程还是本地的都一样调用.
我觉得从目标和手段上都是面向服务的.

你也看出来TOB的紧耦合倾向了, 那么你没有察觉利用TOB写持久类和基于EJB规范写EJB类的差别么?
写TOB持久类, 你就是直接定义你的拓扑结构和逻辑, 别人的可执行对象被 "传递" 到你的TOB服务器环境下也可以直接调用这些逻辑.
EJB是这样么? 不把EJB看作面向服务的话, 多半是因为它基于RMI而不是WebService. 好像非XML, 非WS的就不是SOA似的.

aardvark 写道

可能你一直都在做底层的和中间件层的工作，没有多少做应用的经验，所以你不理解紧耦合在应用中有多糟糕。设想一个实际的应用，如果我用SOA，那么我client side的开发和测试可以很容易脱离server side进行，只要有个mock就行了，反之开发server端也是一样；如果用你的架构，那我client side的开发和测试必须依赖于server side，而开发server side也需要有client side来做测试。

我前面说的很清楚了, HBI不是去解决client调用server(发request得response)的问题的.

aardvark 写道

上面说的是一个系统中不同部分之间的依赖,即coupling。低耦合度的系统易于测试、易于维护、易于扩展，这是现在业界的共识。另外一种依赖是说应用对产品的依赖，即vendor lock-in。你举出GWT的例子，那个应该属于我们说的后面这种依赖，还是不要和前一种混在一起说好。

对产品的依赖，上次说到你的对象数据库的时候，你先举出了Java中的Object的例子，后又举出Oracle的例子，来阐述依赖的不可避免。其实你这是把依赖绝对化了。任何软件系统，绝对地无依赖，是不可能的，至少它要依赖于某个语言来实现。而依赖谁，依赖到什么程度，这里面分别很大。我的某个应用依赖于Oracle，如果我应用了某种ORM比如Hibernate来实现，那它对Oracle的依赖就不很强，我可以把Oracle替换成其他关系数据库比如DB2。你或许说那我还依赖于Hibernate。我用了DAO模式，也可以地把Hibernate替换成其他实现比如JDBC。那你最后说我还依赖于DAO。依赖于某种设计模式会是问题吗？DAO并没有一个vendor。再来说你的对象数据库，任何一个要persist的class都要以你提供的类为基类，基于你的对象数据库的应用完全彻底地依赖于你的产品，这依赖程度能同日而语吗？

作为一个技能相对出色的程序员来说, 往往非常容易低估软件开发成本, 因为这对自己是手到擒来的, 小菜一碟. 但是其实这个问题很严重. 我有些朋友做软件开发生意, 但是自己不搞技术, (从商业角度讲)简直是太难了.

你觉得从一种DAO移植到另一种DAO不难, 通过Hibernate, 从Oracle移植到DB2不难, 确实从写代码的角度不难. 但是这里的风险因素很大.
而中间件产品就是开发了去降低这些风险, 解决移植问题的. 应用程序员去了解底层的细节, 学会多种产品的开发技巧, 对自己是有利的, 但对企业来说不是很好的事情.
中间件产品看起来有些是通过Vendor-Lockin获利的, 不过它的核心价值在于系统级的问题解决, 尽量的剥离应用逻辑与系统逻辑. 每个程序员都是多面手, 能顺利的从Hibernate向iBatis或者Castor移植, 这也是好事, 但这不是一个把IT作为工具来用的企业的关注点.
中国的应用程序员都有系统程序员情结, 这个也是现状.

aardvark 写道

你举了GWT的例子。这我就要说依赖谁的问题了。Google那么大的公司，拿出来的产品谁都不会担心会夭折。Oracle也一样。依赖于Google，没多少人会担心GWT前景如何；依赖于你的产品，有多少人会不担心呢？

所以我是在大企业大架构, 甚至整个行业的高度上来讨论这个思想, 你心理上先把它拽到一个小公司的小产品这么一个级别, 拿软件应用问题来衡量.

aardvark 写道

真理有时是掌握在少数人手中，但并不是少数人掌握的都是真理。相反，产品的生命是掌握在大多数人中，这一点我们倒是可以确定的。能看出你做了不少了不起的工作，深度难度都比做应用要高。可是如果方向失误，那可真是太可惜了。“虽千万人吾往矣”的勇气固然令人敬佩，但你能不能afford the risk呢？望三思。

嗯, 也许在这里讨论更具体的技术细节和应用开发中的问题解决更合适.
我发这个帖子也许就像在80年代谈网际互联的好处. 不过想到了一个idea我就发一发, 经由众人讨论, 哪怕是批评也好, 能找到一些新意, 想到些新问题, 也未尝不是好事.

26 楼 歆渊 2006-11-21  

Gene 写道

楼主既不了解SOA的现状, 也没有明确说出自己的方案如何实现.在我看来你的东道系统就无法满足现代企业内部种类繁多的特遣员的运行要求. 现在SOA的技术已经日趋成熟, 而且有很多主流的产品占据了这个市场. 新的一种实现方式并没有太多的意义.

这个思想其实是立足现状展望未来的, 当前确实是SOA的天下, 因为设计思路未曾突破过.

如果转变到HBI以后, 从应用服务器的架构上就会有根本性的变化, 那时候每个组件都可以有迷你的相当于现在概念的应用服务器特性.

所以这是一个很长远的趋势, 不是目前我就要拿出一个具体的产品来开始应用的问题.

25 楼 aardvark 2006-11-21  

引用

为什么一定会致命呢? 你可能就是不喜欢这种方式, 但这是应对多维逻辑的更有效途径, 当你的组件逻辑复杂到要化大力气才能定义出一套service接口, 花更大的力气才能向别人说明白并且教会如何使用的时候, 这个可能已经超过了你开发这个组件去解决本来问题的成本了. 并且别人学起来也很累, 很头疼. 举例: EJB 规范.

枝节问题就顾不上了，我们直接说最关键的部分。

我很诧异你会举出EJB的例子。不知道你对EJB有多熟悉？在我看来，你的那套想法恰恰如同EJB。你的宿主就如同EJB Container，封装的逻辑就如同EJB。我之所以说是致命的缺陷，就是因为它会有类似EJB和Container之间的紧耦合问题。EJB作为业界标准，被spring,hibernate逼到了墙根，还不就是因为这个缺陷？EJB3带来的进步，还不就是弥补了这个缺陷？

可能你一直都在做底层的和中间件层的工作，没有多少做应用的经验，所以你不理解紧耦合在应用中有多糟糕。设想一个实际的应用，如果我用SOA，那么我client side的开发和测试可以很容易脱离server side进行，只要有个mock就行了，反之开发server端也是一样；如果用你的架构，那我client side的开发和测试必须依赖于server side，而开发server side也需要有client side来做测试。

上面说的是一个系统中不同部分之间的依赖,即coupling。低耦合度的系统易于测试、易于维护、易于扩展，这是现在业界的共识。另外一种依赖是说应用对产品的依赖，即vendor lock-in。你举出GWT的例子，那个应该属于我们说的后面这种依赖，还是不要和前一种混在一起说好。

对产品的依赖，上次说到你的对象数据库的时候，你先举出了Java中的Object的例子，后又举出Oracle的例子，来阐述依赖的不可避免。其实你这是把依赖绝对化了。任何软件系统，绝对地无依赖，是不可能的，至少它要依赖于某个语言来实现。而依赖谁，依赖到什么程度，这里面分别很大。我的某个应用依赖于Oracle，如果我应用了某种ORM比如Hibernate来实现，那它对Oracle的依赖就不很强，我可以把Oracle替换成其他关系数据库比如DB2。你或许说那我还依赖于Hibernate。我用了DAO模式，也可以地把Hibernate替换成其他实现比如JDBC。那你最后说我还依赖于DAO。依赖于某种设计模式会是问题吗？DAO并没有一个vendor。再来说你的对象数据库，任何一个要persist的class都要以你提供的类为基类，基于你的对象数据库的应用完全彻底地依赖于你的产品，这依赖程度能同日而语吗？

你举了GWT的例子。这我就要说依赖谁的问题了。Google那么大的公司，拿出来的产品谁都不会担心会夭折。Oracle也一样。依赖于Google，没多少人会担心GWT前景如何；依赖于你的产品，有多少人会不担心呢？

真理有时是掌握在少数人手中，但并不是少数人掌握的都是真理。相反，产品的生命是掌握在大多数人中，这一点我们倒是可以确定的。能看出你做了不少了不起的工作，深度难度都比做应用要高。可是如果方向失误，那可真是太可惜了。“虽千万人吾往矣”的勇气固然令人敬佩，但你能不能afford the risk呢？望三思。

24 楼 Gene 2006-11-20  

楼主既不了解SOA的现状, 也没有明确说出自己的方案如何实现.在我看来你的东道系统就无法满足现代企业内部种类繁多的特遣员的运行要求. 现在SOA的技术已经日趋成熟, 而且有很多主流的产品占据了这个市场. 新的一种实现方式并没有太多的意义.

23 楼 dongbin 2006-11-20  

复杂问题简单化是大智慧，简单问题复杂化是小聪明。

高內聚，松耦合是复杂问题简单化的手段。我实在想不出紧耦合程序有什么好处。