整合 IBM 後設資料儲存庫,第 1 部
簡介: 通過將您的應用程式與 IBM® Rational® Asset Manager 整合,學習如何支援基於資產的開發。本文主要介紹用於檢索和修改基於儲存庫資產的各種 API 的功能,其中包括使用 Web service 和 HTTP API 進行常見儲存庫操作的示例程式碼。
後設資料儲存庫是業務解決方案一個很重要的部分。本系列文章向您展示如何將您的應用程式和儲存庫整合、儲存庫間如何共享資產、如何發現和挖掘新資產、以及如何使用一個業務術語表從各種資源中分離後設資料。第 1 部分關注如何通過將您的應用程式和 Rational Asset Manager(以下稱為 Asset Manager)整合來支援基於資產的開發。後續文章涉及 Tivoli® Application Dependency Discovery Manager、WebSphere® Service Registry and Repository 和 WebSphere Business Glossary。
基於資產的開發(Asset-based development,ABD)是應對軟體生產和運輸的成本和效率方面不斷增長的挑戰的一個至關重要的機制。Asset Manager 是一個協作軟體開發的資產管理解決方案。支援建立、描述和管理基於可重用資產規範(Reusable Asset Specification,RAS)的資產,RAS 是一個源自 Object Management Group (OMG) 的行業標準。Asset Manager 也提供資產搜尋、更改跟蹤和生命週期管理,這將促進所有型別的軟體開發資產的重用。本文討論如何使用 Web 服務和 HTTP API 來將 Asset Manager 整合到跨平臺應用程式。使用這些 API 時 ABD 可用於各種軟體開發環境:
- 建立和修改一個資產
- 訪問一個資產的執行時後設資料
- 訪問 ABD 流程需要的系統後設資料
- 與資產管理流程互動
在本文底部的 下載部分 獲取本文樣例程式碼。
現代的資訊越來越龐大且複雜。商機出現時,客戶想要使他們的投資最大化;而解決方案的提供商想要重用以前的產品,在節省傳遞成本的同時提高質量。ABD 通過重用以前的解決方案(所謂的資產)來解決復發和新出現的問題,使雙方受益。這能減少資金投入、時間和勞動的重複。
ABD 流程包含四個關鍵階段:資產識別、資產生產、資產管理和資產消耗。被認為是潛在資產的解決方案向前移入到了生產。資產生產的結果在儲存庫中作為資產儲存和管理,並且被客戶重用。客戶也可以提供反饋給資產生產和管理階段,這有助於 ABD 流程成為一個自我完善的迴圈。
IBM 為資產生產、消耗和管理提供一套構建 ABD 流程的產品,包括 Rational Software Architect、Rational Clear Case/Clear Quest 和 Asset Manager。
在套件中,Asset Manager 是資產管理解決方案,在 ABD 流程中處於中心地位。除了資產管理之外,還提供一個協作機制用於資產重用,一個本體系統(ontology system)用於更好地進行資產分類,以及一個管理流程用於資產生命週期。應用程式需要同 Asset Manager 互動來加入 ABD 流程。
Asset Manager 提供兩種型別的使用者介面(UI)。一個是本地的基於 Web 的 UI,另一個是嵌入基於 Eclipse 的開發工具(例如,Rational Software Architect 或 WebSphere Business Modeler)的 Asset Manager Rich Client 外掛。外掛提供與 Asset Manager 的無縫整合。然而一個真正的開發環境通常包含用於不同平臺的多種開發和管理工具,而且使用者對這些工具的操作風格和 UI 可能已經很熟悉了。目前,如果您使用的工具不是基於 Eclipse 的,您必須使用 Asset Manager 的 Web 介面同 ABD Process 互動。
Asset Manager 也提供 API 將 Asset Manager 整合到其他應用程式。其中一個就是基於 Java 的二進位制 API(在 參考資料 的 Asset Manager InfoCenter 中獲取關於整合的 API 和指南的詳細資訊)。然而,該 API 是一個特定於平臺的實現,而其他非 Java 平臺(例如 Microsoft® .NET Framework)不能從該 API 中獲益。另一個是一個 Web 服務和 HTTP API,但是相對比較複雜。
本文討論如何結合使用標準 Web 服務呼叫和 HTTP 請求來將 Asset Manager 整合到應用程式。儘管解決方案被證實是 Java 的,但是也能應用於其他平臺。
Asset Manager 內容模型含有兩類資料:資產資料(與某一資產例項相關的資料)和系統後設資料(資產例項之間共享的資料)。圖 2 說明了 Asset Manager 內容模型。
資產資料包含基本資產資訊,一個資產清單、已擴充套件後設資料和資產內容(圖 3)。
基本資產資訊包含:
- 資產 ID 和資產版本,這是唯一識別資產的
- 資產最後一次更改的日期
- 資產的管理狀態
- 資產的名稱和簡要說明
資產清單是核心後設資料;遵循 RAS ,包含以下部分:
- 分類部分 — 一組描述符用於對資產進行分類,以及資產相關背景的描述。
- 解決方案部分 — 構件集合的索引,描述資產中構件的層次結構。
- 使用部分 — 安裝、定製和使用資產的規則。
- 相關資產部分 — 該資產與其他資產的關係。
已擴充套件後設資料是被 Asset Manager 定義的,用來提高使用體驗和方便使用者重用。這些後設資料包括:
- User Tags — 關於該資產使用者定義的描述性資訊,是附加在資產清單的分類部分的。
- Change History — 一個資產修改的日誌,能被用於資產版本和管理狀態跟蹤。
- Usage Metrics — 一些使用者對資產評價的統計資訊,是一種常見的資產度量方法。度量體系對於提高資產重用是很有用的。
資產內容是解決方案的實現。它包含在目錄層次結構中組織的一組構件。層次結構與資產清單中的解決方案部分是一致的。
系統後設資料是 Asset Manager 中所有資產例項共享的必要公共後設資料。它包含資產型別、類別模式和相關型別。它也是操作資產時重要的資訊。
Asset Manager 提供兩個 API:Web 服務和 HTTP。Web 服務 API 可以訪問系統後設資料和資產清單,但是不能建立和更新資產清單和內容。HTTP API 可以檢索、建立和更新資產內容,但是不能操作資產的已擴充套件資料和系統後設資料。一個成功的 ABD 整合必須結合兩個 API 的功能。
首先,您必須連線 API,兩個 API 都使用 HTTP Basic Authentication 進行識別使用者。因此請求被髮送之前,確保在 HTTP 頭部的使用者名稱和密碼是設定正確的。
HTTP API 使用 HTTP GET 請求來檢索資產內容,使用 HTTP POST 請求來建立和更新資產內容。HTTP API 的端點是:
https:// |
意識到這是一個 HTTP 連線 — 對於一個成功的請求您必須確保諸如金鑰儲存和信任儲存等安全連線引數被正確設定。
為了連線 Web 服務 API,進行以下操作:
- 下載 Asset Manager Web 服務的 Web Services Definition Language (WSDL) 檔案(參見 參考資料 中的 Asset Manager InfoCenter)。
- 使用一個程式碼生成器,例如 WSDL2Java,來生成遠端服務存根。
- 執行一個 Web 服務請求到以下地址:
http://
: /com.ibm.ram.repository.web.ws.was/RAMSecure/services/RAM1
連線完成後,您就可以通過使用在 WSDL 中定義的操作來訪問 Web 服務。在其他的平臺上,例如 .NET 或 C++,您可以使用類似的技術來連線 HTTP 和 Web 服務 API。
這有兩種格式可以訪問一個資產清單。您可以通過 HTTP 介面檢索整個清單 XML 檔案連同資產內容,或者您也可以以一種物件導向的方式使用 Web 服務介面定義的方法。
HTTP API 提供更低階別的資訊和對清單的完全控制,但是為了正確理解和修改清單,您必須熟悉 RAS,這種風格的一個優勢是您可以訪問資產內容和資產清單。這是非常有用的,因為對於建立和修改一個資產它們都是必須的。
要以這種風格訪問,首先,您必須使用資產 ID 和資產版本作為引數傳送一個 HTTP GET 請求。返回的響應是一個 ZIP 流,含有資產清單和資產內容。您可以將其儲存到本地磁碟或使用標準 ZIP 工具來處理它。一個資產 ZIP 檔案結構的樣例如圖 4 所示。
一個資產 ZIP 檔案包含資產清單檔案(manifest.rmd)和構件。清單檔案描述解決方案分類、使用和相關資產。圖 5 顯示了一個樣例清單檔案。
您可以使用標準 ZIP 和 XML 處理技術根據 RAS 來操作資產內容及其清單,這給您完全的資產控制,但是同時也意味著較少的直覺和更大的風險。例如,為了向資產新增一個分類術語,您必須在相應的 descriptorGroup 元素下新增一個 nodeDescriptor 元素,然而如果 descriptorGroup 不存在,您必須同時新增 descriptorGroup 和 nodeDescriptor 元素。(見 訪問系統後設資料 獲取如何通過新增一個新 descriptorGroup 元素來檢索所需資訊。)為了向資產新增一個構件,您首先必須在 ZIP 檔案中的正確位置新增該構件,然後向資產清單相應的解決方案部分新增一個構件實體元素。所有這些在核心資產檔案上的修改必須遵從 RAS。
一個資產被建立或修改之後,您可以使用 HTTPS POST 請求向 Asset Manager 儲存庫提交新資產。HTTP POST 引數在 Asset Manager InfoCenter(見 參考資料)中予以說明。
清單 1 說明了如何使用 HTTP 介面來訪問一個資產。
String http_location = "https://9.125.62.227:9080/com.ibm.ram.repository.web.ws.was/RAMSecure/ RAMAssetAccess.jsp?assetID={C986918C-8E01-4039-6D94-D56E0B6E57A6}&version=0.9"; try { // use the https get to get the asset content InputStream is = HTTPHelper.getHTTPSContent(oneAssetHTTPLocation, username, password); ZipInputStream zis = new ZipInputStream(is); ZipEntry zipEntry; int len = 0; String name = null; byte[] buffer = new byte[512]; while ((zipEntry = zis.getNextEntry()) != null) { ByteArrayOutputStream ut = new ByteArrayOutputStream(); name = zipEntry.getName(); while ((len = zis.read(buffer, 0, buffer.length)) != -1) { out.write(buffer, 0, len); } out.flush(); entryMap.put(name, out.toByteArray()); out.close(); } } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } byte[] mainfest = entryMap.get("manifest.rmd"); |
Web 服務介面對資產客戶是友好的。它以一種物件導向的方式提供訪問資產清單的物件和方法,並提供對資產已擴充套件後設資料的完全控制。
連線到 Web 服務介面之後,您可以在 Asset Manager 中的資產上執行一個搜尋,然後使用資產 ID 和版本來獲取資產的後設資料物件。後設資料物件包含關於資料清單的必要資訊。您可以呼叫 getManifest 方法來獲取清單檔案,與您在之前 manifest.rmd 檔案中所用的方式一樣,或者您可以呼叫關於資產後設資料物件的方法來獲取資產清單的對應部分。例如,您可以在資產清單中呼叫 getRelationships 方法來獲取 relatedAsset 部分,呼叫 getArtifactsRoot 獲取構件層次結構的根,然後遞迴呼叫 getChildren 方法來獲取整體構件層次結構。
一些已擴充套件後設資料,諸如使用者標記和修改歷史,也可以通過 Web 服務 API 檢索和修改,更多 Asset Manager Web 服務 API 的資訊,請參考 參考資料。
清單 2 說明了如何使用 Web 服務 API。
try { //Get the asset metadata object AssetSO asset = ramWebService.getAsset(assetID, assetVersion, true, true, true, true, true, true, true, true, true, "zh_CN"); //Get the category schema list related to this asset object CategorySchema[] categoryschemas=asset.getCategorySchemas(); for(int i=0;i |
一些常見的系統後設資料(例如資產型別、類別模式和關係型別)在 Asset Manager 儲存庫中被多個資產共享。在操作資產清單時該後設資料是必須的。例如,您可能需要檢索系統分離層次結構來更好地理解清單檔案的分類部分,或在您想要向資產中新增一個新分類時,您可能需要了解所有分類術語。這一部分介紹如何訪問兩類系統後設資料:類別模式和關係。
Asset Manager 分類系統包含一組類別模式,每個類別模式含有一組相關術語。在類別模式中每個術語有一個獨一無二的識別符號,並且該識別符號需要理解資產清單檔案中的分類部分。
首先,您需要知道在系統中有多少個類別模式。為了獲取所有類別模式物件的列表,使用 getCategorySchemas 方法,如下所示:
CategorySchemaSO[] categories = ramWebService.getCategorySchemas(null, true); |
這有兩個訪問一個類別模式的方法。一個獲得全部類別模式完整的 XML 描述,另一個是使用 Asset Manager Web 服務 API 的遞迴格式。為了檢索一個類別模式的全部 XML 內容,首先,獲取類別模式的 URL ,然後在模式 UI 上執行一個 HTTP GET。一個類別模式的樣例如圖 6 所示。
類別模式包含一個分類實體的層次結構,每個實體是一個特定的元素,有兩個屬性:@xmi:id 和 @name。@xmi:id 是惟一的,並能識別在類別模式中使用哪些分類實體來對資產清單中的資產進行分類。
檢索實體模式的另一種方法是通過遞迴呼叫 getSubCategories 方法來遍歷類別模式。當使用者從頂層檢視類別層次結構時,這種風格對他們來說更為直觀。
資產之間的關係在組織資產中也起著重要的作用。您可以通過資產清單檢索一個資產的已有關係。然而,當您想要向資產中新增一個新關係,或者在建立一個資產的同時新增和刪除一個新關係時,您需要列出 Asset Manager 伺服器中所有可用的關係型別。這些任務也可使用 Web 服務 API 來完成。清單 3 展示瞭如何列出 Asset Manager 中的所有關係型別。
清單 3. 在一個 Asset Manager 儲存庫中列出所有關係型別
RelationshipType[] types = ramWebService.getAllAssetRelationTypes(); for(int i=0;i |
刪除一個關係型別時要特別注意:刪除一個已有的關係型別可能會導致資產清單的 relatedAsset 缺失。
Asset Manager 有一個預設的資產生命週期定義。當資產被提交時,它可以進行稽核和批准為公眾使用,一箇舊版資產不再適用時,它可能被停止使用並存檔。預設資產生命週期如圖 7 所示。
Asset Manager 不允許自定義資產生命週期。然而,在真實開發環境,使用者有自己的生命週期定義,併為資產審查流程。該生命週期不能完全與 Asset Manager 的預設生命週期保持一致。為了填補這一空缺,應用一個外部驅動的生命週期機制。首先,您可以定義自己生命週期和轉換規則,然後將定製生命週期的狀態對映到 Asset Manager 中的預設資產生命週期。最後,當資產的外部狀態達到一個預定義傳輸點時,您可以在 Asset Manager 中使用一個外部觸發器來傳輸一個資產狀態。
清單 4 說明如何用一個外部觸發器來管理一個資產生命週期。
清單 4. 列出 Asset Manager 儲存庫中的關係型別
// Get the asset metadata object AssetSO asset = ramWebService.getAsset(assetID, assetVersion, true, true, true, true, true, true, true, true, true, "zh_CN"); String currentState = asset.getState().getName(); String newState = "Approved"; if (someConditionSatisfied == true) { String[] message = ramWebService.changeAssetState(assetID, assetVersion, newState, true); if (message == null) { System.out.println("State Change Success"); } else { System.out.println("State Change Failed"); } } |
基於資產的研發是開發一個面向服務架構(SOA)解決方案的最佳選擇。本文提議一個解決方案,可以通過整合 Asset Manager 使異構應用程式輕鬆地加入 ABD 流程。ABD 加速和促進模組和元件在業務和 IT 領域的重用。
原文連結:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0905_cfengli/0905_cfengli.html
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/14789789/viewspace-674309/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料庫內部儲存結構探索資料庫
- 塗抹ORACLE--第16章--資料庫物理儲存結構(1)Oracle資料庫
- #第9篇分享:python資料儲存-MySQL資料庫PythonMySql資料庫
- 第9章 資料儲存
- Salesforce的多型儲存和SAPC4C的後設資料儲存倉庫Salesforce多型
- 資料庫設計:儲存過程資料庫儲存過程
- MongoDB後設資料的儲存介紹MongoDB
- Salesforce的多型儲存和SAP C4C的後設資料儲存倉庫Salesforce多型
- 資料庫表設計之儲存引擎資料庫儲存引擎
- 列式儲存資料庫資料庫
- 資料儲存(1):從資料儲存看人類文明-資料儲存器發展歷程
- 現在後端都在用什麼資料庫儲存資料?後端資料庫
- Flutter持久化儲存之資料庫儲存Flutter持久化資料庫
- 【資料庫】資料庫儲存過程(一)資料庫儲存過程
- 資料庫設計:儲存過程主體資料庫儲存過程
- MySQL 資料庫儲存引擎MySql資料庫儲存引擎
- 資料庫儲存過程資料庫儲存過程
- 資料儲存--面向列的儲存設計
- Cassandra的內部資料儲存結構
- IOS資料儲存之Sqlite資料庫iOSSQLite資料庫
- IOS資料儲存之FMDB資料庫iOS資料庫
- 【儲存資料恢復】IBM儲存檔案NTFS系統損壞的資料恢復案例資料恢復IBM
- 報表資料分庫儲存
- MySql資料庫——儲存過程MySql資料庫儲存過程
- MySQL資料庫操作、儲存引擎MySql資料庫儲存引擎
- gitlab資料庫儲存位置Gitlab資料庫
- 使用Room持久庫儲存資料OOM
- 管理資料庫儲存結構資料庫
- 儲存與資料庫系統資料庫
- 明解資料庫------資料庫儲存演變史資料庫
- 【資料庫】資料庫儲存元素型別基礎資料庫型別
- 塗抹ORACLE--第16章--資料庫物理儲存結構(4)Oracle資料庫
- 塗抹ORACLE--第16章--資料庫物理儲存結構(2)Oracle資料庫
- 【故障公告】1個儲存過程拖垮整個資料庫儲存過程資料庫
- PostgreSQL 資料庫學習 - 1.資料庫體系結構之儲存結構SQL資料庫
- MySQL 更改資料庫資料儲存目錄MySql資料庫
- 【Android】資料儲存(三) 資料庫(SQLite)Android資料庫SQLite
- 重新學習Mysql資料庫3:Mysql儲存引擎與資料儲存原理MySql資料庫儲存引擎