常用构件标准

1、目前国际上， 分布式对象技术有三大流派 COBRA 、COM/DCOM 和 Java。 CORBA 技术是最早出现的， 1991年 OMG 颁布了 COBRA 1.0标准，在当时来说做得 非常漂亮；再有就是 Micr osoft 的 COM 系列，从最初的 COM 发展 成现在的 DCOM ，形成了 Microsoft 一套分布式对象的 计算平台； 而 Sun公司的Java平台，在其最早推出的时候，只提供了远程的方法调 用，在 当时并不能被称为分布式对象计算，只是属于网络计算里的 一种，接着推出的JavaBea n，也还不足以和上述两大流派抗衡，而 其目前的版本叫J2EE,推出了 EJB，除了

2、语言外还 有组件的标准以 及组件之间协同工作通讯的框架。于是，也就形成了目前的三大流 派。 应该说，这三者之中， COBRA 标准是做的最漂亮的。 COBRA 标 准主要分为 3 个层次： 对象请求代理、公共对象服务和公共设施。最底层是对象请求代理 ORB,规定了分布对象 的定义（接口）和语言映射，实现对象间的 通讯和互操作，是分布对象系统中的 “软总 线”；在 ORB 之上定义了 很多公共服务，可以提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种各样的服务；最上层的公共设施则定义了组 件框架，提供可直接 为业务对象使用的服务，规定业务对象有效协 作所需的协定规则。总之， CORB

3、A 的特点是 大而全，互操作性和开 放性非常好。目前CORBA的最新版本是2.3。CORBA 3.0也已基本 完成，增加了有关In ternet集成和QoS控制等内容。CORBA的缺点 是庞大而复杂，并且技术 和标准的更新相对较慢， COBRA 规范从 1.0 升级到 2.0 所花的时间非常短，而再往上的版本 的发布就相对十 分缓慢了。-相比之下，Java标准的制订就快得多，Java是Sun公司自己定的， 演变的很快。Ja va的优势是纯语言的，跨平台性非常好。Java分布 对象技术通常指远程方法调用（ RMI ） 和企业级 JavaBean（EJB）。RMI提供了一个Java对象远程调用另一

4、 Java对象的方法的能 力，与 传统 RPC 类似，只能支持初级的分布对象互操作。 Sun 公司于是基 于RMI，提出了 E JB。基于Java服务器端组件模型，EJB框架提供 了像远程访问、安全、交易、持久和生命 期管理等多种支持分布对 象计算的服务。目前，Java技术和CORBA技术有融合的趋势。 COM 技术是 Microsoft 独家做的，是在 Windows 3.1 中最初为支 持复合文档而使用 OL E 技术上发展而来，经历了 OLE 2/COM、 ActiveX、DCOM和COM+等几个阶段，目前COM+把消 息通讯模块 MSMQ 和解决关键业务的交易模块 MTS 都加进去了，

5、 是分布对象计 算的一个比较 完整的平台。 Microsoft 的 COM 平台效率比较高，同 时它有一系列相应的开发工具支持， 应用开发相对简单。但它有一 个致命的弱点就是 COM 的跨平台性较差， 如何实现与第三方 厂商的 互操作性始终是它的一大问题。 从分布对象技术发展的角度来看， 大 多数人认为 COM 竞争不过 COBRA。 目前我们经常谈到的分布式对象技术主要就是这 3 种，涉及到它的模型、规范、 标 准和实现。 3 种分布对象技术的详细比较可参见附 问：据说，国外软件厂商像 Oracle、Sybase、Lotus 等纷纷宣布其 软件产品中采用 了分布对象技术，并呈现出很好的应用势

6、头。那么， 分布式对象技术有哪些应用？如何 应用呢？有人说，我国在分布式 对象技术领域基本与国外处在同一起跑线下，您对此怎 么看？介绍 一下我国的情况，以及分布式对象技术的新进展。-答：Oracle、Sybase和Lotus等国外软件产商均在其主流产品中支持CORBA、EJB和DCOM技术以支持企业级应用和 Web应用，这 些产品在企业ERP和电子商务中均得到大量的应用。 分布对象技术在比较大型的网络系统中应用较多，比如像医学方 面的医学信息系统 、银行业、交通、电信，几乎各行各业都有成功 的例子，但在国内成功的比较少。 分布对象技术应用起来比较复杂， 因为这种软件通常都比较庞大， 涉及到网络

7、、对 象技术等多种技术，尤其是 COBRA ，系统开发比较 困难。分布式系统通常采用组合框架软 件(Component Software)方 法进行开发或集成，是基于软件体系结构的集成，只有特 殊需求的 组件才需要新开发， 与其他组件在集成框架下集成为一个整体。 当然 使用组合 框架软件进行分布式系统开发需要一整套方法、工具和平 台的支持COM+ 并不是 COM 的新版本，我们可以把它理解为 COM 的新发展，或者为 COM 更高层 次上的应用。 COM+ 的底层结构仍然以 COM 为基础，它几乎包容了 COM 的所有内容。有 一种说法这样认为， COM+ 是 COM、DCOM 和 MTS（M

8、icrosoftTransaction Server）的集成，这种说法有一定的道理，因为 COM+ 确实综合了这些技术要素。但更重要的一点是， COM+ 倡导了一种新的概念，它把 COM 组件软件提升到应用层而不再是底层的软件结构， 它通过操作系统的各种支持， 使组件对象模型建立在应用层上， 把所有组件的底层细节留给 操作系统，因此，COM+与操作系统的结合更加紧密， 这也是COM+非得等到 Windows 2000 发布才能面世的主要原因。我们知道， COM 是个开放的组件标准，它有很强的扩充和扩展能力，从 COM 到 DCOM ， 再到 MTS 的发展过程也充分说明了这一点。对 COM 有

