——Microsoft .Net在企业解决方案中的架构和模式实概述

[摘要] 本专题的目标读者是那些希望理解Microsoft在企业、应用程序和技术体系结构方面提供的方法的商业、软件和基础设施体系结构设计师及其程序设计人员。全专题阐述了体系结构设计中需要考虑的各个要素，讨论了Microsoft .Net在企业解决方案中的结构和模式实现，全文定位比较高，对于架构和模式不是比较了解的读者可以参阅本专题提供的参看书目，对于专题提到的一些模式实现是以.Net Framework为基础的，有相关语言功底的读者就能够看懂示例代码，对于ASP.NET不是很熟悉的读者也可以参考MSDN联机帮助。 什么是架构(Architecture) 软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构。架构尚处在发展期，对于其定义，学术界尚未形成一个统一的意见，而不同角度的视点也会造成软件体系结构的不同理解，以下是一些主流的标准观点。 ANSI/IEEE 610.12-1990软件工程标准词汇对于体系结构定义是：“体系架构是以构件、构件之间的关系、构件与环境之间的关系为内容的某一系统的基本组织结构以及知道上述内容设计与演化的原理(principle)”。 Mary Shaw和David Garlan认为软件体系结构是软件设计过程中，超越计算中的算法设计和数据结构设计的一个层次。体系结构问题包括各个方面的组织和全局控制结构，通信协议、同步，数据存储，给设计元素分配特定功能，设计元素的组织，规模和性能，在各设计方案之间进行选择。Garlan & Shaw模型的基本思想是：软件体系结构={构件(component),连接件(connector)，约束(constrain)}．其中构件可以是一组代码，如程序的模块；也可以是一个独立的程序，如数据库服务器。连接件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构件之间的相互作用。约束一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。 关于架构的定义还有很多其他观点，比如Bass定义、Booch & Rumbaugh &Jacobson定义、Perry & Wolf模型[7]、Boehm模型等等，虽然各种定义关键架构的角度不同，研究对象也略有侧重，但其核心的内容都是软件系统的结构，其中以Garlan & Shaw模型为代表，强调了体系结构的基本要素是构件、连接件及其约束（或者连接语义），这些定义大部分是从构造的角度来甚至软件体系结构，而IEEE的定义不仅强调了系统的基本组成，同时强调了体系结构的环境即和外界的交互。 什么是模式(Pattern) 模式（Pattern）的概念最早由建筑大师Christopher Alexander于二十世纪七十年代提出，应用于建筑领域，八十年代中期由Ward Cunningham和Kent Beck将其思想引入到软件领域，1994年开始由Hillside Group(由Kent Beck等发起成立)和OOPSLA联合发起了国际PLoP（Pattern Language of Programming）会议，如今模式（Pattern）已成为软件工程领域内的一个热门话题，其在计算机领域的影响超过了在建筑界的影响。 Christopher Alexander将模式分为三个部分：首先是周境（Context，也可以称着上下文）,指模式在何种状况下发生作用；其二是动机（System of Forces）,意指问题或预期的目标；其三是解决方案（Solution）,指平衡各动机或解决所阐述问题的一个构造或配置（Configuration）。他提出，模式是表示周境、动机、解决方案三个方面关系的一个规则，每个模式描述了一个在某种周境下不断重复发生的问题，以及该问题解决方案的核心所在，模式即是一个事物（thing）又是一个过程(process)，不仅描述该事物本身，而且提出了通过怎样的过程来产生该事物。这一定义已被软件界广为接受。 软件模式的应用对软件开发产生了重大的作用，主要表现在： ? 软件模式是人们在长期的设计软件、管理组织软件开发等实践中大量经验的提炼和抽象，是复用软件设计方法、过程管理经验的有力工具。模式类似于拳击中的组合拳，它提供了一系列软件开发中的思维套路。如，通过模式的使用，有利于在复杂的系统中产生简洁、精巧的设计。 ? 软件模式为我们提供了一套简洁通用的设计、管理、组织方面的词汇，同时模式也为我们提供了一个描述抽象事物的规范标准，可大大促进软件开发过程中人与人之间的交流，而软件开发中的交流是至关重要的，“软件项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接收它的人”。 架构和模式的关系 因为架构(Architecture)和模式(Pattern)在当前的软件开发中经常地被提及，可是很多人容易混淆这两个术语，而对此，学术界也没有一个非常统一的定义。 架构和模式应该是一个属于相互涵盖的过程，但是总体来说Architecture更加关注的是所谓的High-Level Design,而模式关注的重点在于通过经验提取的“准则或指导方案”在设计中的应用，因此在不同层面考虑问题的时候就形成了不同问题域上的Pattern。相对于系统分析而言，架构是在提出解决问题的方案，而系统分析则是解决这些问题，这两者都会运用到模式，只是侧重的角度略有不同，架构方面倾向于架构模式，而系统分析更多的是采用设计模式和具体语言的实现模式。架构强调的是软件系统的结构及其各个元素之间的关系，而模式则是抽象各个层次上的关系，比如在架构设计时，设计模式是经过经验抽象过后的一些“准则”，而利用这些模式，有助于在架构设计中更好的分离系统元素(elements)和组织系统元素之间的关系。 模式是一个经验提取的“准则”，并且在一次一次的实践中得到验证，在不同的层次有不同的模式，小到语言实现(如Singleton)大到架构。在不同的层面上，模式提供不同层面的指导，比如架构设计方面，三层应用程序，分布式应用程序等等这些技术架构模式为架构设计提供了理论的参考，而在程序设计领域，设计模式则是提供了描述各个元素（在面向对象领域，更多的是指Class)之间的关系,GOF95的《设计模式---可复用面向对象软件的基础 》就是这个层次上的经典巨作，而在语言的实现过程中，也出现了同样的实现模式，如.NET 中的delegate（委托）的Observer（观察者）模式实现。 相对于系统分析或者设计模式来说，体系结构从更高的层面去考虑问题，所以关注的问题就体现在“不变”因素上，比如系统部署中，更加关心应用程序的分层分级设计，而在这个基础之上提出的部署方案，才是架构考虑的重点。体系结构关心应用程序模式，更加体现在通过技术去解决这些业务差异带来的影响，关心是否是分布式应用程序，关心系统分层是如何设计，也关心性能和安全，因此在这样的情况之下，会考虑集群，负载平衡，故障迁移等等一系列技术。 希望通过定义的方式来区分架构和模式是不太可能的，因为本来就是交互交叉和提供服务的，比如著名的MVC(Model-View-Controll)就是一个例子，在设计模式中是一个非常经典的模式，在架构中同样适用。对于熟悉架构设计的系统架构师而言，似乎可以用如下来解释架构和模式之间的关系：架构是Hight-Level Design,着眼于不同业务中共性的解决方案，而模式是General Principle(通用原理)。 模式用来指导架构设计，同时架构设计选择模式 关于Microsoft .Net Framework .NET Framework是一种新的计算平台，它简化了在高度分布式Internet环境中的应用程序开发。.NET Framework旨在实现下列目标： 　 ●提供一个一致的面向对象的编程环境，而无论对象代码是在本地存储和执行，还是在本地执行但在Internet上分布，或者是在远程执行的。 　●提供一个将软件部署和版本控制冲突最小化的代码执行环境。 　●提供一个保证代码（包括由未知的或不完全受信任的第三方创建的代码）安全执行的代码执行环境。 　●提供一个可消除脚本环境或解释环境的性能问题的代码执行环境。 　●使开发人员的经验在面对类型大不相同的应用程序（如基于Windows的应用程序和基于Web的应用程序）时保持一致。 　●按照工业标准生成所有通信，以确保基于.NET Framework的代码可与任何其他代码集成。 .NET Framework具有两个主要组件：公共语言运行库和.NET Framework类库。公共语言运行库是.NET Framework的基础。您可以将运行库看作一个在执行时管理代码的代理，它提供核心服务（如内存管理、线程管理和远程处理），而且还强制实施严格的类型安全以及可确保安全性和可靠性的其他形式的代码准确性。事实上，代码管理的概念是运行库的基本原则。以运行库为目标的代码称为托管代码，而不以运行库为目标的代码称为非托管代码。.NET Framework的另一个主要组件是类库，它是一个综合性的面向对象的可重用类型集合，您可以使用它开发多种应用程序，这些应用程序包括传统的命令行或图形用户界面(GUI)应用程序，也包括基于ASP.NET所提供的最新创新的应用程序（如Web窗体和XML Web services）。 .NET Framework可由非托管组件承载，这些组件将公共语言运行库加载到它们的进程中并启动托管代码的执行，从而创建一个可以同时利用托管和非托管功能的软件环境。.NET Framework不但提供若干个运行库宿主，而且还支持第三方运行库宿主的开发。 例如，ASP.NET承载运行库以为托管代码提供可伸缩的服务器端环境。ASP.NET直接使用运行库以启用ASP.NET应用程序和XML Web services。 下面的插图显示公共语言运行库和类库与应用程序之间以及与整个系统之间的关系。该插图还显示托管代码如何在更大的结构内运行。 .NET Framework环境 Microsoft企业架构(体系结构)概述 企业体系结构(EA)是帮助组织理解自己的结构及其原理的概念工具。它提供了企业的结构图，是业务和技术变化的规划工具。一般来说，企业体系结构表现为一整套相互关联的模型，这些模型描述了企业的结构和功能。企业体系结构主要用于系统化的IT规划和架构，以及改进的决策过程。EA中的各个模型以逻辑方式来排列，可以使企业的详细信息处于不断增长中，包括： 　 ●目的和目标； 　 ●过程和组织； 　 ●系统和数据； 　 ●使用的技术； 企业体系结构中的信息可以从不同角度来审视，并且可以满足各种需要。体系结构的用户包括业务经理和分析员、系统体系结构设计师、工作流程和程序分析员、后勤专家、组织分析员等。这些人员要求有高级的概括信息、详细的数据和各种级别的中间数据。这些需要通过创建概念视图、逻辑分析和物理实现来满足。在Microsoft，我们发现了四个重要并且常用的基本审视角度。它们是业务、应用程序、信息和技术角度。 业务角度 “业务角度”描述了业务的运作方式。它包括广泛的商业策略，以及为了将组织从当前状态推进到构想的未来状态而做的计划。一般包括以下内容： 1． 企业的高级目标； 2． 整个企业或企业的重要部分实施的业务过程； 3． 执行的业务功能； 4． 主要的组织结构； 5． 各元素之间的相互关系； 应用程序角度 “应用程序角度”定义了企业的资产应用，以应用程序为中心。一般包括下列内容： 1. 有关支持业务过程的自动服务的描述； 2. 有关组织中应用程序系统的相互作用和相互依赖（接口）的描述； 3. 根据企业目标开发新应用程序和改造旧应用程序，以及发展技术平台的计划； 应用程序角度可表示跨组织的服务、信息和功能，连接具有不同技能和技术的用户以便达到共同的业务目标。 信息角度 “信息角度”描述了组织在业务处理和运作过程中需要知道的信息。包括下列内容： 1. 标准数据模型； 2. 数据管理策略； 3. 组织中信息产生和使用的模式说明； 信息角度还描述了数据与工作流程关联的方式，包括整个组织中存在的结构化数据存储（如数据库）和非结构化数据存储（如文档、电子表格和演示文稿等）。 技术角度 “技术角度”对组织提供硬件和软件支持。它包括但不仅限于： 1. 台式机和服务器硬件； 2. 操作系统； 3. 网络连接组件； 4. 打印机； 5. 调制解调器； 技术角度对支持应用程序和信息角度所需的基础设施和系统组件提供了逻辑化的、独立于供应商的描述。它定义了一套完成业务所需的技术标准和服务。 尽管有许多角度，但是从这些角度看到的只是一个企业体系结构。企业体系结构的价值不在于任何一个单独的角度，而在于各角度之间的相互关系、相互作用和相互依赖。尽管所有角度都是企业体系结构的关键元素，而本专题将集中讨论应用程序和技术角度。 “应用程序体系结构”是自动服务的体系结构，用于支持和实现这样的业务需求，包括该业务与其他应用程序之间的接口。它描述了应用程序的结构，以及该结构如何实现组织的功能需求。虽然在理想情况下，一个组织应该只有一个应用程序体系结构，但实际上，一个组织往往会有许多不同的应用程序体系结构。 软件系统的“运作”需求定义了软件的可靠性、可管理性、性能、安全性和互操作性等。常见的例子是仅对授权用户开放的服务，这种服务要求在99.999%的时间内都能正确实现它的功能。 “技术体系结构”是支持组织以及实现运作（非功能）需求（尤其是组织的应用程序和信息体系结构）的硬件和软件基础设施的体系结构。它描述了所使用技术的结构和内部关系，以及这些技术如何支持组织的运作需求。 好的技术体系结构可以提供安全性、可用性和可靠性，还可以支持各种其他运作需求。但是如果应用程序的设计没有利用技术体系结构的优点的话，它的执行效果会很差，或者会难以部署和运作。同样，即使一个优秀的应用程序体系结构是通过使用最新的技术、利用可重用软件组件来构建的，能很好地满足业务过程的需求，它也可能不能很好地反映实际的技术配置，例如：服务器没有经过正确配置来支持应用程序组件，网络硬件设置不能支持信息流等。这显示了应用程序体系结构和技术体系结构之间的相互关系：一个好的技术体系结构能够支持组织中关键的应用程序，而一个好的应用程序体系结构能够充分利用技术体系结构，在整个运作需求中提供一致的性能。 图：体系结构之间的关系 所有体系结构角度都有多种体系结构视图，通常分为概念、逻辑和物理视图。“概念视图”是最抽象的视图，一般用系统用户（非IT专业用户）熟悉的术语来描述。概念视图用于定义应用程序的功能需求和商业用户视图，以便生成业务模型。“逻辑视图”显示了主要的功能组件和它们在系统中的关系，而不涉及功能的实现细节。体系结构设计师创建的“应用程序模型”就是业务模型的逻辑视图，因为它们决定了如何满足业务目标和需求。应用程序模型表示应用程序体系结构的逻辑视图。“物理视图”是最不抽象的，它们表示特定的实现组件和它们之间的关系。物理视图中的每个元素一般都由设计和开发过程来实现，如软件和硬件系统。 图：体系结构视图 每一个体系结构级别均可能有（事实上通常都会有）多个视图，例如，每个应用程序通常都会有一个逻辑应用程序体系结构。这些视图由一组需求来驱动，反过来又会生成设计、开发、配置和运作过程及系统的输入。 图：体系结构视图和模式 以.NET为代表的Microsoft产品线向我们展示了“架构为基础，模式为指导”的企业解决方案设计理念，秉承微软产品一贯以来的简单易用以外，同时我们将看到使用.NET构建企业应用平台上使用.NET的优势。毫不夸张地说，.NET不是第一个体现架构和模式的软件应用平台，确是目前为止最后的实现了架构和模式的平台，在随后的文章介绍中，你将会发现，架构设计和模式应用会是如此简单。