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

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

评论

22 楼 dongbin 2006-11-20  

引用

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

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

21 楼 歆渊 2006-11-20  

讨论交流就是好啊, 可以爆发出更多思想火花.

aardvark 写道

厨房比饭馆更好?

...

打个比方来说,SOA就如同饭馆.饭馆有菜单,有的还有套餐.菜单就是server和client交互的接口,如同wsdl.你去饭馆点菜,你只用知道菜单上的这个菜是什么,而不用知道这个菜是怎么做的.反正你点了它就给你上这个菜.

拿用餐的人和饭馆的关系来说, 只是一个 请求 -> 获得服务 的问题. 这就算SOA了么?
这个早在 C/S 架构就解决的很好了, SOA 跳出来做什么呢

aardvark 写道

你说了,饭馆要整理出来一个菜单,太麻烦了,而且也不能满足所有客户的需求.那好,你把饭馆变成个open kitchen,告诉客人火眼在哪锅在哪调料在哪面粉在哪肉在哪,客人进了厨房可以照着自己的想法爱做什么做什么.不可否认,这样的方案更灵活.

但是假如饭馆雇了一个新采办, 负责在外面买菜, 那么配菜师给采办一个单子:

如果你想知道番茄还剩多少, 问我 howMuchTomato();
如果你想知道还有几个空柜子, 问我 getNumEmptyBulks();
...
如果你想问我今天打算买多少茄子, 问我 calcEggplantNeeds();
...
记得每5分钟给我打个电话, 问我是不是菜不够了, hasNewRequest();

aardvark 写道

但是,凡事有利必有弊.SOA正如其名字说的那样,是service oriented,关注的是提供service.饭馆提供的service,就是你点个菜,不用关心具体做菜的细节,它就给你端上来.相对你的方案来说这是个更高层次的service.这个"不用关系做菜的细节",就是松耦合.是你的方案所不能提供的.

上面说了,只是点菜/获得菜这个事情实在挤不出SOA的必要来.
说回来, 如果客人说 "今天想吃活海鲜, 我想去看看你们今天的鲜货哪个合胃口."
那你打算说: 不好意思, 海鲜的品种和价格变化太快, 我们也没有菜单, 菜单上没有的就不做. (不是所有饭馆都这样吧?)

执行环境里也是一些API呀, 只不过可能有一些逻辑和组织上的层次而已; 没有人说过要你自己去操作 C 的 struct 或者 Java 的 field 呀, 为什么不能提供细节无关性呢?

aardvark 写道

你的方案虽然灵活,但client要完成一件事就必须用你提供的低层次的接口实现业务逻辑.这就造成了对这个接口的依赖.虽然说SOA也要依赖于菜单,但这个两种依赖是在不同层面的.SOA的依赖脱离于业务逻辑,菜单这个接口很容易替换.而低层次的依赖和业务逻辑搅在一起,很难替换.

环境也可以定义成相对公开的, 有多个实现的啊, 必要的时候包装一下都可以. 比如 WinNT 内核上的 ANSI 库.

aardvark 写道

并不是说你的方案一无是处,总会有些地方是你的方案更适合的.但是,第一,这个行业的大趋势是松耦合低依赖,你要有更很强烈的理由支持你才能逆潮流而上,这个理由你有没有?第二,具体到底什么地方你的方案更适合,你自己应该做研究,而不是放句话在那说"可能更好".

第一, 说的没错, 走SOA的路子就是这样, 所以我才质疑它的绝对正确性. 真理往往掌握在少数人手里.
第二, 现在这些讨论就是在做这个研究.

20 楼 歆渊 2006-11-20  

dongbin 写道

分布式系统第一法则：不要分布你的对象！

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

19 楼 歆渊 2006-11-20  

aardvark 写道

你的涵养很好,我很佩服.但是请不要再在标题上玩儿花花了.

讨论的实质内容更重要吧, 我觉得标题上适当标新立异没有超出技术论坛的规则范畴吧.

aardvark 写道

