WebSphere sMash 的创新应用，第 2 部分: 借助包装外部系统管理工具，通过云来实现企业操作自动化

本系列文章描述了有关 IBM® WebSphere sMash® 的真实例子，在该例子中 IBM WebSphere sMash 被选择用于执行创新和有价值的任务，来辅助位于美国 CT Southbury 的 IBM's Green Innovation Data Center（GIDC）的运行。第 1 部分 关注如何利用 WebSphere sMash 为构造数据中心指示板构建灵活的架构。在本文中，您将看到 WebSphere sMash 如何利用易用 APIs 包装外部系统管理工具来简化那些高成本的、会增加 GIDC 运行开销的手工任务的自动化。

简介

运行数据中心时，不能只盯着满架的服务器。为达到当今企业在安全标准、数据保护、以及资产管理方面的需求，所必须执行的流程和过程的数量在不断增长。找到新方法来自动化这些任务，并将它们构建到灵活的工作流中，是创新工程组所关注的一个重要问题。

本文重点介绍，利用 WebSphere sMash 的特性，轻松包装外部 API，来实现过去必须由操作人员利用用户接口来执行的一系列步骤，自动化地由云管理基础结构的控制组件驱动的相关例子。

您还有机会了解，应用 WebSphere sMash 生成 Web 应用开发与配置组件特性的技巧。

一个企业应用场景

在我们的环境中，所有联网计算机 — 真实的和虚拟的 — 都需要在数据库中注册，该数据库作为 Address 数据库。传统上，用户通过具有典型用户接口的 Web 应用，来添加、删除、以及更新系统的每个条目。然而，引入云环境后，我们想要在用户发出请求时，利用与其使用习惯相应的注册实例，来简化处理流程。

幸运的是，我们的 Address 数据库应用中已经包含了一个用于执行这些操作的 Java™ API。企业云中的每个云管理系统可以包括一个利用该 API 来管理 Address 数据库中条目的 Java 程序。

然而，试想一下，多个云系统想要利用这一服务的优势。为避免不得不在多个地方分发与更新 Java API 库，我们可以创建包含该 Java API 的服务，从而其他系统就可以利用 RESTful 端点，通过 HTTP 访问该服务。我们能够拥有贯穿整个企业的公共服务。开发该服务背后的步骤，就是本文所关注的焦点。

图1 阐明了该体系结构的概述。通常，系统 — 而不是用户 — 将连接我们所提供的服务，虽然操作人员仍然可以使用用户接口来直接访问 Address 数据库。

图 1. Address 数据库包装器架构

查看原图（大图）

您将看到 WebSphere sMash 如何通过消除复杂的配置和引导您关注应用的逻辑，来简化这一流程。

本文假设您熟悉 WebSphere sMash 环境的基本设置以及 “hello world” 应用程序的创建，并假设您已阅读了本系列的 第 1 部分 ，该部分介绍了将在这里详细叙述的概念。在本例中，这一简单应用将被编码到 Groovy 中，但是 WebSphere sMash 为您提供 PHP 替代选项，您可自己选择。

创建基础

在该 Address 数据库上您所要支持的操作包括：创建、删除、列表、检索、以及更新记录。

第 1 部分 说明 WebSphere sMash 如何在 Groovy 文件中轻松实现这些基本操作与方法、HTTP 路径以及操作之间的映射。然而，该文章只关注从服务获取数据（检索以及列表）。在此，服务调用者越想执行更多类型的操作，事情就会变得越有趣。由于用于 Address 数据库的 Java API 提供了所需的操作，您的任务就是将 API 中的 Java 方法与 URI 端点联系起来。

我们用清单 1 中所列出的方法在 /resources 目录中创建名为 system.groovy 的 Groovy 处理程序。要记住，目录 /resources 是包含用于管理收集的 REST 处理程序的优选位置。在本例中，收集是您正在 Address 数据库中注册与管理的一系列系统。

清单 1. system.groovy 的根存方法

