基于.Net的Microsoft企业体系结构的分析

1、23/23基于.Net的Microsoft企业体系结构的分析学号： 姓名： 摘要本专题的目标读者是那些希望理解Microsoft在企业、应用程序和技术体系结构方面提供的方法的商业、软件和基础设施体系结构设计师及其程序设计人员。全专题阐述了体系结构设计中需要考虑的各个要素，讨论了Microsoft .Net在企业解决方案中的结构和模式实现，包括体系结构的术语、模式、概念和定义，以及体系结构的一系列视图。全文定位比较高，关于架构和模式不是比较了解的读者能够参阅本专题提供的参看书目，关于专题提到的一些模式实现是以.Net Framework为基础的，有相关语言功底的读者就能够看明白示例代码，对ASP

2、.NET不是专门熟悉的读者也能够参考MSDN联机关心。接下来就以下几个方面对Microsoft企业体系结构进行分析和讨论。企业体系结构ANSI/IEEE Std 1471-2000 中使用的体系结构定义是：“一个系统的差不多组织，表现为系统的组件、组件之间的相互关系、组件与环境之间的相互关系以及设计和进化的原理。”企业体系结构 (EA) 是关心组织理解自己的结构及其原理的概念工具。它提供了企业的结构图，是业务和技术变化的规划工具。一般来讲，企业体系结构表现为一整套相互关联的模型，这些模型描述了企业的结构和功能。企业体系结构要紧用于系统化的 IT 规划和架构，以及改进的决策过程。EA 中的各个模

3、型以逻辑方式来排列，能够使企业的详细信息处于不断增长中，包括： 目的和目标。 过程和组织。 系统和数据。 使用的技术。 关于Microsoft .Net Framework.NET Framework是一种新的计算平台，它简化了在高度分布式Internet环境中的应用程序开发。.NET Framework旨在实现下列目标：提供一个一致的面向对象的编程环境，而不管对象代码是在本地存储和执行，依旧在本地执行但在Internet上分布，或者是在远程执行的。提供一个将软件部署和版本操纵冲突最小化的代码执行环境。提供一个保证代码（包括由未知的或不完全受信任的第三方创建的代码）安全执行的代码执行环境。提供

4、一个可消除脚本环境或解释环境的性能问题的代码执行环境。使开发人员的经验在面对类型大不相同的应用程序（如基于Windows的应用程序和基于Web的应用程序）时保持一致。按照工业标准生成所有通信，以确保基于.NET Framework的代码可与任何其他代码集成。.NET Framework具有两个要紧组件：公共语言运行库和.NET Framework类库。公共语言运行库是.NET Framework的基础。您能够将运行库看作一个在执行时治理代码的代理，它提供核心服务（如内存治理、线程治理和远程处理），而且还强制实施严格的类型安全以及可确保安全性和可靠性的其他形式的代码准确性。事实上，代码治理的概念

5、是运行库的差不多原则。以运行库为目标的代码称为托管代码，而不以运行库为目标的代码称为非托管代码。.NET Framework的另一个要紧组件是类库，它是一个综合性的面向对象的可重用类型集合，您能够使用它开发多种应用程序，这些应用程序包括传统的命令行或图形用户界面(GUI)应用程序，也包括基于ASP.NET所提供的最新创新的应用程序（如Web窗体和XML Web services）。.NET Framework可由非托管组件承载，这些组件将公共语言运行库加载到它们的进程中并启动托管代码的执行，从而创建一个能够同时利用托管和非托管功能的软件环境。.NET Framework不但提供若干个运行库宿主

6、，而且还支持第三方运行库宿主的开发。例如，ASP.NET承载运行库以为托管代码提供可伸缩的服务器端环境。ASP.NET直接使用运行库以启用ASP.NET应用程序和XML Web services。下面的插图显示公共语言运行库和类库与应用程序之间以及与整个系统之间的关系。该插图还显示托管代码如何在更大的结构内运行。.NET Framework环境Microsoft 体系结构剖析企业体系结构中的信息能够从不同角度来审视，同时能够满足各种需要。体系结构的用户包括业务经理和分析员、系统体系结构设计师、工作流程和程序分析员、后勤专家、组织分析员等。这些人员要求有高级的概括信息、详细的数据和各种级不的中间

