下载掌阅APP，畅读海量书库
立即打开
3.2 常用构件标准
目前，国际上常用的构件标准主要有三大流派，分别是COM/DCOM/COM+、CORBA和EJB。
EJB（Enterprise Java Bean）规范由Sun公司制订，在EJB2.0规范中对EJB定义如下：EJB是用于开发和部署多层结构的、分布式的、面向对象的Java应用系统的跨平台的构建体系结构。使用EJB编写的应用程序具有可扩展性、交互性，以及多用户安全的特性。这些应用只需要写一次，就可以发布到任何支持EJB规范的服务器平台上。
虽然EJB似乎仅仅是Java Bean的企业版，但EJB绝对不是Java Bean的简单升级。Java Bean是Java语言中的一种构件模型，其重点是允许开发人员在开发工具中可视化的操作构件，Java Bean可以被集成到任何Java程序中，尤其是在Java Applet和Application中得到了大量的应用。而EJB是一种非可视化构件，EJB完全运行于服务器端。EJB可以和远程的客户端程序通讯，并提供一定的功能。如果EJB不和客户端程序交互，则不执行具体的功能。同Java Bean不一样的是，EJB仅仅在网络计算的环境下才有意义。
有三种类型的EJB，分别是会话Bean（Session Bean）、实体Bean（Entity Bean）和消息驱动Bean（Message-driven Bean）。
一个Session Bean描述了与客户端的一个短暂的会话。当客户端的执行完成后，Session Bean和它的数据都将消失。Entity Bean对应数据实体，它描述了存储在数据库的表中的持久数据。如果客户端终止或者服务结束，底层的服务会负责Entity Bean数据的持久性（也就是将其存储到某个地方，如数据库）；Message-driven Bean是EJB2.0新增的类型，它结合了一个Session Bean和一个Java信息服务（JMS）信息监听者的功能。客户把消息发给JMS目的地，然后JMS提供者和EJB容器协作，把消息发送给Message- driven Bean。
COM是微软公司为了计算机工业的软件生产更加符合人类的行为方式开发的一种新的软件开发技术。在COM构架下，人们可以开发出各种各样的功能专一的组件，然后将它们按照需要组合起来，构成复杂的应用系统。由此带来的好处是多方面的：可以将系统中的组件用新的替换掉，以便随时进行系统的升级和定制；可以在多个应用系统中重复利用同一个组件；可以方便地将应用系统扩展到网络环境下；COM与语言，平台无关的特性使所有的程序员均可充分发挥自己的才智与专长编写组件模块。
在此之后微软公司对COM进行了扩展，使其具备分布式的特性，即DCOM。DCOM使其能够支持在局域网、广域网甚至Internet上不同计算机的对象之间的通信。使用DCOM，应用程序就可以在位置上达到分布性，从而满足客户和应用的需求。因为DCOM是COM的无缝扩展，所以可以将对基于COM的应用、构件、工具，以及知识转移到标准化的分布式计算领域中来。在做分布式计算时，DCOM处理网络协议的低层次的细节问题，从而使我们能够集中精力解决用户所要求的问题。
DCOM是COM的进一步扩展，COM定义了构件和它们的客户之间互相作用的方式。它使得构件和客户端无需任何中介构件就能相互联系。客户进程直接调用构件中的方法。图3-8显示了DCOM的整体结构：COM运行库向客户和构件提供了面向对象的服务，并且使用RPC和安全机制产生符合DCOM线路协议标准的标准网络包。
DCOM具有位置独立性。DCOM使得构件的位置对你来说完全透明，无论它是位于客户的同一进程中或是在地球的另一端。在任何情况下，客户连接构件和调用构件的方法的方式都是一样的。DCOM不仅无须改变源码，而且无须重新编译程序。一个简单的再配置动作就改变了构件之间相互连接的方式。
DCOM具有语言无关性。任何语言都可以用来创建COM构件，并且这些构件可以使用更多的语言和工具。Java，Microsoft Visual C++，Microsoft Visual Basic，Delphi，PowerBuilder和Micro Focus COBOL都能够和DCOM很好地相互作用。
图3-8 DCOM ： 不同机器上的COM构件
COM+并不是COM的新版本，我们可以把它理解为COM的新发展，或者为COM更高层次上的应用。COM+的底层结构仍然以COM为基础，它几乎包容了COM的所有内容。有一种说法这样认为，COM+是COM、DCOM和MTS(Microsoft Transaction Server)的集成，这种说法有一定的道理，因为COM+确实综合了这些技术要素。但更重要的一点是，COM+倡导了一种新的概念，它把COM组件软件提升到应用层而不再是底层的软件结构，它通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统。
公共对象请求代理（Common Object Request Broker Architecture，CORBA）是由对象管理组织OMG制订的一个工业标准，其主要目标是提供一种机制，使得对象可以透明地发出请求和获得应答，从而建立起一个异质的分布式应用环境。
由于分布式对象计算技术具有明显优势，OMG提出了CORBA规范来适应该技术的进一步发展。1991年，OMG基于面向对象技术，给出了以对象请求代理（ObjectRequest Broker，ORB）为中心的对象管理结构。
在OMG的对象管理结构中，ORB是一个关键的通信机制，它以实现互操作性为主要目标，处理对象之间的消息分布。对象服务实现基本的对象创建和管理功能，通用服务则使用对象管理结构所规定的类接口实现一些通用功能。
针对ORB，OMG又进一步提出了CORBA技术规范，主要内容包括接口定义语言（Interface Definition Language，IDL），接口池（Interface Repository，IR），动态调用接口（Dynamic Invocation Interface，DII），对象适配器（Object Adapter，OA）等。
（1）接口定义语言。 CORBA利用IDL统一地描述服务器对象（向调用者提供服务的对象）的接口。IDL本身也是面向对象的。它虽然不是编程语言，但它为客户对象（发出服务请求的对象）提供了语言的独立性，因为客户对象只需了解服务器对象的IDL接口，不必知道其编程语言。IDL语言是CORBA规范中定义的一种中性语言，它用来描述对象的接口，而不涉及对象的具体实现。在CORBA中定义了IDL语言到C、C++、SmallTalk和Java语言的映射。
（2）接口池。 CORBA的接口池包括分布计算环境中所有可用的服务器对象的接口表示。它使动态搜索可用服务器的接口、动态构造请求及参数成为可能。
（3）动态调用接口。 CORBA的动态调用接口提供了一些标准函数以供客户对象动态创建请求、动态构造请求参数。客户对象将动态调用接口与接口池配合使用可实现服务器对象接口的动态搜索、请求及参数的动态构造与动态发送。当然，只要客户对象在编译之前能够确定服务器对象的IDL接口，CORBA也允许客户对象使用静态调用机制。显然，静态机制的灵活性虽不及动态机制，但执行效率却胜过动态机制。
（4）对象适配器。 在CORBA中，对象适配器用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便他们使用ORB内部的某些功能。这些功能包括服务器对象的登录与激活、客户请求的认证等。
CORBA体系结构模式充分利用了现今软件技术发展的最新成果，在基于网络的分布式应用环境下实现应用软件的集成，使得面向对象的软件在分布、异构环境下实现可重用、可移植和互操作。其特点可以总结为如下几个方面：
（1）引入中间件作为事务代理，完成客户机向服务对象方（Server）提出的业务请求。
（2）实现客户与服务对象的完全分开，客户不需要了解服务对象的实现过程，以及具体位置。
（3）提供软总线机制，使在任何环境下、采用任何语言开发的软件只要符合接口规范的定义，均能够集成到分布式系统中。
（4）CORBA规范软件系统采用面向对象的软件实现方法开发应用系统，实现对象内部细节的完整封装，保留对象方法的对外接口定义。