SOA的本质在于它用统一的、开发的标准，将分布的、异构的系统集成在一起，实现系统之间的互操作。
其实自1990年代中后期出现了互联网以后，相当数量的各类技术频繁的出现，以解决分布异构系统的集成问题。
比如最初的CORBA，当时火的一塌糊涂，记得当时我还是研究生，还专门跑到书店去买了一本厚厚的大部头，妄想如同学习C++一样去征服CORBA。为此还煞费苦心的向导师弄来了另外一台机器，搭起了简易的试验平台。但后来由于CORBA实在是太复杂，而且当时的ICE研究中心基本上没有恰当的应用背景，于是也是不了了之。
CORBA的劣势在于它的集成的“粒度”太小：函数级别的互操作。另外，它也仅能应用于Intranet环境下。
再比如后来的J2EE，.Net等，大同小异，但都不被看作完美的解决方案。
接着出现了XML，我始终把它看作改变集成技术的重要里程碑，因为在之前，需要在异构分布系统之间交换的数据，要么通过直接的函数调用，要么通过公共的数据库（或黑板），要么通过非结构化的文档（如.doc）。而XML出现之后，在系统之间同步而非函数调用的集成，成为了可能。于是出现了SOAP，出现了UDDI，出现了WSDL，以至于后来的任何有关集成的标准，都是用XML写成的。诸如ebXML，BPEL4WS等最先进的标准，哪个不是？
所以我觉得SGML/HTML/XML的发明者，应该获得Turing Awards。（也许他们早就拿到了这个奖？）
SOA解决了其他技术不能解决的各类问题——完美的方案。它最大的优势在于将Internet这个无边的概念消除了，使系统分析与设计人员不必考虑各系统之间的巨大边界，就如同开发桌面程序一样开发企业间应用程序。如果两个构件都部属在同一个企业，那好，用J2EE已经是很cost-effective的技术了；如果两个构件分属于两个子公司而它们又分布在太平洋两岸，那好，用SOA吧：把两个构件包装为两个服务，然后将两个服务连接在一起，OK。
记住，任何开发技术/工具都要遵循的基本原则就是：弄清楚什么地方该用什么技术，而不是事无巨细都要麻烦SOA老兄。
从今天开始，你们不得不进入细致的思考阶段，而不是仅仅美化你们的简历。我们将共同来思考，在竞赛给定的场景下，该用SOA做点什么？