基于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 实现的集成场景以下图所示：

更多请关注微信公众号