def　onList()　{　　
　
　print("This　function　will　list　systems　in　the　database.")　
　
}　
　
def　onCreate()　{　　
　print　("This　function　will　create　a　new　system　in　the　database")　
　
}　
　
def　onRetrieve()　{　　
　print　("This　function　will　retrieve　a　particular　system　from　the　database")　
　
}　　
　
def　onUpdate()　{　　
　print　("this　function　will　update　an　existing　system　in　the　database")　
　
}　　　
　
def　onDelete()　{　　
　print　("this　function　will　delete　an　existing　system　from　the　database")　
　
}

正如表 1 中所列出的，每个方法将由不同的 HTTP 操作触发，该表展示了 HTTP 操作与 URIs 以及方法之间的映射。概括地说，这是我们的 RESTful API。

表 1. HTTP 操作与 URIs、以及方法之间的映射

例如，对 /resources/system 执行 HTTP GET，会将 onList 函数映射到 system.groovy 中。以所提供的数据作为负载，对 /resource/system 执行 HTTP POST，将会触发函数来创建新的系统记录。事情就是这么简单，不需要做任何配置。

然而，如果您不想采用默认映射，您可以通过在 zero.config 配置文件中编写定制处理程序配置，并将其映射到 Groovy、PHP、或者 Java 代码来完成映射。

您是否期待在您的系统上进行多种 HTTP 操作测试？Firefox 插件 Poster 可帮助您快速地在您所指定的 URL 上进行 GET、POST、PUT、以及 DELETE 操作测试。

此时，您可对所有操作进行测试。在首次启动应用之前，有必要在应用程序的根目录中，以命令行的方式运行 zero resolve 来进行启动。假定应用程序在本地运行，并采用默认端口 8080，可通过浏览器访问应用的默认 URL：http://localhost:8080/resources/system。

通过表 1 ，可见这个 URL 映射到一列操作，onList。onList 方法只是带有一些浏览器输出的存根。此时，将会在浏览器窗口中看到以下文字：This function will list systems in the database。

如果正在数据库中创建新的条目，可尝试在处理程序上执行 POST，来查看来自存根的响应。此时，不必考虑在 HTTP 请求中加入任何载荷，因为还没有包含相关的解析代码。

连接到后端

此时已经拥有了 system.groovy 中每个操作的存根，并且已了解如何基于所选择的 URL 和 HTTP 方法来引用不同的方法。下面的任务是如何挂接到来自 Groovy 处理程序的 Address 数据库遗留 Java API。我们来看一下如何将两者联系起来。

首先，将 Address 数据库 Java 库 JAR 文件放入 WebSphere sMash 应用的 /lib 目录中，这样就可以利用代码来访问这些类。/lib 目录中的 Java JARs 会在应用启动时自动加载，这样就不再需要手动调整类路径。

针对本例的目的，假设 JAR 文件名为 addressdb.jar，并且它还包含一个 Java 接口 com.ibm.addressdb.Manager.class 来连接到 Address 数据库并执行操作。清单 2 列出了管理接口的细节，并且实现（未展示出来）包含在 ManagerImpl.class 中。JAR 还定义了类 com.ibm.addressdb.SystemDetails.class，其代表了 Address 数据库应用中的一个系统。

清单 2. 管理接口

package　com.ibm.addressdb;　
　
import　java.util.List;　
　
public　interface　Manager　{　
　
　public　abstract　void　logon(String　username,　String　password)　throws　Exception;　
　
　public　abstract　List<SystemDetails>　listSystems();　
　
　public　abstract　SystemDetails　getSystem(int　systemId)　throws　Exception;　
　
　public　abstract　SystemDetails　addSystem(SystemDetails　newSystem)　throws　Exception;　
　
　public　abstract　SystemDetails　updateSystem(int　sysId,　
　　SystemDetails　system)　throws　Exception;　
　
　public　abstract　int　deleteSystem(int　sysId)　throws　Exception;　
　
}

为使用来自 Groovy 的 Java 工件，包含相应 Java 导入语句。可以无缝地在您的 Groovy 方法中（清单 3）使用它们。

清单 3. 在 system.groovy 上构建

