在与客户的多次接触中，需要建立一套基本的SOA原则。以下章节介绍了面向服务的架构（SOA）所需要遵循的基本准则，是一套针对SOA相关讨论的框架性意见。
1）清晰的边界
在调用一个服务来完成它提供的功能的时候，需要将服务所需的所有信息传递过去。所有对服务的访问都应通过其对外公开的接口，不应当允许某个服务存在任何隐含的假设。通常情况下，服务的调用应该不依赖共享的上下文，而应该设计成无状态的。服务所暴露的接口通过契约规定了它的功能性和非功能性的作用和特征。服务的调用是一个有业务意义的动作，可能是十分消耗资源的，并引入一系列不同于本地调用或远程过程的异常。服务调用是不同于普通远程过程调用的。
2）共享契约和Schema，而不是Class类
根据服务的描述（某种契约），服务的消费者和提供者应该拥有消费或提供服务所需要的所有东西。根据松耦合原则，服务的提供者不应该依赖消费者在它自己环境下所能提供的代码重用能力，因为服务可能被用在不同的开发时和运行时环境中。该原则在很大程度上限制了可以在SOA中交换的数据类型。理想的数据格式是使用可以被一个或多个Schema所验证的XML文档，因为几乎所有可以想象到的语言环境都支持XML.。
3）策略驱动
要跟一个服务交互，必须满足两组正交的需求：
1）服务提供者的功能、语法和语义必须满足服务消费者的需求；
2）技术能力和技术需求必须相符。
为了支持各式各样不同设备和不同能力的服务消费者来访问服务，SOA工具集必须引入某种策略机制。服务的功能性特征是由它们的接口来描述，而这些非功能性能力和需求则是用策略文件来指定的。
4）自治
跟“清晰的边界”相关的一条准则是，一个服务应该是自治的，即它跟外界的唯一关系（至少从SOA的角度来看）是通过它的接口。在某些情况下，一个服务还必须能够切换它的运行期环境。
5）用格式连接，而不是用程序API
服务都支持使用特定的连接格式。这条原则和“清晰的边界”原则关系非常大，不过是引入了一个新的角度：尽最大可能让服务可以被访问（从而达到长期的可用性），即只要遵循服务所定义的交互策略，应该可以从任何平台上通过符合服务接口定义的消息的交互来访问一个服务。
6）面向文档
在服务交互的时候，数据是通过文档传递的，文档是显式建模的树状容器。在上面提到过的自描述性是面向文档的一个重要特征。理想状况下的文档应该是按照真实世界的文档来建模的，如采购单、发票或帐户声明。设计良好的文档在特定问题域的上下文环境中很有帮助，即它应该被一个或多个服务所采用。
7）松耦合
大多数SOA倡导者都认为松耦合是一个重要的概念。但不幸的是，对于一个系统“松耦合”特性的认定却有很多不同的选项。认定一个系统是松耦合还是紧耦合的，根据具体的需求和上下文可以有许多维度，从某些维度来看可能是松耦合，但是从另一些维度来看又可能那是紧耦合。
8）兼容工业标准
在准备实施SOA的时候一条关键的原则，就是依赖标准而不是依赖特定的API。从技术层面上来说，标准包括数据格式、元信息、传输协议、以及业务级别的文档格式（如UBL）。
9）厂商无关
在任何架构准则中，都不应该依赖某个特定厂商的产品。在将抽象概念转化到实际可运行的系统的过程中，不可避免地要选用某个特定的产品，不论是商业的或开源的软件。但是不应该在架构一级上就先入为主地考虑到这些决定，这就是说要尽量考虑到标准的互可操作性和可移植性。这样一来，参与者可以使用支持标准的任何技术来构建，而不用受制于厂商的产品路线。
10）元数据驱动
在整个SOA架构中，所有的元信息必须以恰当的方式存储在某个地方，使得它们可以同时在设计时和运行时被发现、获取和解释。这些元信息包括服务接口的描述、参与者、服务终端（endpoint）、绑定信息（bingdings）、组织的结构和职责、文档类型和schema、消费者-提供者关系，等等。这些元信息的使用应该利用代码生成或解释的方式尽可能地自动化，并成为服务和参与者生命周期中的一部分。 | 
