SOA没在忽悠

个人觉得数据整合,应用协同发展的步骤分为以下几步.
第一:数据库整合
第二:应用整合
第三:暴露服务整合,请求模式
第四:SOA

这四个步骤都有这么几个要素.
第一:应用方
第二:数据提供方
第三:业务需求

说SOA是忽悠的也可以理解,因为这四个步骤都可以实现SOA的目标.可是如果从业务扩展和变更的角度去考虑就会发现不同.

一个简单的例子,本来A,B,C三个部门有一个应用(比方是公司的三个不同部门) 因为政策变化公司需要把这个三个部门整合成一个部门,这样完全可以把进行数据库整合然后重新开发应用(第一种),或者把三个部门的应用进行整合(第二种)等...
这样的整合在功能实现上是一样的. 好的又过了一段时间,公司业务发展的需要又要把这个整合后的部门分为两个部门,这时候你依旧可以和以前那样进行整合. 这样就不难看出为了适应变化投入的成本.

下面我说说 第三和第四种整合模式

第三:暴露服务整合,请求模式这种整合已经是准SOA模式了只是它把业务的流程积压在应用方,服务提供方提供服务的细节对应用方是透明的.这种整合的缺点是在业务变化的时候 还需要比较大面积的修改原来应用的逻辑.
第四:SOA,其实它把简单的服务调用流程和数据库整合规则逻辑加在了SB上,服务对应用是不透明的.应用只需要知道有这个服务就可以了,这种模式在业务变化的情况下也许只是简单的修改流程脚本而已.

所以SOA有它自己独特的领域,并不能说SOA在忽悠,如果业务变更不大,业务流程不复杂那么完全可以不用SOA去做.

SOA在理论上是要解决数据孤岛的问题,但是它在本质上确实要解决协调工作的问题.快速应答客户需求只是这种模式带来的好处而已.

我不否认SOA是一大堆适配器,在没有平台规范的情况下这种情况是难免的.君不见JAVA世界里面还一大堆接口.你能说接口就不是一个适配器吗?
SOA在发展,就请不要再否认SOA的意义,容忍SOA在发展过程中犯的小错误,存在即合理.垃圾只是发错地方的财富而已.

评论

63 楼 bonny 2009-02-23  

andot 写道

我明白你的意思，你说的那些第二个层面的转换其实是业务层数据的转换，而不是通讯协议的转换。业务层的数据转换交由业务层来做就是了，为何非要一个ESB把业务层转换和通讯层转换放到一起做呢？

分成两部分来做，效率更高，逻辑也更清楚，不是吗？

我前面的帖子说过ESB的作用至少包含了
1，协议转换
2，语义转换

1，是可插拔的。并且协议转换是必须的，因为前后端业务系统需要。通讯层是独立的，在IBM message broker消息流里面表现的是输出输入节点。
2，语义转换。ESB的语义转换层也是独立的（在IBM message broker是消息流处理节点，处理方式可以选择ESQL或者自己写JAVA程序处理）。

谁告诉你说ESB把两个放在一起做了？

62 楼 andot 2009-02-23  

oth 写道

谁能定义协议转换是必须的?

把这个前提放这里,还有啥好说的.逻辑阿逻辑.

协议转换是必须的是由 IBM 定义的。所以所有被 IBM 洗脑的人都这么认为。

61 楼 oth 2009-02-23  

谁能定义协议转换是必须的?

把这个前提放这里,还有啥好说的.逻辑阿逻辑.

60 楼 andot 2009-02-23  

我明白你的意思，你说的那些第二个层面的转换其实是业务层数据的转换，而不是通讯协议的转换。业务层的数据转换交由业务层来做就是了，为何非要一个ESB把业务层转换和通讯层转换放到一起做呢？

分成两部分来做，效率更高，逻辑也更清楚，不是吗？

59 楼 bonny 2009-02-23  

andot 写道

对于大公司来说确实是：“没有复杂的协议转换，业务入侵，我们怎么能做得出又大又慢的软件啊，没有巨耗资源的软件，我们还买什么机器啊！”

我很理解这些公司的心情，我可能真的砸了他们的饭碗，对此我深表同情，但我也只能说节哀顺变。

快吐了我。

