- 论坛徽章:
- 0
|
IBM WebSphere家族产品与BEA WebLogic家族产品比较
第一部、应用服务器篇
WebSphere App Server Vs. WebLogic App Server
第一章、产品概述5
一、软件技术发展5
1、传统两层次软件的缺陷5
2、三层次（或多层次）软件架构与中间件6
二、主要的中间件软件供应商8
1、IBM公司8
2、BEA公司8
3、其它厂商9
第二章、软件体系结构10
一、WEBSPHERE APPLICATION SERVER体系架构10
1、WebSphere体系架构图10
2、Application Server体系架构图11
3、应用程序架构图12
4、体系架构的特点总结13
二、WEBLOGIC SERVER体系架构14
三、WEBSPHERE与WEBLOGIC产品的对比15
第三章、软件支持标准18
一、操作平台18
1、WebSphere的平台支持18
2、WebLogic的平台支持19
3、平台支持的对比21
二、数据库支持21
1、WebSphere的支持22
2、WebLogic的支持22
3、数据库支持的对比22
三、WEB服务器支持23
1、WebSphere的支持23
2、WebLogic的支持24
3、Web服务器支持的对比24
四、浏览器支持25
五、JAVA平台25
1、WebSphere的支持25
2、WebLogic的支持26
3、Java支持的对比27
第四章、软件性能31
一、动态内容缓存（Caching Dynamic Content）31
二、垂直扩展性（VERTICAL SCALABILITY）31
三、水平扩展性（HORIZONTAL SCALABILITY）31
四、数据库存取技术（FASTER DATABASE ACCESS）32
第五章、总结33
一、J2EE标准33
二、产品安装33
三、配套集成工具34
四、性能和扩展性35
五、管理35
六、技术支持36
七、产品前景36
八、真的还是假的？36
附录：击破对手的谎言38
谎言#1：WEBSPHERE不提供“本机”JMS服务38
IBM38
WEBSPHERE v4计划39
BEA39
概要41
谎言#2：高速缓存能力41
谎言#3：WLM和群集能力43
谎言#4：状态会话EJB群集化和故障排除46
谎言#5：轻松使用和安装48
安装48
执行和系统管理49
谎言#6：CICS集成51
谎言#7：对于运行WEBSPHERE的每个平台要求使用IBM的JVM52
谎言8：WEBSPHERE中的JDBC支持53
谎言＃9：WEBSPHERE 的管理数据库是一个单独的故障点。54
第一章、产品概述
一、软件技术发展
1、传统两层次软件的缺陷
现代社会是一个信息社会，随着企业信息化程度的提高，企业信息系统对整个企业的日常运作、企业的发展发挥越来越大的作用。规划，设计，建设一个功能强大的，稳定的，安全可靠的信息系统对于企业是非常重要的。
在规划，设计企业信息系统时，需要考虑的主要是信息系统的基础架构，它的特点主要包括：
Ø先进性
Ø开放性，依从主流的技术标准
Ø安全性
Ø与现有系统的兼容性，异种系统之间的互连
Ø技术的成长性
Ø应用系统开发工具
随着信息技术突飞猛进的发展，我们突然发现已经存在的计算机软件远远跟不上我们的要求，尤其是目前大量使用的两层次的应用软件更是一个瓶颈，主要问题归纳为：
Ø部门协作使得信息通道多样，连接复杂，安全管理困难
Ø大量信息在各级,各地间共用
Ø各企业内，共用信息和私有信息并存
Ø将各种系统资源（数据库，消息传递服务器，邮件服务器）集成在一起
Ø快速反应，移动工作，要求随时，随地访问各种信息，相互通信
回顾以下大多数企业采用的技术，我们不难发现目前的企业信息系统应用架构主要以二层次（Two-tier）平台为基础，是面向数据的应用结构。其理想的应用程序环境是一百个客户端以下，通常只有一个数据源（RDBMS），提供基于局域网的连接，并只能提供较低的安全保障。在这种体系结构中，应用程序的界面和逻辑都放在客户端，从而对客户端的要求比较高。
从开发和维护的角度考虑，当超过100-150个客户端是，每个客户端的开销会呈非线形增长；当客户端的数量超过一定限度时，开发维护的代价会显著增长，单凭硬件升级，并不能解决问题。
当超过100-150个客户端时，每个客户端的开销会非线性增长。同时二层次的数据库系统互操作能力不强，会给部门和部门间带来许多应用限制。
在企业信息系统的系统中，登录点是大量的并来自各方面的。各个基层单位的查询点的计算机系统情况多种多样，要求有高效的查询能力和统一的界面。在传统意义上，这是很难实现的。企业业务工作的数据源是多种的，分布广泛的，数据量十分庞大，要做到快速查询和网上安全传输，对应用系统的体系结构要求比较高。同时，企业信息系统的系统还要求严格的保密性，信息按照保密级别严格分类，维护整体性、实用性、可扩展性和先进性的系统设计原则，
所以，不难看出，传统的二层次（Two-tier）的体系结构不适合企业信息系统的发展，我们必须实现新的、更适应要求的软件产品来满足企业的需要。
2、三层次（或多层次）软件架构与中间件
三层次的浏览器/服务器架构是基于Web的先进的体系结构，在这种架构中，利用成熟的Web应用服务器(WAS) 和事务处理服务器，为应用程序提供Web运行环境，数据资源和客户机将被“应用服务器”分隔开，应用服务器上存储着应用逻辑，这种结构着重于客户机对应用服务的请求，有别于二层次架构着重于数据请求。
其实，中间件是一个比较笼统的说法，顾名思义，我们可以将三层次架构的中间层的所有服务器软件统称为中间件，其主要的任务是响应客户端的请求，进行复杂的企业逻辑运算，访问企业的后台数据资源，生成满足客户需要的结果并返回给客户。除了这些基本功能之外之外，中间件软件还应该提供下面的功能：
Ø应用服务器为应用程序提供各种服务。
Ø程序加载、程序启动、内存管理、负载平衡、出错恢复及强大的应用管理功能
Ø高性能地处理大量并发访问，及时快速响应
Ø屏蔽异构平台，具有强大的和后台各种资源(应用系统，各种数据库) 的连接
在三层次结构中，客户端对数据源的直接访问被对应用程序的请求所替代，客户端访问的是应用程序，由应用程序对数据进行查询和存取，这样就能保证数据不被非法使用和篡改。目前我们比较多的是基于Web的三层次结构应用，一般以标准的TCP/IP网络为平台，可很好的与网络开发语言如Java等有效地集成，使异种资源的结合变得容易。同时，这种结构也提高了系统的性能，简化了用户的管理。
三层次的架构要求的初期投资比二层次的体系结构高，但是它具有极高的长期扩展性，随着客户数量、应用的复杂度的增加，开发和维护的费用基本上随之呈线形增长。三层次的架构浏览器/服务器架构着重于客户机对应服务的请求，而二层次架构仅局限于数据的简单请求。这些优点将有效地帮助企业信息系统实现近期和长远的目标.
二、主要的中间件软件供应商
1、IBM公司
成立于1911年的IBM（国际商用机器有限公司），在全球IT业中起着举足轻重的地位。2000年，在全球企业排名中，名列计算机界的第一位（全部企业排名中的第十九位），公司的年营业收入为八百多亿美元。做为一家有着极高声誉和技术力量的公司，IBM不仅在软件、硬件方面占有极高的市场份额，而且在服务、芯片制造等方面有着骄人的成绩。IBM的软件主要侧重于企业级产品，旗下有四个主要的软件品牌：DB2（数据管理）、WebSphere（应用中间件产品）、Lotus（群件产品）、Tivoli（管理软件）。
IBM在中间件上的投入（WebSphere），比其主要对手BEA公司全年的营业收入还多。1998年IBM全球雇员人数291067人，其中，JAVA研发人员超过3000人，WebSphere的研究人员超过700人。IBM提供的WebSphere Enterprise Edition，其中包括了WebSphere Application Server 和Component Broker等IBM自行开发的产品，可以为企业提供完整的电子商务解决方案。
2、BEA公司
成立于1995年，是世界主要的电子商务软件公司之一，以提供坚固的、经过严格测试的电子交易构架而著名。公司最初从Warburg-Pincus获得了5000万美元的风险投资，截至今年7月31日，公司的营业收入为3.4亿美元，其中，WebLogic的营业收入为1.22亿美元。由于公司规模较小，BEA的市场策略较为灵活，产品能及时转型使之更适应市场发展，在快速发展的Internet时代，抢占了市场先机。1999年，BEA公司重新定位，工作重心由纯交易平台(Tuxedo)调整为为电子商务交易提供平台支持(WebLogic)，增加可提供的技术组件，并通过与GSI、RSI、和WSI等合作伙伴合作获得利润增长。同时，BEA公司积极和许多硬件提供商结成战略性联盟，包括HP、Unisy、Bull、Compaq、IBM、NCR等。
BEA的电子商务交易平台由以下各部分组成：
ØWebLogic应用程序服务器
ØWebLogic交易与个性化服务器
Ø集成电子商务交易
Ø电子商务交易服务
严格地说，BEA公司并没有真正义上自己的产品，因为公司的策略是“从收购中获得增长”。在5年中，BEA已经收购了超过25个项目，其中包括：
Ø1995年收购Tuxedo;
Ø1996年收购MessageQ
Ø1998年收购Top End;
Ø1998年收购了WebLogic;
Ø1999年收购了Theory Center
事实上，Tuxedo作为BEA公司的核心产品，从技术上讲BEA也并不是其技术的主人。
Ø1989年，Tuxedo最初由AT&T开发；
Ø1990年，AT&T将其转给了UNIX Systems Labs (USL)开发维护；
Ø1993年，USL又将其出售给了Novell公司，这其中包括NEC等15个厂家获得Tuxedo license, 独立开发其平台上Tuxedo版本。
Ø1997年，BEA通过收购取得了对该产品的所有权。
BEA以Tuxedo为核心，通过结合一些独立的组件，如ObjectBroker, Jolt等来为客户构建整体解决方案，并且，同Tuxedo的获得一样，BEA公司提供的很多组件都是通过收购从第三方公司获得的，如从DEC购买了MessageQ和 ObjectBroker ORB；从 NCR购买了 TopEnd；从 WebLogic公司购买了WebLogic。
如此众多厂商的产品被整合在一起，一方面，用户不得不面对不同的厂商，另一方面，用户也不得不对如此众多的产品的集成性产生怀疑。
3、其它厂商
由于中间件市场的诱人前景，许多大的计算机公司纷纷投入力量争取市场份额，目前主要的公司有：
Oracle公司：
主要产品为Oracle Application 9i
Sun公司:
主要产品为iPlanet
BlueStone公司
SilverStream公司
另外，还有一些免费的中间件产品，如Tomcat、Resin等等，由于其本身的条件限制，很少在关键的企业应用中使用，更多的是用来学习和练习，对此我们不在做过多的介绍。
第二章、软件体系结构
目前市场上IBM公司的应用服务器以WebSphere3.5为核心，而BEA公司以WebLogic6.0为核心，两个产品的出处不同，自然体系结构也不尽相同。
一、WebSphere Application Server体系架构
1、WebSphere体系架构图
IBM公司提出的电子商务解决方案用以解决企业和企业在网上进行电子交易的构思。IBM公司非常理解在建立企业和企业间、企业和用户间交流信息和进行电子交易方面的战略意义和示范作用。IBM公司提供的产品都是经过了市场的考验。全球通过Internet进行电子购物的第一比交易就是由IBM帮助实现的。同时，IBM提供全面的、安全的、企业应用解决方案，提供端到端的工具，可以迅速的帮助用户构建适应自己需要的系统。
下面是IBM WebSphere的软件体系架构图
图2-1
在图2-1中，主要有以下四个主要组件：
1）Administrator Server：这是应用服务器的管理进程，由它来负责管理所有的应用服务器进程，其配置信息全部存放于关系数据库中（或者存放于明为Instant DB的文件中）
2）Administrative Console：这是管理服务器的操作界面。在这里，用户可以增加、删除WebSphere中的各种资源（应用服务器、企业应用、EJB容器、JDBC数据源等等），启动或停止应用服务器，对应用服务器做各种优化工作。WebSphere一共提供了四种监控方式：Java Console(完全是一个图形化的管理界面)；Browser Console（在浏览器中监控）；XML Config（通过XML来配置）；WSCP（命令行的监控方式）
3）Administrative Database：配置信息存储数据库
4）Application Server：应用服务器。它是所有应用逻辑的容器，负责中间件程序运行时的维护，其完全以Java程序为标准，提供高性能的、可伸缩的、安全的服务器端的运行时环境。
2、Application Server体系架构图
图2-1只是WebSphere的简单架构图，对于该图中的Administrator Server、Administrative Console和Administrative Database我们在这里不做过多的描述，我们重点在Application Server的结构上做进一步的介绍。
下图是Application Server的组件结构图
图2-2
可以看到,Applicaton Server主要有两个组成部分：EJB Container和Servlet Engine。其中，EJB Container负责EJB（Session Bean和Entity Bean）的运行时态的管理维护（Create、Active、Passive、Destroy等等）;Servlet Engine负责Servlet和JSP的运行管理（Init、Service、Destroy等等）。另外，在Application Server中，我们可以建立JDBC驱动程序、DataSource数据源、虚拟主机（Virtual Host）等等。所有这一切的管理信息都存在上面介绍的管理数据库中。
3、应用程序架构图
如果从应用的角度来讲，我们可以按照下面的方式来理解
图2-3
从图2-3可以看到，基于WebSphere的应用程序应该按照下面的方式来设计：表示逻辑关注于界面应用，它只是用户看到的显示部分，这一部分可能经常被改动，它不涉及企业的主要应用；商业逻辑封装所有的企业关键应用，这一部分是企业的核心应用，应该很少做改动；应用服务程序负责和后台数据源的连接，它屏蔽掉各种不同的数据源和网络协议。
4、体系架构的特点总结
不论从软件设计理念上讲，还是从软件产品上将，IBM都居于世界的前列。本着以客户第一的思想，WebSphere的体系结构满足客户的要求，我们可以从以下几个方面来阐述WebSphere的体系结构：
Ø先进性、稳定性：立足先进技术，产品具备国际领先的地位。WebSphere使用的是一种Nanny -- Administration Server -- Application Server 的体系结构，使用该结构，所有的Application Server(应用服务器)将由一个Adminisration Server(管理服务器)来监视管理，一旦由于一个特殊的原因（例如进程被杀掉）导致应用服务器停止，管理服务器将自动重新启动该应用服务器；同样，Administration Server(管理服务器)由一个“Nanny(保姆)”进程管理，该“保姆”进程一旦检测到管理服务器停止也将自动重新启动它。这样WebSphere从体系结构上就最大限度地保证服务器程序的可靠稳定运行。
Ø安全性：全面支持防火墙技术，隔离Internet，一方面可以防范公用网上非法用户的访问，另一方面可以防止中心的一些重要数据被不合法用户所获取。WebSphere包括两方面的安全管理：Security Plug-in和Security Collaborator，可以同时对Web静态资源和动态的资源进行安全认证管理。另外，WebSphere也支持第三方的安全认证管理。在网络安全性方面，IBM是业界的领导者，其遍布全球的大小网络从未被网络黑客非法入侵，其内部的资源也从未遭到黑客的窃取。IBM为客户所提供的齐全性的全面解决方案，使用户在后续的使用中可以高枕无忧。IBM公司本身就是最大网络系统使用者之一，其分布在全球150多个国家的近30万职员每天的联网办公就是其技术实力的最好说明和保证。
Ø可扩展性：所有产品均考虑到随着应用的逐步完善和逐渐增加，系统还能够进行不断扩展的要求。系统支持两方面的扩展：Vertical Scaling（垂直的）Horizontally Scaling（水平的）。使用垂直方式的克隆，可以让用户最大限度地利用机器的性能；使用水平方式的克隆，可以让用户扩展任意数量的机器，保证Clustering(集群的)工作方式顺利实施。
Ø集成性：IBM公司的软硬件系统之间可以方便地实现集成。使用户无需花费过多的精力从事于系统平台的集成，而将精力集中到应用软件的开发和推广中，从时间和进度上促进本项目的成功。集成的应用系统降低了系统维护的难度和要求，方便用户日后的应用和管理。
Ø标准性和开放性：在计算机领域内，有很多国际或行业标准是由IBM公司首创和建立的，因此IBM的产品始终严格遵守国际标准，在还没有形成标准的新领域内也积极倡导标准的形成。尤其是在XML、JAVA等的标准的制定和发展中，IBM起的作用也是有目共睹的。
二、WebLogic Server体系架构
BEA公司的WebLogic Server体系结构与WebSphere Applicaton Server不同，它只是一个大的守护进程，所有的应用服务程序都在该进程之内。可以这么说，WebLogic的作用与WebSphere服务器中的一个组件——Application Server（应用服务器）——类似，它并没有WebSphere中的管理进程和“保姆”进程。因此，从体系结构上说，WebLogic Server与WebSphere Application Server相比较有一定的差距和不足。一旦用户的服务器出现非正常的错误引起应用服务器的退出，那么用户再访问应用服务器的时候将出现错误。从体系结构上来说，WebLogic Server对于容错的处理能力远逊与WebSphere Application Server。
下面的图是从BEA公司的网站上截取下来的，用来说明WebLogic的体系结构，在此仅做一个参考。
.
图2-4
从图2-4可以看到，WebLogic与WebSphere有类似的体系结构，它也是将应用分成了三层：表示逻辑、商业逻辑和应用服务（因为该类产品都是基于J2EE的体系规范）。详细的请见对WebSphere的说明
三、WebSphere与WebLogic产品的对比
WebSphere和WebLogic都不仅仅是一个单一的产品，它们都是一个产品家族。但是由于公司的实力和发展战略不同，IBM WebSphere家族提供了比BEA WebLogic丰富许多的产品，涉及电子商务应用的各个方面
IBM是唯一的一家能提供全面的端到端的应用解决方案的公司，我们可以从下面的产品简介图来说明
图2-5
从图2-5我们可以看到，在IBM WebSphere家族中，产品涵盖了完成中间件功能的全部产品，所有的产品以WebSphere Application Server和MQSeries为核心，包括开发工具、表示工具、部署工具等，以及快速应用开发工具包。通过使用WebSphere家族产品，用户可以快速地开发出符合要求的应用产品，并且可以保证应用产品的安全性、伸缩性、易维护性。
与IBM公司的WebSphere家族产品比较起来，我们不难发现，BEA公司的WebLogic实在是逊色不少，请参见下面的图示
图2-6
比较图2-5和2-6，我们可以看到，除了最基本的应用服务器，BEA公司在开发工具方面只是提供了简单的Java开发工具；在表示工具方面，仅仅有一个个性化服务器应用软件可以使用；在部署工具方面，只有简单的两个工具可以使用（如果客户希望使用 IP负载均衡工具，BEA会建议使用IBM公司的Edge Server）。在应用快速开发环境中，BEA提供的产品也少于IBM公司提供的产品。因此，从产品的角度来讲，想要知道哪一个公司的产品更能满足市场的需要、更能给客户以最大限度的帮助，一个简单的比较就能分出优劣。
下面，我们总结一下两个公司产品的对比：
IBM中间件功能BEA
WebSphere Enterprise (前身是TXSeries)TP 监视器Tuxedo
WebSphere Enterprise (前身是ComponentBroker)CORBA/OTM/EJB服务器WebLogic Enterprise(前身是M3)
MQ Series消息队列Texedo(/Q)
MQ Integrator WebSphere B2B Integrator消息代理处理Enterprise Application Integration (eLink软件包)
MQWorkflow商业处理流程Enterprise Application Integration (eLink软件包)
WebSphere StandardWebShpere AdvancedWebSpher EnterpriseWeb 应用程序服务器WebLogic ExpressWebLogic StandardWebLogic Enterprise
VisualAge For JavaJava程序开发WebGain Studio (前身是VisualCafe)
VisualAge Generator应用开发无
WebSphere Studio 页面开发无
VisualAge Application Rule应用开发无
WebSphere Homepage Builder页面开发无
WebSphere Business Components组件解决方案Theory Center & Avitek Components ersonalization Server Commerce Server
WebSpher Every Place移动通信MCommmerce Server (BEA/Nokia 合伙伙伴)
WebSpher Voice Server语音无
WebSphere Commerce Suite交易BEA Commerce Server
WebSphere Portal Server门户服务无
WebSphere Personalization Server个性化服务Personalization Server
WebSphere Transcoding Publisher代码转换无
WebSphere Site Analyzer内容分析无
WebSphere Edge Server负载管理无
WebSphere Host Integrator主机集成无
第三章、软件支持标准
一、操作平台
1、WebSphere的平台支持
PlatformWebSphere 3.0.xWebSphere 3.5.x
Red Hat Linux----
Caldera Linux --
TurboLinux--
SuSe Linux--
IBM AS/400e with OS/400 V4R3----
IBM AS/400e with OS/400 V4R4----
IBM S/390 with OS/390 ----
IBM S/390 with Linux/390----
IBM/Bull RS/6000 with AIX 4.3----
IBM OS/2----
Intel Pentium-compatible with Windows 2000 Professional--
Intel Pentium-compatible with Windows 2000 Server/Advanced Server--
Intel Pentium-compatible with Windows NT 4.0----
Hewlett-Packard HP/9000 with HP-UX 10.20----
Hewlett-Packard HP/9000 with HP-UX 11.0--
Novell Netware----
Sun Microsystems SPARC with Solaris----
Sun Microsystems Sparc with Solaris 2.6----
2、WebLogic的平台支持
PlatformWebLogic 6.0.xWebLogic 6.1.x
Compaq Alpha with Tru64 UNIX6.0--
Compaq OpenVMS----
Compaq NonStop Himalaya----
IBM AS/400e with OS/400 V4R3----
IBM AS/400e with OS/400 V4R4----
IBM S/390 with OS/390 6.0--
Bull/IBM RS/6000 with AIX 4.2----
Bull/IBM RS/6000 with AIX 4.36.0--
IBM Dynix/ptx----
Intel Pentium-compatible with Windows 2000 Professional6.06.1
Intel Pentium-compatible with Windows 2000 Server/Advanced Server6.06.1
Intel Pentium-compatible with Windows NT 4.06.06.1
Intel Pentium-compatible with Windows 98----
Intel Pentium-compatible with Red Hat Linux6.0--
Hewlett-Packard HP/9000 with HP-UX 10.20----
Hewlett-Packard HP/9000 with HP-UX 11.06.0 (11i is also supported with WLS 6.0)6.1
SCO Unixware----
Siemens MIPS with Reliant UNIX 5.44C----
Silicon Graphics with IRIX----
Sun Microsystems SPARC with Solaris6.06.1
Sun Microsystems Sparc with Solaris 86.06.1
3、平台支持的对比
如果我们细心地一一对比上面的内容，我们会发现二者对于支持操作系统的总数是差别不大的：WebSphere对于Linux有着更多的支持，这也是软件发展的一个大趋势；而WebLogic对于Compaq的Unix有较多的支持，但是，不要忘了，连Compaq公司自己也要慢慢地淘汰其Alpha机器。
所以说，如果只从操作系统上来将，二者的差别不是很大，对于主流的操作系统（Windows、Unix）都比较完备的支持
二、数据库支持
1、WebSphere的支持
PlatformWebSphere 3.0.xWebSphere 3.5.x
IBM DB2 6.1 Fixpack 4----
IBM DB2 7.1--
Oracle 8.1.6--
Oracle 8.0.5--
Sybase 12.0--
Instant DB----
WebSphere不但支持当前主流的关系数据库，而且可以存放在文件系统中（Instant DB）。这样，用户可以对自己的配置信息高枕无忧，同时有可充分利用数据库的优化能力来提高自己的性能；而对于那些没有数据库产品的用户，也可以选择存放在文件系统中，保证中小用户的利益。
2、WebLogic的支持
非常遗憾，WebLogic只是简单的将配置信息存放在文件系统中，根本没有办法充分地保证配置信息的安全性和高性能。
3、数据库支持的对比
产品支持的孰优孰劣一目了然，不用再过多的解释，优胜者当然是IBM的WebSphere
三、Web服务器支持
1、WebSphere的支持
PlatformWebSphere 3.0.xWebSphere 3.5.x
IBM HTTP Server Version 1.3.6.2--
IBM HTTP Server Version 1.3.12--
Apache Server Version 1.3.6--
Apache Server Version 1.3.12--
Domino Version 5.0----
Lotus Domino Go Webserver Version 4.6.2.5 or 4.6.2.6--
Microsoft Internet Information Server Version 4.0--
Microsoft Internet Information Server Version 5.0--
Netscape Enterprise Server Version 3.51 or Version 3.6--
Netscape Enterprise Server Version 4.0--
WebSphere支持当前主流的Web服务器，而且在WebSphere中提供了一个Web服务器：IBM HTTP Server，方便用户的使用。
2、WebLogic的支持
PlatformWebLogic 6.0.xWebLogic 6.1.x
Apache Server Version 1.3.9--
Apache Server Version 1.3.12--
Microsoft Internet Information Server Version 4.0----
Microsoft Internet Information Server Version 5.0----
Netscape Enterprise Server Version 3.6----
Netscape Enterprise Server Version 4.0----
WebLogic内嵌了一个Web服务器，可以不用安装其他的Web服务器；支持当前主流的Web服务器。
3、Web服务器支持的对比
WebSphere支持的Web服务器类型多于WebLogic，但WebLogic自己内嵌了一个Web服务器。因此，在这一方面，二者可以说旗鼓相当。
四、浏览器支持
只要是支持HTML 4 and Cascading Style Sheets 的浏览器即可，例如Netscape Navigator 4.07或者Microsoft Internet Explorer 4.01等等。在此方面，二者类似
五、Java平台
不论WebSphere还是WebLogic，都是基于J2EE的标准研制开发出来的应用服务器。而J2EE中的标准又非常多，变化很快。因此，不论WebSphere还是WebLogic实现的标准都会低于J2EE的最新的标准。
1、WebSphere的支持
SpecificationVersionWebSphere
Java Servelt2.2Yes
Java Server Page1.1Yes
Enterprise JavaBeans1.1Yes
JTA/JTS1.0Yes
Java Database Connectivity2.0Yes
Java Message Service1.0Yes
Java Naming Directory Interface1.2Yes
RMI/IIOPYes
JavaMail/JAFYes
Java ConnectorYes
SSL SecurityJCEYes
J-IDL/CORBAYes
XML DOM/SAXYes
SQL-JYes
2、WebLogic的支持
SpecificationVersionWebSphere
Java Servelt2.2Yes
Java Server Page1.1Yes
Enterprise JavaBeans2.0Yes
JTA/JTS1.0Yes
Java Database Connectivity2.0Yes
Java Message Service1.0Yes
Java Naming Directory Interface1.2Yes
RMI/IIOPYes
JavaMail/JAFYes
Java ConnectorYes
SSL SecurityJCEYes
J-IDL/CORBAYes
XML DOM/SAXYes
SQL-JYes
3、Java支持的对比
如果只是简单的将产品对J2EE的支持版本一一列出，我们可能发现两个产品好象区别不是很大。但是如果仔细分析一下二者细微的区别，我们会有许多有趣的发现：
1）Enterprise JavaBeans：EJB当前最新的版本是2.0。在WebSphere中，全部支持EJB1.1的规范，对于2.0中的规范支持大多数。而BEA号称全部支持2.0的规范。如果仅从版本号来看，好象BEA占了一些优势，其实不然。我们首先应该明白EJB到底是做什么用的。EJB是面向分步式应用、面向分布式事物处理的Java规范。如果我们回顾计算机应用的发展历史，会发现IBM在分步式应用、面向对象的理论、数据库的处理（无论关系型还是非关系型）等面向大规模的企业应用处理方面有着举足轻重的地位。IBM不但最早发明了关系数据库——DB2，而且有业界最早、应用最广泛的事物处理中间件——TXSeries（即CICS）。IBM承诺的是给用户提供稳定、可靠的产品，而不是一味地追求版本的变化。在J2EE的规范制定中，IBM参与了其中80%的技术工作，尤其是在关键的领域：JTA/JTS、EJB、Java Connector等方面。另外一个方面，IBM提供了强大的EJB开发、测试、部署工具——VisualAge For Java Enterprise Edition。它能帮助用户最快地开发出满足自己需要的EJB。为了简化EJB的开发，IBM提供了强有力的封装工具——Access Bean。反观BEA，对于J2EE规范的制定并没有做出什么贡献，虽然号称支持EJB2.0，但是它并不真正支持两阶段提交！而且不提供对CICS、IMS、SAP等主机资源CMP（Container-Managed Persistence）类型的EJB的支持；在WLS中的EJB不能参与WLE中EJB的事物，引起不要的重复工作；其提供的Java开发工具WebGain提供了一个很弱的EJB开发环境；不提供产品级的RMI/IIOP支持。
2）RMI/IIOP：该标准在EJB 1.1中是可选项，但在EJB 2.0中是必须实现的规范。IBM在WebSphere中提供了牢固的产品来完全支持，IBM的产品从JDK1.1.7就开始使用RMI/IIOP，已经有进两年的时间，有很多成功的应用。BEA没有产品级的支持，在WebLogic中仅有一些有限的实现，它强迫用户使用其私有的协议——T3，因为它的速度比WebSphere慢了将近4倍，在其clustering中根本不能使用IIOP!
3）JTA/JTS：JTA（Java Transaction API）提供了标准的事物划分接口。IBM提供了JTA/JTS规范的多数工作，有许多实际的应用在使用。在WebSphere中提供了全面的支持（对多个数据库实例），WebSphere AE版支持复杂的异构环境下的两阶段提交方式，例如对DB2、DB2/390、Sybase、Oracle、MSSql、 JMS/MQSeries（Informix），WS EE版支持DB2、Oracle、Informix、CICS、IMS、DB2/390、MQSeries环境下的两阶段提交；WS AE版和EE版能在一个全局事物中实现双向的交互工作(包括WS 390)。BEA提供了不是非常成熟的支持，不能在WL Server和WL Enterprise之间完成一个事物，而且必须使用EJB 2.0测试版来完成两阶段提交。
4）Java Connector Architecture：JCA规范的指定可以说完全是IBM的工作成果。IBM Common Connector Framework （CCF）在J2EE 1.3 Connector Architecture中作为缺省的属性。WS/VAJ在许多产品中实现了CCF，在WS v4 和VAJ中将完全实现J2EE Connector，J2EE Connector可以支持对大多数的资源的存储，如CICS、SAP R/3、PeopleSoft、JDEdwards和Oracle Applications ，可以方便地从CCF升级到JCA（CICS和SAP R/3），在WebSphere中提供了包括CICS和IMS的分步式两阶段提交支持。BEA在2001年的二月巡捕支持JCA的测试版，只支持“no transaction”的JavaBean，对于后台的传统资源不支持属性上下文。
5）Java Message Service：IBM通过MQSeries提供完全的JMS支持。MQSeries占据全球消息中间件的72+%的市场份额，可以说JMS是MQSeries的一个子集。WebSphere支持跨EJBs和JMS的JTA，允许一个事物横跨多个WebSphere Application Server，多个Database，多个JMS。MQSeries有很好可扩充性和可用性，有超过30多个平台的支持。同时IBM VisualAge for Java支持JMS和MQSeries 的开发，并且在WebSphere中可以使用第三方的JMS产品。BEA提供有限的和未经很多应用验证的支持，在WebLogic版本6的文档中声明JMS是一个新的，仍然不适合用于产品级，只允许在WebLogic JMS到WebLogic JMS之间的通信；BEA在消息中间件的市场份额很低，最近BEA取消了其产品MessageQ！可以毫不夸张地说，只有IBM的消息中间件才是正确的选择！
6）J-IDL/CORBA：IBM提供10个CORBA服务的支： Naming、Transaction、LifeCycle、Security、Event、Notification、Externalization、Identity、Concurrency、Query，IBM对OMG（CORBA规范的制定组织）的发展做了巨大的贡献，许多规范的制定都有IBM的工作；BEA的WLE只有有限的5个服务支持：Naming、Transactions、LifeCycle、Security、Initialization，对于CORBA的发展没有什么贡献和投资。
7）Java Server Page：IBM WebSphere支持JSP 0.91、1.0和1.1；BEA WebLogic支持JSP 1.0和1.1
8）Servlet API：IBM WebSphere支持Servlet API 2.1和2.2；BEA支持Servlet API 2.2
总结上面的分析，我们可以作出下面的总结：
SpecificationIBMBEA
Java ServeltGoodGood
Java Server PageGoodGood
Enterprise JavaBeansExtensiveExtensive
JTA/JTSBest + provenGood + new
Java Database ConnectivityGoodGood
Java Message ServiceBest + provenLimited + unproven
Java Naming Directory InterfaceGoodGood
RMI/IIOPGoodPoor
JavaMail/JAFCommonCommon
Java ConnectorGoodPoor
SSL SecurityJCECommonCommon
J-IDL/CORBAGoodPoor
XML DOM/SAXBestLimited
SQL-JCommonCommon
第四章、软件性能
一、动态内容缓存（Caching Dynamic Content）
众所周知，应用服务器最大限度地重用缓存中的内容，不需要重新生成客户想要的内容对于提高服务器的性能有着多么重要的意义。长期以来，该技术只是简单地用于静态的HTML页面。但是，这种局限在在IBM WebSphere 3.5.3中终于被打破了。IBM WebSphere 3.5.3不但可以提供传统意义上的静态内容的缓存，也可以实现动态生成内容的缓存。
通过在服务器上设置一定的规则，WebSphere能生成基于JSP或者Servlet的内容缓存。用户的请求不必要重新生成，可以从缓存中直接返回到客户端。这样，极大地提高了服务器的吞吐量，减少了服务器的负载。
在服务器端缓存内容的规则设置通过设置一个间隔时间来实现。这个参数通过对Servlet、JSP设置一个有效时间来决定内容缓存的持续时间。
该功能目前在IBM WebShere 3.5.3中已经实现，但是，BEA WebLogic Server没有实现这个功能。
二、垂直扩展性（Vertical Scalability）
IBM在开发和提供多CPU的系统的应用上有非常长的历史和高的信誉。同样，在WebSphere平台中，IBM也提供了对于多CPU环境和多JVM环境性能的支持。在SMP环境下，IBM WebSphere Application有着比BEA WebLogic Server好很多的性能。在一个小的SMP环境下（1-4CPU），无论是WebSpher还是WebLogic都能很好地利用CPU。然而，如果我们增加CPU的数量，WebSphere可以继续充分地利用CPU，但WebLogic对CPU的利用率在6CPU时就有减少，在12CPU时达到顶峰。这一现象与JVM无关，是WebLogic自己内部的问题。
IBM提供在多平台上JVM的性能优化技术，例如Windows、Linux等平台上。这是因为WebSphere采用了IBM的专利技术“inmulti-cpu environments”，在各个平台上都可实现。因此，在多节点、多处理器的环境下IBM WebSphere Application Server比BEA WebLogic Server性能好很多。
三、水平扩展性（Horizontal Scalability）
在Web Application中，保护和维持一个“会话”的状态的能力十分重要。“会话”允许应用保持当前用户的信息，提供一个虚拟的常连接状态。为了提供良好的可扩展性和高的性能，许多Java应用服务器提供了克隆（Cloning）或者聚簇（Clustering）功能来实现单一的实体。在这种环境里，不能保证用户下一个请求的信息被哪一个聚簇服务器响应。因此，“状态”或者说是“Session（会话）”的作用在这种环境里就十分重要了。
IBM聚簇会话管理依赖于稳定的数据库技术。所有参与聚簇的服务器都将信息存放在一个共享的数据库中。所有会话的信息的持续性通过数据库来保证。当一个会话的信息发生改变的时候，它将存放在数据库中，立即可以被参与聚簇的其它的服务器使用。如果其中的一个服务器发生了异常引起死机，存放在数据库中的会话信息不会丢失。这样，WebSphere最大限度地保证了会话的正确状态，保证客户应用的正常处理。
BEA WebLogic服务器采用多点传送（Multicast）的途径来更新一个会话的信息，这种方式有几个致命的缺陷：第一，在一个聚簇的环境里，如果一个服务器发生了异常情况，引起非正常的死机，但是它在其退出之前并没有将信息广播出去，那么该服务器上最新的会话信息将丢失，不能被其它服务器使用；第二，网络的负载将大大增加，采用该种方式将产生大量的广播数据和会话数据在网络中传递，必然降低网络的性能；第三，依赖频繁的广播来更新会话的的内容，当前会话的数据不能够迅速地被其它服务器使用，其结果就是旧的或不正确的信息在后来的请求中被使用。
四、数据库存取技术（Faster Database Access）
在现在的Web应用中，一个程序往往要和数据库频繁的到交道。存取数据库的能力往往也是应用的一个瓶颈。因此，快速有效地存取数据库对应用就显得十分重要了。一个Java程序执行Web应用时，它已经是被编译好的程序。但是一个SQL语句要在程序运行的时候才被数据库服务器编译执行。每当一个数据库请求被执行时，相关的SQL语句必须被编译一次。这也是应用效率高低的一个重要因素。
IBM WebSphere Application Server包含了强大的数据源管理功能和连接池的技术（Connection pooling）。在数据源的管理中，WebSphere提供了一种SQL的缓存叫做“准备好的语句（Prepared Statements）”。Prepared Statements在SQL语句中是指预先编译好的SQL语句。当有数据库存取的请求时，WebSphere中的数据源管理会充分利用缓存中的预先编译好的SQL语句，忽略对SQL语句的重新编译的请求。这对于提高应用的性能有极大的好处，尤其是应用中有许多相同的SQL语句的时候效果就更明显。但是，BEA WebLogic服务器没有这种功能， 必然导致应用程序性能的降低。
第五章、总结
一、J2EE标准
IBM是J2EE发展进程中最大的商业投资者（其中包括SUN 和 BEA），事实证明，JAVA 技术的发展和延伸中 80% 以上的内容都浸透着IBM 的投入，我们可以从 http://www.ibm.com/java 中看到这方面的具体描述。
WebSphere 提供了业界最可观的产品级别的 J2EE 环境。
1、WebSphere V3.5 及其以前的版本都完全支持 RMI/IIOP；BEA的WebLogic 只是部分支持 RMI/IIOP，只有当JDK 1.3正式发布，且 WebLogic 可以支持以后，WebLogic 的 RMI/IIOP 才可被应用。BEA 要求客户使用 T3 协议， 因为他的 RMI/IIOP 将会比在 WebSphere 中慢4倍以上，BEA 对RMI/IIOP 的支持是非产品级别的。
2、J2EE 在进行分布式交易时需要符合 JTA/JTS 标准，但WebLogic对于 JTA/JTS 的支持却是有限的，它的交易只能针对一个数据库。也就是说，WebLogic 不能支持在一个交易中对分布式数据库的交易控制。这在 WebLogic 5.1 对 JTA/JTS 描述的文档中也有这样的描述：“Note that in all cases, transactions must be restricted to a single persistent store. You can't , for instance, mix JDBC persistence from two different sources in the same transanction”；而WebSphere 使用 JTA/JTS ，可以在一个交易中同时提交多个数据库，甚至连iPlanet （SUN 公司Web 应用服务器）也是购买IBM 交易服务控制模块来实现他们的应用服务器上的交易控制。
3、J2EE的下一个版本将会需要JAVA 提供连接后台传统数据的能力。现在，SUN 已经接受IBM提供的后台连接框架（IBM's Common Connector Framework -- CCF），并将其制定为JAVA下一个版本的后台传统数据的连接标准。IBM对其已经提供了从开发工具（VAJ）到运行平台（WAS）的全面支持，而BEA到目前为止还没有任何支持迹象。
4、WebSphere 是通过 IBM MQSeries 来完全支持JMS 1.01 标准。据IDC的报告， MQSeries 占消息中间件市场分额56%以上，Aberdeen Group 调查认为，MQSeries 占市场分额的72%以上；BEA 的 WebLogic 只是对 JMS 提供有限的支持，而且目前不支持生产应用。BEA 曾经拥有 MessageQ ，目前的市场分额只有1.5%，而且不支持 JMS。现在 BEA 已经放弃了这个四年前从DEC 购买的产品。
二、产品安装
凭心而论，WebLogic V5.1*较WebSphere V3.0*“安装”简单，但实际上，WebLogic只是在Unix上解压缩，不涉及操作系统，因此并不存在真正意义上的安装，所以，当用户需要升级和打补丁时，全部需要手工操作，无法使用系统系统提供的支持；WebSphere V3.5*安装界面简洁，整个安装程序流畅，快速自动安装，只需最少的用户干预。用户可根据实际情况，选择适合自身的安装方式：Quick install、Full install和Custom install。
三、配套集成工具
在配套开发工具中，IBM公司提供的解决方案最为全面，IBM WebSphere Studio和IBM Visualage Java 这两个软件包覆盖了WEB应用服务器开发的几乎全部工作。
WebSphere Studio提供了项目工作台和有关向导。项目工作台用来把各种生成的组件集成进一个项目，而各种向导可用来存取数据库、创建JavaBean和servlet等等。在Studio3.5版本还提供对个性化网站（IBM WebSphere Personalization Server）的支持，通过三个内置向导可以很方便的建立一个基于Rule的个性化网站，WebSphere Studio不愧是一个创建、维护和管理整个网站结构的好工具。
VisualAge for Java (以下简称VAJ)是一个全功能的Java开发环境，包含一个智能化集成开发环境，内含丰富的Java类库、高性能Java编译器和虚拟机，集成了包括向导和调试器在内的多种工具，支持JavaBeans的开发，通过先进的版本控制技术和贮存（Repository）机制支持团队开发(team development)。
VAJ最引人瞩目的功能就是与WebSphere Application Server的集成开发能力。从3.0版开始。VAJ就内置了WebSphere 测试环境、JSP/Servlet 开发环境、EJB 开发环境、存贮过程构建器、SQLJ工具、Domino企业存取构建器和XML工具包等。开发人员只需在开发机上安装VAJ就可以编写、调试WEB应用服务器的全部功能模块，从JSP、Servlet到EJB，十分好用。
相比之下，BEA公司就没有如此完备的集成开发环境。BEA控股的WebGain公司的Visual Cafe 和 Studio 提供了一部分集成开发能力，但是功能并不完全。例如，在Visual Cafe中开发EJB的应用时，开发机上必须也要安装和运行WebLogic Server，这是由于Visual Cafe没有提供集成的WebLogic EJB 运行环境，这一点给EJB的调试工作带来了很大的困难，可能开发人员对于EJB源代码的任何修改工作，都需要重新启动WebLogic Server来测试。详情参见下表。
公司EJB调试流程
VisualAge Java(IBM)1．启动WebSphere 测试环境2．编写EJB程序3．利用VAJ提供的EJB测试客户端测试EJB的功能。4．如果要修改EJB，则直接跳到25．封装EJB，用于发布。
Visual Cafe (WebGain)1．启动WebLogic Server2．编写EJB程序3．手工编写EJB测试客户端测试EJB的功能4．修改EJB5．关掉WebLogic Server6．重新启动WebLogic Server7．重新编写EJB测试客户端测试EJB的新功能6．如果要修改EJB，则直接跳到58．封装EJB，用于发布
所以，BEA公司也建议客户使用VAJ做Web应用开发。但是，BEA提供的VAJ开发模块只能安装在VAJ2.0中，无法充分发挥VAJ高版本的优势。
四、性能和扩展性
下面是在不同的平台上的测试结果，见图：
五、管理
WebSphere V3.5*产品本身提供了adminConsole、WSCP、XMLconfig 和Webadmin四种管理方式，全部配置工作均可通过图形界面操作完成，同时也提供API编程接口，用户可以自己编写控制程序；而WebLogic提供的缺省方法是手工修改配置文件，同时它提供的图形界面的Console只能阅读。绝大部分的修改工作均需要手工操作配置文件，需要重新启动服务器才能生效。
在Tivoli 管理方面，WebSphere提供了内置的支持(Tivoli-Ready)，而只是WebLogic需要购买另一控制组件才能实现Tivoli的管理(Tivoli-enabled)。
六、技术支持
作为一个纯软件公司，BEA的信息资源管理较为集中，为用户提供了方便、详尽的查找模式；IBM V3.0*文档管理较为分散，但在V3.5*中推出了InfoCenter，提供用户一个统一的WebSphere信息接入点，从中可以找到关于开发、配置、管理和移植的所有资料。
IBM在全球有多个实验室研究和使用WebSphere，许多资深工程师把他们的实际工作经验都浓缩在了Redbooks中，具体详情请参阅：
http://www.redbooks.ibm.com/
另外，在IBM的外部Web站点上有超过250种公开的技术资料、客户的技术资料参考核商业合作伙伴信息。所有的这些参考资料详尽地向客户展示利用WebSphere软件平台开发与服务软件的前景与价值。
七、产品前景
1999年，IBM公司的WebSphere和BEA公司的WebLogic的市场份额分别是12%和36%，但Giga预计在2000年，IBM与BEA将各占24%的份额，其中IBM市场份额增长50%，而BEA将下降33%。在2000年第一、二季度，IBM在UNIX和NT平台上的WebSphere更是增长了200%，当之无愧地成为当前市场上增长最快的应用程序处理平台。
1、资金支持。2000年IBM公司将在WebSphere上进行超过十亿美元的投资，并计划下一年度在数字咨询方面的投资翻番；BEA公司1999年的营业收入为4.86亿美元。
2、人员支持。本年度，IBM公司将雇佣超过1000名WebSphere工程师和销售人员，并且目前有超过4500名Java技术专家；BEA整个公司的雇员为2500人。
技术前景。IBM已经在OS/390中集成了WebSphere，真正利用OS/390服务器和特性构造Web应用程序服务器；BEA虽然也在OS/390服务器中实现了UNIX技术，但并没有利用独特的390技术特性。
八、真的还是假的？
WebSphere 软件被客户选择的数量是BEA的两倍；
WebSphere 软件增长的速度比BEA快10倍；
WebSphere 软件是集成的领导者，集成了450个适配器，BEA只集成了2个；
WebSphere 软件提供免费的开发者许可。BEA收费约达$2000.
WebSphere 软件提供第一个开发Web服务的集成工具. BEA提供了什么?
这些都是真的！但在华尔街杂志中，BEA声称他们所调查的企业中有80％偏爱BEA。这并不能反应独立的行业分析家和客户的总体评价。这只能证明BEA利用他们自己的客户满意度调查来支持这一声明！实际上，20％的BEA的客户偏爱WebShpere或其它平台！
附录：击破对手的谎言
谎言#1：websphere不提供“本机”JMS服务
（只能通过MQSeries软件才可以实现JMS）。那么怎样才能实现基于标准化的消息传输呢？应用JMS（用于Java消息传输的J2EE API）要求有IBM MQ-Series软件和附加配置的许可和安装以实现JMS消息传输服务（MQ-Series需要每个CPU额外支付2798美元）。
IBM公司指出：1）在与MQ-Series软件集成方面，Websphere和WebLogic有着不同的水平（信息传输能力，相互协作能力，开发工具，技术支持）。 2）IBM和BEA所提供的JMS服务在质量上也相差甚远（各自产品的用户数量可说明这一点）。
BEA所说的“本机JMS支持”是指在纯Java环境中实现JMS，并把JMS内嵌入WebLogic软件（同WL共同安装并可以利用WL操作工具进行配置）。重要的是WebLogic软件中的JMS同BEA的MessageQ产品有所不同。MessageQ是在C/C++中实现的，并且它是一种旧有的已经通过验证的技术（4年前BEA公司从DEC软件开发商那里获得了MessageQ，ObjectBroker和TopEnd），BEA声称，还是原有设计MessageQ产品的工程师在WebLogic中实现了JMS，但是他这种说法并没有得到证实---收购后这些工程师大部分都离开了BEA公司（其中一些现正为IBM效力）。
IBM
l当前，WebSphere支持JMS 1.0.2 (Java Messaging Service)和JTA 1.1 (Java Transaction API)与适用于MQSeries软件JMS的一体化。它允许在多个Websphere应用服务器上，对多个数据库，多个JMS实例进行事务处理。如果增加了WS/EE功能，它还可以支持APPC（CICS，IMS等等）。
l由于WebSphere的JMS支持是由MQSeries来提供的（换句话说基础WebSphere产品不能够实现JMS服务），这就使得用户们能够平衡各种MQ配套产品（用于多种应用软件的不同适配器，操作工具，PD/PI，性能监测等等），即由整个产业领导MQ配套产品的应用开发。
l由于WebSphere的JMS支持是由MQSeries来提供的,这就允许用户可以将WebSphere应用软件应用于各种平台（35+），而且支持通过MQ服务使可移动设备在任意一点与主机相连。而BEA只是允许将WebLogic JMS同WebLogic JMS通信连接。
l作为面向消息的中间件，MQSeries中间件目前处于主流，根据IDC统计，MQSeries中间占有56+%的市场份额，而根据Aberdeen Group的统计其市场份额上升到了72+%。目前，MQSeries中间件应用于大部分的财富2000公司，它适用于所有运行Window操作平台的CPU。但是它需要客户许可证。
l由第三方软件开发商提供的所有JMS都可以在WebSphere中实现。但它也有局限性，即第三方JMS产品不能够提供适当的JTA支持，因此也就不能够参与WebSphere的分布式消息传输。IBM已经进行了一些有限的测试来验证一些第三方软件开发商提供的JMS产品（涉及了JMS的实现）具有兼容性，但是第三方JMS产品没有得到WebSphere的正式支持（虽然测试很成功并且一些客户也采用了这样的配置）。
lIBM工具对于JMS支持和对于用我们的工具（VisualAge for Java）来进行消息传输的支持已经处于显著的领先地位。BEA在开发工具支持方面是比较弱的。在WebSphere和VisualAge for Java中应用的通用连接器架构（CCF）可以通过MQSeries连接器（不久将会增加通过JCA对MQSeries进行工具支持）访问WebSphere消息传输软件。IBM通过提供特定的“连接器”来执行其他系统的接口，这种连接器是适用于不同后端系统的代理JavaBeans发生器。可以说，CCF架构是一组类和接口，他们能够在任何环境中实现同企业资源的连接和互补。第三方软件开发商以特定的连接器来实现CCF架构，这种连接器包含客户方接口和CCF基础接口，CCF基础接口使得WebSphere应用服务器能够控制连接器的工作状态。CCF客户端接口已经脱离了对使用连接器的依赖，而单独进行开发组件过程，例如开发了Servlet组件。这样, 开发人员就可以只运用一套通用的工具来进行部件安装。在VisualAge for JAVA中，这套工具总称为企业存取生成器 (EAB).运用通用的操作过程和相同的工具意味着客户可以通过相同的路径从CICS系统，Encina服务器，或是MQSeries消息传输软件中获取他想要得到的数据。简而言之，因为在WebSphere和Java的VisualAge中引入了CCF架构，那么即使只有一点或是没有MQ经验的开发人员也可以操作MQSeries消息传输软件。而BEA的WebLogic软件没有这样的功能。
WEBSPHERE v4计划
l目前，IBM正着手研发可以向3Q2002中的可视化消息配件提供软件支持。预计在2002年，企业版就可以支持”管理容器消息传输”，从而免除了专业的JMS设计；为消息输出（不只是输入）提供适当的支持；加强对最后编码生成和工具的支持；促进并达成消息和部件之间的映像。
l在WS企业版V4（3Q01）中，我们将向消息接受方(消息驱动粒媒模式)提供支持，它是EJB 2.0的一个重要部分。
lWebSphere V4.0通过Web Services标准(SOAP, WSDL, UDDI)来支持应用程序到应用程序的集成（导航功能，发现和交互功能）。这样就可以促进商务集成（主要为外部）的发展，从而实现对商务集成（主要是内部）的JMS支持。
BEA
l最近，BEA退出了基础消息传输市场。几年前，BEA从NEC软件开发商那里获得了MessageQ软件（这种软件不能支持JMS也无法运行WebLogic）。在BEA的这项产品出台之前，MessageQ占据市场分额的35%，而从那以后，其分额逐渐减少，现在MessageQ只占据市场分额的1.5%。最近，BEA已经放弃了这个产品。对于J2EE规格的JMS API，您最信任哪家公司的产品呢？是产品市场的领导公司还是已经退出市场竞争的公司呢？
l在99年9月底，BEA推出了WebLogic 4.51版本（最新的版本是WL 6.0），迄今为止，BEA第一次可以支持JMS规格。这是BEA首次通过JDBC或是持续文档在基于第三方相关数据库的纯JAVA环境中实现了JMS，但其JMS的实现并没有经过验证。BEA利用代码来提供有限的JMS支持，而这种代码不易生产和部署(在WebLogic 6.0服务器上，实现了主题和行列群集，但是从一个失败节点恢复相关主题和行列预计在2002年实现)，同时，也没有对相关数据库进行优化来管理消息传输，而且，JDBC并不是目前世界上最有效的协议。因此，只是因为其内部构架（JAVA实现，相关数据库的运用，JDBC，群集化和冗余的不足），都足以说明WebLogic JMS没有得到优化，从而也不能保证高容量的消息传输。
l在上面我们已经提到了，WebLogic提供的是简单的，埋入式的工作流和JMS支持，并将其同JDBC和一些JAVA代码链接。这一简易做法容易使人产生误解。对于大多数用户来说，JMS是一种集成技术，它可以使J2EE应用软件通过消息传输来实现同其他系统（IMS, SAP, 批处理程序...）的交互工作。消息传输中间件也支持用于复杂拓扑结构和协议的应用软件。BEA JMS只能在拥有JAVA资源的BEA产品之间实现，这就使得其价值大打折扣，因为消息传输要求在不同的环境中都能够实现连接。如果是这样的话，就无法将WebLogic同由第三方软件开发商提供的用COBOL语言编写的软件相连接，同样，也无法连接于在外来操作平台上运行的C++程序。你将要被迫使用带有WebLogic的JMS/MQSeries软件。
lMQSeries和WebLogic之间没有完全的处理事物的交互工作能力。例如，WebLogic的消息控件可以潜在的同JMS集成。但是其局限性在于只能在WebLogic服务器JMS上执行要求的事务处理，因为WebLogic不支持从外部引进事务处理环境。这意味着，不能运用MQSeries或是其他JMS在WebLogic中进行事务处理。
l与MQSeries不同的是，WebLogic不支持版本和版本之间（也包括最新的WL 6.x版本和WL 5.x之间）的兼容。可以想象，在现实调配中怎么可以运用这样的消息传输软件呢？MQSeries JMS或是任何其他第三方软件开发商提供的JMS都不能在WebLogic 6.0 JMS中实现。
lBEA只能为分布式多个数据库事务处理提供beta支持，这是属于他们的beta EJB 2.0支持部分。EJB 2.0最近经历了一些重大的变革，从而要对BEA的beta进行重做。对WebLogic 2PC支持的局限性之一是，无法向WebLogic引入事务处理。因此，就不能在WebLogic上执行TUXEDO事务处理或是MQSeries事务处理。这时就可以显示出WebSphere的过人之处，WebSphere能够支持完全的2PC（包括引进MQSeries事务处理。
l几乎没有配件可以支持BEA JMS的扩展功能（例如执行检测功能，管理功能，与第三方系统兼容的功能）。
l我们建议要求BEA生产大量的事务处理参考，从而通过有保证的传输来实现他们的WLS JMS ，并且必须将他们记录在案 (不要徒劳无功)).在消息传输方面，让我们来看看BEA的客户证明书，案例研究，市场份额，最优方法，等等，然后我们可以再看看IBM的同样产品，其中的差别是很明显的。
概要
MQSeries是WebSphere软件操作平台的一部分。重要的是在生产中能够进行运行良好。BEA为JMS提供的唯一消息实现代码在市场份额中并没有一席之地，客户是愿意购买众多财富2000公司都采用的产品（指MQSeries软件）还是愿意购买没有经过JMS实现验证的产品（指WebLogic JMS）呢？我想这是不言而喻的。
如果你只要求在同一家软件开发商提供的2个J2EE系统之间实现JMS，并且也不必关心事务处理方式和拓扑结构，而只是关心运用同一个数据库的应用服务器，那么BEA的产品会很适合你的口味（今年年底，WebSphere软件也将提供类似的“小”功能）。这个市场很小（但仍然有一部分客户）。
但是，如果你比较注重消息的保存和传输，非J2EE的应用和在数据库与分布式操作事务处理范围内发送接受消息的能力，那么IBM的产品将是您唯一的选择。因为MQSeries与WebSphere的集成为你提供了你所想要的。所以，MQ面对更简易的前J2EE消息中间件的竞争，仍然可以占据市场份额的70%。
关于在WebSphere中运用MQ的技术细节可以在红皮书中找到，“使用WebSphere 高级版本和MQSI的用户到商务模式”, SG24-6160（本书可在http://www.redbooks.ibm.com免费下载）。
谎言#2：高速缓存能力
WebSphere无法解决Oracle 9iAS的缓存能力问题，而这种能力对于IBM的升级是致关重要的 IBM的解决方案是通过akamai为WebSphere提供一个称之为执行压缩包紧缩方案和某些“通告部件”以进行统计数据缓存
由IBM, Olympics.com,推出的悉尼2000奥运网站曾经是最大的网站，拥有113亿次的点击数，比2年前在日本长野举行的运动会增长了1700%。在悉尼网站的峰值点击数为每分钟1.2百万次。从运动会的开始到结束，可以随时打开网站，网站中所运用的技术包括：
lIBM WebSphere应用服务器高级版本
lIBM HTTP服务器
lIBM DFS（分布式文件系统）
lIBM WebSphere边缘服务器
lIBM DB2
lIBM MQSeries
lIBM/Lotus Domino
IBM在处理一些重大事件方面，例如奥运会和人机大战（一太名为“深蓝”的计算机同人进行的国际象棋大赛），从中获得了很多重要的技术经验。在现实环境中，IBM开发了IBM WebSphere边缘服务器（以前叫做执行包），它是当今最强大的并且是可以升级的互连网基础软件，这种软件提供了本地和外地环境中的电子商务应用软件所要求的可测量性，可靠性和可执行性。它集成了动态通信加载平衡功能，内容复制和分配管理功能，还集成了超级高速缓存功能和支持宽带管理的过滤功能。这些功能可以单独使用也可以集中使用来满足不同网络的特殊要求，并对遗传下来的存在于互连网中的弱点进行校正，从而为关键商务应用软件的运行提供支持。
WebSphere边缘服务器通过集成前缘，强大的高速缓存功能和加载平衡部件来对互连网的总体性能进行改善。它适用于任何互连网和见于市场上的任何应用软件服务器。（Oracle产品并没有此项功能，它们只能在Oracle产品之间适用，而不适用于第三方软件开发商提供的产品）。WebSphere边缘服务器有2个部件：
l加载平衡部件，也称电子网络分配器（eND）,它可以对TCP服务器和应用软件进行实时监控和平衡. 加载平衡部件的一个最大优点就是它可以使访量很大的网站增加容量，而这归功于它同网络中一个单独逻辑服务器的动态连接。
l高速缓存和过滤部件，也称网络高速公路（WTE），是一个高速缓存代理服务器，它可以提供可升级的高速缓存功能和过滤功能，这些功能可使其接收命令并向URL提供服务。通过这个可调的高速缓存部件来支持高速缓存的高点击率，可以降低宽带的成本并提供更快的客户响应时间。另外，高速缓存和过滤部件的应用也使得服务器错误戏剧化的减少。WTE是作为一个高速缓存服务器来工作的。传统的代理服务器只能够从一个客户端那里接收到一个请求，并将这个请求发送大目的网站服务器。而WTE的工作原理是，当WTE从目标服务器上接收到数据，它可以在本地文件系统（高速缓冲存储器）中保留数据复件。如果再提出一个相同URL的请求，WTE则不必返回到相同的目标服务器。这就大大减少了响应时间并降低了网络带宽。
IBM运用WebSphere边缘服务器技术构建了一个可升级的并且相当可靠的系统，这个系统能够对通信容量进行高效的控制。1998年2月17日日本标准时间12：41，在日本长野举办的冬奥会的官方网站创下了互连网的新记录，网站访问次数达到了每分钟98，226次，这可以说是互连网的一次革命，然而时间过了还不到一个星期，冬奥会还没有结束，一个空前高的记录又产生了，在仍然保持原有响应时间的前提下，点击率突破了每分钟103,400次。这个记录被收入了吉尼斯世界记录大全。如果想对WebSphere进行更多的了解，可以访问http://www.redbooks.ibm.com网站并键入”Performance Pack” 关键字进行搜索。在那里你可以看到“管理互连网通信和带宽要求的高速缓存功能和过滤功能”。值得一提的是，IBM公司在很久以前就已经拥有了该项技术，并创下了众多世界记录，世界上最大的网站都运用了这项技术，而Oracle公司只是在最近才开发出了这项功能，其进程远远的落在了WebSphere应用服务器之后。WebSphere边缘服务器的很多性能已经得到了证实，包括可升级性，群集性和可高速缓存性。
谎言#3：WLM和群集能力
负荷平衡功能：WebLogic运用的是复杂的系统规则，而WebSphere用的是简单的罗宾式系统规则。当多个应用服务器在位运行多个WebSphere实例时，要想充分发挥它的工作性能，那么应用服务器是否能够对负载进行高效率的分配就成为了关键。
WebSphere在很多领域都具有优势。首先，WebSphere的群集化支持并没有在应用服务器原有价格基础上增加收费，而WebLogic不能做到这一点。另外，在WebLogic中进行群集化配置要比在WebSphere中困难的多，而这种群集化配置又是不可忽视的。要想在WebLogic中实现群集化要求进行大量的人工配置步骤，包括要经过多次重新启动来完成配置, 它不能提供一个模型对群集化对象进行反复拷贝（要求网络管理员不仅要拷贝一个目标，还要按顺序在目标下对其进行人工配置）。与WebLogic比较WebSphere在这方面又高出一筹，WebSphere提供有功能强大的“模型和克隆”架构，这种结构可以先制作一个对象模型，例如应用服务器，然后将其复制到节点，复制的数目根据需要而定。复制品与原模型配置的变化同步，这样就减少了大量的人工操作。WebSphere还可以在父对象下对子对象进行循环模拟，这样就可以制作出一个与EJB容器有相同配置信息的应用服务器模型、Servlet运行引擎模型和应用服务器中所有对象的模型，然后可以把这个模型克隆到多个节点上去。值得注意的是，这一过程中的步骤简洁，可以通过基于Java的管理GUI或是WSCP管理工具来执行，而不是通过WebLogic的 基于web的GUI接口进行反复的人工管理作业。这就节约了宝贵的生产时间。
Websphere WLM第一眼看上去像是“简单的循环”，事实上，它融入了研究人员的集体智慧，并且也证明是有效的。总体来说，基于web的 servlet/JSP/EJB应用软件给我们展示了一种数量大、过程（相对）简短的事务处理模式。这样，随机的或是循环的作业负载传输大大提高了全面的传输性能。它可以在流程中再增加一个断点。Websphere WLM依赖可决定服务器可用度的“灵敏”EJB抽头来路由作业。WLM消除了在路由器接口产生阻塞（和/或断点）的可能性，Websphere中的业务负载管理并不只具有循环特点，还具有以下优化：
l1. 尽可能在相同的JVM中路由作业。
l2. 尽可能在同一台机器的多个服务器上路由作业（如果选择的倾本地化政策）
l3. 如果#1或#2都无效，那么可以在其他机器上路由作业。
这些优化戏剧化的减少了网络中的信息流量，同时也减少了对方法呼叫整理和分解的开销. 从而缩短了事务处理时间，增加了总吞吐量。为了事物处理的持续完整，要实现同一台特殊服务器的亲和力以确保接合/反转的完整
我们现在有一项解决方案，来实现具有不同负载的服务器的群集化，在这种情况下，WLM要将更多的作业导入到特定的负载量跟大的服务器中去。要做到这一点，必须在具有更大负载量的服务器上增加附加的克隆模型。这项技术不久即将被开发出来，届时，这种加权循环/随机运算规则就何以自动的处理此项方案。网站服务器与Websphere之间的消息传输能够由servlet转向器来执行（它开发了EJB-based WLM）或是通过我们的OSE远程架构，这种架构可以在一组Websphere服务器中进行业务负载分配，当一台服务器发生堵塞时，可以通过其他服务器传输消息，还可以实现用于优化会话数据性能的客户亲和力. WLM特性的集合使得Websphere工业在分布式平台上具有了领先升级能力和先进的性能。390系统上的Websphere增强了OS/390的业务负载管理能力，提供了可实现最大容量，最容易升级和最可靠的应用服务器。
关于在WebLogic中的WLM和群集
l不能够实现真正的克隆-不能克隆服务器的内容（只可以对其外壳进行克隆，而且要通过人工操作将所有组件转移到新的服务器中）
l运用IP多点传输—但是DMZ中经常失败并且难以管理（参看《状态复制和FAILOVER》）
l如果在同一网络中需要多个应用服务器，必须采用多启始地址网络适配器或是使用多个网卡。
l不能够在控制台远程启动或是关闭服务器—必须人工启动文稿编排程序。
l如果需要运用第三方的应用服务器怎么办？--为了使这种插入式配置生效，每次都必须重启网络服务器—必须要购买第三方IP喷射器（CISCO LD, IBM WS边缘服务器, 等等.）--这些都不能与WL集成。
l关于价格—如果实现了群集化，每个CPU必须附加支付$7k。
无论在哪一种操作平台上，WebSphere的定标系数和性能都要强过WebLogic。要想了解对这两者所进行的基准问题测试情况，请访问http://water.raleigh.ibm.com （IBM链结）
WebSphere应用服务器超过了它的竞争对手—其工作性能和规模可伸缩性能在IBM网站的白皮书中都有详载。http://www.ibm.com/software/webservers/appserv/whitepapers.html。
WebSphere高级版本在工业应用中具备世界一流的群集性和最快的EJB和Servlet/JSP工作性能。WebSphere高级版本3.0输送2个负载平衡和FAILOVE层面：
l电子网络调度器是WebSphere边缘服务器的一部分，通过电子网络调度器提供IP喷射和工作量管理可以实现任何网站服务器的群集化和HTTP传输。（BEA不向第三方网站提供群集化和WLM支持，所以需要购买WebSphere边缘服务器或是其他同类产品）
l在WebSphere应用服务器高级版本中为EJBs, Servlets, JSP和其他所有网站应用资源提供工作负荷管理和群集。
WebSphere免费提供将群集集成到产品中的服务，而WebLogic还要另行收费（每个CPU w/WLM收费$5K）。
Websphere WLM第一眼看上去像是“简单的循环”，事实上，它融入了研究人员的集体智慧，并且也证明是有效的。总体来说，基于web的 servlet/JSP/EJB应用软件给我们展示了一种数量大过程（相对而言）简短的事务处理模式。这样，随机的或是循环的作业负载传输大大提高了全面的传输性能。它可以在流程中再增加一个断点。Websphere WLM依赖可决定服务器可用度的“精密”EJB抽头来路由作业。WLM消除了在路由器接口产生阻塞（和/或断点）的可能性，Websphere中的业务负载管理并不只具有循环特点，还具有以下优化：
l1. 尽可能在相同的JVM中路由作业。
l2. 尽可能在同一台机器的多个服务器上路由作业（如果选择的倾本地化政策）
l3. 如果#1或#2都无效，那么可以在其他机器上路由作业。
这些优化戏剧化的减少了网络中的信息流量，同时也减少了对方法呼叫整理和分解的开销. 从而缩短了事务处理时间，增加了总吞吐量。为了事物处理的持续完整，要实现同一台特殊服务器的亲和力以确保接合/反转的完整
我们现在有一项解决方案，来实现具有不同负载的服务器的群集化，在这种情况下，WLM要将更多的作业导入到特定的负载量跟大的服务器中去。要做到这一点，必须在具有更大负载量的服务器上增加附加的克隆模型。这项技术不久即将被开发出来，届时，这种加权循环/随机运算规则就何以自动的处理此项方案。网站服务器与Websphere之间的消息传输能够由servlet转向器来执行（它开发了EJB-based WLM）或是通过我们的OSE远距架构，这种架构可以在一组Websphere服务器中进行业务负载分配，当一台服务器发生堵塞时，可以通过其他服务器传输消息。还可以实现用于优化会话数据性能的客户亲和力. WLM特性的集合使得Websphere工业在分布式平台上具有了领先升级能力和先进的性能。
WebSphere应用服务器V.3版本还提供一个多服务器实现模型，它允许在一个群集中定义多个物理服务器。其中，每个服务器都能够轮流执行一个或是多个应用服务进程。每个应用服务器都可以作为一个JAVA虚拟机来工作，并能够和其他应用服务器进程同一配置，它也可以用做一个特殊的目的应用服务器以满足对高吞吐量的要求。WebSphere边缘服务器的HTTTP群集能力能够同高级版本3.0中的企业JAVA群集能力相结合。
通过边缘服务器对于进入HTTP请求和应用服务器对于JAVA和企业JAVA服务的适当群集，使得我们不仅可以获得CA还可以获得HA。任何一个单独机器上的进程失败或是整台机器的进程失败（或是为了维修目的从群集器上拆除）都很容易导致负荷改向而进入群集器的其它服务器。为了防止这种情况发生，我们推荐一种硬件群集方案，例如HACMP（在下面文章里我们对它进行了详细讲解），因为它的数据库可以用做EJB系统信息中心库来保持群集器的配置、会话、事务处理和作业负荷状态。
群集器和作业负荷管理（WLM）的实现，依赖于运行在每个物理服务器上的管理服务进程概念。每个管理服务器利用一个单独的EJB系统信息中心库来保持群集器配置和运行状态。通过这种方式，一旦EJB系统信息中心库中有任何变化，就会马上向群集器中的所有机器和服务处理器发出通知。之中变化包括事务处理状态或是服务器处理状态（有效/无效）。
实际WLM处理依赖于一个改进的RMIC编译程序来产生灵敏的WLM认知抽头，这些抽头包含了控制流程逻辑，这种逻辑可以有效的将方法启用喷涂到经过服务器组中服务器的可复制对象上。有一点很重要，为了实现WebSphere WLM，这些抽头必须可以跨越RMI-IIOP ORB运行时间移植。通过可移植的org.omg.CORBA.和javax.rmi.CORBA包，OMG规格使这种移植成为可能。为了保持这种跨越运行时间的可移植性，ORB运行时间不得有任何变动，以此来实现负荷的分配。而对于抽头的修改是有限的，这种修改是以一种允许哑客户（不具备WLM客户运行时间的客户）使用的方式来进行的。客户运行时间对实际作业负荷进行分配。当拥护把第一次在一个可复制的对象上进行请求调用，WLM客户运行时间就从对应的EJB服务模块系统信息中心库中检索有关服务器组的信息。这些信息都有时间标记，然后选定一个服务器调用请求。当请求进入了地址服务器的地址空间，那么服务器就会先对其进行检查以确定是否可以向它服务。如果可以的话，服务器就会开始服务这个请求。如果这个请求已经过期了，服务器将会发给客户运行时间新的配置信息。如果由于某种原因（脱离了服务器组或重负荷或是处于开始和终止过程）服务器不能服务这个要求，它将给出提示，并要求客户重试。客户运行时间捕获到这个提示，对其超高速缓冲存储器进行相应的更新并且重试请求调用。
谎言#4：状态会话EJB群集化和故障排除
WebLogic的EJB群集化甚至在服务器终止的情况下都可以为状态会话EJB对象提供清楚的连接，这使得它在竞争中抢先了一步
在规模可伸缩性方面，WebSphere通过将会话都写入数据库来执行跨框会话共享。我更看好WebLogic和iPlanet群集化/Dsync方法，因为可以用它在框之间传输共享会话信息。
对于网站应用软件来说，保持状态的能力是一项非常重要的性能。这种能力允许网络应用软件保存有关当前所连接的用户信息和与网络应用流程相关联的信息，并在一个没有连接的环境中建立一个虚拟连接。这个“状态”信息就是通常所说的会话。BEA的weblLogic服务器使用的是一个多点传送途径，向所有群集的服务器定时广播会话信息（HTTP会话和状态会话控件）的更新。但是存在几个缺点：
l如果在服务器突然终止之前群集器中的weblLogic服务器没有广播，那么全部新的会话信息会从服务器上丢失。可以实现100%的错误修复和100%的事务处理完整性吗？不能。当我们阅读weblLogic文件的时候，发现服务器是通过使用IP多点传送来实现状态会话倥件和HTTP会话状态复制的，而IP多点传送不能确保事务处理的完整性。WL 6.0文件的局限性为：“IP多点传送不能确保能够收到消息。如果本地缓冲器已没有空间，新的消息就不能被写入缓冲器，而一旦丢失消息，应用软件也无法得到通知。因此，weblLogic服务器可能会丢失一些通过IP多点传送的消息。”此文件的URL地址是http://e-docs.bea.com/wls/docs61///////cluster/features.html）
lBEA的内存复制是一大特色，但是鉴于上述原因，如果要求100%的错误修复能力和兼容性，我们建议使用HTTPS会话数据库和实体控件，而不要用状态会话控件。下面的文章摘自WebLogic 6.1文档资料http://e-docs.bea.com/wls/docs61///////cluster/object.html#1006807：复制EJB状态变化：“当客户要改变EJB状态时，状态差异被复制到副服务器实例上。对于参加事务处理的EJBs，在事务处理提交之后复制过程马上发生。对于不参加事务处理的EJBs，在每个请求调用之后开始复制。这两重情况都只是将EJB状态的实际变化复制到副服务器上面。这就可以最大程度的精简复制过程。注意：正如EJB规格书中所说，状态化EJB的实际状态是非事务处理性的。虽然这听上去不太可能，但是当前的EJB状态有可能丢失。例如，如果一个客户提交包括EJB的事务处理，这时候主服务器在状态改变被复制前出错，那么客户将退回到EJB的先前储存状态。如果退出时可以保存你的EJB状态这一点对你非常重要的话，建议你还是用一个实体EJB，而不要用状态会话EJB”。
l用户不应该太迷信市场宣传（如果我把我们的会话复制称为—超级、特大型、迅速、立即的CPU高速缓存，你们会相信吗？）他们应当运行一些实际工作性能测试来看看，在WebLogic中的会话复制究竟是好还是坏，也可以看到配置IP多道传送是多么的困难。而IBM推出的群集化的HTTP会话管理是在经过验证的数据库基础上开发的。群集器中的所有服务器都共享访问一个数据库。所有HTTP会话信息都可以在这个数据库中保留（如果不要求故障排除的话，还可以保存到内存当中）。当对会话信息进行了一项更新，这项更新就可以保留在数据库，而且群集器中的任何服务器都可以立即访问它。如果一台服务器突然终止，不会导致信息丢失，因为这些信息已经数据库中保存。当客户返回到同一台服务器，具有会话亲和力的HTTP会话状态就被存取到内存中。在故障排除方案中可以使用多Servlet引擎，而不只用一个单独备份（在BEA的“成对”结构中运用）。也可以使用高效数据库解决方案来排除一个单独断点。对WebSphere v3.x进行工作性能优化允许使用人工更新模式，它能产生更大的附加利益，将对象的串行化影响降至最低，并数据库不过多的依赖应用软件的写入特性。WebSphere v4.0版本一些特性可以更有效的提升机器的工作性能，这些特性包括增强亲和力（将会话嵌入到正在生成的JVM）和基于时间的写入（基本上是一套人工自动升级版本）。最后，我们对即将实现的内存到内存会话复制技术进行一下预览（它将基于轻型JMS实现上）
lWebLogic群集器和许多播送方式的推出，使网络使用得到了进一步发展。其中，会话数据和播送频率也起着重要的作用。
l由于WebLogic中会话更新播送频率的影响，群集器中的其他服务器可能不易接收到正确的会话数据。这就导致了在群集器中的其他服务器上执行请求的时候产生旧的或是错误的数据。
l在WebLogic 6.0版本中，状态会话粒媒复制是它的专有特性，它被锁在一个单独的平台上。EJB 1.1和2.0规格不对状态会话粒媒提出排除故障和状态复制要求。因此，这是WebLogic EJB规格的扩展，它可以将用户锁在BEA平台。（使用此特性的JAVA代码不能够移植，并要求重写）。
l你在DMZ中运行过群集器吗？IP多道传送并不总适用于DMZ并且很难对其进行管理）。
最后- 你想得到最佳的工作性能和规模可伸缩性吗？千万不要用WebLogic软件中的特征。想得到最佳工作性能吗？建议您使用通用会话粒媒。想得到持久性和100%的保证其完整性吗？可以使用实体粒媒。所有基于事务处理监控的高性能应用软件都是通用的。
谎言#5：轻松使用和安装
WebSphere的使用起来非常困难并且难于管理。要用一个星期来进行安装。
安装
“WebSphere的安装方便快捷。在服务器上安装WebSphere，步骤简单，无须过多的进行配置，也不会遇到什么麻烦。IBM公司已经改善了安装程序：现在，WebSphere对于那些先决项目进行预安装—例如Web服务器、数据库和JDK（JAVA开发工具包） --另外，包也与Lotus Domino, IBM VisualAge for Java和WebSphere商务组件有了更好的集成。为了更加简化安装过程，IBM公司提供了大量的应用示例以供参考。”此文摘自信息中心COM的WebSphere应用服务器3.5高级版本评述2001.10.6（请访问http://www.infoworld.com/articles/es/xml/00/10/09/001009eswebsphere.xml）
l安装（“Out of the box experience”） -尽管IBM公司已经对WebSphere V 3.5高级版本的安装进行了改良，大多数开发人员仍然认为，BEA的WebLogic可以为单用户开发工作站提供最简易的安装。对此，我们表示同意。但这种简易安装是有局限性的。如果你不在WebLogic上安装数据库，不必对Web服务器的插入进行发展盒配置，而且在配置过程中几乎没有配置选项，在这些前提下，会给你一种错觉，认为用BEA的WebLogic技术进行安装很简单。但是如果在安装中需要更复杂的技术，它就不那么简单了，这时，只有IBM的WebSphere技术才可以完成您的心愿。
l在WebSphere中把相关数据库作为一个配置系统信息中心库，而不是像在BEA WebLogic中把它作为一个XML配置文件，这样做的好处立时可见：a)它可以提供一个单独的系统映像，在那里多个节点可以参与一个WebSphere域，并且在环境棵中很容易应用平衡负载技术和故障排除技术。 B) 作为配置系统信息中心库要比做为一个平面文件具有更大的潜在可靠性（假设平面文本文件对于文件系统和OS具有可靠性，并假设在文件中没有开发人员的失误）。
lWebSphere的安装已经得到了相当大的改进，甚至还增加了3按钮的“立即安装”，我们对产品设计上的考虑越来越广，包括你经常要做的管理/配置任务（多节点的系统辊平、多节点的负载平衡配置和分配，等等）
n将现有Web服务器配置成应用服务器
对于一个单独节点Web服务器应用服务器的安装，或是增加一些步骤安装一个多节点Web服务器，WebSphere具有明显的优势。相比较，用WebLogic就要麻烦的多，WebLogic要求你必须对IIS服务器（和任何第三方提供的Web服务器）进行烦琐的人工调整来对web服务器插入进行人工注册和人工配置web服务器，并且每次改变web服务器的配置时都要将其终止然后重新启动，等等。Web服务器插入配置对产品的进行实际使用的前提；否则，你就是在使用BEA自己的基于JAVA的Web服务器，当你选择默认选项的时，它将自动安装。
WebSphere安装可以很容易的对Web服务器插入进行配置（在启动时，会自动安装插入配置—而不需要人工调节，并要求在一开始就进行现有web服务器的插入配置。当你改变群集器的配置，WebSphere将把这种变化更新到所有的插入件中（即使是在远距机器上操作），这样，网络管理员就不必对多特性文件进行人工更新（而在WebLogic中需要人工更新）。WebSphere插入构架可以使所有的更新立即生效而不必重新启动计算机（而在WebLogic中，当插入配置发生变化要求对web服务器进行重新启动）。
简而言之，WebLogic的安装程序是一种单盒开发这机器安装，表面上看起来好象很快捷简单；IBM认为，眼前的省事会给你以后安装现实配制带来麻烦。详细内容请参见“Plug-in for IIS”部分。
执行和系统管理
WebSphere信息世界评述，“IBM WebSphere最新版本又竖起了难以逾越的栏杆”— 10/6/00，“总之，WebSphere V 3.0版本是一款强有力的产品，可以说是出色的。另外，安装容易的让人难以置信，负载平衡能力极其出色并且还具有可靠的安全性。所以无论您是购买还是升级，我们都向您全力推荐WebSphere V 3.0版本。”
每一款产品都有它自己的用户接口来管理产品。在很多情况下，这并没有增加在WebSphere中执行相同配置任务的难度，只是有所不同罢了。尽管如此，IBM的方法不仅可以提供一个广阔的管理用户接口，还可以给开发人员和操作人员提供实时储存，以供以后应用。这可通过多种途径获得；考虑到可计量的时间存储，我们将在下面对可用性和管理的不同方面进行讨论。从我们角度看，在系统管理领域WebSphere要胜过WebLogic。GUI是BEA的一个单独产品，要单独收费。并且在WebLogic v6.0版本无法运用GUI。
WebSphere V 3.5版本使其在WebSphere应用服务器中的可用性得到了提升，并且通过管理工具提供全面管理：
lGUI工具：基于Java的管理GUI– 用于在公司防火墙范围内管理和 访问应用服务器，并可对产品的各个方面进行图形化管理。在管理控制台方面，我们开发了做实用的工具。GUI允许改变EJB调配描述符，安全设置，群集器操作（建立，启动，关闭，等等并且可以在一台单独的控制台来完成管理任务。
l基于浏览器的GUI ：HTTP/SSL – 在远距离管理环境中，允许在防火墙 外 访问。
lTivoli集成 ：除了WebSphere内部的工具，Tivoli中的工具也可以提供全面的系统管理（管理、启动/关闭、部署、视图注册、存档，等等）
lXML配置命令行工具：此工具允许你输入、输出、和备份你的整个WebSphere域配置信息映像到一个XML文件；这对于进行大批量生产很有用，因为你可以从这个XML文件为每个新的WebSphere节点引入所有必要的配置，而不是为每个节点进行人工配置。
lWscp命令行工具连同Java TCL API是一个完全的可编译的基于Tcl的命令行接口，它允许对应用服务器的所有方面进行管理（安全对象例外）；可以写入Tcl原本来执行普通操作，展开大规模生产，备份，配置新的代码（EJB代码/EJB代码/...）等等。
lWebSphere在很多领域都具有优势。首先，WebSphere的群集化支持并没有在应用服务器原有价格基础上增加收费，而WebLogic不能做到这一点。另外，在WebLogic中进行群集化配置要比在WebSphere中困难的多，而这种群集化配置又是不可忽视的。要想在WebLogic中实现群集化要求进行大量的人工配置步骤，包括要经过多次重新启动来完成配置, 它不能提供一个模型对群集化对象进行反复拷贝（要求网络管理员不仅要拷贝一个目标，还要依次在目标下对其进行人工配置）。
l与WebLogic比较WebSphere在这方面又高出一筹，WebSphere提供有功能强大的“模型和克隆”架构，这种结构可以先制作一个对象模型，例如应用服务器，然后将其复制到节点，复制的数目根据需要而定。复制品与原模型配置的变化同步，这样就减少了大量的人工操作。WebSphere还可以在父对象下对子对象进行循环模拟，这样就可以制作出一个与EJB容器有相同配置信息的应用服务器模型、Servlet运行引擎模型和应用服务器中所有对象的模型，然后可以把这个模型克隆到多个节点上去。值得注意的是，这一过程中的步骤简洁，可以通过Java-based管理GUI或是WSCP管理工具来执行，而不是通过WebLogic的 基于web的GUI接口进行反复的人工管理作业。
关于WebLogic中的WLM和群集化：不能够实现真正的克隆-不能克隆服务器的内容（只可以对其外壳进行克隆，而且要通过人工操作将所有组件转移到新的服务器中）
运用IP多点传输来进行状态复制：不是经过事务处理的，不能保证总在DMZ中有效并且难于管理。WL 6.0文档有很多局限性：“IP多点传输不能保证消息接收。如果本地缓存器已满，那么新的消息将不能写入缓存器，然而并不通知应用软件消息何时“丢失”。因此，WebLogic服务器有可能会偶尔丢失通过IP多点传输进行广播的消息。BEA建议使用JDBC来实现100%的故障排除和一致性（WebSphere已经高度优化了基于JDBC的状态复制，从而实现了100%的事务处理遗一致性和100%故障排除性能并且它比WebLogic的存储器内复制要快的多）
如果在同一网络中需要多个应用服务器，必须采用多启始地址网络适配器或是使用多个网卡（来为每台服务器定义个别的IP地址 – 而WebSphere没有此限制）
不能够在控制台来完成对服务器的远程启动或是关闭—必须人工启动文稿编排程序并人工启动一个群集器中的所有服务器（而WebSphere中只需敲击一个按纽就可启动整个群集器）。
如果需要运用第三方的应用服务器怎么办？--不得不人工 |
|
免费注册
发表于 2002-09-06 09:10
