《微软云计算Windows Azure开发与部署权威指南》——第6章 Windows Azure平台访问控制与总线AppFabric6.1 服务导向架构

本节书摘来自异步社区《微软云计算Windows Azure开发与部署权威指南》一书中的第6章,第6.1节,作者: 尹成 , 郝庭毅 , 张俊强 , 孙奉刚 , 寇睿明 更多章节内容可以访问云栖社区“异步社区”公众号查看。

第6章 Windows Azure平台访问控制与总线AppFabric

6.1 服务导向架构

微软云计算Windows Azure开发与部署权威指南
什么是SOA(Service-Oriented Architecture,服务导向架构)?SOA的理念广为人知,然而其概念解释又有多种版本。本书认为SOA是为了满足组织机构的商业需求而建立的松耦合的体系结构。

需要读者注意的是,SOA注重架构而不是实现,它不是一门技术,而是一门设计哲学,很多人将面向服务的架构和面向服务的实现混淆。SOA并不强调实现的技术,如Web服务。虽然目前大部分组织机构采用Web服务来实现松耦合的体系架构,但这并不代表SOA必须使用Web服务。表6-1是微软MSDN上的一个表格,纠正了人们对SOA的一些常见的误解。


《微软云计算Windows Azure开发与部署权威指南》——第6章 Windows Azure平台访问控制与总线AppFabric6.1 服务导向架构

如何理解这里的“服务”呢?服务既可以是操作系统的进程,也可以是使用定义良好的契约的应用程序,该应用程序可以基于Web服务,也可以不使用Web服务,但是该服务必须可以加入到一个松耦合的体系结构中。下面给出设计服务的4个准则。

1.边界明确
服务之间通过显示的消息传递进行交互,该消息跨越定义良好的边界。跨服务边界可能需要很大的开销。此处的边界指的是一个服务的公共接口和其内部私有实现之间的界限。一个服务的边界可以通过服务描述文档(WSDL)公开。

2.服务自治
各个服务是发布、更新和管理都互相独立的实体。服务自治并不意味着服务会成为孤岛,基于SOA的解决方案往往是不规则的,通过配置一些服务得到。实现自治服务的关键是隔离和去耦。各服务之间的设计和部署都是相互独立的,只通过契约驱动的消息交互。

3.服务之间共享数据定义模式和契约,而不是类
服务交互只能通过服务策略、模式和基于契约的行为。大多数开发人员使用类来代表问题空间中的不同实体。类将数据和行为绑定到一种编程语言或者特定的平台结构。服务要将这种模型分开以最大化灵活性和互操作性。使用XML这种基于模式的消息进行交互的服务对程序语言和平台而言都是透明的。模式定义了消息对的结构和内容,而契约定义了服务自身的行为。

4.基于策略的服务兼容性
虽然人们对这条设计原则了解最少,但在实现Web服务灵活性方面该原则作用非常强大。仅仅通过一个服务描述文档WSDL是不能表达完整对服务交互的要求的。策略表达式可以将结构兼容性与语义兼容性分离开来,它提供了一个可配置的包含一系列交互语义的集合来控制某个特定服务的行为和期望值,服务提供者可以使用机器可读的策略表达式来表明操作要求。

上一篇:SAP S/4HANA生产订单创建时使用的工厂数据是从什么地方带出来的


下一篇:三方联袂打造物联网LBS生态平台 加速进阶IOE时代