微软《SOA in the Real World》笔记05——第一章

微软《SOA in the Real World》笔记05——第一章

理解服务
任何SOA努力的第一步是清晰地识别出关键的业务上的问题或者挑战。问题或挑战定义得越准确，就越容易确定SOA项目的方向和范围。通过在高层设定清晰的方向和愿景，就能够很容易得到天生具有跨职能部门的合适的项目。一旦定义了组织的业务推动力，服务分析过程就可以开始了。服务分析是组成服务生命周期的一个步骤。服务生命周期解释了组织定义、开发、部署和操作服务所必经的步骤。

服务通常用来暴露诸如遗留平台和业务运行系统等方面的IT投资。服务可以装配（或组合）进业务流程，可以为终端用户、系统或其他服务所使用。创建（或暴露）新的服务、聚集（或组合）服务到组合应用中，以及让商业客户可以使用服务的过程是一个迭代的过程。



服务模型的基础是接口和实现的分离。服务的调用者只需要（应该只需要）理解接口，实现可以随时进行优化而不用分发到服务的客户那里。面向服务的几个关键好处都是从功能交付的抽象能力中得来的。这就意味着，很多实现可以提供相同的接口，或者反过来，在不影响组合应用的情况下更换实现。在最抽象的情况下，面向服务把所有的一切都作为服务的提供者，包括主机应用、打印机、货运码头职员和通宵速递公司等。服务模型是分形的，新组成的流程本身也是服务，暴露了新的、组合起来的功能。

什么是服务？在本书中避免使用Web服务这个术语只是因为所有服务并不一定是Web服务。服务有可能表现为操作系统级别的进程，例如Unix daemon或者Windows Service。服务也可能是一个使用定义良好契约的应用程序，该应用程序可能是也可能不是建立在Web服务的基础上的。不管实际的服务是如何开发的，他们必须能够参与到松耦合的架构中。有四个明确的原则可以确保建立一个松耦合的架构。服务设计原则定义如下：

服务设计原则
缩写词SOA提出了一个明显的问题——什么是服务。简单来说，服务是可以通过定义良好的消息交换进行交互的程序。服务的设计必须具有可用性和稳定性。创建的服务需要长时间保持，而服务的配置和组合则可以更改。敏捷常常被称为SOA的最大好处——在松耦合基础设施上实现了业务流程的组织对变化有更高的开放性，那些被限制在单一应用程序下的组织，即时最小的修改也需要几周的时间。松耦合系统导致了松耦合的业务流程，因为业务流程不再受到基础设施的限制。服务和它们的接口必须保持稳定，以便能够重新配置或重新组合它们来满足已经改变了的业务需求。服务可以通过基于标准的接口和定义良好的消息来保持稳定——例如，使用SOAP和XML样式作为消息的定义。那些设计用来执行简单的、细粒度的功能的服务，只需要那些消息如何传送和恢复的有限知识，这些服务更多可能是在更大的SOA基础设施中进行重用。如前所述，用于OO设计的封装和接口设计基本原则可以同样应用于设计和创建可重用的Web服务。通过深入理解我们常常提起的四个面向服务的原则，我们把这些OO原则扩展到了Web服务的领域：

原则1：边界是显式的。
通过边界后面的显式消息传递方式，服务可以进行交互。对于服务边界之后的空间，我们不做任何假设。跨越服务边界可能需要很高的成本(例如，你可能需要扩展地域、可靠的边界或执行环境)。通过在服务之间正式地传递已定义的消息，我们明确地决定调用服务。显式的边界使我们可以正式地展示独立于实现过程的交互操作——我们不必明确地选择实现其它服务所使用的平台、中间件或编码语言。

原则2：服务是自治的。

作为独立的实体，服务采取了合理的行为。对于服务边界之间的空间，我们不做任何假设。在面向服务的环境中，并没有主导的权威。服务的部署、版本控制和管理都是独立的。执行服务的拓扑可能会(也必将会)不断地发展。服务应该预料到对等的服务可能会(也必将会)失效，而且它可能会(也必将会)收到残缺的或恶意的消息。应该使用冗余和故障转移等技术来创建服务，以避免服务失效。

原则3：服务对架构和协定(而不是类)进行共享。

服务只在其使用架构的结构表达式和使用协定的行为表达式上进行交互。服务的协定描述了消息的结构和消息的排序约束。表达式的形式使机器可以验证传入的消息，这样我们就可以保护服务的完整性。在时间变化时，协定和架构必须保持稳定，因此灵活地创建它们(例如，通过在架构中使用xsd:any)很重要。

原则4：服务的兼容性是以策略为基础的。

服务提供者和服务消费者都具有与跨边界交互相关的策略——操作要求。提供端策略的一个简单示例是，服务可能需要调用者在服务提供者那里拥有有效的帐户。从消费端的角度来说，组织可能需要对跨越Internet的服务调用进行加密，这样它就只能使用可提供安全性增强的双向数据交换功能的服务。服务使用了机器可读的策略表达式来表现其功能和要求。策略断言是由一个稳定的全局唯一名称来标识的。单独的策略断言对于整个系统而言是难以理解的;服务必须能够满足彼此的策略要求。

这四个原则主要是用来帮助你设计和开发服务的。