WebSphere Application Server 常见问题及解答：开发与部署
2009-08-17 09:50
1. WAS 产品包中的 Application Server Toolkit 可以为您的开发和运行提供哪些帮助？

答：
Application Server Toolkit（AST）为创建面向 WebSphere Application Server V6.1 的新应用程序提供了基本的支持。其中包括用于创建新的 Web 应用程序、Web 服务、Portlet、EJB 组件的各种向导和工具，以及基于注释的编程支持、新的管理工具、用于编辑 WebSphere 特定绑定和扩展的工具，等等。  WAS V6.1包括了 J2EE 透视图和 Web 透视图、Eclipse 3.1 和 Eclipse Web Tools Platform（WTP） Version 1.0。它本身是一个完整的 J2EE 开发环境，因此您可以使用它构造、调试并直接将新的应用程序部署到 WebSphere Application Server V6.1。  尽管完全能够开发 J2EE 应用程序，但 AST 只是 IBM Rational® 开发环境，如 Rational Software Architect 和 Rational Application Developer的子集。图2中所示的层次结构能够很好的表明这几种工具组合的关系。外层的工具提供的功能完全包含内层工具提供的功能。

图2 集成开发环境
WAS V6.1 中的 AST 在 Eclipse Web Tools Platform 的基础上提供了下列关键特性：
∙ 用于 WebSphere Application Server 的服务器工具，如调试和单元测试支持。
∙ 支持 WebSphere Application Server 特定扩展，如 SIP 和 Jython 工具。
∙ 用于 WebSphere Application Server 属性文件和部署描述符的图形编辑器。

Rational 组合甚至提供了更多的扩展特性，其中一些关键的特性包括：
∙ 建模和可视化工具。
∙ 分析、验证和代码更正工具。
∙ 测试和分析工具。
∙ 支持多种服务器类型。

AST 被授权作为 WebSphere Application Server 的组件部分。可以对其进行无限制的复制，这使得 AST 可以用于开发面向 WebSphere Application Server V6.1 的应用程序。  有关 WAS 和 AST的更多资源，请参阅 developerWorks 中国站点的文章《Hello World，第 4 部分：WebSphere Application Server 和 Application Server Toolkit V6.1》。
2. 是否用 MDB（Message-Driven Bean）来侦听 MQ 队列?

答：
我们建议用MDB（Message-Driven Bean）来侦听MQ队列。因为MDB实现了多线程的处理方式，而且MDB是EJB的规范，程序员进行编程和维护都很方便。MDB有着自己的容器来管理这些线程，使应用不必关心MQ侦听和线程池的各种细节。
3. 如何处理 JSP 的中文显示问题？

答：
在 WAS 中您需要采取以下两个步骤解决 JSP 的中文显示问题： 1．在每个jsp文件的最前面添加下面两行：

<%@ page c %>

<%request.setCharacterEncoding("GBK");%> 2．在控制台上，选中Server > Java 和进程管理 > 进程定义 > Java 虚拟机，设置通用 JVM 参数：

ding=GBK

ding.override=GBK

ding=GBK  有关Web开发中字符处理的更多资源，请参阅 developerWorks 中国站点的文章：
∙ 《JSP/Servlet 中的汉字编码问题》
∙ 《UTF-8 字符处理在 Web 开发中的应用》
4. 在 WAS 中连接 MQ 有哪些方式？最佳方式是什么？

答：
通常，在 WAS 中连接 WebSphere MQ 的方式有以下三种方式： 1. 使用 WebSphere MQ webserver接口开发链路

使用 WAS 的管理控制台来配置和管理 WebSphere MQ 链路（WebSphere MQ Link）。该方式在WAS的服务集成总线（SI BUS）与 WebSphere MQ 消息传递网络中的队列管理器之间提供直接连接。连接方式类似 WebSphere MQ 的 server 和 server 的连接，这里把WAS 看作一个 WebSphere MQ Server 来进行配置。  2. 在 WebSphere Application Server 中配置WebSphere MQ 服务器

使用WAS 的管理控制台配置一个 WebSphere MQ 服务器。该方式在 WebSphere Application Server 中的服务集成消息传递引擎与 z/OS WebSphere MQ 队列管理器或队列共享组之间提供直接连接。但是，配置在 WAS 中的 WebSphere MQ 服务器已设计为利用 WebSphere MQ on z/OS 网络提供的高可用性和最优负载均衡特征。所以，这种方式适用于在 WAS 中连接在 z/OS 上的 WebSphere MQ 的情况。  3. 将 WebSphere MQ 用作 WAS 的外部 JMS 提供者

