互联网上充斥着面向服务（SO）的对话，大部分会话都是抽象地描述为面向服务。这一章我们会一些不同的方法。下面一些章页，我们会站在需求的角度看一下面向服务。更具体地说，我们将看一下一般的消息应用和需要什么才能使他们运转。通过这个过程，我们将发掘几个理解面向服务必需的几个概念。本章的最后几段会给出面向服务的比较正式的定义，并且会讨论一下为什么当今世界里面向服务对于分布式计算意义重大。

　　如果你问10面向服务的专家去定义面向服务，你可能会得到10个不同的答案。如果你几年后再问他们一次，你可能得到另外一组不同的答案。这个不足为奇，当面向对象（OO）和组件驱动开发成为主流的时候，许多开发者也搞不清楚他们应该如何适应或者考虑让自己的流程设计展示符合新的架构模型。理解OO和组件架构需要关于应用系统设计在思想上根本的转变。这个过程有时非常痛苦，但是回报的确是强壮的设计、更好的代码复用、先进的应用功能、易于调试和短时间市场化。我的看法是，从组建驱动设计转向面向服务设计像从面向过程到面向对象的转变一样，需要思想上的根本转变。好消息是，面向服务设计的好处是可以提供更丰富的通信模式、松耦合的应用系统、改进的系统功能和兑现真正应用程序互操作性的承诺。因为互操作性的术语使用过多，这些说明是为了避免混淆。这本书里，互操作性指的是系统改变硬件、操作系统或者平台而不会影响其它的分布式场景里参与者的能力。

　　面向服务，不管现在与它的定义有关的混淆，它不是一个新的概念。它诞生于大型机统治的时代，并且最近已经在中间件里被接受。最近互操作性的倡议和富通信模式重新激起了面向对象的兴趣，并且正在使面向服务成为主流。可以想象随着面向服务更加广泛的实施，它的定义将会日益完善。
快速定义面向服务
简单地说，面向服务是一种分布式应用组件通过消息和契约实现松耦合的架构风格。面向服务的应用通过契约描述它们交互中使用的消息。这些契约必须使用一种语言描述并且格式能够被其它应用简单地理解，因此可以减少组件实现带来的依赖性。
注意，在描述面向服务概念的时候我没有提到厂商或者技术。所以这是一个超越厂商和技术边界的概念，在很大程度上，面向对象的也跨越了这些边界。在最初OO的概念形成时期，它非常容易混淆，我猜想面向服务也会有类似的情况。因此，我会首先通过一些列例子阐述面向服务的概念，避免和别的抽象概念一起定义一些抽象的概念。
理解消息
在面向服务的应用中，消息是通信的基本单位。因此，面向服务的应用通常被称为消息应用系统。在某一时刻，每个面向服务的应用系统都会发送或者接受消息。这个能够帮助你理解面向服务的消息很像你在Email系统里收到的信件一样。在邮件系统里，一个信件是抽象的实体：它可以包涵任何类型的信息，可以以不同的形式和大小存在，可以关联任何东西。同样，一个面向服务的消息也是一个抽象实体：它几乎可以包涵任何数据，可以使用许多不同的方式编码，并且可以关联到虚拟东西，甚至是其它消息。邮件的一些属性已经被广泛接受。例如，一封信件可以被某个人发送，邮寄给某个人，并且可能被某个人投递(某一时刻更多的是“可能”)。同样，一个面向服务的消息可以被计算机发送，发送给另一个计算机，并且可能由另外的计算机来投递。考虑某些喜欢死扣理论的书呆子，我必须澄清，与面向服务消息交互的实体不一定必须是计算机。理论上说，它们可以是信鸽，拉布拉多猎犬或者是狮虎。无论如何，这些与面向服务消息交互的实体被称作消息的参与者，并且在这本书里，一个消息参与者可以是一个计算机上的进程。