"厨房是个可能比饭馆更好的方案",这个论断没有意义.你再改头换面成"是不是有可能更好",还是没有意义.是不是更好需要有预设前提,是"一般意义上更好",还是"在某种特定的条件下更好",才是有意义的论断.

厨房比饭馆好吗?

我现在也觉得 "方案" 这个词用的不合适, 说 "思路" 可能更恰当一些.

但是标题一定要加上那么严谨的限定吗? 如果我标题设为 "一个可能比饭馆做出来的南瓜都好吃的做法", 你是不是也会介意啊?

aardvark 写道

封装既有数据又有逻辑的任务对象,比单纯的数据好吗?封装进去的逻辑是依赖于服务器方提供的接口的.紧耦合是它的致命缺陷.

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

aardvark 写道

AJAX技术中Server端在response中放Javascript,是假定client端支持Javascript.这种依赖在web环境中是合理的,因为绝大多数浏览器都支持Javascript.即便如此,通常AJAX应用也还要考虑到如果客户端不支持Javascript如何degrade.而在你的方案中,业务逻辑对服务器的依赖是server specific的,是很紧的依赖.你拿AJAX技术打比方,可惜,不恰当.

我前面提到 GTK 写错了, 应该是 GWT (Google Web Toolkit)
GWT 不是 AJAX 的一种扩展么? 如果基于GWT开发AJAX应用, 你是用Java去写浏览器界面, 从编译到执行, 对GWT的依赖是不是就可以称得上你说的 "很紧的依赖" 了?
你看一个更极端的: http://www.youos.com -- 你的浏览器摇身一变成了操作系统了. 如果不是有了youos这样一个宿主环境, 怎么可能开发出它已经有的那些轻量级应用呢. 如果观念还没有从 request/response 模式转变过来, 就不可能有GWT和YouOS, 而只有有了这些给你提供环境去依赖的复杂软件组件以后, 你才可能在它所提供的架子上开发更好的业务组件, 以与时俱进的方式运行.

aardvark 写道

我很纳闷,为什么你总是prefer紧耦合的方案呢?那个Ojbect Database如此,这个又如此.你真的从来就不觉得紧耦合的不便吗?

我对紧耦合确实比较偏向, 因为相对于松耦合它可以代表: 性能, 控制, 优美. 这也不止是我一个人的偏向, 在刚开始推崇Java时, 网络既是计算机 (The Network Is The Computer) 就是 SUN 的口号, 虽然现在看来他们没有获得预期的结果, 但现在也还列在 SUN 的商标当中. 你可以看到 SUN 后来搞 开放网络环境 (Open Network Environment) 也是没有怎么成功. 我觉得在一定程度上可以把前者看成紧耦合倾向, 后者看成松耦合倾向.

这都是因时因地而异的, 在复杂软件组件需要相互密集协作的环境下, 我就是觉得在它们之间传递紧耦合于它们环境的可执行对象是最好的方式.
之所以针对SOA提出, 是因为它也是目标去解决复杂组件协作问题的, 不是去中继 request 然后定位处理程序, 再把处理程序的结果 response 传递回去那么简单.

18 楼 aardvark 2006-11-20  

complystill 写道

aardvark 写道

厨房比饭馆更好?

上次我指出你关公战秦琼,你辩说是为了吸引眼球.这次你又来个"可能比SOA更好",实在太过分了.作为方案的提出人,你应该做过它和SOA的比较,什么地方比SOA好,什么地方不如SOA,你理当给出自己的分析.含含糊糊地说"可能比SOA更好",很不严肃,很不老实!做技术的人不能搞小报记者那一套!

打个比方来说,SOA就如同饭馆.饭馆有菜单,有的还有套餐.菜单就是server和client交互的接口,如同wsdl.你去饭馆点菜,你只用知道菜单上的这个菜是什么,而不用知道这个菜是怎么做的.反正你点了它就给你上这个菜.