你要明白，对大企业的发展和信息整合而言。协议转换是必须的。
因为所谓的协议包括两个层面的意思，
一，是公用的标准的协议，比如TCP，http等，
二，是客户自定义的系统之间自定义编码，比如，在以前的遗留系统中，绝大多数场合，互相制定“AAA:****,BBB:****,DDD:****”这样的字符串或者制定<AAA>BBB</AAA>，或者是“1-10位表示**涵义，11-12位表示***”来，并且使用的传输方式也是各式各样。
随着客户信息系统的发展，必须讲这些数据服务整合到新系统中，如果是N对N的整合，工作量相当庞大，尤其涉及到系统1服务1+系统2服务2+....系统N服务N 的服务整合成新服务。
ESB不但可以整合协议一层次更重要的是整合协议二以上上的“协议”，并发布为协议一意义上的标准协议、标准的格式（或者任意的协议和格式），极大的简化了企业内部庞大繁多的信息系统服务整合。

既然协议转换无法避免，效率低下就无法避免（如果效率转换如你所言是效率低下的话）

PHPRPC我试用了一下，还不错。但是绝对无法替代“ESB”这样“又臭又大，效率低下”的东西。根本不一个层次的东西。你最多也就解决“协议一”层次上一些东西（比如SOAP的效率低下）。距离ESB概念还远着呢。

我浪费这么多时间给你解释ESB，我怀疑你根本就不懂ESB。却处处打着ESB的招牌，靠贬低ESB来推销自己。

58 楼 bonny 2009-02-23  

引用

对于大公司来说确实是：“没有复杂的协议转换，业务入侵，我们怎么能做得出又大又慢的软件啊，没有巨耗资源的软件，我们还买什么机器啊！”

我很理解这些公司的心情，我可能真的砸了他们的饭碗，对此我深表同情，但我也只能说节哀顺变。

要说效率高。

你效率有两个系统之间自定私自协议高么？
要说服务耦合度低，你有ESB服务耦合度低么？

我给你的定位：解决了普通场合soap效率低下的缺点，对于简单系统信息传递，具有简单、高效的有点。

你去扯SOA和ESB，并且贬低别人作广告，我鄙视你。

57 楼 oth 2009-02-23  

eyeieye 写道

捧哏的逗哏的都出来了，好不热闹。
我很喜欢andot的这个phprpc，非常喜欢，但也只是视为an other hessian ，但也不至于扯到soa啥事情吧？
andot 和你的支持者的心态不好，"我都有银弹了，你们还啰嗦什么"，这个是我仔细读了这几天je上的帖子后的发现，以至于有人要讨论esb的协议转换，你们来一个“都用phprpc不就成了？”来打发，这个也太....

长江后浪推前浪,前浪死在沙滩上,
技术上的革新是否成功,基本上都是拼了命的,以这种心态做事,才不会完全依赖洋人的技术.

首先我没说过“都用phprpc不就成了？”
其次,这也是行的通的,
再次,这不是打法,即使是你讲的"银弹",也许要耐心的看说明书.更何况,本来就没有银弹.

当提出用PHPRPC的时候,大家为啥不能用探索新鲜事物的心态去了解它呢?




<海角七号>很多人说是亲日,这些人了解台湾嘛?

"我都有银弹了，你们还啰嗦什么",      请不要用这种心态来揣测我们...

56 楼 andot 2009-02-23  

对于大公司来说确实是：“没有复杂的协议转换，业务入侵，我们怎么能做得出又大又慢的软件啊，没有巨耗资源的软件，我们还买什么机器啊！”

我很理解这些公司的心情，我可能真的砸了他们的饭碗，对此我深表同情，但我也只能说节哀顺变。

55 楼 eyeieye 2009-02-23  

捧哏的逗哏的都出来了，好不热闹。
我很喜欢andot的这个phprpc，非常喜欢，但也只是视为an other hessian ，但也不至于扯到soa啥事情吧？
andot 和你的支持者的心态不好，"我都有银弹了，你们还啰嗦什么"，这个是我仔细读了这几天je上的帖子后的发现，以至于有人要讨论esb的协议转换，你们来一个“都用phprpc不就成了？”来打发，这个也太....

54 楼 oth 2009-02-23  

