系统架构_软件架构风格概述
                                   转载自:http://jpkc.whu.edu.cn/jpkc/dxqyxxxtfgnjg/dzja/dzjc/jc3.htm

1         软件架构风格概述

软件体系结构设计的一个核心问题是能否使用重复的体系结构模式，即能否达到体系结构级的软件重用。也就是说，能否在不同的软件系统中，使用同一体系结构。基于这个目的，学者们开始研究和实践软件体系结构的风格和类型问题。

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。

对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可以 共享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为”客户/服务器”模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。

软件系统结构风格通常分为三种模式，即架构模式，设计模式，代码模式。这三种不同的模式存在于它们各自的抽象层次和具体层次。架构模式是一个系统的，多层次策略，涉及到大尺度的组件以及整体性质和力学。它描述软件系统里的基本结构组织或纲要，提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。架构模式的好坏可以影响到总体布局和构架结构。设计模式是中等尺度的结构策略， 它描述了普遍存在的相互通讯组件中重复出现的结构．这种结构解决了在一定背号中的具有一般性的设计问题，定义出了子系统或组件的微观结构。设计模式的好坏不会影响到系统的总体布局和总体框架。代码模式是底层次的模式，并与编程语言密切相关，它描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。代码模式的好坏会影响到一个中等尺度组件的内部、外部结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。

体系结构风格定义了一个系统家族，即一个体系结构定义一个词汇表和一组约束：词汇表中包含一些构件和连接器类型，而这组约束指出系统是如何将这些构件和连接器组合起来的。常见的软件体系结构风格涉及：

• 设计词汇表是什么者构件和连接器的类型是什么/li>
• 可容许的结构模式是什么/li>
• 基本的计算模型是什么/li>
• 风格的基本不变性是什么/li>
• 其使用的常见例子是什么/li>
• 使用此风格的优缺点是什么/li>
• 其常见特例是什么/li>

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

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

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

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

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

2         经典软件架构风格

2.1    管道和过滤器风格

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

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

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

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

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

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

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

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

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

2.3    基于事件的隐式调用风格

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

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

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

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

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

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

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

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

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

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

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

2.4    层次系统风格

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

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

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

图 2黑板系统的组成

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

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

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

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

2.6    C2风格

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

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

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

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

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

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

4.2 三层C/S的功能

1.表示层
　 　表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，显示应用输出的数据。为使用户能直观地进行操作，一 般要使用图形用户接口(GUI)，操作简单、易学易用。在变更用户接口时，只需改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的 形式和值的范围，不包括有关业务本身的处理逻辑。
      图形界面的结构是不固定的，这便于以后能灵活地进行变更。例如，在一个窗口中不是放入几个功能，而是按功能分割窗口，以便使每个窗口的功能简洁单纯。在这层的程序开发中主要是使用可视化编程工具。

---

xR~2U}bqKO+0L8_& 
2. 功能层
　 　功能层相当于应用的本体，它是将具体的业务处理逻辑地编入程序中。例如，在制作订购合同的时要计算合同金额，按照定好的格式配置数据、打印订购合同，而 处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。例如，用户检索数据时，要设法将有关检索要求的信息一次传送给功能 层(参见图2)，而由功能层处理过的检索结果数据也一次传送给表示层。在应用设计中，一定要避免进行一次业务处理，在表示层和功能层间进行多几次数据交换 的笨拙设计。
通常，在功能层中包含有：确认用户对应用和数据库存取权限的功能以及记录系统处理日志的功能。这层的程序多半是用可视化编程工具开发的，也有使用COBOL和C语言的。
3. 数据层
　　数据层就是DBMS，负责管理对数据库数据的读写。DBMS必须能迅速执行大量数据的更新和检索。现在的主流是关系数据库管理系统(RDBMS)。因此，一般从功能层传送到数据层的要求大都使用SQL语言。

4.3 三层C/S结构的优点

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