你说了,饭馆要整理出来一个菜单,太麻烦了,而且也不能满足所有客户的需求.那好,你把饭馆变成个open kitchen,告诉客人火眼在哪锅在哪调料在哪面粉在哪肉在哪,客人进了厨房可以照着自己的想法爱做什么做什么.不可否认,这样的方案更灵活.

但是,凡事有利必有弊.SOA正如其名字说的那样,是service oriented,关注的是提供service.饭馆提供的service,就是你点个菜,不用关心具体做菜的细节,它就给你端上来.相对你的方案来说这是个更高层次的service.这个"不用关系做菜的细节",就是松耦合.是你的方案所不能提供的.

你的方案虽然灵活,但client要完成一件事就必须用你提供的低层次的接口实现业务逻辑.这就造成了对这个接口的依赖.虽然说SOA也要依赖于菜单,但这个两种依赖是在不同层面的.SOA的依赖脱离于业务逻辑,菜单这个接口很容易替换.而低层次的依赖和业务逻辑搅在一起,很难替换.

并不是说你的方案一无是处,总会有些地方是你的方案更适合的.但是,第一,这个行业的大趋势是松耦合低依赖,你要有更很强烈的理由支持你才能逆潮流而上,这个理由你有没有?第二,具体到底什么地方你的方案更适合,你自己应该做研究,而不是放句话在那说"可能更好".

呵呵, 问题和思想不就是拿来讨论的么, 一步到位的方案我就去发Paper了, 不用在论坛交流了.
讨论问题不用动火气吧.

你说的其实就是抽象封装的原理, 这个是从古至今未曾受过怀疑的公认方法, SOA也继承了这个思想.
所以我才说另一条途径 "可能更好", 因为它是条新路.

其实在我设想的环境中, 软件组件之间的关系相对更为平等, 相互协作来完成全局功能. 没有C/S模式下那么严格的client概念(我说的时候偶尔提到client为了顺承理解方便,其实概念不太一样了).
如果还是基于 request/response 机制, 那确实就是抽象封装起来最好不过了, 什么request返回什么response, 简单明了, 和实现无关.

但是现在软件开发有更复杂的趋势了, 比如AJAX吧, 浏览器可以认为是传统意义的client, 但是它现在提供了相当强大的DHTML模型, 才会出来AJAX这个东西, 用一下反向思维, 当前形势下其实web服务器也是去 "调用" 浏览器来呈现动态内容的, JS代码就是这些Task Agent, 被发送到浏览器去完成改变显示内容的任务. GTK是不是可以认为就是我这种思想的一种体现, 把浏览器的功能搭建成一个浏览器本地环境(这个你觉得封装成service更好么?), 然后你在服务器上写了功能代码发过去到那边执行?

现在AJAX是通过XML传递数据的, 要完成的逻辑附加在XML的结构和内容上, 还得由对方代码来解析执行, 如果从我这种思想出发, 把传递的XML进一步面向对象化, 封装成既有数据又有逻辑的任务对象, 是不是 "有可能更好" ?

你的涵养很好,我很佩服.但是请不要再在标题上玩儿花花了.

"厨房是个可能比饭馆更好的方案",这个论断没有意义.你再改头换面成"是不是有可能更好",还是没有意义.是不是更好需要有预设前提,是"一般意义上更好",还是"在某种特定的条件下更好",才是有意义的论断.

厨房比饭馆好吗?

封装既有数据又有逻辑的任务对象,比单纯的数据好吗?封装进去的逻辑是依赖于服务器方提供的接口的.紧耦合是它的致命缺陷.

AJAX技术中Server端在response中放Javascript,是假定client端支持Javascript.这种依赖在web环境中是合理的,因为绝大多数浏览器都支持Javascript.即便如此,通常AJAX应用也还要考虑到如果客户端不支持Javascript如何degrade.而在你的方案中,业务逻辑对服务器的依赖是server specific的,是很紧的依赖.你拿AJAX技术打比方,可惜,不恰当.

我很纳闷,为什么你总是prefer紧耦合的方案呢?那个Ojbect Database如此,这个又如此.你真的从来就不觉得紧耦合的不便吗?

