WebLogic初步理解

BEA WebLogic Server具有开发和部署关键任务电子商务Web应用系统 所需的多种特色和优势，包括：

1) 标准

对业内多种标准的全面支持，包括EJB、JSP、JMS、JDBC、XML和WML，使Web应用系统的实施更为简单，并且保护了投资，同时也使基于标准的解决方案的开发更加简便。

2) 可扩展性

BEA WebLogic Server以其高扩展的架构体系闻名于业内，包括客户机连接的共享、资源pooling以及动态网页和EJB组件群集。

3) 快速开发

凭借对EJB和JSP的支持，以及BEA WebLogic Server 的Servlet组件架 构体系，可加速投放市场速度。这些开放性标准与WebGain Studio配合时，可简化开发，并可发挥已有的技能，迅速部署应用系统。

4) 更趋灵活

BEA WebLogic Server的特点是与领先数据库、操作系统和Web服务器紧密集成。

5) 可靠性等等

但在一份WebLogic中间件报告中了解到了WebLogic也存在一些安全隐患。例如报告中说的：由于应用程序中频繁使用了超大对象，导致Full GC执行得比较频繁，整体性能受Full GC影响比较大及由于不恰当��设置JVM启动参数，导致JVM堆内存区域划很不合理，当业务访问比较频繁的时候，系统的整体性能难以发挥等情况。

因此也查阅了关于WebLogic Web服务的安全性问题，比如保护WebLogic Web服务，提供身份验证参考（www.w3c.org/Protocols/Specs.html ）。

1. 保护消息风格的Web服务

    可以通过保护负责处理客户端和服务之间SOAP消息的SOAP servlet，来保护消息风格的Web服务。

不论是手动还是使用wsgen Ant任务来组装Web服务时，都可以在Web应用程序的web.xml文件中引用SOAP servlet。这些servelet负责处理在WebLogic Server和客户端应用程序之间传递的SOA消息。它们始终部署在WebLogic Server上，并为所有部署的WebLogic Web服务所共享。

2. HTTP身份验证

HTTP是一个无状态协议--也就是说，一旦请求完成之后，服务器不会记住关于该请求的任何信息--浏览器需要为每个请求重新发送用户名和密码第一次访问需验证的资源时，服务器将返回401状态（“Unauthorized”），并包括一个WWW身份验证的响应头，用于指明所使用的域名和身份验证模式。然后，浏览器应该要求用户输入用户名和密码。接着，它再次请求同样的资源，这次包括了一个含有模式名（“Basic”）的身份验证头，以及输入的用户名和密码。服务器检查此用户名和密码，如果它们是有效的，就会返回相应的页面。如果密码对于该用户无效，或者用户没有访问权限，服务器还会像以前一样返回401状态。然后，浏览器可以要求用户尝试重新输入用户名和密码。

假定用户名和密码有效，接下来用户可能会请求一个受保护的资源。在这种情��下，服务器将使用401状态作为响应，而浏览器能够使用用户和密码详细信息再次发送请求。这样做会很慢，然而对于随后的请求，浏览器就会改为发送身份验证头。

“安全隐患”中提到的Full GC，难道是WebLogic独有的吗？

tomcat也有