DOM组件编程.doc

第9章 组件编程组件（component）技术是各种软件重用方法中最重要的一种方法，也是分布式计算和Web服务的基础。网络应用中的软件组件，又被称为中间件（middleware）。组件技术的应用现在已经十分广泛，从Windows编程中使用的各种控件和公用对话框，到ActiveX控件和DirectX的应用；从微软公司的COM，到Sun公司的JavaBean。其中最流行的组件技术的应用是客户端的COM（微软/VB、VC）、服务器端的EJB（Sun/Java）、以及可用于客户端和服务器端的.NET（微软/C#、VB、C+/CLI）。在网络及其应用都很发达的今天，对组件服务的需求十分强烈，因此组件技术近年来得到了飞速的发展和广泛的应用。9.1 概述面向过程的编程重用函数、面向对象的编程重用类、范型编程重用的是算法的源代码，而组件编程则重用特定功能完整的程序模块。每个组件会提供一些标准且简单的应用接口，允许使用者设置和调整参数和属性。用户可以将不同来源的多个组件有机地结合在一起，快速构成一个符合实际需要（而且价格相对低廉）的复杂（大型）应用程序。组件区别于一般软件的主要特点，是其重用性（公用/通用）、可定制性（设置参数和属性）、自包容性（模块相对独立，功能相对完整）和互操作性（多个组件可协同工作）。可以简单方便地利用可视化工具来实现组件的集成，也是组件技术一个重要优点。普通的面向过程和面向对象的编程，一般会生成两种类型的软件针对特定应用的可执行程序和面向通用编程的API库。前者包含你需要的各种特殊的具体功能，但必须从头到尾自己来创建，其中很多是低层次的重复劳动；后者虽然通用，但是却不能满足你的具体应用的特殊需要。组件技术提供了第三种途径，它将库的可重用性与特定程序的可定制性结合起来，让用户可以用可重用的组件来定制自己特定的应用程序。所以组件在某些方面类似于“可执行程序”，在另一些方面又类似于“库”。采用MFC编程，可选的项目类型为：MFC应用程序、MFC DLL和MFC ActiveX控件，刚好对应于上面所讨论的可执行程序、库和组件这三类软件。使用组件来构造应用程序的工作（组件集成）非常简单，不需要专业程序员，普通用户就可以很快做到。但是设计和创建组件（组件编写）的工作却十分复杂，只有高水平的程序员才有可能完成。这也是为什么VB和Delphi会如此流行的真正理由（组件功能强大，编写又非常简单），同样也是ATL和EJB等（创建组件）编程少有人问津的原因。1组件模型软件组件的核心技术是组件模型，它定义了组件的体系结构、及如何操作此结构并与外部交互。组件模型的两个基本要素是组件和容器。模型的组件部分，提供构造组件的模版，是各种组件创建和使用的基础；模型的容器部分，定义了将多个组件结合成有用结构的方法，为组件的结合和交互提供环境支持。一个功能完整的组件模型应该提供如下6种主要的服务：l 自检（introspection内省）向外部显示本组件功能和信息的机制，是组件模型的最关键方面；l 事件处理使组件产生响应某个内部状态变化的事件通知的机制，相关的组件之间是通过事件的消息传递来协同工作的；l 持久性（persistence）从一个固定位置（如磁盘）存储和检索组件的方法；l 设计规划支持组件的物理设计规划（可视化界面）；l 应用程序构造器支持支持组件的GUI交互创建工具（如VB）；l 分布式计算支持需要考虑网络定位、远程调用、传输错误或失败、以及通信速率的限制等方面的问题。2中间件中间件（middleware）是一种软件，它能使处于应用层的各种应用组件之间实现异构网络平台上的协同工作。它是组件技术的最重要方面，也是分布式计算和Web服务等网络应用技术的主要组成部分。可协同工作应用软件中间件网络协议操作系统硬件平台应用软件DBMS中间件网络协议操作系统硬件平台中间件的定义中间件一般由执行环境和应用开发工具两部分组成，可以分成事务处理中间件、消息中间件和分布式中间件等三种类型。传统网络应用采用的是C/S（客户/服务器）双层结构模式：客户程序操作系统数据库的C/S通信规程服务程序DBMS操作系统客户端服务器端C/S双层结构应用表示层业务处理逻辑数据库的C/S通信规程应用软件数据库管理系统客户端服务器端双层结构的客户/服务器关系这种模式，开发简捷，但效率低下，而且不适应于Web和组件应用的需要。中间件一般采用三层结构：请求应答客户程序中间件操作系统服务程序中间件DBMS操作系统客户端服务器端C/S三层结构第一层客户端进程中间层业务逻辑服务企业信息层服务器端进程数据库三层结构的客户/服务器关系9.2 组件标准组件应用的基础是标准，没有统一的接口描述、没有规范的组件通信、没有标准的对象请求和远程调用，就没有组件应用的可能。目前的主要标准有CORBA（国际通用）、EJB（Sun的Java）、COM和CLR（Microsoft的Windows和.NET）。1CORBA最早而且最权威的组件标准是CORBA (Common Object Request Broker Architecture公共对象请求代理体系结构)，它由OMG所制定的，1991年10月推出1.0版、1996年8月推出2.0、2002年7月推出3.0，目前的最新标准为2006年4月1日推出的CORBA 4.0版。OMG（Object Management Group对象管理组，http:/www.omg.org/）是一个开放型非赢利组织，负责制定和维护协同企业应用的计算机工业规范。OMG是1989年4月由3COM、Apple、美国航空、佳能、DG、HP、IBM、Philips、Unisys和Sun等11个公司所创建的，后来发展到800多个公司、大学和国际组织，包括Adobe、AT&T、Borland、CA、加州大学、富士通、HP、IBM、MIT、NEC、Oracle、Sun、东芝、东京大学、清华大学、W3C等。（注意，Intel和Microsoft并没有参加）。OMG制定的其他标准还有：UML（Unified Modeling Language统一建模语言）和IDL（Interface Definition Language接口定义语言）等。CORBA是一种独立于语言的分布式对象模型，其核心是ORB（Object Request Broker对象请求代理），对象的接口用IDL描述，在各个对象之间采用IIOP（Internet Inter-ORB Protocal因特网ORB交互协议）进行通信。OMG的OMA（Object Management Architecture对象管理体系结构）从客户传递到对象实现的请求使用ORB-to-ORB通信的协同工作的能力CORBA的C/S模型2EJBSun公司于1997年在Java的JDK 1.1中引入了JavaBean组件技术，后来又于2000年随J2EE（Java 2 Platform, Enterprise Edition，Java 2平台企业版，2005年6月后更名为Java EE）引入服务器端的组件技术EJB（Enterprise JavaBeans，企业爪哇豆）和网页编程工具JSP（JavaServer Page, Java，服务器网页）。至此，Java成为了一种功能完备的分布式计算环境。这对（一心想进入利润丰厚的服务器端网络应用软件领域的）微软公司，造成了极大的威胁。1998年3月24日Sun公司在第3届Java开发者会议（JavaOne 1998）上发布了EJB 1.0版、1999年12月17日推出1.1版、2001年8月22日推出2.0版、2003年11月24日又推出2.1版，当前最新版是2006年5月2日推出的3.0版。Java EE 6体系结构图Applet容器(Applet)Web容器（JSP、Servlet）EJB容器（EJB）应用客户容器（应用客户）JAX-PRCJAX-WSJAXRJMSWeb BeansWeb服务WS元数据管理Java持久性JAX-RSJASPICJACC连接器JTAJava邮件JSFJSTLSAAJJava SE数据库Java EE 6平台Java SE 6平台l J2EE（1.2）引入的新概念与技术：n EJB（Enterprise Java Beans，企业爪哇豆）n JSP（Java Server Pages，爪哇服务器页面）n Servlet（小服务器程序）n Container（容器）l J2EE 1.2（为首个J2EE版本）原有的API：n JDBC（Java Database Connectivity，爪哇数据库联接）从J2EE 1.4起被放进J2SEn JNDI（Java Naming and Directory Interface，命名与目录接口）从J2EE 1.3起被放进J2SEn JMS（Java Message Service，爪哇消息服务）n JavaMail（爪哇邮件）n JAF（Java Beans Activation Framework，爪哇豆激活框架）用于JavaMail，从Java EE 6起被放进Java SEn JavaIDL（Java IDL, 爪哇IDL），其中：IDL = Interface Description Language（接口描述语言）从J2EE 1.3起被放进J2SE？l J2EE 1.3新引进的API：n JAXP（Java API for XML Processing，爪哇XML解析API）从J2EE 1.4起被放进J2SEn JTA（Java Transaction API，爪哇事务API）n JAAS（Java Authentication and Authorization Service，爪哇验证和授权服务）从J2EE 1.4起被放进J2SEn Connectors（连接器）l J2EE 1.4新引进的API：n SAAJ（SOAP with Attachments API for Java，用于爪哇的带有附件的SOAP），其中：SOAP = Simple Object Access Protocol（简单对象访问协议）n JAX-RPC（Java API for XML-Based Remote Procedure Calls，基于XML的远程过程调用之爪哇API）n JAXR（Java API for XML Registries，XML注册的爪哇API）n JACC（Java Authorization service provider Contract for Containers，爪哇授权服务提供者容器合同）n Web Services（Web服务）n JMX（Java Management Extensions，爪哇管理扩展）用于Management，从Java EE 5起被放进Java SEn Management（管理）l Java EE 5新引进的API：n JAX-WS（Java API for XML Web Services，XML Web服务的爪哇API）n WS Metadata（Web Services Metadata，Web服务元数据）n Java Persistence（爪哇持久性）n JSF（Java Server Faces，爪哇服务器外观）n JSTL（Java server pages Standard Tag Library，爪哇服务器页面标准标签库）n StAX（Streaming APIs for XML Parsers，XML解析器的流API）从Java EE 6起被放进Java SEl Java EE 6新引进的API：n JAX-RS（Java API for RESTful Web Services，完全REST的Web服务之爪哇API），其中：REST = Representational State Transfer（代表状态转移）n JASPIC（Java Authentication Service Provider Interface for Containers，爪哇验证服务提供者容器接口）n Web Beans（Web豆）因特网表单显示Web服务Web服务器Web应用业务逻辑EJB容器EJBData数据库客户端界面基于Web应用的J2EE应用编程模型简单的EJB体系结构JavaBean是一种可复用的平台独立的软件组件，开发者可以在软件构造器工具（如网页构造器、可视化应用程序构造器、GUI设计器、服务器应用程序构造器等）中对其直接进行可视化操作。而EJB则是用于开发企业级的服务器端应用程序的JavaBean组件，可以分为会话bean（维护会话）、实体bean（处理事务）和消息bean（提供异步消息机制）等三种类型。JavaBean的接口采用标准的IDL定义，在各个EJB之间采用RMI（Remote Method Invocation远程方法调用）进行通信，而且J2EE还为EJB与CORBA的集成提供了适配器和RMI的扩展RMI-IIOP，可以用于EJB与CORBA对象之间进行通信。而对数据库的访问，采用的则是JDBC（Java DataBase Connection，Java数据库连接）。JavaBean应用程序JavaBean组件JavaBean组件JavaBean组件JDBC数据库服务器CORBA服务器Java服务器数据库协议RMI-IIOPRMIJavaBean的三种远程对象交互机制EJB与CORBA的比较与结合EJB的体系结构3COM / .NETCOM（Component Object Model，组件对象模型）是微软公司于1993年提出的一种组件技术，是软件对象组件之间相互通信的一种方式和规范，它是一种平台无关、语言中立、位置透明、支持网络的中间件技术。COM是OLE（Object Linking and Embedding，对象链接和嵌入）的发展（而OLE又是DLL Dynamic Link Libraries，动态链接库的发展），DCOM（Distributed COM分布式COM，1996年）和COM+（DCOM+管理，1999年）则是COM的发展。ActiveX控件是COM的具体应用（如VBX和DirectX都是基于ActiveX的）。ATL（Active Template Library活动模板库）是开发COM的主要工具，也可以用MFC来直接开发COM，但是非常复杂。作为组件技术的进一步发展，微软公司又于2002年推出了.NET框架，其中的核心技术就是用来代替COM组件功能的CLR（Common Language Runtime公共语言运行库），可采用各种编程语言，利用托管代码来访问（例如C#、VB、MC+），使用的是.NET的框架类库FCL（Framework Class Library）。微软公司的各种组件技术之间的关系与发展可以参见下图：ATL / MFC FCL / C#、VB、MC+、C+/CLI开发 开发1981 1991 1993 1996 1999 2002DLLOLECOMDCOMCOM+.NET应用 应用 应用VBXActiveXDirectX ASP.NET/ADO.NET/ Web服务替换 应用 分布式计算本地 网络 Web微软组件技术之间的关系与发展示意图下面分别对这几种组件技术加以简单的介绍：1）DLLDLL（Dynamic Link Libraries，动态链接库）还不能算组件技术，但它是软件重用的鼻祖。普通的静态链接库，虽然也能做到代码共享，但是只能是在编译链接阶段。在运行时，程序调用的是已经链接到自己程序内的库函数。如果每个程序都包含所有用到的公共库函数，则这是很大的浪费，即增加了链接器的负担，也增大了可执行程序的大小，还加大了内存的消耗。而DLL采用动态链接，对公用的库函数，系统只有一个拷贝（位于系统目录的*.DLL文件），而且只有在应用程序真正调用时，才加载到内存。在内存中的库函数，也只有一个拷贝，可供所有运行的程序调用。当再也没有程序需要调用它时，系统会自动将其卸载，并释放其所占用的内存空间。运行时调用运行时调用编译器编译时链接应用程序(*.exe)#include <xx.h>fun();fun() 静态库(*.lib)fun() 操作系统运行时链接应用程序(*.exe)#include <xx.h>fun();fun() 动态链接库(*.dll)fun() 使用静态库函数使用动态链接库静态库函数与动态链接库的区别由于应用程序是通过系统来调用动态链接库的，因此每个DLL都有一个类似于main的入口函数。在DLL中，供外部应用程序调用的库函数叫做导出函数，而只是被DLL内部调用的库函数则叫做内部函数。导出函数在客户端叫做导入函数。关于DLL的进一步信息，可以参考教材的第14章。2）OLEOLE（Object Linking and Embedding，对象链接和嵌入）是微软公司于1991年推出的一种简单的组件技术，它允许Windows中的程序相互之间进行合作一个（客户）程序调用另一个（服务器）程序，以完成特定的功能。而且客户/主程序的界面不变，就似将服务器程序嵌入到客户程序中一样。DLL产生DDE消息DLL产生DDE消息客户应用服务器应用客户DLL服务器DLL调用DLL回调应用调用DLL回调应用OLE的基本库结构和函数调用实际上，OLE是一套可扩充的协议（OLECLI.DLL和OLESVR.DLL），能使客户和服务器应用程序通过一组DLL彼此进行通信。1993年随VC1.0又推出OLE2.0，对1.0版进行了若干改进，使客户和服务器的结合更加紧密，还允许服务器继承客户的主菜单，使得用户感觉不到在不同应用之间的切换，并且提供了C+的开发接口（1.0版只支持C语言开发）。OLE使用DDE（Dynamic Data Exchange动态数据交换）作为客户和服务器应用程序间通信的传输机制。DDE派生类派生类OLE客户基类OLE服务器基类调用回调调用回调客户应用服务器应用OLECLI.DLLOLESVR.DLLSHELL.DLLREG.DATOLE类与OLE DLL之间的关系3）COMOLE 1.0实际上只是一种复合文档，而OLE 2.0已经具有标准组件的特性了，显然它是受了CORBA的影响。所以从OLE 1.0到OLE 2.0，是微软公司在组件技术上的一次飞跃。这时，OLE的名称就有一些名不副实了，因此，在增加了一些功能和规范之后，微软公司于1993年在OLE 2.0的基础上又推出了COM，用来替代原有的OLE。这样一来，OLE就不再是一种独立的组件技术，而只是COM技术在链接和嵌入方面的一个具体应用。而1996年3月推出的ActiveX控件，也只是COM的一个具体应用，它是用来替代原有的VBX控件的。COM及其应用COM与OLE之间的关系COM（Component Object Model，组件对象模型）的核心是一组组件对象间交互的规范，它定义了组件对象如何与其使用者通过二进制接口标准进行交互，COM的接口是组件的球类型纽带。除了规范之外，COM还是一个称为COM库的实现，它包括若干API函数，用于COM程序的创建。COM还提供定位服务的实现，可以根据系统注册表，从一个类标识（CLSID）来确定组件的位置。COM采用自己的IDL来描述组件的接口（interface），支持多接口一解决版本兼容问题。COM为所有组件定义了一个共同的父接口IUnknown。GUID 是一个 128 位整数（16 字节），COM将其用于计算机和网络的唯一标识符。除了基本规范和系统实现之外，COM的构成还包括永久存储、绰号（moniker智能命名/标记）和统一数据转移（UDT = Uniform Data Transfer）三个核心的操作系统部件。统一数据转移永久存储绰号COM底层支持和组件对象COM基础架构在COM模型中，所有将CLSID传递给COM并获得实例化的对象，都被称为COM客户（程序）。最简单的实例化方式，是调用COM函数CoCreateInstance。也可以通过调用CoGetClassObject函数来为CLSID获得类工厂（Class Factory）对象的接口指针。COM库返回接口A的指针COM定位，并实例化服务器CLSID_XC:Svr1.DLLCLSID_YC:Svr2.EXE客户调用CoCreateInstance(CLSID_Y, IID_A)客户应用程序服务器对象ACOM库 客户可调用接口A的方法COM客户与COM组件对象之间的交互与COM客户程序相比，COM服务器在于实现类工厂和其生产的对象类，并将工厂提供给COM使用。COM服务器结构构造对象创建对象返回新接口指针给客户客户应用程序服务器对象类工厂COM客户通过类工厂创建对象4）DCOMDCOM（Distributed COM，分布式COM）是COM的网络化。COM具有进程透明性，组件对象和客户代码不必考虑调用传递的细节，只须按照普通函数方式进行调用即可。而DCOM将COM的进程透明性扩展为位置透明性，形成分布式的组件对象模型。COM组件有两种进程模型：进程内组件和进程外组件。由于本地进程外组件与客户运行在不同的进程空间，所以客户程序对组件对象的调用，并不是直接进行的，而是用到了操作系统支持的一些跨进程通信方法，主要有OSF（Open Software Foundation开放软件基金会，现在改为Open Group开放小组http:/www.opengroup.org/）开发的DCE RPC（Distributed Computing Environment 分布式计算环境Remote Procedure Call 远程过程调用）和LPC（Local Procedure Calls本地过程调用）。客户组件客户与进程内组件通信客户组件安全提供器DCE RPCLPC对象代理安全提供器DCE RPCLPC存根客户端服务器端客户与本地进程外组件通信COM的客户进程与组件的通信为了将组件服务延伸到网络，DCOM建立在自己的网络协议上，并通过SCM（Service Control Manager，服务控制管理器）来创建远程对象。客户组件安全提供器DCE RPC协议栈对象代理安全提供器DCE RPC协议栈存根客户端服务器端DCOM网络协议SCMSCMOLE32DCOM组件的网络环境工作模型从COM到DCOMCOM的“ORB”结构5）COM+COM+是COM-based services and technologies（基于COM的服务与技术）的简称，+表示将COM组件技术和MTS（Microsoft Transaction Server，微软事务服务器）应用程序主机技术结合在一起。它是一个面向应用的高级COM运行环境，它在COM基础上实现了许多面向企业应用的分布式应用程序所需要的服务。COM+是1999年随Windows 2000推出的。COM+是Windows DNA（Distributed interNet Application Architecture分布式网间应用程序体系结构）框架的重要组成部分。DNA为Windows环境下开发分布式应用程序提供了工具和框架，而COM+则是DNA的中间件技术和粘结剂。COM+会自动处理不同的编程任务，诸如资源集池、分离应用程序、事件发布、预定和分布式事务。DNA核心工具HTML/XML/脚本编写组件创建快速应用程序开发组开发用户界面与导航VBDHTMLXML脚本C+业务进程综合存储文件系统数据库电子邮件其他存储Web服务器事务消息队列逻辑规则分布式操作环境互操作性位置透明性安全性网络互连低级服务COM+队列组件负载均衡内存数据库事务服务COMWindows DNA服务框架Windows DNA 一种从部门到因特网的伸缩性综合平台IISASPMTSMSMQSQL服务器异步IOVC+VB组件VisualInterDevHTTPIEADODNA与Visual Studio其中：IE = Internet Explorer因特网探索者（微软的网页浏览器）HTTP = Hypertext Transfer Protocol超文本传输协议（W3C制定的万维网的数据传输协议）IIS = Internet Information Services因特网信息服务（微软的因特网服务器平台组件）ASP = Active Server Page动态服务器网页（微软的Web服务器端的动态网页脚本语言）Visual InterDev = VS中针对因特网应用程序的专用开发工具（使用ASP）MTS = Microsoft Transaction Server微软事务服务器（协调组件和数据库、负责管理资源的缓存和共享、实现可伸缩性，通常被用作组件的容器，可以视为组件管理器或代理程序）MSMQ = Microsoft Message Queue Server微软信息队列服务器（负责复杂的、涉及发送和接收、同步和异步之信息获取的协调工作）ADO = ActiveX Data Objects，ActiveX数据对象（微软的关系数据库访问组件）SQL = Structured Query Language结构化查询语言（关系数据库的通用查询语言，国际标准）简单的COM+应用使用IIS/ASP的Web应用通过MSMQ协作组件激活6）.NET / CLR.NET的核心是CLR，它可以视为是COM技术的继承和发展，它解决了COM组件模型中存在的主要问题。Web服务框架和库（ASP.NET、ADO.NET、Windows窗体）交互标准（SOAP、WSDL）开发工具（Visual Studio）组件模型对象模型和CLSCLR.NET框架的分层结构（1）COM的缺陷COM（含DCOM和COM+）组件技术存在许多问题，其中有一些是关键的，有的甚至是致命的。组件技术主要强调在独立开发和部署的程序之间的一套约定（contract），COM则是微软公司将这些约定规范化的首次尝试。COM既能作为设计范例（paradigm）（它将组件的约定，表示为类型定义），也可用作支持平台技术。作为前者，COM编程模型相当成功；但是后者却存在诸多问题，正是由于缺乏稳固的平台技术，COM时代面临着终结。组件间的约定，纯粹是通过用户与组件之间的语义保证和假设的形式来表示的。但是，仍需要定义某种形式来表示语义，专业的做法是采用可编程的类型定义，以及描述这些类型定义的人工可读文档。COM用类型的形式表示组件约定，但是该约定存在如下两个关键问题，使得其对语义的表示并不是最优的。1约定的描述：COM没有定义约定的交换格式，即COM规范所约定的类型定义，必须通过完全是COM之外的某种技术来进行交互。微软定义和支持的COM交换格式有两个IDL（Interface Definition Language接口语言定义）和TLB（Type LiBrary类型库），但是这两种格式并不是同构的，其中也没有哪种格式是权威的或标准的。另外，COM的描述约定方式，至少还存在两个其他的关键问题： COM缺乏对组件依赖性的描述。因此，没有办法来解析COM组件（或者其约定的定义），也不能确定它所需要的其他组件，从而无法保证它的正确运行。由于缺少相关信息，使得部署基于COM的应用程序，很难确定它需要哪些DLL，也不能静态确定所需要的是哪个版本的组件，这让对版本问题的诊断变得极其复杂； COM约定的描述格式缺乏扩展性。IDL是基于文本的，极少随组件部署，通常只有C+程序员才会使用。但是，在MTS下开发企业应用的C+程序员很少，这使得IDL约定用处不大。TLB在扩展性方面存在缺陷，而且VB与TLB/MTS之间被隔离开来，这最终导致了TLB的没落。2约定的工作方式：COM组件的约定是基于类型描述的，所采用的类型系统是C+的可移植子集。而且COM对组件的约定是物理的（二进制约定）。它要求：每个方法都具有精确的虚函数表vtable偏移量、每个被传递的参数在堆栈规则中都有明确的偏移量、对象引用采用接口指针的明确格式、使用规定的分配器进行被调用这内存分配。就底层技术而言，COM组件的约定，最终只是在内存中形成堆栈结构的协议，根本没有（按组件所要求的那样来）描述语义内容。二进制的物理约定，过度关心细节，使COM难于使用和开发。尤其在针对COM组件的版本控制问题上，物理性约定所产生的问题就更大了。这使得COM组件，难以进行语义修改和版本升级。COM组件的约定定义的精确性，产生了高效的代码，但这却是以难以接受的不可靠性和开发使用及扩展升级的困难与复杂性为代价的。（2）CLR与CLI为了解决COM所存在的这些问题，微软公司的COM和MTS小组，计划开发一个新的组件平台。开始时叫COM3或COM+ 2.0，后来又叫COR（Component Object Runtime，组件对象运行时）和URT（Universal Runtime通用运行时），最后才被命名为CLR（Common Language Runtime，公共语言运行时库/层）。它是现在（由微软提交的）成为国际标准的CLI（Common Language Infrastructure公共语言基础结构）在Windows平台上的一种具体实现。CLI是针对可执行代码格式、以及能执行该代码的运行时环境的一种规范。CLI标准包含如下几个主要组成部分：l CTS（Common Type System公共类型系统）被编译器、工具和CLI本身所共用的一种统一类型系统。 它是一个模型，定义了在声明、使用和管理类型时，CLI应遵循的规则。CTS建立了一个框架，使跨语言集成、类型安全和高性能的代码执行成为可能；l CLS（Common Language Specification公共语言规范）语言设计者和框架（类库）设计者之间的一种协定（agreement）。它指定了CTS的一个子集和一个用法常规（usage conventions）集；l metadata（元数据）描述和引用CTS所定义类型的数据。元数据被以一种独立于任何特定的程序设计语言的方式存储。从而，元数据为操作程序的工具（如编译器和调试器）之间，以及这些工具和VES之间提供了一种公共交换机制。l VES（Virtual Execution System虚拟执行系统）该系统实现和实施CTS模型。VES负责装入和运行为CLI编写的程序。它在运行时，利用元数据将分开产生的模型连接在一起，并为执行托管代码和数据提供所需要的服务。VES也被称为执行引擎；l CIL（Common Intermediate Language公共中间语言）可被VES理解的指令集，也被称为MSIL（微软IL）。程序集（Assembly，装配/汇编）就是CLR中的组件，它是一种功能上不可分割的逻辑单元，由一个或多个模块（module，DLL或EXE文件）组成。大多数程序集就是一个DLL，所以程序集也被称为“托管DLL”。每个程序集中有一个程序清单（manifest），它包含了程序集内所有模块和其他文件的信息（如程序集的名称、版本号、文化和语言、程序集包含的所有文件列表、程序集所依赖的其他程序集等）。程序集中自然包含了若干CLR类的（MSIL中间语言）代码，同时还包含了这些类的元数据。元数据（metadata）描述模块中类型的相关信息，如类型的名称、类型的可见性（public或assembly）、基类、实现的接口和方法、暴露的属性、提供的事件等。清单类X的代码类Y的代码类Z的代码类X、Y、Z的元数据app1.dll程序集A清单类P的代码类Q的代码类P、Q的元数据app3.dll程序集Bapp2.exe类R的代码类R的元数据程序集示例（3）.NET(CLR)与COM与COM相比，CLR的组件技术有了质的飞跃，前面提到的各种COM问题都迎刃而解、一扫而光。l 相同点约定（类型）与COM平台一样，CLR也注意组件间的约定，而且这些约定也是基于类型的（注意，组件技术里的类型是广义的，除了包括字符、布尔、整数和浮点数等基本数据类型之外，还包括类、结构、接口、串、数组、枚举、委托delegate，指向方法和函数的安全指针，用于事件处理和回调等高级结构类型）。l 不同点1约定的描述（元数据）但是与COM（没有标准格式来描述约定）不同的是，CLR有完全规范的格式来描述组件之间的约定元数据（metadata）。CLR的元数据是机器可读的