17,740
社区成员
发帖
与我相关
我的任务
分享.net如何取代com？我得一点疑问.
com是一种以组件为单位进行交互的技术，它采用接口描述组件信息，而且客户对组件的访问也是通过接口，它的契约建立在二进制基础上。而clr的装配件是采用元数据描述，使用中间语言描述。
com有进程内和进程外com组件之分，com组件需要注册到注册表，当客户程序调用com提供的服务的时候，需要查找注册表，并动态加载com组件，所以com组件的其中一个特性就是位置透明性。
在.net中，装配件是CLR加载的最小单位。在一个项目中要调用其他装配件的服务，就必须先引用那个装配件，同时复制到本地bin内。也就是说，在.net中，无法实现com中那种位置透明性？
另外在com的模型中，客户端可以调用进程外的com组件（包括本地和跨网络），如果是本机不同进程，则由本机的com库直接进行组件加载操作；如果是其他机器，com库应该在特定的端口监听，当收到请求时，同样由com库加载组件.在.net中，是通过remoting来实现的，其监听加载宿主可以是windows服务，iis或是其他自己写的程序。
不知道，我得理解是否正确，是否在.net中，就是通过如此方式来取代com的？
com有进程内和进程外com组件之分，com组件需要注册到注册表，当客户程序调用com提供的服务的时候，需要查找注册表，并动态加载com组件，所以com组件的其中一个特性就是位置透明性。
在.net中，装配件是CLR加载的最小单位。在一个项目中要调用其他装配件的服务，就必须先引用那个装配件，同时复制到本地bin内。也就是说，在.net中，无法实现com中那种位置透明性？
另外在com的模型中，客户端可以调用进程外的com组件（包括本地和跨网络），如果是本机不同进程，则由本机的com库直接进行组件加载操作；如果是其他机器，com库应该在特定的端口监听，当收到请求时，同样由com库加载组件.在.net中，是通过remoting来实现的，其监听加载宿主可以是windows服务，iis或是其他自己写的程序。
不知道，我得理解是否正确，是否在.net中，就是通过如此方式来取代com的？
...全文
请发表友善的回复…
发表回复
liyin_first 2003-12-25
- 打赏
- 举报
呵呵 ,谢谢 juqiang(方枪枪（正在修炼伤心小箭）) 老兄!
DangerousWang 2003-12-24
- 打赏
- 举报
公共语言运行库
为了处理COM约定及其定义所引发的问题，Microsoft公司的COM与MTS小组计划开发一个新的组件平台，名为COM3。就在选定该名称不久，Microsoft的多个组织一致认为，在特定的Microsoft平台下，COM3这个名称并不合适。随即将其更名为公共对象运行库[Component Object Runtime(COR)]。在开发过程中，还采用过COM+在内的其他名称。很快地，又变为通用运行库[Universal Runtime(URT)]。在第一个beta版发布之前，最终将名称定为公共语言运行库[Common Language Runtime(CLR)]。
同COM平台一样，CLR也关注组件间的约定，并且，这些约定也都是基于类型的。不过，这也是两种约定的全部共同之处。
不同于COM，CLR自从问世以来，就有完全规范的格式描述组件之间的约定。这种格式一般称为元数据（metadata）。CLR元数据是机器可读的（machine-readable），其格式是完全规范的。此外，CLR提供了一些实用部件，使得程序员在不懂底层文件格式的情形下，就能够读写元数据。通过定
制特性（attribute；其本身就是强类型的），CLR元数据可以达到清晰容易的可扩展性。CLR元数据还包括组件的依赖关系和版本信息，这就允许使用一些新的技术来处理组件的版本控制问题。CLR元数据的存在是强制性的；你要部署或者加载组件，都必须访问元数据。同将元数据的存在作为可选项的环境（例如，COM）相比，构建基于CLR的基础架构和工具，显然要容易一些。
CLR约定与COM约定的第二个差别就是约定本身的特性。在COM中，组件约定暗示了堆栈约定、虚函数表，以及作为方法参数传递的数据结构在内存中的表示形式。在这方面，CLR和COM有着非常大的差异。
在CLR中，约定被描述为类型的逻辑结构。特别是，CLR约定不会描述任何数据的内存表示形式。CLR推迟确定有关内存的表示形式，直到在运行时类型被首次加载。约定的虚拟化（virtualization）很大程度上降低COM二进制约定所带来的不稳定性，这是因为组件间不存在任何内存表示形式的假设。
由于CLR类型定义是逻辑的，而不是物理的，因此，CLR的约定中并没有暗示访问字段或方法的精确的代码顺序。这样，在考虑虚方法布局、堆栈规则、对齐方式以及参数传递转换时，CLR具有极大的灵活性。并且，CLR的版本改变，不会带来组件的重新编译。因而，CLR通过名字与签名引用字段与方法，而不是偏移量。这样，CLR避免了困扰COM的声明顺序问题。成员的实际地址/偏移量需要等到在运行时类型被加载及初始化时才能够确定。
实现数据表示形式和方法地址的虚拟化有一个重要前提条件。由于约定的物理方面（例如，方法表/字段的位移量）在组件编译时都不知道，因此，就需要引进某种机制，延期这些位移量的解析，直到代码实际部署，以便在特定处理器构架中生成组件的最终版本。为了实现这个可能性，CLR的组件中几乎不包含机器代码，准确地说，基于CLR组件采用的公共中间语言[Common Intermediate Language(CIL)]用于他们的实现。
人们容易认为CIL只不过是个处理器无关（processor-neutral）的指令集，从而轻易地拒绝使用它。不过，即使只有一种处理器架构加入，CIL也是很重要的，这是因为CIL具有抽象能力，它将与机器代码密切关联的物理数据表示形式抽象出来。被CIL使用的操作码（opcode），在访问字段或调用方法时，不再使用绝对位移量或地址。准确地说，为了操作字段或方法，那些CIL会包含元数据的引用。这些引用只是基于字段或方法的名字与签名，而不是其位置或位移量。只要目标组件中存在与名字与签名匹配的字段或方法，CLR就没有必要选择物理位移量。
要注意，CLR不会直接执行CIL。准确地说，CIL在执行前总是被翻译为本机的机器语言。要么是在组件载入内存时，要么是组件被安装到部署机器上时，翻译就会被执行。无论哪种情况，当CIL到本机代码的翻译完成时，任何数据类型或方法的实际内存表示形式将被用于生成本机的机器代码，从而得到高效代码。
CIL生成的本机代码同样受益于高性能的物理耦合方式（physical coupling）,这也是C++和COM所采用的方式。然而，C++和COM在形式阶段就考虑这种物理耦合，而CLR在CIL到本机代码翻译发生之前，不会解析这种物理绑定的细节。由于翻译是在部署机器上翻译的，因此，部件以外所需的类型定义将与部署机器上的某个类型相匹配，而不是开发者的机器上。这极大的减少了跨组件约定的不可靠性，同时，又不降低性能。
最后，由于CIL到本机器代码的翻译发生在部署机器上，因此，任何用到的待定处理器布局或对齐规则（alignment rule）将与目标处理器架构（代码将在上面运行）匹配。软件也即将迎来另一个处理器迁移，即由现在的IA-32/Pentium架构向IA-64/Itanium架构发展。对于这次升级，CLR显得尤为重要。
为了处理COM约定及其定义所引发的问题，Microsoft公司的COM与MTS小组计划开发一个新的组件平台，名为COM3。就在选定该名称不久，Microsoft的多个组织一致认为，在特定的Microsoft平台下，COM3这个名称并不合适。随即将其更名为公共对象运行库[Component Object Runtime(COR)]。在开发过程中，还采用过COM+在内的其他名称。很快地，又变为通用运行库[Universal Runtime(URT)]。在第一个beta版发布之前，最终将名称定为公共语言运行库[Common Language Runtime(CLR)]。
同COM平台一样，CLR也关注组件间的约定，并且，这些约定也都是基于类型的。不过，这也是两种约定的全部共同之处。
不同于COM，CLR自从问世以来，就有完全规范的格式描述组件之间的约定。这种格式一般称为元数据（metadata）。CLR元数据是机器可读的（machine-readable），其格式是完全规范的。此外，CLR提供了一些实用部件，使得程序员在不懂底层文件格式的情形下，就能够读写元数据。通过定
制特性（attribute；其本身就是强类型的），CLR元数据可以达到清晰容易的可扩展性。CLR元数据还包括组件的依赖关系和版本信息，这就允许使用一些新的技术来处理组件的版本控制问题。CLR元数据的存在是强制性的；你要部署或者加载组件，都必须访问元数据。同将元数据的存在作为可选项的环境（例如，COM）相比，构建基于CLR的基础架构和工具，显然要容易一些。
CLR约定与COM约定的第二个差别就是约定本身的特性。在COM中，组件约定暗示了堆栈约定、虚函数表，以及作为方法参数传递的数据结构在内存中的表示形式。在这方面，CLR和COM有着非常大的差异。
在CLR中，约定被描述为类型的逻辑结构。特别是，CLR约定不会描述任何数据的内存表示形式。CLR推迟确定有关内存的表示形式，直到在运行时类型被首次加载。约定的虚拟化（virtualization）很大程度上降低COM二进制约定所带来的不稳定性，这是因为组件间不存在任何内存表示形式的假设。
由于CLR类型定义是逻辑的，而不是物理的，因此，CLR的约定中并没有暗示访问字段或方法的精确的代码顺序。这样，在考虑虚方法布局、堆栈规则、对齐方式以及参数传递转换时，CLR具有极大的灵活性。并且，CLR的版本改变，不会带来组件的重新编译。因而，CLR通过名字与签名引用字段与方法，而不是偏移量。这样，CLR避免了困扰COM的声明顺序问题。成员的实际地址/偏移量需要等到在运行时类型被加载及初始化时才能够确定。
实现数据表示形式和方法地址的虚拟化有一个重要前提条件。由于约定的物理方面（例如，方法表/字段的位移量）在组件编译时都不知道，因此，就需要引进某种机制，延期这些位移量的解析，直到代码实际部署，以便在特定处理器构架中生成组件的最终版本。为了实现这个可能性，CLR的组件中几乎不包含机器代码，准确地说，基于CLR组件采用的公共中间语言[Common Intermediate Language(CIL)]用于他们的实现。
人们容易认为CIL只不过是个处理器无关（processor-neutral）的指令集，从而轻易地拒绝使用它。不过，即使只有一种处理器架构加入，CIL也是很重要的，这是因为CIL具有抽象能力，它将与机器代码密切关联的物理数据表示形式抽象出来。被CIL使用的操作码（opcode），在访问字段或调用方法时，不再使用绝对位移量或地址。准确地说，为了操作字段或方法，那些CIL会包含元数据的引用。这些引用只是基于字段或方法的名字与签名，而不是其位置或位移量。只要目标组件中存在与名字与签名匹配的字段或方法，CLR就没有必要选择物理位移量。
要注意，CLR不会直接执行CIL。准确地说，CIL在执行前总是被翻译为本机的机器语言。要么是在组件载入内存时，要么是组件被安装到部署机器上时，翻译就会被执行。无论哪种情况，当CIL到本机代码的翻译完成时，任何数据类型或方法的实际内存表示形式将被用于生成本机的机器代码，从而得到高效代码。
CIL生成的本机代码同样受益于高性能的物理耦合方式（physical coupling）,这也是C++和COM所采用的方式。然而，C++和COM在形式阶段就考虑这种物理耦合，而CLR在CIL到本机代码翻译发生之前，不会解析这种物理绑定的细节。由于翻译是在部署机器上翻译的，因此，部件以外所需的类型定义将与部署机器上的某个类型相匹配，而不是开发者的机器上。这极大的减少了跨组件约定的不可靠性，同时，又不降低性能。
最后，由于CIL到本机器代码的翻译发生在部署机器上，因此，任何用到的待定处理器布局或对齐规则（alignment rule）将与目标处理器架构（代码将在上面运行）匹配。软件也即将迎来另一个处理器迁移，即由现在的IA-32/Pentium架构向IA-64/Itanium架构发展。对于这次升级，CLR显得尤为重要。
DangerousWang 2003-12-24
- 打赏
- 举报
以下是转贴：希望能解答搂主的一些问题（我并没有全不理解我转贴所说的）
<<.Net 本质论>>第一章：
COM回顾
组件技术主要强调独立开发和部署的程序之间的约定（contract） 。组件对象模型[Component Object Mode(COM)]是Microsoft公司首次尝试将这些约定规范化。这样，它们既能作为设计范例（design paradigm），也能用作支持的平台技术（supporting platform technology）。COM的设计范例就是将组件约定表示为类型定义（type definition）。而在COM出现以前，约定仅仅表现为简单的函数入口点，于是COM从以前的世界跨出了一大步。在这个方面，COM是个重大的进步 ，它将动态加载代码和类型系统以相当一致的方式有机结合在一起。
COM编程模型本身极好地经受住了时间的考验。COM将很多现有的思想，例如，封装（encapsulation）、多态（polymorphism），以及接口与实现分离等等，融合进统一的编程规范，这在软件工程领域留下了不可磨灭的印记。这里，我不想重复阐述COM模型，有关内容你可以参考《Essential COM》或者《Design Patterns》（Erich Gamma等著，Addison-Wesley出版，1995年） 的第一章。尽管它们在表述上相差甚远，但本质上都是指相同的编程模型。
COM既是编程模型，也是支持的平台技术。对于后者，COM做得就不如我所喜爱的编程模型那样棒。遗憾的是，还需要一个稳固的平台技术，使COM不只是一个理念或者编程准则。正是因为这方面的原因，COM时代面临着终结。
多数COM平台的问题都能追溯到组件（component）间约定的本性上。在理想世界中，组件间的约定纯粹是通过用户与组件之间的语义保证和假设的形式表示的。不过，软件工程领域仍然要定义某种形式来表示语义，并且，它是已经被证明，对于大范围工业界的部署在商业上（或者技术上）是可行的。最接近的专业做法是采用可编程的类型定义，以及描述那些类型定义的人工可读的（human-readable）文档。这是COM以前的做法，也是最后一个COM组件消失后的做法 。
COM用类型的形式表示组件约定；不过，COM的组件约定存在两个关键问题，使得基于COM的约定技术对表示语义并不是最优的。其中，一个问题与COM约定的描述有关；另一个则与约定本身有关。
COM的第一个问题来自约定的描述。COM规范特别避免强制用于约定定义的交换格式。这意味着如果只遵循COM规范，就无法以标准化的方式描述约定；准确地说，COM规范假定约定的类型定义之间将通过完全是COM之外的某种技术进行交互。当然，这只有在规范的世界里才行之有效。为了使COM成为有用的技术，就需要具体的解决方案；否则，构建编译器、工具和支撑架构都是不可能的。
对于约定描述，Microsoft定义和支持的COM交换格式不是一个，而是两个：接口定义语言[Interface Definition Language(IDL)]和类型库[type library(TLB)]文件。这似乎没有什么问题；但是，两种格式并不是同构的（isomorphic）。也就是说，其中一种格式表示的结构，对另一种格式没有什么意义。更糟的是，某种格式所支持的结构无法成为其他格式支持结构的子集。因此，对约定描述而言，无法确定哪种格式是“权威的”或者“标准的”。
有人主张简单地定义第三种格式，并以它来支持其他两种格式都支持的所有构件。然而，在COM中，描述约定的方式还存在其他至少两个关键问题。其中一个就是COM没有描述组件的依赖性（dependency）。直到撰写本书时，还是没有办法解析COM组件（或者它的约定定义），以及确定它所需要的其他组件，以保证它的正确运行。由于缺乏相关信息，使得在部署基于COM的应用程序时，很难确定采用哪些DLL。此外，静态地确定需要哪个版本的组件也是不可能的，这使诊断版本问题变得极其困难。
第二个主要问题，也是敲响COM约定描述格式最终丧钟的，就是缺乏扩展性。早在九十年代，Microsoft事务服务器[Microsoft Transaction Server(MTS)]开发小组正致力于一种新的编程模型，它是基于现在被称为面向方面 [aspect-orient programming(AOP)]的编程思想。AOP获取非特定域（not domain-specific）代码的方面（aspect），并将它们从开发者的源代码中提炼出来。基于AOP的系统依赖于可选择的机制，用于声明它们的方面（aspect），从而使程序员的意图更加清晰，而不是隐晦的。
MTS小组希望开发者将他们对并发、事务以及安全的需求表示为方面（aspect），而不是API函数的调用。由于COM的广泛运用，MTS开发者采用增加COM约定描述的机制，用于表示这些方面。对于使用MTS的开发者，只要简单地通过特性（attribute）批注他们的COM类、接口和方法
定义，就能够通知MTS执行器（MTS executive）他们对底层代码的要求和假定。为了使这些特性有效，MTS执行器将取代COM加载器，并基于加载类的方面（aspect）插入侦听器。MTS侦听器（interceptor）[也称为上下文包装器(context wrapper)]将采用任何措施，确保在分发方法调用之前，满足开发者的要求。有趣的是，使用声明式的特性模型和侦听模型，后来演变为Enterprise Java Bean（EJB）的基础，这也说明了Sun Microsystems公司对MTS的认同。
遗憾的是，MTS小组并没有依赖任何一个COM约定格式，并将其作为传递和存储特性的可靠方式。其中的一种约定格式，接口定义语言（IDL）是基于文本格式的，极少随组件部署。并且，IDL通常只有C++开发者才会使用。然而，在MTS下开发企业应用的C++程序员数量相对较少，这使得基于IDL约定定义的用途不大。第二种格式类型库（TLB）文件，在扩展性方面也存在不成熟性（甚至缺陷）。然而，最终导致TLB没落的因素是Visual Basic的主流开发者无法直接影响TLB。准确地说，VB的IDE和编译器将开发者和TLB隔离了开来，这就导致了VB程序员在开发的过程中无法指定MTS特性。尽管VB5.0最后只是增加了对一种MTS特性（Transaction）的支持，但MTS小组还是要感谢VB小组，使得这项技术得以推广。由于VB小组有着自己的工作日程，MTS和COM小组只能从大局出发，最终考虑放弃TLB和IDL，而定义新的约定定义格式，它将以一种比TLB更简洁和更易于理解的方式来提供可扩展性。这个约定格式也将是本书所关注的焦点。
前面的讨论主要围绕组件约定的描述问题。然而，即使有一种很好的统一描述格式，在约定的工作方式上，COM也存在着根本问题。这是约定的描述方式所无法解决的，准确地说，是约定本身的问题。
COM组件约定是基于类型描述的。在这些约定中，所采用的类型系统是C++中被保证在编译器间可移植的一个子集。对于这种可移植性的保证，并不仅仅体现在语言层面，更进一步说，是在大多数现代编译器所采用的数据表示方面。然而，问题就出在这里。
COM的组件约定是物理的[(physical)；也被称作二进制(binary)约定]。这也就是说，COM对组件间的调用方式有着严格的要求。COM约定要求每一个方法都具有精确的vtable 偏移量。在调用方法时，COM约定要求使用明确的堆栈规则（例如，__stdcall）；COM约定强制命令作为方法参数传递的每一个数据结构的明确偏移量；COM约定强制命令具体使用哪一个分配器，用于为被调用者分配的内存；COM约定强制对象引用的明确格式[称为接口指针(interface pointer)]，包括被采用的vptr 和vtbl 的明确格式。就COM的底层技术而言，组件约定最终只是在内存中形成堆栈结构的协议，根本没有描述语义内容。
在COM中，组件约定的物理特性存在着缺陷。其中一个就是过度地关注细节，因为只有这样，才能确保正常工作。因而，COM成了难于使用的技术，甚至对那些很关注COM的开发者也是这样的。工具开发者试图隐藏COM的复杂性，但这反而增加了问题。这些可以从处理VB二进制兼容模式的VB程序员那里得到证实。
尤其在针对COM组件的版本控制上，其物理本性的问题就更大了。当必须要求进行语义修改时，版本控制就将成为十分棘手的难题。哪怕是vtable的次序或者字段的对齐这类很小的细节，都会导致运行时的错误，这些只使问题变得更糟。尽管在COM中，约定定义的精确性将产生高效的代码，但它是以难于接受的不可靠性为代价。
<<.Net 本质论>>第一章：
COM回顾
组件技术主要强调独立开发和部署的程序之间的约定（contract） 。组件对象模型[Component Object Mode(COM)]是Microsoft公司首次尝试将这些约定规范化。这样，它们既能作为设计范例（design paradigm），也能用作支持的平台技术（supporting platform technology）。COM的设计范例就是将组件约定表示为类型定义（type definition）。而在COM出现以前，约定仅仅表现为简单的函数入口点，于是COM从以前的世界跨出了一大步。在这个方面，COM是个重大的进步 ，它将动态加载代码和类型系统以相当一致的方式有机结合在一起。
COM编程模型本身极好地经受住了时间的考验。COM将很多现有的思想，例如，封装（encapsulation）、多态（polymorphism），以及接口与实现分离等等，融合进统一的编程规范，这在软件工程领域留下了不可磨灭的印记。这里，我不想重复阐述COM模型，有关内容你可以参考《Essential COM》或者《Design Patterns》（Erich Gamma等著，Addison-Wesley出版，1995年） 的第一章。尽管它们在表述上相差甚远，但本质上都是指相同的编程模型。
COM既是编程模型，也是支持的平台技术。对于后者，COM做得就不如我所喜爱的编程模型那样棒。遗憾的是，还需要一个稳固的平台技术，使COM不只是一个理念或者编程准则。正是因为这方面的原因，COM时代面临着终结。
多数COM平台的问题都能追溯到组件（component）间约定的本性上。在理想世界中，组件间的约定纯粹是通过用户与组件之间的语义保证和假设的形式表示的。不过，软件工程领域仍然要定义某种形式来表示语义，并且，它是已经被证明，对于大范围工业界的部署在商业上（或者技术上）是可行的。最接近的专业做法是采用可编程的类型定义，以及描述那些类型定义的人工可读的（human-readable）文档。这是COM以前的做法，也是最后一个COM组件消失后的做法 。
COM用类型的形式表示组件约定；不过，COM的组件约定存在两个关键问题，使得基于COM的约定技术对表示语义并不是最优的。其中，一个问题与COM约定的描述有关；另一个则与约定本身有关。
COM的第一个问题来自约定的描述。COM规范特别避免强制用于约定定义的交换格式。这意味着如果只遵循COM规范，就无法以标准化的方式描述约定；准确地说，COM规范假定约定的类型定义之间将通过完全是COM之外的某种技术进行交互。当然，这只有在规范的世界里才行之有效。为了使COM成为有用的技术，就需要具体的解决方案；否则，构建编译器、工具和支撑架构都是不可能的。
对于约定描述，Microsoft定义和支持的COM交换格式不是一个，而是两个：接口定义语言[Interface Definition Language(IDL)]和类型库[type library(TLB)]文件。这似乎没有什么问题；但是，两种格式并不是同构的（isomorphic）。也就是说，其中一种格式表示的结构，对另一种格式没有什么意义。更糟的是，某种格式所支持的结构无法成为其他格式支持结构的子集。因此，对约定描述而言，无法确定哪种格式是“权威的”或者“标准的”。
有人主张简单地定义第三种格式，并以它来支持其他两种格式都支持的所有构件。然而，在COM中，描述约定的方式还存在其他至少两个关键问题。其中一个就是COM没有描述组件的依赖性（dependency）。直到撰写本书时，还是没有办法解析COM组件（或者它的约定定义），以及确定它所需要的其他组件，以保证它的正确运行。由于缺乏相关信息，使得在部署基于COM的应用程序时，很难确定采用哪些DLL。此外，静态地确定需要哪个版本的组件也是不可能的，这使诊断版本问题变得极其困难。
第二个主要问题，也是敲响COM约定描述格式最终丧钟的，就是缺乏扩展性。早在九十年代，Microsoft事务服务器[Microsoft Transaction Server(MTS)]开发小组正致力于一种新的编程模型，它是基于现在被称为面向方面 [aspect-orient programming(AOP)]的编程思想。AOP获取非特定域（not domain-specific）代码的方面（aspect），并将它们从开发者的源代码中提炼出来。基于AOP的系统依赖于可选择的机制，用于声明它们的方面（aspect），从而使程序员的意图更加清晰，而不是隐晦的。
MTS小组希望开发者将他们对并发、事务以及安全的需求表示为方面（aspect），而不是API函数的调用。由于COM的广泛运用，MTS开发者采用增加COM约定描述的机制，用于表示这些方面。对于使用MTS的开发者，只要简单地通过特性（attribute）批注他们的COM类、接口和方法
定义，就能够通知MTS执行器（MTS executive）他们对底层代码的要求和假定。为了使这些特性有效，MTS执行器将取代COM加载器，并基于加载类的方面（aspect）插入侦听器。MTS侦听器（interceptor）[也称为上下文包装器(context wrapper)]将采用任何措施，确保在分发方法调用之前，满足开发者的要求。有趣的是，使用声明式的特性模型和侦听模型，后来演变为Enterprise Java Bean（EJB）的基础，这也说明了Sun Microsystems公司对MTS的认同。
遗憾的是，MTS小组并没有依赖任何一个COM约定格式，并将其作为传递和存储特性的可靠方式。其中的一种约定格式，接口定义语言（IDL）是基于文本格式的，极少随组件部署。并且，IDL通常只有C++开发者才会使用。然而，在MTS下开发企业应用的C++程序员数量相对较少，这使得基于IDL约定定义的用途不大。第二种格式类型库（TLB）文件，在扩展性方面也存在不成熟性（甚至缺陷）。然而，最终导致TLB没落的因素是Visual Basic的主流开发者无法直接影响TLB。准确地说，VB的IDE和编译器将开发者和TLB隔离了开来，这就导致了VB程序员在开发的过程中无法指定MTS特性。尽管VB5.0最后只是增加了对一种MTS特性（Transaction）的支持，但MTS小组还是要感谢VB小组，使得这项技术得以推广。由于VB小组有着自己的工作日程，MTS和COM小组只能从大局出发，最终考虑放弃TLB和IDL，而定义新的约定定义格式，它将以一种比TLB更简洁和更易于理解的方式来提供可扩展性。这个约定格式也将是本书所关注的焦点。
前面的讨论主要围绕组件约定的描述问题。然而，即使有一种很好的统一描述格式，在约定的工作方式上，COM也存在着根本问题。这是约定的描述方式所无法解决的，准确地说，是约定本身的问题。
COM组件约定是基于类型描述的。在这些约定中，所采用的类型系统是C++中被保证在编译器间可移植的一个子集。对于这种可移植性的保证，并不仅仅体现在语言层面，更进一步说，是在大多数现代编译器所采用的数据表示方面。然而，问题就出在这里。
COM的组件约定是物理的[(physical)；也被称作二进制(binary)约定]。这也就是说，COM对组件间的调用方式有着严格的要求。COM约定要求每一个方法都具有精确的vtable 偏移量。在调用方法时，COM约定要求使用明确的堆栈规则（例如，__stdcall）；COM约定强制命令作为方法参数传递的每一个数据结构的明确偏移量；COM约定强制命令具体使用哪一个分配器，用于为被调用者分配的内存；COM约定强制对象引用的明确格式[称为接口指针(interface pointer)]，包括被采用的vptr 和vtbl 的明确格式。就COM的底层技术而言，组件约定最终只是在内存中形成堆栈结构的协议，根本没有描述语义内容。
在COM中，组件约定的物理特性存在着缺陷。其中一个就是过度地关注细节，因为只有这样，才能确保正常工作。因而，COM成了难于使用的技术，甚至对那些很关注COM的开发者也是这样的。工具开发者试图隐藏COM的复杂性，但这反而增加了问题。这些可以从处理VB二进制兼容模式的VB程序员那里得到证实。
尤其在针对COM组件的版本控制上，其物理本性的问题就更大了。当必须要求进行语义修改时，版本控制就将成为十分棘手的难题。哪怕是vtable的次序或者字段的对齐这类很小的细节，都会导致运行时的错误，这些只使问题变得更糟。尽管在COM中，约定定义的精确性将产生高效的代码，但它是以难于接受的不可靠性为代价。
DangerousWang 2003-12-24
- 打赏
- 举报
<<<在.net中，装配件是CLR加载的最小单位。在一个项目中要调用其他装配件的服务，就必须先引用那个装配件，同时复制到本地bin内。>>>
可以就建立共享程序集。多个项目共享一个程序集
可以就建立共享程序集。多个项目共享一个程序集
gucs 2003-12-24
- 打赏
- 举报
没有接触过，等等高手回答
yoobj 2003-12-24
- 打赏
- 举报
C# Web服务高级编程——使用.NET REMOTING和ASP.NET创建Web服务 看看这本。
yoobj 2003-12-24
- 打赏
- 举报
用web servces和remoting
yuewang 2003-12-24
- 打赏
- 举报
坐下来学习
juqiang 2003-12-24
- 打赏
- 举报
胡言乱语，请多多指教！因为，偶也是初学，呵呵。
juqiang 2003-12-24
- 打赏
- 举报
com+组件的类型描述信息，是写在注册表中的，或者说“之前”，是在tlb中的。.net assembly很简单，全部放在metadata中了。
对于您说的assembly被load的时候，其实也是按照一定规则来的。首先，GAC，其次，local temp folder，最后，control指定的codebase的路径中，寻找*.dll/*.exe之类的（也是essential .net中的，我记不大清了）。从这点来看，也“相当”于位置”透明“的，至少，半透明的。
你说的最后一部分，跨appdomain的组件通信，是通过marshal的方式来作的，也是通过.net remoting实现的。
对了，楼上的，有没有essential.net的中文版？不过，看你paste的部分，好像翻译得比较滥，呵呵。
对于您说的assembly被load的时候，其实也是按照一定规则来的。首先，GAC，其次，local temp folder，最后，control指定的codebase的路径中，寻找*.dll/*.exe之类的（也是essential .net中的，我记不大清了）。从这点来看，也“相当”于位置”透明“的，至少，半透明的。
你说的最后一部分，跨appdomain的组件通信，是通过marshal的方式来作的，也是通过.net remoting实现的。
对了，楼上的，有没有essential.net的中文版？不过，看你paste的部分，好像翻译得比较滥，呵呵。
liyin_first 2003-12-24
- 打赏
- 举报
另外，哪位高人对com＋熟悉，推荐几本书，谢谢
liyin_first 2003-12-24
- 打赏
- 举报
to yoobj(老黑)
你所说的那本书，我已经看过，谢谢。
to DangerousWang(Everest)
我看的是don box的影印版<Essential .net>,可能由于英语上问题，还有思想境界没有达到一定高度，所以他的第一章的确看起来很吃力。其中有些东西还不能理解，只能记住，因为我现在还没有这么深的体验。
不知道，老兄有没有全书的电子版，我想同时看看这个中文版的，帮助一下理解。
你所说的那本书，我已经看过，谢谢。
to DangerousWang(Everest)
我看的是don box的影印版<Essential .net>,可能由于英语上问题，还有思想境界没有达到一定高度，所以他的第一章的确看起来很吃力。其中有些东西还不能理解，只能记住，因为我现在还没有这么深的体验。
不知道，老兄有没有全书的电子版，我想同时看看这个中文版的，帮助一下理解。
