weblogic,websphere,和Jboss之间有什么区别_weblogic与webshphere-优快云博客

weblogic,websphere,和Jboss之间有什么区别

目录
- 概述
小结
参考资料和推荐阅读

LD is tigger forever，CG are not brothers forever， throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI， Keep progress，make a better result.
Survive during the day and develop at night。

架构比较
从架构上来说，显然Jetty比Tomcat更加简单。
Jetty的架构从前面的分析可知，他的所有组件都是基于Handler来实现的，当然他页支持JMX。但是主要的功能扩展都可以用Handler来实现。可以说Jetty是面向Handler的架构，就像Spring是面向Bean的架构，iBATIS是面向Statement的一样，而Tomcat是以多级容器构建起来的，他们的架构设计必然都有一个“元神”，所有以这个“元神”构建的其他组件都是肉身。
从设计模板角度来看，Handler的设计实际上就是一个责任链模式，接口类HandlerCollection可以帮助开发者构建一个链，而另一个接口类ScopeHandler可以帮助开发者控制这个链的访问顺序。另外一个用到的设计模板就是观察者模式，用这个设计模式控制了整个Jetty的生命周期，只要继承了LifeCycle接口，对象就可以交给Jetty来统一管理了。所以扩展Jetty非常简单，也很容易让人理解。整体架构上的简单也带来了无比的好处，Jetty可以很容易的被扩展和裁剪。
相比之下，Tomcat臃肿很多，Tomcat的整体设计很复杂，前面说了Tomcat的核心是他的容器的设计，从Server达到Service再到engine等container容器。作为一个应用服务器，这样设计无可厚非，容器的分层设计也是为了更好的扩展，但是这种扩展的方式将应用服务器的内部结构暴露给外部使用者，使得如果想扩展Tomcat，开发人员必须要首先了解Tomcat的整体设计结构，然后才能知道如何按照他的而规范来做扩展。这样就无形增加了对Tomcat的学习成本。不仅仅是容器，实际上Tomcat也有基于责任链的设计模式，像串联Pipeline的Value设计，也是与Jetty的Handler类似的方式，要自己实现一个Value与写一个Handler的难度不相上下。从表面上看，Tomcat的功能要比Jetty强大，因为Tomcat已经帮你做了很多工作，而Jetty只告诉你能怎么做，如何都由你去实现。

打个比方，就像小孩子学数学，Tomcat告诉你1+1=2、1+2=3、2+2=4这个结果，然后你可以根据这个方式得出1+1+2=4，你要计算其他数必须根据他给你的公式才能计算，而Jetty是告诉你加、减、乘、除的算法规则，然后你就可以根据这个规则自己做运算了。所以你一旦掌握了Jetty，Jetty将变得异常强大。

性能比较

单纯比较Tomcat与Jetty的性能意义不是很大，只能说在某种使用场景下他们表现得各有差异，因为他们面向的使用场景不尽相同。从架构上来看Tomcat在处理少数非常繁忙的连接上更有优势，也就是说连接生命周期如果短，Tomcat的总体性能更高。
而Jetty刚好相反，Jetty可以同时处理大量连接而且可以长时间博爱吃这些连接。例如，一些Web聊天应用非常适合用Jetty做服务器。淘宝的Web旺旺就用Jetty作为Servlet引擎。
由于Jetty的架构非常简单，作为服务器他可以按需加载组件，这样，不需要的组件就可以去掉，无形中可以减少服务器本身的内存开销，处理一次请求也可以减少产生的临时对象，这样性能也会提高。另外Jetty默认使用的是NIO技术，在处理I/O请求上更占优势，Tomcat默认使用的是BIO，在处理静态资源时，Tomcat的性能较差。

作为一个标准的Servlet引擎，他们都支持标准的Servlet规范，还有Java EE的规范也都支持，由于Tomcat使用得更加广泛，他对这些支持得更加全面一些，有很多特性Tomcat都直接集成进来了。但是Jetty的应变更加快速，一方面是因为Jetty的开发社区更加活跃，另一方面也是因为Jetty的修改更加简单，他只要把相应的组件替换就好了。而Tomcat在整体结构上要复杂得多，修改功能比较缓慢，所以Tomcat对最新的Servlet规范的支持总是要比人们预期的晚。

WL的发展速度比WAS快.
WL比WAS更用户友好.要简单地在WAS中部署应用程序，我们需要深入研究，很难找到您是否是新来的.
我发现WAS在某些机器上比WL慢.
我发现，与WAS相比，WL中的Classloading更易于理解和有效

