SOA是英文Service-Oriented Architecture，即面向服务架构的缩写.
SOA是一种范式，目的是增强灵活性。SOA很适宜处理复杂的分布式系统。
SOA方法接受异质（不同的平台，不同的编程语言，不同的中间件等）。SOA正是依靠对异质性的承认和支持来处理大系统的。
SOA也可以被视为一种信息系统架构风格，它使结合松耦合、互操作的服务来创建应用成为可能。
SOA的关键技术概念：
（1）、服务：就是业务功能的IT体现。
（2）、互操作性
（3）、松耦合：目标有灵活性、可伸缩性、容错。松耦合是表达最小化依赖的概念。当依赖最小化时，改动造成的影响也被最小化了。最小化依赖有助于容错和灵活性。松耦合还带来了可伸缩性，避免瓶颈。
ESB的关键特性是它使你能在异质系统间进行服务调用。它的职责包括数据转化、（智能）路由、处理安全和可靠性、服务管理、监测，以及日志。
理解、监管、管理支持和钻研是SOA成功的关键因素。
实践中，对服务的描述往往从定义良好的接口开始。服务自足（独立的、自主的、自给自足的）是个设计目标。服务是种抽象，向消费者隐藏了实现细节。因此，在供应者和消费者之间用一个服务调用传输所有必需的数据，比起用多个服务调用处理同等数量的数据，通常说来是更好的办法。粗粒度也有助于分离服务供应者的内部数据结构和外部接口。怎么才能确定粒度够“粗”呢？可能是根据需求定义每个接口的粒度。同时还需要考虑性能问题。
当讨论异步性时，人们往往不是在说同一件事情。例如，从消费者的角度看，异步通信可能指的是消费者不用阻塞自己来等待答复，然而，从基础设施（ESB）的角度来看，异步通信可能指的是用来解耦消费者和供应者的消息队列。
服务分类：
（1）、基本服务：基础的SOA，只有一个基本服务层。每个基本服务提供一个基本的业务功能。
分为基本数据服务和基本逻辑服务。
基本数据服务从一个后端系统读取数据或者向其写入数据，通常，每一个这类服务都代表后端的一个基础业务操作，对外封装了平台相关部分及实现细节，这些服务应该提供一些最低限度的业务功能。如创建一个新客户；改变客户的地址；返回客户的信息等。基本服务应该具备ACID特性（原子性，一致性，隔离性，持久性）。
基础逻辑服务代表基础业务规则。这些服务通常处理一些输入数据，然后返回相应结果。基础逻辑服务是少数。典型的有：定义产品目录和价格列表；返回某年是否是闰年；定义改变客户合同的规则等等。
（2）、组合服务：联合的SOA，除了基本服务外，还有个组合服务层。
组合服务是典型的访问多个后端的服务，因此，组合服务由许多基本服务组成。一个典型的例子是在多个后端上更新冗余数据的服务。如对于客户的数据，一个企业可能有多个后端系统维护相同的客户数据，可以提供一个服务，在所有的后端上修改客户数据并保证数据的一致性。（这与基本服务不同，基本服务只负责一个后端的一致性）。对于组合服务提出了事务安全的问题，要么同时成功，如果有一个失败，其他成功的必须回滚。
用于一个后端的组合服务，组合服务也可能是对现有服务在某些方面进行映射或改装。这些服务可以为某个服务提供不同的接口。典型的应用是提供向下兼容性或者把服务映射到所有要求的接口上。
（3）、流程服务：流程使能的SOA，它有用于流程服务的第三层。同时具备基本服务和组合服务。代表了长期的工作流或业务流程。业务流程服务代表了“宏流”，它是可（被人工干预）中断的长期运行的活动（服务）流。
和基本服务、组合服务不同，流程服务通常有一个状态，该状态在多个调用之间保持稳定。流程服务典型的例子是购物车服务，该服务的状态为购物车的内容，也许还掺杂着点客户的数据，这样一来，客户的订单就可以在多个会话之间被保持和处理。根据具体的设计，流程最终可以在客户订单敲定时结束，或者甚至是在所订购商品发货时结束。
流程服务要考虑失效备援，即当包含目前状态的一个系统失败时，是否以及如何保持流程状态。长期运行的流程服务往往要求更加健壮，质量更好。
在处理流程服务时，你必须作出一个重大设计决策：业务的状态是保持在后端，还是保持在服务本身当中？该问题决定着对你的业务而言，流程状态的相关性有多大。如果流程数据成了“法律数据”（消费者或调用者被分配了一个唯一的流程ID（订单号码、记账号码等），持久化存储，能在以后的某个时间点引用该流程），在平常的后端管理状态也许更合适。如果流程数据只是些持久数据，与你的业务没有本质上的关联，则使用有状态服务即可。
服务使用不同的消息交换模式（MEP），这些消息交换模式定义了完成特定服务操作所需发送的消息的次序、方向、个数。
基本MEP是请求/应答和单程，还有请求/回调（异步或非阻塞的请求/应答）、发布/订阅模式等。
对SOA来说，最重要的消息交换模式是请求/应答，而协议层和API层的MEP最重要。
在请求/应答模式中，消费者向供应者发出一个请求消息，等待供应者发出应答消息，就像远程过程调用RPC，直到应答到达之前，消费者都被阻塞。这种模式优点是代码简单，缺点是在等待应答时，无法做任何其他事情。
发布/订阅模式，在SOA基础设施中，通常只见到这个模式的第二部分：通知。订阅可能是业务流程的一部分，体现到服务设计中。
事件是一种特殊类型的单程消息。事件带来事件驱动的架构EDA，可以被认为是一种特殊情况的SOA或是对SOA的补充。
服务设计阶段通常生成服务接口的规格说明书，这个接口包括语义和非功能特性，也可能是服务供应乾和服务消费者之间的一个或多个契约。因此，在服务的实现和测试阶段，任何设计的变化都可能影响其他系统。
一旦服务进入生产，它就会被用到关键业务的场景和业务流程中。实际上，让生产中的服务保持稳定是一个最佳实践。任何时候，如果需要修改生产中的服务的行为，你应该做的是引入与服务的老版本相互独立的新服务或服务的新版本。
撤销是服务生命周期的最后一步，要保持系统可维护，重要的是防止使用中服务和服务版本的数量出现急剧膨胀，这意味着过时的服务和服务版本必须被逐步淘汰。
撤销分布式系统中的服务正确过程：
（1）、首先，把服务标记为过时（附上该用哪个服务代替的提示）。
（2）、然后，监控服务是否（及由谁）还在使用。要求有一些监控代码，通常它们是ESB的一部分。
（3）、如果服务还在继续使用，应该和相关的消费者联系，讨论出一个解决方案要。同时根据讨论结果，写出服务最终撤销的进度表。
服务版本问题：无需工作量的版本划分政策
SOA中服务版本的问题，最简单的方式是将现有服务的每个修改都当作是新的服务，可以简单地用相应的命名来体现，比如GetUserInfo_1(), GetUserInfo_2()......使用这种命名习惯，服务名字永远都包含两个部分：一部分指明服务干什么，另一部分指明版本号。
当服务被带入生产之后，在其上修复缺陷没有问题，但向后兼容的修改“应该”产生新的服务版本，并且，不兼容的变化“必须”产生出新版本。这样做带来的问题是生产线上会存在过多版本，可以通过规则约定线上同时存在的最多的服务版本数量，需要不时地让某些服务版本退出生产状态，这经常通过两个步骤来实现：
（1）、声明一个老服务版本过期。
（2）、撤销过时的服务。
服务版本问题：需要工作量的、领域驱动的版本划分
将不同的命名空间用于不同版本，对服务请求进行不同的路由等。
服务版本问题：数据类型版本划分
对于数据类型的版本，如后期增加属性。
作为服务消费者，让你的代码多多少少独立于所调用服务的版本划分是个好主意。你应该使用自己的数据类型，使用服务时，将自己的数据类型映射到服务的数据类型。
除了供应者和消费者，服务修改永远不应该影响任何其他东西。
服务的性能与安全
在可重用性和性能之间，可能存在一种取舍关系。
性能可能对服务的粒度有影响，其影响在两个方向上都存在：如果多个服务调用的开销过高，服务就倾向于变得更粗粒度；如果处理非必要数据的开销过高，服务就倾向于更细粒度些。另外，当服务变成了普适的银弹时，就应该认为粗粒度已经到达极限了。
SOA的安全需求
一、认证
认证与检验身份有关。对SOA来说，意味着找出谁在调用服务。
二、授权
授权与决定一个身份被允许干什么相关。对SOA来说，意味着检查调用者是否被允许调用服务，以及/或者是否被允许看到结果。
三、机密性
数据在传输或存储时是否保持机密性。对服务而言，意味着要保证当服务数据在供应者和消费者之间传递时，除了服务调用者之外，没有谁能看到服务数据。
四、完整性
保证数据不可能被篡改或伪造。
五、可用性
无法请求到服务，典型形式是拒绝服务DoS攻击。
六、记账
保持消费资源的记录，对SOA来说，意味着对用于管理、计划、计费，以及其他目的的服务调用进行跟踪。
七、审计
关键是评估某个安全概念及其应用，目的是改善它的可靠性。记录所有安全相关的信息，有助于分析安全漏洞或攻击。包括对所有安全相关的数据流进行监测、日志记录，以及跟踪。
什么是无状态服务？
从概念上，一个无状态服务是在不同服务调用之间不维持任何状态的服务，就是说，在服务调用结束后，要销毁所有为运行服务而临时创建的局部变量和对象。
什么是有状态服务？
一个有状态的服务，指的是在多个服务调用之间，可以保持状态的服务。
有状态服务的典型例子是购物车。
幂等性：在服务的上下文环境中，意味着对同一服务调用的多次递交/处理不会引发问题，即同一服务调用的多次请求只产生一次的效果。