一个可能比SOA更好的思路

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

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


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


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

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

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

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


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


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

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

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

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

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

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

我很诧异你会举出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呢？望三思。

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

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

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

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

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

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

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

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

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

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

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

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


你没明白我的重点。我并不是说从Oracle移植到DB2是多么painless，我是说我保留了这种可能，以备不时之需。而基于TOB的系统是无法至少是很难移植的。
好的中间件在消除系统对产品的依赖的同时，是不会引入系统对中间件的过多的依赖的。spring作为一个小小的opensource的产品能够抗衡EJB，靠的就是这个。
把IT作为工具的企业关注什么？不管你认为是什么，大的企业一定会关注vendor lock-in的。或许他们不关注我是用iBatis还是Hibernate，但是他们一定关注他们会被锁定在哪个厂商身上。DAO很好地解决了这个问题，而TOB简直就是反面典型。
另，请不要用这种居高临下的口气谈论中国的应用程序员。


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

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

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