---

 
　 　对于各个层可以选择与其处理负荷和处理特性相适应的硬件。这是一个与系统可缩放性直接相关的问题。例如，最初用一台Unix工作站作为服务器，将数据层 和功能层都配置在这台服务器上。随着业务的发展，用户数和数据量逐渐增加，这时就可以将Unix工作站作为功能层的专用服务器，另外追加一台专用于数据层 的服务器。若业务进一步扩大，用户数进一步增加，则可以继续增加功能层的服务器数目，用以分割数据库。清晰、合理地分割三层结构并使其独立，可以使系统构 成的变更非常简单。因此，被分成三层的应用基本上不需要修正。
2。 提高程序的可维护性
　　三层C/S结构中，应用的各层可以并行开发，各层也可以选择各自最适合的开发语言。
3。 利于变更和维护应用技术规范
　　因为是按层分割功能，所以各个程序的处理逻辑变得十分简单。
4。 进行严密的安全管理
　　越关键的应用，用户的识别和存取权限设定愈重要。在三层C/S结构中，识别用户的机构是按层来构筑的，对应用和数据的存取权限也可以按层进行设定。例如，即使外部的入侵者突破了表示层的安全防线，若在功能层中备有另外的安全机构，系统也可以阻止入侵者进入其他部分。
　　此外，系统管理简单，可支持异种数据库，有很高的可用性。

4.4 三层C/S应用的开发

---

[su);dH 
　　三层C/S应用的开发必须遵从以下原则：保护已有投资；降低应用系统的风险； 满足当前的迫切需要；考虑未来的发展规划。
　　开发出的三层C/S应用系统必须是：功能丰富且具有高可用性；功能要能跨应用系统；系统要能跨平台运行。
　 　美国BEA系统有限公司产品计划和战略副总裁Jeri Edwards女士，按下述三种三层C/S应用系统的典型开发类型，分别举例介绍了他们的开发目标、开发过程、开发成果及经验体会。新建应用系统类型 (Greenfield)，如英国劳工局的劳动力市场系统；提升已有系统性能类型(Turbocharger)，如Apple公司的AppleOrder Global系统；综合集成已有系统类型(Integrator)，如AT&T的Zenith应用系统。Jeri Edwards女士根据三层C/S应用系统的开发经验和教训，总结出了实现C/S应用系统的黄金10原则 ：
　　(1) 尽量简化项目，使项目易于管理。应尽快建起一个初始系统，并尽早投入运行。当项目规模较大时，可以将其分割成由更小开发组担负的子项目。
　　(2) 要把精力花在设计上。首先要彻底弄清需求 ，然后建立一个原型，以便测试设计中的薄弱环节。后来增加的特性或部件要保证与系统结构兼容。
　　(3) 要奉行拿来主义。近来，可供选购的市售C/S产品很多，要坚持能买就买，为我所用的原则。必要时，买来后可对系统加以修改，其中既包括基础部件也包括应用。
　　(4) 严格遵守业界标准。
　　(5) 采用TP监控器或对象事务处理管理器 (Object Transaction Manager ，OTM)。
　　(6) 要循序渐进。及时得到用户的反馈；保证项目各部分的良好衔接；及早解决接口问题，以保证项目进展协调；坚持边分析，边设计；边编码，边测试的原则。
　　(7) 在应用开发过程中，不可忽视系统管理。
　　(8) 反复测试，包括用户信任测试、基准测试、系统测试、性能测试、系统集成测试、坚固性测试、服务交付测试等。
　　(9) 制定合理的工程进度。
　　(10) 制定完善的系统拓展计划，包括用户的培训和技术支持、高效的硬软件装载、已有数据和系统的平滑迁移。

---

>xkr k=M#-sF_Z 62^
*G

4.5 三层C/S应用中的核心

 

每个C/S环境，从最小的LAN环境到超级网络环境，都使用某种形式的中间件。实际上，无论客户机何时给服务器发送请求，也无论它何时应用存取数据库文 件，都有某种形式的中间件传递C/S链路，用以消除通信协议、数据库查询语言、应用逻辑与操作系统之间潜在的不兼容问题。中间件是C/S环境中最重要的部 件。所谓中间件是一个用API定义的软件层，是具有强大通信能力和良好可扩展性的分布式软件管理框架。它的功能是在客户机和服务器或者服务器和服务器之间 传送高级通信，将客户机群和服务器群有机地粘合起来。其工作流程是：在客户机里的应用程序需要驻留网络上某个服务器的数据或服务时，搜索此数据的C/S应 用程序需访问中间件系统，该系统将查找数据源或服务，并在发送应用程序请求后重新打包响应，将其传送回应用程序。

---

