点评主流中间件技术平台z

无双

转过来的 中间件只接触过corba 其它没有接触 欢迎各位发表一下自己观点



conquerli（转载自天极网）　
引言
　　软件系统的复杂性不断增长、软件人员的频繁流动和软件行业的激烈竞争迫使软件企业提高软件质量、积累和固化知识财富,并尽可能地缩短软件产品的开发周期。于是集软件复用、分布式对象计算、企业级应用开发等技术为一体的"基于中间件的软件开发"(CBSD,Component Based Sortware Development)应运而生，这种技术以软件架构为组装蓝图,以可复用软件构件为组装模块,支持组装式软件的复用,大大提高了软件生产效率和软件质量。为此国风外对于这一技术的研究正在不断深入,同时大型的软件公司（例如sun,microsoft）及软件组织机构（OMG）都推出了支持中间件技术的软件平台。面对高深的中间件技术和繁多的软件平台，很多人感到很茫然和无从下手，本文简单介绍了中间件技术的发展和特点，重点阐述和比较了三大主流中间件技术平台，使读者对中间件技术有个全面的了解。
1 中间件技术的概念及发展
　　顾名思义，中间件是处于应用软件和系统软件之间的一类软件，是独立于硬件或数据库厂商（处于其产品的中间，实现其互连）的一类软件，是客户方与服务方之间的连接件，是需要进行二次开发的中间产品。
　　应该说，中间件技术是伴随网络而发展起来的一种面向对象的技术。以前的计算机系统多是单机系统，多个用户是通过联机终端来访问的，没有网络的概念。网络出现后，产生了Client/Server的计算服务模式，多个客户端可以共享数据库服务器和打印服务器等等。随着网络的更进一步发展，许多软件需要在不同厂家的网络产品、硬件平台、网络协议异构环境下运行，应用的规模也从局域网发展到广域网。在这种情况下，Client/Server模式的局限性也就暴露出来了，于是中间件应运而生。中间件是位于操作系统和应用软件之间的通用服务，它的主要作用是用来屏蔽网络硬件平台的差异性和操作系统与网络协议的异构性，使应用软件能够比较平滑地运行于不同平台上。同时中间件在负载平衡、连接管理和调度方面起了很大的作用，使企业级应用的性能得到大幅提升，满足了关键业务的需求。

无双

2　当前支持服务器端中间件技术的平台
　　考察当前主流的分布计算技术平台,主要有OMG的CORBA、Sun的J2EE和Microsoft DNA 2000。它们都是支持服务器端中间件技术开发的平台,但都有其各自的特点，将分别阐述如下。
2.1　OMG的CORBA
　　CORBA分布计算技术是OMG组织基于众多开放系统平台厂商提交的分布对象互操作内容的基础上制定的公共对象请求代理体系规范。
　　CORBA分布计算技术,是由绝大多数分布计算平台厂商所支持和遵循的系统规范技术,具有模型完整、先进,独立于系统平台和开发语言,被支持程度广泛的特点,已逐渐成为分布计算技术的标准。COBRA标准主要分为3个层次：对象请求代理、公共对象服务和公共设施。最底层是对象请求代理ORB，规定了分布对象的定义（接口）和语言映射，实现对象间的通讯和互操作，是分布对象系统中的"软总线"；在ORB之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务；最上层的公共设施则定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。目前,CORBA兼容的分布计算产品层出不穷,其中有中间件厂商的ORB产品,如BEAM3,IBM Component Broker,有分布对象厂商推出的产品,如IONAObix和OOCObacus等.
　　CORBA规范的近期发展,增加了面向Internet的特性,服务质量控制和CORBA构件模型(CORBA Component Model)。
　　Internet集成特性包括了针对IIOP传输的防火墙(Firewall)和可内部操作的定义了URL命名格式的命名服务(Naming Service)。
　　服务质量控制包括能够具有质量控制的异步消息服务,一组针对嵌入系统的CORBA定义,一组关于实时CORBA与容错CORBA的请求方案。
　　CORBA CCM(CORBA Component Model)技术,是在支持POA的CORBA规范(版本2.3以后)基础上,结合EJB当前规范的基础上发展起来的。CORBA构件模型,是OMG组织制定的一个用于开发和配置分布式应用的服务器端中间件模型规范,它主要包括如下三项内容:
　　a.抽象构件模型,用以描述服务器端构件结构及构件间互操作的结构;
　　b.构件容器结构,用以提供通用的构件运行和管理环境,并支持对安全、事务、持久状态等系统服务的集成;
　　c.构件的配置和打包规范,CCM使用打包技术来管理构件的二进制、多语言版本的可执行代码和配置信息,并制定了构件包的具体内容和基于XML的文档内容标准。
　　总之，CORBA的特点是大而全，互操作性和开放性非常好。CORBA的缺点是庞大而复杂，并且技术和标准的更新相对较慢，COBRA规范从1.0升级到2.0所花的时间非常短，而再往上的版本的发布就相对十分缓慢了。在具体的应用中使用不是很多。



