谎言#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 ... 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/article ... 1009eswebsphere.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服务器,当你选择默认选项的时,它将自动安装。