SOA 是一种程序设计思想，其实早在远古时代（计算机史）它就已经出现了。无非就是把系统分解，将数据和业务逻辑部分尽量独立出来，然后以服务形式提供给另外的系统共用。

那时也有一些可以实现 SOA 的工具，比如 DCOM、CORBA 等，不过前者仅限于 Windows，后者又太复杂，而且也仅对 C/C++、Delphi、Java 这等语言有较好支持，而且也都是商业开发软件中才会包含，对于开源的脚本类语言来说支持很差甚至没有支持（因为太复杂了，不是什么人都可以实现的了的，能够把整个 CORBA 规范完整读下来，都需要很好的耐心，还不一定都能够完全理解）。之后互联网发展了，XML-RPC 出现了，XML-RPC 很简单，但是也太过简单（因为它只是一个 SOAP 的实验原型而已），简单的数据可以传输，复杂点的就没办法了，所以后来就发展成了 SOAP 这个名字简单实际却很复杂的怪物，尽管 SOAP 已经够复杂了，但它也不过仅仅是定义了数据格式，于是后来就又有了一堆 WS-* 的补充。这样就变得跟 CORBA 一样了，不再是什么人都能理解，什么人都能实现了，或者说除了大公司和大组织有这个能力外，其他人基本上没有这个能力介入。再之后人们突然想发现了宝一样，发现了几年前就被提出来的 REST，于是一堆号称 REST 的服务又出现了，这东西看上去简单，可是实际上却是把数据转换、传输等等问题全都扔给使用者来自行解决了。最后 REST 教父都把这些号称 REST 的服务给否定了。除了这些以外，当然还有其它的方案，比如 Hessian、ICE、Adobe 的基于 AMF3 的通信方案等等，这些不能不说是好的技术，但不是局限于某几种语言，就是局限于某个特定的应用范围。所以要搞 SOA 就需要在这些不同的协议和解决方案之间进行转换，这就出来了 ESB，到这里之后已经看上去很好很强大了。可是它真的可以解决问题吗？真的不是在制造新问题吗？当然它解决了一定的问题，可是同样也制造了更多新问题。能够在各种技术之间转换固然很好，可是本来要掌握这些很复杂的技术中的一种就已经是一件很困难的事了，还要几种都学，几种都要用，这是多大的挑战啊！还有一个问题就是这些协议中本来就有慢的要命的（比如基于 SOAP 的 Web Service），还要再加个转换的过程，那还有什么效率可言。所以，ESB 最后就变成了“哦，傻逼”！SOA 也就变成了听上去很美，做起来很难的东西。

可是实际上我们回过头来再想想，我们要 SOA 到底是想实现什么？不就是要将系统分解，然后异构重组吗？最后问题就这么简单，我们需要的不一定是基于 SOAP 的 Web Service，不一定是将各种协议都能进行转换的 ESB。我们需要的是一种能够在异构系统间可以有效的进行数据交换的技术，这样我们就已经可以构建 SOA 的系统了。别的技术我不敢说，至少目前 PHPRPC 做到了这一点，你不但可以在 Java、.NET 这些语言之间方便的交换数据，还可以跟 PHP、Ruby、Python、Perl 这些开源脚本语言中以同样的方式交换数据，还可以用 Delphi/BCB 来做 Windows 界面的前台，也可以用 JavaScript 做 Web 前台，还可以用 Flash/Flex/RIA/WPF/SilverLight 这些来做内容更丰富的前台，而所有这些前台都可以共享同一个后台，还不需要关心后台究竟用什么语言来实现。甚至手机上的 J2ME、.NET CF、Flash Lite 和手机浏览器的 JavaScript 都可以完美支持。有了 PHPRPC 之后，你就突然就有了这么多选择，甚至随着 PHPRPC 的发展，你还会有更多更多的选择，SOA 从现在开始就不再是遥不可及的梦了。