2.2　Sun的J2EE


　　为了推动基于Java的服务器端应用开发,Sun于是在1999年底推出了Java2技术及相关的J2EE规范,J2EE的目标是:提供平台无关的、可移植的、支持并发访问和安全的,完全基于Java的开发服务器端中间件的标准。
　　在J2EE中,Sun给出了完整的基于Java语言开发面向企业分布应用规范,其中,在分布式互操作协议上,J2EE同时支持RMI和IIOP,而在服务器端分布式应用的构造形式,则包括了Java Servlet、JSP(Java Server Page)、EJB等多种形式,以支持不同的业务需求,而且Java应用程序具有"Write once,run anywhere"的特性,使得J2EE技术在发布计算领域得到了快速发展。
　　J2EE简化了构件可伸缩的、其于构件服务器端应用的复杂度,虽然DNA 2000也一样,但最大的区别是DNA 2000是一个产品,J2EE是一个规范,不同的厂家可以实现自己的符合J2EE规范的产品,J2EE规范,是众多厂家参与制定的,它不为Sun所独有,而且其支持跨平台的开发,目前许多大的分布计算平台厂商都公开支持与J2EE兼容技术。
　　EJB是Sun推出的基于Java的服务器端构件规范J2EE的一部分,自从J2EE推出之后,得到了广泛的发展,已经成为应用服务器端的标准技术。SunEJB技术是在Java Bean本地构件基础上,发展的面向服务器端分布应用构件技术。它基于Java语言,提供了基于Java二进制字节代码的重用方式。EJB给出了系统的服务器端分布构件规范,这包括了构件、构件容器的接口规范以及构件打包、构件配置等的标准规范内容。EJB技术的推出,使得用Java基于构件方法开发服务器端分布式应用成为可能。从企业应用多层结构的角度,EJB是业务逻辑层的中间件技术,与JavaBeans不同,它提供了事务处理的能力,自从三层结构提出以后,中间层,也就是业务逻辑层,是处理事务的核心,从数据存储层分离,取代了存储层的大部分地位。从分布式计算的角度,EJB像CORBA一样,提供了分布式技术的基础。提供了对象之间的通讯手段。
　　从Internet技术应用的角度,EJB和Servlet,JSP一起成为新一代应用服务器的技术标准,EJB中的Bean可以分为会话Bean和实体Bean,前者维护会话,后者处理事务,现在Servlet负责与客户端通信,访问EJB,并把结果通过JSP产生页面传回客户端。
　　J2EE的优点是,服务器市场的主流还是大型机和UNIX平台,这意味着以Java开发构件,能够做到"Write once,run anywhere",开发的应用可以配置到包括Windows平台在内的任何服务器端环境中去。

无双

