级别: 初级 Qinhua Wang (qwang@us.ibm.com), 顾问软件工程师, BM WebSphere Development
2003 年 9 月 01 日 WebSphere Application Server V5 中的配置服务功能提供了一个 Java 编程接口,通过这个接口,您可以查询或修改您的 WebSphere Application Server 配置。
© Copyright International Business Machines Corporation 2003. All rights reserved.
引言
WebSphere®Application Server V5 中的配置服务功能提供了一个 Java™ 编程接口,通过这个接口,您可以查询或修改您的 WebSphere Application Server 配置。例如,您可以用它查找单元中的所有服务器、修改某些服务器配置参数或者配置新的数据源。实际上,通过 Web 管理控制台(配置选项卡)与 wsadmin 脚本工具(AdminConfig 命令)提供的与配置相关的功能,配置服务也可以提供。因此,您可以编写自己的管理程序来用配置服务配置您的整个 WebSphere Application Server 环境。
本文将通过一些示例来演示如何使用配置服务。尽管本文是独立的,但是您还是应该先阅读一下本系列的
第 1 部分和
第 2 部分,熟悉一下 WebSphere Application Server 管理。
WebSphere Application Server 配置服务 javadoc也是关于这个主题的很有用的文档,它提供了包
com.ibm.websphere.management.configservice 和
com.ibm.websphere.management.configservice.tasks 的有关信息,这两个包包含所有的配置服务 API。
配置对象
WebSphere Application Server 配置由一套 XML 文档组成,这些文档存储在 WebSphere 安装根目录下的
config 目录中。(您可以在
第 1 部分中找到有关配置目录结构以及下级文档的更多信息。)
这个文档中的术语“配置对象(config object)”是指配置文档中的一个 XML 元素,配置文档定义了 WebSphere Application Server 中运行时组件的配置。下面是配置文档中定义的两个配置对象示例。您可以看到,配置对象可以是嵌套的,即一个配置对象可以包含其他的配置对象。
样本配置对象 1. 定义跟踪服务组件的配置
<services XMI:type="traceservice:TraceService" XMI:id="TraceService_1" enable="true"
startupTraceSpecification="*=all=disabled"traceOutputType="SPECIFIED_FILE" traceFormat="BASIC"
memoryBufferSize="8">
<traceLog XMI:id="TraceLog_1"fileName="${SERVER_LOG_ROOT}/trace.log" rolloverSize="20"
maxNumberOfBackupFiles="1"/>
</services>
样本配置对象 2. 定义 JVM 的配置
<processDefinition XMI:type="processexec:JavaProcessDef" XMI:id="JavaProcessDef_1"
executableName="${Java_HOME}/bin/Java" workingDirectory="${USER_INSTALL_ROOT}"
executableTargetKind="Java_CLASS"executableTarget="com.ibm.ws.runtime.WsServer">
<execution XMI:id="ProcessExecution_1"processPriority="20" runAsUser="" runAsGroup=""/>
<ioRedirect XMI:id="OutputRedirect_1"stdoutFilename="${SERVER_LOG_ROOT}/native_stdout.log"
stderrFilename="${SERVER_LOG_ROOT}/native_stderr.log"/>
<monitoringPolicy XMI:id="MonitoringPolicy_1"maximumStartupAttempts="3" pingInterval="60"
pingTimeout="300"autoRestart="true" nodeRestartState="STOPPED"/>
<jvmEntries XMI:id="JavaVirtualMachine_1"verboseModeClass="false" verboseModeGarbageCollection="false"verboseModeJNI="false" initialHeapSize="0" maximumHeapSize="256"runHProf="false" hprofArguments=""
debugMode="false"debugArgs="-DJava.compiler=NONE -Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7777"genericJvmArguments="">
<classpath></classpath>
<bootClasspath></bootClasspath>
</jvmEntries>
</processDefinition>

 |