17 楼 dongbin 2006-11-20  

分布式系统第一法则：不要分布你的对象！

16 楼 歆渊 2006-11-20  

s5kk 写道

俺怎么看你说的似乎就是个 Template,
这东西咋就会比谁谁谁先进捏？

你说的Template是什么概念?

15 楼 s5kk 2006-11-20  

俺怎么看你说的似乎就是个 Template,
这东西咋就会比谁谁谁先进捏？

14 楼 歆渊 2006-11-20  

又想起来, 其实这也是拆分庞大组件的一种途径. 在SOA下, 一个组件必需对它的全部Service接口负责, 即使内部再拆分成内部模块, 作为整个组件出现时, 容器所能管理的最小单元也还是这个组件, 它整体庞大复杂不说, 还不得不承担起本身内部模块的管理工作.

如果基于 Hosting Based Interfacing, 一个基本组件在完成了基础设施建设(Hosting Environment)以后就可以完工了, 细分逻辑可以作为更多单独的组件被独立设计, 开发, 调试, 部署. 当然它们会依赖于大组件, 但是只要容器先部署了大组件就可以了. 独立卸载或者重新部署细分组件对大组件和其他组件都不会造成影响, 也就提高了容器的可控粒度, 增加了动态部署的可能程度.

13 楼 歆渊 2006-11-20  

aardvark 写道

厨房比饭馆更好?

上次我指出你关公战秦琼,你辩说是为了吸引眼球.这次你又来个"可能比SOA更好",实在太过分了.作为方案的提出人,你应该做过它和SOA的比较,什么地方比SOA好,什么地方不如SOA,你理当给出自己的分析.含含糊糊地说"可能比SOA更好",很不严肃,很不老实!做技术的人不能搞小报记者那一套!

打个比方来说,SOA就如同饭馆.饭馆有菜单,有的还有套餐.菜单就是server和client交互的接口,如同wsdl.你去饭馆点菜,你只用知道菜单上的这个菜是什么,而不用知道这个菜是怎么做的.反正你点了它就给你上这个菜.

你说了,饭馆要整理出来一个菜单,太麻烦了,而且也不能满足所有客户的需求.那好,你把饭馆变成个open kitchen,告诉客人火眼在哪锅在哪调料在哪面粉在哪肉在哪,客人进了厨房可以照着自己的想法爱做什么做什么.不可否认,这样的方案更灵活.

但是,凡事有利必有弊.SOA正如其名字说的那样,是service oriented,关注的是提供service.饭馆提供的service,就是你点个菜,不用关心具体做菜的细节,它就给你端上来.相对你的方案来说这是个更高层次的service.这个"不用关系做菜的细节",就是松耦合.是你的方案所不能提供的.

你的方案虽然灵活,但client要完成一件事就必须用你提供的低层次的接口实现业务逻辑.这就造成了对这个接口的依赖.虽然说SOA也要依赖于菜单,但这个两种依赖是在不同层面的.SOA的依赖脱离于业务逻辑,菜单这个接口很容易替换.而低层次的依赖和业务逻辑搅在一起,很难替换.

并不是说你的方案一无是处,总会有些地方是你的方案更适合的.但是,第一,这个行业的大趋势是松耦合低依赖,你要有更很强烈的理由支持你才能逆潮流而上,这个理由你有没有?第二,具体到底什么地方你的方案更适合,你自己应该做研究,而不是放句话在那说"可能更好".

呵呵, 问题和思想不就是拿来讨论的么, 一步到位的方案我就去发Paper了, 不用在论坛交流了.
讨论问题不用动火气吧.

你说的其实就是抽象封装的原理, 这个是从古至今未曾受过怀疑的公认方法, SOA也继承了这个思想.
所以我才说另一条途径 "可能更好", 因为它是条新路.

其实在我设想的环境中, 软件组件之间的关系相对更为平等, 相互协作来完成全局功能. 没有C/S模式下那么严格的client概念(我说的时候偶尔提到client为了顺承理解方便,其实概念不太一样了).
如果还是基于 request/response 机制, 那确实就是抽象封装起来最好不过了, 什么request返回什么response, 简单明了, 和实现无关.