7、数据。这些需要通过创建概念视图、逻辑分析和物理实现来满足。在 Microsoft，我们发觉了四个重要同时常用的差不多审视角度。它们是业务、应用程序、信息和技术角度。业务角度“业务角度”描述了业务的运作方式。它包括广泛的商业策略，以及为了将组织从当前状态推进到构想的以后状态而做的打算。一般包括以下内容： 企业的高级目标。 整个企业或企业的重要部分实施的业务过程。 执行的业务功能。 要紧的组织结构。 各元素之间的相互关系。 应用程序角度“应用程序角度”定义了企业的资产应用，以应用程序为中心。一般包括下列内容： 有关支持业务过程的自动服务的描述。 有关组织中应用程序系统的相互作用和相互依靠（接口）的

8、描述。 依照企业目标开发新应用程序和改造旧应用程序，以及进展技术平台的打算。 应用程序角度可表示跨组织的服务、信息和功能，连接具有不同技能和技术的用户以便达到共同的业务目标。信息角度“信息角度”描述了组织在业务处理和运作过程中需要明白的信息。包括下列内容： 标准数据模型。 数据治理策略。 组织中信息产生和使用的模式讲明。 信息角度还描述了数据与工作流程关联的方式，包括整个组织中存在的结构化数据存储（如数据库）和非结构化数据存储（如文档、电子表格和演示文稿等）。技术角度“技术角度”对组织提供硬件和软件支持。它包括但不仅限于： 台式机和服务器硬件。 操作系统。 网络连接组件。 打印机。 调制解调器

9、。 技术角度对支持应用程序和信息角度所需的基础设施和系统组件提供了逻辑化的、独立于供应商的描述。它定义了一套完成业务所需的技术标准和服务。尽管有许多角度，然而从这些角度看到的只是一个企业体系结构。企业体系结构的价值不在于任何一个单独的角度，而在于各角度之间的相互关系、相互作用和相互依靠。尽管所有角度差不多上企业体系结构的关键元素，本文仍将集中讨论应用程序和技术角度。应用程序和技术体系结构软件系统的“功能”需求描述了软件提供的商业价值。关于天气预报服务来讲，功能需求能够描述为“将组织良好的信息 A 作为输入，服务将返回关于信息 A 所表示的时刻跨度和地理位置来讲正确的信息 B”。“应用程序体系结

10、构”是自动服务的体系结构，用于支持和实现如此的业务需求，包括该业务与其他应用程序之间的接口。它描述了应用程序的结构，以及该结构如何实现组织的功能需求。尽管在理想情况下，一个组织应该只有一个应用程序体系结构，但实际上，一个组织往往会有许多不同的应用程序体系结构。软件系统的“运作”需求定义了软件的可靠性、可治理性、性能、安全性和互操作性等。常见的例子是仅对授权用户开放的服务，这种服务要求在 99.999% 的时刻内都能正确实现它的功能。“技术体系结构”是支持组织以及实现运作（非功能）需求（尤其是组织的应用程序和信息体系结构）的硬件和软件基础设施的体系结构。它描述了所使用技术的结构和内部关系，以及这

11、些技术如何支持组织的运作需求。好的技术体系结构能够提供安全性、可用性和可靠性，还能够支持各种其他运作需求。然而假如应用程序的设计没有利用技术体系结构的优点的话，它的执行效果会专门差，或者会难以部署和运作。同样，即使一个优秀的应用程序体系结构是通过使用最新的技术、利用可重用软件组件来构建的，能专门好地满足业务过程的需求，它也可能不能专门好地反映实际的技术配置，例如：服务器没有通过正确配置来支持应用程序组件，网络硬件设置不能支持信息流等。这显示了应用程序体系结构和技术体系结构之间的相互关系：一个好的技术体系结构能够支持组织中关键的应用程序，而一个好的应用程序体系结构能够充分利用技术体系结构，在整个

