|
|
|
软件架构设计的一个核心问题是能否使用重复的架构模式，即能否达到架构级的软件重用。也就是说，能否在不同的软件系统中，使用同一架构。软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（idiomatic paradigm）。架构风格定义了一个系统家族，即一个架构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件架构风格定义了用于描述系统的术语表和一组指导构件系统的规则。
|
|
|
|
|
|
|
|
（2）调用／返回风格：主程序／子程序，面向对象风格，层次结构。
|
|
|
|
|
|
|
|
（5）仓库风格：数据库系统，超文本系统，黑板系统。
|
|
|
|
|
|
|
|
|
|
在管道／过滤器风格中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。因此，这里的构件被称为过滤器，这种风格的连接件就像是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。此风格中特别重要的过滤器必须是独立的实体，它不能与其他的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。
|
|
|
|
一个典型的管道／过滤器架构的例子是以UNIX shell编写的程序。UNIX既提供一种符号，以连接各组成部分（UNIX的进程），又提供某种进程运行机制以实现管道。另一个著名的例子是传统的编译器。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成）的输出是另一个阶段的输入。
|
|
|
|
|
|
（1）使得构件具有良好的隐蔽性和高内聚、低耦合的特点。
|
|
|
|
（2）允许设计者将整个系统的I/O行为看成是多个过滤器行为的简单合成。
|
|
|
|
（3）支持软件重用。只要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来。
|
|
|
|
（4）系统维护简单，可扩展性好。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉。
|
|
|
|
|
|
（6）支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其他任务并行执行。
|
|
|
|
|
|
（1）通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
|
|
|
|
（2）不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。
|
|
|
|
（3）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
|
|
|
|
|
|
面向对象风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。
|
|
|
|
|
|
（1）因为对象对其他对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其他的对象。
|
|
|
|
（2）设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
|
|
|
|
|
|
（1）为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。
|
|
|
|
（2）必须修改所有显式调用它的其他对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。
|
|
|
|
|
|
基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个多事件。系统中的其他构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。
|
|
|
|
从架构上说，这种风格的构件是一些模块，这些模块既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。
|
|
|
|
基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会受到这些事件影响。由于不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。
|
|
|
|
|
|
（1）为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
|
|
|
|
（2）为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其他构件的接口。
|
|
|
|
|
|
（1）构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其他构件是否会响应它，而且，即使它知道事件注册了哪些构件的过程，它也不能保证这些过程被调用的顺序。
|
|
|
|
（2）数据交换的问题。有时数据可被一个事件传递，但在另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。
|
|
|
|
（3）既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理就存在问题。
|
|
|
|
|
|
层次系统组织成一个层次结构，每一层为上层服务，并作为下层的客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样的系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的），连接件通过决定层间如何交互的协议来定义。这种风格支持基于可增加抽象层的设计。这样，允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。
|
|
|
|
下图是层次系统风格的示意图。层次系统最广泛的应用是分层通信协议。在这一应用领域中，每一层提供一个抽象的功能，作为上层通信的基础。较低的层次定义低层的交互，最低层通常只定义硬件物理连接。
|
|
|
|
|
|
|
|
|
|
（1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解。
|
|
|
|
（2）支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层。
|
|
|
|
（3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。
|
|
|
|
|
|
（1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，架构设计师不得不把一些低级或高级的功能综合起来。
|
|
|
|
|
|
|
|
在仓库（repository）风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存储上执行。控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。
|
|
|
|
黑板系统的传统应用是信号处理领域，主要由3部分组成：
|
|
|
|
（1）知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。
|
|
|
|
（2）黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
|
|
|
|
（3）控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。
|
|
|
|
|
|
C2（Component-Connector）架构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：
|
|
|
|
（1）系统中的构件和连接件都有一个顶部和一个底部。
|
|
|
|
（2）构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的。
|
|
|
|
（3）一个连接件可以和任意数目的其他构件和连接件连接。
|
|
|
|
（4）当两个连接件进行直接连接时，必须由其中一个的底部连接到另一个的顶部。
|
|
|
|
从C2风格的组织规则和结构图中，我们可以得出C2风格具有以下特点：
|
|
|
|
（1）系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起。
|
|
|
|
（2）所有构件之间的通信是通过以连接件为中介的异步消息交换机制来实现的。
|
|
|
|
（3）构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。
|
|
|
|
|
|
C/S架构可以是二层的，也可以是三层的。本节介绍二层的C/S架构，12.3.3节介绍三层的C/S架构。
|
|
|
|
二层C/S架构是基于资源不对等，且为实现共享而提出来的，C/S架构定义了工作站如何与服务器相连，以实现数据和应用分布到多个处理机上。C/S架构有3个主要组成部分，分别是数据库服务器、客户应用程序和网络。
|
|
|
|
服务器负责有效地管理系统的资源，其任务集中于：数据库安全性的要求、数据库访问并发性的控制、数据库前端的客户应用程序的全局数据完整性规则、数据库的备份与恢复；客户应用程序的主要任务是：提供用户与数据库交互的界面，向数据库服务器提交用户请求并接收来自数据库服务器的信息，利用客户应用程序对存在于客户端的数据执行应用逻辑要求；网络通信软件的主要作用是完成数据库服务器和客户应用程序之间的数据传输。
|
|
|
|
C/S架构将应用一分为二，服务器（后台）负责数据管理，客户机（前台）完成与用户的交互任务。服务器为多个客户应用程序管理数据，而客户程序发送、请求和分析从服务器接收的数据，这是一种胖客户机（fat client）、瘦服务器（thin server）的软件架构。其数据流图如下图所示。
|
|
|
|
|
|
|
|
在一个C/S架构的软件系统中，客户应用程序是针对一个小的、特定的数据集，如一个表的行来进行操作，而不是像文件服务器那样针对整个文件进行，对某一条记录进行封锁，而不是对整个文件进行封锁，因此保证了系统的并发性，并使网络上传输的数据量减到最少，从而改善了系统的性能。
|
|
|
|
C/S架构的优点主要在于系统的客户应用程序和服务器构件分别运行在不同的计算机上，系统中每台服务器都可以适合各构件的要求，这对于硬件和软件的变化显示出极大的适应性和灵活性，而且易于对系统进行扩充和缩小。在C/S架构中，系统中的功能构件充分隔离，客户应用程序的开发集中于数据的显示和分析，而数据库服务器的开发则集中于数据的管理，不必在每一个新的应用程序中都要对一个DBMS进行编码。将大的应用处理任务分布到许多通过网络连接的低成本计算机上，以节约大量费用。
|
|
|
|
C/S架构具有强大的数据操作和事务处理能力，模型思想简单，易于人们理解和接受。但随着企业规模的日益扩大，软件的复杂程度不断提高，C/S架构逐渐暴露了以下缺点：
|
|
|
|
（1）开发成本较高。C/S架构对客户端软硬件配置要求较高，尤其是软件的不断升级，对硬件要求不断提高，增加了整个系统的成本，且客户端变得越来越臃肿。
|
|
|
|
（2）客户端程序设计复杂。采用C/S架构进行软件开发，大部分工作量放在客户端的程序设计上，客户端显得十分庞大。
|
|
|
|
（3）信息内容和形式单一，因为传统应用一般为事务处理，界面基本遵循数据库的字段解释，开发之初就已确定，用户获得的只是单纯的字符和数字，既枯燥又死板。
|
|
|
|
（4）用户界面风格不一，使用繁杂，不利于推广使用。
|
|
|
|
（5）软件移植困难。采用不同开发工具或平台开发的软件，一般互不兼容，不能或很难移植到其他平台上运行。
|
|
|
|
（6）软件维护和升级困难。采用C/S架构的软件要升级，开发人员必须到现场为客户机升级，每个客户机上的软件都需维护。对软件的一个小小改动，每一个客户端都必须更新。
|
|
|
|
（7）新技术不能轻易应用。因为一个软件平台及开发工具一旦选定，不可能轻易更改。
|
|
|
|
|
|
二层C/S架构是单一服务器且以局域网为中心的，所以难以扩展至大型企业广域网或Internet，软、硬件的组合及集成能力有限。客户机的负荷太重，难以管理大量的客户机，系统的性能容易变坏。另外，因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。正是因为二层C/S架构有这么多缺点，因此，三层C/S架构应运而生。
|
|
|
|
|
|
与二层C/S架构相比，在三层C/S架构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种结构称为瘦客户机（thin client）。三层C/S架构是将应用功能分成表示层、功能层和数据层三个部分，如下图所示。
|
|
|
|
|
|
|
|
（1）表示层。表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输出的数据。为使用户能直观地进行操作，一般要使用图形用户界面，使得操作简单、易学易用。在变更用户界面时，只需改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。
|
|
|
|
（2）功能层。功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。例如，在制作订购合同时要计算合同金额，按照定好的格式配置数据、打印订购合同，而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简捷。例如，用户检索数据时，要设法将有关检索要求的信息一次性地传送给功能层，而由功能层处理过的检索结果数据也一次性地传送给表示层。
|
|
|
|
（3）数据层。数据层就是DBMS，负责管理对数据库数据的读写。
|
|
|
|
|
|
三层C/S的解决方案是：对这三层进行明确分割，并在逻辑上使其独立。原来的数据层作为DBMS已经独立出来，所以，关键是要将表示层和功能层分离成各自独立的程序，并且还要使这两层间的接口简洁明了。
|
|
|
|
一般情况是只将表示层配置在客户机中，如下图中（1）或（2）所示。如果像下图中（3）所示的那样连功能层也放在客户机中，与二层C/S架构相比，其程序的可维护性要好得多，但是其他问题并未得到解决。客户机的负荷太重，其业务处理所需的数据要从服务器传给客户机，所以系统的性能容易变差。
|
|
|
|
|
|
|
|
如果将功能层和数据层分别放在不同的服务器中，如上图中（2）所示，则服务器和服务器之间也要进行数据传送。但是，由于在这种形态中三层是分别放在各自不同的硬件系统上的，所以灵活性很高，能够适应客户机数目的增加和处理负荷的变动。例如，在追加新业务处理时，可以相应增加装载功能层的服务器（应用服务器）。因此，系统规模越大这种形态的优点就越显著。在三层C/S架构中，中间件是最重要的构件，有关中间件的知识，请阅读10.2节。
|
|
|
|
|
|
与传统的二层结构相比，三层C/S架构具有以下优点：
|
|
|
|
（1）允许合理地划分三层结构的功能，使之在逻辑上保持相对独立，从而使整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性。
|
|
|
|
（2）允许更灵活有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层；并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
|
|
|
|
（3）三层C/S架构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言，使之能并行地、而且是高效地进行开发，达到较高的性能价格比；对每一层的处理逻辑的开发和维护也会更容易些。
|
|
|
|
（4）允许充分利用功能层有效地隔离开表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础；整个系统的管理层次也更加合理和可控制。
|
|
|
|
：三层C/S架构各层间的通信效率若不高，即使分配给各层的硬件能力很强，其作为整体来说也达不到所要求的性能。此外，设计时必须慎重考虑三层间的通信方法、通信频度及数据量，这和提高各层的独立性一样是三层C/S架构的关键问题。
|
|
|
|
|
|
在三层C/S架构中，表示层负责处理用户的输入和向客户的输出（出于效率的考虑，它可能在向上传输用户的输入前进行合法性验证）。功能层负责建立数据库的连接，根据用户的请求生成访问数据库的SQL语句，并把结果返回给客户端。数据层负责实际的数据库存储和检索，响应功能层的数据处理请求，并将结果返回给功能层。
|
|
|
|
浏览器／服务器（Browser/Server，B/S）风格就是上述三层应用结构的一种实现方式，其具体结构为：浏览器/Web服务器／数据库服务器。B/S架构主要是利用不断成熟的WWW浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。从某种程度上来说，B/S结构是一种全新的软件架构。
|
|
|
|
在B/S架构中，除了数据库服务器外，应用程序以网页形式存放于Web服务器上，用户运行某个应用程序时只须在客户端上的浏览器中输入相应的网址，调用Web服务器上的应用程序并对数据库进行操作完成相应的数据处理工作，最后将结果通过浏览器显示给用户。可以说，在B/S模式的计算机应用系统中，应用（程序）在一定程度上具有集中特征。
|
|
|
|
基于B/S架构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。B/S架构还提供了异种机、异种网、异种应用服务的联机、联网、统一服务的最现实的开放性基础。
|
|
|
|
与C/S架构相比，B/S架构也有许多不足之处，例如：
|
|
|
|
（1）B/S架构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能。
|
|
|
|
（2）B/S架构的系统扩展能力差，安全性难以控制。
|
|
|
|
（3）采用B/S架构的应用系统，在数据查询等响应速度上，要远远地低于C/S架构。
|
|
|
|
（4）B/S架构的数据提交一般以页面为单位，数据的动态交互性不强，不利于OLTP应用。
|
|
|
|
|
|
为了弥补B/S架构存在的一些不足，提高用户体验，RIA（Rich Internet Application，富互联网应用）应运而生。RIA是一个用户接口，它比用HTML能实现的接口更加健壮、反应更加灵敏和更具有令人感兴趣的可视化特性。RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性。RIA简化并改进了B/S架构的用户交互。这样，用户开发的应用程序可以提供更丰富、更具有交互性的用户体验。
|
|
|
|
|
|
RIA利用相对健壮的客户端描述引擎，提供内容密集、响应速度快和图形丰富的用户界面。除了可以提供具有各种控件的界面之外，一般还允许使用SVG（Scalable Vector Graphics，可伸缩向量图）或其他技术来随时构建图形。一些RIA技术甚至能够提供全活动的动画来对数据变化作出响应。
|
|
|
|
RIA的另一个好处在于，数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。对于无线设备和需要偶尔连接的设备来说，将来的趋势肯定是向富客户端的方向发展，并且会逐渐远离基于文本的Web客户端。
|
|
|
|
|
|
一个新的技术是否能够被广泛应用，与该技术的支持平台的多少以及平台功能是否强大、是否易用等因素密切相关。下面就来简单介绍一下支持RIA的技术平台。
|
|
|
|
（1）Flash/Flex。今天，几乎每个人都可以使用基于Flash的RIA。Flex是为满足希望开发RIA的企业级程序员的需求而推出的表示服务器和应用程序框架，它可以运行于J2EE和.NET平台。Flex应用程序框架由MXML（Macromedia XML）、ActionScript 2.0及Flex类库构成。开发人员利用MXML及ActionScript 2.0编写Flex应用程序。利用MXML定义应用程序用户界面元素，利用ActionScript 2.0定义客户逻辑与程序控制。Flex类库中包括Flex组件、管理器及行为等。该语言由Flex服务器翻译成SWF格式的客户端应用程序，在Flash Player中运行。
|
|
|
|
（2）Bindows。Bindow是用Javascript和DHTML（Dynamic HTML，动态HTML）开发的Web窗体框架。Javascript用于客户端界面的显示和处理，XML和HTTP用于客户端与服务器的信息传输。Bindows的一个主要缺点是它采用一次全部载入的方式来实现脚本库，在窗口的加载期，需要一个漫长的等待过程，甚至浏览器的进程会产生无响应的情况。这点Bindows根本没有遵循“用多少取多少”的准则。另外，内部大量利用了IE（Internet Explorer）的技术，没有考虑到非IE的浏览器，限制了Bindows的流行。
|
|
|
|
（3）Java。一些相当复杂的客户端应用程序（如Eclipse）都是用Java编写的，这说明可以用Java来建立几乎任何一个能够想象得到的RIA。开发人员可以利用Java编写Applet代码，而且能够提供几乎所有编程语言所具备的完整灵活性。不过，在实际应用中，Applet的下载和执行性能较差，在不同操作系统上的执行也很不连贯。因此，虽然Java是最受欢迎的服务器端代码开发平台之一，但它的Applet在实际应用中并不是非常普及。使用Java建立RIA的主要障碍是它的复杂性（即使对简单的窗体和图形也要求编写非常烦琐的代码）。
|
|
|
|
（4）AJAX（Asynchronous JavaScript and XML，异步JavaScript和XML）。AJAX用来描述一组技术，它使浏览器可以为用户提供更为自然的浏览体验。借助于AJAX，可以在用户单击按钮时，使用JavaScript和DHTML立即更新用户界面，并向服务器发出异步请求，以执行更新或查询数据库。当请求返回时，就可以使用JavaScript和CSS来相应地更新用户界面，而不是刷新整个页面。最重要的是，用户甚至不知道浏览器正在与服务器通信，Web站点看起来是即时响应的。AJAX是由几种蓬勃发展的技术以新的方式组合而成的，包含基于XHTML（eXtensible HyperText Markup Language，可扩展超文本标识语言）和CSS（Cascading Style Sheets，层叠样式表）标准的表示；使用DOM（Document Object Model，文档对象模型）进行动态显示和交互；使用XMLHttpRequest与服务器进行异步通信；使用JavaScript绑定一切。
|
|
|
|
（5）Laszlo。Laszlo是一个开源的RIA开发环境。使用Laszlo平台时，开发者只需编写名为LZX的描述语言（其中整合了XML和Javascript），运行在J2EE应用服务器上的Laszlo表示服务器会将其编译成SWF格式的文件并传输给客户端展示。从这点上来说，Laszlo的本质和Flex是一样的。
|
|
|
|
（6）XUL（XML User Interface Language，基于XML的用户界面语言）。XUL可用于建立窗体应用程序，这些应用程序不但可以在Mozilla浏览器上运行，而且也可以运行在其他描述引擎上。XUL描述引擎都非常小（通常都在100KB以下），它既可以使用XML数据，也可以生成XML数据。XUL最大的优点在于它与Gecko引擎的集成，与大多数其他XML用户界面描述语言相比，它是一种非常具有表达力和简洁的语言。
|
|
|
|
（7）Avalon。Avalon是Vista的一部分，是一个图形和展示引擎，主要由新加到.NET框架中的一组类集合而成。Avalon定义了一个在Longhorn中使用的新标记语言，其代号为XAML（eXtensible Application Markup Language，可扩展应用程序标记语言）。可以使用XAML来定义文本、图像和控件的布局，程序代码可以直接嵌入到XAML中，也可以将它保留在一个单独的文件内。这与Flex中的MXML或者Laszlo中的LZX非常相似。不同的是：基于Avalon的应用程序必须运行在Longhorn环境中，而Flex和Laszlo是不依赖于平台的，仅仅需要装有Flash播放器的浏览器即可。
|
|
|
|
|
|
正交（orthogonal）软件架构由组织层和线索的构件构成。层是由一组具有相同抽象级别的构件构成；线索是子系统的特例，它是由完成不同层次功能的构件组成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能。每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在相互调用的。
|
|
|
|
如果线索是相互独立的，即不同线索中的构件之间没有相互调用，那么这个结构就是完全正交的。从以上定义，我们可以看出，正交软件架构是一种以垂直线索构件族为基础的层次化结构，其基本思想是把应用系统的结构按功能的正交相关性，垂直分割为若干个线索（子系统），线索又分为几个层次，每个线索由多个具有不同层次功能和不同抽象级别的构件构成。各线索的相同层次的构件具有相同的抽象级别。因此，我们可以归纳正交软件架构的主要特征如下：
|
|
|
|
（1）正交软件架构由完成不同功能的n（n>1）个线索（子系统）组成。
|
|
|
|
|
|
|
|
（4）系统有一个公共驱动层（一般为最高层）和公共数据结构（一般为最低层）。
|
|
|
|
对于大型的和复杂的软件系统，其子线索（一级子线索）还可以划分为更低一级的子线索（二级子线索），形成多级正交结构。正交软件架构的框架如下图所示。
|
|
|
|
|
|
|
|
上图是一个三级线索、五层结构的正交软件架构框架图。在该图中，ABDFK组成了一条线索，ACEJK也是一条线索。因为B、C处于同一层次中，所以不允许进行互相调用；H、J处于同一层次中，也不允许进行互相调用。一般来讲，第五层是一个物理数据库连接构件或设备构件，供整个系统公用。
|
|
|
|
|
|
（1）结构清晰，易于理解。正交软件架构的形式有利于理解。由于线索功能相互独立，不进行互相调用，结构简单、清晰，构件在结构图中的位置已经说明它所实现的是哪一级抽象，担负的是什么功能。
|
|
|
|
（2）易修改，可维护性强。由于线索之间是相互独立的，所以对一个线索的修改不会影响到其他线索。因此，当软件需求发生变化时，可以将新需求分解为独立的子需求，然后以线索和其中的构件为主要对象分别对各个子需求进行处理，这样软件修改就很容易实现。系统功能的增加或减少，只需相应的增删线索构件族，而不影响整个正交架构，因此能方便地实现结构调整。
|
|
|
|
（3）可移植性强，重用粒度大。因为正交结构可以为一个领域内的所有应用程序所共享，这些软件有着相同或类似的层次和线索，可以实现架构级的重用。
|
|
|
|
|
|
层次消息总线（Hierarchy Message Bus，HMB）的架构风格基于层次消息总线、支持构件的分布和并发，构件之间通过消息总线进行通讯，如下图所示。
|
|
|
|
|
|
|
|
消息总线是系统的连接件，负责消息的分派、传递和过滤以及处理结果的返回。各个构件挂接在消息总线上，向总线登记感兴趣的消息类型。构件根据需要发出消息，由消息总线负责把该消息分派到系统中所有对此消息感兴趣的构件，消息是构件之间通信的唯一方式。构件接收到消息后，根据自身状态对消息进行响应，并通过总线返回处理结果。由于构件通过总线进行连接，并不要求各个构件具有相同的地址空间或局限在一台机器上。该风格可以较好地刻画分布式并发系统，以及基于CORBA、DCOM和EJB规范的系统。
|
|
|
|
如上图所示，系统中的复杂构件可以分解为比较低层的子构件，这些子构件通过局部消息总线进行连接，这种复杂的构件称为复合构件。如果子构件仍然比较复杂，可以进一步分解，如此分解下去，整个系统形成了树状的拓扑结构，树结构的末端结点称为叶结点，它们是系统中的原子构件，不再包含子构件，原子构件的内部可以采用不同于HMB的风格，例如前面提到的数据流风格、面向对象风格及管道-过滤器风格等，这些属于构件的内部实现细节。但要集成到HMB风格的系统中，必须满足HMB风格的构件模型的要求，主要是在接口规约方面的要求。另外，整个系统也可以作为一个构件，通过更高层的消息总线，集成到更大的系统中。于是，可以采用统一的方式刻画整个系统和组成系统的单个构件。
|
|
|
