每一款产品都有它自己的用户接口来管理产品。在很多情况下,这并没有增加在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中只需敲击一个按纽就可启动整个群集器)。
如果需要运用第三方的应用服务器怎么办?--不得不人工
本文来自电脑杂谈,转载请注明本文网址:
http://www.pc-fly.com/a/jisuanjixue/article-30071-25.html
嘻嘻
但也绝不怕事