12、运作需求中提供一致的性能。图 1：体系结构之间的关系概念、逻辑和物理视图所有体系结构角度都有多种体系结构视图，通常分为概念、逻辑和物理视图。“概念视图”是最抽象的视图，一般用系统用户（非 IT 专业用户）熟悉的术语来描述。概念视图用于定义应用程序的功能需求和商业用户视图，以便生成业务模型。“逻辑视图”显示了要紧的功能组件和它们在系统中的关系，而不涉及功能的实现细节。体系结构设计师创建的“应用程序模型”确实是业务模型的逻辑视图，因为它们决定了如何满足业务目标和需求。应用程序模型表示应用程序体系结构的逻辑视图。“物理视图”是最不抽象的，它们表示特定的实现组件和它们之间的关系。物理视图中的每个元素一

13、般都由设计和开发过程来实现，如软件和硬件系统。“实现视图”通常归组织的开发或运作部门治理，因此不在本文的讨论范围内。图 2：体系结构视图每一个体系结构级不均可能有（事实上通常都会有）多个视图，例如，每个应用程序通常都会有一个逻辑应用程序体系结构。这些视图由一组需求来驱动，反过来又会生成设计、开发、配置和运作过程及系统的输入。图 3：体系结构视图和模式本指南的其余部分将集中讨论应用程序和技术体系结构，以及利用 Web 服务技术构造基于服务的应用程序的概念和关键模式。尽管实现部分（包括设计、开发、配置、部署和治理）关于总体系统的生成十分重要，然而不在本文的讨论范围内。应用程序体系结构如前所述，应用

14、程序体系结构提供了三种视图：概念、逻辑和物理视图。体系结构设计师能够使用这些视图在组织中生成支持和满足其业务需求的模型。理想情况下，每个视图只有一个模型，但实际上每个视图可能有多个模型，这是由于组织和技术在不断成长和改变。然而，是否能得到这些模型的合理的最小集合是组织是否灵活、高效的关键。概念视图概念视图用于定义应用程序的业务需求和商业用户视图，以便生成“业务模型”。概念性建模技术（如用例分析、活动图解、过程设计和业务实体建模等）有助于构建关键业务过程及其使用的数据的描述，能够强调业务目标和需求，同时不包含实现技术。逻辑视图体系结构设计师创建的“应用程序模型”确实是业务模型的逻辑视图，因为它们

15、决定了如何满足业务目标和需求。应用程序模型表示应用程序体系结构的逻辑视图。体系结构设计师关怀的是应用程序的总体结构。他们决定数据治理和处理步骤的对应关系，依照逻辑信息和顺序设计模型部件之间的交互，并确定模型保留的数据类型和状态。物理视图应用程序模型的每个元素均要求映射到真正的技术元素。通过这种方法，应用程序模型以“实现模型”的方式得以实现。当程序员将详细的业务逻辑编写成代码时，常规的开发过程承担了部分实现任务，但大部分实现活动应归为框架完成。框架完成是一种开发技术，大多数分布式应用程序和数据治理的基础设施差不多上由复杂的框架处理的，而这些框架由自定义的应用程序逻辑和公布的控件结构进行了扩展。框

16、架完成使开发人员幸免了繁琐的工作（例如错综复杂的异步消息处理），使一般开发人员能够对项目作出更大的贡献。为组织规划和构建不同级不的模型是一项相当费时费劲的工作。而且，能否正确定义这些模型关于组织来讲也是至关重要的。体系结构模型的设计错误总是会导致严峻的设计问题或运作问题（例如可伸缩性和可靠性问题），严峻时甚至会导致项目无法完成以及阻碍业务。体系结构设计师正在查找框架和指南以关心他们创建和实现这些模型，并把由于使用错误模型而带来的风险降到最低。体系结构设计师能够使用两种体系结构指南和关心来加快建模速度和降低风险。第一是一组体系结构概念，它们提供： 一般的理解和通信。 关于如何以及何时使用某个概念

17、的指南，以及有关其属性的信息。 依照这些指南或实际的技术，何时能够实现和使用这些概念的指示。 第二是一组模式，基于大量成功的分布式应用程序的实际经验，由这些差不多概念组成。这些模式通过提供优秀的、通过测试的体系结构模型，封装了重要的最佳分布式应用程序设计实例，同时能使项目失败的风险降到最低。图 4：应用程序体系结构的视图这两组指南（概念和模式）在概念级（它们是企业模型概念和模式）、逻辑级（它们是应用程序概念和模式）和技术级都有对应的指南。提供这些概念和模式关于在组织中成功、快速和高效地实现系统以及采纳技术是十分关键的。应用程序体系结构：概念视图过去，应用程序的构建是通过集成本地系统服务（如文件

