关键字：构架SOA 在与客户的多次接触中，我都需要建立一套基本的SOA原则。以下章节介绍了面向服务的架构（SOA）所需要遵循的基本准则。这些准则不是绝对正确的，只是一套针对SOA相关讨论的框架性意见。你可能注意到前四条是基于Don Box的四项原则，只是我在经过了这么长时间后加上了点个人的想法（我之所以把它们列出来是因为有人要求我提供一个可供参考的版本；我没有回顾过这几条，可能现在我对其中某些的看法已有改变）
1）清晰的边界
在调用一个服务来完成它提供的功能的时候，需要将服务所需的所有信息传递过去。所有对服务的访问都应通过其对外公开的接口；不应当允许某个服务存在任何隐含的假设。：“服务不可避免地要依赖消息，因为所有进出服务的东西都是消息”。通常情况下，服务的调用应该不依赖共享的上下文，而应该设计成无状态的。服务所暴露的接口通过契约规定了它的功能性和非功能性的作用和特征。服务的调用是一个有业务意义的动作，可能是十分消耗资源的，并引入一系列不同于本地调用或远程过程的异常。服务调用是不同于普通远程过程调用的。
提供和消费服务需要尽可能的容易，所以应当避免隐藏过多服务之间所发生的交互。服务发送和接受的消息、服务的契约以及服务本身是SOA中首先需要确立的。这里面所包含的意思，对于任何建模的语言和工具来说，就是起码应该对编写服务的程序员提供这几个概念方面的API.总而言之，服务通过外部接口隐藏内部细节，暴露服务的功能；于服务的交互是一个显式的行为，它依赖服务的提供者和消费者之间消息传递。
2）共享契约和Schema，而不是Class类
根据服务的描述（某种契约），服务的消费者和提供者应该拥有消费或提供服务所需要的所有东西。根据松耦合原则，服务的提供者不应该依赖消费者在它自己环境下所能提供的代码重用能力；因为服务可能被用在不同的开发时和运行时环境中。该原则在很大程度上限制了可以在SOA中交换的数据类型。理想的数据格式是使用可以被一个或多个Schema所验证的XML文档，因为几乎所有可以想象到的语言环境都支持XML.
3）策略驱动
要跟一个服务交互，必须满足两组正交的需求：
1）服务提供者的功能、语法和语义必须满足服务消费者的需求，
2）技术能力和技术需求必须相符。
打个比方，一个服务提供者可以很好地满足一个服务消费者的要求，但是它是通过JMS来提供服务的，而消费者却只能使用HTTP(例如它是在.NET平台上实现的)；提供者可能要求通过XML加密标准在消息层进行加密，而消费者只支持SSL的传输层加密。即便在那些双方都具备所需要的能力的情况下，这些能力也需要被“激活”--例如，服务提供者可能会有必要根据不同的消费者对应答消息采用不同的加密算法。
为了支持各式各样不同设备和不同能力的服务消费者来访问服务，SOA工具集必须引入某种策略机制。服务的功能性特征是由它们的接口来描述，而这些非功能性能力和需求则是用策略文件来指定的。
4）自治
跟“清晰的边界”相关的一条准则是，一个服务应该是自治的，即，它跟外界的唯一关系（至少从SOA的角度来看）是通过它的接口。在某些情况下，一个服务还必须能够切换它的运行期环境，例如，从轻量级的原型实现切换到完善的基于应用服务器的互相协作的多个组件的实现，而不需要用户做任何相应的改动。服务可以相互独立地进行改变、部署和版本管理。服务的提供者应该能够不依赖用户能力而迅速切换服务到更新的版本；而一些用户也无法或不愿意切换到新的服务接口（特别是那些服务提供者无法控制的用户）。
5）用格式连接，而不是用程序API
服务都支持使用特定的连接格式。这条原则和“清晰的边界”原则关系非常大，不过是引入了一个新的角度：尽最大可能让服务可以被访问（从而达到长期的可用性），即，只要遵循服务所定义的交互策略，应该可以从任何平台上通过符合服务接口定义的消息的交互来访问一个服务。比如，要测试某个服务是否符合这个准则，可以看看是否能使用某种非主流的动态编程语言，例如Perl，Python或Ruby来调用或提供这项服务。虽然这些语言在当下的技术蓝图中无足轻重，但可以作为试纸来评估服务是否满足下列约束：
1）所有消息的格式使用公开标准，或人类可读的描述；
2）不需要耗费很多工作就可以创建符合特定Schema的消息，也不需要依赖特定的程序库；
3）正确通讯所需的额外信息（例如为了安全或可靠性所创建的头部信息）的语义和语法应该依照公开规范或标准；
4）与服务交互相关的传输（或传送）协议中至少有一个是标准的网络协议（或可以通过标准网络协议进行访问的）；
6）面向文档
文章来源于领测软件测试网 https://www.ltesting.net/
