基於OSLC的系統集成

1. 引言

相信大家凡是查看到這篇博文，大多的可能是從事系統集成工作，又或者是從事軟件工程相關的咨詢工作，想要了解OSLC的基本概念以及原理。作者將以一系列的博文對OSLC的方方面面進行介紹。

2. 相關背景

2.1 信息孤島與跨生命周期協作的沖突

我們說, OSLC解決的是系統集成問題，那么，我們需要先從系統集成的源頭說起。

企業信息化的過程向來不是“一蹴而就”，而是通過迭代、漸進的方式展開。基於企業研發業務的需要，各個生命周期階段的信息化逐步提上日程。然而，產品的生命周期跨越多個工程領域，典型的如需求管理、配置管理、質量管理、變更管理等等。要實現“一鍵式”的快速自動化是一個復雜的、漫長的過程。因此，企業信息化的過程往往是從某一個或幾個工程領域展開，然后通過迭代的方式逐步完善。

信息化的落地實施離不開軟件工具的支撐，因此，在信息化過程中，企業一般會基於業務和成本等綜合因素，采購並實施一系列的商業化或開源軟件工具。工具的研發往往是領域業務驅動，用於解決特定領域存在的問題。因此，多領域工具間往往天然的存在隔離關系。即使有一些大的工具廠商會開發某些大的平台產品，以實現基於同一平台的多領域工具間的有效協同，這種背景下的工具平台在功能層面往往也是多方面受限的。首先是成本問題。傳統的工具開發商往往是在特定的一個或多個領域比較強勢，例如達索在三維模型，IBM在配置管理、需求管理等等。而平台化戰略可能不僅僅局限於開發商擅長的領域，這同具體的平台戰略規划和市場業務驅動相關。因此，開發商不得不投入大量的人力用於平台工具研發。這本身帶來一定的成本以及風險。其次是產品發布周期。不同的工程領域往往都有着占據較大市場份額或認可度的公司，競爭關系異常激烈。如何快速的將工具推向市場是開發商是否能取得成功的決定性因素之一。

如下圖所示，眾多的軟件工具存在如下特性：

1. 不同工具廠商：

   一般企業采購工具會出現廠商來源多元化特點，工具大多來自多個公司。同時，任何一個商業公司也不可能做到 “面面俱到”，研發所有的領域工具並做到獨占市場。

2. 異構數據庫

   不同工具可能依賴於不同的數據庫，有的可能是免費版的MySQL，有的可能是商業化的Oracle、SqlServer等，有的可能是自己實現的特定的數據庫。

3. 工具類型

   有些工具可能是商業化的，有些可能是開源的，有些可能是企業內部自研的。

4. 異構平台

   有的是基於Windows平台，有些事基於Linux。有些事基於C/S模式，有些工具可能是基於B/S模式。

5. 不同的UI和風格

   不同廠商的工具用戶界面各異，操作風格也顯著不同。

6. 其他......

總之，企業信息化過程中大多會存在這樣的問題：信息孤島。每個領域工具在各自領域內發揮了巨大作用，但領域工具間的數據和工作流彼此割裂，無法在軟件的全生命周期內實現數據共享和一致的工作流。由此導致了企業內部信息孤島的形成。

隨着企業的成熟度越高，提升研發管理能力也必然會成為管理者着重考慮的問題。而橫亘在各個獨立領域的信息孤島則成了進一步提升研發能力的障礙。

2.2 傳統的系統集成方式及弊端

解決信息孤島的方式有很多，最為符合實際也最為常用的方式是“P2P”集成。“點到點”工具的集成通過已有工具對外提供的API，通過擴展開發的形式實現工具間的數據交互。點對點的集成具有直接、靈活的特點。

該種方式雖然受限於工具對外提供的API支撐能力，但其可以基於業務需要，在API功能允許的情況下，便捷的實現兩款工具間的集成，實現數據的交互，而不必考慮更多的例如通用性、復用性的細節。但，點對點集成的缺點是明顯的。

　　數據復制而非鏈接：典型的情況下，點對點集成的數據利用方式是復制，由此極易導致數據冗余和不一致。

　　開發成本高：開發人員需要了解集成兩端的工具的集成機制，包括平台、語言、API，集成前期的預研和學習成本較高。

　　維護成本高：如果發生工具替換或者版本升級，則API的變化或不穩定必然影響對已有集成工作的返工，極大的提高維護成本。

　　擴展性不好：如果引入新的工具，則集成點會議N方級別增長，由此導致繁重的成本。

　　可復用性差：點對點集成依賴於特定工具的特定API，和工具緊密耦合，很難實現高效率的復用。

3. OSLC應運而生

3.1 什么是OSLC

　　OSLC，全稱 “Open Services for Lifecycle Collaboration”，是由IBM提出的一套技術規范，該規范主要用於解決生命周期工具的集成問題。OSLC規范由核心規范和領域規范組成。核心規范用於對核心的集成技術及通用概念進行描述。領域規范則是對具體的工程領域展開。

所謂領域，就是我們所熟悉的例如需求管理、配置管理、質量管理、資產管理、變更管理等傳統軟件工程領域。OSLC規范的制定由OSLC社區的工作組完成，根據制定規范所屬領域不同，工作組又可以分為核心工作組和領域工作組。顧名思義，核心工作組專注於核 心規范的制定。領域工作組則專注於不同的工程領域的OSLC規范制定。