9、使用经验的读者一定可以感觉到， 虽然 COM 已经改变了 Windows 程序员的应用开发模式，把组件的概念融入到 Windows 应 用中，但是由于种种原因， DCOM 和 MTS 的许多优越性还没有为广大的 Windows 程序员 所认识。 MTS 针对企业应用和 Web 应用的特点，在 COM/DCOM 的基础上又添加了许多功 能和特性，包括事务特性、安全模型、管理和配置等，MTS 使 COM 成为一个完整的组件体系结构。由于历史的原因， COM 、 DCOM 和 MTS 相互之间并不很融洽，难以形成统一 的整体，不过，这种状况很快就要结束，因为COM+ 将把这三者有效地统一起来，形成一

10、个全新的、功能强大的组件体系结构，并且把DCOM 和 MTS 的各种优势以更为简捷的方式带给 Windows 2000 程序员和用户。COM+ 不再局限于 COM 的组件技术，它更加注重于分布式网络应用的设计和实现，已经 成为Microsoft系统平台策略和软件发展策略的一部分。COM+继承了 COM几乎全部的优势，同时又避免了 COM实现方面的一些不足。COM+紧紧地与操作系统结合起来，通过系 统服务为应用程序提供全面的服务.从 COM 的发展角度来看， COM 最初作为桌面操作系统平台上的组件技术，主要为 OLE 服务。但是随着 Windows NT 与 DCOM 的发布， COM 通过底

11、层的远程支持使组件技术延伸到了分布式应用领域，充分体现了 COM 的扩展能力以及组件结构模型的优势。 MTS 为 COM 增添了许多新的内容，弥补了 COM 和 DCOM 的一 些不足，它注重于服务器一端的组件管理和配置环境。COM+ 进一步把 COM、 DCOM 和MTS统一起来，形成真正适合于企业应用的组件技术。COM+不仅继承了 COM、DCOM和MTS 的许多特性，同时也新增了一些服务，比如负载平衡、内存数据库、事件模型、队列 服务等。 COM+ 新增的服务为 COM+ 应用提供了很强的功能， 建立在 COM+ 基础上的应用程 序可以直接利用这些服务而获得良好的企业应用特性，去掉 MS

12、对于COM+华丽的包装，个人认为 COM+就是COM for Business.也就是特别为 商业改良的 COMCOM+ 相对于 Com来说，主要是增加 JIT,Connection Pool,QC,Auto Transaction（这是我自 己想出来的 ，就是自动事务支持 ），COM+ 的订阅功能和安全功能我认为还不够成熟 .COM+我认为最有用的就是自动事务支持功能，它使得编写分部式事务程序非常方便在以前要写出实现类似功能的代码非常麻烦JIT 通过在方法调用时 （而不是组件初始化时 ）执行数据库初始化操作 ,在方法调用完毕后立 即释放数据库连接 ,减少了 DBMS 服务器的并发连接 .这在

13、 web 服务中是相当有用的 ,很多时 候用户都是在浏览网页内容 ,真正需要访问数据库都是一瞬间而已,为那么多的未知用户保留数据库连接是很昂贵的 .连接池技术我没有用过 ,因为我一直使用 VB 开发 ,从来没有用过 C,COM+ 的连接池必须要 求组件必须为 MTA, 所以 VB 和 MFC 都不能使用这个功能我认为 QC 是一个很有趣的功能 ,通过队列系统 ,它减少了组件的并发数 ,而且 QC 提供了松 散的连接方式 ,加上它本身支持事务 ,使用 QC 来作为 SOAP 的后端是一个很好的做法 .COM+ 的订阅功能使得只要一次函数调用,就可以激发所有订阅者组件 .这是一个相当方便的功能 ,

14、对于商业上是相当实用的 （比如在开出送货单的同时 ,财务系统开始记账 ,业务系统开 始扣减库存 ,调度系统开始分析是否需要立即出车等等）.不过我认为目前 COM+ 的订阅系统还不够完善 ,限制太多 ,如果能够做成一个支持呼叫方式的订阅就更好了.比如可以支持非本机的部件订阅，或者发送通知给其他的基于Web的SOAP组件在其中再加上可编程的发送方法（比如通过编程来对不同的订阅者进行过滤和参数格式转换）.以及可以把正在运行中的组件实例作为订阅者 （这一点目前是可以做到的 ，但是需要把实例的 IUnknown 接口作为参数发 送，在 VB 中非常不方便 ）.呵呵 ，关于订阅发了这么多牢骚 ，有点离题了

15、 .其实上述所说的东西 自己也可以通过编程来做到 ，不过非常希望 MS 能够把它做到 COM+ 2.0 中.毕竟没有必要 每个人都去写一套这种东西 .COM+ 的安全机制是基于角色和规则的 现一个接口就可以知道当前的调用者是谁（类似于 NT4 里面的用户和组 ），程序代码中通过实，属于哪个组 .可以在 COM+ 中设置谁拥有哪个组件的调用权限 .不过我认为这在局域网还行 ，在 WEB 上面对那么多的 anonymous 就无能为力了 而且仅仅是基于 AD 的管理并不够 ，很多时候我们都习惯把企业内部的账号和权限信息放在DBMS 中，而且很多时候我们不仅仅是 "允许"或者是"拒绝"某个调用 （因为我们企业的规则不 可能正正好好和组件中的方法一一对应 ）.这使得现有的 COM+ 安全机制无法和我们业务系统 整合 ，几乎没有用 .ps:由于我对于COM+的安全机制研究并不深，如果有不当之处，还请指正最近看了 MS介 绍.NET Framework的安全机制，非常希望早日使用 VS.NET.ps again