N2nM^J^ 
　 　TP监控器在中间件技术中扮演着越来越重要的角色，特别是在三层C/S系统中。据Standish Group的调查，TP监控器是近两年信息业界最热门的技术之一。1996年有57%的关键应用是构筑在TP监控器上的。TP监控器擅长提供事务性语义， 允许就环境速度和可靠性进行编程。作为一种中间件，TP监控器提供一种用于编写分布式应用程序的API，它通常包含一组强大的管理工具。TP监控器是一个 高性能、高并行性、多用户的快速响应软件运行环境，它能有效地管理大量的并发任务，进而提高系统资源的利用率。如果采用TP监控器，系统总投资可节约 30%以上，开发周期可缩短40%～50%。大多数投入应用的三层应用系统都配备有一套事务处理监控系统，BEA TUXEDO是目前应用最广泛的事务处理监控系统。
　 　BEA TUXEDO是用于分布计算的中间件基础结构，它使开放式应用系统具有高可缩放性、高灵活性和高可维护性。它不仅具有分布式交易处理和应用间报文通信的功 能，而且具有一系列极其完善的服务，可帮助企业建立和运行应用系统，使开发人员能够建立跨越多个平台、数据库和操作系统的应用程序。这样，可以灵活选配操 作平台以充分适应应用环境。它具有以下特点： 
　　1、支持多种软硬件平台。完全符合Open Group的X/Open标准，支持TCP/IP协议，支持包括Unix、Windows NT、AS/400和大型机专用系统在内的70多个硬件平台和操作系统。
　　2、结构开放、灵活。模块结构以高级程序接口ATMI(Application-to-Transaction Manager Interface)为中心，有丰富的ATMI函数可供调用。
　　3、开放的联机事务处理。可提供诸如事务性语义、透明的二段式提交、事务记录及分布事务处理管理结构等功能。
　　4、与DCE的结合。通过一套工具和程序库，实现了与Open Group组织的分布计算环境DCE的有机结合。
　　5、功能丰富，包括：应用管理；事件代理；通过鉴别服务、授权服务和数据加密服务，为客户提供安全保证；对COBOL语言的支持；应用动态调节、负载平衡等保证高可靠性的功能等。
六、三层C/S结构的应用现状
　 　目前，用三层C/S结构开发的应用还不太多，但其数量的确在逐日增加。图3显示了北美运行的应用开发形态。三层C/S型应用的比例1995年占 5%，1997年增加到7。8%，预计到1999年将占22。9%。二层C/S型应用和在原有系统上附加GUI型的应用，是被定位为向三层C/S型转化的 过
度形态。就当前来说，这种形态的比例要比三层C/S高，且要持续一段时间。那么，什么情况下应采用三层C/S呢Gartner Group的调查表明，具有下述特点的应
用应考虑采用三层C/S。
　　1、应用的服务或种类超过50个；
　　2、应用是用不同语言编写的；
　　3、两个以上的异构数据源，如2个不同的DBMS或1个DBMS和1个文件系统；
　　4、应用的生命周期超过3年；
　　5、高工作负荷，例如每天超过5万个事务处理或在同一系统访问同一数据库的并发用户数超过300个；
　　6、有至关重要的应用内部通信，包括像电子数据交换(EDI)这类企业的内部通信。
　　从传统的主机/终端型应用到三层C/S化，要考虑时间和费用问题，有的场合还不适合，需要循序渐进。

5         浏览器/服务器风格

5.1 B/S结构的基本概念

B/S结构，即Browser/Server(浏览器/服务器)结构，是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，客户机上只要安装一个浏览器（Browser），如Netscape Navigator或Internet Explorer，服务器安装Oracle、Sybase、Informix或 SQL Server等数据库。浏览器通过Web Server同数据库进行数据交互。用户界面完全通过WWW浏览器实现，一部分事务逻辑在前端实现，但是主要事务逻辑在服务器端实现，形成所谓3-tier结构。B/S结构，主要是利用了不断成熟的WWW浏览器技术，结合浏览器的多种Script语言(VBScript、JavaScript…)和ActiveX技术，用通用浏览器就实现了原来需要复杂专用软件才能实现的强大功能，并节约了开发成本，是一种全新的软件系统构造技术。随着Windows 98/Windows 2000将浏览器技术植入操作系统内部，这种结构更成为当今应用软件的首选体系结构。