在这种方式中，作为外部 JMS 提供者的 WebSphere MQ 不会将服务集成总线消息传递连接至 WebSphere MQ 网络，它允许直接从 WebSphere Application Server 中访问 WebSphere MQ。采用这种方式，WAS 不需要配置 WebSphere MQ 服务器，也不需要设置SI BUS 相关的内容，只需要在创建 JMS 资源时，选择创建 WebSphere MQ 的资源（MQQueueConnectionFactory和MQQueue）即可。针对 WAS 和 WebSphere MQ 是否安装在同一台机器上，分别有两种配置方法：  (1) 如果 WAS 和 WebSphere MQ 在同一台服务器上，在配置 MQQueueConnectionFactory 的时候，其属性“transportType”选择“BINDING”。

(2) 如果 WAS 和 WebSphere MQ 不在同一台服务器上，在配置 MQQueueConnectionFactory 的时候，其属性“transportType” 选择“CLIENT”。 以上几种方式的详细描述参考WAS InfoCenter： publib.boulder.ibm/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.pmc.nd.doc/tasks/tjfp0015_.html 
综上所述，通过结合客户实际应用案例，连接 WebSphere MQ 的最佳方式为第三种，尤其当 WAS 和 WebSphere MQ 在同一台服务器上的情况下，即3-(1)。这种配置模式从 WAS 的角度来说最为简单，而且可靠性和性能也都是最佳的。如果 WAS 和 WebSphere MQ 不能在同一台服务器上则推荐3-(2)，性能仅次于3-(1)的方式。

关于 WAS 与 WebSphere MQ 连接的更多资源，请访问 developerWorks 中国站点文章《保证 WebSphere Application Server 和 WebSphere MQ 之间连接的安全》： 第 1 部分/ 第 2 部分。
5. 我希望编写的 Web 应用能够支持尽可能多的客户端，有哪些注意事项？

答：
可以用一句话来概括：您依赖的功能越少，您能支持的客户端就越多。
∙ 少用ActiveX，Applet；
∙ 少用持久性cookies，但非持久性的 cookies没关系；
∙ 少用弹出式窗口；
∙ 使用Javascript通常没问题，但要小心：有些人会限制某些Javascript的运行；
∙ 使用各种插件存在风险。在主要功能上（如flash，media player）使用插件是不明智的。但在附加功能上使用插件没什么关系。
∙ 确信对敏感信息使用HTTPS，并要保证使用知名CA发行的证书。
6. 我是否可以在 WAS 上自己实现多线程编程和实现类加载器？

答：
不建议开发者自己再去控制多线程应用程序的实现，因为WebSphere已经提供了多线程的容器。每一个请求在WAS里运行都是在独立的一个线程里运行的。如果应用程序自己实现多线程编程，产生新的线程和维护线程对系统来说都有很大的系统开销。另外WebSphere已经提供了类加载器，应用程序也不需要实现自己的类加载器。
7. 在多个独立的 WebSphere 应用程序服务器环境中，一个服务器上的应用程序该如何访问运行在其他服务器上的应用程序？

答：
这涉及到名字空间（namespace）的联合问题。举例说明：
假设我们有两个独立的WebSphere 应用服务器Server1和Server2，为了让Server1上运行的程序能够访问Server2上的EJB程序，我们需要使用CorbaName绑定Server1和Server2的名字空间。在联合上下文之前，运行Server1上的/bin目录下的dumpNameSpace.sh/bat命令，如：

dumpNameSpace.sh -root server –port 2809 这时只会列出Server1的名字空间里的内容。下面，我们把Server2的名字空间绑定到Server1上。在Server1的管理控制台上，选择“环境”>“命名”> “名称空间绑定”，作用域选择“节点1”>“Server1”，点击“新建”, 选择“CORBA”绑定类型, 指定“绑定标识”，在名称空间中的名称中输入Server2（这是我们希望使用的名字），在“Corba名称 URL”中输入如下类似内容：

corbaname:iiop:*.*.*.*:2810#nodes/NODE1/servers/server2

选中“联合上下文”。此时，运行：

dumpNameSpace.sh -root server –port 2809

这时也会列出Server2的名字空间里的内容。于是，当我们把Server1作为Server2的Client 时，原来的 JNDI 名字“ejb/ibm/CMPHome”应该被改成“server2/ejb/ibm/CMPHome”。 综上，为了让不同服务器上的应用程序实现互访，关键要做到名字空间的共享。一旦把一台服务器的名字空间共享给另一台服务器，则第二台服务器上的应用程序通过修改JNDI名字，就可以轻松访问第一台服务器上的应用程序了。
8. 对于EJB的部署代码，是在构建应用程序时生成好，还是在部署应用程序时生成好？