厂商的行为,只有一个目的:使it企业利润最大化.
这些厂商,或者是厂商联盟提出的概念和方案同样也是使其自身利润最大化.

一个复杂的概念,一个繁杂的方案,以及其他高深的东西,都是围绕着利润.

而andot的phprpc却不是这样.
当直面phprpc的好处的时候,

这也就是很多靠这些厂商,牛逼方案吃饭的人所芥蒂,厌恶的时候.



有种的用phprpc试试,很多人不敢,没乐厂商,联盟的金字招牌,挣钱会少.
狠明显,andot不是这样,不是这个层次的民工.

53 楼 andot 2009-02-21  

bonny 写道

我们不可能去改造客户，不可能去要求客户去改造已经有的投资，或者丢弃已经有的投资。纸上谈兵很简单，可是真正作起来很难。

无差别数据交换，多好的梦想啊。sun说：write once，use anywhere，多好的梦想啊，成本不就是个小小的jvm么？你考虑过有多难么？

真正去一个经常去和客户打交道的公司，尤其是弱势的乙方，你就知道，一个美好的概念，即使是正确的，为客户省钱的，要他们接受是多么难。

能在保护既有投资，最佳是不变动的情况下的技术，是最好的。而不是高效什么的，那是程序员的想法。尤其硬件不值钱的情况下。对很多老板，宁愿花1kw买硬件提速，也不愿意在软件上作一点点改动。

你自己去考虑去吧。不要让客户适应你，你去适应客户。

明白，而且也是很实际的问题。如果现有的系统可以工作的很好，那是绝对没有必要采用什么新技术替换的。就好像现在还有很多原来使用旧的 EJB 方式编写的系统，也没有过渡到 Spring + Hibernate 这种新型的 EJB 组合上来。因为它们现在可以正常的跑，而且没有改造的必要，或者只要在上面进行小的修修补补即可，而无需大的改动。这都是很正常的。

但是如果某客户希望对自己的系统作较大改动，而在原有的基础上改动比采用新技术要花费更大（不只是硬件方面，也包括软件和人），而改造之后的维护费用也是采用新技术花费更少的话。那么你认为客户还会抱着旧技术不放吗？当然不会，对于客户来说，永远都是，在可以提供更好的服务的情况下，怎么才能做到最省钱还最赚钱。

而在构建新系统时，客户考虑的还是同样的问题。只要你能够做到在满足所有条件的基础上，最快最省的解决问题，那么客户就会选择这个。

bonny 写道

话再说回来，ESB在协议发布这个环节上，没有什么问题。他的协议发布是可插拔的，如果有一天PHPRPC协议主流了，我想ESB服务被发布成PHPrpc节点也肯定会有的。

明白，ESB 要做的就是大一统嘛，将所有问题集中于一处解决，但是这种思想跟 SOA 的解耦思想是有点背道而驰的。

bonny 写道

问题是esb内部要进行语义转换和服务整合，暂时主流都是用xml格式的数据，不知道phprpc数据结构在内部解析的时候高效么？数据整合的时候高效么？直观么？从内部数据发布为服务的时候，高效么？

PHPRPC 数据结构是否高效在之前我已经发过两篇评测的帖子了，不管在 .NET 还是 Java 下，都跟 Hessian 是一个级别的，甚至是超越 Hessian 的（但没有 10 倍数量级这种超越），而跟 XML 相比，是超越其十倍到百倍数量级的。其实 PHPRPC 最初就是为了要解决基于 XML 那些低效技术才被设计出来的，如果不高效，也就没有存在的意义了。数据格式在直观性上也超越 Hessian、AMF 等，因为是半文本结构，而不是纯二进制结构。

52 楼 andot 2009-02-21  

fjlyxx 写道

这个规范化 不是服务发布方式不同引起的, 这么和你说一个很简单的例子  比如A B 两个服务  A用1表示性别中的男  0表示性别中的女 B中用0表示男 1表示女  这样的话 你可以在流程脚本中进行指明 或者由 请求方和服务方进行约定等等方式去解决这个问题  但是这样就会让SOA平台流程处理,或请求方开发受很大的影响. 这个例子只是SOA规范中比较不紧要的一个例子. 再则如果我有两个SOA平台  那么我又如果应该在这两个SOA平台间进行通信调用流程能, 不是所以的SOA平台的流程都是BPEL的规范的.SOA的规范其实已经影响了SOA的发展.

