ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 借助包装外部系统管理工具,通过云来实现企业操作自动化

借助包装外部系统管理工具,通过云来实现企业操作自动化

原创 Linux操作系统 作者:CloudSpace 时间:2010-09-29 14:27:45 0 删除 编辑
Aaron Kasman, 高级软件工程师, IBM
Andy J. F. Bravery, 高级技术专家组成员,高级 IT 架构师, IBM

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

简介

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

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

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

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

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

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

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


图 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、以及方法之间的映射

HTTP 方法 URI 描述 映射到方法
GET /system 返回系统列表。 onList
POST /system 创建新系统。 onCreate
GET /system/3 检索系统 3 的细节。 onRetrieve
PUT /system/4 更新现有的系统 4。 onUpdate
DELETE /system/7 删除现有的系统 7。 onDelete

例如,对 /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 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:// /",
"jndiSecurityAuthentication" : "simple",
"ldapSearchScope" : 2,
"ldapUserIdSearchFilterPattern" : "(&(mail={0})(objectclass=person))",
"ldapUserIdBaseDn" : "ou=bluepages,o=.com",
"ldapGroupBaseDn" : "ou=memberlist, ou=,o=.com",
"ldapUserIdAttributeType": "mail"
}

逐步浏览这一配置:

  1. 参考包含在 WebSphere sMash 框架中的配置 security/enableSecurity.config 来确保安全。参考包含在 WebSphere sMash 框架中的配置 security/enableSecurity.config 来启用安全功能。
  2. 为了能在应用程序上下文中使用安全功能,需要生成一个密钥。该密钥用于在 WebSphere sMash 环境中加密机密用户数据。生成操作要在 Zero 命令行中使用命令 zero secretkey 实现。一旦生成了密钥,就需要将其包含到文件 zero.config 中。清单 10 展示了密钥的示例。
  3. 选择如何进行用户认证。可以在应用中包含一系列用户名和密码,还可以挂接到 LDAP 目录。在本例中,将连接到 LDAP,其操作如下所示:

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

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

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

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

  6. 最后,指定允许访问的 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"]   
    }

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

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

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

利用 HTTPS 实现安全连接

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

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

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


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

				
/config/https/port = 8443
/config/https/sslconfig = {
        "keyStore": "./config/key.jks",
        "keyStorePassword": "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=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="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"
}

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

想了解有关应用正式上线的其他有价值建议,参见 projectzero.org

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

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

作者感谢 Natasha Sharma 为实现本文档所描述服务所做的工作,并感谢 Steve Ims、IBM STSM 在审阅这些文章中所做的有价值的反馈和对细节的关注。

原文链接:http://www.ibm.com/developerworks/cn/websphere/techjournal/1007_kasman/1007_kasman.html

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14789789/viewspace-675105/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-08

  • 博文量
    355
  • 访问量
    860182