SOA没在忽悠

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

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


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

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

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


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

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

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

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

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

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



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



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

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

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

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

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



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

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

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

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

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

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

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




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

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

要说效率高。

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

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

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

快吐了我。

你要明白，对大企业的发展和信息整合而言。协议转换是必须的。
因为所谓的协议包括两个层面的意思，
一，是公用的标准的协议，比如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来推销自己。