精华内容
下载资源
问答
  • 软件体系结构 消息总线风格 文档管理
  • 基于层次消息总线的体系结构是一种新的软件体系风格
  • C++ 消息总线的特点

    2019-12-23 11:35:31
    1.对象只通过消息联系,不直接依赖或者关联 2.降低复杂度,简化对象关系 3.提高程序可维护性 要解决的问题 1.消息的定义:通用的消息格式使得所有对象能够接受 2.消息的注册:所有对象都可以注册消息 3.消息的...

    好处

    1.对象只通过消息联系,不直接依赖或者关联

    2.降低复杂度,简化对象关系

    3.提高程序可维护性

     

    要解决的问题

    1.消息的定义:通用的消息格式使得所有对象能够接受

    2.消息的注册:所有对象都可以注册消息

    3.消息的分发:使得所有对象都可以收到消息并处理

    展开全文
  • 架构风格是一组原则。你可以把它看成是一组为系统家族提供抽象框架的粗粒度模式。架构风格能改进分块,还能为频繁出现的问题提供解决方案,以此促进设计重用。常见的软件体系结构风格...

    架构风格是一组原则。你可以把它看成是一组为系统家族提供抽象框架的粗粒度模式。架构风格能改进分块,还能为频繁出现的问题提供解决方案,以此促进设计重用。

    常见的软件体系结构风格涉及:

    • 设计词汇表是什么?或者构件和连接器的类型是什么?

    • 可容许的结构模式是什么?

    • 基本的计算模型是什么?

    • 风格的基本不变性是什么?

    • 其使用的常见例子是什么?

    • 使用此风格的优缺点是什么?

    • 其常见特例是什么?

    软件体系结构设计的一个中心问题是能否重用软件体系结构模式,或者采用某种软件体系结构风格。有原则地使用软件体系结构风格具有如下意义:

    • 它促进了设计的复用,使得一些经过实践证实的解决方案能够可靠地解决新问题。

    • 它能够带来显著的代码复用,使得体系结构风格中的不变部分可共享同一个解决方案。

    • 便于设计者之间的交流与理解。

    • 通过对标准风格的使用支持了互操作性,以便于相关工具的集成。

    • 在限定了设计空间的情况下,能够对相关风格作出分析。

    • 能够对特定的风格提供可视化支持。

    与此同时,人们目前尚不能准确回答的问题是:

    • 系统设计的哪个要点可以用风格来描述;

    • 能否用系统的特性来比较不同的风格,如何确定用不同的风格设计系统之间的互操作;

    • 能否开发出通用的工具来扩展风格;

    • 如何为一个给定的问题选择恰当的体系结构风格,或者如何通过组合现有的若干风格来产生一个新的风格。

    M.Shaw等人根据此框架给出了管道与过滤器、数据抽象和面向对象组织、基于事件的隐式调用、分层系统、仓库系统及知识库和表格驱动的解释器等一些常见的软件体系结构风格。

     

    架构风格

    客户端-服务器 

    基于组件的架构 

    分层架构 

    消息总线 

    N层/三层架构 

    面向对象 

    分离表现层 

    面向服务架构(SOA) 

    这些架构风格分别适用于特定领域:

    通信 

    部署 

    领域 

    交互 

    结构 

     

    下面介绍几种常见的架构风格: 

    管道和过滤器风格

    在管道/过滤器风格的软件体系结构中,每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。因此,这里的构件被称为过滤器,这种风格的连接件就像是数据流传输的管道,将一个过滤器的输出传到另一过滤器的输入。此风格特别重要的 过滤器必须是独立的实体,它不能与其它的过滤器共享数据,而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进 行增量计算过程的顺序。

    图2-1是管道/过滤器风格的示意图。一个典型的管道/过滤器体系结构的例子是以Unix shell编写的程序。Unix既提供一种符号,以连接各组成部分(Unix的进程),又提供某种进程运行时机制以实现管道。另一个著名的例子是传统的编 译器。传统的编译器一直被认为是一种管道系统,在该系统中,一个阶段(包括词法分析、语法分析、语义分析和代码生成)的输出是另一个阶段的输入。

    0?wx_fmt=gif

    图 2‑1管道/过滤器风格的体系结构

    管道/过滤器风格的软件体系结构具有许多很好的特点:

    (1)使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;

    (2)允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成;

    (3)支持软件重用。重要提供适合在两个过滤器之间传送的数据,任何两个过滤器都可被连接起来;

    (4)系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来;旧的可以被改进的过滤器替换掉;

    (5)允许对一些如吞吐量、死锁等属性的分析;

    (6)支持并行执行。每个过滤器是作为一个单独的任务完成,因此可与其它任务并行执行。

    但是,这样的系统也存在着若干不利因素。

    (1)通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据,但它们是独立的,所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。

    (2)不适合处理交互的应用。当需要增量地显示改变时,这个问题尤为严重。

    (3)因为在数据传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作,这样就导致了系统性能下降,并增加了编写过滤器的复杂性

     

    数据抽象与面向对象风格

    抽象数据类型概念对软件系统有着重要作用,目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上,数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象,或者说是抽象数据类型的实例。对象是一种被称作管理者的构件,因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。

    图2-2是数据抽象和面向对象风格的示意图。

    0?wx_fmt=gif

    图 2‑2数据抽象和面向对象风格的体系结构

    面向对象的系统有许多的优点,并早已为人所知:

    (1) 因为对象对其它对象隐藏它的表示,所以可以改变一个对象的表示,而不影响其它的对象。

    (2) 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

    但是,面向对象的系统也存在着某些问题:

    (1)为了使一个对象和另一个对象通过过程调用等进行交互,必须知道对象的标识。只要一个对象的标识改变了,就必须修改所有其他明确调用它的对象。

    (2)必须修改所有显式调用它的其它对象,并消除由此带来的一些副作用。例如,如果A使用了对象B,C也使用了对象B,那么,C对B的使用所造成的对A的影响可能是料想不到的。

     

    基于事件的隐式调用风格

    基于事件的隐式调用风格的思想是构件不直接调用一个过程,而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程,这样,一个事件的触发就导致了另一模块中的过程的调用。

    从体系结构上说,这种风格的构件是一些模块,这些模块既可以是一些过程,又可以是一些事件的集合。过程可以用通用的方式调用,也可以在系统事件中注册一些过程,当发生这些事件时,过程被调用。

    基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序,甚至不知道哪些过程会被调用,因此,许多隐式调用的系统也包含显式调用作为构件交互的补充形式。

    支持基于事件的隐式调用的应用系统很多。例如,在编程环境中用于集成各种工具,在数据库管理系统中确保数据的一致性约束,在用户界面系统中管理数据,以及在编辑器中支持语法检查。例如在某系 统中,编辑器和变量监视器可以登记相应Debugger的断点事件。当Debugger在断点处停下时,它声明该事件,由系统自动调用处理程序,如编辑程 序可以卷屏到断点,变量监视器刷新变量数值。而Debugger本身只声明事件,并不关心哪些过程会启动,也不关心这些过程做什么处理。

    隐式调用系统的主要优点有:

    (1)为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时,只需将它注册到系统的事件中。

    (2)为改进系统带来了方便。当用一个构件代替另一个构件时,不会影响到其它构件的接口。

    隐式调用系统的主要缺点有:

    (1)构件放弃了对系统计算的控制。一个构件触发一个事件时,不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成,它也不能保证这些过程被调用的顺序。

    (2)数据交换的问题。有时数据可被一个事件传递,但另一些情况下,基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下,全局性能和资源管理便成了问题。

    (3)既然过程的语义必须依赖于被触发事件的上下文约束,关于正确性的推理存在问题。

     

    层次系统风格

    层次系统组织成一个层次结构,每一层为上层服务,并作为下层客户。在一些层次系统中,除了一些精心挑选的输出函数外,内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机(在另一些层次系统中层是部分不透明的)。连接件通过决定层间如何交互的协议来定义,拓扑约束包括对相邻层间交互的约束。

    这种风格支持基于可增加抽象层的设计。这样,允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层,同时只要给相邻层提供相同的接口,允许每层用不同的方法实现,同样为软件重用提供了强大的支持。

    图2-3是层次系统风格的示意图。层次系统最广泛的应用是分层通信协议。在这一应用领域中,每一层提供一个抽象的功能,作为上层通信的基础。较低的层次定义低层的交互,最低层通常只定义硬件物理连接。

    0?wx_fmt=gif

    图 2‑3层次系统风格的体系结构

    层次系统有许多可取的属性:

    (1)支持基于抽象程度递增的系统设计,使设计者可以把一个复杂系统按递增的步骤进行分解;

    (2)支持功能增强,因为每一层至多和相邻的上下层交互,因此功能的改变最多影响相邻的上下层;

    (3)支持重用。只要提供的服务接口定义不变,同一层的不同实现可以交换使用。这样,就可以定义一组标准的接口,而允许各种不同的实现方法。

    但是,层次系统也有其不足之处:

    (1)并不是每个系统都可以很容易地划分为分层的模式,甚至即使一个系统的逻辑结构是层次化的,出于对系统性能的考虑,系统设计师不得不把一些低级或高级的功能综合起来;

    (2)很难找到一个合适的、正确的层次抽象方法。

     

    仓库风格

    在仓库风格中,有两种不同的构件:中央数据结构说明当前状态,独立构件在中央数据存贮上执行,仓库与外构件间的相互作用在系统中会有大的变化。

    控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择,则仓库是一传统型数据库;另一方面,若中央数据结构的当前状态触发进程执行的选择,则仓库是一黑板系统。

    图2-4是黑板系统的组成。黑板系统的传统应用是信号处理领域,如语音和模式识别。另一应用是松耦合代理数据共享存取。

    0?wx_fmt=gif

    图 2‑4黑板系统的组成

    我们从图2-4中可以看出,黑板系统主要由三部分组成:

    (1)知识源。知识源中包含独立的、与应用程序相关的知识,知识源之间不直接进行通讯,它们之间的交互只通过黑板来完成。

    (2)黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据,知识源通过不断地改变黑板数据来解决问题。

    (3)控制。控制完全由黑板的状态驱动,黑板状态的改变决定使用的特定知识。

     

    C2风格

    C2体系结构风格可以概括为:通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下:

    (1)系统中的构件和连接件都有一个顶部和一个底部;

    (2)构件的顶部应连接到某连接件的底部,构件的底部则应连接到某连接件的顶部,而构件与构件之间的直接连接是不允许的;

    (3)一个连接件可以和任意数目的其它构件和连接件连接;

    (4)当两个连接件进行直接连接时,必须由其中一个的底部到另一个的顶部。

    图2-5是C2风格的示意图。图中构件与连接件之间的连接体现了C2风格中构建系统的规则。

    0?wx_fmt=gif

    图 2‑5 C2风格的体系结构

    C2风格是最常用的一种软件体系结构风格。从C2风格的组织规则和结构图中,我们可以得出,C2风格具有以下特点:

    (1)系统中的构件可实现应用需求,并能将任意复杂度的功能封装在一起;

    (2)所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的;

    (3)构件相对独立,构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行,或某些构件共享特定控制线程之类的相关性假设。

     

    二层C/S我们不再介绍了,直接说三层C/S

    三层C/S的基本硬件结构

    传统的二层C/S结构存在以下几个局限:

    l 它是单一服务器且以局域网为中心的,所以难以扩展至大型企业广域网或Internet;

    l 受限于供应商;

    l 软、硬件的组合及集成能力有限;

    l 难以管理大量的客户机。

    因此,三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据层三部分。其解决方案是:对这三层进行明确分割,并在逻辑上使其独立。原来的数据层作为DBMS已经独立出来,所以关键是要将表示层和功能层分离成各自独立的程序,并且还要使这两层间的接口简洁明了。

    将上述三层功能装载到硬件的方法基本上有三种(如图所示)。其中表示层配置在客户机中,而数据层配置在服务器中。

    一般情况是只将表示层配置在客户机中,与二层C/S结构相比,其程序的可维护性要好得多,是其他问题并未得到解决。客户机的负荷太重,其业务处理所需的数据要从服务器传给客户机,所以系统的性能容易变坏。

    如果将功能层和数据层分别放在不同的服务器中,则服务器和服务器之间也要进行数据传送。但是,由于在这种形态中三层是分别放在各自不同的硬件系统上的,所以灵活性很高,能够适应客户机数目的增加和处理负荷的变动。例如,在追加新业务处理时,可以相应增加装载功能层的服务器。因此,系统规模越大这种形态的优点就越显著。

    值得注意的是:三层C/S结构各层间的通信效率若不高,即使分配给各层的硬件能力很强,其作为整体来说也达不到所要求的性能。此外,设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/S结构的关键问题。

    0?wx_fmt=jpeg

    三层C/S的功能

    1.表示层

    表示层是应用的用户接口部分,它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据,显示应用输出的数据。为使用户能直观地进行操作,一 般要使用图形用户接口(GUI),操作简单、易学易用。在变更用户接口时,只需改写显示控制和数据检查程序,而不影响其他两层。检查的内容也只限于数据的 形式和值的范围,不包括有关业务本身的处理逻辑。

    图形界面的结构是不固定的,这便于以后能灵活地进行变更。例如,在一个窗口中不是放入几个功能,而是按功能分割窗口,以便使每个窗口的功能简洁单纯。在这层的程序开发中主要是使用可视化编程工具。

    2. 功能层

    功能层相当于应用的本体,它是将具体的业务处理逻辑地编入程序中。例如,在制作订购合同的时要计算合同金额,按照定好的格式配置数据、打印订购合同,而 处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。例如,用户检索数据时,要设法将有关检索要求的信息一次传送给功能 层(参见图2),而由功能层处理过的检索结果数据也一次传送给表示层。在应用设计中,一定要避免进行一次业务处理,在表示层和功能层间进行多几次数据交换 的笨拙设计。

    通常,在功能层中包含有:确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。这层的程序多半是用可视化编程工具开发的,也有使用COBOL和C语言的。

    3. 数据层

    数据层就是DBMS,负责管理对数据库数据的读写。DBMS必须能迅速执行大量数据的更新和检索。现在的主流是关系数据库管理系统(RDBMS)。因此,一般从功能层传送到数据层的要求大都使用SQL语言。 

    三层C/S结构的优点

    1。 具有灵活的硬件系统构成

    对于各个层可以选择与其处理负荷和处理特性相适应的硬件。这是一个与系统可缩放性直接相关的问题。例如,最初用一台Unix工作站作为服务器,将数据层 和功能层都配置在这台服务器上。随着业务的发展,用户数和数据量逐渐增加,这时就可以将Unix工作站作为功能层的专用服务器,另外追加一台专用于数据层 的服务器。若业务进一步扩大,用户数进一步增加,则可以继续增加功能层的服务器数目,用以分割数据库。清晰、合理地分割三层结构并使其独立,可以使系统构 成的变更非常简单。因此,被分成三层的应用基本上不需要修正。

    2。 提高程序的可维护性

    三层C/S结构中,应用的各层可以并行开发,各层也可以选择各自最适合的开发语言。

    3。 利于变更和维护应用技术规范

    因为是按层分割功能,所以各个程序的处理逻辑变得十分简单。

    4。 进行严密的安全管理

    越关键的应用,用户的识别和存取权限设定愈重要。在三层C/S结构中,识别用户的机构是按层来构筑的,对应用和数据的存取权限也可以按层进行设定。例如,即使外部的入侵者突破了表示层的安全防线,若在功能层中备有另外的安全机构,系统也可以阻止入侵者进入其他部分。

    此外,系统管理简单,可支持异种数据库,有很高的可用性。

     

    C/S和B/S 的优缺点比较

    C/S和B/S是当今世界开发模式技术架构的两大主流技术。C/S是美国 Borland公司最早研发,B/S是美国微软公司研发。目前,这两项技术以被世界各国所掌握,国内公司以C/S和B/S技术开发出产品也很多。这两种技术都有自己一定的市场份额和客户群,各家企业都说自己的管理软件架构技术功能强大、先进、方便,都能举出各自的客户群体,都有一大群文人墨客为自己摇旗呐 喊,广告满天飞,可谓仁者见仁,智者见智。

    1、C/S架构软件的优势与劣势

    (1)、应用服务器运行数据负荷较轻。

    最简单的C/S体系结构的数据库应用由两部分组成,即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序 的机器,也称为应用服务器。一旦服务器程序被启动,就随时等待响应客户程序发来的请求;客户应用程序运行在用户自己的电脑上,对应于数据库服务器,可称为 客户电脑,当需要对数据库中的数据进行任何操作时,客户程序就自动地寻找服务器程序,并向其发出请求,服务器程序根据预定的规则应答,送回结果,应用 服务器运行数据负荷较轻。

    (2)、数据的储存管理功能较为透明。

    在数据库应用中,数据的储存管理功能,是由服务器程序和客户应用程序分别独立进行的,前台应用可以违反的规则,并且通常把那些不同的(不管是已知 还是未知的)运行数据,在服务器程序中不集中实现,例如访问者的权限,编号可以重复、必须有客户才能建立定单这样的规则。所有这些,对于工作在前台程序上 的最终用户,是“透明”的,他们无须过问(通常也无法干涉)背后的过程,就可以完成自己的一切工作。在客户服务器架构的应用中,前台程序不是非常“瘦小 ”,麻烦的事情都交给了服务器和网络。在C/S体系的下,数据库不能真正成为公共、专业化的仓库,它受到独立的专门管理。

    (3)、C/S架构的劣势是高昂的维护成本且投资大。

    首先,采用C/S架构,要选择适当的数据库平台来实现数据库数据的真正“统一”,使分布于两地的数据同步完全交由数据库系统去管理,但逻辑上两地 的操作者要直接访问同一个数据库才能有效实现,有这样一些问题,如果需要建立“实时”的数据同步,就必须在两地间建立实时的通讯连接,保持两地的数据库服 务器在线运行,网络管理工作人员既要对服务器维护管理,又要对客户端维护和管理,这需要高昂的投资和复杂的技术支持,维护成本很高,维护任务量大。

    其次,传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件,由于产品的更新换代十分快,代价高和低效率已经不适应工作需要。在JAVA这样的跨平台语言出现之后,B/S架构更是猛烈冲击C/S,并对其形成威胁和挑战。

    2、B/S架构软件的优势与劣势

    (1)、维护和升级方式简单。

    目前,软件系统的改进和升级越来越频繁,B/S架构的产品明显体现着更为方便的特性。对一个稍微大一点单位来说,系统管理人员如果需要在几百甚至 上千部电脑之间来回奔跑,效率和工作量是可想而知的,但B/S架构的软件只需要管理服务器就行了,所有的客户端只是浏览器,根本不需要做任何的维护。无论 用户的规模有多大,有多少分支机构都不会增加任何维护升级的工作量,所有的操作只需要针对服务器进行;如果是异地,只需要把服务器连接专网即可,实现远程 维护、升级和共享。所以客户机越来越“瘦”,而服务器越来越“胖”是将来信息化发展的主流方向。今后,软件升级和维护会越来越容易,而使用起来会越来越简单,这对用户人力、物力、时间、费用的节省是显而易见的,惊人的。因此,维护和升级革命的方式是“瘦”客户机,“胖”服务器。

    (2)、成本降低,选择更多。

    大家都知道windows在桌面电脑上几乎一统天下,浏览器成为了标准配置,但在服务器操作系统上windows并不是处于绝对的统治地位。现在 的趋势是凡使用B/S架构的应用管理软件,只需安装在Linux服务器上即可,而且安全性高。所以服务器操作系统的选择是很多的,不管选用那种操作系统都 可以让大部分人使用windows作为桌面操作系统电脑不受影响,这就使的最流行免费的Linux操作系统快速发展起来,Linux除了操作系统是免费的 以外,连数据库也是免费的,这种选择非常盛行。

    (3)、应用服务器运行数据负荷较重。

    由于B/S架构管理软件只安装在服务器端(Server)上,网络管理人员只需要管理服务器就行了,用户界面主要事务逻辑在服务器 (Server)端完全通过WWW浏览器实现,极少部分事务逻辑在前端(Browser)实现,所有的客户端只有浏览器,网络管理人员只需要做硬件维护。 但是,应用服务器运行数据负荷较重,一旦发生服务器“崩溃”等问题,后果不堪设想。因此,许多单位都备有数据库存储服务器,以防万一。 

    C/S 与 B/S 区别

          Client/Server是建立在局域网的基础上的,Browser/Server是建立在广域网的基础上的。

    (1)硬件环境不同:

          C/S 一般建立在专用的网络上, 小范围里的网络环境, 局域网之间再通过专门服务器提供连接和数据交换服务。

    B/S 建立在广域网之上的, 不必是专门的网络硬件环境,例如电话上网, 租用设备, 信息自己管理, 有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行。

    (2)、对安全要求不同

          C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强。 一般高度机密的信息系统采用C/S 结构适宜,可以通过B/S发布部分可公开信息。

    B/S 建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群。

    (3)、对程序架构不同

          C/S 程序可以更加注重流程,可以对权限多层次校验,对系统运行速度可以较少考虑。

    B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上。 比C/S有更高的要求,B/S结构的程序架构是发展的趋势,从MS的。Net系列的BizTalk 2000 Exchange 2000等,全面支持网络的构件搭建的系统。SUN和IBM推的JavaBean构件技术等,使B/S更加成熟。

    (4)、软件重用不同

          C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好。

          B/S 对的多重结构,要求构件相对独立的功能。 能够相对较好的重用。就如买来的餐桌可以再利用,而不是做在墙上的石头桌子。

    (5)、系统维护不同

    系统维护是软件生存周期中,开销大,相当重要。C/S 程序由于整体性,必须整体考察,处理出现的问题以及系统升级难, 可能是再做一个全新的系统。 B/S 构件组成方面构件个别的更换,实现系统的无缝升级。系统维护开销减到最小,用户从网上自己下载安装就可以实现升级。

    (6)、处理问题不同

          C/S 程序可以处理用户面固定,并且在相同区域, 安全要求高的需求,与操作系统相关, 应该都是相同的系统。 B/S 建立在广域网上, 面向不同的用户群,分散地域, 这是C/S无法作到的,与操作系统平台关系最小。

    (7)、用户接口不同

          C/S 多是建立在Window平台上,表现方法有限,对程序员普遍要求较高。 B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流, 并且大部分难度减低,降低开发成本。

    (8)、信息流不同

          C/S 程序一般是典型的中央集权的机械式处理,交互性相对低。 B/S 信息流向可变化, B-B、 B-C、 B-G等信息流向的变化, 更像交易中心。

     

    基于层次消息总线的架构风格

    JB/HMB风格的基本特征

    目前对软件体系结构的研究集中在以下方面:各种体系结构风格的汇编和总结、体系结

    构描述语言(architectural description languages,简称ADLS)、体系结构的形式化基础、体系结构分析技术、基于体系结构的软件开发、体系结构恢复和再工程、支持体系结构设计的工具和环境及特定领域的软件体系结构等。 青鸟工程在“九五”期间,对基于构件构架模式的软件工业化生产技术进行了研究,并实现了青鸟软件生产线系统151。以青鸟软件生产线的实践为背景,提出了基于层次消息总线的软件体系结构(Jade bird hierarchical message bus based style,以下简称JB/HMB风格),设计了相应的体系结构描述语言,开发了支持软件体系结构设计的辅助工具集,并研究了采用JB/HMB风格进行应用系统开发的过程框架。

    JB/HMB风格的提出基于以下的实际背景:

    (1) 随着计算机网络技术的发展,特别是分布式构件技术的日渐成熟和构件互操作标准的出现,如CORBA,DCOM和EJB等,加速了基于分布式构件的软件开发趋势,具有分布和并发特点的软件系统已成为一种普遍的应用需求。

    (2) 基于事件驱动的编程模式已在图形用户界面程序设计中获得广泛应用。在此之前的

    程序设计中,通常使用一个大的分支语句(switch Statement)控制程序的转移,对不同的输人情况分别进行处理,程序结构不甚清晰。基于事件驱动的编程模式在对多个不同事件响应的情况下,系统自动调用相应的处理函数,程序具有清晰的结构。

    (3) 计算机硬件体系结构和总线的概念为软件体系结构的研究提供了很好的借鉴和启发,

    在统一的体系结构框架下(即总线和接口规范),系统具有良好的扩展性和适应性。任何计算机厂商生产的配件,甚至是在设计体系结构时根本没有预料到的配件,只要遵循标准的接口规范,都可以方便地集成到系统中,对系统功能进行扩充,甚至是即插即用(即运行时刻的系统演化)。正是标准的总线和接口规范的制定,以及标准化配件的生产,促进了计算机硬件的产业分工和蓬勃发展。

    0?wx_fmt=jpeg

    JB/HMB风格基于层次消息总线、支持构件的分布和并发,构件之间通过消息总线进行通讯,如图所示。消息总线是系统的连接件,负责消息的分派、传递和过滤以及处理结果的返回。各个构件挂接在消息总线上,向总线登记感兴趣的消息类型。构件根据需要发出消息,由消息总线负责把该消息分派到系统中所有对此消息感兴趣的构件,消息是构件之间通讯的唯一方式,构件接收到消息后,根据自身状态对消息进行响应,并通过总线返回处理结果。由于构件通过总线进行连接,并不要求各个构件具有相同的地址空间或局限在一台机器上。该风格可以较好地刻画分布式并发系统,以及基于CORBA,DCOM和EJB规范的系统。

    如图所示,系统中的复杂构件可以分解为比较低层的子构件,这些子构件通过局部消息

    总线进行连接,这种复杂的构件称为复合构件。如果子构件仍然比较复杂,可以进一步分解。

    如此分解下去,整个系统形成了树状的拓扑结构,树结构的末端结点称为叶结点,它们是系统中的原子构件,不再包含子构件,原子构件的内部可以采用不同于JB/HMB的风格,例如数据流风格、面向对象风格及管道/过滤器风格等,这些属于构件的内部实现细节。但要集成到JB/HMB风格的系统中,必须满足JB/HMB风格的构件模型的要求,主要是在接口规约方面的要求。另外,整个系统也可以作为一个构件,通过更高层的消息总线,集成更大的系统中。于是,可以采用统一的方式刻画整个系统和组成系统的单个构件。

    构建模型

    系统和组成系统的成分通常是比较复杂的,难以从一个视角获得对它们的完整理解,因

    此一个好的软件工程方法往往从多个视角对系统进行建模,一般包括系统的静态结构、动态行为和功能等方面。例如,在Rumbaugh等人提出的OMT(object modeling technology)方法中,

    采用了对象模型、动态模型和功能模型刻画系统的以上3个方面。

    借鉴上述思想,为满足体系结构设计的需要,JB/HMB风格的构件模型包括了接口、静态结构和动态行为3个部分,如图所示。

    0?wx_fmt=jpeg

    在图中所示的构件模型中,左上方是构件的接口部分,一个构件可以支持多个不同的接口,每个接口定义了一组输入和输出的消息,刻画了构件对外提供的服务以及要求的环境服务,体现了该构件同环境的交互.右上方是用带输出的有限状态自动机刻画的构件行为,构件接收到外来消息后,根据当前所处的状态对消息进行响应,并可能导致状态的变迁.下方是复合构件的内部结构定义,复合构件是由更简单的子构件通过局部消息总线连接而成的.消息总线为整个系统和各个层次的构件提供了统一的集成机制。

    构件接口

    在体系结构设计层次上,构件通过接口定义了同外界的信息传递和承担的系统责任,构件接口代表了构件同环境的全部交互内容,也是唯一的交互途径.除此之外,环境不应对构件做任何其他与接口无关的假设,例如实现细节等。JB/HMB风格的构件接口是一种基于消息的互联接口,可以较好地支持体系结构设计。

    构件之间通过消息进行通讯,接口定义了构件发出和接收的消息集合.同一般的互联接口相比.JB/HMB的构件接口具有两个显著的特点.首先,构件只对消息本身感兴趣,并不关心消息是如何产生的,消息的发出者和接收者不必知道彼此的情况,这样就切断了构件之间的直接联系,降低了构件之间的藕合强度,进一步增强了构件的复用潜力,并使得构件的替换变得更为容易。另外,在一般的互联接口定义的系统中,构件之间的连接是在要求的服务和提供的服务之间进行固定的匹配,而在JB/HMB的构件接口定义的系统中,构件对外来消息的响应,不但同接收到的消息类型相关,而且同构件当前所处的状态相关.构件对外来消息进行响应后,可能会引起状态的变迁.因此,一个构件在接收到同样的消息后,在不同时刻所处的不同状态下,可能会有不同的响应。

    消息是关于某个事件发生的信息,上述接口定义中的消息分为两类:(i)构件发出的消息,通知系统中其他构件某个事件的发生或请求其他构件的服务;(ii)构件接收的消息,对系统中某个事件的响应或提供其他构件所需的服务.接口中的每个消息定义了构件的一个端口,具有互补端口的构件可以通过消息总线进行通讯,互补端口指的是除了消息进出构件的方向不同之外,消息名称、消息带有的参数和返回结果的类型完全相同的两个消息. 当某个事件发生后,系统或构件发出相应的消息,消息总线负责把该消息传递到对此消息感兴趣的构件.按照响应方式的不同,消息可分为同步消息和异步消息.同步消息是指消息的发送者必须等待消息处理结果返回才可以继续运行的消息类型.异步消息是指消息的发送者不必等待消息处理结果的返回即可继续执行的消息类型.常见的同步消息包括(一般的)过程调用。 消息总线

    JB/HMB风格的消息总线是系统的连接件,构件向消息总线登记感兴趣的消息,形成构件-消息响应登记表.消息总线根据接收到的消息类型和构件一消息响应登记表的信息,定位并传递该消息给相应的响应者,并负责返回处理结果.必要时,消息总线还对特定的消息进行过滤和阻塞.下图给出了采用对象类符号表示的消息总线的结构。

    0?wx_fmt=jpeg

    在许多重要的应用领域中,例如金融、电力、电信及空中交通管制等,系统的持续可用性是一个关键性的要求,运行时刻的系统演化可减少因关机和重新启动而带来的损失和风险。此外,越来越多的其他类型的应用软件也提出了运行时刻演化的要求,在不必对应用软件进行重新编译和加载的前提下,为最终用户提供系统定制和扩展的能力。JBI/HMB风格方便地支持运行时刻的系统演化,主要体现在以下3个方面:

    (1) 动态增加或删除构件。在JB/HMB风格的系统中,构件接口中定义的输人和输出消息刻画了一个构件承担的系统责任和对外部环境的要求,构件之间通过消息总线进行通讯,彼此并不知道对方的存在。因此只要保持接口不变,构件就可以方便地替换。一个构件加人到系统中的方法很简单,只需向系统登记其所感兴趣的消息即可。但删除一个构件可能会引起系统中对于某些消息没有构件响应的异常情况,这时可以采取两种措施:一是阻塞那些没有构件响应的消息,二是首先使系统中的其他构件或增加新的构件对该消息进行响应,然后再删除相应的构件。系统中可能增删改构件的情况包括:当系统功能需要扩充时,往系统中增加新的构件。当对系统功能进行裁剪,或当系统中的某个构件出现问题时,需要删除系统中的某个构件。用带有增强功能或修正了错误的构件新版本代替原有的旧版本。

    (2) 动态改变构件响应的消息类型。类似地,构件可以动态地改变对外提供的服务(即接收的消息类型),这时应通过消息总线对发生的改变进行重新登记。

    (3) 消息过滤。利用消息过滤机制,可以解决某些构件集成的不匹配问题,详见“消息过滤”一节。消息过滤通过阻塞构件对某些消息的响应,提供了另一种动态改变构件对消息进行响应的方式。

    JB/HMB风格的优点

    以上讨论了JB/HMB风格的各组成要素,下面对JB/HMB风格的主要特点作总结。

    (1) 从接口、结构和行为方面对构件进行刻画。在JB/HMB风格中,构件的描述包括接口、静态结构和动态行为3个方面。接口:构件可以提供一个或多个接口,每个接口定义了一组发送和接收的消息集合,刻画了构件对外提供的服务以及要求的环境服务,接口之间可以通过继承表达相似性。

    静态结构:复合构件是由子构件通过局部消息总线连接而成的,形成该复合构件的内部结构。

    动态行为:构件行为通过带输出的有限状态机刻画,构件接收到外来消息后,不但根

    据消息类型,而且根据构件当前所处的状态对消息进行响应,并导致状态的变迁。

    基于层次消息总线:消息总线是系统的连接件,负责消息的传递、过滤和分派,以及

    处理结果的返回。各个构件挂接在总线上,向系统登记感兴趣的消息。构件根据需要发出消息,由消息总线负责把该消息分派到系统中对此消息感兴趣的所有构件。构件接收到消息后,根据自身状态对消息进行响应,并通过总线返回处理结果。由于构件通过总线进行连接,并不要求各个构件具有相同的地址空间或局限在一台机器上,系统具有并发和分布的特点。系统和复合构件可以逐层分解,子构件通过(局部)消息总线相连。每条消息总线分别属于系统和各层次的复合构件,我们把这种特征的总线称为层次消息总线。在系统开发方面,由于各层次的总线局部在相应的复合构件中,因此可以更好地支持系统的构造性和演化性。

    统一描述系统和组成系统的构件:组成系统的构件通过消息总线进行连接,复杂构

    件又可以分解为比较简单的子构件,通过局部消息总线进行连接,如果子构件仍然比较复杂,

    可以进一步分解。系统呈现出树状的拓扑结构。另外,整个系统也可以作为一个构件,集成到更大的系统中。于是,就可以对整个系统和组成系统的各层构件采用统一的方式进行描述。

    支持运行时刻的系统演化:系统的持续可用性是许多重要的应用系统的一个关键性

    要求,运行时刻的系统演化可减少因关机和重新启动而带来的损失和风险。JB/HMB风格方便地支持运行时刻的系统演化,主要包括动态增加或删除构件、动态改变构件响应的消息类型和消息过滤。

    REST架构风格

    首先,REST是Web自身的架构风格。REST也是Web之所以取得成功的技术架构方面因素的总结。REST是世界上最成功的分布式应用架构风格(成功案例:Web,还不够吗?)。它是为运行在互联网环境 的 分布式 超媒体系统量身定制的。互联网环境与企业内网环境有非常大的差别,最主要的差别是两个方面:

    • 可伸缩性需求无法控制:并发访问量可能会暴涨,也可能会暴跌。

    • 安全性需求无法控制:无法控制客户端发来的请求的格式,很可能会是恶意的请求。

    而所谓的“超媒体系统”,即,使用了超文本的系统。可以把“超媒体”理解为超文本+媒体内容。

    REST是HTTP/1.1协议等Web规范的设计指导原则,HTTP/1.1协议正是为实现REST风格的架构而设计的。新的Web规范,其设计必须符合REST的要求,否则整个Web的体系架构会因为引入严重矛盾而崩溃。这句话不是危言耸听,做个类比,假如苏州市政府同意在市区著名园林的附近大型土木,建造大量具有后现代风格的摩天大楼,那么不久之后世界闻名的苏州园林美景将不复存在。

    上述这些关于“REST是什么”的描述,可以总结为一句话:REST是所有Web应用都应该遵守的架构设计指导原则。当然,REST并不是法律,违反了REST的指导原则,仍然能够实现应用的功能。但是违反了REST的指导原则,会付出很多代价,特别是对于大流量的网站而言。

    要深入理解REST,需要理解REST的五个关键词:

    1. 资源(Resource)

    2. 资源的表述(Representation)

    3. 状态转移(State Transfer)

    4. 统一接口(Uniform Interface)

    5. 超文本驱动(Hypertext Driven)

    什么是资源?

    资源是一种看待服务器的方式,即,将服务器看作是由很多离散的资源组成。每个资源是服务器上一个可命名的抽象概念。因为资源是一个抽象的概念,所以它不仅仅能代表服务器文件系统中的一个文件、数据库中的一张表等等具体的东西,可以将资源设计的要多抽象有多抽象,只要想象力允许而且客户端应用开发者能够理解。与面向对象设计类似,资源是以名词为核心来组织的,首先关注的是名词。一个资源可以由一个或多个URI来标识。URI既是资源的名称,也是资源在Web上的地址。对某个资源感兴趣的客户端应用,可以通过资源的URI与其进行交互。

    什么是资源的表述?

    资源的表述是一段对于资源在某个特定时刻的状态的描述。可以在客户端-服务器端之间转移(交换)。资源的表述可以有多种格式,例如HTML/XML/JSON/纯文本/图片/视频/音频等等。资源的表述格式可以通过协商机制来确定。请求-响应方向的表述通常使用不同的格式。

    什么是状态转移?

    状态转移(state transfer)与状态机中的状态迁移(state transition)的含义是不同的。状态转移说的是:在客户端和服务器端之间转移(transfer)代表资源状态的表述。通过转移和操作资源的表述,来间接实现操作资源的目的。

    什么是统一接口?

    REST要求,必须通过统一的接口来对资源执行各种操作。对于每个资源只能执行一组有限的操作。以HTTP/1.1协议为例,HTTP/1.1协议定义了一个操作资源的统一接口,主要包括以下内容:

    • 7个HTTP方法:GET/POST/PUT/DELETE/PATCH/HEAD/OPTIONS

    • HTTP头信息(可自定义)

    • HTTP响应状态代码(可自定义)

    • 一套标准的内容协商机制

    • 一套标准的缓存机制

    • 一套标准的客户端身份认证机制

    REST还要求,对于资源执行的操作,其操作语义必须由HTTP消息体之前的部分完全表达,不能将操作语义封装在HTTP消息体内部。这样做是为了提高交互的可见性,以便于通信链的中间组件实现缓存、安全审计等等功能。

    什么是超文本驱动?

    “超文本驱动”又名“将超媒体作为应用状态的引擎”(Hypermedia As The Engine Of Application State,来自Fielding博士论文中的一句话,缩写为HATEOAS)。将Web应用看作是一个由很多状态(应用状态)组成的有限状态机。资源之间通过超链接相互关联,超链接既代表资源之间的关系,也代表可执行的状态迁移。在超媒体之中不仅仅包含数据,还包含了状态迁移的语义。以超媒体作为引擎,驱动Web应用的状态迁移。通过超媒体暴露出服务器所提供的资源,服务器提供了哪些资源是在运行时通过解析超媒体发现的,而不是事先定义的。从面向服务的角度看,超媒体定义了服务器所提供服务的协议。客户端应该依赖的是超媒体的状态迁移语义,而不应该对于是否存在某个URI或URI的某种特殊构造方式作出假设。一切都有可能变化,只有超媒体的状态迁移语义能够长期保持稳定。

     

    0?wx_fmt=png 

    理解REST风格的架构所具有的6个的主要特征:

    • 面向资源(Resource Oriented)

    • 可寻址(Addressability)

    • 连通性(Connectedness)

    • 无状态(Statelessness)

    • 统一接口(Uniform Interface)

    • 超文本驱动(Hypertext Driven)

    这6个特征是REST架构设计优秀程度的判断标准。其中,面向资源是REST最明显的特征,即,REST架构设计是以资源抽象为核心展开的。可寻址说的是:每一个资源在Web之上都有自己的地址。连通性说的是:应该尽量避免设计孤立的资源,除了设计资源本身,还需要设计资源之间的关联关系,并且通过超链接将资源关联起来。无状态、统一接口是REST的两种架构约束,超文本驱动是REST的一个关键词,在前面都已经解释过,就不再赘述了。

    从架构风格的抽象高度来看,常见的分布式应用架构风格有三种:

    • 分布式对象(Distributed Objects,简称DO)

    架构实例有CORBA/RMI/EJB/DCOM/.NET Remoting等等

    • 远程过程调用(Remote Procedure Call,简称RPC)

    架构实例有SOAP/XML-RPC/Hessian/Flash AMF/DWR等等

    • 表述性状态转移(Representational State Transfer,简称REST)

    架构实例有HTTP/WebDAV

    DO和RPC这两种架构风格在企业应用中非常普遍,而REST则是Web应用的架构风格,它们之间有非常大的差别。 

    REST与DO的差别在于:

    • REST支持抽象(即建模)的工具是资源,DO支持抽象的工具是对象。在不同的编程语言中,对象的定义有很大差别,所以DO风格的架构通常都是与某种编程语言绑定的。跨语言交互即使能实现,实现起来也会非常复杂。而REST中的资源,则完全中立于开发平台和编程语言,可以使用任何编程语言来实现。

    • DO中没有统一接口的概念。不同的API,接口设计风格可以完全不同。DO也不支持操作语义对于中间组件的可见性。

    • DO中没有使用超文本,响应的内容中只包含对象本身。REST使用了超文本,可以实现更大粒度的交互,交互的效率比DO更高。

    • REST支持数据流和管道,DO不支持数据流和管道。

    • DO风格通常会带来客户端与服务器端的紧耦合。在三种架构风格之中,DO风格的耦合度是最大的,而REST的风格耦合度是最小的。REST松耦合的源泉来自于统一接口+超文本驱动。

    REST与RPC的差别在于:

    • REST支持抽象的工具是资源,RPC支持抽象的工具是过程。REST风格的架构建模是以名词为核心的,RPC风格的架构建模是以动词为核心的。简单类比一下,REST是面向对象编程,RPC则是面向过程编程。

    • RPC中没有统一接口的概念。不同的API,接口设计风格可以完全不同。RPC也不支持操作语义对于中间组件的可见性。

    • RPC中没有使用超文本,响应的内容中只包含消息本身。REST使用了超文本,可以实现更大粒度的交互,交互的效率比RPC更高。

    • REST支持数据流和管道,RPC不支持数据流和管道。

    • 因为使用了平台中立的消息,RPC风格的耦合度比DO风格要小一些,但是RPC风格也常常会带来客户端与服务器端的紧耦合。支持统一接口+超文本驱动的REST风格,可以达到最小的耦合度。

    比较了三种架构风格之间的差别之后,从面向实用的角度来看,REST架构风格可以为Web开发者带来三方面的利益:

    • 简单性

    采用REST架构风格,对于开发、测试、运维人员来说,都会更简单。可以充分利用大量HTTP服务器端和客户端开发库、Web功能测试/性能测试工具、HTTP缓存、HTTP代理服务器、防火墙。这些开发库和基础设施早已成为了日常用品,不需要什么火箭科技(例如神奇昂贵的应用服务器、中间件)就能解决大多数可伸缩性方面的问题。

    • 可伸缩性

    充分利用好通信链各个位置的HTTP缓存组件,可以带来更好的可伸缩性。其实很多时候,在Web前端做性能优化,产生的效果不亚于仅仅在服务器端做性能优化,但是HTTP协议层面的缓存常常被一些资深的架构师完全忽略掉。

    • 松耦合

    统一接口+超文本驱动,带来了最大限度的松耦合。允许服务器端和客户端程序在很大范围内,相对独立地进化。对于设计面向企业内网的API来说,松耦合并不是一个很重要的设计关注点。但是对于设计面向互联网的API来说,松耦合变成了一个必选项,不仅在设计时应该关注,而且应该放在最优先位置。

     

    架构风格和架构模式之间的细微差别

    • 架构风格是系统主要的、组织性的设计。

    • 架构模式从子系统或模块、及其之间的关系层次上描述了粗粒度的解决方案。

    • 系统隐喻则更为概念化,比起软件工程概念,它更多地涉及现实世界的概念。

     

    David Calvert在1996年给出了一份架构风格/模式的部分清单:

    • 数据流系统——批处理,管道-过滤器。

    • 调用-返回系统——主程序和子程序,面向对象系统,分层。

    • 独立组件——通信过程,事件系统。

    • 虚拟机——解释器,基于规则的系统。

    • 以数据为中心的系统(仓库)——数据库,超文本系统,黑板。

    出处:http://www.cnblogs.com/wintersun/p/4355267.html

    展开全文
  • 由于基于总线的模型是一种集中式的架构,总线自身容易形成性能瓶颈,而且在实现高可用和容错性方面的复杂度和成本相对较高。所以,该模式并不是很适合于高并发、高性能、高吞吐量的互联网应用。   注:关于消息总线...

    曾今SOA的概念犹如今日“云计算、大数据”一样,被炒得火热,不少企业便纷纷响应,并宣称会拥抱和实施SOA。而事实上,业界出现了两种极端:一种是由于各类文章和书籍关于SOA的描述往往太过抽象,再加上各大厂商的呼吁,使得SOA往往显得“高大上”,令不少企业和架构师们望而却步。第二种恰好相反,有部分人却认为SOA无非是“新瓶装旧酒”。

     

    个人理解,SOA在宏观上确实太复杂,因为它涉及到的不仅仅是技术和架构本身。而从技术的视角来看,并非难以落地。

     

    SOA全称“面向服务架构”,它提供的是一种架构风格和理念,而并非是一种技术或者产品。并不是说项目中用了WebService、WCF、Hessian、RMI之类的就是SOA了。

    通俗点来讲,SOA提倡将不同应用程序的业务功能封装成“服务”并宿主起来,通常以接口和契约的形式暴露并提供给外界应用访问(通过交换消息),达到不同系统可重用的目的。

    流行的WebService等可以看作是实现SOA基础设施的技术方法。当然,实践SOA不仅需要解决服务调用的问题,还包括服务编排、服务治理、服务路由、服务监控等一系列的问题。在大型分布式系统中,SOA被广泛实践,但是在不同的应用场景中,设计方法也大不相同。

     

    SOA是一个组件模型,它能将不同的服务通过定义良好的接口和契约联系起来。服务是SOA的基石,在开始服务设计和SOA实践之前,有必要先了解服务的概念以及服务的常见特性。

     

     

    何为服务

    服务的概念非常宽泛,在宏观上,服务的理解是“为他人做事,满足他人需要,而且通常是不以实物形式提供劳动的…”。在SOA系统中,服务指的是应用程序的功能单元,它通常体现了业务功能。服务是一种抽象,它向服务使用者隐藏了服务内部的实现细节。根据服务设计的基本原则,服务可能会具有以下特性:

    l  自治(理)性 

    服务应该是独立部署和运行存在的,且边界清晰,应尽量减少对外部的引用和依赖。

    l  粗粒度

    服务调用是需要开销的,这也是实现松耦合的分布式系统必须付出的代价。因此,应尽量通过一次服务调用传输所有需要的数据,而不是分多次去调用服务和组装数据。

    l  可见性

    服务是对外提供的,必须在某公共的地方可搜寻和发现,且服务要有必要的描述。

    l  无状态

    服务不应该依赖于其他服务的上下文、会话等,尽量减少不必要的状态管理流程所带来的资源消耗。但是,对于业务流程服务而言,状态数据是不可避免的。

    l  幂等性

    当消费者调用服务后,服务调用可能会有“成功、失败、超时”这三种状态,当服务并没有最终响应完成时,消费者可以尝试反复地调用服务,这样仍不会影响到最终结果。

    l  可重用性

    服务应该是可以被重用的,相同功能应可以调用相同的服务,这也是软件设计的原则。

    l  可组合

    服务是可以被当作成一个步骤的,服务也可以调用其它的服务。这样能够灵活的组合。

     

    有关服务的“粗粒度、无状态、幂等性”等特性,一直是饱受争议的话题,可谓见仁见智。这里有必要说明下,这些特性并不是服务不可或缺的,应当在实践中根据需求来取舍。

    SOA所面临的问题

    SOA架构将公共的业务拆分出来,形成可共用的服务,最大程度的保障了代码和逻辑的复用,避免了系统的重复建设,并且让应用程序的部署找到了一种持续可扩展的方案,给应用抗负载能力带来了质的飞跃。

    SOA架构所面临的一大问题就是如何解决集成服务应用普遍存在的一致性问题,举例来说,同时调用多个服务,当其中一个服务调用失败时,其他服务已经处理执行的结果该如何进行回滚,这在单机本地调用的情况下使用事务比较好处理,而分布式环境下的事务将问题复杂化,并且性能开销难以承受,因此,只有在极端情况下才会考虑强一致性,一般情况下更多的关注最终一致性。另外一个就是安全问题,面向企业的平台级的SOA架构,需要对参数传递、响应内容以及各种用户私有信息的交互,有着更严格的且特殊的安全需求,如何构建一个安全的SOA架构体系,也给技术人员带来了很大的挑战。

    在讲了很多“大而空”的理论之后,估计很多人要拍砖了。后面文章中将会讲一些干货,更贴合实际应用。先预告一下后面文章:

    1.SOA之基于服务总线的设计

    (从设计的角度讲述服务总线--比较适合企业级系统集成的设计方式)

    2.大型分布式网站的演变历程

    (随着网站快速发展,解决业务复杂化、大流量、稳定性等问题的必经之路。正所谓“天下大势,分久必合,合久必分”。

    重点不是讲负载均衡这些手段,而是设计层面的“集中式”到“分布式”)

    3.SOA架构体系之通信协议和远程调用(RPC)

    (讲解具体的实现技术,对比各自优缺点)

    4.SOA之基于服务框架的应用

    (服务化实践--介绍流行的服务框架,重点演示一种服务框架的使用)


    基于服务总线的设计

    基于总线的设计,借鉴了计算机内部硬件组成的设计思想(通过总线传输数据)。在分布式系统中,不同子系统之间需要实现相互通信和远程调用,比较直接的方式就是“点对点”的通信方式,但是这样会暴露出一些很明显的问题:系统之间紧密耦合、配置和引用混乱、服务调用关系错综复杂、难以统一管理、异构系统之间存在不兼容等。而基于总线的设计,正是为了解决上述问题。总线则作为中枢系统,提供统一的服务入口,并实现了服务统一管理、服务路由、协议转换、数据格式转换等功能。这样能够将不同系统有效地连接起来,并大大降低了连接数(每个子系统只需要和总线建立连接)和系统间连接拓扑的复杂度。如图所示:

    0?wx_fmt=jpeg

     

    基于服务总线的设计,往往需要ESB(Enterprise Service Bus,企业服务总线)产品来充当基础设施。ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构,以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态的互连互通。 ESB是一种在松散耦合的服务和应用之间标准的集成方式。

    在其内部设计和实现中,通常会应用到一些经典的架构模式,例如:Broker模式、消息总线模式、管道过滤器模式、发布订阅模式等。这里,我们将重点介绍这几种核心的架构模式。

    Broker模式

    Broker可以看作是服务总线中的一部分,通常应用于同步调用的场景(调用服务后阻塞,等待远程服务响应完成后再返回结果)。Broker可以看作是代理、分发,意味着对服务的调用,可以直接通过Broker来完成。在软件架构设计中,向已经存在(引用或者调用)关系的两者中间加入“第三者”是一种常见的解耦方式,显然,Broker也不例外。如下图所示:

     0?wx_fmt=jpeg

    为了进一步加深读者对Broker模式的理解,这里通过举例来说明:

    在现实生活中,我们需要租房子(可以看作是一种服务调用),可以通过几种途径来完成。第一,我们可以先在网上了解,然后跑到目标小区去询问和看房,最后再找房东签合同等;第二,也可以直接找附近的地产中介,说出我们的要求和预算,请中介直接帮我们搞定一切。很明显,第一种方式,需要自己对目标有足够的了解而且还要亲自去找房东签合同(依赖具体,可以看作是紧密耦合),而第二种方式,仅仅需要告知中介需要什么即可完成租房,甚至都不需要知道哪个小区有房子、房东到底是谁等这些信息(依赖抽象,并通过第三者来实现解耦)。当然,找中介虽然省事,也会产生额外的经济开销。同理,通过Broker来调用服务也可能会产生一定的开销。

     

    消息总线模式

     

    SOA系统有三种基础组件:消息总线、信息转换/处理引擎和存储库。一般来说,这些组件会集成到ESB中,而在这些基础组件中,消息总线是最重要的。消息总线主要应用于异步通信场景(投递消息后立刻返回结果,而不用等待远程系统返回执行成功),可以大大提升响应速度和系统吞吐量。当然,消息总线也同时支持同步通信模式。基于消息总线模式的设计中,消息中间件屏蔽了系统间底层通信的细节,是比较典型的(异步)松耦合的架构。

    在企业中,随着业务的逐渐发展,各大系统之间的调用交互变得非常频繁,关系错综复杂。

    想象如果有几十或者上百个系统(在保险、金融领域很常见),将变得难以维护。通过引入消息中间件,便能有效的解决这些问题。不同系统之间,只需要连接到消息总线,能保证成功投递/接收消息即可。对于消息投递者(生产者)而言,根本不用关心消息的接收者(消费者)到底有哪些,也不用关心消费者接收到消息之后该如何处理。对于接收者(消费者)而言,只需要关注与自己有关的消息,接收到消息后并做出相应的处理即可。如下图所示:

    0?wx_fmt=jpeg

    比较典型的应用场景:张三在CRM系统中录入了一条客户签约订单的信息并审核通过后,CRM系统会向消息总线投递一条消息(消息中包含必要信息,例如员工ID,订单编号,产品编号和交易金额等,而CRM系统不用关心有哪些系统会接受到该消息)。员工绩效奖金管理系统订阅了该消息主题,收到消息通知后开始处理(给张三执行加奖金操作),同时,进销存系统收到消息通知后也会即时地更新商品库存的数量。这样,便实现异构系统之间的松耦合、异步通信。当然,真实场景可能比这里更复杂,但是实现思路上都大同小异。

     

    在理解了上述实例之后,有必要了解下Java EE中被广泛应用和实现的JMS(Java消息服务)。

    JMS是一种关于消息的规范,业界流行的ActiveMQ则是实现了JMS规范的开源消息总线。

    JMS支持两种模式:发布/订阅模式和队列模式(点对点模式)。其中,发布/订阅模式借鉴了现实生活中的出版社(发布图书)和读者(订阅图书),消息的消费者(读者)只需要订阅自己感兴趣的消息(图书)即可,消息生产者(出版社)生产(出版)了消费者(读者)感兴趣的新消息(新书)后,会通知消费者(读者)接受处理。在JMS发布/订阅模式中,通常以Topic(主题)来标识消息,是一对多的模式,意味着同一个主题可以同时被多个消费者来订阅和消费。而在JMS 队列模型中,通常以Queue name来标识消息,是一对一的模型,意味着同一条消息只能被一个消费者接收并消费(且只能被消费一次)。在生产者和消费者都是集群的环境中,通常需要将这两种模式结合起来使用,情况会复杂很多,而且需要考虑容错性、负载均衡、消息一致性、消息优先级等复杂的问题。

    业界主流的消息总线(消息中间件)产品,普遍支持消息过滤、自动重试、分布式事务、持久化、消息优先级、消息回溯、(生产者/消费者/中间件自身)集群、故障转移等高级特性。

     

     

    总结

     

    基于总线架构的主要优势在于:

    l  可扩展性

    使用消息架构,可以在不影响现有应用的情况下增加或移除应用。

    l  低复杂度

    每个应用只需要和总线通信,只有1个连接点,降低了应用程序集成的复杂度。

    l  灵活性

    对于构成复杂处理的应用程序通信组来说,只需要改变配置和控制路由参数就能满足业务逻辑或者需求变更,而不需要更改服务本身。

    l  松耦合

    应用程序直接和消息总线通信,不依赖其它应用程序,因此可以替换和修改。

    l  可扩展性

    可以把多个应用程序附加到总线上,进行并发处理,达到负载均衡的目的。

     

    基于总线的模型,可以面向同构和异构系统(跨平台)。当前主要应用于传统企业应用的整合与系统集成中(例如:电信、保险、金融等行业)。由于基于总线的模型是一种集中式的架构,总线自身容易形成性能瓶颈,而且在实现高可用和容错性方面的复杂度和成本相对较高。所以,该模式并不是很适合于高并发、高性能、高吞吐量的互联网应用。

     

    注:关于消息总线(消息中间件)的知识点很多,在实际应用中还有很多更加深入和复杂的细节问题。由于篇幅问题,笔者就不做过多的细节介绍和展开,感兴趣的读者,可以自行去查阅相关资料或者参考开源产品,做深入的学习和研究。

    ESB产品主要包括:开源Mule ESB、ServiceMix、JBoss ESB,商业的Oracle ESB、BEA AquaLogic ServiceBus,.NET领域的NService Bus、MassTransit等。

    MQ产品主要包括:ActiveMQ、RabbiteMQ、ZeroMQ、RocketMQ、Kafka、MSMQ等。

    出处:http://blog.csdn.net/dinglang_2009/article/details/44516657

    展开全文
  • 软件体系结构风格介绍

    千次阅读 2020-02-18 12:46:38
    文章目录软件体系结构风格介绍(一)管道和过滤器风格(二)数据抽象与面向对象风格(三)基于事件的隐式调用风格(四)层次系统风格(五)仓库风格(六)C2风格(七)基于层次消息总线的架构风格 软件体系结构风格...

    软件体系结构风格介绍

    软件结构风格的定义:软件结构风格是描述某一特定应用领域中系统组织方式的惯用模式(idiomatic paradigm)。体系结构风格定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件组合起来的。体系结构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一租个完整的系统。按这种方式理解,软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

    构件的定义:构件是具有某种功能的可重用的软件模板单元,表示了系统中主要的计算元素和数据存储。构件有两种:复合构件和原子构件,复合构件由其他复合构件和原子构件通过连接而成;原子构件是不可再分的构件,底层由实现该构件的类组成,这种构件的划分提供了体系结构的分层表示能力,有助于简化体系结构的设计。

    接件的定义:连接件表示了构件之间的交互,简单的连接件如管道(pipe)、过程调用(proceduce call)、事件广播(event broadcast)等,更为复杂的交互如客户-服务器(client-server)通信协议,数据库和应用之间的SQL连接等。

    软件体系结构风格的四要素:
    (1)提供一个词汇表;
    (2)定义一套配置规则;
    (3)定义一套语义解释规则;
    (4)定义对基于这种风格的系统所进行的分析。

    软件体系结构风格的目的:软件体系结构风格为大粒度的软件重用提供了可能。

    软件体系结构设计的一个中心问题是能否重用软件体系结构模式,或者采用某种软件体系结构风格。有原则地使用软件体系结构风格具有如下意义:

    • 它促进了设计的复用,使得一些经过实践证实的解决方案能够可靠地解决新问题。
    • 它能够带来显著的代码复用,使得体系结构风格中的不变部分可共享同一个解决方案。
    • 便于设计者之间的交流与理解。
    • 通过对标准风格的使用支持了互操作性,以便于相关工具的集成。
    • 在限定了设计空间的情况下,能够对相关风格作出分析。
    • 能够对特定的风格提供可视化支持。

    与此同时,人们目前尚不能准确回答的问题是:

    • 系统设计的哪个要点可以用风格来描述;
    • 能否用系统的特性来比较不同的风格,如何确定用不同的风格设计系统之间的互操作;
    • 能否开发出通用的工具来扩展风格;
    • 如何为一个给定的问题选择恰当的体系结构风格,或者如何通过组合现有的若干风格来产生一个新的风格。

    M.Shaw等人根据此框架给出了管道与过滤器、数据抽象和面向对象组织、基于事件的隐式调用、分层系统、仓库系统及知识库和表格驱动的解释器等一些常见的软件体系结构风格。

    (一)管道和过滤器风格

    在管道/过滤器风格的软件体系结构中,每个构件都有一组输入和输出,构件读输入的数据流,经过内部处理,然后产生输出数据流。这个过程通常通过对输入流的变换及增量计算来完成,所以在输入被完全消费之前,输出便产生了。因此,这里的构件被称为过滤器,这种风格的连接件就像是数据流传输的管道,将一个过滤器的输出传到另一过滤器的输入。此风格特别重要的 过滤器必须是独立的实体,它不能与其它的过滤器共享数据,而且一个过滤器不知道它上游和下游的标识。一个管道/过滤器网络输出的正确性并不依赖于过滤器进 行增量计算过程的顺序。

    图2-1是管道/过滤器风格的示意图。一个典型的管道/过滤器体系结构的例子是以Unix shell编写的程序。Unix既提供一种符号,以连接各组成部分(Unix的进程),又提供某种进程运行时机制以实现管道。另一个著名的例子是传统的编译器。传统的编译器一直被认为是一种管道系统,在该系统中,一个阶段(包括词法分析、语法分析、语义分析和代码生成)的输出是另一个阶段的输入。

    在这里插入图片描述
    图 2‑1管道/过滤器风格的体系结构

    举例:媒体播放器
    在这里插入图片描述
    还有编译器
    在这里插入图片描述

    管道/过滤器风格的软件体系结构具有许多很好的特点:

    (1) 使得软构件具有良好的隐蔽性和高内聚、低耦合的特点;
    (2) 允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成;
    (3) 支持软件重用。重要提供适合在两个过滤器之间传送的数据,任何两个过滤器都可被连接起来;
    (4) 系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来;旧的可以被改进的过滤器替换掉;
    (5) 允许对一些如吞吐量、死锁等属性的分析;
    (6) 支持并行执行。每个过滤器是作为一个单独的任务完成,因此可与其它任务并行执行。

    但是,这样的系统也存在着若干不利因素。

    (1) 通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据,但它们是独立的,所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
    (2) 不适合处理交互的应用。当需要增量地显示改变时,这个问题尤为严重。
    (3) 因为在数据传输上没有通用的标准,每个过滤器都增加了解析和合成数据的工作,这样就导致了系统性能下降,并增加了编写过滤器的复杂性

    (二)数据抽象与面向对象风格

    抽象数据类型概念对软件系统有着重要作用,目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上,数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象,或者说是抽象数据类型的实例。对象是一种被称作管理者的构件,因为它负责保持资源的完整性。对象是通过函数和过程的调用来交互的。

    图2-2是数据抽象和面向对象风格的示意图。
    在这里插入图片描述
    图 2‑2数据抽象和面向对象风格的体系结构

    面向对象的系统有许多的优点,并早已为人所知:

    (1) 因为对象对其它对象隐藏它的表示,所以可以改变一个对象的表示,而不影响其它的对象。
    (2) 设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。

    但是,面向对象的系统也存在着某些问题:

    (1) 为了使一个对象和另一个对象通过过程调用等进行交互,必须知道对象的标识。只要一个对象的标识改变了,就必须修改所有其他明确调用它的对象。
    (2) 必须修改所有显式调用它的其它对象,并消除由此带来的一些副作用。例如,如果A使用了对象B,C也使用了对象B,那么,C对B的使用所造成的对A的影响可能是料想不到的。

    (三)基于事件的隐式调用风格

    基于事件的隐式调用风格的思想是构件不直接调用一个过程,而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程,这样,一个事件的触发就导致了另一模块中的过程的调用。

    从体系结构上说,这种风格的构件是一些模块,这些模块既可以是一些过程,又可以是一些事件的集合。过程可以用通用的方式调用,也可以在系统事件中注册一些过程,当发生这些事件时,过程被调用。

    支持基于事件的隐式调用的应用系统很多。例如,在编程环境中用于集成各种工具,在数据库管理系统中确保数据的一致性约束,在用户界面系统中管理数据,以及在编辑器中支持语法检查。例如在某系 统中,编辑器和变量监视器可以登记相应Debugger的断点事件。当Debugger在断点处停下时,它声明该事件,由系统自动调用处理程序,如编辑程 序可以卷屏到断点,变量监视器刷新变量数值。而Debugger本身只声明事件,并不关心哪些过程会启动,也不关心这些过程做什么处理。

    隐式调用系统的主要优点有:

    (1) 为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时,只需将它注册到系统的事件中。
    (2) 为改进系统带来了方便。当用一个构件代替另一个构件时,不会影响到其它构件的接口。

    隐式调用系统的主要缺点有:

    (1) 构件放弃了对系统计算的控制。一个构件触发一个事件时,不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成,它也不能保证这些过程被调用的顺序。
    (2) 数据交换的问题。有时数据可被一个事件传递,但另一些情况下,基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下,全局性能和资源管理便成了问题。
    (3) 既然过程的语义必须依赖于被触发事件的上下文约束,关于正确性的推理存在问题。

    Java的Swing、安卓以及JavaScript 事件的注册与监听都体现了此风格。基于事件的隐式调用风格特点很明显:事件的触发者并不知道哪些构件会被这些事件影响:不能假定构件的处理顺序,甚至不知道哪些过程会被调用;为此,许多隐式调用的系统也包含显式调用作为构件交互的补充形式。

    支持隐式调用的系统可以举出这些

    1. 在编程环境中用于集成各种工具。(集成开发环境)
    2. 在数据库管理系统中确保数据的一致性约束。
    3. 在用户界面系统中管理数据。
    4. 在编辑器中支持语法检查等。

    (四)层次系统风格

    层次系统组织成一个层次结构,每一层为上层服务,并作为下层客户。在一些层次系统中,除了一些精心挑选的输出函数外,内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机(在另一些层次系统中层是部分不透明的)。连接件通过决定层间如何交互的协议来定义,拓扑约束包括对相邻层间交互的约束。

    这种风格支持基于可增加抽象层的设计。这样,允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层,同时只要给相邻层提供相同的接口,允许每层用不同的方法实现,同样为软件重用提供了强大的支持。

    图2-3是层次系统风格的示意图。层次系统最广泛的应用是分层通信协议。在这一应用领域中,每一层提供一个抽象的功能,作为上层通信的基础。较低的层次定义低层的交互,最低层通常只定义硬件物理连接。
    在这里插入图片描述
    图 2‑3层次系统风格的体系结构

    层次系统有许多可取的属性:

    (1) 支持基于抽象程度递增的系统设计,使设计者可以把一个复杂系统按递增的步骤进行分解;
    (2) 支持功能增强,因为每一层至多和相邻的上下层交互,因此功能的改变最多影响相邻的上下层;
    (3) 支持重用。只要提供的服务接口定义不变,同一层的不同实现可以交换使用。这样,就可以定义一组标准的接口,而允许各种不同的实现方法。

    但是,层次系统也有其不足之处:

    (1) 并不是每个系统都可以很容易地划分为分层的模式,甚至即使一个系统的逻辑结构是层次化的,出于对系统性能的考虑,系统设计师不得不把一些低级或高级的功能综合起来;
    (2) 很难找到一个合适的、正确的层次抽象方法。

    分层通信协议TCP/IP体现此风格
    在这里插入图片描述

    (五)仓库风格

    在仓库风格中,有两种不同的构件:中央数据结构说明当前状态,独立构件在中央数据存贮上执行,仓库与外构件间的相互作用在系统中会有大的变化。

    控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择,则仓库是一传统型数据库;另一方面,若中央数据结构的当前状态触发进程执行的选择,则仓库是一黑板系统。

    图2-4 是黑板系统的组成。黑板系统的传统应用是信号处理领域,如语音和模式识别。另一应用是松耦合代理数据共享存取。
    在这里插入图片描述
    图 2‑4黑板系统的组成

    我们从图2-4中可以看出,黑板系统主要由三部分组成:

    (1) 知识源。知识源中包含独立的、与应用程序相关的知识,知识源之间不直接进行通讯,它们之间的交互只通过黑板来完成。
    (2) 黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据,知识源通过不断地改变黑板数据来解决问题。
    (3) 控制。控制完全由黑板的状态驱动,黑板状态的改变决定使用的特定知识。

    典型范例:信号处理领域中的语音和模式识别。另一应用是松耦合代理数据共享存取。
    在这里插入图片描述
    在这里插入图片描述

    (六)C2风格

    C2体系结构风格可以概括为:通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下:

    (1) 系统中的构件和连接件都有一个顶部和一个底部;
    (2) 构件的顶部应连接到某连接件的底部,构件的底部则应连接到某连接件的顶部,而构件与构件之间的直接连接是不允许的;
    (3) 一个连接件可以和任意数目的其它构件和连接件连接;
    (4) 当两个连接件进行直接连接时,必须由其中一个的底部到另一个的顶部。

    图2-5是C2风格的示意图。图中构件与连接件之间的连接体现了C2风格中构建系统的规则。

    在这里插入图片描述
    图 2‑5 C2风格的体系结构

    C2风格是最常用的一种软件体系结构风格。从C2风格的组织规则和结构图中,我们可以得出,C2风格具有以下特点:

    (1) 系统中的构件可实现应用需求,并能将任意复杂度的功能封装在一起;
    (2) 所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的;
    (3) 构件相对独立,构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行,或某些构件共享特定控制线程之类的相关性假设。

    二层C/S我们不再介绍了,直接说三层C/S

    三层C/S的基本硬件结构
    传统的二层C/S结构存在以下几个局限:

    • 它是单一服务器且以局域网为中心的,所以难以扩展至大型企业广域网或Internet;
    • 受限于供应商;
    • 软、硬件的组合及集成能力有限;
    • 难以管理大量的客户机。

    因此,三层C/S结构应运而生。三层C/S结构是将应用功能分成表示层、功能层和数据层三部分。其解决方案是:对这三层进行明确分割,并在逻辑上使其独立。原来的数据层作为DBMS已经独立出来,所以关键是要将表示层和功能层分离成各自独立的程序,并且还要使这两层间的接口简洁明了。

    将上述三层功能装载到硬件的方法基本上有三种(如图所示)。其中表示层配置在客户机中,而数据层配置在服务器中。

    一般情况是只将表示层配置在客户机中,与二层C/S结构相比,其程序的可维护性要好得多,是其他问题并未得到解决。客户机的负荷太重,其业务处理所需的数据要从服务器传给客户机,所以系统的性能容易变坏。

    如果将功能层和数据层分别放在不同的服务器中,则服务器和服务器之间也要进行数据传送。但是,由于在这种形态中三层是分别放在各自不同的硬件系统上的,所以灵活性很高,能够适应客户机数目的增加和处理负荷的变动。例如,在追加新业务处理时,可以相应增加装载功能层的服务器。因此,系统规模越大这种形态的优点就越显著。

    值得注意的是:三层C/S结构各层间的通信效率若不高,即使分配给各层的硬件能力很强,其作为整体来说也达不到所要求的性能。此外,设计时必须慎重考虑三层间的通信方法、通信频度及数据量。这和提高各层的独立性一样是三层C/S结构的关键问题。

    在这里插入图片描述

    三层C/S的功能

    1.表示层
    表示层是应用的用户接口部分,它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据,显示应用输出的数据。为使用户能直观地进行操作,一 般要使用图形用户接口(GUI),操作简单、易学易用。在变更用户接口时,只需改写显示控制和数据检查程序,而不影响其他两层。检查的内容也只限于数据的 形式和值的范围,不包括有关业务本身的处理逻辑。

    图形界面的结构是不固定的,这便于以后能灵活地进行变更。例如,在一个窗口中不是放入几个功能,而是按功能分割窗口,以便使每个窗口的功能简洁单纯。在这层的程序开发中主要是使用可视化编程工具。

    2.功能层
    功能层相当于应用的本体,它是将具体的业务处理逻辑地编入程序中。例如,在制作订购合同的时要计算合同金额,按照定好的格式配置数据、打印订购合同,而 处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。例如,用户检索数据时,要设法将有关检索要求的信息一次传送给功能 层(参见图2),而由功能层处理过的检索结果数据也一次传送给表示层。在应用设计中,一定要避免进行一次业务处理,在表示层和功能层间进行多几次数据交换 的笨拙设计。

    通常,在功能层中包含有:确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。这层的程序多半是用可视化编程工具开发的,也有使用COBOL和C语言的。

    3.数据层
    数据层就是DBMS,负责管理对数据库数据的读写。DBMS必须能迅速执行大量数据的更新和检索。现在的主流是关系数据库管理系统(RDBMS)。因此,一般从功能层传送到数据层的要求大都使用SQL语言。

    三层C/S结构的优点

    1.具有灵活的硬件系统构成
    对于各个层可以选择与其处理负荷和处理特性相适应的硬件。这是一个与系统可缩放性直接相关的问题。例如,最初用一台Unix工作站作为服务器,将数据层 和功能层都配置在这台服务器上。随着业务的发展,用户数和数据量逐渐增加,这时就可以将Unix工作站作为功能层的专用服务器,另外追加一台专用于数据层 的服务器。若业务进一步扩大,用户数进一步增加,则可以继续增加功能层的服务器数目,用以分割数据库。清晰、合理地分割三层结构并使其独立,可以使系统构 成的变更非常简单。因此,被分成三层的应用基本上不需要修正。

    2.提高程序的可维护性

    三层C/S结构中,应用的各层可以并行开发,各层也可以选择各自最适合的开发语言。

    3.利于变更和维护应用技术规范

    因为是按层分割功能,所以各个程序的处理逻辑变得十分简单。

    4.进行严密的安全管理

    越关键的应用,用户的识别和存取权限设定愈重要。在三层C/S结构中,识别用户的机构是按层来构筑的,对应用和数据的存取权限也可以按层进行设定。例如,即使外部的入侵者突破了表示层的安全防线,若在功能层中备有另外的安全机构,系统也可以阻止入侵者进入其他部分。
    此外,系统管理简单,可支持异种数据库,有很高的可用性。

    C/S和B/S 的优缺点比较

    C/S和B/S是当今世界开发模式技术架构的两大主流技术。C/S是美国 Borland公司最早研发,B/S是美国微软公司研发。目前,这两项技术以被世界各国所掌握,国内公司以C/S和B/S技术开发出产品也很多。这两种技术都有自己一定的市场份额和客户群,各家企业都说自己的管理软件架构技术功能强大、先进、方便,都能举出各自的客户群体,都有一大群文人墨客为自己摇旗呐 喊,广告满天飞,可谓仁者见仁,智者见智。

    1、C/S架构软件的优势与劣势

    (1)应用服务器运行数据负荷较轻。

    最简单的C/S体系结构的数据库应用由两部分组成,即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序 的机器,也称为应用服务器。一旦服务器程序被启动,就随时等待响应客户程序发来的请求;客户应用程序运行在用户自己的电脑上,对应于数据库服务器,可称为 客户电脑,当需要对数据库中的数据进行任何操作时,客户程序就自动地寻找服务器程序,并向其发出请求,服务器程序根据预定的规则应答,送回结果,应用 服务器运行数据负荷较轻。

    (2)数据的储存管理功能较为透明。

    在数据库应用中,数据的储存管理功能,是由服务器程序和客户应用程序分别独立进行的,前台应用可以违反的规则,并且通常把那些不同的(不管是已知 还是未知的)运行数据,在服务器程序中不集中实现,例如访问者的权限,编号可以重复、必须有客户才能建立定单这样的规则。所有这些,对于工作在前台程序上 的最终用户,是“透明”的,他们无须过问(通常也无法干涉)背后的过程,就可以完成自己的一切工作。在客户服务器架构的应用中,前台程序不是非常“瘦小 ”,麻烦的事情都交给了服务器和网络。在C/S体系的下,数据库不能真正成为公共、专业化的仓库,它受到独立的专门管理。

    (3)C/S架构的劣势是高昂的维护成本且投资大。

    首先,采用C/S架构,要选择适当的数据库平台来实现数据库数据的真正“统一”,使分布于两地的数据同步完全交由数据库系统去管理,但逻辑上两地 的操作者要直接访问同一个数据库才能有效实现,有这样一些问题,如果需要建立“实时”的数据同步,就必须在两地间建立实时的通讯连接,保持两地的数据库服 务器在线运行,网络管理工作人员既要对服务器维护管理,又要对客户端维护和管理,这需要高昂的投资和复杂的技术支持,维护成本很高,维护任务量大。

    其次,传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件,由于产品的更新换代十分快,代价高和低效率已经不适应工作需要。在JAVA这样的跨平台语言出现之后,B/S架构更是猛烈冲击C/S,并对其形成威胁和挑战。

    2、B/S架构软件的优势与劣势

    (1)维护和升级方式简单。

    目前,软件系统的改进和升级越来越频繁,B/S架构的产品明显体现着更为方便的特性。对一个稍微大一点单位来说,系统管理人员如果需要在几百甚至 上千部电脑之间来回奔跑,效率和工作量是可想而知的,但B/S架构的软件只需要管理服务器就行了,所有的客户端只是浏览器,根本不需要做任何的维护。无论 用户的规模有多大,有多少分支机构都不会增加任何维护升级的工作量,所有的操作只需要针对服务器进行;如果是异地,只需要把服务器连接专网即可,实现远程 维护、升级和共享。所以客户机越来越“瘦”,而服务器越来越“胖”是将来信息化发展的主流方向。今后,软件升级和维护会越来越容易,而使用起来会越来越简单,这对用户人力、物力、时间、费用的节省是显而易见的,惊人的。因此,维护和升级革命的方式是“瘦”客户机,“胖”服务器。

    (2)成本降低,选择更多。

    大家都知道windows在桌面电脑上几乎一统天下,浏览器成为了标准配置,但在服务器操作系统上windows并不是处于绝对的统治地位。现在 的趋势是凡使用B/S架构的应用管理软件,只需安装在Linux服务器上即可,而且安全性高。所以服务器操作系统的选择是很多的,不管选用那种操作系统都 可以让大部分人使用windows作为桌面操作系统电脑不受影响,这就使的最流行免费的Linux操作系统快速发展起来,Linux除了操作系统是免费的 以外,连数据库也是免费的,这种选择非常盛行。

    (3)应用服务器运行数据负荷较重。

    由于B/S架构管理软件只安装在服务器端(Server)上,网络管理人员只需要管理服务器就行了,用户界面主要事务逻辑在服务器 (Server)端完全通过WWW浏览器实现,极少部分事务逻辑在前端(Browser)实现,所有的客户端只有浏览器,网络管理人员只需要做硬件维护。 但是,应用服务器运行数据负荷较重,一旦发生服务器“崩溃”等问题,后果不堪设想。因此,许多单位都备有数据库存储服务器,以防万一。

    C/S 与 B/S 区别

    Client/Server是建立在局域网的基础上的,Browser/Server是建立在广域网的基础上的。

    (1)硬件环境不同:

    C/S 一般建立在专用的网络上, 小范围里的网络环境, 局域网之间再通过专门服务器提供连接和数据交换服务。

    B/S 建立在广域网之上的, 不必是专门的网络硬件环境,例如电话上网, 租用设备, 信息自己管理, 有比C/S更强的适应范围, 一般只要有操作系统和浏览器就行。

    (2)、对安全要求不同

    C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强。 一般高度机密的信息系统采用C/S 结构适宜,可以通过B/S发布部分可公开信息。

    B/S 建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群。

    (3)对程序架构不同

    C/S 程序可以更加注重流程,可以对权限多层次校验,对系统运行速度可以较少考虑。

    B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上。 比C/S有更高的要求,B/S结构的程序架构是发展的趋势,从MS的。Net系列的BizTalk 2000 Exchange 2000等,全面支持网络的构件搭建的系统。SUN和IBM推的JavaBean构件技术等,使B/S更加成熟。

    (4)软件重用不同

    C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好。

    B/S 对的多重结构,要求构件相对独立的功能。 能够相对较好的重用。就如买来的餐桌可以再利用,而不是做在墙上的石头桌子。

    (5)系统维护不同

    系统维护是软件生存周期中,开销大,相当重要。C/S 程序由于整体性,必须整体考察,处理出现的问题以及系统升级难, 可能是再做一个全新的系统。 B/S 构件组成方面构件个别的更换,实现系统的无缝升级。系统维护开销减到最小,用户从网上自己下载安装就可以实现升级。

    (6)处理问题不同

    C/S 程序可以处理用户面固定,并且在相同区域, 安全要求高的需求,与操作系统相关, 应该都是相同的系统。 B/S 建立在广域网上, 面向不同的用户群,分散地域, 这是C/S无法作到的,与操作系统平台关系最小。

    (7)用户接口不同

    C/S 多是建立在Window平台上,表现方法有限,对程序员普遍要求较高。 B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流, 并且大部分难度减低,降低开发成本。

    (8)信息流不同

    C/S 程序一般是典型的中央集权的机械式处理,交互性相对低。 B/S 信息流向可变化, B-B、 B-C、 B-G等信息流向的变化, 更像交易中心。

    (七)基于层次消息总线的架构风格

    JB/HMB风格的基本特征

    目前对软件体系结构的研究集中在以下方面:各种体系结构风格的汇编和总结、体系结

    构描述语言(architectural description languages,简称ADLS)、体系结构的形式化基础、体系结构分析技术、基于体系结构的软件开发、体系结构恢复和再工程、支持体系结构设计的工具和环境及特定领域的软件体系结构等。 青鸟工程在“九五”期间,对基于构件构架模式的软件工业化生产技术进行了研究,并实现了青鸟软件生产线系统151。以青鸟软件生产线的实践为背景,提出了基于层次消息总线的软件体系结构(Jade bird hierarchical message bus based style,以下简称JB/HMB风格),设计了相应的体系结构描述语言,开发了支持软件体系结构设计的辅助工具集,并研究了采用JB/HMB风格进行应用系统开发的过程框架。

    JB/HMB风格的提出基于以下的实际背景:

    (1) 随着计算机网络技术的发展,特别是分布式构件技术的日渐成熟和构件互操作标准的出现,如CORBA,DCOM和EJB等,加速了基于分布式构件的软件开发趋势,具有分布和并发特点的软件系统已成为一种普遍的应用需求。
    (2) 基于事件驱动的编程模式已在图形用户界面程序设计中获得广泛应用。在此之前的程序设计中,通常使用一个大的分支语句(switch Statement)控制程序的转移,对不同的输人情况分别进行处理,程序结构不甚清晰。基于事件驱动的编程模式在对多个不同事件响应的情况下,系统自动调用相应的处理函数,程序具有清晰的结构。
    (3) 计算机硬件体系结构和总线的概念为软件体系结构的研究提供了很好的借鉴和启发,

    在统一的体系结构框架下(即总线和接口规范),系统具有良好的扩展性和适应性。任何计算机厂商生产的配件,甚至是在设计体系结构时根本没有预料到的配件,只要遵循标准的接口规范,都可以方便地集成到系统中,对系统功能进行扩充,甚至是即插即用(即运行时刻的系统演化)。正是标准的总线和接口规范的制定,以及标准化配件的生产,促进了计算机硬件的产业分工和蓬勃发展。

    在这里插入图片描述

    JB/HMB风格基于层次消息总线、支持构件的分布和并发,构件之间通过消息总线进行通讯,如图所示。消息总线是系统的连接件,负责消息的分派、传递和过滤以及处理结果的返回。各个构件挂接在消息总线上,向总线登记感兴趣的消息类型。构件根据需要发出消息,由消息总线负责把该消息分派到系统中所有对此消息感兴趣的构件,消息是构件之间通讯的唯一方式,构件接收到消息后,根据自身状态对消息进行响应,并通过总线返回处理结果。由于构件通过总线进行连接,并不要求各个构件具有相同的地址空间或局限在一台机器上。该风格可以较好地刻画分布式并发系统,以及基于CORBA,DCOM和EJB规范的系统。

    如图所示,系统中的复杂构件可以分解为比较低层的子构件,这些子构件通过局部消息

    总线进行连接,这种复杂的构件称为复合构件。如果子构件仍然比较复杂,可以进一步分解。

    如此分解下去,整个系统形成了树状的拓扑结构,树结构的末端结点称为叶结点,它们是系统中的原子构件,不再包含子构件,原子构件的内部可以采用不同于JB/HMB的风格,例如数据流风格、面向对象风格及管道/过滤器风格等,这些属于构件的内部实现细节。但要集成到JB/HMB风格的系统中,必须满足JB/HMB风格的构件模型的要求,主要是在接口规约方面的要求。另外,整个系统也可以作为一个构件,通过更高层的消息总线,集成更大的系统中。于是,可以采用统一的方式刻画整个系统和组成系统的单个构件。

    构建模型

    系统和组成系统的成分通常是比较复杂的,难以从一个视角获得对它们的完整理解,因

    此一个好的软件工程方法往往从多个视角对系统进行建模,一般包括系统的静态结构、动态行为和功能等方面。例如,在Rumbaugh等人提出的OMT(object modeling technology)方法中,

    采用了对象模型、动态模型和功能模型刻画系统的以上3个方面。

    借鉴上述思想,为满足体系结构设计的需要,JB/HMB风格的构件模型包括了接口、静态结构和动态行为3个部分,如图所示。

    在这里插入图片描述

    在图中所示的构件模型中,左上方是构件的接口部分,一个构件可以支持多个不同的接口,每个接口定义了一组输入和输出的消息,刻画了构件对外提供的服务以及要求的环境服务,体现了该构件同环境的交互.右上方是用带输出的有限状态自动机刻画的构件行为,构件接收到外来消息后,根据当前所处的状态对消息进行响应,并可能导致状态的变迁.下方是复合构件的内部结构定义,复合构件是由更简单的子构件通过局部消息总线连接而成的.消息总线为整个系统和各个层次的构件提供了统一的集成机制。

    构件接口

    在体系结构设计层次上,构件通过接口定义了同外界的信息传递和承担的系统责任,构件接口代表了构件同环境的全部交互内容,也是唯一的交互途径.除此之外,环境不应对构件做任何其他与接口无关的假设,例如实现细节等。JB/HMB风格的构件接口是一种基于消息的互联接口,可以较好地支持体系结构设计。

    构件之间通过消息进行通讯,接口定义了构件发出和接收的消息集合.同一般的互联接口相比.JB/HMB的构件接口具有两个显著的特点.首先,构件只对消息本身感兴趣,并不关心消息是如何产生的,消息的发出者和接收者不必知道彼此的情况,这样就切断了构件之间的直接联系,降低了构件之间的藕合强度,进一步增强了构件的复用潜力,并使得构件的替换变得更为容易。另外,在一般的互联接口定义的系统中,构件之间的连接是在要求的服务和提供的服务之间进行固定的匹配,而在JB/HMB的构件接口定义的系统中,构件对外来消息的响应,不但同接收到的消息类型相关,而且同构件当前所处的状态相关.构件对外来消息进行响应后,可能会引起状态的变迁.因此,一个构件在接收到同样的消息后,在不同时刻所处的不同状态下,可能会有不同的响应。

    消息是关于某个事件发生的信息,上述接口定义中的消息分为两类:(i)构件发出的消息,通知系统中其他构件某个事件的发生或请求其他构件的服务;(ii)构件接收的消息,对系统中某个事件的响应或提供其他构件所需的服务.接口中的每个消息定义了构件的一个端口,具有互补端口的构件可以通过消息总线进行通讯,互补端口指的是除了消息进出构件的方向不同之外,消息名称、消息带有的参数和返回结果的类型完全相同的两个消息. 当某个事件发生后,系统或构件发出相应的消息,消息总线负责把该消息传递到对此消息感兴趣的构件.按照响应方式的不同,消息可分为同步消息和异步消息.同步消息是指消息的发送者必须等待消息处理结果返回才可以继续运行的消息类型.异步消息是指消息的发送者不必等待消息处理结果的返回即可继续执行的消息类型.常见的同步消息包括(一般的)过程调用。

    消息总线

    JB/HMB风格的消息总线是系统的连接件,构件向消息总线登记感兴趣的消息,形成构件-消息响应登记表.消息总线根据接收到的消息类型和构件一消息响应登记表的信息,定位并传递该消息给相应的响应者,并负责返回处理结果.必要时,消息总线还对特定的消息进行过滤和阻塞.下图给出了采用对象类符号表示的消息总线的结构。

    在这里插入图片描述
    运行时的演化

    在许多重要的应用领域中,例如金融、电力、电信及空中交通管制等,系统的持续可用性是一个关键性的要求,运行时刻的系统演化可减少因关机和重新启动而带来的损失和风险。此外,越来越多的其他类型的应用软件也提出了运行时刻演化的要求,在不必对应用软件进行重新编译和加载的前提下,为最终用户提供系统定制和扩展的能力。JBI/HMB风格方便地支持运行时刻的系统演化,主要体现在以下3个方面:

    (1) 动态增加或删除构件。在JB/HMB风格的系统中,构件接口中定义的输人和输出消息刻画了一个构件承担的系统责任和对外部环境的要求,构件之间通过消息总线进行通讯,彼此并不知道对方的存在。因此只要保持接口不变,构件就可以方便地替换。一个构件加人到系统中的方法很简单,只需向系统登记其所感兴趣的消息即可。但删除一个构件可能会引起系统中对于某些消息没有构件响应的异常情况,这时可以采取两种措施:一是阻塞那些没有构件响应的消息,二是首先使系统中的其他构件或增加新的构件对该消息进行响应,然后再删除相应的构件。系统中可能增删改构件的情况包括:当系统功能需要扩充时,往系统中增加新的构件。当对系统功能进行裁剪,或当系统中的某个构件出现问题时,需要删除系统中的某个构件。用带有增强功能或修正了错误的构件新版本代替原有的旧版本。

    (2) 动态改变构件响应的消息类型。类似地,构件可以动态地改变对外提供的服务(即接收的消息类型),这时应通过消息总线对发生的改变进行重新登记。

    (3) 消息过滤。利用消息过滤机制,可以解决某些构件集成的不匹配问题,详见“消息过滤”一节。消息过滤通过阻塞构件对某些消息的响应,提供了另一种动态改变构件对消息进行响应的方式。

    JB/HMB风格的优点

    以上讨论了JB/HMB风格的各组成要素,下面对JB/HMB风格的主要特点作总结。

    (1) 从接口、结构和行为方面对构件进行刻画。在JB/HMB风格中,构件的描述包括接口、静态结构和动态行为3个方面。接口:构件可以提供一个或多个接口,每个接口定义了一组发送和接收的消息集合,刻画了构件对外提供的服务以及要求的环境服务,接口之间可以通过继承表达相似性。

    静态结构:复合构件是由子构件通过局部消息总线连接而成的,形成该复合构件的内部结构。

    动态行为:构件行为通过带输出的有限状态机刻画,构件接收到外来消息后,不但根

    据消息类型,而且根据构件当前所处的状态对消息进行响应,并导致状态的变迁。

    基于层次消息总线:消息总线是系统的连接件,负责消息的传递、过滤和分派,以及

    处理结果的返回。各个构件挂接在总线上,向系统登记感兴趣的消息。构件根据需要发出消息,由消息总线负责把该消息分派到系统中对此消息感兴趣的所有构件。构件接收到消息后,根据自身状态对消息进行响应,并通过总线返回处理结果。由于构件通过总线进行连接,并不要求各个构件具有相同的地址空间或局限在一台机器上,系统具有并发和分布的特点。系统和复合构件可以逐层分解,子构件通过(局部)消息总线相连。每条消息总线分别属于系统和各层次的复合构件,我们把这种特征的总线称为层次消息总线。在系统开发方面,由于各层次的总线局部在相应的复合构件中,因此可以更好地支持系统的构造性和演化性。

    统一描述系统和组成系统的构件:组成系统的构件通过消息总线进行连接,复杂构

    件又可以分解为比较简单的子构件,通过局部消息总线进行连接,如果子构件仍然比较复杂,

    可以进一步分解。系统呈现出树状的拓扑结构。另外,整个系统也可以作为一个构件,集成到更大的系统中。于是,就可以对整个系统和组成系统的各层构件采用统一的方式进行描述。

    支持运行时刻的系统演化:系统的持续可用性是许多重要的应用系统的一个关键性

    要求,运行时刻的系统演化可减少因关机和重新启动而带来的损失和风险。JB/HMB风格方便地支持运行时刻的系统演化,主要包括动态增加或删除构件、动态改变构件响应的消息类型和消息过滤。

    摘自《软件体系结构原理、方法与实践(第2版)张友生》

    展开全文
  • 基于区块链可在各节点共同存储消息的特性,可以实现消息的永久存储,可有效避免因为单个节点故障引起的消息丢失,发布到消息系统上的消息支持永久存储,不可篡改,支持事后跟踪和审计。 确保用户与物联网设备通信时...
  • 基于platform总线的驱动分析

    千次阅读 2016-08-31 15:23:03
    在设备驱动模型中,总线负责将设备和驱动绑定。在系统每注册一个设备的时候,会寻找与之匹配的驱动;相反的,在系统每注册一个驱动的时候,会寻找与之匹配的设备,而匹配由总线完成。
  • 第三章 软件体系结构风格(下)

    千次阅读 2020-03-05 15:04:15
    第三章 软件体系结构风格(下) 继第三章 软件体系结构风格(上),再简单介绍几种软件体系结构风格,并了解异构体系结构集成。 3.10 反馈控制环体系结构风格 反馈控制环的思想源自过程控制理论,从过程控制角度来...
  • 涉及到组织架构、团队文化、技术体系等因素,仅仅通过系统内部重构很大程度上只能缓解而不能消除信息孤岛的产生,这就需要使用某种手段进行业务服务整合,分布式架构风格的目的就在于此。分布式作为一种基础架构风格...
  • Lahja是用Python 3.6+编写的通用事件总线实现,可基于非阻塞异步IO实现轻量级进程间通信。 这个是来做什么的? Lahja是针对一个主要用例量身定制的:使用基于asyncio或trio的非阻塞API,使多进程Python应用程序...
  • 《软件体系结构》第三章 软件体系结构风格

    万次阅读 多人点赞 2018-07-01 13:56:42
    第三章 软件体系结构风格 一、基本概念 1. 软件体系结构设计的一个核心问题是能否使用重复的体系结构模式,即能够达到体系结构级的复用。 2. 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。...
  • 它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有...
  • 如果你是一个IC工程师,并且当前的芯片设计是基于各种复用IP的SOC芯片,你肯定听说过AMBA、AHB、APB、AXI、AXI-lite、ACE、CHI等。AMBA总线协议是一套由ARM提...
  • 目录 一、什么是ESB 二、ESB解决了什么问题以及什么是HSB ...4. 消息路由 5. 其他功能 五、ESB与微服务的区别 本文主要是对ESB的总结,下面我将从以下几点去理清ESB相关知识点。 什么是ESB ESB解决了什么问题...
  • 基于SpringBoot的微服务架构实践

    千次阅读 2018-07-11 11:34:19
    Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种...
  • CANoe总线开发测试工具学习帖(20190329-201904)

    千次阅读 多人点赞 2019-04-10 22:19:36
    CANoe总线开发测试工具学习帖
  • ESB 企业服务总线

    万次阅读 2013-08-24 10:36:41
    整理的OSChina 第 38 期高手问答 —— ESB 企业服务总线,嘉宾...曾参和设计和开发基于FuseESB 企业级服务总线系统,对FuseESB企业级服务总线以及内嵌的Camel/ActiveMQ 有深刻的理解。 ESB 全称为Enterprise Servic
  • 一、概述 软件体系结构表示系统的框架结构,用于从较高的层次上来描述各部分之间的关系和接口,主要包括构件、构件性质和构件之间的关系。 通过使用软件体系结构,...由此,产生了软件体系结构风格的概念。 ...
  • 架构风格基于网络的软件架构设计 (博士论文) 作者:Roy Thomas Fielding博士 译者:李锟、廖志刚、刘丹、杨光 2 原文链接:Architectural Styles and the Design of Network-based Software Architectures 作者...
  • 软件架构风格介绍

    2015-10-11 15:19:00
    架构风格是一组原则。你可以把它看成是一组为系统家族提供抽象框架的粗粒度模式。架构风格能改进分块,还能为频繁出现的问题提供解决方案,以此促进设计重用。 常见的软件体系结构风格涉及: 设计词汇表是什么?或者...
  • JBOSS ESB企业服务器总线

    千次阅读 2015-07-25 14:24:04
    其实,总线的概念并不新鲜,传统的EAI系统中,也曾经提出过信息总线的概念,通过某种中间件平台,如CORBA来连接企业信息孤岛,但是,ESB的概念不仅仅是提供消息交互的通道,更重要的是提供服务的智能化集成基础架构...
  •   在Linux 2.6以后的设备驱动模型中,需关心总线、设备和驱动这3个实体,总线将设备和驱动绑定。在系统每注册一个设备的时候,会寻找与之匹配的驱动;相反的,在系统每注册一个驱动的时候,会寻找与之匹配的设备,...
  • 微服务最早由Martin Fowler与James Lewis于2014年共同提出,微服务架构风格是一种使用一套小服务来开发单个应用的方式途径,每个服务运行在自己的进程中,并使用轻量级机制通信,通常是HTTP API,这些服务基于业务...
  • 第二阶段是实现基于信息总线的业务流程整合,利用BPM技术实现不同系统间流程的衔接,解决流程割裂的问题。  二、数据服务概念的引入  企业级信息总线的建设有助于优化IT总体架构,其首要任务应是建设EASB...
  • 性格反映了不同驾驶员在不同时间、地点的驾驶风格,对于智能驾驶系统,驾驶风格由驾驶操作模型中的参数决定。情绪是生物的特有属性,人类驾驶行为会受到情绪焦躁、恐惧等的影响,妨碍安全驾驶。驾驶脑的实现不包括...
  • 引言 编写目的 背景与意义 ... 在企业内部业务系统比较... 企业服务总线(EnterpriseServiceBus,ESB)是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分,是由中间件技术实现并支持SOA的一组基
  • 软件体系结构风格 一、概述 软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。 体系结构风格定义了一个系统家族,即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型,而...
  • 软件体系结构与软件体系结构风格 软件体系结构:系统的框架结构,用较高的层次描述各部分之间的关系与接口 软件体系结构风格:不同的结构有些差别,但是不同的系统设计方案总有共性,于是我们进一步抽象总结,把共性...
  • 系统架构_软件架构风格概述  转载自:http://jpkc.whu.edu.cn/jpkc/dxqyxxxtfgnjg/dzja/dzjc/jc3.htm 1 软件架构风格概述 软件体系结构设计的一个核心问题是能否使用重复的体系结构模式,即能否达到体系...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 14,498
精华内容 5,799
关键字:

基于消息总线的风格

友情链接: dojo.rar