|
通过示例使用配置服务
我们将通过一个简单的示例
ConfigServiceExample1.Java 来说明配置服务的基本编程模型,在
下载部分可以下载到该示例的代码。执行时,这个示例将:
- 读出服务器的跟踪规范,
- 设置一个新的跟踪掩码,然后
- 保存更改。
稍微做一点变动,您就可以用这些代码轻松地查询和修改大多数的配置信息。
我们将遵循下列这些主要步骤来使用配置服务:
-
获取配置服务
-
创建一个会话
-
标识配置对象
-
获取配置对象标识
-
查询和修改属性值
-
查询端口信息
-
保存更改
-
清除会话
1. 获取配置服务
第一步就是获取对
ConfigService 的引用。配置服务既可以在服务器内运行,也可以在服务器外一个独立的 JVM 中运行。配置服务在服务器内运行时,您既可以从客户机进程通过远程方式访问它,也可以在服务器进程中通过本地方式访问它,如图 1 所示。
图 1. 获取配置服务
如果配置服务在服务器
内运行……
- 同时您的代码在服务器
外运行,下面这个代码片断将展示如何在远程客户机进程中通过一个
AdminClient 对象获取对配置服务的引用。本系列的第 2 部分
编写您自己的管理程序详细说明了怎样获取一个
AdminClient 对象。
AdminClient adminClient = ....;
// create a config service proxy object.
ConfigService configService = new ConfigServiceProxy(adminClient);
- 同时您的代码也在服务器
内运行,您就可以使用下面的代码行来获取对配置服务的引用:
ConfigService configService = ConfigServiceFactory.getConfigService();
图 2. 独立的 JVM
配置服务也可以在服务器
外独立的 JVM 中运行(图 2)。在这种情况下运行的典型原因包括:为了能在产品安装过程中修改配置、为了开发配置验证工具等等。在配置损坏得太严重而不能启动时,这种运行方式也特别有用。下面的代码片断展示了如何在服务器外独立的 JVM 中运行配置服务。
//runing config service with local mode
ConfigService configService = ConfigServiceFactory.getConfigService();
if (configService == null) {
Properties prop = new Properties();
prop.setProperty("location", "local");
configService = ConfigServiceFactory.createConfigService(true,prop);
}
在独立的 JVM 中运行配置服务时:
- 在 JVM 的整个生命期中,您应该只调用
createConfigService 一次;在整个 JVM 中只能有一个配置服务实例。万一对
createConfigService 进行了多次调用就会生成一个异常,该异常指出已经存在另一个配置服务实例。先获取配置服务,然后在其返回值为空(null)时再调用
createConfigService() 是个不错的主意。
- 您必须将系统属性
com.ibm.ws.management.standalone 设置为 true。如果您想在非缺省位置修改配置文档,那么您还需要通过系统属性
was.repository.root 设置 config 目录的位置。
虽然配置服务既可以在服务器中运行,也可以在独立的 JVM 中运行,但是
请不要在同一个 config 目录上同时以这两种方式运行,因为这两种运行方式下同时发生的更新可能会发生冲突,破坏 WebSphere Application Server 配置的完整性。
2. 创建一个会话
配置服务支持会话这个概念;也就是说,直到保存命令被发出,所有通过配置服务进行的查询和修改才会被存入 config 目录。由于所有的
ConfigService 方法都使用一个 session 参数,因此在任何调用之前,您都要先创建一个
com.ibm.websphere.management.Session
,如下所示。
// create a session
Session session = new Session();
通常,您会先创建一个会话,对配置做几处更改,然后一次保存会话过程中所做的全部更改。
session 参数可以为空,这表示该方法将创建一个单独的匿名会话,请创建该会话,然后在一次方法调用中保存它。但是,请记住:会话的创建不是廉价的,因此请尽可能地重用会话。
3. 标识配置对象
配置服务使用
javax.management.ObjectName
唯一标识配置对象,同样,JMX 规范使用
ObjectName 来唯一标识注册在
MBeanServer 中的 MBean。下面这些键可以用在
ObjectName 中:
SystemAttributes._WEBSPHERE_CONFIG_DATA_ID
| 一个唯一标识配置对象的不透明处理程序 |
SystemAttributes._WEBSPHERE_CONFIG_DATA_TYPE
| 配置对象的类型,例如 DataSource、Server 或 ServerCluster 等等 |
SystemAttributes._WEBSPHERE_CONFIG_DATA_DISPLAY_NAME
| 配置对象的名称,例如 Server 的名称 |
ConfigServiceHelper 类提供了各种操纵 ObjectName(如构造 ObjectName 或从 ObjectName 检索信息)的助手方法。例如,这个类提供了一个从 ObjectName 获取位置信息的
getObjectLocation 方法。
4. 获取配置对象标识
可以用
resolve 方法和
queryConfigObjects 方法获取配置对象的标识。
下面的代码行展示了如何用
resolve 方法获取服务器配置对象的标识。它会解析节点(名为 myNode)上的服务器(名为 gooddog)的标识。这个方法是轻松找到配置对象的高效途径。请参考
Javadoc以获取关于搜索模式语法的详细说明。由于它返回一个配置对象数组,因此您总是要检查返回的数组的长度。
// query to get the server
ObjectName server = configService.resolve(session, "Node=myNode:Server=gooddog")[0];
queryConfigObjects 方法提供了根据配置对象的类型、名称或根据这两者在一定范围内进行搜索的功能;范围的值可以是
Cell 、
Node 、
Server 、
Application 或者
Cluster 配置对象。如果搜索范围被指定为空,该方法将搜索整个 config 目录,这样开销会非常大。所以说应该优化搜索算法,使其能处理一般情况,如列出单元中所有的服务器、节点或者 J2EE 应用程序等等。下面的代码列出了服务器(我们在上面用
resolve 方法获取的)上定义的 TraceService 组件。与
resolve 类似,这个方法也会返回一个配置对象数组,因为许多配置对象都可以匹配这种模式。
// query to get the trace service component in server.
ObjectName pattern = ConfigServiceHelper.createObjectName(null, "TraceService");
ObjectName traceService = configService.queryConfigObjects(session, server, pattern, null)[0];
5. 查询和修改属性值
一旦您获取了配置对象的标识,就可以使用
getAttribute 方法和
setAttribute 方法来查询和修改这个配置对象的各种属性值。下面的代码片断先使用
setAttribute 方法将
startupTraceSpecification 属性设置为新值
*=all=enabled ,然后使用
getAttribute 方法验证这种更改。
// set the server's trace specification to new value.
String newTrace = "*=all=enabled";
AttributeList attrList = new AttributeList();
attrList.add(new Attribute("startupTraceSpecification", newTrace));
configService.setAttributes(session, traceService, attrList);
newTrace = (String) configService.getAttribute(session, traceService, "startupTraceSpecification");System.out.println("new trace is" + newTrace);
在这个示例中,由于我们提前知道了返回值的类型,因此我们把它从
Object 转化成了
String 。一般情况下,返回值的类型取决于指定属性的类型。
6. 查询端口信息
用配置服务查询各种端口信息是很常见的。例如,ConfigServiceSample11 代码(
下载部分中)展示了如何得到 HTTP/HTTPS 传输端口、SOAP 连接器端口以及名称服务器引导程序端口的主机名和端口号。(名称服务器引导程序端口也是 admin RMI 连接器的端口。)
7. 保存更改
到目前为止所做的更改都还未保存,因此在
save 方法被调用之前您还看不到 config 目录的任何更新。
// save the change.
configService.save(session, false);
没有必要在每次修改过配置后都进行保存。原则是当您准备把在会话中所做的配置更新发布到 config 目录时才保存配置,使系统能够使用更新过的配置。出现会话这个概念的主要原因很可能是为了防止部分配置更新的失败影响整个配置的一致性和完整性。
由于要等到您保存了会话,在这个会话中进行的所有配置更改才会进入 config 目录,因此您也看不到在其他并发会话中所做的任何未保存的配置更改。用户通过不同会话同时更新同一份配置文档时,
save 方法会检测到这种冲突。上面代码中的布尔型参数是一个
overwriteOnConflict 标志,如果它的值为
false 就表示若另一用户同时也在修改这份配置文档,则 save 方法的调用会失败,如果是
true 就表示 save 方法的调用将覆盖其他的并发修改(由于这样会导致配置不一致,所以很危险)。您还可以用
getConflictDocuments 方法查询冲突文档列表,以此来帮助您决定是用您的更新覆盖其他的并发更新还是丢弃您的更新。
8. 清除会话
完成上面的操作后请调用
discard 方法来释放该会话所用的所有资源。若不释放的话会浪费资源,并且可能导致内存泄漏。请在您的代码末尾或者任何最合适的地方加上下面这行代码:
configService.discard(session);
除了释放会话拥有的所有资源外,discard 方法还会丢弃自上一次保存以来发生的所有更改。因此,若是您选择不完成会话(例如,在失败的情况下),它还可以被用来丢弃任何未保存的更改。
探究配置对象的类型和属性
前面有一段说明了如何查询和修改 WebSphere Application Server 配置信息。这里,我们将了解一下如何查找所有支持的配置对象类型及其属性的信息。
有四种获取这些信息的基本方法:
- 使用 WebSphere Application Server 信息中心的
WebSphere Configuration Documentation
- 在 wsadmin 中运行
$AdminConfig attributes 命令和
$AdminConfig types 命令
- 查看 XML 配置文档,了解一下配置对象是如何显示的
- 调用
ConfigService 的
getSupportedConfigObjectTypes 方法和
getAttributesMetaInfo 方法。
用 AttributeList 显示配置信息
我们可以用来自于 JMX 规范的
javax.management.AttributeList 类来显示配置对象的配置信息。
AttributeList 是一个属性对象集合,这些属性对象都是名称-值对。由于
AttributeList 是通用数据结构,因此
ConfigServiceHelper 提供了几个构造和遍历
AttributeList 的助手方法。
从配置服务返回的任何属性列表都包含配置服务定义的两个系统属性:
-
SystemAttributes._WEBSPHERE_CONFIG_DATA_ID
-
SystemAttributes._WEBSPHERE_CONFIG_DATA_TYPE 。
下面几段将讨论 AttributeList 如何显示各种属性的配置信息。
简单属性
如果属性的类型是一种简单的 Java 类型,如字符串型(String)、整型(Integer)、布尔型(Boolean)等,该属性的值就会在属性列表中被直接使用。例如,显示
TraceService 配置对象(如下所示)的
AttributeList 包含一个布尔值为
true 的
enable 属性、一个字符串值为
*=all=disabled 的
startupTraceSpecification 属性以及其他一些属性。
<services XMI:type="traceservice:TraceService" XMI:id="TraceService_1"enable="true"
startupTraceSpecification="*=all=disabled" traceOutputType="SPECIFIED_FILE" traceFormat="BASIC"
memoryBufferSize="8">
<traceLog XMI:id="TraceLog_1" fileName="${SERVER_LOG_ROOT}/trace.log"rolloverSize="20"
maxNumberOfBackupFiles="1"/>
</services>
复杂属性
如果是复杂的属性类型,那么属性值就会以一个
AttributeList (也就是一个嵌套的属性列表)的形式出现。
TraceService 配置对象(如上所示)有一个复杂类型属性
traceLog ,它的值是一个带有
fileName 和
rolloverSize 等属性的嵌套
AttributeList 。
集合属性
如果属性的类型是集合,那么
AttributeList 中的属性值就是
java.util.List 。例如,
resources.xml 文件(如下所示)中的 DataSource 配置对象就有一个集合类型属性
ResourceProperties ,因此它的属性值就是一个列表对象,其中的每个元素同时也是一个显示
ResourceProperty 配置对象的
AttributeList :
<factories XMI:type="resources.jdbc:DataSource" XMI:id="DataSource_1"name="Default Datasource"
jndiName="DefaultDatasource" description="Datasourcefor the WebSphere Default Application"
category="default" authMechanismPreference="BASIC_PASSWORD"statementCacheSize="0"
datasourceHelperClassname="com.ibm.websphere.rsadapter.CloudscapeDataStoreHelper"
relationalResourceAdapter="builtin_rra">
<propertySet XMI:id="DB2a-J2EEResourcePropertySet_1a">
<resourcePropertiesXMI:id="res_prop_template_DB2j_5_1" name="databaseName"type="java.lang.String"
value="${WAS_INSTALL_ROOT}/bin/DefaultDB" description="Location of Cloudscape default
Database."/>
<resourcePropertiesXMI:id="res_prop_template_DB2j_5_2" name="remoteDataSourceProtocol"
type="java.lang.String" value=""/>
<resourcePropertiesXMI:id="res_prop_template_DB2j_5_3" name="shutdownDatabase"
type="java.lang.String" value=""/>
<resourceProperties XMI:id="res_prop_template_DB2j_5_4" name="dataSourceName" type="java.lang.String"
value=""/>
</propertySet>
<connectionPool XMI:id="ConnectionPool_1" connectionTimeout="1000" maxConnections="30" minConnections="1"
reapTime="180"unusedTimeout="1800" purgePolicy="FailingConnectionOnly"/>
</factories>
虽然您可以使用
setAttributes 方法修改集合类型属性的值,但这种方法的缺点是修改时是替换整个集合,而不是让您修改列表中的个别元素。尽管如此,
addElement 方法和
removeElement 方法仍可以让您对集合类型的属性进行更好的修改。请参阅
Javadoc以获取更多信息。
也可用
createConfigData 方法将复杂类型的元素添入集合。基本上,它会创建一个带有指定属性列表的配置对象,并将其添加在集合的末尾。这里
addElement 的优点是您可以指定创建的对象的位置,而使用
createConfigData 的优点是它会返回已创建的配置对象的标识,您可以通过这个标识进一步处理配置对象。
下面来自于
ConfigServiceSample2.Java (请参见
下载)的代码片断说明了如何将一个
J2EEResourceProperty 对象添入
DataSource 配置对象的
propertySet :
// get the J2EEResourcePropertySet object
AttributeList value = configService.getAttributes(session, newDataSource, new String[]{"propertySet"}, false);
ObjectName propertySet = (ObjectName) ConfigServiceHelper.getAttributeValue(value,"propertySet");
// create a J2EEResourceProperty object and add into the list of resourceProperties.
attrList.clear();
ConfigServiceHelper.setAttributeValue(attrList, "name", "DatabaseName");
ConfigServiceHelper.setAttributeValue(attrList, "type", "Java.lang.String");
ConfigServiceHelper.setAttributeValue(attrList, "value", "myDatabase");
ObjectName prop = configService.createConfigData(session, propertySet, "resourceProperties",
"J2EEResourceProperty", attrList);
上面的代码会在
DataSource 配置对象中生成下面的 XML 片断:
<propertySet XMI:id="J2EEResourcePropertySet_1">
<resourceProperties XMI:id="res_prop_1" name="DatabaseName" type="Java.lang.String" value="myDatabase" />
</propertySet>
引用属性
引用类型属性不是直接包含一个值;而是引用其他地方定义的其他配置对象,比如前面一段中显示的
DataSource 配置对象的
relationalResourceAdapter 属性。被引用配置对象的标识可充当任意引用类型属性的值,在本例中,
relationalResourceAdapter 属性的值就是被引用的
J2CResourceAdapter 配置对象的标识。
创建与删除配置对象
ConfigServiceSample2 代码样本(请参见
下载)说明了如何创建与删除配置对象。这段样本代码将:
- 创建一个
Server
- 创建一个
JDBCProvider
- 创建一个新的
DataSource
- 删除上面所创建的
Server 。
下面几部分再看一下在样本中是如何对这些函数进行编码的,同时还将讨论关系(relationship)、模板(template)和范围(scope)等概念。
创建一个 Server
在样本代码中,通过
createConfigData 方法创建了一个新的
Server 配置对象。您一般只需要指定它的
name 属性。配置服务会建立日志目录并恰当地解决端口冲突问题。创建了服务器(server),您就可以用
setAttributes 方法进一步修改属性。
// query to get the config object ID for the node
// where we want to create the new server.
ObjectName node = configService.resolve(session, "Node=" + nodeName)[0];
// create a new application server.
AttributeList attrList = new AttributeList();
ConfigServiceHelper.setAttributeValue(attrList, "name", serverName);
ObjectName newServer = configService.createConfigData(session, node, "Server","Server", attrList);
createConfigData 方法会要求您指定创建的配置对象的父配置对象和属性名。前面描述过,配置对象可以是嵌套的,可以被建模为父配置对象的属性。然而,由于 WebSphere Application Server 配置数据存储在一组配置文档中,因此父配置对象和新的配置对象可能驻留在不同的文档中。在这种情况下,新创建的配置对象就无法被建模为父配置对象的属性。例如,从逻辑上说一个 Node 配置对象包含多个 Server 配置对象,但 Node 配置对象存储在一个
node.xml 文件中,而 Server 配置对象却存储在
server.xml 文件中,因此 Server 配置对象并不是 Node 配置对象的一个属性。配置服务使用“关系”这个术语描述驻留在不同配置文档中的配置对象间的逻辑包含关系。
每个关系都有一个名称-值对:
- 关系的名称描述配置对象间的逻辑包含关系的类型
- 关系的值是相互关联的配置对象组成的一个集合,可以为空(empty)。
当父配置对象和新的配置对象在不同配置文档中时,
createConfigData 方法中应该使用关系名,而不应使用属性名。在此样本代码中,第一个
Server 是节点与新创建的服务器之间的关系名。图 3 展示了 Node 配置对象的各个关系的名称:
- parent
- Server
- JDBCProvider
- J2CResourceAdapter
- JMSProvider
- VariableMap。
图 3. 示例节点关系
parent 关系把配置对象和包含它的配置对象关联在一起,在本例中该父对象是个单元配置对象。其他关系把配置对象和它逻辑上包含的任意类型的配置对象关联在一起。关系名称通常是描述包含的配置对象的类型;“server”关系描述节点上的服务器,依此类推。下面的代码样本展示了如何获取包含指定节点的单元配置对象,以及如何获取该节点上的服务器。一个配置对象所拥有的关系集取决于配置对象的类型。您可以使用
getRelationship 和
getRelationships 来获取关系值。
// get the Cell config object.
ObjectName cell = configService.getRelationship(session, node, "parent")[0];
// list servers on the node
ObjectName[] servers = configService.getRelationship(session, node, "Server");
创建一个 JDBCProvider
不同数据库供应商(不同实现)的 JDBCProvider 配置方法有很大的区别,因此配置服务提供了
createConfigDataByTemplate 方法,让您可以为创建的配置对象指定一个模板。这个方法会创建一个空白的配置对象,并将配置数据从所选的模板复制到所创建的配置对象,然后为该配置对象应用指定的属性值。您可以指定系统定义的模板(有几种是为普通的数据库供应商和实现提供的),也可以指定现有的配置对象来充当模板。
系统定义的模板存储在
config 目录下的
templates 目录中,并且只有在创建配置对象时才用到。配置服务提供了
queryTemplates 方法来查询系统定义的所有模板。下面的样本代码将查询系统中定义的所有 JDBCProvider 模板,并使用
Cloudscape JDBC Provider 5.0 模板创建一个新的 JDBCProvider。
String jdbcProviderTemplateName = "Cloudscape JDBC Provider 5.0";
ObjectName[] templates = configService.queryTemplates(session, "JDBCProvider");
ObjectName match = null;
for (int i = 0; i < templates.length; i++) {
System.out.println("JDBCProvider template" + templates[i]);
if (jdbcProviderTemplateName.equals(ConfigServiceHelper.getDisplayName(templates[i]))){
match = templates[i];
break;
}
}
System.out.println("found JDBCProvider template " + match);
// create an instance of embeded JDBC provider using template.
attrList.clear();
ConfigServiceHelper.setAttributeValue(attrList, "name", jdbcProviderName);
ObjectName jdbcProvider = configService.createConfigDataByTemplate(session, newServer, "JDBCProvider",
attrList, match);
创建一个新的 DataSource
下面的代码将用上面创建的 JDBCProvider 创建一个新的 DataSource:
// create a JDBC data source for the application.
ConfigServiceHelper.setAttributeValue(attrList, "name", dataSourceName);
ConfigServiceHelper.setAttributeValue(attrList, "jndiName", "foo");
ObjectName newDataSource = configService.createConfigData(session, jdbcProvider,"DataSource",
"DataSource", attrList);
删除一个配置对象
您可以用
deleteConfigData 方法来删除任何配置对象。请注意,删除一个父配置对象时还会删除它的所有子配置对象。例如,如果您删除
JDBCProvider的话,其下定义的
DataSource也会被隐式删除。
配置服务与管理安全
作为 WebSphere Application Server V5 管理编程模型的一部分,所有配置服务方法都受 WebSphere 管理安全基础结构的保护,这个基础结构中预定义了几种管理角色:管理员(administrator)、配置者(configurator)、操作员(operator)以及监视者(monitor)。(请参阅
WebSphere 5.0 信息中心以获取对这些角色的描述,以及关于如何向组和用户分配这些角色的指导。特别有价值的部分包括:
Planning to secure your environment、
Role-based authorization以及
Assigning users to administrator roles。)
至于要求哪些管理角色来调用各种配置服务方法,一般的规则是:只读方法只要求监视者来调用,更新方法要求配置者来调用。由于这些角色间的关系可以替换,因此允许被任命为任意管理角色的用户访问只读方法,同时还允许被任命为管理员或配置者的用户访问更新方法。另外,还要求管理员角色用传统的方式访问安全信息(密码、密钥文件等等)以更好地保护敏感数据。
下面这些是只读方法:
- getAttribute
- getAttributes
- getAttributesMetaInfo
- getConflictDocuments
- getRelationship
- getRelationships
- getRelationshipsMetaInfo
- getSupportedConfigObjectTypes
- getUnsavedChanges
- queryConfigObjects
- queryTemplates
- resolve
- validate。
当配置服务在服务器外运行时,并没有对其实施访问控制,因为管理安全基础结构是在服务器内运行。在这种情况下,配置文档只受文件系统访问控制机制保护,也就是说只要您有访问配置文档的文件系统许可权,您就可以通过配置服务读取和修改配置。不过您也不必担心安全问题,因为文件系统访问控制机制通常都可以提供充分的保护。
用配置服务向用户分配管理角色
配置服务定义了四种命名(naming)角色来控制对 JNDI 名称空间的访问:CosNamingRead、CosNamingWrite、CosNamingCreate 以及 CosNamingDelete。(请参阅 WebSphere Application Server 5.0 信息中心的
Role-based authorization部分以获取有关这几种角色的更多信息。)用户到管理角色的映射存储在
naming-authz.xml 文件中,您可以使用类似的逻辑向用户分配管理角色。唯一不同的是,您应该使用命名角色名称,而不是管理角色名称。
结束语
本文说明了如何通过编程的方式用配置服务查询和修改 WebSphere Application Server 配置。本系列的下一篇文章将向您展示如何同样通过编程的方式来安装和管理您的 Web 应用程序。
相关信息
下载 | 名字 | 大小 | 下载方法 |
|---|
| configservice.zip | 0.1 MB | HTTP |
关于作者  | |  |
Qinhua Wang是 IBM 的一名顾问软件工程师,在位于德克萨斯州奥斯汀市的 WebSphere Application Server 开发机构工作。从 WebSphere Application Server V3.5 开始,她就一直是 WebSphere 系统管理小组的主要开发人员之一。她主要从事 WebSphere 配置方面的工作。您可以通过
qwang@us.ibm.com与 Qinhua 联系。
|
对本文的评价
|