我为客户审查基于.NET平台的新系统的架构设计时，发现它们大多采用传统两层或三层方式来创建新应用程序。但讨论其中哪些系统组件要在未来的项目中重用时，除了少数几个数据表或存储过程，他们很少能指出别的什么。由于必须创建特定的系统，所以他们创建的组件接口必须同这些系统所强加的事务需求高度耦合。而且他们找不到任何办法既能满足这些需求，又不至于显著影响性能。但当我们换用全新的思路，着眼于应用程序提供的服务，而不是着眼于提供服务所需的组件时，“面向服务的架构”（Services-Oriented Architecture，SOA）的优势就昭然若揭了。
在SOA中，结构师要尝试由单个实体来提供一系列特定的任务。该实体接收服务请求并返回处理结果；或返回因尝试失败而导致的错误。这些服务，以及规定它们应如何组合来构成一个完整应用程序的指导原则，就构成了一个SOA。下例解释SOA和基于组件的架构的关键区别。
在基于组件的架构中，组件通常封装了特定实体以及对其进行操作的事务处理规则。例如，采用基于组件的架构，一个发票系统可能包括一个Customer（客户）组件，一个Invoice（发票）组件，以及一个Products（产品）组件。开发者要创建这些组件，与底层实体（Customer、Invoice和Products）紧密配合，并封装预期的实体行为。
在这个例子中，AddCustomer(…)允许添加一名客户，InvoiceTotal(1001)返回编号为1001的那张发票的总金额。由于组件是单独实现的，所以隐藏了执行上述操作的方法。换言之，Invoice组件的用户不知道InvoiceHeader表是否含有一个TotalInvoice列，或者组件是否要遍历InvoiceLineItems表中的各个条目来生成发票总金额。在基于组件的系统中，还存在着多层组件，这些组件要使用某种事务处理实体，在系统中相互调用和传输数据。基于组件的系统从后端数据源访问共享数据，而这些数据源可能由、也可能不由它们独占性地管理。
但在SOA中，功能不是根据实体和组件层来划分的。相反，要先制定对一系列实体的运作进行管理所需的全部服务，再考察如何来实现这些服务。例如，一个客户服务也许要响应其他任何系统或服务（它们是对客户信息进行检查或处理所需的）的请求。客户服务可处理添加一名客户的请求，检查其信用历史，或指出未支付的发票。这个客户服务拥有和它管理的客户直接相关的所有数据，并能代表发出调用的实体来执行其他服务查询，以提供统一的客户服务视图。
一个用户界面程序可向客户服务发送一个服务请求来查询未支付的发票，并从发票服务获得相关的信息。但是，用户不必直接调用发票服务。相反，通过身份验证的用户请求会自动传给发票服务，并由服务为用户提供信息。
