SOA是一个服务的集合，这些服务事实上是一些为应用程序提供不同功能的类。这些类，或者说这些服务，是应用程序常用的基本构建模块。服务之间互不关联，可以独立操作也可以协作。创建独立的服务可以提高应用程序的可维护性，因为服务的优化甚至替换是不会影响系统的其他部分的。这种模块化也促进了各组件之间的松耦合，允许组件更好地复用。（在本章后面的部分还会深入讨论“耦合”这个概念。）
通常，服务有两种类型。
●应用程序无关服务：无关服务在提供服务时不需要了解应用程序的任何内容。没有针对服务所在的应用程序的特定业务规则，没有针对特定业务的数据操作，也没有引用需要这种服务类型知识的外部代码。
·应用程序无关服务的一个例子是将日志消息写入文本文件的类。不管应用程序的业务目的是什么，这种类可以应用于任何应用程序。logger类或服务的方法和属性不随应用程序改变，所以logger是与应用程序无关的。
·另一个例子是和Facebook交互的类。这种类按一般的方式建立，所以它不做任何修改就可以在其他应用程序中复用。有需要时，任何特定于应用程序的数据都可以传输到Facebook服务中去。
·应用程序无关服务也可以是类的集合，比如用户管理系统。不同的应用程序有相同的用户和安全信息，这种情况是很常见的。这些信息包括诸如用户登录时的用户名、密码和用户登录时赋予的安全角色。如果这个逻辑能够广泛地应用于不同的应用程序，那么它就是应用无关的。
●应用程序特定服务：这些服务需要了解其工作环境中的特定问题域知识。这意味着它们使用应用程序的特定数据，或是需要实现不适用于通用业务程序的规则。这些服务可以在同一公司的其他地方使用，但如果在一个完全不同的环境中，它们就无法使用。
·应用程序特定服务的一个例子是使用特定业务规则的类。假设你正在建设一个销售管理系统，任何可能超过10万美元的销售都必须获得销售经理的批准。这就是特定于应用程序的规则，所以所有使用这条规则的类都是特定于应用程序的。
当构建服务时，有可能会做成应用程序无关的，以提高可移植性。我们也会在不同的项目中使用这两种服务，以进一步确保它们的复用。应用程序无关服务并不普遍，但是引入它们是很有用的。在使用它们时要额外小心，不要和特定于业务的逻辑混在一起。
在后续的几个小节中，我们将会讲述SOA服务使用过程中需要遵循的几个基本准则。
