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,一个仍在进化的技术。。。。。。