import　com.ibm.addressdb.Manager;　
import　com.ibm.addressdb.ManagerImpl;　
import　com.ibm.addressdb.SystemDetails;　
　
　
def　onList()　{　
　
　Manager　m　=　ManagerImpl.getInstance　()　
　m.logon　('addressdbid@myorg.org','systempassword')　
　List　list　=　m.listSystems　()　　
　request.view='JSON'　
　request.json.output=list　
　render()　
　
}

onList 方法用于通过 Java API 连接 Address 数据库，并在表单 JSON 中返回系统列表。请注意，WebSphere sMash 请求处理程序框架会利用所示的语法，自动将包含零或更多 SystemDetails 的 List 对象转换为 JSON 数组。要确保 List 类型的 getters 和 setters 遵循 JavaBean 惯例来支持这一转变。清单 4 展示了相应的示例。随后，将介绍如何对密码进行编码，来避免其以明文形式在代码中出现。

清单 4. 对列表请求的响应

[　
{　
"creatorId":"cloud1@myorg,com",　
"ipAddress":"9.45.15.40",　
"ownerId":"user1@myorg.com",　
"systemId":"0",　
"systemName":"financeServer"　
}　
{　
"creatorId":"cloud1@myorg,com",　
"ipAddress":"9.45.15.41",　
"ownerId":"user2@myorg.com",　
"systemId":"1",　
"systemName":"hrServer"　
}　
]

接下来，我们来看您如何为在数据库中创建新的系统记录而进行 onCreate 方法编码。在此，需要领会包含系统细节的 POST 内容，然后将这些填充进 Java API。该操作通过提取 HTTP POST 的内容，并将其转换成 JSON 对象来实现。那么，就可方便引用传入的特定属性。清单 5 以在 POST 请求中显示的格式展示一些系统参数。

清单 5. 创建系统记录的 POST 参数样例

{　
　"systemName":"auditServer",　
"ownerId":"user4@myorg.com",　
　　　　　　"ipAddress":“9.45.15.43"　
}　

清单 6 展示了如何轻松地提取请求中的参数并将其提供到 Java API 中。注意，从 JSON 对象中提取 IP 地址、系统名、以及系统所有者名，并将其传入您的服务中。

然而为了审计，还需要识别与服务请求相关的 ID。调用服务的系统将其作为服务 ID。为此，需要通过从检索全局上下文，来获取认证用户的用户名。参见 Global Context Reference 来了解其默认的存储值。借助这一参考，能够发现登录用户的用户名存储在 /request/subject/remoteUser 中。可通过将请求路径作为参数来执行 zget 方法，在全局上下文中检索成员：

zget (“/request/subject/remoteUser”)

或者通过调用另一个语法：

request.subject.remoteUser []

这将会返回认证的用户名。接下来，使用第二个语法，的它很简洁。

因为在当前的应用中并未采用身份认证，此时执行 remoteUser 检索将会返回空值。在下一部分中，您可了解到如何利用 LDAP 来建立认证与授权规则。

在 onCreate 方法的最后，会依照 REST 惯例，返回一个合适的 HTTP 代码。如果创建成功，会返回 HTTP 状态代码 201，来表明操作成功并且已经创建了一些内容。还会在 HTTP 资源头中返回新资源的位置。例如，新系统可能位于 URI：http://localhost:8080/resources/system/3。

可利用这一位置来检索新创建系统的 ID，确定其 ID 并查看其数据。需要追踪本地系统 ID，这样就可在其上执行后续操作（检索、更新、删除），但在本文中我们将要略去对本地数据库的管理。所创建的元素可被有选择地返回，但这不是必需的，我们选择不包含这些。

清单 7 展示检索系统的代码，清单 8 展示了删除系统，清单 9 展示了创建系统。

一些所有技术的注释：

将 POST 或者 PUT 主体中的 JSON 字符串转换为 JSON 对象，采用如下语法：

def systemInputs = zero.json.Json.decode(request.input[]);

接下来您可轻松访问 JSON 对象成员。可在 onUpdate 与 onCreate 中查看相关示例。

如前面所提到的，可利用 WebSphere sMash 的请求/响应框架，将简单 Java 对象和集合（Lists,、Maps 等等）转换成相应的 JOSN。该技术在 onRetrieve 和 onList 方法的最后有相关说明。没有必要手动将 Java 对象转换成 JSON 对象。