答：
这依赖于具体的环境：
∙ 如果您确定服务器的版本、数据库的类型，那么在构建应用程序时直接生成一个完整的可运行的EAR包会比较好。
∙ 如果您需要在不同的服务器版本、不同的数据库上运行EJB应用程序，那么应该在部署应用程序时选中"部署EJB"按钮。
另一个经验是：在开发测试较大的应用程序时，根据不同的阶段，既可以在构建时部署EJB，又可以在部署应用程序时部署EJB。细说如下：
∙ 在开发早期阶段，如果使用IBM的开发工具，则可由开发者直接生成完整的EAR包，其中包含被部署过的EJB代码，便于开发者进行单体测试和功能测试。
∙ 在开发阶段中期，当这些代码被加到某个库系统中后，需在库系统中统一构建库。此时，要到部署应用程序时再部署EJB。 例如，在管理部署一个含有第三方编写的EJB的应用程序时，由于不能完整构建整个应用，所以需要在部署应用时部署EJB。
∙ 然而，在安装产品阶段，此时通常会使用wsadmin自动脚本，因为没法在部署应用时部署EJB，所以需要在构建应用程序时就部署EJB。
9. 关于 Java EE 开发，有哪些最佳实践应该采纳？

答：
这里我们总结了 19 条Java EE 开发的最佳实践：

1. 始终使用 MVC 框架：将业务逻辑（Java Bean 和 EJB 组件）从控制器逻辑（Servlet/Struts 操作）和表示逻辑（JSP、XML/XSLT）中清晰地分离出来。良好的分层可以带来许多好处。

2. 不要做重复的工作：使用常见的、经过证实的框架，如 Apache Struts、JavaServer Faces 和 Eclipse RCP。

3.在每一层都应用自动单元测试和测试管理：不要只是测试您的图形用户界面（GUI）。分层的测试使得调试和维护工作变得极其简单。

4. 按照规范来进行开发，而不是按照应用服务器来进行开发：要将规范熟记于心，如果要背离规范，需经过慎密的考虑后才可以这样做。这是因为当您背离规则的时候，您所做的事情往往并不是您应该做的事情。

5. 从一开始就计划使用 Java EE 安全性：启用 WebSphere 安全性。锁定您的 EJB 和 URL，只允许所有授权用户访问。

6. 构建您所知道的：迭代的开发工作将使您能够逐渐地掌握所有的 Java EE 模块。要从创建小而简单的模块开始而不是从一开始就马上涉及到所有的模块。

7. 使用 EJB 组件时，始终使用会话 Façade：在体系结构合适的情况下，使用本地 EJB。

8. 使用无状态会话 Bean，而不是有状态会话 Bean：这样做可以使您的系统更经得起故障考验。使用 HttpSession 存储和用户相关的状态。

9. 使用容器管理的事务：学习一下 Java EE 中的两阶段提交事务，并且使用这种方式，而不是开发您自己的事务管理。容器在事务优化方面几乎总是比较好的。

10.将 JSP 作为表示层的首选：只有在需要多种表示输出类型，并且输出类型必须被单一的控制器及后端支持时才使用 XML/XSLT。

11. 当使用 HttpSession 时，尽量只将当前事务所需要的状态保存其中，其他内容不要保存在 HttpSession 中：启用会话持久性。

12. 充分利用应用服务器中不需要修改代码的特性：使用某些特性（如 WebSphere Application Server 缓存和 Prepared Statement

缓存）可以极大地提高性能，并且使得开销最小。

13. 充分利用现有的环境：提供一个 Java EE EAR 和可配置的安装脚本，而不是黑盒二进制安装程序。

14. 充分利用应用服务器环境所提供的服务质量：设计可使用 WebSphere Application Server Network Deployment 集的应用程序。

15. 充分利用 Java EE，不要欺骗：致力于构建真正利用 Java EE 功能的 Java EE 应用程序。

16. 安排进行版本更新：更改是在所难免的。安排新的发行版和修复程序更新，以便您的客户能够获得最新的版本。

17. 在代码中所有关键的地方，使用标准的日志框架记录程序的状态：这包括异常处理程序。使用像 JDK 1.4 Logging 或 Log4J 这样的日志框架。

18. 在完成相应的任务后，请始终进行清理：如果您从池中获取了一个对象，请始终确保将其返回到池中。

