在前面两篇文章中，我们了解了中间件的基本概念和中间件的主要技术分类，在这篇文章中我们了解下基于中间件的主流技术平台。
技术平台
现有的基于中间件的主流技术平台一般典型的应用是为三层/多层结构的分布式软件系统提供各种开发支撑，因为三层结构的分布式软件的核心为中间层，因此支撑主要集中在对中间层开发的支撑上，目前应该最广泛的技术平台有三类：
基于 OMG（ObjectManagement Group，对象管理组织）CORBA规范
基于 Sun JEE（JavaEnterprise Edition，Java 企业版）规范
基于Microsoft的Distributed interNet Applications (DNA) 2000规范、
OMG的CORBA
CORBA规范是OMG组织基于众多开放系统平台厂商提交的分布对象互操作内容的基础上制定的公共对象请求代理体系规范，用于开发和配置分布式应用的服务器端中间件模型的规范，让分布式应用程序中的远程对象可以相互通信，独立于系统平台和开发语言。
CORBA所基于的概念框架是对象管理体系结构（Object Management Architecture，OMA） ，OMA 描述了一个基于 CORBA的应用系统的基本结构与构成系统的构件的特性。
OMA的核心基础设施是象请求代理（ObjectRequest Broker，ORB），
，CORBA规范规定了ORB的标准体系结构。ORB 负责完成查找请求的对象实现、让对象实现准备好接收请求、传递构成请求的数据等完成远程调用时底层通信任务所需的全部机制
CORBA CCM(CORBAComponentModel)技术,是在支持POA的CORBA规范(版本2.3以后)基础上,结合EJB当前规范的基础上发展起来的。CORBA构件模型,是OMG组织制定的一个用于开发和配置分布式应用的服务器端中间件模型规范
CORBA的目标是支持多个层次的可互操作性，CORBA 规范经过多次改进与发展才达到这一目标。CORBA支持在可互操作性主要包括如下几个层次：
1、不同平台（如操作系统）与语言之间的可互操作性：这是早期的 CORBA版本强调解决的主要问题，解决方法包括制定IDL标准以及IDL到程序设计语言的映射。这使得使用同一供应商的 ORB 产品开发的客户程序与服务程序之间可以交互， 但使用不同供应商的ORB产品开发的客户程序与服务程序则未必是可互操作的。
2、不同厂商 ORB 产品之间的可互操作性：CORBA 2.0 版引入了GIOP 和 IIOP，从而实现了不同供应商的 ORB 产品之间的可互操作性，所有供应商的 ORB产品如果与 CORBA 2.0 兼容则彼此之间可互操作。
3、不同体系结构之间的可互操作性：更完善的可互操作性还应包括不同体系结构之间的可互操作， 例如一个CORBA对象可通过协议桥接操作一个DCOM对象，OMG通过引入ESIOP来解决这一问题。 但ESIOP只能解决CORBA与特定体系结构 （如DCOM）之间的互操作，并不能通过一套 ESIOP解决所有的问题。
关于CORBA的特点是大而全，互操作性和开放性非常好。CORBA的缺点是庞大而复杂，并且技术和标准的更新相对较慢，COBRA规范从1.0升级到2.0所花的时间非常短，而再往上的版本的发布就相对十分缓慢了。在具体的应用中使用不是很多。
Sun的J2EE
为了推动基于Java的服务器端应用开发,Sun于是在1999年底推出了Java2技术及相关的J2EE规范,J2EE的目标是:提供平台无关的、可移植的、支持并发访问和安全的,完全基于Java的开发服务器端中间件的标准。
在J2EE中,Sun给出了完整的基于Java语言开发面向企业分布应用规范,其中,在分布式互操作协议上,J2EE同时支持RMI和IIOP,而在服务器端分布式应用的构造形式,则包括了JavaServlet、JSP(Java Server Page)、EJB等多种形式,以支持不同的业务需求,而且Java应用程序具有"Writeonce,run anywhere"的特性,使得J2EE技术在发布计算领域得到了快速发展。
J2EE简化了构件可伸缩的、其于构件服务器端应用的复杂度,虽然微软的DNA也一样,但最大的区别是微软的DNA是一个产品,J2EE不是一系列产品，而是一个规范和标准,不同的厂家可以实现自己的符合J2EE规范的产品,J2EE规范,是众多厂家参与制定的,它不为Sun所独有,而且其支持跨平台的开发,目前许多大的分布计算平台厂商都公开支持与J2EE兼容技术。
J2EE的优点是,服务器市场的主流还是大型机和UNIX平台,这意味着以Java开发构件,能够做到"Writeonce,run anywhere",开发的应用可以配置到包括Windows平台在内的任何服务器端环境中去。
构件:Ejb技术
EJB是Sun推出的基于Java的服务器端构件规范J2EE的一部分,自从J2EE推出之后,得到了广泛的发展,已经成为应用服务器端的标准技术。Sun的EJB技术是在JavaBean本地构件基础上,发展的面向服务器端分布应用构件技术。EJB技术的推出,使得用Java基于构件方法开发服务器端分布式应用成为可能。
从企业应用多层结构的角度,EJB是业务逻辑层的中间件技术,与JavaBeans不同,它提供了事务处理的能力,自从三层结构提出以后,中间层,也就是业务逻辑层,是处理事务的核心,从数据存储层分离,取代了存储层的大部分地位。
从分布式计算的角度,EJB像CORBA一样,提供了分布式技术的基础。提供了对象之间的通讯手段。
从Internet技术应用的角度,EJB和Servlet,JSP一起成为新一代应用服务器的技术标准,EJB中的Bean可以分为会话Bean和实体Bean,前者维护会话,后者处理事务,现在Servlet负责与客户端通信,访问EJB,并把结果通过JSP产生页面传回客户端。
Microsoft DNA 2000
MicrosoftDNA 2000(Distributed interNetApplications)是Microsoft在推出Windows2000系列操作系统平台基础上,在扩展了分布计算模型,以及改造BackOffice系列服务器端分布计算产品后发布的新的分布计算体系结构和规范。
在服务器端,DNA2000提供了ASP、COM、Cluster等的应用支持。目前,DNA2000在技术结构上有着巨大的优越性。一方面,由于Microsoft是操作系统平台厂商,因此DNA2000技术得到了底层操作系统平台的强大支持;另一方面,由于Microsoft的操作系统平台应用广泛,支持该系统平台的应用开发厂商数目众多,因此在实际应用中,DNA2000得到了众多应用开发商的采用和支持。
DNA2000融合了当今最先进的分布计算理论和思想,如事务处理、可伸缩性、异步消息队列、集群等内容。DNA使得开发可以基于Microsoft平台的服务器构件应用,其中,如数据库事务服务、异步通讯服务和安全服务等,都由底层的分布对象系统提供。
但是它的不足是依赖于Microsoft的操作系统平台,因而在其它开发系统平台(如Unix、Linux)上不能发挥作用。
构件
DNA构件有COM(Component Object Model)/DCOM/COM+构件。
以Microsoft为首的DCOM/COM/COM+阵营,从DDE,OLE到ActiveX等,提供了中间件开发的基础,如VC,VB,Delphi等都支持DCOM,包括OLEDB在内新的数据库存取技术,随着Windows2000的发布,Microsoft的DCOM/COM/COM+技术,在DNA2000分布计算结构基础上,展现了一个全新的分布构件应用模型。
首先,DCOM/COM/COM+的构件仍然采用普通的COM(ComponentObjectModel)模型。COM最初作为Microsoft桌面系统的构件技术,主要为本地的OLE应用服务,但是随着Microsoft服务器操作系统NT和DCOM的发布,COM通过底层的远程支持使得构件技术延伸到了分布应用领域。DCOM/COM/COM+更将其扩充为面向服务器端分布应用的业务逻辑中间件。通过COM+的相关服务设施,如负载均衡、内存数据库、对象池、构件管理与配置等等,DCOM/COM/COM+将COM、DCOM、MTS的功能有机地统一在一起,形成了一个概念、功能强的构件应用体系结构。而且,DNA2000是单一厂家提供的分布对象构件模型,开发者使用的是同一厂家提供的系列开发工具,这比组合多家开发工具更有吸引力。
比较
针对上述的各种分布计算平台技术,都出现了相似且具有可比性的分布式构件,即CORBACCM(CORBA Component Model)技术、SUN的EJB(Enterprise JavaBean)技术和DNA2000中的COM/DCOM/COM+技术。
我们从集成性、可用性、可扩展性进行比较之前，先了解下这三个特性。
集成性主要反映在基础平台对应用程序互操作能力的支持上。它要求分布在不同机器平台和操作系统上、采用不同的语言或者开发工具生成的各类商业应用必须能集成在一起，构成一个统一的企业计算框架。这一集成框架必须建立在网络的基础之上，并且具备对于遗留应用的集成能力；
可用性要求所采用的软件构件技术必须是成熟的技术，相应的产品也必须是成熟的产品，在至关重要的企业应用中能够稳定、安全、可靠地运行。另外，由于数据库在企业计算中扮演着重要角色，软件构件技术应能与数据库技术紧密集成；
可扩展性，集成框架必须是可扩展的，能够协调不同的设计模式和实现策略，可以根据企业计算的需求进行裁剪，并能迅速反应市场的变化和技术的发展趋势。通过保证当前应用的可重用性，最大程度地保护企业的投资。
下表从集成性，可用性，可扩展性三个方面，给出了上述三种主流分布计算平台的比较结果。
表格
|
|
CORBA（CCM） |
Ejb |
DCOM |
| 集成性
|
|
|
|
| 跨语言性能 |
好 |
差（限于java） |
好 |
| 跨平台性能 |
好 |
好 |
差（限于windows） |
| 网络通讯 |
好 |
好 |
一般 |
| 公共服务构件 |
好 |
好 |
一般 |
| 可用性
|
|
|
|
| 事务处理 |
好 |
一般 |
一般 |
| 消息服务 |
一般 |
一般 |
一般 |
| 安全服务 |
好 |
好 |
一般 |
| 目录服务 |
好 |
一般 |
一般 |
| 容错性 |
一般 |
一般 |
一般 |
| 软件开发商支持度 |
一般 |
好 |
好 |
| 产品成熟性 |
一般 |
一般 |
好 |
| 可扩展性 |
好 |
好 |
一般 |
虽然这三种平台因为其形成的历史背景和商业背景有所不同，各自有自己的侧重和特点，其实在它们之间也有很大的相通性和互补性。目前许多平台都能实现EJB构件和CORBA构件的互操作。同EJB和CORBA之间相互之间方便的互操作性相比,DOCM和CORBA之间的互操作性要相对复杂些,因为商业利益的原因，在EJB和DCOM之间基本没有提供互操作方法。
后记
关于中间件的知识这篇文章就介绍到这里，下篇文章我们继续中间件的知识。