原来你说的规范是从业务层出发的啊，那这个就跟具体技术无关了。这个只能在构建这样的系统前，就要对这些有一个统一的定义，否则确实会有你说的这种问题。而如果事先做的不够充分，以至于在实施阶段才发现的话，就只能通过编写语义转换的接口来完成了。

51 楼 andot 2009-02-21  

fjlyxx 写道

这些不确定的因素要求SOA的平台的健壮性,网络等服务的异常是很容易抓取的 问题在于碰见这些情况的时候  你的流程的走向怎么重新定义 ,重试机制怎么定义, 这是一个策略定义的问题,本来问题不复杂如果碰上多变的业务需求问题就复杂了

这些问题都是跟业务层紧密相关的，如果把它放到业务层去思考，你就会有一个好的解决办法（就是上面我提到的指导原则）。而如果试图把它放到数据交换层来处理，就会把简单的事情复杂化。数据交换层只负责数据交换，业务的完整性则由业务层去保证。

fjlyxx 写道

还有ESB总线的热切换,监控应用的异常监控,异常信息推送到其他ESB等都是在这里考虑的问题了.

这部分放到部署、构架和管理阶段去思考，思路就会更清晰。比如服务的切换，同样可以通过 DNS 的切换来完成，而无需什么 ESB 来做，因为你也不能保证你的 ESB 不会宕掉，如果你的 ESB 本身宕掉谁来切换它呢。

监控说白了就是一个日志问题，只要在你系统设计时，有良好的错误日志记录，并有一个专门的异常日志分析器的话，根据日志就可以完成这些工作。而指望一个特定实现的 ESB 去管理不同异构系统的异常也是不现实的，同样是将简单问题复杂化。

SOA 设计思想最重要的就是解耦，而 ESB 却想把所有功能都集中于一处解决反而离解耦这个思想有点背道而驰了。

fjlyxx 写道

对于SOA网络这块,通信数据的方式无非就是 推 拉 半推半拉  ,你不可能我一个SOA的流程请求就要占用一个和ESB的长连接, 如果我这个流程请求的流程生命周期是1小时 那么是否这个连接就要占用1小时呢? SOA平台内的通信机制不应该是请求就等待连接的模式  必须要有握手协议  先请求一个令牌 再发送流程调用内容 再去获取结果(当然也可以由SOA平台推给你)
我说的不确定因素 是说SOA平台内要怎么去架构一个很好的分布式的异常处理机制和监控机制.

至于调用时间长的，你可以采用异步调用方式来解决，PHPRPC 是支持异步调用的，所以这个不是问题。另外，你说的握手啊、传令牌啊、然后再传数据这样的事情，只要分3次来调用3个相关服务就可以了。也就是说用 PHPRPC 本身来解决这个问题就可以了。

在做 SOA 时，最重要的思想就是什么部分该做什么要分清，业务层的事让业务层去做，数据转换层的事让数据转换层去做，数据传输层的事就让数据传输层去做……，只有这样才能充分解耦，这样再构建 SOA 系统时也就不会有那么多疑惑了。而如果一锅端的希望把所有问题放在一起解决（ESB 的做法），就会让人有种复杂到无法实现或者难以实现的感觉了。

50 楼 zhaozhongwei 2009-02-21  

楼主，你头像是你的姑娘吗？很漂亮很可爱啊~~

49 楼 bonny 2009-02-21  

andot 写道

bonny 写道

引用

现有用于实现 SOA 的技术在忽悠，庞大复杂低效（还要在原本就很低效的各个协议之间转来转去），

现有ESB产品的确是庞大而且低效。经常在各个协议之间转换。

但是这个是没办法的事情，有的客户需要http，有的需要mq，有的需要webservice。。。。
另外还有消息语意的转换，服务整合。请问PHPrpc能解决这些ESB已经解决的问题么？

你批评这些毫无道理

是啊，你说的那些问题在我的另一篇独立出来的回复中也提到了，比如“有的客户需要http，有的需要mq，有的需要webservice。。。。”这种事，但是这些问题是怎么造成的呢？ESB 从来不考虑这些，ESB 只考虑用于需要什么我们就做什么。而没有去深究，客户为什么需要这些，客户需要这些背后的目的是什么？

