Software-Think SOA 面向服务架构思想

SOA 四项信条

  1. 边界明确
  2. 服务自治
  3. 服务共享数据模式和契约而不是类
  4. 基于策略确定服务兼容性

在大规模分布式应用程序(如 SOA系统)领域中,相关联得涉及模式被称为 Messagign 消息传送模式。

Messaging 模式(与设计模式类似)为复杂问题提供标准得解决方案。

以一种统一得形式解决在众多彼此分离得系统中共享数据得问题。

Document Message 模式使得能够采用一种统一、灵活得方法与服务通信。

该模式并不使用典型得 RPC 风格得参数化方法来暴露服务API,而是采用消息对象。

Docment Message 模式通过将所有消息封装到文档正文中以形成一个更简单和干净得服务签名,

简化了通信:

Customer[ ]  FindBy(CustomerSearchRequest  request) ;

给出 Document Message 类:

public class  CustomerSearchRequest

{

  public  string  Country { get;  set; }

  public  string  PostalCode { get;  set; }

  public  string  Street { get;  set; }

}

消息常包含其他热议得信息条目, 包括

1. 服务版本号

2. 确认标识符

3. 身份验证数据

把这些条目添加到一个所有请求都能够继承得基类中,通过在所有通信中使用 Document Message 模式,

可以容易地改进服务方法并包含额外得参数,而不需要修改方法的签名。

Request-Response 模式确保 响应和请求 一样均使用 Document  Message 模式 , 因此

RetrieveCustomers 方法得签名类似与下面得代码:

CustomerSearchResponse  RetrieveCustomers( CustomerSearchRequest request );

Request 可以继承自某个基类,该基类可以提供对

1. 通用消息

2. 成功标记

3. Correlation ID ( 关联 ID ) 等常见属性得访问。

而 Correlation Id  关联 Idempotent  模式

在所有服务中一致地使用 Request-Response 模式,从而形成灵活得、易于使用得API.

Idempotent 模式

计算领域, 幂等 Idempotent 操作是指使用相同得输入参数调用多次不会带来副作用得操作。

因为服务不能控制它的客户端如何使用,所以确保重复调用不会对系统状态造成非预期的效果非常重要。

客户代码调用一个服务调用发送请求。并指定一个唯一标识号码。

在接受该请求时,服务进行检查,通过搜索本地响应资源库看以前是否已经处理过它。

如果并不存在匹配该唯一标识符的响应,则该业务事务就可以进行。

如果已经存在,就取出存储的响应并将其返回给客户代码。

除了在每个请求中包含一个唯一的标识符,还可以让服务在返回给客户端的响应结果中包含同样的ID,

还可以带来另一个好处:允许调用该服务的客户代码验证匹配请求的响应,在这里这个唯一标识符

称为关联 ID .

时间: 2024-08-27 15:25:20

Software-Think SOA 面向服务架构思想的相关文章

为什么说社会形态影响着SOA面向服务架构思想?

产品将面对的社会形态 新研发的平台产品所面临的问题是:面对激烈的商业竞争形势,使大多数企业都面临着增长业绩.提高生产率和降低成本的压力,而产业的趋势是业务方法不断变化,特别表现在企业重构和解构这两个特征上. 企业重构:传统上的企业管理是一种层次化的垂直结构,打造了一个具有固定业务.确定交互.执行高效的模式.但是当竞争形势和市场需求发生变化的时候,它就与动态业务的趋势相冲突,阻碍了快速反应时间.这种外部压力迫使企业重新定位,向水平集成的业务流改变,这就形成了企业重构的趋势. 产业解构:在企业重构中

SOA面向服务架构简述

如果你对项目管理.系统架构有兴趣,请加微信订阅号"softjg",加入这个PM.架构师的大家庭 在上篇中我们简单谈了下架构设计中服务层的简单理解,在这里我们将继续服务层的架构,在本节我们将重点在于分布式服务.在分布式系统中表现层和业务逻辑层 并不处于同一物理部署,所以我们必须存在分布式服务,以契约方式发布于网络中,我们的关注点在于服务,面向服务编程,这种通过组合业务逻辑暴露可用服务的架构叫做面向服务架构(SOA). SOA强调一个松耦合,基于宏服务的架构,通过契约暴露给服务消费者可用的

学习~SOA面向服务框架

SOA面向服务架构 首先Martin Fowler提出SOA歧义Service Oriented Ambiguity,认为"什么是SOA"是不可能回答,因为不同的人意味着不同的事情,SOA意味服务接口,意味流程整合,意味资源再利用,意味着管制,在下面SOA组件图中,服务和服务消费者(客户端)之间存在多个约束,当一个服务显式暴露后,客户端能够通过绑定定位到该服务,相当于两者签订了合同,规定了合同内容和如何实施,具体合同的描述是通过消息方式进行: 由于Java等传统语言主要是以类表达对象,

SOA——面向服务的体系架构

上一篇博文中提到了"紧耦合"的现象,如何解决?SOA,采用面向服务的体系架构. 一.What? SOA=Service-oriented Architecture面向服务的体系结构 SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来. 我个人更加倾向于这样的一种解释:SOA是指为了解决在Internet环境下业务集成的需要,通过连接能完成特定任务的独立功能实体实现的一种软件系统架构. 所以,SOA是什么?SOA不是一种语言,也不是一

面向服务架构SOA

SOA架构即面向服务架构. 面向服务的体系结构,是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来. 接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台.操作系统和编程语言.这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互. 这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合.松耦合系统的好处有两点,一点是它的灵活性,另一点是,当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时,

面向服务架构的一些思考

在谈面向服务架构之前,首先来看看什么是服务.常谈的业务组件,业务方法或操作是否都是服务?真正的服务必须满足两个条件,一个服务本身是能力供给,必须有外界的需求:一个是服务本身是可复用或重用.一般来讲服务应该是可重用的任务,这种任务可以是业务方面的操作组合,也可以是一种技术能力. 面向服务的重点就是一切以服务为中心,从服务识别,服务分析,服务设计,服务开发和服务上线使用一切都是以服务为中心.但是要注意到面向服务本身不是在面向结构或面向对象基础上的一个新方法,而是对面向对象和组件化思想的提升. 面向服

领域驱动设计的面向服务架构

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店 一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列

OSGi——面向服务架构规范简述

OSGi——面向服务架构规范简述 去年我们组要开发一个新的产品,在讨论产品架构路线的时候,美国的架构师向大家征集了架构设计思想(我推荐了SCSF),有一位工程师向他推荐了OSGi.以前我还没有听过OSGi这玩意,虽然我参加工作后,现学了Java和Flex,但非常菜.在工作之前我用了4年的.NET.接触了OSGi后,发现它是一个面向Java的服务规范,还没有一个像样的面向.NET的框架(有个EgeyeAddIn,据说兼容OSGi,我看了源代码了,觉得它离OSGi较远http://www.codep

[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店

一.前言 在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Byteart Retail案例并没有对其形成过程做一步步分析,而是把整个DDD的实现案例展现给我们,这对于一些刚刚接触领域驱动设计的朋友可能会非常迷茫,从而觉得领域驱动设计很难,很复杂,因为学习中要消化一个整个案例的知识,这样未免很多人消化不了就打退堂鼓,就不继续研究下去了,所以这样也不利于DDD的推广.然而本系列可以说是刚接触领域驱动设计朋友的福音,本系列将结合领域驱动设计的思想来一步步构建一个网