将系统 ID 作为 URL 参数提取的方法（onCreate、onRetrieve、onDelete 以及 onUpdate），采用如下语法：

request.params.systemId[]

为引用 URL 参数，然后将参数转换为整数。要遵照以下惯例来构成 “systemId” 部分：将出现在URL（在本例中为 “system” ）中的集合资源名与 “Id” 连接来生成 “systemId”。

注意，不论在成功或失败的案例中，在每个方法的最后总返回 HTTP 返回代码。这些提供了 API 中成功操作的一个清楚而简洁的表示。

清单 6. system.groovy 的 onCreate 方法

def　onCreate()　{　
　　
　//Convert　request　entity　to　JSON　object　
　//then　we　can　easily　pull　out　the　objects　from　it　
　def　systemInputs　=　zero.json.Json.decode(request.input[])　
　
　SystemDetails　newSystem　=　new　SystemDetails　()　
　
　newSystem.setIpAddress　(systemInputs.ipAddress)　
　newSystem.setSystemName　(systemInputs.systemName)　
　newSystem.setOwnerId　(systemInputs.ownerId)　
　
　String　remoteUser　=　request.subject.remoteUser[]　
　
　if　(remoteUser　==　null)　{　
　　
　remoteUser　=　'none'　
　//handle　error...　
　}　
　
　newSystem.setCreatorId　(remoteUser)　
　
　
　
　Manager　m　=　　ManagerImpl.getInstance　()　
　m.logon　('addressdbid@myorg.org','systempassword')　
　
　SystemDetails　confirmedSystem　=　m.addSystem　(newSystem)　
　
　
　if　(confirmedSystem　!=null　)　{　
　//　Set　a　Location　header　with　URI　to　the　new　record　
　　　locationUri　=　getRequestedUri(false)　+　'/'　+　newSystem.getSystemId()　
　request.status　=　HttpURLConnection.HTTP_CREATED　
　
　　
　}　else　{　
　　
　//handle　error　
　request.status　=　HttpURLConnection.HTTP_INTERNAL_ERROR　
　request.error.message　=　"system　$requestSystemId　not　found."　
　　　　request.view　=　'error'　
　　　　render()　
　
　}　
　
　
}

清单 7. system.groovy 的 onRetrieve 方法

def　onRetrieve()　{　
　
　
　//　Getting　the　system　id　of　the　system　from　the　REST　URL　
　//　Follows　the　convention　of　"collection　item　name"　+　"Id"　
　
　def　requestSystemId　=　Integer.parseInt(request.params.systemId[])　
　
　Manager　m　=　ManagerImpl.getInstance　()　
　m.logon　('addressdbid@myorg.org','systempassword')　
　SystemDetails　system　=　m.getSystem　(requestSystemId)　　
　
　String　response　=　null　
　
　if　(system　!=null　)　{　
　response　=　zero.json.Json.encode(system)　
　request.json.output=response　
　request.view='JSON'　
　　
　render()　
　
　　
　}　else　{　
　　//　Error　handling　
　　　　request.status　=　HttpURLConnection.HTTP_NOT_FOUND　
　　　　request.error.message　=　"system　$requestSystemId　not　found."　
　　　　request.view　=　'error'　
　　　　render()　
　
　　
　
　}　
　
}　

清单 8. system.groovy 的 onDelete 方法

def　onDelete()　{　
　
　def　requestSystemId　=　Integer.parseInt(request.params.systemId[])　
　
　Manager　m　=　ManagerImpl.getInstance　()　
　
　m.logon　('addressdbid@myorg.org','systempassword')　
　
　int　deletedSystem　=　m.deleteSystem　(requestSystemId)　　
　
　if　(deletedSystem　>=　0　)　{　
　request.status　=　HttpURLConnection.HTTP_NO_CONTENT　
　
　　
　}　else　{　
　　
　　//　Error　handling　
　　　　request.status　=　HttpURLConnection.HTTP_NOT_FOUND　
　　　　request.error.message　=　"system　$requestSystemId　not　found."　
　　　　request.view　=　'error'　
　　　　render()　
　
　}　
　
}

