一个可能比SOA更好的思路

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

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

现在呢, 我直接告诉你:

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

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

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

厨房比饭馆更好?

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

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

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

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

你的方案虽然灵活,但client要完成一件事就必须用你提供的低层次的接口实现业务逻辑.这就造成了对这个接口的依赖.虽然说SOA也要依赖于菜单,但这个两种依赖是在不同层面的.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进一步面向对象化, 封装成既有数据又有逻辑的任务对象, 是不是 "有可能更好" ?

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

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

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

你说的Template是什么概念?

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

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

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

厨房比饭馆好吗?

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

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

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

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


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

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


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


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


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

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