19. 在开发和测试过程中遵循严格的程序：这包括采用和遵循软件开发方法学。  由于篇幅的原因，在这里不能详细阐述，更多内容请访问 developerWorks 中国站点文章《IBM WebSphere 开发者技术期刊：最重要的 Java EE 最佳实践》。
10. 我可以在 WAS CE 上运行 PHP 吗？

答：
可以通过 PHP Integration Kit 让 IBM 的开源服务器 WebSphere Application Server Community Edition（WAS CE） 支持 PHP 脚本。
PHP 是一种在 web 应用开发中非常受欢迎的脚本语言。当我们使用 PHP 作为服务器端脚本时，需要运行在 Apache HTTP 服务器或者 Microsoft IIS 这样的 web 服务器上。虽然我们可以在 Apache HTTP 服务器上同时配置 PHP 和 JSP 支持，但是需要将 PHP 和 JSP 请求分别转发到相应的 PHP 引擎或者 Java 应用服务器，在 PHP 脚本和 JSP 代码之间没有建立关系，也不能在一个 HTML 页面中混合使用 PHP 脚本和 JSP 代码。

通过 PHP Integration Kit for WebSphere Application Server (WAS)，Community Edition (CE)，我们可以将 PHP 脚本集成到 Java 2 Enterprise Edition (J2EE) 应用中，例如通过 Container Managed Security (CMS) 来控制对 PHP 脚本的访问权限，通过 WAS CE 的管理控制台来安装/更新 PHP 应用，还可以通过 Java Filter 技术来修饰包含 PHP 脚本的 HTML 页面。您可以在 IBM alphaWorks 网站到这个项目的最新信息，目前支持的平台有 Windows 和 Linux，不过现在这个项目还不能使用在产品环境中。

PHP Integration Kit 通过在 Servlet 容器中配置 FastCGI filter，将 PHP 脚本请求转发到 PHP 引擎。PHP Integration Kit 提供了一个 launcher 来调用 PHP 引擎。需要指出的是 PHP Integration Kit 并没有重新构建一个 PHP 的引擎，而是需要利用现有的 PHP 引擎（这个比较容易理解，因为 PHP 引擎是由 PHP 提供和维护的）。如果系统中安装有多个版本的 PHP 引擎，可以在 web 部署描述文件 l 中对 PHP 引擎进行配置。

由于篇幅的原因，在这里不能详细阐述。更多关于 PHP Integration Kit 安装和配置的信息请访问 developerWorks 中国站点文章《在 WebSphere Application Server Community Edition 上运行 PHP》。
11、问题：在 WebSphere Application Server 中能否部署多个共存应用程序？

答：
可以。在 IBM WebSphere Application Server 的单一实例中部署多个共存应用程序在某些环境中具有一定的好处，但在问题隔离和问题确定方面也会产生一些特有的困难。

优点

1,成本较低。此方法的主要好处就是其规模上的经济性。用少量的物理服务器和服务器进程承载大量的应用程序通常可以在硬件资源、基础结构、软件成本和系统管理成本方面节约大量的开支。

2,资源共享。在一个服务器实例中，多个应用程序之间共享资源这一概念使得更好地利用资源成为可能。一个应用程序的空闲期可能是另一应用程序的峰值期。当然，这也可能是多个独立服务器共享一个通用的硬件资源池，还可能是在单个应用服务器进程中进一步共享其他资源池（例如，共享内存池、数据库连接池等等）。就其本质而言，这实际上就是随需应变的计算原则。

缺点

1,问题确定。如果一个服务器崩溃或者开始出现某些异常行为（例如响应时间缓慢、出现错误消息等等），则在同一服务器上同时部署的多个应用程序中，可能很难确定究竟是哪个应用程序造成了此问题，是直接造成的还是间接造成的。事实上，仅关注一个应用程序中的缺陷或错误配置可能是不够的；基础 WebSphere Application Server 运行时中的某个缺陷或错误配置可能以不同的方式影响不同的应用程序--或者可能由于某些特定的应用程序存在而触发，进而影响其他应用程序。在这些情况下，多个应用程序的共存可能使探究问题的根本原因更加困难。

2,问题隔离。由于多个应用程序共享环境中的许多通用资源，源于一个应用程序中的任何问题都可能最终影响在同一服务器上运行的其他应用程序。这些问题可能是从与性能调整相关的细微影响到服务器完全瘫痪，通常需要应用程序部署人员和管理员在处理不同的应用程序时协调他们的活动。  本答案，来自 IBM WebSphere 开发者技术期刊中的在 WebSphere Application Server 中部署多个共存应用程序并解决相应的问题

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。