基於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 實現的集成場景以下圖所示：

更多請關注微信公衆號