2.3　Microsoft DNA 2000
　　Microsoft DNA 2000(Distributed interNet Applications)是Microsoft在推出Windows2000系列操作系统平台基础上,在扩展了分布计算模型,以及改造Back Office系列服务器端分布计算产品后发布的新的分布计算体系结构和规范。
　　在服务器端,DNA 2000提供了ASP、COM、Cluster等的应用支持。目前,DNA2000在技术结构上有着巨大的优越性。一方面,由于Microsoft是操作系统平台厂商,因此DNA 2000技术得到了底层操作系统平台的强大支持;另一方面,由于Microsoft的操作系统平台应用广泛,支持该系统平台的应用开发厂商数目众多,因此在实际应用中,DNA 2000得到了众多应用开发商的采用和支持。
　　DNA 2000融合了当今最先进的分布计算理论和思想,如事务处理、可伸缩性、异步消息队列、集群等内容。DNA使得开发可以基于Microsoft平台的服务器构件应用,其中,如数据库事务服务、异步通讯服务和安全服务等,都由底层的分布对象系统提供。
以Microsoft为首的DCOM/COM/COM+阵营,从DDE,OLE到ActiveX等,提供了中间件开发的基础,如VC,VB,Delphi等都支持DCOM,包括OLE DB在内新的数据库存取技术,随着Windows2000的发布,Microsoft的DCOM/COM/COM+技术,在DNA2000分布计算结构基础上,展现了一个全新的分布构件应用模型。首先,DCOM/COM/COM+的构件仍然采用普通的COM(Component Object Model)模型。COM最初作为Microsoft桌面系统的构件技术,主要为本地的OLE应用服务,但是随着Microsoft服务器操作系统NT和DCOM的发布,COM通过底层的远程支持使得构件技术延伸到了分布应用领域。DCOM/COM/COM+更将其扩充为面向服务器端分布应用的业务逻辑中间件。通过COM+的相关服务设施,如负载均衡、内存数据库、对象池、构件管理与配置等等,DCOM/COM/COM+将COM、DCOM、MTS的功能有机地统一在一起,形成了一个概念、功能强的构件应用体系结构。而且,DNA2000是单一厂家提供的分布对象构件模型,开发者使用的是同一厂家提供的系列开发工具,这比组合多家开发工具更有吸引力。
　　但是它的不足是依赖于Microsoft的操作系统平台,因而在其它开发系统平台(如Unix、Linux)上不能发挥作用。

无双

3　相关性比较分析
　　目前,针对上述的各种分布计算平台技术,都出现了相似且具有可比性的分布式构件,即CORBA CCM(CORBA Component Model)技术、SUN的EJB(Enterprise JavaBean)技术和DNA 2000中的COM/DCOM/COM+技术。
　　对于以上三个分布计算平台，本文采用业界常用的做法从以下三个方面进行分析：
　　集成性:集成性主要反映在基础平台对应用程序互操作能力的支持上。它要求分布在不同机器平台和操作系统上、采用不同的语言或者开发工具生成的各类商业应用必须能集成在一起，构成一个统一的企业计算框架。这一集成框架必须建立在网络的基础之上，并且具备对于遗留应用的集成能力；
　　可用性:要求所采用的软件构件技术必须是成熟的技术，相应的产品也必须是成熟的产品，在至关重要的企业应用中能够稳定、安全、可靠地运行。另外，由于数据库在企业计算中扮演着重要角色，软件构件技术应能与数据库技术紧密集成；
可扩展性:集成框架必须是可扩展的，能够协调不同的设计模式和实现策略，可以根据企业计算的需求进行裁剪，并能迅速反应市场的变化和技术的发展趋势。通过保证当前应用的可重用性，最大程度地保护企业的投资。
　　下表从集成性，可用性，可扩展性三个方面，给出了上述三种主流分布计算平台的比较结果。