而客户之所以要这样做的原因，就是因为之前还没有一个技术可以在各个领域都可以以无差别的方式方便的进行数据交换。如果有这样的技术，你认为客户还会舍近求远吗？还会愿意花更多的钱做更低效的事吗？当然不会！而 PHPRPC 就是这样的一种技术，让客户在也不需要绕这些弯路，只要所有的服务都以 PHPRPC 方式发布，那么就可以在任何环境下被调用。而且更改这种发布方式还及其的方便，可以以很低的成本就能够完成。那么请问 PHPRPC 是不是已经解决了最最主要的问题了呢？

我这些讨论都是从技术角度出发的，不能算是口水。呵呵。

我们不可能去改造客户，不可能去要求客户去改造已经有的投资，或者丢弃已经有的投资。纸上谈兵很简单，可是真正作起来很难。

无差别数据交换，多好的梦想啊。sun说：write once，use anywhere，多好的梦想啊，成本不就是个小小的jvm么？你考虑过有多难么？

真正去一个经常去和客户打交道的公司，尤其是弱势的乙方，你就知道，一个美好的概念，即使是正确的，为客户省钱的，要他们接受是多么难。

能在保护既有投资，最佳是不变动的情况下的技术，是最好的。而不是高效什么的，那是程序员的想法。尤其硬件不值钱的情况下。对很多老板，宁愿花1kw买硬件提速，也不愿意在软件上作一点点改动。

你自己去考虑去吧。不要让客户适应你，你去适应客户。


话再说回来，ESB在协议发布这个环节上，没有什么问题。他的协议发布是可插拔的，如果有一天PHPRPC协议主流了，我想ESB服务被发布成PHPrpc节点也肯定会有的。

问题是esb内部要进行语义转换和服务整合，暂时主流都是用xml格式的数据，不知道phprpc数据结构在内部解析的时候高效么？数据整合的时候高效么？直观么？从内部数据发布为服务的时候，高效么？

48 楼 fjlyxx 2009-02-21  

andot 写道

fjlyxx 写道

个人觉得SOA中碰见的问题大多是因为以下几点引起的

第一 压力
第二 千变万化的服务提供方式
第三 分布式
第四 不确定因素 比如网络阻塞   服务非正常停止
第五 规范化  原来应用的发展历史对SOA平台是有影响的

但是以上这些技术难道 并不是没有办法解决的  已经有很多成功的解决案例  但是不得不承认现在很多公司打着SOA的旗号在忽悠客户  做一个SOA平台需要比较大的投入

SOA涉及的技术领域比较广泛,我觉得单靠PHPRPC 是不能满足需求的.

下面我就来帮你解决上面你遇到的这五个问题：

引用

第五 规范化  原来应用的发展历史对SOA平台是有影响的

这就是一个过渡问题，如果要让一个原有系统过渡到一个利用新技术构建的系统要花费很大的代价的话，自然会成为一个很大的问题。而 PHPRPC 充分的考虑了这点，因此，当你将一个原有系统用 PHPRPC 重新构建时，你会发现你几乎不需要对你的原有系统做什么更改，你原有的业务逻辑层可以直接使用 PHPRPC 来发布成服务。而且不仅适用于 Java，同样适用于其它语言构建的系统，例如 PHP、.NET、Ruby、Python 甚至 ASP 等。对其它技术来说（包括 Web Service），这点确实很难做到。这也是 PHPRPC 的最大亮点之一。

综上所述，PHPRPC 解决了 SOA 领域对于以前大多数技术可能会遇到的问题。因此，利用 PHPRPC 构架 SOA 系统是非常合适的选择。

这个规范化 不是服务发布方式不同引起的, 这么和你说一个很简单的例子  比如A B 两个服务  A用1表示性别中的男  0表示性别中的女 B中用0表示男 1表示女  这样的话 你可以在流程脚本中进行指明 或者由 请求方和服务方进行约定等等方式去解决这个问题  但是这样就会让SOA平台流程处理,或请求方开发受很大的影响. 这个例子只是SOA规范中比较不紧要的一个例子. 再则如果我有两个SOA平台  那么我又如果应该在这两个SOA平台间进行通信调用流程能, 不是所以的SOA平台的流程都是BPEL的规范的.SOA的规范其实已经影响了SOA的发展.

