藉助包裝外部系統管理工具，通過雲來實現企業操作自動化

CloudSpace發表於2010-09-29
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/，如需轉載，請註明出處，否則將追究法律責任。

相關文章