一个可能比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) 时体现出来, 不过现在感觉看得更清晰一些了.

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

我觉得有道理并且模糊。想听你更多解释一些。

派个木马程序过去，摸清目标计算机的 service, port, 用户账户权限等各种不公开情况，传送回本机。
然后本机产生一套 script，发送到目标计算机的木马，里面有个script intepreter，可以执行 script。
可以最大限度地利用目标计算机的计算资源。

在 http://www.webofweb.net/manifesto/AppletAgainstAJAX.html 里我试图拿一个 Web Feed聚合器组件 来和一个经典的 字典(Java 里的 java.util.Map) 来做比较, 怎么样设计让它们被其他应用程序或者组件使用, 不过时间有限, 没有太细化.

我觉得大家有兴趣的话可以在这儿讨论一下, 大概的思路是:

Map比较简单, 基本的元操作就是3个:

get(key);
put(key, value);
remove(key);

而且只需要在被调用的时候本地运行.

Web聚合器就比较复杂, 可以想象到的操作比较多, 而且有可能是远程执行, 需要在后台自动抓新数据, 自动通知等等功能的问题.


具体的聚合器我也没做过, 只是觉得是个合适的例子, 自己想有点头大, 所以提出来希望有实战经验的朋友一起讨论讨论.


设想的最后结果是: 不像以传统方式那样给这个聚合器定义一系列service接口, 而是可能有个新的方案, 就是创建任务对象发送给聚合器, 然后在聚合器的环境下得到执行. 使用聚合器的组件本身也提供自己的环境, 这样聚合器那边有些任务的执行结果就可以创建新的任务对象再发送回来, 在主调组件这边执行, 比如修改主调组件这边的cache什么的.

在两边都是java平台时, 可以考虑通过RMI进行对象的传递. RMI效率和防火墙方面有点问题, 实际的应用可以用其他方案, 像WoW是通过自己的XT框架通过XML流发送对象. 不过RMI做原型来讨论比较直观, 就是发对象收对象.

哈哈, 是哦, 看来是黑客早就有这种思想了.

另外关于部署问题, 基于Java的话, 可以是这样一个方案:

组件都在容器中执行, 假设主调组件和被调组件处于两个容器当中.

特遣专员 单独开发编译打包, 当然要依赖于两边组件公开出来的类库.

然后特遣专员的代码包分别部署到两边的容器上. 这样一个包中的特定 特遣专员 类大部分时候在执行的时候如果需要创建和自己同一个包的 特遣专员类 实例往回发送, 就可以保证两边都可以正常接收并执行.

特遣专员类也可能需要创建其他特遣专员包中的特遣专员类对象, 这些依赖关系和J2EE容器中代码的依赖问题性质差不多, 可以类似解决.

哦对了, 特遣专员对象 在构造和传递时本身所承载的实例变量是用来代替通过 接口/服务 调用时的参数的, 这个也是一个关键点. 因为一个对象的实例成员变量可以比参数表传递的参数信息丰富灵活得多, 可以是动态结构化的. (在WoW的XT框架中, 其实还不止是实例成员变量, 传递对象时的XML流是由这里称为 特遣专员 的对象控制的, 其实传递的动态XML结构承载了更丰富灵活的信息. 不过跟这里主题扯得远了点了, 就不讨论了)

BOINC...

我觉得楼主提出的方案应该满足下面三个条件才采用:
1.客户的调用相当多，服务资源成为瓶颈。
2.本地的调用能数量级的提升计算速度。
3.客户所要的服务是动态的，随需的。

1,2两个条件的结合为本地脚本出现的必要条件。
条件3为脚本从客户端传送提供必要条件。
如果只有3没有1,2，客户端仍然可以组合多个远程的服务来完成服务的任务。

嗯,目前这个需要还不那么明显, 是因为程序架构一直是按老的路子去设计的, 而也不是所有的客户组件都达到了那么复杂的逻辑.

在中间件这个级别的组件没有改变观念重新设计架构之前, 是不太适合直接在最终客户组件里实施这样的思路.

这种转变另一半真正的好处是在定义接口规范方面的成本降低, 如果客户组件的接口随随便便就能定义的很好, 不用化很大力气, 那么也没有到须要做这种转变的地步.

另外, 在基于调用的架构上, server push需要客户端定期轮询才能实现; 如果转变到基于东道的架构, 有了Task Agent Bus, 那么直接就有这个能力了.