3.2 OSLC技術規范剖析

3.2.1 OSLC的核心思想-Linked Data

OSLC核心思想是"鏈接數據"，即“Linked Data” ，其規則如下(來自 http://www.w3.org/DesignIssues/LinkedData.html)：

1. 使用URI作為事物的名字標識
2. 使用HTTP URI 以便用戶能夠查詢這些名字
3. 當用戶查詢某個URI時，使用標准格式（RDF*, SPARQL）提供有用信息。
4. 包含到其他URI的鏈接，以便用戶能發現更多信息。

“Linked Data”規則可概述為：

事物都通過HTTP URI進行標識，用戶通過請求能夠獲取通過標准形式表述的有用信息，並且允許事物間的鏈接，使得用戶能夠發現更多的信息。

OSLC正是基於這一基礎思想，將軟件研發生命周期的工件進行資源化，例如一條需求、一個測試用例、一個開發計划等都是HTTP URI標識的資源。用戶通過HTTP協議對這些資源進行訪問。OSLC中對資源的表述強制要求具備RDF的提供能力，同時也可以支持例如JSON/HTML等其他資源格式。

OSLC核心規范定義了一些簡單的HTTP和RDF的使用模式以及最小級化的資源類型，用於確保工具的集成。OSLC的領域規范基於OSLC核心規范的核心技術，定義了面向特定領域的資源形式。

OSLC中的集成技術

OSLC的存在是為了解決生命周期工具集成問題，那么它是如何從規范的層面實現的呢？

OSLC提供了兩種主要的集成技術:基於HTTP CRUD(Linking data via HTTP)和基於HTML UI(“Linking Data via HTML User Interface”)

1. 基於HTTP協議的CRUD.
   OSLC通過標准的資源表述以及HTTP協議實現對資源的C.R.U.D操作。
   

2. 基於HTML界面的集成

除了在基礎數據操作的層面提供支持，OSLC還提供了嶄新的集成方式，即“UI的無縫集成”。OSLC規定的UI集成方式包括“UI Preview” 和 “Delegated UI”。“UI Preview” 主要用於信息的預覽。“Delegated UI” 主要用於工件的選擇和創建。

3.3 OSLC核心規范詳解

3.3.1 服務發現

服務發現是OSLC重要特性之一，也是不太容易理解的地方。OSLC技術規范中的服務接口不是以“固定API”的形式標識，而是通過服務發現的方式由客戶端進行層層解析得出。對於客戶端而言，只需要知道基礎服務的入口地址，即可根據OLSC協議，逐步發現所需要的服務。

3.3.2 標准化資源表述

例如，請求資源: http://example.com/blogs/entry/1， 返回如下RDF/XML數據。

<rdf:RDF    
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dcterms="http://purl.org/dc/terms/"    
   xmlns:foaf="http://xmlns.com/foaf/0.1/"    
   xmlns:oslc_blog="http://open-services.net/ns/bogus/blogs#">

   <oslc_blog:Entry
      rdf:about="http://example.com/blogs/entry/1">

      <dcterms:title>I love trash</dcterms:title>
      <dcterms:modified>2002-10-10T12:00:00-05:00</dcterms:modified>
      <dcterms:content>
         Anything dirty or dingy or dusty. 
         Anything ragged or rotten or rusty.
      </dcterms:content>
      <dcterms:creator>
         <foaf:Person>
             <foaf:name>Oscar T. Grouch</foaf:name>
         </foaf:Person>
      </dcterms:creator>

   </oslc_blog:Entry>

</rdf:RDF>

3.3.3 基於HTTP協議的C.R.U.D

OSLC規范定義的服務是基於Rest風格。Rest風格的架構的特點是資源化。領域數據的資源要進行統一的資源化表述，對外暴露的接口也是資源化的URL。同時，Rest架構直接利用了HTTP協議的語義用於對資源的存儲操作。

3.3.4 資源查詢

OSLC規范針對復雜查詢定義了查詢機制，使得客戶端可以靈活對遠程資源進行查詢。例如：

http://example.com/bugs?oslc.where=cm:severity="high" and dcterms:created >"2010-04-01"

3.3.5 Delegated UI Dialog

基於Delegated UI Dialog典型的集成場景：
場景A: 用戶希望在工具A中選擇並鏈接工具B中的資源。

場景B: 用戶希望在工具A中無縫的創建工具B中的資源。

3.3.6 UI Preview

UI Preview 主要是用於解決跨工具的數據預覽問題。假設存在需求管理工具A和測試管理工具B，兩款工具間存在一條從測試用例到需求的鏈接關系。如下圖：

那么，用戶期望從測試管理工具中查看用例所關聯的需求的信息。如何才能實現：用戶在測試管理工具中能夠直接獲得與之關聯的需求信息，而不需要進入到需求管理系統中查看呢？？？基於這種場景，我們稱之為 "數據預覽"。而OSLC中的UI Preview正是滿足了這一場景。基於 UI Preview 實現的集成場景如下圖所示：

更多請關注微信公眾號