虽然这三种平台因为其形成的历史背景和商业背景有所不同，各自有自己的侧重和特点，其实在它们之间也有很大的相通性和互补性。例如，EJB提供了一个概念清晰、结构紧凑的分布计算模型和构件互操作的方法,为构件应用开发提供了相当的灵活性。但由于它还处于发展初期,因此其形态很难界定。CORBA CCM是一种集成技术,而不是编程技术。它提供了对各种功能模块进行构件化处理并将它们捆绑在一起的粘合剂。EJB和CORBA在很大的程度是可以看作为互补的。这个适应WEB应用的发展要求,许多厂商多非常重视促进EJB和CORBA技术的结合,将来RMI可能建立在IIOP之上。CORBA不只是对象请求代理ORB,也是一个非常完整的分布式对象平台。CORBA可以扩展EJB在网络、语言、组件边界、操作系统中的各种应用。目前许多平台都能实现EJB构件和CORBA构件的互操作。同EJB和CORBA之间相互之间方便的互操作性相比,DOCM和CORBA之间的互操作性要相对复杂些,虽然DCOM和CORBA极其类似。DOCM的接口指针大体相当于CORBA的对象引用。为了实现CORBA和DCOM的互操作,OMG在CORBA3。0的规范中,加入了有关的CORBA和DCOM互操作的实现规范,并提供了接口方法。因为商业利益的原因，在EJB和DCOM之间基本没有提供互操作方法。

mygod

写文档的时候还没有.net构架呀，也没有TP monitor

无双

文章确实比较老 不过它说到的东西现在还在用着

其它技术也差不多

,net和dcom差不多吧mygod

mygod

.net和dcom不一样,甚至不兼容

sxf2000

