自1964年G. AMDAhl首次提出体系结构这个概念，人们对计算机系统开始有了统一而清晰的认识，为从此以后计算机系统的设计与开发奠定了良好的基础。近四十年来, 体系结构学科得到了长足的发展, 其内涵和外延得到了极大的丰富。特别是网络计算技术的发展，使得网络计算体系结构成为当今一种主要的计算模式结构。微电子技术的飞速发展使芯片级体系结构研究成为一个挑战性课题。体系结构与系统软件，应用软件，程序设计语言的紧密结合与相互作用也使今天的计算机与以往有很大的不同，并触发了大量的前沿技术、相关产品开发与基础研究课题。
在传统的程序设计领域中，人们使用流程图来表达系统的基本功能和实现的具体逻辑，但是，流程图实际上仅仅是源程序的图形化表示，无法给系统的分析和开发者提供更多的信息，所以没有在实际的系统开发过程中得到广泛的应用。随着软件系统的规模和复杂性的增加，对软件系统的整体结构（数据和控制的逻辑）进行分析和描述成为大型系统开发的一个不可缺少的重要部分，显然，使用流程图是无法达到这个目标的，我们必须使用新的方法和概念来对系统的整体结构进行把握。
系统分析实际上包括两个阶段的工作，首先是需求的 分析，也就是说，划分出系统和环境之间的界面，将所研究（或者是将要开发）的系统和周围的环境分离，这就是从使用者的观点，将整个系统作为一个整体来考 察。其次是系统的设计，根据系统的整体功能和数据，参考实际的物理系统或者类似的系统，设计实际运行的软件系统，这一步骤实际上就是体系结构的分析和确 定。
从系统工程的观点看来，任何复杂的系统都是由相对简单的，在当前所分析的系统层次是原始的基本元素（虽然在更进一步的分析中，这些元素可能具有非常复杂的 内部结构）组成的，这些基本元素之间存在复杂的相互作用。所以，软件系统的分析和设计的基本任务是：确立系统中的基本元素（完成系统的功能所必不可少的成 分）；确定这些元素之间相互作用的方式（这就是系统的体系结构）。
我们在这里简单的介绍几种最基本的体系结构的范式，他们的特点、优点和缺点，最后给出实际开发中如何选择体系结构范式的一些指导性的意见。
一、基本的体系结构的范式
1. 管道和过滤器：
每个组件具有输入和输出的集合，从流中读出数据作为输入，产生输出数据的流。整个系统可以看成多个过滤器复合形成的数据处理组件。
过滤器A
过滤器B
过滤器C
过滤器A
过滤器D
管道
管道
特点：
l 过滤器之间是相互独立的（不能共享状态），其中一个过滤器的操作和行为不能影响另外过滤器的操作和行为，流的传送没有副作用。
l 过滤器对所输入流的来源和输出流的去向不关心，不需要知道流的来源和流的去向，来源和去向对于过滤器的数据处理没有任何影响。
l 过滤和流的传送可以是并发的，可以同时有多个流的传送存在于系统之中。
实例：
一个最著名的实例是unix的shell编程，多个对数据进行处理的程序（组件）通过管道联结起来，产生总和的效果；还有传统的编译器，源代码经过词法分析、语法分析、中间代码生成、目标代码生成等步骤生成输出的目标代码。
优点：
l 整个系统的功能是多个过滤器作用的总和，这样可以简化系统的分析和设计，可以经过需求的分析之后将整个系统作为一个过滤器处理，然后再逐步的细化成为多个相互连接的过滤器。
l 支持组件的重用，同一个过滤器可以多次出现在系统的不同位置。
l 易于维护和增强，过滤器可以被替换，可以增加新的过滤器到系统中而不改变原有的过滤器，不改变原来系统的基本功能。
l 本质上的并发性支持，这种体系结构由于本质上是与各个独立的过滤器的状态无关的，与并行的流的通过次序也是无关的，所以并发是一个基本的体系结构自然具有的特性。
缺点：
l 由于过滤器之间本质上是独立的，所以设计者必须独立考虑每一个过滤器的输入、处理和输出的过程，对于过滤器逻辑上的共同点和相互关系无法在设计中加以体现。
l 由于这种体系的批处理特性，所以不适合开发和用户交互的应用程序。
l 系统的多个处理流之间的共同特性无法提取、多个过滤器之间的共同特性也无法提取，所以增加了设计的复杂性。
2. 数据抽象和面向对象的体系
在这种体系中，数据和数据上的操作被封装成抽象数据类型或者对象。系统由大量的对象组成，在物理上，对象之间通过函数或者过程调用相互作用；在逻辑上，对象之间通过集成、复合等方式实现设计的复用。
对象D
对象B
对象A
对象E
对象C
对象调用
对象调用
对象调用
类A
类B
类C
类G
对象A
对象E
类F
复合
继承
物理结构 逻辑结构
特点：
面向对象系统分析和设计的资料已经太多，这里就不再详细说明了。
优点：
由于封装，实现了灵活性和扩充性，隐藏了实现的细节，提高代码的质量；
使用继承和多态、提高了软件的可重用性。
缺点：
最主要的缺点是，由于对象之间的交互是通过明确的对象函数调用进行的，所以当一个对象需要实现一个特定功能的时候，必须知道哪一个对象提供这种服务，这就降低了系统的灵活性。管道和过滤器模型不需要明确指明数据的来源和去向。
3. 事件驱动的体系
对象E
对象E
对象E
事件分发的总线
事件的创建
事件接收者的注册的创建
对象E
这是面向对象和数据抽象体系的一种变形，系统同样是由大量的对象组成的，但是对象之间的交互不是通过明确指明对象的函数或者过程调用进行的，相反，系统提 供事件的创建和发布的机制，对象产生事件，一个或者多个对象通过向系统注册关注这个事件并由此触发出相应的行为或者产生新的事件。
实例：
一个最著名的例子是GUI的模型，鼠标、键盘或者其他输入设备产生各种事件，窗口、程序或者其他对象有这些事件所触发，产生新的事件、进行数据处理或者其他操作。
优点：
用于函数和过程的调用调用不需要指明特定的对象，所以系统具有非常好的灵活性和扩展性，新的组件只需要向系统的事件处理部分注册就可以立刻加入系统中，同 样，老的组件也可以方便的从系统中删除。对于动态性要求特别高的系统，特别是如果需要在运行时对系统进行扩充，应该采用该结构。
缺点：
由于函数调用是通过事件发送进行的，所以，发出事件的对象不能确认是否有对象处理了这个事件、是否是期望的对象处理了这个事件、是否获得期望的结果，同样也无法控制事件发生的次序，系统的逻辑和时序的正确性必须通过复杂的时序逻辑和前后条件的断言加以保证。
4. 分层次的体系
将系统功能和组件分成不同的功能层次，一般而言，只有最上层的组件和功能可以被系统外的使用者访问，只有相邻的层次之间才能够有函数调用。
下面是一个基本的商务处理系统的层次结构：
事务逻辑层
核心层
实例：
显然，ISO的OSI（开放系统互连）参考模型是最著名的层次模型的例子，通过将开放系统的功能和组件划分成7个层次，定义清晰的（很多时候是过于复杂的）层次之间的接口，实现复杂的互操作性。
优点：
l 系统的开发和设计可以逐步的分层次的进行，从底层的简单的功能逐步建立高层的复杂和抽象的功能。
l 灵活性和扩展性，由于相邻层次之间通过清晰的接口交互，所以特定的层次可以被替换和增强，甚至可以增加新的层次。
缺点：
l 不是所有的系统都可以分解成为清楚的层次
l 划分清晰、逻辑上一致的层次是非常困难的（OSI的失败和TCP/IP的成功说明了这一点）
l 严格的层次调用结构会降低系统的性能。
5. 知识库体系
使用一个中心数据结构表示系统的当前状态，一组相互独立的组件在中心数据库上进行操作。如果组件负责对中心数据进行选择、处理，这种体系就是传统的数据库模型；如果中心数据结构自主的引发一系列的行为，则这种体系可以看成一个黑板模型。
中心数据库（知识库）
客户组件A
客户组件B
客户组件C
实例：
大量的传统数据库应用程序实际上就是这一体系的具体实例。在很多研究系统中，使用的基于知识库的黑板模型，实际上也是这种体系
优点：
以数据为中心的体系结构，可以自然的表示大量的数据和事务处理的逻辑，适合表达以数据为重新的应用程序。
缺点：
只有很少一部分简单的数据库存储应用可以完全采用这种体系结构表示，在大量实际的商业应用中，完成师傅处理和其他逻辑的应用程序必须采用其他的体系结构表达
6. 解释器体系
用户
如果应用程序的逻辑非常复杂，例如，AutoCAD的各种绘图指令，而且，用户可能以非常复杂的方式使用这个系统，一个较好的体系就是提供面向领域的一组指令（语言），系统解释这种语言，产生相应的行为，用户使用这种指令（语言）完成复杂的操作。
使用虚拟机语言描述的业务逻辑
虚拟机解释器
完成实际操作任务的基本指令
实际的问题领域
实例：
大量的开发工具、二次开发工具体现了这一思想：微软在其产品中大量使用的Visual BASic for Application，以及在AutoDESk产品中大量使用的AutoLisp语言，实际上就是给用户提供了一种面向领域的语言，然后核心解释执行这一语言的指令和指令序列。从而扩充产品的功能，方便用户按照自己的需要定制系统。
优点：
非常好的扩展性，用户可以实现对软件系统的二次开发
缺点：
软件开发复杂，特别是这种指令集的设计非常困难。
是否可以采用一种成熟的语言作为二次开发的基础（例如，基于Java）
二、实际系统开发的观点
在实际开发过程中，简单的判断某一个具体的应用应该采取何种体系结构是非常困难的。从目前的趋势来看：简单的管道、过滤器体系已经非常少见，面向对象的思 想已经融合在几乎所有的体系结构之中，而层次化的思想同样也被广泛使用，所以，一个基本的系统分析方法应该是功能和复杂性的分解，也就是说，从横向分解 （分模块、子系统），纵向分解中得到系统的基本组件（分类、分层次的功能和对象）。然后根据问题领域的特性选择系统的行为模式（具体的体系结构）。
三、目前最常见的体系结构
l 严格的层次结构（系统可以清楚的分解成为不同的功能层次，例如基本的图形库，提供不同层次的绘图接口）
这种体系结构适合于系统的功能相对简单，并且可以按照复杂的程度、抽象的程度、和硬件平台的关系等方面的特性加以分层的软件中。
l 事件驱动的体系：
对互操作性、特别是异构环境下的互操作性要求非常高的情况下，可以采用这种体系，当整个系统中存在大量的并发的，相互之间没有逻辑联系的组件的时候（例如操作系统或者图形用户界面）可以使用这种体系结构。现代软件技术中微软的COM和ISO的CORBA实际上都是这种体系结构的例子。
l 知识库的体系：
以大量数据为核心的系统采用这种体系，一些人工智能的应用同样需要这种体系结构，面向对象的知识库是这种体系结构的一个发展方向。将面向对象和层次化的思想引入知识库系统中，将得到一种非常强大的体系结构。
l 基于解释器的体系：
如果应用系统和用户的交互非常复杂，采用这种体系结构是最适合的方案，只有将系统的基本操作以指令的形式提供给用户，同时，提供一种简单明了的语法和基本 的数据操作、处理的功能，才能得到功能最强大、最灵活、具有最佳扩充新的应用系统；一个非常合适的例子是浏览器，一开始，浏览器只是简单的下载和显示 HTML的页面，随着用户对界面交互要求的发展，开发出javasCRipt，提供一种语言和基本的界面元素操纵的指令来得到扩充性和强大的功能。
绝大多数实际运行的系统都是上面几种体系结构的复合：在系统的某些部分采用一种体系结构而在其他的部分采用另外的体系，我们可以将复合几种基本体系结构的 系统称作复合体系结构。在实际的系统分析和设计中，可能首先将整个系统作为一个功能体进行分析和权衡，得到适宜的、最上层的体系结构，如果该体系结构中的 元素较为复杂，可以继续进行分解，得到某一部分的，局部的体系。分析的层次应该在可以清晰的使用简单的功能和界面描述表达结束，这样，可以将我们在分析和 设计的这一阶段将焦点集中在系统的总体结构上，而避免引入和所使用的语言、实现所具体需要的技术等实现的细节上。
]]>软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。
对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可 以共享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为”客户／服务 器”模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。
下面是Garlan和Shaw对通用体系结构风格的分类：
（1）数据流风格：批处理序列；管道/过滤器
（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构
（3）独立构件风格：进程通讯；事件系统
（4）虚拟机风格：解释器；基于规则的系统
（5）仓库风格：数据库系统；超文本系统；黑板系统
在上两篇文章中，我们介绍了软件体系结构的概念、现状及发展方向，读者可能会觉得”软件体系结构太抽象、太理论化，没有什么实际的东西”。然而，任何实践都必须接受理论的指导，如果抛弃理论基础，一味地追求实用，那也只能是囫囵吞枣。
软件体系结构设计的一个核心问题是能否使用重复的体系结构模式，即能否达到体系结构级的软件重用。也就是说，能否在不同的软件系统中，使用同一体系结构。基于这个目的，学者们开始研究和实践软件体系结构的风格和类型问题。
软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。它反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。按这种方式理解，软件体系结构风格定义了用于描述系统的术语表和一组指导构件系统的规则。
对软件体系结构风格的研究和实践促进了对设计的复用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。体系结构风格的不变部分使不同的系统可 以共享同一个实现代码。只要系统是使用常用的、规范的方法来组织，就可使别的设计者很容易地理解系统的体系结构。例如，如果某人把系统描述为”客户／服务 器”模式，则不必给出设计细节，我们立刻就会明白系统是如何组织和工作的。
下面是Garlan和Shaw对通用体系结构风格的分类：
（1）数据流风格：批处理序列；管道/过滤器
（2）调用/返回风格：主程序/子程序；面向对象风格；层次结构
（3）独立构件风格：进程通讯；事件系统
（4）虚拟机风格：解释器；基于规则的系统
（5）仓库风格：数据库系统；超文本系统；黑板系统
限于篇幅，在本文中，我们将只介绍几种主要的和经典的体系结构风格和它们的优缺点。有关新出现的软件体系结构风格，将在后续文章中进行介绍。
一、C2风格
C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：
（1）系统中的构件和连接件都有一个顶部和一个底部；
（2）构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
（3）一个连接件可以和任意数目的其它构件和连接件连接；
（4）当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
图1是C2风格的示意图。图中构件与连接件之间的连接体现了C2风格中构建系统的规则。
图1 C2风格的体系结构
C2风格是最常用的一种软件体系结构风格。从C2风格的组织规则和结构图中，我们可以得出，C2风格具有以下特点：
（1）系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起；
（2）所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的；
（3）构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设。
二、管道/过滤器风格
在管道/过滤器风格的软件体系结构中，每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常通过对输入流 的变换及增量计算来完成，所以在输入被完全消费之前，输出便产生了。因此，这里的构件被称为过滤器，这种风格的连接件就象是数据流传输的管道，将一个过滤 器的输出传到另一过滤器的输入。此风格特别重要的过滤器必须是独立的实体，它不能与其它的过滤器共享数据，而且一个过滤器不知道它上游和下游的标识。一个 管道/过滤器网络输出的正确性并不依赖于过滤器进行增量计算过程的顺序。
图2是管道/过滤器风格的示意图。一个典型的管道/ 过滤器体系结构的例子是以Unix shell编写的程序。Unix既提供一种符号，以连接各组成部分(Unix的进程)，又提供某种进程运行时机制以实 现管道。另一个著名的例子是传统的编译器。传统的编译器一直被认为是一种管道系统，在该系统中，一个阶段（包括词法分析、语法分析、语义分析和代码生成） 的输出是另一个阶段的输入。
图2 管道/过滤器风格的体系结构
管道/过滤器风格的软件体系结构具有许多很好的特点：
（1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；
（2）允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；
（3）支持软件重用。重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；
（4）系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；
（5）允许对一些如吞吐量、死锁等属性的分析；
（6）支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。
但是，这样的系统也存在着若干不利因素。
（1）通常导致进程成为批处理的结构。这是因为虽然过滤器可增量式地处理数据，但它们是独立的，所以设计者必须将每个过滤器看成一个完整的从输入到输出的转换。
（2）不适合处理交互的应用。当需要增量地显示改变时，这个问题尤为严重。
（3）因为在数据传输上没有通用的标准，每个过滤器都增加了解析和合成数据的工作，这样就导致了系统性能下降，并增加了编写过滤器的复杂性。
三、数据抽象和面向对象风格
抽象数据类型概念对软件系统有着重要作用，目前软件界已普遍转向使用面向对象系统。这种风格建立在数据抽象和面向对象的基础上，数据的表示方法和它们的 相应操作封装在一个抽象数据类型或对象中。这种风格的构件是对象，或者说是抽象数据类型的实例。对象是一种被称作管理者的构件，因为它负责保持资源的完整 性。对象是通过函数和过程的调用来交互的。
图3是数据抽象和面向对象风格的示意图。
图3 数据抽象和面向对象风格的体系结构
面向对象的系统有许多的优点，并早已为人所知：
（1）因为对象对其它对象隐藏它的表示，所以可以改变一个对象的表示，而不影响其它的对象。
（2）设计者可将一些数据存取操作的问题分解成一些交互的代理程序的集合。
但是，面向对象的系统也存在着某些问题：
（1）为了使一个对象和另一个对象通过过程调用等进行交互，必须知道对象的标识。只要一个对象的标识改变了，就必须修改所有其他明确调用它的对象。
（2）必须修改所有显式调用它的其它对象，并消除由此带来的一些副作用。例如，如果A使用了对象B，C也使用了对象B，那么，C对B的使用所造成的对A的影响可能是料想不到的。
四、基于事件的隐式调用风格
基于事件的隐式调用风格的思想是构件不直接调用一个过程，而是触发或广播一个或多个事件。系统中的其它构件中的过程在一个或多个事件中注册，当一个事件被触发，系统自动调用在这个事件中注册的所有过程，这样，一个事件的触发就导致了另一模块中的过程的调用。
从体系结构上说，这种风格的构件是一些模块，这些模块既可以是一些过程，又可以是一些事件的集合。过程可以用通用的方式调用，也可以在系统事件中注册一些过程，当发生这些事件时，过程被调用。
基于事件的隐式调用风格的主要特点是事件的触发者并不知道哪些构件会被这些事件影响。这样不能假定构件的处理顺序，甚至不知道哪些过程会被调用，因此，许多隐式调用的系统也包含显式调用作为构件交互的补充形式。
支持基于事件的隐式调用的应用系统很多。例如，在编程环境中用于集成各种工具，在数据库管理系统中确保数据的一致性约束，在用户界面系统中管理数据，以 及在编辑器中支持语法检查。例如在某系统中，编辑器和变量监视器可以登记相应Debugger的断点事件。当Debugger在断点处停下时，它声明该事 件，由系统自动调用处理程序，如编辑程序可以卷屏到断点，变量监视器刷新变量数值。而Debugger本身只声明事件，并不关心哪些过程会启动，也不关心 这些过程做什么处理。
隐式调用系统的主要优点有：
（1）为软件重用提供了强大的支持。当需要将一个构件加入现存系统中时，只需将它注册到系统的事件中。
（2）为改进系统带来了方便。当用一个构件代替另一个构件时，不会影响到其它构件的接口。
隐式调用系统的主要缺点有：
（1）构件放弃了对系统计算的控制。一个构件触发一个事件时，不能确定其它构件是否会响应它。而且即使它知道事件注册了哪些构件的构成，它也不能保证这些过程被 调用的顺序。
（2）数据交换的问题。有时数据可被一个事件传递，但另一些情况下，基于事件的系统必须依靠一个共享的仓库进行交互。在这些情况下，全局性能和资源管理便成了问题。
（3）既然过程的语义必须依赖于被触发事件的上下文约束，关于正确性的推理存在问题。
五、层次系统风格
层次系统组织成一个层次结构，每一层为上层服务，并作为下层客户。在一些层次系统中，除了一些精心挑选的输出函数外，内部的层只对相邻的层可见。这样的 系统中构件在一些层实现了虚拟机（在另一些层次系统中层是部分不透明的）。连接件通过决定层间如何交互的协议来定义，拓扑约束包括对相邻层间交互的约束。
这种风格支持基于可增加抽象层的设计。这样，允许将一个复杂问题分解成一个增量步骤序列的实现。由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件重用提供了强大的支持。
图4是层次系统风格的示意图。层次系统最广泛的应用是分层通信协议。在这一应用领域中，每一层提供一个抽象的功能，作为上层通信的基础。较低的层次定义低层的交互，最低层通常只定义硬件物理连接。
图4 层次系统风格的体系结构
层次系统有许多可取的属性：
（1）支持基于抽象程度递增的系统设计，使设计者可以把一个复杂系统按递增的步骤进行分解；
（2）支持功能增强，因为每一层至多和相邻的上下层交互，因此功能的改变最多影响相邻的上下层；
（3）支持重用。只要提供的服务接口定义不变，同一层的不同实现可以交换使用。这样，就可以定义一组标准的接口，而允许各种不同的实现方法。
但是，层次系统也有其不足之处：
（1）并不是每个系统都可以很容易地划分为分层的模式，甚至即使一个系统的逻辑结构是层次化的，出于对系统性能的考虑，系统设计师不得不把一些低级或高级的功能综合起来；
（2）很难找到一个合适的、正确的层次抽象方法。
六、仓库风格
在仓库风格中，有两种不同的构件：中央数据结构说明当前状态，独立构件在中央数据存贮上执行，仓库与外构件间的相互作用在系统中会有大的变化。
控制原则的选取产生两个主要的子类。若输入流中某类时间触发进程执行的选择，则仓库是一传统型数据库；另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是一黑板系统。
图4是黑板系统的组成。黑板系统的传统应用是信号处理领域，如语音和模式识别。另一应用是松耦合代理数据共享存取。
图4 黑板系统的组成
我们从图4中可以看出，黑板系统主要由三部分组成：
（1）知识源。知识源中包含独立的、与应用程序相关的知识，知识源之间不直接进行通讯，它们之间的交互只通过黑板来完成。
（2）黑板数据结构。黑板数据是按照与应用程序相关的层次来组织的解决问题的数据，知识源通过不断地改变黑板数据来解决问题。
（3）控制。控制完全由黑板的状态驱动，黑板状态的改变决定使用的特定知识。
七、结束语
软件体系结构风格为大粒度的软件重用提供了可能。然而，对于应用体系结构风格来说，由于视点的不同，系统设计师有很大的选择空间。要为系统选择或设计某一个体系结构风格，必须根据特定项目的具体特点，进行分析比较后再确定，体系结构风格的使用几乎完全是特化的。
在本文中，我们只讲述了”纯”的体系结构。但是，从上面的介绍中，我们知道，不同的结构有不同的处理能力的强项和弱点，一个系统的体系结构应该根据实际 需要进行选择，以解决实际问题。事实上，也存在一些系统，它们是由这些纯体系结构组合而成，即采用了异构软件体系结构。关于软件体系结构的异构问题，我们 将在后续文章中进行介绍
]]>下午4点，电话铃又响：”妈妈，晚上几个同学想来家里吃饭，你帮准备一下。” （紧急订单）
“好的，儿子，你们想吃什么，爸爸晚上也有客人，你愿意和他们一起吃吗？”
“菜你看着办吧，但一定要有番茄炒鸡蛋。我们不和大人一起吃，6：30左右回来。”（呵呵，不能并单处理）
“好的，肯定让你们满意。”（订单确认）
鸡蛋又不够了，打电话叫小贩送来。（紧急采购）
6：30，一切准备就绪，可烤鸭还没送来，急忙打电话询问：”我是李太太，怎么订的烤鸭还没送来。”（采购 委外单跟催）
“不好意思，送货的人已经走了，可能是堵车吧，马上就会到的。”
门铃响了，”李太太，这是您要的烤鸭。请在单上签一个字。”（验收、入库、转应付帐款）
6：45，女儿的电话：”妈妈，我想现在带几个朋友回家吃饭可以吗？”（呵呵，又是紧急订购意向，要求现货）
“不行呀，女儿，今天妈妈已经需要准备两桌饭了，时间实在是来不及，真的非常抱歉，下次早点说，一定给你们准备好。”（哈哈，这就是ERP的使用局限，要有稳定的外部环境，要有一个起码的提前期）
送走了所有客人，疲惫的妻子坐在沙发上对丈夫说：”亲爱的，现在咱们家请客的频率非常高，应该要买些厨房用品了（设备采购），最好能再雇个小保姆（连人力资源系统也有接口了）。”
丈夫：”家里你做主，需要什么你就去办吧。”（通过审核）
妻子：”还有，最近家里花销太大，用你的私房钱来补贴一下，好吗？”（哈哈哈哈，最后就是应收货款的催要）
现在还有人不理解ERP吗？记住，每一个合格的家庭主妇都是生产厂长的有力竞争者！！！！
]]>
,Visual C++好用（自己的破机器实在陪不起JBuilder，贪婪的家伙，以后一定要收拾她
）。什么JAVA_HOME,CLASSPATH，虚拟机等概念都是初次基础，旁边的人都很少用Java的
。感觉Java就是做Applet的。慢慢的知道了http://java.sun.com，开始知道Java博大精
深。让我不可思议的是JAVA 2,JDK,J2SE,J2EE,J2ME等新名词在自己的脑海里蔓延。慢慢
的自己知道了JCP组织是制定Java相关规范的发源地http://java.jcp.org ,于是订阅了
一份邮件列表。真是好东西啊，定期有Java的最新动向，所以Java的动态尽收眼里，建
议大家也去订阅一份。免费的。自己动手下载了Java(TM) 2 SDK和Java(TM) 2 SDK Doc
umentation后,不懂的就查Java(TM) 2 SDK Documentation,特别好用，也不需要什么手
册之类的，建议大家都要有一份。
搭起Java开发环境后，记得还是用UltraEdit编辑并编译的（在其中可以配好Java的编译
环境）。慢慢的改用JCreator了。不错，至少很多方面有改进。最开始卖了一套
最近做的项目中用到了FormView切换视图，其主要原理是：先新建一些Dialog对话框，然后给这些对话框绑定对应的View，注意：这些View要基于FormView。
一开始还好好的，利用切换视的代码进行的很顺利(网上的相关代码很多，我就不赘述了)，但是，后来新加了两个Dialog，不知我怎么弄的，奇怪的事发生了：先前添加了Dialog都能正常的切换，但是，一切换新添加的Dialog，每次运行到：
BOOL CFormView::Create(LPCTSTR /*lpszClassName*/, LPCTSTR /*lpszWindowName*/,
DWORD dwRequestedStyle, const RECT& rect, CWnd* pParentWnd, UINT nID,
CCreateContext* pContext)
{
ASSERT(pParentWnd != NULL);
ASSERT(m_lpszTemplateName != NULL);
m_pCreateContext = pContext; // save state for later OnCreate
#ifdef _DEBUG
// dialog template must exist and be invisible with WS_CHILD set <——请注意此处
if (!_AfxCheckDialogTemplate(m_lpszTemplateName, TRUE))
{
ASSERT(FALSE); // invalid dialog template name
PostNcDestroy(); // cleanup if Create fails too soon
return FALSE;
}
#endif //_DEBUG
中的ASSERT时就报错，而在Release版本下却不会报错。我检查了一下这两个新加的Dialog与先前的Dialog属性有哪些不同，原来是自己把后来加的Dialog的Visible属性设置成了TRUE了, 根据代码的要求是：对话框模板必须存在，属性要设置成不可见和子窗口风格。SystemMenu和TitleBar属性最好都设为False，改完以后，一切正常~~
注：还有一种方法就是在添加Dialog资源时，在Dialog列表上点右键->添加资源，选择Dialog->IDD_FORMVIEW,再点“新建”按钮，这样新建出来的Dialog属性就会自动配好了
1 跨浏览器布局的问题： 由于浏览器之间的微小差距，在布局复杂的页面时将会碰到麻烦
我现在的项目就要求firefox 和ie. 由于ie一些著名的bug，有时候不小心就踩到地雷。
2 日期控件
如何实现跨浏览器的日期控件，如何设定缺省值，如何实现大范围的日期直接定位？如何自适应多区域格式问题？
我也用过不少现成的东西，比如 http://www.mattkruse.com/javascript/calendarpopup/
但都有或多或少的问题
3、分辨率
如何支持常见分辨率，例如800*600 ，1024*768，1280*1024？表格和层如何自适应？
有些客户喜欢居左居中，有些内容超宽，有些超宽内容还在容器里，有些还要叠加，把这些混在一起麻烦就来了
4、防止SQL注入式攻击
参数使用占位符，这个算是基本解决了，只是有些担心数据库的效率。
5．防止脚本攻击。 有时候需要在页面允许部分html或javascript代码, 如显示多行文本。
html 转义我知道，但我要允许部分html代码起作用，比如我要让<br>起作用，其他不起作用，以实现多行文本
6、用户非授权页面访问
如何实现每个页面的安全验证，如何防止用户通过直接拷贝具体页面地址等方式，访问系统； 包括没有链接的某些页面和jsp 页面。 如何控制部分权限，最小控制单元是什么？
看上去很简单，但一深思问题就来了，
每个页面的安全验证：动态页面一般是 URL + Query String
URL数量有限，但Query String一般以id为参数，有许多，所以如以URL为基础验证，则有时候
粒度不够细，如加上Query String，则不能再以配置表为基础校验，因为Query String乘以
用户数量（或角色数量，将是一个天文数字），所以如何建立安全验证规则表又是一个头疼的
问题，每个系统的安全验证规则都不一样。
再深入，你会发现如果一个操作被分成几个步骤，此时，这几个步骤的页面必须是相同的权限
设置，否则用户操作到一半，告诉他没有权限，他会被气死的。
如果再细化粒度，页面某些元素能够被部分用户修改和看见，你的头开始疼了吗？
7、重复提交问题
功能操作完成后，鼠标右键点击所在页面，选择弹出菜单的刷新功能，容易出现重复提交问题。
功能操作完成后，通过浏览器的后退键进行重复操作，容易出现重复提交问题。
URL没有重定向，刷新页面出现重复提交问题。
某功能键反应时间延迟时，在短时间内重复点击该功能键，容易出现重复提交问题；
某些用户习惯双击按钮，某些用户错误地点了两次按钮，某些鼠标出现故障，导致单击变成双击，结果发生重复提交。
如果不加处理，这些请求都会被服务器处理，从而导致错误的结果。
struts的token确实能解决问题，但用户老是向我抱怨，为什么我不
能用浏览器的回退按钮重新提交，我在其他网站上从没有这个问题，你如何解释？
然后你还会发现部分操作是能够允许重复提交的。
8．如何锁定资源如记录：这是一个老大难问题了，为此还搞了不少东西出来。
用 关键词 隔离级别 脏 锁定 去搜搜，就会发现，要解决这个问题是有方法的，但代价
你愿意承担吗？开发代价，性能代价，可用性代价
9，如何防止浏览器记住数据，某些浏览器能够为每一个URL记住用户输入的数据，在某些情况下是危险的。比如我修改了某些数据，但由于某些原因我想刷新，此时数据已经被其他用户修改，但在浏览器里面你看到的是你修改的数据（你用刷新按钮也不能看到新数据）。如果你再次保存，你认为你没有修改数据，但数据已经被修改了。当页面是脚本动态生成的时候，这个问题更严重。
常发生在firefox等浏览器上。
10，如何防止或侦测客户修改浏览器设置，比如客户在打开页面之后关闭脚本功能。
有时候甚至不是用户禁止脚本，而是么某些软件和插件，病毒甚至企业文化影响到用户设置。
11，回退问题，对于工作流熟悉的人对这个问题很清楚，某个操作节点如何回到启动点，如何回到上一节点，如何避免硬编码？ 比如一个页面被两个操作流所共享，此时安全验证是个问题，回退也许要仔细考虑。
12，校验问题，如何同时实现客户端和服务器端校验，客户端调用服务器端的校验功能。
我已经在使用struts自带的apache commons validator，可是我不得不修改许多地方才能
用起来。比如我有些隐藏字段需要校验。但commons validator居然使用focus语句，导致出错。
这是小的bug，但更麻烦的是部分服务器端的校验没有办法在客户端实现。比如validwhen
又如，某些校验需要查询数据库，所以我想要的校验应该是能够被ajax 调用，这样
校验在客户端和服务器端完全一样，但这样客户端校验还有必要吗，我们原来用客户端校验
是看中他的校验响应快，不给服务器加负担。所以我又迷茫了。
13，如何防止数据伪造，如何防止客户使用特殊工具和技术伪造数据提交到服务器。
浏览器发送的数据都是遵循公开的标准，嗅探器等黑客工具可以随便地修改你的数据，
还有一些神奇的浏览器插件可以任意修改数据。就算ssl也只能保障中间传输，客户端无法控制。你还认为你的隐藏字段是安全的吗？你还认为你的select只有那几个选项吗？
14， 如何追踪定位错误，如何处理异常？
在一个运行的系统里，你如何知道哪个数据产生了这个错误？多个用户的日志绞缠在一起
如何组织？
15，如何在两个操作之间传递大量数据，尤其是非存储数据。
比如分页数据（按什么列排序的第几页，过滤条件）一般是不存储到数据库的，但在某些时候必须传递到下一个页面，session 也不是最终解决方案。
16， 带安全控制的断点续传的上载 和下载
甚至服务器端恐怕也要装点什么，这个可是许多企业的忌讳
17，分布式环境的特殊处理，
18，如何提高开发效率？
Macromedia被并购进入Adobe的尘埃已经落定，新的产品，新的策略将在2006年产生。我相信一定有不少人对Macromedia公司的历史颇感兴趣，在这里，我为大家贴出一个完整无误的Macromedia历史和发展进程，相信能够帮助不少人了解Macromedia这家公司是如何发展并推动Web进程的，让我们记住曾经的Web发展之路上，曾经有过一个出色的公司叫作Macromedia。
上述就是Macromedia公司的发展历程。
http://blog.csdn.net/JavaProgramers
Macromedia被并购进入Adobe的尘埃已经落定，新的产品，新的策略将在2006年产生。我相信一定有不少人对Macromedia公司的历史颇感兴趣，在这里，我为大家贴出一个完整无误的Macromedia历史和发展进程，相信能够帮助不少人了解Macromedia这家公司是如何发展并推动Web进程的，让我们记住曾经的Web发展之路上，曾经有过一个出色的公司叫作Macromedia。
上述就是Macromedia公司的发展历程。
]]>
]]>