但是现在软件开发有更复杂的趋势了, 比如AJAX吧, 浏览器可以认为是传统意义的client, 但是它现在提供了相当强大的DHTML模型, 才会出来AJAX这个东西, 用一下反向思维, 当前形势下其实web服务器也是去 "调用" 浏览器来呈现动态内容的, JS代码就是这些Task Agent, 被发送到浏览器去完成改变显示内容的任务. GTK是不是可以认为就是我这种思想的一种体现, 把浏览器的功能搭建成一个浏览器本地环境(这个你觉得封装成service更好么?), 然后你在服务器上写了功能代码发过去到那边执行?

现在AJAX是通过XML传递数据的, 要完成的逻辑附加在XML的结构和内容上, 还得由对方代码来解析执行, 如果从我这种思想出发, 把传递的XML进一步面向对象化, 封装成既有数据又有逻辑的任务对象, 是不是 "有可能更好" ?

12 楼 wolfsquare 2006-11-20  

说的还是比较模糊,搞不好换汤不换药.
让SOA出份菜单也是很简单的事情.

11 楼 aardvark 2006-11-20  

厨房比饭馆更好?

上次我指出你关公战秦琼,你辩说是为了吸引眼球.这次你又来个"可能比SOA更好",实在太过分了.作为方案的提出人,你应该做过它和SOA的比较,什么地方比SOA好,什么地方不如SOA,你理当给出自己的分析.含含糊糊地说"可能比SOA更好",很不严肃,很不老实!做技术的人不能搞小报记者那一套!

打个比方来说,SOA就如同饭馆.饭馆有菜单,有的还有套餐.菜单就是server和client交互的接口,如同wsdl.你去饭馆点菜,你只用知道菜单上的这个菜是什么,而不用知道这个菜是怎么做的.反正你点了它就给你上这个菜.

你说了,饭馆要整理出来一个菜单,太麻烦了,而且也不能满足所有客户的需求.那好,你把饭馆变成个open kitchen,告诉客人火眼在哪锅在哪调料在哪面粉在哪肉在哪,客人进了厨房可以照着自己的想法爱做什么做什么.不可否认,这样的方案更灵活.

但是,凡事有利必有弊.SOA正如其名字说的那样,是service oriented,关注的是提供service.饭馆提供的service,就是你点个菜,不用关心具体做菜的细节,它就给你端上来.相对你的方案来说这是个更高层次的service.这个"不用关系做菜的细节",就是松耦合.是你的方案所不能提供的.

你的方案虽然灵活,但client要完成一件事就必须用你提供的低层次的接口实现业务逻辑.这就造成了对这个接口的依赖.虽然说SOA也要依赖于菜单,但这个两种依赖是在不同层面的.SOA的依赖脱离于业务逻辑,菜单这个接口很容易替换.而低层次的依赖和业务逻辑搅在一起,很难替换.

并不是说你的方案一无是处,总会有些地方是你的方案更适合的.但是,第一,这个行业的大趋势是松耦合低依赖,你要有更很强烈的理由支持你才能逆潮流而上,这个理由你有没有?第二,具体到底什么地方你的方案更适合,你自己应该做研究,而不是放句话在那说"可能更好".

10 楼 歆渊 2006-11-20  

庄表伟 写道

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

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

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

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

现在呢, 我直接告诉你:

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

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

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

9 楼 歆渊 2006-11-19  

nihongye 写道

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

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

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

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

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

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

8 楼 nihongye 2006-11-18  

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

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

7 楼 partech 2006-11-18  

BOINC...

6 楼 歆渊 2006-11-18  

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

5 楼 歆渊 2006-11-18  

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

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

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

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

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

4 楼 歆渊 2006-11-18  

buaawhl 写道

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

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

3 楼 歆渊 2006-11-18  

gigix 写道

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

在 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做原型来讨论比较直观, 就是发对象收对象.