IBM WebSphere家族产品与BEA WebLogic家族产品比较
第一部、应用服务器篇WebSphere App Server Vs. WebLogic App Server第一章、产品概述5一、软件技术发展51、传统两层次软件的缺陷52、三层次（或多层次）软件架构与中间件6二、主要的中间件软件供应商81、IBM公司82、BEA公司83、其它厂商9第二章、软件体系结构10一、WEBSPHE...显示全部
返回一生何求的回答
“答”则兼济天下，请您为题主分忧！
关于在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服务模块系统信息中心库中检索有关服务器组的信息。这些信息都有时间标记，然后选定一个服务器调用请求。当请求进入了地址服务器的地址空间，那么服务器就会先对其进行检查以确定是否可以向它服务。如果可以的话，服务器就会开始服务这个请求。如果这个请求已经过期了，服务器将会发给客户运行时间新的配置信息。如果由于某种原因（脱离了服务器组或重负荷或是处于开始和终止过程）服务器不能服务这个要求，它将给出提示，并要求客户重试。客户运行时间捕获到这个提示，对其超高速缓冲存储器进行相应的更新并且重试请求调用。
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服务模块系统信息中心库中检索有关服务器组的信息。这些信息都有时间标记，然后选定一个服务器调用请求。当请求进入了地址服务器的地址空间，那么服务器就会先对其进行检查以确定是否可以向它服务。如果可以的话，服务器就会开始服务这个请求。如果这个请求已经过期了，服务器将会发给客户运行时间新的配置信息。如果由于某种原因（脱离了服务器组或重负荷或是处于开始和终止过程）服务器不能服务这个要求，它将给出提示，并要求客户重试。客户运行时间捕获到这个提示，对其超高速缓冲存储器进行相应的更新并且重试请求调用。
浏览398