使用WL控制台获得更好的用户体验(但是使用WAS管理员脚本获得更好的体验)
很多要在Websphere上安装的修订包(但至少它们存在:-))
关于类加载，即使您可以调整一些我不推荐的内容，您也应该参考Java doc的内容(但由于您正在使用J2EE，所以情况并非如此).

可靠性，可扩展性,可用性
根据最近的公开评测和客户的反映表明：BEA在可靠性（reliability），可扩展性(scalability)，性能(performance),
可用性（availablity）方面领先于IBM。
BEA最近所做的内部测试和与客户一起做的测试（一个大型金融机构）表明。BEA具有良好的线性可扩展性。性能是IBM的1.5-2.5倍
WebSphere的可用性比weblogic低.如:IBM没有提供热部署功能.意味着当你对应用做修改并要重新发布时，你必须重新启动应用或
应用服务器才能生效。BEA在性能和可靠性，可扩展性，可用性等方面的优势。使BEA在很多与IBM的竞争中获胜,如: UPS, GE Capital,
Verizon, NIST, TIM Peru等.
互操作性
IBM的产品很大程度上限制在IBM自己的产品线上(DB2,Tivoli,AIX等)
IBM提供自己的数据库，硬件，操作系统，内容管理，安全产品，消息中间件，管理软件等，并由他的服务部门提供支持。
很多大型企业都有来自不同厂家的软硬件环境.他们希望应用平台软件能支持这样的环境。而IBM很难做到或做的不好。
相反,BEA做为独立软件供应商,提供一个开放的基础架构,可以在异构环境(不同的数据库,硬件,操作系统,内容管理,安全产品)
中即插即用,BEA的独立性,使他必须支持不同厂家的产品,并与他们建立Partner良好的合作关系.而Partner也乐意采用BEA的产品。
可靠性，可扩展性,可用性
根据最近的公开评测和客户的反映表明：BEA在可靠性（reliability），可扩展性(scalability)，性能(performance),
可用性（availablity）方面领先于IBM。
BEA最近所做的内部测试和与客户一起做的测试（一个大型金融机构）表明。BEA具有良好的线性可扩展性。性能是IBM的1.5-2.5倍
WebSphere的可用性比weblogic低.如:IBM没有提供热部署功能.意味着当你对应用做修改并要重新发布时，你必须重新启动应用或
应用服务器才能生效。BEA在性能和可靠性，可扩展性，可用性等方面的优势。使BEA在很多与IBM的竞争中获胜,如: UPS, GE Capital,
Verizon, NIST, TIM Peru等.
互操作性
IBM的产品很大程度上限制在IBM自己的产品线上(DB2,Tivoli,AIX等)
IBM提供自己的数据库，硬件，操作系统，内容管理，安全产品，消息中间件，管理软件等，并由他的服务部门提供支持。
很多大型企业都有来自不同厂家的软硬件环境.他们希望应用平台软件能支持这样的环境。而IBM很难做到或做的不好。
相反,BEA做为独立软件供应商,提供一个开放的基础架构,可以在异构环境(不同的数据库,硬件,操作系统,内容管理,安全产品)
中即插即用,BEA的独立性,使他必须支持不同厂家的产品,并与他们建立Partner良好的合作关系.而Partner也乐意采用BEA的产品。
开发效率
由于没有象Workshop那样的统一的开发工具，在WebSphere上开发不同的IT系统要用不同的工具。需要不同的技能，使开发效率十分低下。
IBM没有提供象Workshop（IDE+Framework）那样的开发工具，无法使各种层次的开发人员，在一个工具中完成不同IT系统（的开发，测试，
部署工作。根据最近，美国Crossvale 公司对IBM的开发工具WSAD5.0与BEA的开发工具Workshop8.1进行的对比研究显示：开发,
部署相同复杂的多层应用,WSAD需要的代码行数大约是 Workshop 的4倍，花费的时间大约是WebLogic Workshop的8倍。
反映出了WSAD 所需的低层J2EE开发的复杂性，而Workshop 的抽象层则相对简单，能够使开发人员充分利用先进的 J2EE 功能，
无需直接编写J2EE 代码。大大提高开发人员的效率。
因为IBM底层基础结构不统一，其中包括WebSphere Application Server、WebSphere Business Integration、 WebSphere MQSeries、
WebSphere Portal。这些产品有些是采用JAVA开发的，有些是采用C开发的。WebSphere 产品家族提供的多个开发工具也无法做到真正的
统一（象Workshop那样），组成WebSphere 的一百多个产品也无法统一。开发人员在开发不同的IT系统时要使用不同的工具，
而且每个工具的使用都需要掌握非常不同的知识和技能