本文英文版发在: [url]http://www.theserverside.com/discussions/thread.tss?thread_id=43148[/url]
在公开回答 ([url]http://www.webofweb.net/manifesto/AppletAgainstAJAX.html[/url]) 为什么 WoW 当初选了Applet而不是AJAX的问题时, 我开始思考当前大规模软件组件相互集成的问题, 有了一些新想法.
概括来说, 我发现通常的 API(应用编程接口) 都是单一层次的, 即使是SOA中的服务定义也是. 描述为"单一层次"是因为它们是一个设计来被调用的一些 method/function 列表. 但是现在的软件组件其本身逻辑和调用它们的逻辑都复杂了很多, 而且相当一部分是 "多维" 的 - 结构化的对象和结构化的逻辑. 如此一来, 把多维的逻辑 压缩/抽象 成为单层的公开接口的必需工作量增长很快. 有些情况下, 这些抽象过程和为组合API设计规范的工作甚至有可能超过去理解和解决本来问题的成本.
所以我开始质疑这种通过公开接口来定义组件行为的方式, 还是这样最好? 别无他法? 我把这种方式叫做 基于调用的接合方式 (Invocation Based Interfacing), 这种方式下你都是通过调用去改变一个组件的状态或者获取它的结果.
然后我总结出一个截然不同的方式, 我称之为 基于东道的接合方式 (Hosting Based Interfacing). 在这种方式下 所谓的 特遣专员 被传递于软件组件之间, 各自完成预定的任务. 这样所带来的改变是软件组件不再需要定义公开的, 用来被反复调用/返回的 接口(服务), 而是公开它们的内部环境 (可能只需要把它们的部分内部逻辑直接公开出来, 无需再封装). 向接收到的 "特遣专员" 提供这样的环境以尽 "东道". 然后各种 "特遣专员" 就可以通过目标组件所提供的环境来完成自己的工作, 如果需要的话也可以构造新的 "特遣专员" 发送结果回去.
原始的想法已经在我设计 WoW 的 Traverser/Scener Architecture ([url]http://www.webofweb.net/webstart?r=412[/url]) 时体现出来, 不过现在感觉看得更清晰一些了.
不知道大家怎么想这个问题.
在公开回答 ([url]http://www.webofweb.net/manifesto/AppletAgainstAJAX.html[/url]) 为什么 WoW 当初选了Applet而不是AJAX的问题时, 我开始思考当前大规模软件组件相互集成的问题, 有了一些新想法.
概括来说, 我发现通常的 API(应用编程接口) 都是单一层次的, 即使是SOA中的服务定义也是. 描述为"单一层次"是因为它们是一个设计来被调用的一些 method/function 列表. 但是现在的软件组件其本身逻辑和调用它们的逻辑都复杂了很多, 而且相当一部分是 "多维" 的 - 结构化的对象和结构化的逻辑. 如此一来, 把多维的逻辑 压缩/抽象 成为单层的公开接口的必需工作量增长很快. 有些情况下, 这些抽象过程和为组合API设计规范的工作甚至有可能超过去理解和解决本来问题的成本.
所以我开始质疑这种通过公开接口来定义组件行为的方式, 还是这样最好? 别无他法? 我把这种方式叫做 基于调用的接合方式 (Invocation Based Interfacing), 这种方式下你都是通过调用去改变一个组件的状态或者获取它的结果.
然后我总结出一个截然不同的方式, 我称之为 基于东道的接合方式 (Hosting Based Interfacing). 在这种方式下 所谓的 特遣专员 被传递于软件组件之间, 各自完成预定的任务. 这样所带来的改变是软件组件不再需要定义公开的, 用来被反复调用/返回的 接口(服务), 而是公开它们的内部环境 (可能只需要把它们的部分内部逻辑直接公开出来, 无需再封装). 向接收到的 "特遣专员" 提供这样的环境以尽 "东道". 然后各种 "特遣专员" 就可以通过目标组件所提供的环境来完成自己的工作, 如果需要的话也可以构造新的 "特遣专员" 发送结果回去.
原始的想法已经在我设计 WoW 的 Traverser/Scener Architecture ([url]http://www.webofweb.net/webstart?r=412[/url]) 时体现出来, 不过现在感觉看得更清晰一些了.
不知道大家怎么想这个问题.
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
