机构继续以服务的形式建立企业自动化逻辑，这就极大的需要增加服务在运行时间操作的可靠性和效率。在用大量可重用服务组合一项服务时，这个需求就更加重要了。

　　可重用服务和并行操作

　　重用是SOA的核心部分，其作用非常重要，一些与企业相关的SOA变化的战略目标都和其有直接联系，以便成功实现自动化逻辑的重用。因此，我们要保证交付的服务不仅拥有重用逻辑，同时在用于现实世界时，还能被重用。

　　总之，我们要增加重用的机会。每一个被划分为“重用”的服务能为潜在的大量客户程序所用。结构是可以预测的。随着时间的流逝，我们需要同样的服务来促进不同业务流程或服务的自动化，这个服务可能成为众多服务组合的一部分。

　　这最终翻译成大使用量、不可预测的使用方案和一个我们非常有兴趣准备的运行条件;并行存取的运行环境。当一个服务被两个或更多的服务用户同时访问时，就会产生服务实例。这些的发生很大程度上取决于负责运行服务的供应商运行时刻平台。

　　但是，为了构造基础服务逻辑以便方便并行存取的条件和其它和与依赖性相关的条件，我们需要通过几个重要的步骤来为服务的设计定型。

　　这涉及到两个设计原则，我们将在文章中简要介绍。

　　·服务是独立的
　　·服务是无状态的

　　如果创建一个使用某个特定服务的程序，我可能不知道或不关心有多少其他的人正在使用这项服务。我会想基于服务合同和辅助SLA里的内容，这个服务能做些什么。因此，我会依靠服务的性能来提供一个行为、实行性、和可靠性可预测层，不管其是否会被使用。

　　服务独立性

　　当涉及到分解时，服务定向带来许多不同的态度。在建立一个企业服务清单时，尤其需要强调将清单上的每个组件定位成一个构造块。

　　对于服务来说，要提供可靠可预测的性能，他们需要很大程度上控制基础资源。独立性代表其量度，这个原则强调单个服务拥需要有高度的个体独立性。

　　通过增加服务在执行环境的控制，我们减少了在企业里共享资源所要求的依赖性。尽管我们不能经常提供一个被封装的逻辑专有所属权的服务。我们主要关注的是在执行时间里不管逻辑代表什么，服务能够实现合理的控制。

　　因为衡量独立性的不同方法的存在，有助于将它们区别开。下面，我们单列出独立性的两个层次。

　　服务层面的独立性—服务间的界限清楚明晰，但是服务也可能共享基础资源。例如，一个封装旧环境的包装服务，它控制旧系统，但同时也和老用户共享资源。

　　纯粹独立性——服务拥有并控制基本逻辑。这是建立支持服务逻辑时最常见实例。很显然，一个含有纯粹独立服务的服务清单更令人向往。这不仅帮助我们处理伸展性问题，如并行存取条件，还能帮我们将服务定位的更可靠以应对在杠杆作用重用自动化逻辑时“单点故障”。但是它通常要求建立新的服务逻辑并需要特别部署。这就需要花费更多的时间和精力。

　　服务无状态性

　　独立性是IT最容易理解的一个方面，但状态信息的构成却不太透明。由于这个原因我们需要在讨论这个原则前，花点时间来定义状态管理。

　　状态指一件事物的特殊情况。一辆车在运动的状态下行驶，而不是在固定不动的状态下行驶。

　　在商业自动化方面，一个软件程序通常被认为是有两个主要的状态。

　　·主动状态

　　·被动状态

　　第一个状态代表被调用的或者被执行的软件程序处于一个主动状态。当程序没有使用时，就处于被动或非主动状态。

　　在设计程序时，我们对软件程序在主动状态下的表现很感兴趣。我们如此感兴趣，事实上，我们还有应用于程序的其它状态，该程序代表主动状态的特定类型。在我们谈到状态管理时，有两种基本状况：

　　·无状态的

　　·有状态的

　　这些术语常常被用来证明一个程序的主动或运行时间状态，因为这和执行指定任务的处理有关。我们可以把这个数据称为状态信息。

　　一个程序可能是积极的，但其不一定参与了状态信息的处理。在理想情况下该程序是无状态的。正如你所猜想的，一个积极处理或保持状态信息的程序被认为是有状态的。

　　处理过程要求服务在常规基础上，增加被重用、组合和并行存取的机率，同时也要优化处理逻辑的服务。当我们建立面向服务架构时，需要特别注意状态管理。因此，我们如此强调优化架构内服务信息的管理，以至于我们有了一个用于服务设计方面的原则。

　　该原则规定，服务应该最大限度减少他们管理的状态信息的内容和他们有状态的期限。在一个面向服务里，状态信息通常代表现有服务活动的特定数据。当服务在处理一个消息时比如，它是暂时有状态的（图2 ）如果一个服务负责在长时间内保持状态，其被其它用户使用的能力就会受到阻碍。

　　至于独立性，无状态是一个服务最佳状态。该状态能促进可重用性和伸展性。对于一个服务来说，应该尽量保持小状态。其基本服务逻辑应该考虑设计成无状态的过程。另外，架构本身就应该配有在大范围服务内支持该原则应用的延期扩展。

　　下一步如何？

　　在服务设计中，无状态性和独立性并行不悖.他们每一个都支持另一个的目标，并一起支持SOA的目标。在文章的最后一期里，我们将关注面向服务设计原则间的主要关系，以及怎样通过使用服务抽取层来进一步更好的应用范例。