-
[转] 中间件技术的概念与分类
2009-02-23 11:13:37
转自:
http://tech.it168.com/d/2008-04-11/200804112227497.shtml
一、为什么要中间件
计算机技术迅速发展。从硬件技术看，CPU速度越来越高，处理能力越来越强；从软件技术看，应用程序的规模不断扩大，特别是Internet及WWW的出现，使计算机的应用范围更为广阔，许多应用程序需在网络环境的异构平台上运行。这一切都对新一代的软件开发提出了新的需求。在这种分布异构环境中，通常存在多种硬件系统平台(如PC，工作站，小型机等)，在这些硬件平台上又存在各种各样的系统软件(如不同的操作系统、数据库、语言编译器等)，以及多种风格各异的用户界面，这些硬件系统平台还可能采用不同的网络协议和网络体系结构连接。如何把这些系统集成起来并开发新的应用是一个非常现实而困难的问题。
二、什么是中间件为解决分布异构问题，人们提出了中间件(middleware)的概念。中间件是位于平台(硬件和操作系统)和应用之间的通用服务，如图1所示，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件平台，它们可以有符合接口和协议规范的多种实现。
图1 中间件
也许很难给中间件一个严格的定义，但中间件应具有如下的一些特点：
满足大量应用的需要
运行于多种硬件和OS平台
支持分布计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互
支持标准的协议
支持标准的接口
由于标准接口对于可移植性和标准协议对于互操作性的重要性，中间件已成为许多标准化工作的主要部分。对于应用软件开发，中间件远比操作系统和网络服务更为重要，中间件提供的程序接口定义了一个相对稳定的高层应用环境，不管底层的计算机硬件和系统软件怎样更新换代，只要将中间件升级更新，并保持中间件对外的接口定义不变，应用软件几乎不需任何修改，从而保护了企业在应用软件开发和维护中的重大投资。
三、主要中间件的分类
中间件所包括的范围十分广泛，针对不同的应用需求涌现出多种各具特色的中间件产品。但至今中间件还没有一个比较精确的定义，因此，在不同的角度或不同的层次上，对中间件的分类也会有所不同。由于中间件需要屏蔽分布环境中异构的操作系统和网络协议，它必须能够提供分布环境下的通讯服务，我们将这种通讯服务称之为平台。基于目的和实现机制的不同，我们将平台分为以下主要几类：
远程过程调用（Remote Procedure Call）
面向消息的中间件（Message-Oriented Middleware）
对象请求代理（Object Request Brokers）
它们可向上提供不同形式的通讯服务，包括同步、排队、订阅发布、广播等等，在这些基本的通讯平台之上，可构筑各种框架，为应用程序提供不同领域内的服务，如事务处理监控器、分布数据访问、对象事务管理器OTM等。平台为上层应用屏蔽了异构平台的差异，而其上的框架又定义了相应领域内的应用的系统结构、标准的服务组件等，用户只需告诉框架所关心的事件，然后提供处理这些事件的代码。当事件发生时，框架则会调用用户的代码。用户代码不用调用框架，用户程序也不必关心框架结构、执行流程、对系统级API的调用等，所有这些由框架负责完成。因此，基于中间件开发的应用具有良好的可扩充性、易管理性、高可用性和可移植性。
下面，针对几类主要的中间件分别加以简要的介绍。
1、远程过程调用
远程过程调用是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来“远程”执行一个位于不同地址空间里的过程，并且从效果上看和执行本地调用相同。事实上，一个RPC应用分为两个部分：server和client。server提供一个或多个远程过程；client向server发出远程调用。server和client可以位于同一台计算机，也可以位于不同的计算机，甚至运行在不同的操作系统之上。它们通过网络进行通讯。相应的stub和运行支持提供数据转换和通讯服务，从而屏蔽不同的操作系统和网络协议。在这里RPC通讯是同步的。采用线程可以进行异步调用。
在RPC模型中，client和server只要具备了相应的RPC接口，并且具有RPC运行支持，就可以完成相应的互操作，而不必限制于特定的server。因此，RPC为client/server分布式计算提供了有力的支持。同时，远程过程调用RPC所提供的是基于过程的服务访问，client与server进行直接连接，没有中间机构来处理请求，因此也具有一定的局限性。比如，RPC通常需要一些网络细节以定位server；在client发出请求的同时，要求server必须是活动的等等。
2、面向消息的中间件MOM指的是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可在分布环境下扩展进程间的通信，并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM中间件产品有IBM的MQSeries、 BEA的MessageQ等。消息传递和排队技术有以下三个主要特点：
通讯程序可在不同的时间运行:程序不在网络上直接相互通话，而是间接地将消息放入消息队列，因为程序间没有直接的联系。所以它们不必同时运行。消息放入适当的队列时，目标程序甚至根本不需要正在运行；即使目标程序在运行，也不意味着要立即处理该消息。
对应用程序的结构没有约束:在复杂的应用场合中，通讯程序之间不仅可以是一对一的关系，还可以进行一对多和多对一方式，甚至是上述多种方式的组合。多种通讯方式的构造并没有增加应用程序的复杂性。
程序与网络复杂性相隔离: 程序将消息放入消息队列或从消息队列中取出消息来进行通讯，与此关联的全部活动，比如维护消息队列、维护程序和队列之间的关系、处理网络的重新启动和在网络中移动消息等是MOM的任务，程序不直接与其它程序通话，并且它们不涉及网络通讯的复杂性。
3、对象请求代理
随着对象技术与分布式计算技术的发展，两者相互结合形成了分布对象计算，并发展为当今软件技术的主流方向。1990年底，对象管理集团OMG首次推出对象管理结构OMA(Object Management Architecture)，对象请求代理（Object Request Broker）是这个模型的核心组件。它的作用在于提供一个通信框架，透明地在异构的分布计算环境中传递对象请求。CORBA规范包括了ORB的所有标准接口。1991年推出的CORBA 1.1 定义了接口描述语言OMG IDL和支持Client/Server对象在具体的ORB上进行互操作的API。CORBA 2.0 规范描述的是不同厂商提供的ORB之间的互操作。
对象请求代理(ORB)是对象总线，它在CORBA规范中处于核心地位，定义异构环境下对象透明地发送请求和接收响应的基本机制，是建立对象之间client/server关系的中间件。ORB使得对象可以透明地向其他对象发出请求或接受其他对象的响应，这些对象可以位于本地也可以位于远程机器。ORB拦截请求调用，并负责找到可以实现请求的对象、传送参数、调用相应的方法、返回结果等。client对象并不知道同server对象通讯、激活或存储server对象的机制，也不必知道server对象位于何处、它是用何种语言实现的、使用什么操作系统或其他不属于对象接口的系统成分。
值得指出的是client和server角色只是用来协调对象之间的相互作用，根据相应的场合，ORB上的对象可以是client，也可以是 server，甚至兼有两者。当对象发出一个请求时，它是处于client角色；当它在接收请求时，它就处于server角色。大部分的对象都是既扮演 client角色又扮演server角色。另外由于ORB负责对象请求的传送和server的管理，client和server之间并不直接连接，因此，与RPC所支持的单纯的Client/Server结构相比，ORB可以支持更加复杂的结构。
4、事务处理监控
事务处理监控（Transaction processing monitors）最早出现在大型机上，为其提供支持大规模事务处理的可靠运行环境。随着分布计算技术的发展，分布应用系统对大规模的事务处理提出了需求，比如商业活动中大量的关键事务处理。事务处理监控界于client和server之间，进行事务管理与协调、负载平衡、失败恢复等，以提高系统的整体性能。它可以被看作是事务处理应用程序的“操作系统”。总体上来说，事务处理监控有以下功能：
进程管理，包括启动server进程、为其分配任务、监控其执行并对负载进行平衡。
事务管理，即保证在其监控下的事务处理的原子性、一致性、独立性和持久性。
通讯管理，为client和server之间提供了多种通讯机制，包括请求响应、会话、排队、订阅发布和广播等。
事务处理监控能够为大量的client提供服务，比如飞机定票系统。如果server为每一个client都分配其所需要的资源的话，那 server将不堪重负（如图2所示）。但实际上，在同一时刻并不是所有的client都需要请求服务，而一旦某个client请求了服务，它希望得到快速的响应。事务处理监控在操作系统之上提供一组服务，对client请求进行管理并为其分配相应的服务进程，使server在有限的系统资源下能够高效地为大规模的客户提供服务。
图2 事务处理监控
四、面临的一些问题
中间件能够屏蔽操作系统和网络协议的差异，为应用程序提供多种通讯机制；并提供相应的平台以满足不同领域的需要。因此，中间件为应用程序了一个相对稳定的高层应用环境。然而，中间件服务也并非“万能药”。中间件所应遵循的一些原则离实际还有很大距离。多数流行的中间件服务使用专有的API和专有的协议，使得应用建立于单一厂家的产品，来自不同厂家的实现很难互操作。有些中间件服务只提供一些平台的实现，从而限制了应用在异构系统之间的移植。应用开发者在这些中间件服务之上建立自己的应用还要承担相当大的风险，随着技术的发展他们往往还需重写他们的系统。尽管中间件服务提高了分布计算的抽象化程度，但应用开发者还需面临许多艰难的设计选择，例如，开发者还需决定分布应用在client方和server方的功能分配。通常将表示服务放在client以方便使用显示设备，将数据服务放在server以靠近数据库，但也并非总是如此，何况其它应用功能如何分配也是不容易确定的。
-
[转] 对常见的WEB服务器和应用服务器的介绍
2009-02-23 10:30:55
-
[转]WebSphere环境搭建实践指南（二）
2008-12-19 14:10:26
转载自：
http://tech.it168.com/jd/2007-08-23/200708230733862.shtml
在生产环境中安装WAS完毕并创建了一个可用的概要文件之后，必须根据实际情况进行必要参数的调整，以便提高WAS性能、方便错误诊断。这些参数通常要结合运行环境的实际情况、实际的并发量和服务器的资源利用情况进行调整。完整的调优涉及操作系统、应用、应用服务器和数据库的综合调整，具体要调整的参数、含义，请参见WAS资源中提到的资源监控和性能调优章节，例如，红皮书sg246392的17.5章节中明确谈到了性能调优通常涉及的参数以及调整原则。本文提出的只是针对应用服务器本身一些重要的参数调整的指导原则和经验之谈，以便读者能够快速起步：
- Java虚拟机堆大小（JVM Heap Size）: 控制JVM代码可使用的堆大小，单位M。该参数在服务器->应用程序服务器>进程定义>Java虚拟机中进行设置。JVM最大堆大小默认是256M，在生产环境中通常要根据机器物理内存情况、应用运行特性来设置，且多数情况下都要把此参数调大。根据经验，内存充足时，通常的调整在500M到1024M之间。需要注意的是，建议JVM Heap的最大值不要超过1024M，如果JVM Heap Size过大，可能会引起内存分页，或者造成JVM垃圾回收时间过长，反而影响应用服务器性能。有关Java虚拟机调优的具体信息，请参考调整JVM参数。
- Web容器线程池：该参数在“服务器 > 应用程序服务器 > server1 > 线程池”的“WebContainer”中进行设置（如图6），默认值是10到50。如果硬件资源允许，通常会把线程池的最大大小调到100。
图 6. 调整线程池
- 数据源连接池：该参数在资源->JDBC->数据源->数据源名称，选择“连接池设置”中设置，默认大小为1到10。根据资源设置的队列(Queue)原则，从Web容器线程池，到数据源连接池的参数设置，应该是从大到小的管道。前面我们列举了Web容器线程池的最大值设置100，对于数据源连接池，设置的最大值通常不超过50。多数情况下调整为30。实际运行中可以修改此参数值，观察调整对性能是否有正面影响。注意，如果把数据库连接池最大大小调得过大，JVM有限的资源都耗费在维护连接池、处理与数据库连接上，可能反而造成WAS性能的下降。
- WAS 进程日志参数：WAS进程日志常用的有SystemOut.log和SystemErr.log。这两份日志默认大小为1M，历史日志文件数为1份。在生产环境中，这样的设置通常不足以充分保存发生问题时的错误信息。我们可以通过修改日志默认大小、历史日志文件数来保存更多的信息。注意，不要把单份日志文件大小设置过大（例如，超过10M以上），否则可能影响WAS性能。另外，我们建议把应用日志与WAS日志分离开。如果应用中大量以System.out.print或者System.err.print来保存应用状态日志，也可能会影响服务器性能。
图 7. 修改WAS日志属性
- Heapdump文件：前面我们提到，Heapdump文件对磁盘空间占用很快，因此，可以设置IBM_HEAPDUMP参数把Heapdump文件存放到指定目录下。
- Web服务器的访问日志access.log：IBM Http Server的访问日志access.log默认是打开的，其中记录了经过Http服务器的请求信息。在高并发的系统中，这一日志增长非常过，当日志过大时，可能占用过多磁盘空间或引起性能下降，如果您的系统不需要这份日志，或者有其他技术手段保存用户访问信息，可以关闭该日志。具体做法为：打开IBM Http Server安装目录/conf目录下的httpd.conf文件，搜索CustomLog，把CustomLog所在行用#注释掉即可。
由于生产环境访问控制的需要，搭建WebSphere环境之后，通常可能会要求修改应用访问端口，或者更改WAS管理员密码，启用/停用管理安全性等等。
应用服务器安装完毕之后，为了避免生产环境中的端口冲突、端口访问控制，有时我们需要查看或更改应用服务器的端口。
- 查看端口
- 更改应用访问端口
默认情况下，WAS的管理控制台和应用访问是两个不同的端口。访问WAS的管理控制台或者WAS上部署的应用，所使用的端口由应用服务器端口以及虚拟主机决定。假设我们要把应用访问的端口从9080变成9082（实际工作中，如果没有Web服务器，有的环境会希望把应用访问端口变成80，方法类似），则按如下步骤进行：登陆WAS管理控制台，选择 左边菜单 服务器 － 应用服务器，点击 server1，选择“端口”，点击“WC_defaulthost”（如图8），修改端口为自己想要的任意端口（注意避免端口冲突），例如，9082。然后点击“确定”。然后“保存”。
图 8. 修改应用访问端口
然后，选择 左边菜单 环境 － 虚拟主机，点击”default_host”，选择“主机别名”（如图9），把原有端口9080改成与前面应用服务器/端口/WC_defaulthost一致的端口，例如，9082。或者点击“新建”，把在WC_defaulthost修改之后的端口号填入，点击“确定”、“保存”。
图 9. 修改虚拟主机
当然，如果你在前面应用服务器/端口/WC_defaulthost中设置的端口已经出现在虚拟主机/default_host/主机别名的列表中，则不需要做改动或者新增主机别名端口的工作。目的就是要让 应用服务器/端口/WC_defaulthost的端口出现在 虚拟主机/default_host的主机别名列表中。更改在重启WAS服务器之后生效。
- 更改WAS管理控制台端口
登陆WAS管理控制台，选择 左边菜单 服务器 － 应用服务器，点击 server1选择“端口”。然后更改WC_adminhost为自己希望的管理控制台端口。然后点击“确定”、“保存”。选择 左边菜单 环境 － 虚拟主机，点击；然后选择admin_host，选择“主机别名”。把原有端口9060改成与前面应用服务器/端口/WC_adminhost一致的端口，例如，9063。或者点击“新建”，创建一个主机别名 *, 9063。然后“确定”，“保存”。目的就是要让 应用服务器/端口/WC_adminhost的端口出现在 虚拟主机/admin_host的主机别名列表中。
-
针对生产环境要求的多变性，实际WAS环境搭建中可能涉及管理安全性的多种操作。
- 启用管理安全性
启用管理安全性将激活用于防止未经授权的用户使用服务器的设置，简单来说，进入管理控制台、更改应用服务器配置、停止应用服务器进程这些管理任务，都需要输入预先定义的用户名和密码才能完成。缺省情况下，创建概要文件时会启用管理安全性（图9）。如果在创建概要文件时没有选择“启用管理安全性”，在随后使用过程中又希望启用，则可按如下步骤进行：
首先进入控制台，例如：http://was_ip:9060/admin，注意这里登陆的用户一定要是设置安全性的用户。例如，admin。选择“安全性”>“安全管理、应用程序和基础结构”，然后点击“安全配置向导”(图10)。为了配置的简便性，在“指定保护范围”中，可以不选择“使用 Java 2 安全性来限制应用程序访问本地资源”；在“选择用户存储库”中接受默认选项，用户存储库为“联合存储库”，点击“下一步”；在配置用户存储库中填入用户名、密码。如果您是第一次启用管理安全性，则输入一个新的用户名（您登陆管理控制台的用户名）和密码。这个用户名密码是任意的，并不要求是操作系统用户，因为联合存储库默认的用户条目来自于文件；如果以前曾经使用该存储库启用过管理安全性，则使用存储库中持有管理员特权的用户名和密码。点击“下一步”、“完成”。保存之后重启应用服务器，这时登陆管理控制台等就需要提供您预定义的用户名/密码了。
图 10. 配置管理安全性
- 停用管理安全性
停用管理控制台很简单，在图10所示页面，不选择“启用管理安全性”，点击“应用”，保存并重启应用服务器即可。有一种特殊情况下，特如忘掉了管理员密码，此时我们无法登陆管理控制台，从而无法在管理控制台中停用管理安全性。这时，可从$WAS_HOME/profiles/xxx概要文件名/bin目录下，发出如下命令： wsadmin -conntype NONE 。当wsadmin的命令行窗口出现之后，发出下列命令： securityoff 。上述操作在应用服务器启动或停止的状态都能发出。再次启用WAS时，就是停用管理安全性的状态了。
- 更改管理员密码
当我们需要更改管理员密码时，可以选择“用户和组”>“管理用户”，如图11，在搜索内容为“*”时点击“搜索”，会列出该存储库中的所有用户。选中管理用户标识，可更改该用户的密码。更改即时生效。
- 停用管理安全性
停用管理控制台很简单，在图10所示页面，不选择“启用管理安全性”，点击“应用”，保存并重启应用服务器即可。有一种特殊情况下，特如忘掉了管理员密码，此时我们无法登陆管理控制台，从而无法在管理控制台中停用管理安全性。这时，可从$WAS_HOME/profiles/xxx概要文件名/bin目录下，发出如下命令： wsadmin -conntype NONE 。当wsadmin的命令行窗口出现之后，发出下列命令： securityoff 。上述操作在应用服务器启动或停止的状态都能发出。再次启用WAS时，就是停用管理安全性的状态了。
- 更改管理员密码
当我们需要更改管理员密码时，可以选择“用户和组”>“管理用户”，如图11，在搜索内容为“*”时点击“搜索”，会列出该存储库中的所有用户。选中管理用户标识，可更改该用户的密码。更改即时生效。
图 11. 管理用户
- 忘记管理员密码
如果忘记管理员密码，我们无法进入管理控制台更改密码。此时，需要先用“停用管理安全性”一节中wsadmin命令的方法，停用管理安全性，然后“更改管理员密码”，再次“启用管理安全性”即可。
- 创建更多的管理用户
使用启用管理安全性的WAS环境时，默认情况下只有一个管理员ID，这意味着同一时刻只有一个人能登陆管理控制台。这对于多人开发小组在同一WAS环境发布测试时并不方便。您可先在存储库中创建一个用户，然后为该用户ID分配相应的管理角色。具体步骤如下：1）选择“用户和组”>“管理用户”，如图24，点击“添加”，添加一个用户ID，例如，admin1。保存。 2） 选择“用户和组”>“管理用户角色”，如图25，填入用户名（必须是在存储库中已经存在的用户名），选择相应的管理角色，例如，“管理员”。点击“确定”，保存。这样，下次重启WAS时，两个用户都能同时登陆管理控制台。
生产环境、概要文件配置过于复杂或经常更改时，我们需要定期备份概要文件，以便必要时快速恢复。您可使用backupConfig 命令备份配置文件。例如，要备份概要文件AppSrv01的当前配置，可以从$WAS_HOME/profiles/AppSrv01/bin目录下，发出命令 backupConfig，它会将AppSrv01当前概要文件默认生成一个压缩包，您也可以指定该压缩包的名称，例如：backupConfig WebSphereConfig_2007_05_30.zip。恢复配置时，使用restoreConfig WebSphereConfig_2007_05_30.zip。
需要提醒的是，WAS的卸载过程不是直接删除目录，如果这样做，下次你可能无法在同一台机器上成功安装WAS。在卸载WAS之前，先停止机器上的WAS进程，用ps –ef |grep java确保没有was进程在运行。然后，执行WAS_HOME/uninstall/uninstall.sh命令卸载WAS。如果因为某些特殊原因卸载向导引导的卸载过程没有成功（例如，您直接删除了WAS安装目录），或者您希望在同一目录再次安装WAS，请参照信息中心“手工卸载”给出的建议。
- 启用管理安全性
应用部署通常会涉及如下几个任务：配置应用所需要的环境：如系统变量、虚拟主机、类路径、安全性等等；配置应用所需要的资源如JMS资源、数据源等。其中，需要注意的是：- 应用打包：部署在 WebSphere 应用服务器上的应用可以是打包的*.ear/*.war文件，也可以是未打包但符合J2EE规范要求的组件。在生产环境中，推荐使用打包的*.ear/*.war文件，便于版本控制和管理。对于复杂项目中多个J2EE组件的打包，请参见文章“关于J2EE应用开发项目包的管理”。
- 管理 Utility Jar包：大多数J2EE应用都会有一些公用的Utility Jar包，首先要强调的是：一定要避免在同一个类载入路径下存在同一个类的多个版本！这会在实际运行中带来很多莫名其妙且难以诊断的问题。其次，对于JDBC驱动这类通用等级较高的Utility Jar包，可以放置在<WAS_HOME>/lib/ext目录下；对于多个应用共享的Utility Jar，可以放在 <WAS_HOME>/lib/ext中，也可以放在shared library（共享库）中，推荐放在shared library中；对于单个应用使用的Utility Jar，可与应用打包在一起，或放入shared library中。共享库的使用能够避免Utility Jar包多个版本的混乱，以及Utility Jar包的冲突。共享库配置方法请参见红皮书sg247304 12.5.4 Step 4: Sharing utility JARs using shared libraries章节。
- Jar 包冲突：Jar包冲突问题在大型Java软件开发中经常遇到，简单的说，当不同应用使用的公用Utility Jar包、应用服务器底层的Jar包中存在同名、且版本不同的类时，我们称之为Jar包冲突。这种问题的解决办法可以参考文章如何在WebSphere中解决Jar包冲突 。
- 会话超时：针对应用场景的不同，不同应用期望的会话超时时间各不相同。WebSphere应用服务器的会话管理分为Application server、Application、Web Module三个级别。顾名思义，在每个特定级别上更改的会话管理的配置，对当前级别起作用。部署在WebSphere应用服务器上的应用，默认的会话超时时间为30分钟，默认的会话管理级别是Application Server。如果您期望更改您的应用，例如，DefaultApplication的会话超时时间，可按如下步骤进行：选择应用程序>应用程序名>会话管理(图13)，选择“覆盖会话管理”，并在“设置超时”中填上期望的会话超时时间。点击“确定”保存即可。
当应用需要通过写Java环境变量的方式配置一些变量时，可在应用服务器启动脚本中用-D参数指定，也可以在应用程序服务器 > 应用程序服务器名（例如，server1) > 进程定义 > Java 虚拟机中设置“通用JVM参数” -Daaa=xxx。
当在WAS环境中遇到问题时，最方便的是利用网上资源查阅相关资料。这方面的文章已经太多，为了达到本文的目标：“为初级用户提供一个尽量完整的快速入门指南”，我不得不在这里老调重谈，请参照从何学习 WebSphere? 了解WebSphere应用服务器的常用网上资源。
了解WAS的过程是渐进式的，希望这篇文章能够在WAS安装示例文档和用户的WebSphere生产环境搭建实践之间提供一个过渡，节省您的时间。从工程师的角度看，遇到问题不是坏事，遇到问题越多，经验越多，查阅资料，并通过多种渠道获得IBM的技术支持，相信您对WAS的使用体验会更加美妙。
-
[转]WebSphere环境搭建实践指南（一）
2008-12-19 14:06:06
转载自：
http://tech.it168.com/jd/2007-08-23/200708230733862.shtml
【IT168 技术文档】
生产环境中 WebSphere 应用服务器的搭建与演示环境有很多不同，由于生产环境的多样性、应用场景的性能调优、错误诊断等严格要求，生产环境中 WebSphere 应用服务器的安装涉及到安装前系统各项检查、安装中各种参数调整，以及安装后常见的管理任务。WebSphere 应用服务器有着大量的资源可以参考，但对于很多仅仅搭建过演示或简单测试环境的用户来说，面对浩如烟海的文档很难下手。本文试图总结在搭建一个完整的 WebSphere 环境中遇到的常见问题和注意事项，为初次搭建 WebSphere 应用服务器准生产环境的人提供一个快速入门指南。与大多数商用应用服务器一样，如果您计划把WebSphere应用服务器（以下简称WAS）用于正式的生产环境或用于性能测试、生产前检验的测试环境，除了简单地安装步骤外，您还需要做一些额外的检查、规划和配置，来确保您的WebSphere应用服务器环境安全稳定运行。 WebSphere应用服务器各个版本之间安装步骤差别不大，WAS V6.x版本比以前版本的安装配置步骤中多了创建概要文件的过程，本文举例的版本为V6.1。在阅读本文之前，推荐读者先了解安装WebSphere应用服务器的大致过程或相关概念。对于WebSphere应用服务器各版本的具体安装步骤，请参照WebSphere应用服务器产品随机安装文档以及WebSphere信息中心，DeveloperWorks上也有很多关于WAS环境搭建的参考文章，如：WAS5的安装及其常见问题、在WAS6.0 ND中实现集群等，见参考资源。
在搭建准生产环境的过程中，好的准备是成功的一半，推荐逐条进行以下安装前准备工作。
WebSphere应用服务器能否顺利安装成功首先取决于目标平台是否满足安装的软件和硬件条件。WebSphere应用服务器对硬件配置的要求主要体现在待部署平台的硬件架构、CPU、内存和磁盘存储空间上，通常最低内存要求在512M以上，根据硬件平台、WebSphere应用服务器版本、组件的不同，要求的配置也会略有区别，请参考WAS详细系统需求 。磁盘空间的分配请参见“2.4 确认磁盘空间是否满足要求”。
作为一个成熟的商用应用服务器，WebSphere应用服务器会定期发布不同WAS版本（例如WAS V5.0, WAS V5.1， WAS6.0…）、组件（例如：Application Server, Edge Component）支持的操作系统版本信息。使用WebSphere服务器支持的操作系统平台，能确保应用服务器安装、使用过程中环境的正常稳定运行。尤其要注意的是，如果操作系统平台不是IBM WebSphere应用服务器官方支持的平台，在WebSphere应用环境出现问题后则无法获得WebSphere应用服务器的售后支持，更谈不上解决问题了。
例如，在笔者写这篇文章时，在x86芯片上，对于RedHat AS 4操作系统，如果要安装WebSphere应用服务器V6.1的Application Server组件，则要求的操作系统版本是Red Hat Enterprise Linux AS, Version 4 with Update 2。如果您的操作系统版本是Red Hat Enterprise Linux AS, Version 4，则还需要安装Update2，否则有可能遇到问题。
由于支持的操作系统版本是定期更新的，请在搭建WebSphere应用服务器环境前，参照系统详细需求去查看当前操作系统版本（版本要与网上列出的完全一致）是否满足WebSphere应用服务器要求。
在安装WebSphere应用服务器过程中，创建概要文件这一步骤需要用户填入机器的主机名（如图1），并且，WAS运行时也需要用到主机名(Host Name)。主机名是WAS安装节点的物理机器的网络名，它必须解析到服务器上的物理网络节点。创建概要文件中WAS使用的主机名的值可以是全限定 DNS 主机名（例如： hosta.cn.ibm.com）、短主机名(例如：hosta)，或甚至是数字 IP 地址(例如：192.168.1.3)，但必须是WAS所在服务器实际配置的主机名。而且，当WAS配置完毕投入使用之后，不推荐更改您设定的主机名，即使能改，过程也比较复杂。因此，根据实际经验，我们推荐用户在安装WebSphere应用服务器之前配置主机名。如果采用全限定 DNS 主机名或短主机名，可以通过hostname命令来查看当前系统的主机名。如果没有配置，则到hosts文件中添加相应的条目。
- 常见问题1：在安装WAS之后，更改了主机名，WAS无法正常启动或停止，日志报错：javax.naming.ConfigurationException: Cannot get canonical host name for server。或者报错无法找到主机名xxx。因此，在创建WAS的概要文件之前，需要根据实际情况，选择三种形式的主机名（全限定 DNS 主机名、短主机名或数字 IP 地址)中保持不变的那种主机名形式，作为WAS使用的主机名，在概要文件创建向导（图1）中填入。如果您使用 DHCP或者如果您经常更改 IP 地址，那么我们推荐在概要文件创建时使用全限定 DNS 主机名或短主机名；如果机器ip固定，而全限定 DNS 主机名或短主机名有可能更改，则在概要文件创建中使用数字ip。
- 常见问题2：如果您需要创建集群，请确保网络配置中，除了保证本机主机名配置正确外，还必须保证集群所在机器之间互相能ping通主机名。否则集群创建中add node一步可能不成功。
考虑硬盘空间分配时，在UNIX或Linux平台下可以用df –k 先查看各目录大小。如果是在生产环境上安装WebSphere应用服务器，一般要从以下几个方面来计算要预留的空间。
- WebSphere 应用服务器自身代码的占用空间。这个空间一般在1G左右，在不同的系统平台上略有差异。应在WAS安装目录下预留此空间。WebSphere应用服务器在Linux下的默认安装路径是 /opt/IBM/WebSphere/AppServer，在AIX下的默认安装路径是/usr/IBM/WebSphere/AppServer（后面我们把此路径简称为WAS_HOME）。用户可以在安装WAS时修改此安装路径。
- 概要文件所占的空间。WebSphere应用服务器V6.1创建的概要文件基本类型有3种，每个概要文件所占用的空间如下：应用程序服务器(Application Server)：在WebSphere应用服务器安装没有选择安装样本程序时，这一概要文件所占磁盘空间约为200M；Deployment Manager：30M；定制概要文件（Custom，即node agent）：10M。
- 如果要安装WEB服务器，则在WEB服务器所在服务器上要预留WEB服务器所占的磁盘空间。IBM HTTP服务器一般占用110M左右的空间。
- 如果安装WEB服务器，则在WEB服务器所在机器上通常也要安装Web Server Plug-in组件，该组件所占磁盘空间约为200M。
- WebSphere 应用服务器系统日志的占用空间。日志空间的估算要结合系统对日志的配置情况。WebSphere应用服务器的主要日志有SystemOut.log，SystemErr.log。我们可设置日志文件的大小和保存的历史日志文件数量，从而可以估算出其需要的空间。请参考“必要参数的调整”部分了解如何调整WebSphere应用服务器日志参数。
- 如果有WEB服务器，需考虑WEB服务器的日志空间。如果客户开启了WEB服务器的访问日志access.log（默认开启），此日志增长的速度极快，要预留足够的空间。
- 备份文件需要的空间。WebSphere应用服务器提供了一个备份命令（backupConfig.bat/sh），用来备份应用服务器的配置及其上应用。我们建议在系统稳定之后及时备份。对于一个典型生产系统，WebSphere应用服务器这个配置文件经常超过100M。可在发出backupConfig命令时，使用-logfile参数指定该备份文件的存放位置。
- 系统出错时日志，例如，JVM在发生OutOfMemory时，在大多数平台上WebSphere应用服务器会默认写javacore文件和heapdump文件，记录错误出现时的JVM Heap、线程情况，以备错误诊断使用。虽然可以调整应用服务器参数使之不产生此类文件，但为了分析问题，通常需要从此类文件入手。这类文件通常都特别大，例如heapdump文件，可能达到几百M。如果多次出现OutOfMemroy，对磁盘空间的占用很快。因此，必须考虑为此类文件预留磁盘空间。
- WAS安装程序还需要在系统的临时目录/tmp中有100M以上的空闲空间。
- 用户发布到WebSphere应用服务器上所有应用程序以及应用自身的应用日志的占用空间。这个大小与实际应用相关，而且不同应用可以差别很大。
如要了解不同平台具体的磁盘空间要求，请参考WAS V6.1信息中心“为产品安装准备操作系统”一节的内容。
前面提到WebSphere应用服务器对支持的操作系统版本有明确要求，除此之外，WAS信息中心还对特定的操作系统版本安装的包、内核参数等有特殊要求。例如，对于RHEL AS4，信息中心中说明必须安装compat-libstdc++-33-3.2.3-47.3.ppc.rpm包（这是保持 C++ 运行时兼容性所必需的，供诸如 GSKit 的组件、Java 2 软件开发包（SDK）以及 Web 服务器插件使用）以及其他一些包。对于Linux、Solaris、HP等系统，还需要调整一些相应的内核参数。请参照请WAS V6.1信息中心“为产品安装准备操作系统”一节的内容。对于Solaris系统，需要调整的参数列表列举如下：
set shmsys:shminfo_shmmax = 4294967295 set shmsys:shminfo_shmseg = 1024 set shmsys:shminfo_shmmni = 1024 set semsys:seminfo_semaem = 16384 set semsys:seminfo_semmni = 1024 set semsys:seminfo_semmap = 1026 set semsys:seminfo_semmns = 16384 set semsys:seminfo_semmsl = 100 set semsys:seminfo_semopm = 100 set semsys:seminfo_semmnu = 2048 set semsys:seminfo_semume = 256 set msgsys:msginfo_msgmap = 1026 set msgsys:msginfo_msgmax = 65535 set rlim_fd_cur=1024
WAS的安装可以使用人机交互的图形界面安装或批处理安装（称为静默安装，silent installation，预先写好响应文件，安装过程中不需要启动图形界面或者人机交互）。如果使用图形界面安装，在服务器是Linux/UNIX平台时，我们通常没有机会直接使用服务器的显示屏/控制台，而是通过自己的机器telenet到服务器上去。这种命令行直接telnet的模式下，可能不支持启动图形界面，需要用到Xmanager、X-Win32等支持X Window的工具软件。你可以在命令行下敲入命令xclock进行测试。如果出现如图2所示的图形显示，表明你能够在你的终端上启动图形界面。
图 2. 验证能够启动图形界面
2.7. 准备合适的安装介质WAS是跨平台的产品，不同的UNIX、Linux、Windows平台、32位或者64位操作系统上，安装介质都是不一样的，而且产品中包含了Application Server、Web Server、Edge Component等多种组件，当搭建WebSphere环境时，您需要从订购的WAS产品包（包括各个平台、组件的多张CD）中选择需要的安装介质。因此，安装前我们需要根据安装的WAS组件、操作系统版本、操作系统位数，选择所需要的介质。例如，如果我们要在x86架构、64位(注意，这里的64位是指操作系统是64位的)的Linux AS 4上安装WAS，就应该选择WebSphere Application Server for x86 64-bit Linux的安装介质；如果我们要安装IBM Http Server或者update installer，这两个组件都是在WebSphere Application Server Supplements CD中，同理，根据操作系统版本、位数、服务器的芯片，我们就可以选出所需要的介质了。如果WAS安装中需要打补丁，建议在安装WAS前提前下载这些补丁以备安装过程中使用。具体内容在“打补丁”一节详述。
根据实际应用场景的不同，我们需要决定WAS、Web 服务器分别装在哪些服务器上，如果需要配置集群环境，还需要考虑Deployment Manager、各个结点和集群成员都分部在哪些服务器上。例如，如果我们要配置一个集群环境，安装前，我们通常会先设计出如图3的一张拓扑结构图，以决定安装中每台服务器上实际安装、配置的组件。例如，如图3所示，图中实线是运行时的请求流，虚线是WAS各组件间的控制流。我们可以看出，在hosta机器上，应该安装WAS组件，并创建Deployment Manager、NodeA概要文件，配置集群成员C1和C2；在hostb机器上，应该安装WAS组件，创建NodeB概要文件，配置集群成员C3和C4。在machine3机器上，应该安装IBM Http Server和Plug-in组件。其中，WAS集群的配置是非常方便的，可以在创建完概要文件之后灵活调整。
其他一些常见注意事项还包括权限、端口控制等等。例如:
- WebSphere应用服务器在Unix/Linux系统上支持root用户和非root用户。但为了操作设置的简便性，通常都会在root用户下进行。
- 有的生产系统对端口访问有限制，或者系统中可以已经占用了 WAS 即将使用的默认端口，因此，需要更改WAS使用的端口（此任务将在“更改WAS使用的端口”中详述）等等。
- 如果需要创建集群，请确保参与Cell环境的各台机器之间时间一致、时区一致，建议误差控制在秒级。否则在add node过程中可能不成功。
-
安装WAS的过程非常简单，通常分为3步：安装WAS产品，为产品打补丁(如果有补丁)，创建概要文件。如果您的环境很干净，没有一些特殊的限制，安装过程大多数时候是点击默认的“Next”。当然，根据环境的不同，通常会要注意以下方面：
使用图形界面方式安装WAS的过程十分简单，通常不需要做特定的修改。下面列举安装中常见的一些注意事项和提高安装速度的小窍门：
- 通常，如果您的系统曾经安装过WAS产品，安装WAS产品之前，建议停掉正在运行的WAS进程。如果安装IBM Http Server，通常最好停掉正在运行的Apache Http Server或者其他IBM Http Server进程。在Unix/Linux系统上，可以用 ps –ef |grep java 命令，去查看当前系统是否有was进程，用 ps –ef |grep httpd 命令，去查看当前系统是否有http server进程在运行。
- 安装WAS可以执行launchpad.bat/luanchpad.exe,启动“启动板”，从启动板中点击“启动WebSphere Application Server的安装向导”。如果无法成功启动“启动板”，直接到安装介质目录下的WAS目录中，执行install.exe/install.sh即可。
- 乱码：启动板或WAS安装向导显示的语言与本地操作系统语言设置有关。如果本地操作系统语言设置为中文，则 WAS安装向导就会显示中文。如果发现向导中语言显示为乱码，可以先把本地操作系统语言设置为英文，使用英文语言安装WAS。这样安装完毕的WAS仍然具有中文支持，不必担心。在Unix/Linux平台上，更改语言为英文使用下列命令: export LANG=en_US
- 安装 WAS 过程中可以选择是否安装样本应用程序（samples），为了在开发环境和生产环境中都能获得更高性能，请不要安装样本。通过省略样本，可以将应用程序服务器启动时间缩短 60％ 并节省 15％ 的磁盘空间；可以节省相当程度的进程占用量；并且可以节省WAS产品安装以及每次创建应用服务器概要文件的时间。
- 一个可运行的 WAS 环境至少要包含一个概要文件。因此，WAS产品安装过程中会让用户选择要创建的初始概要文件。如果在安装完WAS产品之后还要打补丁，建议此时先不要选择创建任何初始概要文件（图4），以节省打补丁所需的时间。如果在安装期间未创建概要文件，安装WAS产品结束后会显示用于启动“概要文件创建”向导的选项。基于同样原因，如果需要打补丁，我们将把创建概要文件这个工作放到打补丁之后进行，因此此处不必选择启动“概要文件创建”向导。
图 4. 安装时不选择创建初始概要文件
如果您使用的WAS版本已经推出市场一段时间，根据用户的测试和使用情况， WAS会定期公布补丁包(Fix Pack)或补丁(Fix)。建议先在测试环境中安装补丁，确认安装的补丁不会对您的运行环境带来负面影响，再将补丁安装到生产环境中。一旦您经过了适当的测试后，主动地安装预防补丁，将避免一些可能导致您系统出故障的问题。WAS V6.x的补丁升级策略 了解补丁升级策略的详情。并可以在IBM支持网站WAS补丁下载下载WAS补丁。
一般来说，WAS补丁的命名规范为：版本名-产品名-产品组件名-平台名-补丁编号名.pak。例如，6.1.0-WS-WAS-SolarisSparc64-FP0000007.pak ，这是WAS V6.1的WAS组件针对Solaris Sparc64操作系统的FP0000007补丁。如果您安装了WAS，就需要产品组件名为WASSDK和WAS的补丁；如果您安装了IBM Http Server，就需要产品组件名为IHS的补丁；如果您安装了Plugin就需要产品组件名为PLG的补丁。通常，同样补丁编号的补丁，先装WASSDK补丁，再装WAS补丁。以后，每一次打补丁的过程，都是：
1) 把补丁文件拷贝到补丁工厂安装目录的maintenance目录下;
2) 在补丁工厂的安装目录下，执行./update.sh命令启动补丁工厂；
3) 在“安装目录”中选择将要打补丁的组件的安装目录。通常，对WAS组件，补丁会自动识别出安装位置；对于IBM Http Server（简称IHS）或者Plug-in这样的组件，需要选择正确的安装位置;
4）在maintenance package selection页面中选择想要打的补丁。
概要文件是一组用于定义运行时环境的文件，每个概要文件都是一组完全隔离的运行时环境。前面我们提到了概要文件有三种基本类型。在创建概要文件的过程中，通常我们要了解以下细节：
- 概要文件创建有两种方式，图形化创建向导和命令行方式。为了操作的简便和直观，我们通常采用图形化创建向导(执行WAS_Home/ bin/ProfileManagement/pmt.sh启动该向导)。如果安装的是64位的WAS，则没有该图形化创建向导工具。这时，请直接使用./manageprofiles.sh命令。例如：在UNIX平台上创建一个Application Server类型的名为AppSrv01的profile，使用manageprofiles命令可以如下操作：
export WAS_HOME=/opt/IBM/WebSphere/AppServer echo $WAS_HOME cd $WAS_HOME/bin ./manageprofiles.sh -create -profileName AppSrv01 -profilePath $WAS_HOME/profiles/AppSrv01 -templatePath $WAS_HOME/profileTemplates/default -hostName kcgg1d7.itso.ibm.com -enableAdminSecurity true -adminUserName adminUser_ID -adminPassword adminPassword
注意，命令和参数大小写敏感的。Manageprofiles命令的语法和更多参数选项请参见红皮书sg247304.pdf或信息中心。
- 在“确认网络配置/主机名满足要求”一节中，提到了选择适当的主机名；在创建概要文件（图1）过程中，大多数情况下向导自动识别出的主机名就符合要求，否则我们需要向概要文件向导中填入适当的主机名。在同一台机器上用概要文件创建向导创建多个profile时，自动识别的主机名可能是加上域名的全限定名称例如hosta.cn.ibm.com，也可能是短名hosta。这两种形式都支持，但是不要在一个cell (Cell指WAS多个实例组成的一个受管域)中混用这两种名称方式。
- 创建应用程序服务器概要文件过程中，可以根据需要选择创建适用于开发环境或生产环境使用的应用服务器实例。例如，对于开发环境，我们可以选择使用开发模板来创建服务器，开发模板针对开发目的进行了优化的配置，减少了WAS启动时间并允许服务器在功能较少的硬件上运行。但在生产环境中，不要选择“使用开发模板”。
- 概要文件创建过程中我们可以选择“启用管理安全性”，让用户在进行登陆管理控制台、停止WAS实例等管理任务时需要输入用户名/密码。注意，如果在创建概要文件过程中没有启用管理安全性，或者启用管理安全性之后希望修改用户名或密码，都可以在概要文件创建完毕之后再次进行修改（请参见“管理安全性”）。
- 创建概要文件过程中可查看/更改该概要文件所占的port。图5显示了创建的这个概要文件实例启动时将占用的端口，我们可看到管理控制台端口是9060，Http传输端口（也就是应用访问端口）是9080。如果用命令行方式创建概要文件向导，无法通过图形化显示看到这些端口，如果希望查看端口，可以在概要文件创建完毕后查看配置得到端口值（请参见“查看/更改应用服务器端口”）；如果希望修改这些端口，则可以在概要文件创建中用参数-portsFile或-startingPort指定端口。当然，所有这些端口值都可以在概要文件创建完毕之后再次修改。
图 5. 创建概要文件中显示端口
我的栏目
标题搜索
我的存档
数据统计
- 访问量: 146340
- 日志数: 249
- 书签数: 41
- 建立时间: 2007-08-11
- 更新时间: 2013-03-28
