请问DCOM是不是Com+? DCOM只是COM的客户端，怎么是COM+，客户端程序通过DCOM与服务器上的COM+进行沟通 解决方案 » 免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货 up 看得还是不明, 有没有相关学习资料[email protected] DOCM + MTS = COM+look book Professional VB.NET Transaction ActiveX、OLE和COM介绍戴宗友 汪涛熟悉面向对象编程和网络编程的人一定对ActiveX、OLE和COM/DCOM这些概念不会陌生，但是它们之间究竟是什么样的关系，对许多们还是比较模糊的。在具体介绍它们的关系之间，我们还是先明确组件（Component）和对象（Object）之间的区别。组件是一个可重用的模块，它是由一组处理过程、数据封装和用户接口组成的业务对象（Rules Object）。组件看起来像对象，但不符合对象的学术定义。它们的主要区别是：1）组件可以在另一个称为容器（有时也称为承载者或宿主）的应用程序中使用，也可以作为独立过程使用；2）组件可以由一个类构成，也可以由多个类组成，或者是一个完整的应用程序；3）组件为模块重用，而对象为代码重用。现在，比较流行的组件模型有COM（Component Objiect Module，对象组件模型）/DCOM（Distributed COM，分布式对象组件模型）和CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）。到这里，已经出现了与本文相关的主题COM，而CORBA与本文无关，就不作介绍。之所以从组件与对象的区别说起，是想让大家明确COM和CORBA是处在整个体系结构的最底层，如果暂时对此还不能理解，不妨继续往下看，最后在回过头看一看就自然明白了。现在开始阐述ActiveX、OLE和COM的关系。首先，让大家有一个总体的概念，从时间的角度讲，OLE是最早出现的，然后是COM和ActiveX；从体系结构角度讲，OLE和ActiveX是建立在COM之上的，所以COM是基础；单从名称角度讲，OLE、ActiveX是两个商标名称，而COM则是一个纯技术名词，这也是大家更多的听说ActiveX和OLE的原因。既然OLE是最早出现的，那么就从OLE说起，自从Windows操作系统流行以来，“剪贴板”（Clipboard）首先解决了不同程序间的通信问题（由剪贴板作为数据交换中心，进行复制、粘贴的操作），但是剪贴板传递的都是“死”数据，应用程序开发者得自行编写、解析数据格式的代码，于是动态数据交换（Dynamic Data Exchange，DDE）的通信协定应运而生，它可以让应用程序之间自动获取彼此的最新数据，但是，解决彼此之间的“数据格式”转换仍然是程序员沉重的负担。对象的链接与嵌入（Object Linking and Embedded，OLE）的诞生把原来应用程序的数据交换提高到“对象交换”，这样程序间不但获得数据也同样获得彼此的应用程序对象，并且可以直接使用彼此的数据内容，其实OLE是Microsoft的复合文档技术，它的最初版本只是瞄准复合文档，但在后续版本OLE2中，导入了COM。由此可见，COM是应OLE的需求而诞生的，所以虽然COM是OLE的基础，但OLE的产生却在COM之前。COM的基本出发点是，让某个软件通过一个通用的机构为另一个软件提供服务。COM是应OLE的需求而诞生，但它的第一个使用者却是OLE2，所以COM与复合文档间并没有多大的关系，实际上，后来COM就作为与复合文档完全无关的技术，开始被广泛应用。这样一来，Microsoft就开始“染指”通用平台技术。但是COM并不是产品，它需要一个商标名称。而那时Microsoft的市场专家们已经选用了OLE作为商标名称，所以使用COM技术的都开始贴上了OLE的标签。虽然这些技术中的绝大多数与复合文档没有关系。Microsoft的这一做法让人产生这样一个误解OLE是仅指复合文档呢？还是不单单指复合文档？其实OLE是COM的商标名称，自然不仅仅指复合文档。但Microsoft自己恐怕无法解释清楚，这要花费相当的精力和时间。于是，随着Internet的发展，在1996年春，Microsoft改变了主意，选择ActiveX作为新的商标名称。ActiveX是指宽松定义的、基于COM的技术集合，而OLE仍然仅指复合文档。当然，ActiveX最核心的技术还是COM。ActiveX和OLE的最大不同在于，OLE针对的是桌面上应用软件和文件之间的集成，而ActiveX则以提供进一步的网络应用与用户交互为主。到这里，大家应该对ActiveX、OLE和COM三者的关系有了一个比较明确的认识，COM才是最根本的核心技术，所以下面的重点COM。让对象模型完全独立于编程语言，这是一个非常新奇的思想。这一点从C++和Java的对象概念上，我们就能有所了解。但所谓COM对象究竟是什么呢？为了便于理解，可以把COM看作是某种（软件）打包技术，即把它看作是软件的不同部分，按照一定的面向对象的形式，组合成可以交互的过程和以组支持库。COM对象可以用C++、Java和VB等任意一种语言编写，并可以用DLL或作为不同过程工作的执行文件的形式来实现。使用COM对象的浏览器，无需关心对象是用什么语言写的，也无须关心它是以DLL还是以另外的过程来执行的。从浏览器端看，无任何区别。这样一个通用的处理技巧非常有用。例如，由用户协调运行的两个应用，可以将它们的共同作业部分作为COM对象间的交互来实现（当然，现在的OLE复合文档也能做到）。为在浏览器中执行从Web服务器下载的代码，浏览器可把它看作是COM对象，也就是说，COM技术也是一种打包可下载代码的标准方法（ActiveX控件就是执行这种功能的）。甚至连应用与本机OS进行交互的方法也可以用COM来指定，例如在Windows和Windows NT中用的是新API，多数是作为COM对象来定义的。可见，COM虽然起源于复合文档，但却可有效地适用于许多软件问题，它毕竟是处在底层的基础技术。用一句话来说，COM是独立于语言的组件体系结构，可以让组件间相互通信。随着计算机网络的发展，COM进一步发展为分布式组件对象模型，这就是DCOM，它类似于CORBA的ORB，本文对此将不再做进一步的阐述。通过上面的讲述相信大家一定对ActiveX、OLE和COM/DCOM的关系有了一个清楚的了解。 .NET框架与COM背景和历史可复用软件不是一个新概念。八年来，人们一直在使用各种形式的组件对象模型(COM)。事实证明，它是最为成功的可复用软件模型。COM引进了“组件”的概念——它是可复用的代码块，可以将多个独立函数的功能进行组合，从而扩充成诸如Microsoft Word这样的应用程序。大多数开发人员使用OLE时深刻体验了COM功能。OLE是基于COM形成的一组功能，使得用户能将一种文档嵌入到另一种文档中。这个功能本身似乎不太引人入胜，但它的作用却不同凡响：当用户将一个Excel文档粘贴到Word文档中后，单击嵌入的Excel文档时，OLE将会把Word的工具栏和菜单转换成Excel的工具栏和菜单。从开发人员的角度看，COM通过引进几个明确定义的接口（诸如iUnknown）便可提供代码复用功能，开发期工具可通过这些接口来查询一个组件的功能，并能把这些功能添加到工具中。这就像Visual Basic®开发系统工具箱中的控件能够被拖到某个窗体中一样。实际上，每个控件都代表上百行甚至上千行的代码，可以容易地封装在“黑匣子”中，开发人员只需直接调用其功能即可。开发人员在使用COM时感到不便的一个问题是，他们必须编写附加代码来将业务逻辑程序转换成可复用的组件，同时还必须实现许多接口才能进行这种转换。最重要的是，COM要求开发人员必须手动处理复杂问题，比如：清空不再使用的组件曾占用的内存、计算组件的使用次数、建立或撤消线程和进程以及处理版本控制问题等。有人可能认为，让开发人员亲自执行这类工作的主意非常好，但这也有几个弊端。首先，要开发人员一一执行上述所有工作非常困难，往往容易出错：导致应用程序错误、系统崩溃以及可怕的“DLL Hell”。另外，严格地写出所有这种附加代码，会降低开发人员的工作效率，导致延期上市。这对使用Visual C++®开发系统的开发人员来说，尤其如此。而对使用Visual Basic的开发人员来说，这种情况不是很严重。Visual Basic抽象并简化了COM的许多概念，是全世界最具生产力、最流行的开发环境，但它的局限性在于：为了实现这种高生产力而不得不向开发人员屏蔽了COM的一些功能。微软在2000年的专业开发人员大会（PDC）上引进的.NET框架，能自动在软件编写过程中进行“智能拼接”，使得开发人员可以集中精力编写业务逻辑，而不必编写COM基本结构。什么是.NET框架？.NET框架是一个多语言组件开发和执行环境，它由以下三个主要部分组成：公共语言运行时。此名称不能准确反映它的全部功能。实际上，公共语言运行时在组件的开发及运行过程中，都扮演着非常重要的角色。在组件运行过程中，运行时负责管理内存分配、启动或删除线程和进程、实施安全性策略、同时满足当前组件对其它组件的需求。在开发阶段，运行时的作用有些变化：与现今的COM相比，运行时的自动化程度大为提高（比如可自动执行内存管理），因而开发人员的工作变得非常轻松。尤其是，映射功能将锐减开发人员将业务逻辑程序转化成可复用组件的代码编写量。对编程语言而言，运行时这个概念并不新奇：实际上每种编程语言都有自己的运行时。Visual Basic开发系统具有最为明显的运行时（名为VBRUN），Visual C++®跟Visual FoxPro®、Jscript®、SmallTalk、Perl、Python和Java一样有一个运行时，即MSVCRT。.NET框架的关键作用在于，它提供了一个跨编程语言的统一编程环境，这也是它能独树一帜的根本原因。 统一的编程类。.NET框架为开发人员提供了一个统一、面向对象、层次化、可扩展的类库集(API)。现今，C++开发人员使用的是Microsoft基类库，Java开发人员使用的是Windows®基类库，而Visual Basic用户使用的又是Visual Basic API集。只是简单地一用，.NET框架就统一了微软当前的各种不同类框架。这样，开发人员无需学习多种框架就能顺利编程。远不止于此的是，通过创建跨编程语言的公共API集，.NET框架可实现跨语言继承性、错误处理功能和调试功能。实际上，从JScript到C++的所有编程语言，都是相互等同的，开发人员可以自由选择理想的编程语言。 活动服务器页面(ASP+)。ASP+是使用.NET框架提供的编程类库构建而成的，它提供了Web应用程序模型，该模型由一组控件和一个基本结构组成。有了它，Web应用程序的构建变得非常容易。开发人员可以直接使用ASP+控件集，该控件集封装了公共的、用于超文本标识语言(HTML)用户界面的各种小器件（诸如文本框、下拉菜单等等）。实际上，这些控件运行在Web服务器上，它们将用户界面转换成HTML格式后再发送给浏览器。在服务器上，控件负责将面向对象的编程模型提供给Web开发人员，这种编程模型能提供面向对象编程技术的丰富功能。ASP+还提供一些基本结构服务（诸如会话状态管理和进程重启服务），这些服务大大减少了开发人员要编写的代码量，并使应用程序的可靠性得到大幅度提高。ASP+还允许开发人员将软件作为一项服务来提供。通过使用ASP+ Web服务功能，ASP+开发人员只需进行简单的业务逻辑编程，而由ASP+基本结构负责通过简单对象访问协议(SOAP)来提供服务。与COM的关系.NET框架的一个主要目的是使COM开发变得更加容易。COM开发过程中最难的一件事是处理COM基本结构。因此，为了简化COM开发，.NET框架实际上已自动处理了所有在开发人员看来是与“COM”紧密相关的任务，包括引用计算、接口描述以及注册。必须认识到，这并不意味着.NET框架组件不是COM组件。事实上，使用Visual Studio 6.0的COM开发人员可以调用.NET框架组件，并且在他们看来，后者更像是拥有iUnknown数据的COM组件。相反，使用Visual Studio.NET的.NET框架开发人员则将COM组件视作.NET框架组件。为了避免引起误解，这里需对这种关系加以特别说明：COM开发人员必须手动去做大多数.NET框架开发人员可以在运行时自动执行的事情。例如，必须手写COM组件的安全性模块，且无法自动管理模块占用的内存，而在安装COM组件时，注册条目必须放进Windows注册表中。对.NET框架而言，运行时实现了这些功能的自动化。例如，组件本身是自我描述型的，因而无需注册到Windows注册表中便能安装。与COM+的关系当把COM与Microsoft事务服务器(MTS)和分布式COM(DCOM)结合在一起时，就变成了COM+。COM+提供了一组面向中间层的服务。特别是COM+提供了进程管理功能和数据库与对象连接池处理功能。在将来的版本中，它还将提供一种称为分区的功能——专门为应用程序服务提供商设计的更强大的进程隔离功能。COM+服务主要面向中间层应用程序开发，并主要为大型分布式应用程序提供可靠性和可扩展性。这些服务是对.NET框架所提供服务的补充；通过.NET框架类，可以直接访问这些服务。 COM+介绍可能有许多人已经用COM设计过应用程序并知道它有很多局限性。实际上，这项技术的一个主要问题是它不太适用于通常通过公司的局域网(LAN)或广域网(WAN)进行发布的企业级应用程序。MS很久以前就意识到了这种限制，并试图通过分布式COM(DCOM)来弥补这个缺陷。但是DCOM也存在一些限制，所以MS在Windows2000中提出了COM+. COM+不是一项新技术，它是对当前技术的一个扩充。 COM+中增加的主要东西包括两种已有的技术，微软事务服务器(MTS)和微软消息对列(MSMQ)。MTS通过事务增加了COM的可靠性。它确保每次COM数据传输至少发生一次，而且只有一次。另一方面MSMQ还改正了另一个与COM有关的问题，就是紧密连接的应用程序的问题。当使用位于本地机器上的应用程序时，客户和服务器同时存在。但是分布式应用程序就不能保证这一点。用户可能在没有连接到服务器上但同时又创建了新的工作。分布式应用程序需要提供一个强健的环境，允许用户在服务器处于不可用状态时仍然可以工作。 1.1 COM+的历史DDE和OLE是MS早期的东东。后来OLE发展成了ActiveX(一种特殊类型的组件技术)。ActiveX实际上包含有DDE和OLE中的多种概念和技术，它增加了一种思想，既可以将ActiveX控件(独立的专用程序或库，通常很小)用于传统的应用程序或嵌入到HTML文档中在internet上使用。DCOM在分布式计算中所起的作用DCOM它依赖于开放软件基金会(OSF)分布式计算环境(DCE)的远程程序调用网络协议获得了成功。它可以使应用程序通过网络以DDE、OLE和COM进行通信。另外，DCOM创建的链接即安全又持久。如果移动了服务器端的组件，则客户机无论如何也找不到它。不过，排除掉那些不合理的东西DCOM还是十分可靠的。DCOM的问题在于它与协议结合的台紧密了。这意味着客户和服务器必须同时存在并且在他们之间有连接。DCOM还存在其他的问题。对于一次通信至少要发生一次而且只能发生一次来说DCOM就不能提供任何保证。那么COM+有多好呢？实际上COM+是三种技术的结合：DCOM、MTS和MSMQ。DCOM有一个并且只有一个问题，就是信息的传输。将MTS加进来就解决了这个问题。现在每次数据传输都将作为一个事务而发生，这就意味着每次传输将只发生一次，而且至少发生一次。DCOM不能在非连接的环境中工作。MSMQ使用一个消息协议解决了这个问题。1.2 COM+要点1.2.1连通性COM+有两种连通性。第一,COM+所包含的MTS确保了通信的可靠性。每一次通性都保证发生且仅发生一次。第二，非连接的应用程序的开发意味着无论在何处都可以产生数据，即使没有直接连接到服务器也可以。1.2.2用户无论是对用户还是对程序员，COM+都设计有可靠的连通性和简易的使用性。1.2.3用户界面1.2.4程序员大多数开发人员能够从COM+中得到的好处快速的开发时间、更少的调试时间、更多的自动功能、更加可靠1.3 COM+和COM的比较从创建组件的角度来讲，COM和COM+是相同的。实际上，在谈及组件时COM+仅是对现存COM技术的一个扩充。COM+是COM的一个超集，所以在应用程序中用COM+代替COM不会丢失任何东西。1.3.1 COM+设计目标一个主要的目标是使服务器组件的开发能像客户端的组件的开发一样容易。COM+消除了大量的由多用户环境所带来的问题。如多个用户同时对同一组件进行访问。第二个目标是使企业级的开发变得容易。创建适用于任何规模的组件。13.2 COM+服务事件：应用程序能够接收到服务器上产生的事件，就好像发生在本地机器上一样。安全性:COM+实际上依靠MTS来实现它的安全性。组件负载平衡:队列组件：补偿资源管理器：实际上是在老的服务器应用程序上搭建一个支架，使客户机可以用COM+提供的所有新功能对应用程序进行访问。管理：使用MMC插件对服务器端的组件进行管理。发布/预定事件模型：这种新模型使开发人员可以创建一种应用程序，在执行一项任务时可以不用知道彼此的情况。组件将事件发出去而不管这些事件去向那里。应用程序可以订阅事件，而不用知道他们的来源。1.4配置环境推荐的操作系统一台用作客户机，安装win2000 professional一台用作服务器，安装win2000 serverIIS完全安装如果使用MSMQ,请安装 MESSAGE Queuing Services datagridview和sql存储图片问题 如何修改一个外部程序的ListView控件 希望关注！serialport委托 关于自定义控件属性 接口 关于数据库存储加密 应该把哪些代码写在构造函数里，哪些代码写在OnLoad()里呢？ 关于TcpListener和TcpClient的两个不明白的地方，请大家指教 求教Calendar日历控件的问题 请问正则表达式的替换构造 dataGrid的各个例的宽度怎么设置？ c#菜鸟~~~居然是void Page_Load错误,帮忙看看 [WEB]如何将光标定在TextBox最后面？
看得还是不明, 有没有相关学习资料[email protected]
look book Professional VB.NET Transaction
在具体介绍它们的关系之间，我们还是先明确组件（Component）和对象（Object）之间的区别。组件是一个可重用的模块，它是由一组处理过程、数据封装和用户接口组成的业务对象（Rules Object）。组件看起来像对象，但不符合对象的学术定义。它们的主要区别是：
1）组件可以在另一个称为容器（有时也称为承载者或宿主）的应用程序中使用，也可以作为独立过程使用；
2）组件可以由一个类构成，也可以由多个类组成，或者是一个完整的应用程序；
3）组件为模块重用，而对象为代码重用。
现在，比较流行的组件模型有COM（Component Objiect Module，对象组件模型）/DCOM（Distributed COM，分布式对象组件模型）和CORBA（Common Object Request Broker Architecture，公共对象请求代理体系结构）。到这里，已经出现了与本文相关的主题COM，而CORBA与本文无关，就不作介绍。之所以从组件与对象的区别说起，是想让大家明确COM和CORBA是处在整个体系结构的最底层，如果暂时对此还不能理解，不妨继续往下看，最后在回过头看一看就自然明白了。
现在开始阐述ActiveX、OLE和COM的关系。首先，让大家有一个总体的概念，从时间的角度讲，OLE是最早出现的，然后是COM和ActiveX；从体系结构角度讲，OLE和ActiveX是建立在COM之上的，所以COM是基础；单从名称角度讲，OLE、ActiveX是两个商标名称，而COM则是一个纯技术名词，这也是大家更多的听说ActiveX和OLE的原因。
既然OLE是最早出现的，那么就从OLE说起，自从Windows操作系统流行以来，“剪贴板”（Clipboard）首先解决了不同程序间的通信问题（由剪贴板作为数据交换中心，进行复制、粘贴的操作），但是剪贴板传递的都是“死”数据，应用程序开发者得自行编写、解析数据格式的代码，于是动态数据交换（Dynamic Data Exchange，DDE）的通信协定应运而生，它可以让应用程序之间自动获取彼此的最新数据，但是，解决彼此之间的“数据格式”转换仍然是程序员沉重的负担。对象的链接与嵌入（Object Linking and Embedded，OLE）的诞生把原来应用程序的数据交换提高到“对象交换”，这样程序间不但获得数据也同样获得彼此的应用程序对象，并且可以直接使用彼此的数据内容，其实OLE是Microsoft的复合文档技术，它的最初版本只是瞄准复合文档，但在后续版本OLE2中，导入了COM。由此可见，COM是应OLE的需求而诞生的，所以虽然COM是OLE的基础，但OLE的产生却在COM之前。
COM的基本出发点是，让某个软件通过一个通用的机构为另一个软件提供服务。COM是应OLE的需求而诞生，但它的第一个使用者却是OLE2，所以COM与复合文档间并没有多大的关系，实际上，后来COM就作为与复合文档完全无关的技术，开始被广泛应用。这样一来，Microsoft就开始“染指”通用平台技术。但是COM并不是产品，它需要一个商标名称。而那时Microsoft的市场专家们已经选用了OLE作为商标名称，所以使用COM技术的都开始贴上了OLE的标签。虽然这些技术中的绝大多数与复合文档没有关系。Microsoft的这一做法让人产生这样一个误解OLE是仅指复合文档呢？还是不单单指复合文档？其实OLE是COM的商标名称，自然不仅仅指复合文档。但Microsoft自己恐怕无法解释清楚，这要花费相当的精力和时间。
于是，随着Internet的发展，在1996年春，Microsoft改变了主意，选择ActiveX作为新的商标名称。ActiveX是指宽松定义的、基于COM的技术集合，而OLE仍然仅指复合文档。当然，ActiveX最核心的技术还是COM。ActiveX和OLE的最大不同在于，OLE针对的是桌面上应用软件和文件之间的集成，而ActiveX则以提供进一步的网络应用与用户交互为主。到这里，大家应该对ActiveX、OLE和COM三者的关系有了一个比较明确的认识，COM才是最根本的核心技术，所以下面的重点COM。
让对象模型完全独立于编程语言，这是一个非常新奇的思想。这一点从C++和Java的对象概念上，我们就能有所了解。但所谓COM对象究竟是什么呢？为了便于理解，可以把COM看作是某种（软件）打包技术，即把它看作是软件的不同部分，按照一定的面向对象的形式，组合成可以交互的过程和以组支持库。COM对象可以用C++、Java和VB等任意一种语言编写，并可以用DLL或作为不同过程工作的执行文件的形式来实现。使用COM对象的浏览器，无需关心对象是用什么语言写的，也无须关心它是以DLL还是以另外的过程来执行的。从浏览器端看，无任何区别。这样一个通用的处理技巧非常有用。例如，由用户协调运行的两个应用，可以将它们的共同作业部分作为COM对象间的交互来实现（当然，现在的OLE复合文档也能做到）。为在浏览器中执行从Web服务器下载的代码，浏览器可把它看作是COM对象，也就是说，COM技术也是一种打包可下载代码的标准方法（ActiveX控件就是执行这种功能的）。甚至连应用与本机OS进行交互的方法也可以用COM来指定，例如在Windows和Windows NT中用的是新API，多数是作为COM对象来定义的。可见，COM虽然起源于复合文档，但却可有效地适用于许多软件问题，它毕竟是处在底层的基础技术。用一句话来说，COM是独立于语言的组件体系结构，可以让组件间相互通信。随着计算机网络的发展，COM进一步发展为分布式组件对象模型，这就是DCOM，它类似于CORBA的ORB，本文对此将不再做进一步的阐述。
通过上面的讲述相信大家一定对ActiveX、OLE和COM/DCOM的关系有了一个清楚的了解。
背景和历史可复用软件不是一个新概念。八年来，人们一直在使用各种形式的组件对象模型(COM)。事实证明，它是最为成功的可复用软件模型。COM引进了“组件”的概念——它是可复用的代码块，可以将多个独立函数的功能进行组合，从而扩充成诸如Microsoft Word这样的应用程序。大多数开发人员使用OLE时深刻体验了COM功能。OLE是基于COM形成的一组功能，使得用户能将一种文档嵌入到另一种文档中。这个功能本身似乎不太引人入胜，但它的作用却不同凡响：当用户将一个Excel文档粘贴到Word文档中后，单击嵌入的Excel文档时，OLE将会把Word的工具栏和菜单转换成Excel的工具栏和菜单。从开发人员的角度看，COM通过引进几个明确定义的接口（诸如iUnknown）便可提供代码复用功能，开发期工具可通过这些接口来查询一个组件的功能，并能把这些功能添加到工具中。这就像Visual Basic®开发系统工具箱中的控件能够被拖到某个窗体中一样。实际上，每个控件都代表上百行甚至上千行的代码，可以容易地封装在“黑匣子”中，开发人员只需直接调用其功能即可。开发人员在使用COM时感到不便的一个问题是，他们必须编写附加代码来将业务逻辑程序转换成可复用的组件，同时还必须实现许多接口才能进行这种转换。最重要的是，COM要求开发人员必须手动处理复杂问题，比如：清空不再使用的组件曾占用的内存、计算组件的使用次数、建立或撤消线程和进程以及处理版本控制问题等。有人可能认为，让开发人员亲自执行这类工作的主意非常好，但这也有几个弊端。首先，要开发人员一一执行上述所有工作非常困难，往往容易出错：导致应用程序错误、系统崩溃以及可怕的“DLL Hell”。另外，严格地写出所有这种附加代码，会降低开发人员的工作效率，导致延期上市。这对使用Visual C++®开发系统的开发人员来说，尤其如此。而对使用Visual Basic的开发人员来说，这种情况不是很严重。Visual Basic抽象并简化了COM的许多概念，是全世界最具生产力、最流行的开发环境，但它的局限性在于：为了实现这种高生产力而不得不向开发人员屏蔽了COM的一些功能。微软在2000年的专业开发人员大会（PDC）上引进的.NET框架，能自动在软件编写过程中进行“智能拼接”，使得开发人员可以集中精力编写业务逻辑，而不必编写COM基本结构。什么是.NET框架？.NET框架是一个多语言组件开发和执行环境，它由以下三个主要部分组成：
公共语言运行时。此名称不能准确反映它的全部功能。实际上，公共语言运行时在组件的开发及运行过程中，都扮演着非常重要的角色。在组件运行过程中，运行时负责管理内存分配、启动或删除线程和进程、实施安全性策略、同时满足当前组件对其它组件的需求。在开发阶段，运行时的作用有些变化：与现今的COM相比，运行时的自动化程度大为提高（比如可自动执行内存管理），因而开发人员的工作变得非常轻松。尤其是，映射功能将锐减开发人员将业务逻辑程序转化成可复用组件的代码编写量。对编程语言而言，运行时这个概念并不新奇：实际上每种编程语言都有自己的运行时。Visual Basic开发系统具有最为明显的运行时（名为VBRUN），Visual C++®跟Visual FoxPro®、Jscript®、SmallTalk、Perl、Python和Java一样有一个运行时，即MSVCRT。.NET框架的关键作用在于，它提供了一个跨编程语言的统一编程环境，这也是它能独树一帜的根本原因。 统一的编程类。.NET框架为开发人员提供了一个统一、面向对象、层次化、可扩展的类库集(API)。现今，C++开发人员使用的是Microsoft基类库，Java开发人员使用的是Windows®基类库，而Visual Basic用户使用的又是Visual Basic API集。只是简单地一用，.NET框架就统一了微软当前的各种不同类框架。这样，开发人员无需学习多种框架就能顺利编程。远不止于此的是，通过创建跨编程语言的公共API集，.NET框架可实现跨语言继承性、错误处理功能和调试功能。实际上，从JScript到C++的所有编程语言，都是相互等同的，开发人员可以自由选择理想的编程语言。 活动服务器页面(ASP+)。ASP+是使用.NET框架提供的编程类库构建而成的，它提供了Web应用程序模型，该模型由一组控件和一个基本结构组成。有了它，Web应用程序的构建变得非常容易。开发人员可以直接使用ASP+控件集，该控件集封装了公共的、用于超文本标识语言(HTML)用户界面的各种小器件（诸如文本框、下拉菜单等等）。实际上，这些控件运行在Web服务器上，它们将用户界面转换成HTML格式后再发送给浏览器。在服务器上，控件负责将面向对象的编程模型提供给Web开发人员，这种编程模型能提供面向对象编程技术的丰富功能。ASP+还提供一些基本结构服务（诸如会话状态管理和进程重启服务），这些服务大大减少了开发人员要编写的代码量，并使应用程序的可靠性得到大幅度提高。ASP+还允许开发人员将软件作为一项服务来提供。通过使用ASP+ Web服务功能，ASP+开发人员只需进行简单的业务逻辑编程，而由ASP+基本结构负责通过简单对象访问协议(SOAP)来提供服务。与COM的关系.NET框架的一个主要目的是使COM开发变得更加容易。COM开发过程中最难的一件事是处理COM基本结构。因此，为了简化COM开发，.NET框架实际上已自动处理了所有在开发人员看来是与“COM”紧密相关的任务，包括引用计算、接口描述以及注册。必须认识到，这并不意味着.NET框架组件不是COM组件。事实上，使用Visual Studio 6.0的COM开发人员可以调用.NET框架组件，并且在他们看来，后者更像是拥有iUnknown数据的COM组件。相反，使用Visual Studio.NET的.NET框架开发人员则将COM组件视作.NET框架组件。为了避免引起误解，这里需对这种关系加以特别说明：COM开发人员必须手动去做大多数.NET框架开发人员可以在运行时自动执行的事情。例如，必须手写COM组件的安全性模块，且无法自动管理模块占用的内存，而在安装COM组件时，注册条目必须放进Windows注册表中。对.NET框架而言，运行时实现了这些功能的自动化。例如，组件本身是自我描述型的，因而无需注册到Windows注册表中便能安装。与COM+的关系当把COM与Microsoft事务服务器(MTS)和分布式COM(DCOM)结合在一起时，就变成了COM+。COM+提供了一组面向中间层的服务。特别是COM+提供了进程管理功能和数据库与对象连接池处理功能。在将来的版本中，它还将提供一种称为分区的功能——专门为应用程序服务提供商设计的更强大的进程隔离功能。COM+服务主要面向中间层应用程序开发，并主要为大型分布式应用程序提供可靠性和可扩展性。这些服务是对.NET框架所提供服务的补充；通过.NET框架类，可以直接访问这些服务。
可能有许多人已经用COM设计过应用程序并知道它有很多局限性。实际上，这项技术的一个主要问题是它不太适用于通常通过公司的局域网(LAN)或广域网(WAN)进行发布的企业级应用程序。
MS很久以前就意识到了这种限制，并试图通过分布式COM(DCOM)来弥补这个缺陷。
但是DCOM也存在一些限制，所以MS在Windows2000中提出了COM+.
COM+不是一项新技术，它是对当前技术的一个扩充。
COM+中增加的主要东西包括两种已有的技术，微软事务服务器(MTS)和微软消息对列(MSMQ)。MTS通过事务增加了COM的可靠性。它确保每次COM数据传输至少发生一次，而且只有一次。另一方面MSMQ还改正了另一个与COM有关的问题，就是紧密连接的应用程序的问题。当使用位于本地机器上的应用程序时，客户和服务器同时存在。但是分布式应用程序就不能保证这一点。用户可能在没有连接到服务器上但同时又创建了新的工作。分布式应用程序需要提供一个强健的环境，允许用户在服务器处于不可用状态时仍然可以工作。
1.1 COM+的历史
DDE和OLE是MS早期的东东。后来OLE发展成了ActiveX(一种特殊类型的组件技术)。ActiveX实际上包含有DDE和OLE中的多种概念和技术，它增加了一种思想，既可以将ActiveX控件(独立的专用程序或库，通常很小)用于传统的应用程序或嵌入到HTML文档中在internet上使用。
DCOM在分布式计算中所起的作用
DCOM它依赖于开放软件基金会(OSF)分布式计算环境(DCE)的远程程序调用网络协议获得了成功。它可以使应用程序通过网络以DDE、OLE和COM进行通信。另外，DCOM创建的链接即安全又持久。如果移动了服务器端的组件，则客户机无论如何也找不到它。不过，排除掉那些不合理的东西DCOM还是十分可靠的。
DCOM的问题在于它与协议结合的台紧密了。这意味着客户和服务器必须同时存在并且在他们之间有连接。
DCOM还存在其他的问题。对于一次通信至少要发生一次而且只能发生一次来说DCOM就不能提供任何保证。
那么COM+有多好呢？实际上COM+是三种技术的结合：DCOM、MTS和MSMQ。DCOM有一个并且只有一个问题，就是信息的传输。将MTS加进来就解决了这个问题。现在每次数据传输都将作为一个事务而发生，这就意味着每次传输将只发生一次，而且至少发生一次。DCOM不能在非连接的环境中工作。MSMQ使用一个消息协议解决了这个问题。
1.2 COM+要点
1.2.1连通性
COM+有两种连通性。第一,COM+所包含的MTS确保了通信的可靠性。每一次通性都保证发生且仅发生一次。第二，非连接的应用程序的开发意味着无论在何处都可以产生数据，即使没有直接连接到服务器也可以。
1.2.2用户
无论是对用户还是对程序员，COM+都设计有可靠的连通性和简易的使用性。1.2.3用户界面
1.2.4程序员
大多数开发人员能够从COM+中得到的好处
快速的开发时间、更少的调试时间、更多的自动功能、更加可靠1.3 COM+和COM的比较
从创建组件的角度来讲，COM和COM+是相同的。实际上，在谈及组件时COM+仅是对现存COM技术的一个扩充。COM+是COM的一个超集，所以在应用程序中用COM+代替COM不会丢失任何东西。
1.3.1 COM+设计目标
一个主要的目标是使服务器组件的开发能像客户端的组件的开发一样容易。COM+消除了大量的由多用户环境所带来的问题。如多个用户同时对同一组件进行访问。
第二个目标是使企业级的开发变得容易。创建适用于任何规模的组件。
13.2 COM+服务
事件：应用程序能够接收到服务器上产生的事件，就好像发生在本地机器上一样。
安全性:COM+实际上依靠MTS来实现它的安全性。
组件负载平衡:
队列组件：
补偿资源管理器：实际上是在老的服务器应用程序上搭建一个支架，使客户机可以用COM+提供的所有新功能对应用程序进行访问。
管理：使用MMC插件对服务器端的组件进行管理。
发布/预定事件模型：这种新模型使开发人员可以创建一种应用程序，在执行一项任务时可以不用知道彼此的情况。组件将事件发出去而不管这些事件去向那里。应用程序可以订阅事件，而不用知道他们的来源。1.4配置环境
推荐的操作系统
一台用作客户机，安装win2000 professional
一台用作服务器，安装win2000 server
IIS完全安装
如果使用MSMQ,请安装 MESSAGE Queuing Services