软件开发是一件很难的事情，因为要处理的问题越来越复杂，处理这种复杂性问题最常用的手段就是抽象。回顾历史，抽象层次越来越多，反映在各个方面，从编程语言、平台、开发过程、工具到模式。尤其是模式，大量出现在那些结构上设计得很好的软件系统中，无论是微观层次上（对象、组件）稳定出现的结构范式，还是在宏观层面上出现的架构模式。使用哪些抽象手段来为问题域建模？如何定义组成部分之间的协作和结构关系？如何定义从外界所看到的系统结构和行为？是什么设计原则在指导架构决策？有什么最佳实践和模式可供借鉴？所有这些，形成了不同设计风格和体系结构范式（Architecture Paradigm）。
通常，一种体系结构范式，包括设计原则，来自实践的结构式样、组成要素和关系，以及在整个开发生命周期中它们是如何被识别、描述和控制的。体系结构从过去单个应用包罗一切的客户/服务器的模式，逐渐演变到三层和多层结构的各种分布式计算模式。今天，人们开始谈论和实践面向服务、更加分布化的架构范式。
从抽象手段而言，SOA在原有方法的基础上，增加了服务、流程等元素，其概念模型架构如图3-6所示。
图3-6 SOA的概念模型架构
如何利用这些抽象手段，将一个业务需求转化为流程、服务，进一步建模为服务组件，然后结合具体实现环境，在重用已有系统的功能和数据资源的基础上来实现？IBM总结的SOA架构概念模式如图3-7所示。
SOA架构中，继承了来自对象和组件设计的各种原则，如封装、自我包含等。那些保证服务的灵活性、松散耦合和重用能力的设计原则，对SOA架构来说同样是非常重要的。
结构上，服务总线是SOA的架构模式之一。
关于服务，一些常见和讨论的设计原则如下：
（1）无状态：以避免服务请求者依赖于服务提供者的状态。(https://www.xing528.com)
（2）单一实例：避免功能冗余。
图3-7 IBM总结的SOA架构概念模式
（3）明确定义的接口：服务的接口由WSDL定义，用于指明服务的公共接口与其内部专用实现之间的界线。WS-Policy用于描述服务规约，XML模式（Schema）用于定义所交换的消息格式（即服务的公共数据）。使用者依赖服务规约来调用服务，所以服务定义必须长时间稳定，一旦公布，不随意更改；服务的定义应尽可能明确，减少使用者的不适当使用；不要让使用者看到服务内部的私有数据。
（4）自包含和模块化：服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
（5）粗粒度：服务数量不应该太大，依靠消息交互而不是远程过程调用（RPC），通常消息量比较大，但是服务之间的交互频度较低。
（6）服务之间的松耦合性：服务使用者看到的是服务的接口，其位置、实现技术、当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
（7）重用能力：服务应该是可以重用的。
（8）互操作性、兼容和策略声明：为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。这可以是技术相关的内容，比如一个服务对安全性方面的要求；也可以是跟业务有关的语义方面的内容，比如需要满足的费用或者服务级别方面的要求，这些策略对于服务在交互时是非常重要的。WS-Policy用于定义可配置的互操作语义，来描述特定服务的期望，控制其行为。在设计时，应该利用策略声明确保服务期望和语义兼容性方面的完整和明确。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
