“为什么我们需要面向服务？”回答很简单：可伸缩性、维护性、互操作性和灵活性。过去，分布式组件技术像COM紧紧地把所有的组件绑定到一起。最低限度上，这些分布式技术必须分享公共类型系统，并且常常是一个运行时。有了这些依赖，升级和软件升级变得复杂、费时和费力的。面向服务的应用系统，恰恰相反，不需要相同类型的依赖，因此显示出更加适合企业精算需求的行为。
版本升级
应用系统的需求会随着时间的变化而变化。这个问题从计算机出现的时候就一只存在，而且并没有任何迹象表明这个行为会在将来减慢。开发者、架构师和项目经理已经付出了巨大的努力到软件开发过程的中去，希望能够调节和控制应用系统变化的数量和步骤。在整个应用系统的声明周期里，开发过程里的一些设想将会证明是徒劳的。某些情况下，最后集成应用系统的改变将会导致一系列级联的其它应用系统部分的改变。自治的、边界清晰的、基于契约的面向服务的应用提供了几层封装来缓冲这些系统部分版本升级带来的影响。在面向服务的应用系统里，消息发送者和接收者之间的唯一协定就是契约。两者都可以根据自己的期望自由改变自己的实现，只要保持契约不变。这些同样适用于组件架构，面向服务契约的普遍自然属性把发送者和接收者从实现中解耦，因此使得版本升级周期变短。面向服务并没有去掉了一个好的版本化升级过程的需求。
负载均衡
每个应用都有一些瓶颈，优势这些瓶颈可能阻止一个应用为了增加吞吐量需求而进行的扩展。
平台随时改变
平台变化，随着时间的过去，有时候会很快。这个确实在任何厂商的平台里存在，像补丁和服务包，并且平台的新版本经常发布。对于分布式组件，会经常有一个平台组件运行时的依赖。比如，一个系统架构师如何知道一个DCOM组件能够在Microsoft Windows Server 2000、Windows Professional 2000、 Windows XP或者 Windows Server 2003上行为一致？因为一个DCOM组件依赖于每个系统的组件运行时，许多测试场景看起来无中生有。当你开始思考测试每个可能的配置、服务包和热补丁的时候，你也许会紧张的直流鼻血。当应用变为面向服务的时候许多这些问题消失了。这个很大程度上因为使用了平台独立的XML语法来表示消息契约。这个契约把发送者和接受者解耦。发送者就是遵守契约产生和发送消息，而接受者就是接受和处理消息。不需要序列化平台规范到消息里，所以终结点可以不受他们关注的平台版本更新的影响。进一步说，测试更简单，因为终结点必须测试的只是一个清晰的服务边界。
基于内容的路由
过去，面向服务的消息在面临路由场景的时候一直非常困难。为了演示，围绕我们的订单处理例子我们可以建立一些商业规则：
- 订单可以订购新商品和维修现有商品。
- 新商品的订单会发送给制造管理系统
- 维修订单会发送到维修管理系统
- 两个订单，在发送给最终目标系统以前必须发送到财务系统和调度系统。
面向服务的消息应用系统非常好地适应了这些类型的需求。本质上，路由的信息可以放置到消息头里，被终结点用来判断消息路径。
端到端的安全
许多分布式系统在传输级别通过点对点方式保证通信安全。传输是安全的，但是被传输的数据在传输结束以后也许就不安全了。日志文件和其它审核机制经常包含传输时保护的信息，结果，他们经常成为许多安全攻击的目标。可以使用标准的XML安全机制通过面向服务的消息来提供端到端的安全。即使消息被持久化到日志文件或者被破解攻击，如果消息使用标准的XML安全机制加密，消息里的数据是可以保证机密的。
互操作性
当一个初始发送者发送消息给一个最终接受者时，初始发送者不需要依赖最终接受者运行的平台。如你看到的二进制消息编码，没有恒定不变的情况。一些消息格式能够引入平台依赖，但是这个是选择的问题。在纯正意义上，面向服务的应用系统式平台独立的。平台独立是XML语法表述消息契约的普遍本性。真的可能（不是理论上）是发送一个消息给一个终结点而不知道它所运行的平台。这与生意人和管理人员产生了共鸣，因为它不需要用一个单一平台的一个同质应用的集合来取代现有的应用系统。