47 楼 andot 2009-02-21  

fjlyxx 写道

SOA平台内部标准的定义是必然的,就看你怎么选择了  我所说的 千变万化的服务提供方式 是指 服务提供方 有可能是暴露数据库 有可能是WS接口 有可能是文件 邮件 等等  不管怎么说碰到这些 都必须经过改照让他能够被平台识别调用等,这些工作占SOA工作中很大的一个比重.

明白，现在的 SOA 平台内部因为希望什么都可以包含，比如你说的服务提供方“有可能是暴露数据库 有可能是WS接口 有可能是文件 邮件 等等”这些都要包含进去，因此在这个基础上定义一个 SOA 平台内部标准就会很大很复杂，ESB 也就成了一个必然且必须的东西。

但是我们如果能够做到将服务提供方暴露的接口统一，都统一成 PHPRPC 的接口方式，那么这个问题也就不存在了。可能你会说，服务提供方如果是我们自己的话，当然这样做没问题，但是如果我们是使用别人提供的接口，不能改变怎么办？这个问题在之前使用 PHPRPC 的一些案例中也遇到过，而解决方法很简单，只要用最适合调用那个接口的语言写一个协议转换代理就可以了，最终暴露的是一个 PHPRPC 接口，而这个 PHPRPC 服务是通过调用原来的其他类型的接口服务完成的。这个协议转换代理相当于 ESB 中做协议转换的那部分功能，但是因为是专用的，而且编写相当简单，因此，不管是效率还是灵活性上来说都比用一种特定语言实现的 ESB 要好得多。

46 楼 fjlyxx 2009-02-21  

andot 写道

fjlyxx 写道

个人觉得SOA中碰见的问题大多是因为以下几点引起的

第一 压力
第二 千变万化的服务提供方式
第三 分布式
第四 不确定因素 比如网络阻塞   服务非正常停止
第五 规范化  原来应用的发展历史对SOA平台是有影响的

但是以上这些技术难道 并不是没有办法解决的  已经有很多成功的解决案例  但是不得不承认现在很多公司打着SOA的旗号在忽悠客户  做一个SOA平台需要比较大的投入

SOA涉及的技术领域比较广泛,我觉得单靠PHPRPC 是不能满足需求的.

下面我就来帮你解决上面你遇到的这五个问题：

引用

第四 不确定因素 比如网络阻塞   服务非正常停止

这个问题在任何分布式系统中都会遇到，但是如果在构建分布式系统时，你能够清楚的认识到这一点，那么它就不是问题。有人（甚至是专家）会说 RPC 方式隐藏了网络通讯的细节，以至于让人们忽略了网络调用和本地调用之间的区别，我觉得这个说法是错的。如果说隐藏网络通讯细节的话，这个问题应该归咎到分布式对象模型的头上，而不是 RPC 的头上，只有在分布式对象模型中，程序员才无法分清一个操作是否要跨网络（如果你不明白，建议补充一下对分布式对象模型的一些知识，最好是学一些关于分布式对象模型的一些具体技术，在对这些具体技术有所实践后，你应该明白我说的是什么）而在 RPC 中，任何一个远程调用都是跨网络的，这一点是可以很清楚的知道的。

另外一点，就是 RPC 调用只有两个结果，要么成功，要么不成功。当然你还可以分得更细，可以分三种，一种是是调用成功后，客户端得到了结果；第二种是调用成功后，客户端还没有得到结果，但网络中断了，客户端认为没有成功，而实际上服务器端已经成功执行了调用；第三种是调用开始后，客户端请求还未完全到达服务器，网络中断了，这时服务器没有执行调用，也就是不成功，客户端也自然收到没有调用成功的消息。在 PHPRPC 调用中（其它的 RPC 协议我不能保证）不存在这种情况，那就是客户请求一边发送，服务器就一边执行，所以，你不用担心服务器会在执行一部分调用后失败的情况，这种情况在 PHPRPC 中是不存在的。所以，现在问题简单了，你只要遵循下面一套指导原则，对于网络的不确定因素就能很好的面对和处理了。