18、系统和设备驱动程序）来实现的。这种模型在访问丰富的开发资源以及精确操纵应用程序的行为方面提供了专门大的灵活性，但同时也容易出错、成本较高同时较为费时。现在，能够通过集成整个网络上现有的应用程序和服务，然后使用诸如业务实体、数据实体和其他方面在其上提供独特的附加价值，来构造复杂的分布式应用程序。这就使开发人员能够将注意力集中于提供独特的业务价值，从而减少进入市场的时刻，提高开发效率，同时最终开发出高质量的软件。多年来，这一直是一个强大的体系结构模型，但它产生了“应用程序通风口”或“信息孤岛”，而这在体系结构重用中会引起重大问题。现在，我们进入下一个计算时期。那个时期通过 Internet 和 W

19、eb 服务概念来实现，能够创建能够随时随地使用的强大的应用程序。它增加了应用程序的应用范围，同时能够不断交付软件。在这种情况下，软件即服务 - 一种通过通信网络来订购和使用的服务。.NET 通过结合 N 层计算的高效的紧耦合特点以及 Web 以信息为导向的松耦合概念来推进了这种理念。这种计算方式称为“XML Web Service”。它代表了下一代应用程序开发技术，同时是概念性应用程序体系结构的基础。Web 服务是应用程序逻辑的有效单元，它们提供了基于消息的、适合通过网络访问的接口。通常，服务既提供业务逻辑，也提供与要解决的问题相关的状态治理。在设计服务时，您的目标是有效地封装与现实世界中的过

20、程相关的逻辑和数据，对要包括在内的内容和要作为独立服务实现的内容作出明智的选择。状态处理由业务规则来治理。业务规则是相对稳定的算法（例如从商品清单汇总动身票的方法），一般是作为应用程序逻辑来实现的。服务由策略来治理。与业务规则相比，策略的稳定性较差，同时可能是区域性的或针对特定客户的。策略一般是通过在运行时查阅表格来驱动的。因此，服务的更完整的定义应该是：“服务是能在网络上运行的软件单元，它通过消息来实现逻辑、治理状态和通信，同时由策略来治理。” 应用程序模式模式是问题在环境中的解决方案。模式将从某个领域内收集的特定知识整理成文。应用程序模式是体系结构级的模式，它定义了体系结构设计在特定应用程

21、序环境中的最佳实例。模式有许多种分类法能够作为特定模式的定义和解释，但不在本文的讨论范围内。许多现有的体系结构模式都能够应用到基于 Web 服务的体系结构中，但在 Web 服务的新结构还带来了大量新的模式。技术体系结构与应用程序体系结构相似，技术体系结构也提供了三种视图：概念、逻辑和物理视图。体系结构设计师能够使用这些视图在组织中生成支持和满足其运作需求的模型。就象应用程序一样，应当只有一个技术体系结构，但实际上由于组织和技术在不断成长和改变，几乎总是存在多个技术体系结构。组织的一个关键需求是将这些完全不同的技术体系结构集成到一个完整的体系结构中，以便重用现有的应用程序，并使这些技术体系结构达

22、到合理的最小集合。如此一个公共的体系结构关于创建高效、灵活的组织是至关重要的。概念视图技术体系结构的概念视图用于将技术领域制定为结构和框架。它用于定义、命名和定位 IT 供应商和使用技术的组织都能理解的领域，确保在实现组织的运作或非功能性需求时所需的所有技术领域都得到定义并可供组织使用。逻辑视图技术体系结构的逻辑视图是要紧的功能元素，它们提供对企业级运作需求的支持，并提供相互之间的内部关系。企业技术元素（例如数据库、邮件系统、交易支持和可靠的消息传送）是在逻辑视图中提供的。在那个级不上提供的技术通常由企业软件供应商与服务器一起提供。物理视图技术体系结构的每个元素均需要映射到硬件和软件的实际技术元素上。通