名扬数据:软件面向服务的设计原则,体系结构的演变

战略成为一个越来越重要的方面,这可以是技术相关的内容,互操作性、兼容和策略声明,为了确保服务规约的全面和明确比如一个服务对平安性方面的要求;也可以是跟业务有关的语义方面的内容,比如需要满足的费用或者服务级别方面的要求,这些战略对于服务在交互时是非常重要的WS-Polici用于定义可配置的互操作语义,来描述特定服务的期望、控制其行为。设计时,应该利用战略声明确保服务期望和语义兼容性方面的完整和明确。

因为我要处理的问题越来越复杂,软件开发一直是一件很难的事情。人们处置这种复杂性最主要的手段就是笼统。回顾历史,笼统层次越来越高,反映在各个方面,从编程语言、平台、开发过程、工具到模式。尤其是模式,大量呈现在那些结构上设计得很好的软件系统中,无论是微观层次上(对象、组件)稳定呈现的结构范式,还是宏观层面上出现的架构模式。使用哪些笼统手段来为问题域建模?如何定义组成局部之间的协作和结构关系?如何定义从外界所看到系统结构和行为?什么设计原则在指导我架构决策?有什么最佳实践和模式可供借鉴?所有这些,形成了不同设计风格和体系结构范式。

一种体系结构范式,通常包括设计原则,来自实践的结构式样、组成要素和关系,以及在整个开发生命周期中它如何被识别、描述和控制的体系结构从过去单个应用包罗一切的客户/服务器的模式,逐渐演变到三层和多层结构的各种分布式计算模式。今天,人们开始谈论和实践面向服务、更加分布化的架构范式。

SOA 原有方法的基础上,从笼统手段而言,增加了服务、流程等元素,将一个业务需求转化为流程、服务,如何利用这些笼统手段。进一步建模为服务组件,然后结合具体实现环境,重用已有系统的功能和数据资源的基础上来实现?架构概念模式,继承了来自对象和组件设计的各种原则,SOA 架构中如封装、自我包括等。那些保证服务的灵活性、松散耦合和重用能力的设计原则,对SOA 架构来说同样是非常重要的

一些罕见和讨论的设计原则如下:关于服务,无状态,以防止服务请求者依赖于服务提供者的状态;单一实例,防止功能冗余。用于指明服务的公共接口与其内部专用实现之间的界线。WS-Polici用于描述服务规约,明确定义的接口。服务的接口由WSDL定义。XML模式(Schema用于定义所交换的消息格式(即服务的公共数据)使用者依赖服务规约来调用服务,所以服务定义必需长时间稳定,一旦公布,不随意更改;服务的定义应尽可能明确,减少使用者的不适当使用;不要让使用者看到服务内部的私有数据。

实现服务的功能实体是完全独立自主的独立进行安排、版本控制、自我管理和恢复。自包括和模块化。服务封装了那些在业务上稳定、重复呈现的活动和组件。依靠消息交互而不是远程过程调用RPC通常消息量比较大,粗粒度。服务数量不应该太大。但是服务之间的交互频度较低。其位置、实现技术、当前状态等对使用者是不可见的服务私有数据对服务使用者是不可见的,服务之间的松耦合性。服务使用者看到服务的接口。