清单 9. system.groovy 的 onUpdate 方法

def　onUpdate()　{　
　
　
　
　def　requestSystemId　=　Integer.parseInt(request.params.systemId[])　
　
　
　Manager　m　=　ManagerImpl.getInstance　()　
　m.logon　('addressdbid@myorg.org','systempassword')　
　SystemDetails　existingSystem　=　m.getSystem　(requestSystemId)　　
　SystemDetails　confirmedSystem　=　null　
　
　if　(existingSystem!=null){　
　
　
　//　Convert　POSTED　data　to　JSON　object　
　//then　we　can　easily　pull　out　the　objects　from　it　
　def　systemInputs　=　zero.json.Json.decode(request.input[])　
　　
　　
　existingSystem.setIpAddress　(systemInputs.ipAddress)　
　existingSystem.setSystemName　(systemInputs.systemName)　
　existingSystem.setOwnerId　(systemInputs.ownerId)　
　　
　String　remoteUser　=　request.subject.remoteUser[]　
　　
　if　(remoteUser　==　null)　{　
　　
　　remoteUser　=　'none'　
　　//handle　error...　
　}　
　　
　existingSystem.setCreatorId　(remoteUser)　
　　
　　
　confirmedSystem　=　m.updateSystem　(requestSystemId,　existingSystem)　
　}　　　　
　
　if　(confirmedSystem　!=null　)　{　
　
　request.status　=　HttpURLConnection.HTTP_NO_CONTENT　
　
　}　else　{　
　　
　　//　Error　handling　
　　　　request.status　=　HttpURLConnection.HTTP_NOT_FOUND　
　　　　request.error.message　=　"system　$requestSystemId　not　found　or　could　not　be　
　updated."　
　　　　request.view　=　'error'　
　　　　render()　
　}　
　
　
　
}

加强服务的安全

现在已完全拥有了服务的基础，但还有必要实现对其安全访问。不仅您和访问该服务的注册用户需要知道它，而且还要确保只有授权的系统或用户可以访问它。幸运的是，WebSphere sMash 设计目的是使资源安全保护直接了当。最妙的是，仅需几行配置就可实现应用安全。

清单 10 阐述了可包括在 zero.config 中的配置。

清单 10. 安全配置

#　Enable　Security　
@include　"security/enableSecurity.config"　
　
#　Secret　Key　-　run　"zero　secretkey"　CLI　command　to　generate　secret　key　
#　Required　whenever　security　is　enabled　in　sMash　
/config/security/secretKey　=　"xMgwl+sUzcsRBLb4tBkn5w=="　
　
　　
　
#　Using　the　LDAP　for　authentication　
/config/security/userservice/registryType="ldap"　
　　
　
###　Inbound　authorization　to　this　wrapper　
　　　　　　　　　　　　　　　
#　LDAP　related　configuration　
/config/security/userservice/ldap　+=　{　
"jndiProviderUrl"　:　"ldaps://<serviceURL>　/",　
"jndiSecurityAuthentication"　:　"simple",　
"ldapSearchScope"　:　2,　
"ldapUserIdSearchFilterPattern"　:　"(&(mail={0})(objectclass=person))",　
"ldapUserIdBaseDn"　:　"ou=bluepages,o=<domain　name>.com",　
"ldapGroupBaseDn"　:　"ou=memberlist,　ou=<groupdDN>,o=<domain　name>.com",　
"ldapUserIdAttributeType":　"mail"　
}

逐步浏览这一配置：

参考包含在 WebSphere sMash 框架中的配置 security/enableSecurity.config 来确保安全。参考包含在 WebSphere sMash 框架中的配置 security/enableSecurity.config 来启用安全功能。

为了能在应用程序上下文中使用安全功能，需要生成一个密钥。该密钥用于在 WebSphere sMash 环境中加密机密用户数据。生成操作要在 Zero 命令行中使用命令 zero secretkey 实现。一旦生成了密钥，就需要将其包含到文件 zero.config 中。清单 10 展示了密钥的示例。