[quote]原帖由 "mygod"].net和dcom不一样,甚至不兼容[/quote 发表：
   

对金蝶 公司的中间件APUSIC了解否？有什么看法吗？

mygod

不了解，你给介绍一下 ？

sxf2000

[quote]原帖由 "mygod"]不了解，你给介绍一下 ？ [/quote 发表：
   

呵呵，那我启不是成了金蝶公司的准销售了！有点资料可以介绍介绍
实现声明，没有商业目的，就是想了解它产品的应用到底如何，结果没人知道！：），别说我再推销！：）

摘抄=====================================

概述
从企业应用的开发、部署、运行到维护各个阶段，Apusic应用服务器2.0基于各种现有的被广泛接受的工业标准，包括J2EE™1.2和1.3规范、XML相关规范、数据交换以及各种安全方面的协议和标准，为企业应用提供了一个可靠、高效的开发、部署和维护的平台。
1.1. 基于工业标准和规范的解决方案
Apusic遵循的相关工业标准、规范和已实现的API如下：
1.1.1. J2EE™相关
•  JDBC™3.0及JDBC™2.0扩展
•  EJB™2.0
•  EJB™1.1
•  Servlets2.3
•  JSP™1.2
•  JMS1.0
•  JTA1.0
•  JCE1.2
•  JSSE
•  JavaMail™1.2
•  JAF1.0
•  JAXP1.1
•  JNDI
•  JMX
1.1.2. XML相关规范
•  XML1.0
•  XML Namespaces 1.0
•  SAX 2.0 API

•  DOM Level 2 Core Recommendation
•  XSL 1.0
1.1.3. Internet相关协议及标准
•  TCP/IP protocol family
•  HTTP 1.0
•  SSL 3.0
2. 服务器特性
除提供了对以上规范、标准的支持和对相关API的实现之外，Apusic提供了很多独有的极具竞争力的特性，致力于降低分布式多层企业应用的设计、开发、部署和维护成本，提高生产效率，而同时不影响企业应用遵循相关的标准和规范。
按照多层企业应用的分层方式，从以下三个层次概述Apusic应用服务器2.0的特性。
2.1. 表示层
多层应用模型中的表示层主要被用于与浏览器、桌面应用、无线设备及其他客户端的交互，Apusic应用服务器支持所有的客户机/服务器的交互机制。
在基于J2EE™编程模型的应用中，表示层主要使用JSP、Servlets 编程模型，对于Apusic应用服务器，还支持诸如Java Applets、Java Application或其他ActiveX组件的客户类型。
对于通过浏览器进行的Http请求，Apusic应用服务器提供了一个高效可靠的Web服务器。通过使用Servlet和JSP实例池、结果缓存、JSP编译调试工具等工具和技术，对于部署于服务器上的JSP和Servlet，Apusic应用服务器服提供了一个高效可靠的运行时环境和开发、部署和维护的高效易用的平台。
2.1.1. 对规范的实现
J2EE™1.3规范中包含了JSP和Servlet规范，通过使用JSP和Servlet规范，定义了J2EE企业应用中的表示层的编程模型。通过使用JSP和Servlet，实现Web内容的动态生成。
JSP与Servlet是紧密相关的两种编程模型，二者都生成动态的Web内容。不同之处在于Servlet使用JAVA语言编写，而JSP的编写还使用了HTML的扩展版本。对于使用HTML编辑器或设计器并熟悉HTML的Web设计者来说，JSP非常便利。而全部使用JAVA的Servlet更适用于JAVA程序员而非Web设计者。
Apusic2.0应用服务器中的Web服务器严格遵循了J2EE™规范中Servlets2.3规范和JSP1.2规范。
2.1.2. 增值特性
除了对J2EE相关JSP和Servlet规范的实现，Apusic应用服务器中的Web容器和相关工具还提供了一些增值特性，通过这些增值特性，使得面向Apusic应用服务器的表示层的开发、部署、运行和维护变得更加方便和高效。
•  虚拟主机
可以在单个的Apusic应用服务器上配置多个Web站点。通过域名与应用服务器的路径映射实现此功能，只需指定域名即可实现对站点的访问。
•  多路复用
Apusic 应用服务器采用了多路复用(multiplexing)通讯技术。在一个TCP/IP 连接上建立多个双向的虚拟连接，每个虚拟连接可以进行完全独立的通讯功能。通讯双方可以根据需要打开或关闭虚拟连接，进行通讯，实现了将多个服务统一到一个端口上，降低服务器的管理成本。
•  使用第三方Web服务器
除了Apusic应用服务器内置的Web服务器外 ，Apusic应用服务器可以与其他现有的Web服务器进行整合，如Apache、Microsoft IIS等，通过使用Apusic应用服务器提供的负载均衡功能，为企业应用提供一个更高可用性和伸缩性的平台。
•  负载均衡与失效恢复
Apusic应用服务器提供了基于Web层的负载均衡的功能。当使用Apusic作为集群中的负载均衡器时，服务器提供了独有的负载均衡和失效恢复的特性。
对于一个使用Apusic作为负载均衡器的服务器集群，当客户请求到达负载均衡器时，负载均衡器将请求转发到最初服务此请求的内部服务器，如果是初次请求，则负载均衡器随机选择集群中的任意一个内部服务器处理此请求；当内部服务器处理完请求，将产生的应答返回给负载均衡器，会话数据被保存在负载均衡器上；当下一个请求到达而原先处理该请求的内部服务器失效时，负载均衡器重新选择一个正常的内部服务器，这时会话数据连同请求一起被转发给新的内部服务器，会话数据被迁移到新的内部服务器。
此特性以较少的数据迁移量，较高的容错性，提供了基于Web层的负载均衡与失效恢复的增值特性。
•  JSPC工具
为提高表示层JSP的开发调试的效率，Apusic提供了一个简单易用的JSP命令行编译工具JSPC，通过此工具，开发者可以对JSP进行更为高效的开发和调试，通过设置相关调试工具，可以实现对JSP的源码级调试。
最有利的是，发布应用只需要发布编译好的jsp class，即可对jsp源代码提供保护，而不需要提供jsp源程序文件，以免因为其他原因暴露jsp的源文件，并且，在应用运行时，避免对jsp源文件进行编译以节省时间