指导原则很简单，那就是把服务分为两类，一类是幂等性操作，一类是非幂等性操作。当执行幂等性远程过程调用操作时，网络发生故障中断并再次恢复后，只需重发调用即可。对于非幂等性操作，你可以为它配一个查询执行是否成功的幂等性操作，在正常情况下，我们不需要使用这个查询执行是否成功的幂等性操作，但是当执行非幂等性远程过程调用操作时，网络故障中断并再次恢复后，我们首先要执行这个查询执行是否成功的幂等性操作，然后根据它的返回的状态来决定是否重发非幂等性远程过程调用操作。这样就可以保证幂等性操作至少执行一次，非幂等性操作仅执行一次的要求了。

这个指导原则不仅适用于用 PHPRPC 构建的系统，同样适用于其它可以将执行调用结果分为以上三类的 RPC 服务，例如 Web Service。但是不适用于基于分布式对象模型构建的系统，因为在这样的系统中，你无法弄清到底哪个调用触发了网络通讯。

这些不确定的因素要求SOA的平台的健壮性,网络等服务的异常是很容易抓取的 问题在于碰见这些情况的时候  你的流程的走向怎么重新定义 ,重试机制怎么定义, 这是一个策略定义的问题,本来问题不复杂如果碰上多变的业务需求问题就复杂了. 还有ESB总线的热切换,监控应用的异常监控,异常信息推送到其他ESB等都是在这里考虑的问题了.

对于SOA网络这块,通信数据的方式无非就是 推 拉 半推半拉  ,你不可能我一个SOA的流程请求就要占用一个和ESB的长连接, 如果我这个流程请求的流程生命周期是1小时 那么是否这个连接就要占用1小时呢? SOA平台内的通信机制不应该是请求就等待连接的模式  必须要有握手协议  先请求一个令牌 再发送流程调用内容 再去获取结果(当然也可以由SOA平台推给你)
我说的不确定因素 是说SOA平台内要怎么去架构一个很好的分布式的异常处理机制和监控机制.

45 楼 andot 2009-02-21  

fjlyxx 写道

谢谢你的帮助

第一压力问题,我说的恰恰是ESB的压力 而不是服务器本身的压力.这个问题应该是水位保护去解决  不能通过部署去解决  每一个ESB上应该都有自己挂接的接入应用 和服务  这个不能靠要求客户去增加服务器来解决问题的  在实际应用中ESB不是一个的  ESB应该是分布式的  如果你用开源的第三方ESB 那有可能出现只有一个ESB的情况 但是这个是不实际的  实际应用中只有 资源管理应用,流程管理应用,监控应用等辅助应用是一个的吧.

你这么说我就明白很多了。因为在使用 PHPRPC 之后，可以彻底抛弃了 ESB，因此也就没有 ESB 压力的问题了。

44 楼 andot 2009-02-21  

bonny 写道

引用

现有用于实现 SOA 的技术在忽悠，庞大复杂低效（还要在原本就很低效的各个协议之间转来转去），

现有ESB产品的确是庞大而且低效。经常在各个协议之间转换。

但是这个是没办法的事情，有的客户需要http，有的需要mq，有的需要webservice。。。。
另外还有消息语意的转换，服务整合。请问PHPrpc能解决这些ESB已经解决的问题么？

你批评这些毫无道理

是啊，你说的那些问题在我的另一篇独立出来的回复中也提到了，比如“有的客户需要http，有的需要mq，有的需要webservice。。。。”这种事，但是这些问题是怎么造成的呢？ESB 从来不考虑这些，ESB 只考虑用于需要什么我们就做什么。而没有去深究，客户为什么需要这些，客户需要这些背后的目的是什么？

而客户之所以要这样做的原因，就是因为之前还没有一个技术可以在各个领域都可以以无差别的方式方便的进行数据交换。如果有这样的技术，你认为客户还会舍近求远吗？还会愿意花更多的钱做更低效的事吗？当然不会！而 PHPRPC 就是这样的一种技术，让客户在也不需要绕这些弯路，只要所有的服务都以 PHPRPC 方式发布，那么就可以在任何环境下被调用。而且更改这种发布方式还及其的方便，可以以很低的成本就能够完成。那么请问 PHPRPC 是不是已经解决了最最主要的问题了呢？

我这些讨论都是从技术角度出发的，不能算是口水。呵呵。