选择如何进行用户认证。可以在应用中包含一系列用户名和密码，还可以挂接到 LDAP 目录。在本例中，将连接到 LDAP，其操作如下所示：

/config/security/userservice/registryType="ldap"

为了进行测试，可能需要采用基于文件的用户注册方式。这一点在 WebSphere sMash 文档中有具体描述。

包括了 LDAP 数据库，其中是企业 LDAP 服务器所特有的代码。需要依据所采用的 LDAP 服务来定制该代码。

配置的最后一部分，包含在清单 11 中，这部分指出了所需保护的资源以及所要采用的认证方式。本例中选用基本认证方式。配置文件指出了以 “/resources/” 开头的资源需要授权。换句话说，保护的是 resource 目录下的资产而不是整个应用程序。假设有一些文档位于应用程序的公共目录下，任何人都可对其进行访问。如果采用这一安全配置将无法保护 WebSphere sMash 目录结构中 /resource/ 路径之外的公共目录。

注意，授权条件可能需要更细的粒度。在本例中，应用需要在 system.groovy 上执行除了 GET 之外所有操作，包括 POST、PUT、DELETE，进行授权。或者，也可以简单地只包含 HTTP 和 GET 操作。后面将对此做演示。

最后，指定允许访问的 LDAP 组 Address-Database-Wrapper-Users。非该组的用户将无法访问服务。

清单 11. 加密资源
#uses　group　discovered　through　LDAP　authentication.　
@include　"security/basicAuthentication.config"{　
　　　"conditions":　"(/request/path　=~　/resources　(/.*)?)　&&　　
　(/request/method　=~　(POST|　PUT|DELETE))　"　
　　"groups"　:["Address-Database-Wrapper-Users"]　　　　
}

重启应用，并尝试对 http://localhost:8080/resources/system 执行 GET 或 POST 操作，将出现认证提示。

基本认证容易实施，因此在原型及情景应用中大量使用。还可方便用于本文所描述的系统到系统的场景中。它也有一些缺点，例如，用户名密码弹出对话框是否美观，要看浏览器的实施情况。另外，浏览器会缓存用户名和密码基本认证，因此无法进行刷新。其结果是退出很难实现。用户需要关闭浏览器来退出应用程序。

为实现更可靠以及定制化功能更强的认证处理，并获得更流畅的用户体验，您可能会选择基于表单的认证方式。此处不讨论基于表单认证方式的细节，但是 WebSphere sMash 框架支持这种方式。

利用 HTTPS 实现安全连接

由于需要请求用户名和密码，因此，在实际环境中必须采用 HTTPS 来实现安全连接。因为开发工作的需要，可以采用自签名认证，WebSphere sMash 在 zero.core.webtools 中包含一个自签名认证测试组件。

为启用 HTTPS，需要对文件 zero.config 进行一些配置，见清单 12。注意，密码 keystore 带有前缀 “<xor>.”。这一语法说明密码已加密，不会以明文方式出现在配置文件中。

现在要编码以明文形式包含在 groovy.system 中，用于后端 API 的密码。可利用 XOREncode 工具完成此操作。在利用 XOR 对应用程序进行编码时，可查询 WebSphere sMash 相关文档。

清单 12. 启用基本 HTTPS - 入站

/config/https/port　=　8443　
/config/https/sslconfig　=　{　
　　　　"keyStore":　"./config/key.jks",　
　　　　"keyStorePassword":　"<xor>JTotMC8+LCw="　
　
’,　
　　　　"keyStoreType":　"JKS"　
}

配置文件

关于配置的其他一些设置。

采用 WebSphere sMash，需要为应用程序设置上下文根。这有助于确保应用程序的可移植性，并可避免在假定应用资源位于根 “/” 中的前提下进行编码。还可在应用中为 URLs 增加可描述属性。下面是需要在 WebSphere sMash 中设置根上下文的配置示例：

/config/contextRoot="/addressdb"

通过正确设置，应用程序的基本 URL 改变了，之前是 http://localhost:8080/resources/system，现在变为 http://localhost:8080/addressdb/resources/system。