以目前的技术看，局域网建立B/S结构的网络应用，并通过Internet/Intranet模式下数据库应用，相对易于把握、成本也是较低的。它是一次 性到位的开发，能实现不同的人员，从不同的地点，以不同的接入方式（比如LAN， WAN， Internet/Intranet等）访问和操作共同的数据库；它能有效地保护数据平台和管理访问权限，服务器数据库也很安全 。特别是在JAVA这样的跨平台语言出现之后，B/S架构管理软件更是方便、快捷、高效。

B／S三层体系结构采用三层客户／服务器结构，在数据管理层(Server)和用户界面层(Client)增加了一层结构，称为中间件 (Middleware)，使整个体系结构成为三层。三层结构是伴随着中间件技术的成熟而兴起的，核心概念是利用中间件将应用分为表示层、业务逻辑层和数 据存储层三个不同的处理层次，如图2所示。三个层次的划分是从逻辑上分的，具体的物理分法可以有多种组合。中间件作为构造三层结构应用系统的基础平台，提 供了以下主要功能：负责客户机与服务器、服务器与服务器间的连接和通信；实现应用与数据库的高效连接；提供一个三层结构应用的开发、运行、部署和管理的平 台。这种三层结构在层与层之间相互独立，任何一层的改变不会影响其它层的功能。 
       在B／S体系结构系统中，用户通过浏览器向分布在网络上的许多服务器发出请求，服务器对浏览器的请求进行处理，将用户所需信息返回到浏览器。而其余如数据 请求、加工、结果返回以及动态网页生成、对数据库的访问和应用程序的执行等工作全部由Web Server完成。随着Windows将浏览器技术植入操作系统内部，这种结构已成为当今应用软件的首选体系结构。显然B／S结构应用程序相对于传统的 C／S结构应用程序是一个非常大的进步。

5.2 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除了操作系统是免费的 以外，连数据库也是免费的，这种选择非常盛行。 
     比如说很多人每天上“网易”（原文为新浪）网，只要安装了浏览器就可以了，并不需要了解“网易”的服务器用的是什么操作系统，而事实上大部分网站确实没有使用windows操作系统，但用户的电脑本身安装的大部分是windows操作系统。 
（3）、应用服务器运行数据负荷较重。 
     由于B/S架构管理软件只安装在服务器端（Server）上，网络管理人员只需要管理服务器就行了，用户界面主要事务逻辑在服务器 （Server）端完全通过WWW浏览器实现，极少部分事务逻辑在前端（Browser）实现，所有的客户端只有浏览器，网络管理人员只需要做硬件维护。 但是，应用服务器运行数据负荷较重，一旦发生服务器“崩溃”等问题，后果不堪设想。因此，许多单位都备有数据库存储服务器，以防万一。 

5.3 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等信息流向的变化， 更像交易中心。

6         正交软件架构风格

6.1    正交软件架构风格概述

正交软件架构由组织层(Layer)和线索(Thread)的构件(Component)构成。层是由一组具有相同抽象级别(Level of Abstraction)的构件构成。线索是子系统的特例，它是由完成不同层次功能的构建组成（通过相互调用来关联），每一条线索完成整个系统中相对独立的一部分功能。每一条线索的实现与其他线索的实现无关或关联很少，在同一层中的构件之间是不存在相互调用的。

       如果线索是相互独立的，即不同线索中的构建之间没有相互调用，那么这个节都就是完全正交的。从以上定义，我们可以看出，正交软件架构是一种以垂直线索架构族为基础的层次化结构，其解不能思想是把应用系统的结构按功能的正交相关性，垂直分割为若干个线索（子系统），线索又分为几个层次，每个线索由多个具有不同层次功能和不同抽象级别的构件构成。各线索的相同层次的构建具有相同的抽象级别。因此，我们可以归纳正交软件架构的主要特征如下：

（1）    由完成不同功能的n(n>1)个线索（子系统）组成；

（2）    系统具有m(m>1)个不同抽象级别的层；

（3）    线索之间是相互独立的(正交的)；

（4）    系统有一个公共驱动层（一般为最高层）和公共数据结构（一般为最底层）。

对大型的和复杂的软件系统，其子系统（一级子线索）还可以划分为更低一级的子线索（二级子线索），形式多级正交结构。正交软件架构的框架如图所示：

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

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

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

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

7.2    构建模型

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

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

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

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

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

来源：JustInToday