到目前为止，已经介绍了很多需要在配置文件中进行的设置。默认情况下，WebSphere sMash 会查找名为 zero.config 的配置文件。但是，随着配置的增加，zero.config 会变得难以控制。WebSphere sMash 中的一些特性能够帮助避免这一问题。

配置文件包括

配置文件中可以包含其他配置文件。清单 12 展示了将安全配置移动到其所拥有文件中的示例。您可能会发现，在为应用启用安全功能时，曾经见过这一示例。其中包含用于启用安全功能的基本 WebSphere sMash 配置文件。可对我们的文件采用相同的方法。

在清单 13 中，用于连接数据库 Address 的用户名和密码都加入到配置中，这样就可以从代码中删除最初写入的文字值（清单 3、6、8 和 9）。如前面所述，已利用 XOR API 对真实密码 “systempassword” 进行编码，实现了模糊处理；查看配置文件的其他用户无法读取该密码。如果想在代码中引用这些配置值，可采用与获取远程用户操作相同的语法。在本例中，采用 config.addressDB.username[] 来检索用户名。

清单 13. 包含配置文件

zero.config　的内容：　
　
…　
@include　"addressDBSecurity.config"　
…　
　
　
Contents　of　config/addressDBSecurity.config:　
….　
#default　logon　ID　and　password　to　access　backend　Address　Database　
/config/addressDB/username="addressdbid@myorg.org"　
/config/addressDB/password=<xor>df3533wsKG8tOw==　
　
　
#　Enable　Security　
@include　"security/enableSecurity.config"　
　
#　Secret　Key　-　run　"zero　secretkey"　CLI　command　to　generate　secret　key　
　
/config/security/secretKey　=　"xMgwl+sUzcsRBLb4tBkn5w==""　
　
...

重写配置

通常，您很希望能有一个配置文件来帮助组织配置。这样还可以很方便地重写文件中所包含的属性。WebSphere sMash 能够轻松实现这一需求。举一个例子：假设在测试应用时，想利用非默认的测试用户名和密码来连接后端 Address 数据库。清单 14 如何设置 zero.config 文件来达到这一目的。在本清单中，重写了 addressDBSecurity.config 中所提供的默认用户名和密码。

清单 14. 重写匹配规则

Contents　of　zero.config　
　
…　
@include　"addressDBSecurity.config"　　
#override　the　username　and　password　used　to　connect　to　the　backend　Address　Database.　
/config/addressDB/username　="test-addressdbid@myorg.org"　
/config/addressDB/password="<xor>MiYvPiwsKG8tOw=="

这模仿在清单 11 资源上中首次设置认证时的技术。在清单 14 中，创建清单 13 上的配置。将整个安全配置转移到 addressDBSecurity.config 中。当调用包含时，就指出了希望替代 addressDBSecurity.config 中的基本配置，就不需要对 “GET” 请求做认证。

调试技术

如果既启用安全功能又要连接到供应商服务，那么启用附加追踪很有必要。requestLogging 服务在针对服务的追踪请求中很有用。每个请求记录到单独的文件中，并包含有价值的信息。而且，还会发现需要针对特定组件的附加追踪。清单 15 展示了日志配置的示例。

清单 15. 日志配置示例

#Enable　the　logging　
/config/requestLogging　=　true　
　
#　Enable　fine　detail　on　certain　components.　
/config/logging/levels　=　{　
　　　　"zero.core.config"　:　"FINE",　
　　　　"zero.core.security"　:　"FINEST"　
}

在应用正式上线时，确保已禁用或减少了日志，因为日志总会增加性能负载，而且详细的追踪日志会快速增长，并会消耗掉可用的硬盘空间。

结束语

本系列的第 2 部分，介绍了如何利用 WebSphere sMash 来围绕旧版 Java 工具构建 RESTful API 到外部系统管理应用的包装，并检查了将 WebSphere sMash 编程模式惯例用于支持快速应用开发的更多方法。

本系列中的第 3 部分将介绍 WebSphere sMash 利用可视化工具来创建工作流的能力，并介绍如何将其包含在应用当中。