【OSLC】OSLC Overview

原创最新推荐文章于 2026-09-07 16:51:49 发布 4.1k 阅读 AI写同款

258粉丝38篇原创

关注

Log4j JSON ezmoph：结构化日志在IBM Jazz与OSLC中的应用本文还有配套的精品资源，点击获取简介：Log4j是一个Java日志框架，提供灵活的日志配置与处理。本课程探讨了在IBM Jazz和OSLC（开放服务生命周期协作）项目中，Log4j如何与JSON数据格式及ezmoph库结合使用，以实现结构化日志记录。通过Log4j的配置，日志信息能以JSON格式输出，利用JSON的易读性和结构化特性，便于后续的数据分析。ezmorph库则... 阅读详情

AI摘要

本文介绍了OSLC（Open Services for Lifecycle Collaboration）的概念与原理，探讨了系统集成中的信息孤岛问题及传统集成方式的局限性，并详细阐述了OSLC如何通过Linked Data等技术手段解决这些问题。

1. 引言

相信大家凡是查看到这篇博文，大多的可能是从事系统集成工作，又或者是从事软件工程相关的咨询工作，想要了解OSLC的基本概念以及原理。作者将以一系列的博文对OSLC的方方面面进行介绍。

2. 相关背景

2.1 信息孤岛与跨生命周期协作的冲突

我们说, OSLC解决的是系统集成问题，那么，我们需要先从系统集成的源头说起。

企业信息化的过程向来不是“一蹴而就”，而是通过迭代、渐进的方式展开。基于企业研发业务的需要，各个生命周期阶段的信息化逐步提上日程。然而，产品的生命周期跨越多个工程领域，典型的如需求管理、配置管理、质量管理、变更管理等等。要实现“一键式”的快速自动化是一个复杂的、漫长的过程。因此，企业信息化的过程往往是从某一个或几个工程领域展开，然后通过迭代的方式逐步完善。

信息化的落地实施离不开软件工具的支撑，因此，在信息化过程中，企业一般会基于业务和成本等综合因素，采购并实施一系列的商业化或开源软件工具。工具的研发往往是领域业务驱动，用于解决特定领域存在的问题。因此，多领域工具间往往天然的存在隔离关系。即使有一些大的工具厂商会开发某些大的平台产品，以实现基于同一平台的多领域工具间的有效协同，这种背景下的工具平台在功能层面往往也是多方面受限的。首先是成本问题。传统的工具开发商往往是在特定的一个或多个领域比较强势，例如达索在三维模型，IBM在配置管理、需求管理等等。而平台化战略可能不仅仅局限于开发商擅长的领域，这同具体的平台战略规划和市场业务驱动相关。因此，开发商不得不投入大量的人力用于平台工具研发。这本身带来一定的成本以及风险。其次是产品发布周期。不同的工程领域往往都有着占据较大市场份额或认可度的公司，竞争关系异常激烈。如何快速的将工具推向市场是开发商是否能取得成功的决定性因素之一。

如下图所示，众多的软件工具存在如下特性：
信息孤岛

不同工具厂商：

一般企业采购工具会出现厂商来源多元化特点，工具大多来自多个公司。同时，任何一个商业公司也不可能做到 “面面俱到”，研发所有的领域工具并做到独占市场。
异构数据库

不同工具可能依赖于不同的数据库，有的可能是免费版的MySQL，有的可能是商业化的Oracle、SqlServer等，有的可能是自己实现的特定的数据库。
工具类型

有些工具可能是商业化的，有些可能是开源的，有些可能是企业内部自研的。
异构平台

有的是基于Windows平台，有些事基于Linux。有些事基于C/S模式，有些工具可能是基于B/S模式。
不同的UI和风格

不同厂商的工具用户界面各异，操作风格也显著不同。
其他……

总之，企业信息化过程中大多会存在这样的问题：信息孤岛。每个领域工具在各自领域内发挥了巨大作用，但领域工具间的数据和工作流彼此割裂，无法在软件的全生命周期内实现数据共享和一致的工作流。由此导致了企业内部信息孤岛的形成。

随着企业的成熟度越高，提升研发管理能力也必然会成为管理者着重考虑的问题。而横亘在各个独立领域的信息孤岛则成了进一步提升研发能力的障碍。

2.2 传统的系统集成方式及弊端

解决信息孤岛的方式有很多，最为符合实际也最为常用的方式是“P2P”集成。“点到点”工具的集成通过已有工具对外提供的API，通过扩展开发的形式实现工具间的数据交互。点对点的集成具有直接、灵活的特点。

P2P集成

该种方式虽然受限于工具对外提供的API支撑能力，但其可以基于业务需要，在API功能允许的情况下，便捷的实现两款工具间的集成，实现数据的交互，而不必考虑更多的例如通用性、复用性的细节。但，点对点集成的缺点是明显的。

　　数据复制而非链接：典型的情况下，点对点集成的数据利用方式是复制，由此极易导致数据冗余和不一致。

　　开发成本高：开发人员需要了解集成两端的工具的集成机制，包括平台、语言、API，集成前期的预研和学习成本较高。

　　维护成本高：如果发生工具替换或者版本升级，则API的变化或不稳定必然影响对已有集成工作的返工，极大的提高维护成本。

　　扩展性不好：如果引入新的工具，则集成点会议N方级别增长，由此导致繁重的成本。

　　可复用性差：点对点集成依赖于特定工具的特定API，和工具紧密耦合，很难实现高效率的复用。

3. OSLC应运而生

3.1 什么是OSLC

　　OSLC，全称 “Open Services for Lifecycle Collaboration”，是由IBM提出的一套技术规范，该规范主要用于解决生命周期工具的集成问题。OSLC规范由核心规范和领域规范组成。核心规范用于对核心的集成技术及通用概念进行描述。领域规范则是对具体的工程领域展开。

所谓领域，就是我们所熟悉的例如需求管理、配置管理、质量管理、资产管理、变更管理等传统软件工程领域。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”)

基于HTTP协议的CRUD.
OSLC通过标准的资源表述以及HTTP协议实现对资源的C.R.U.D操作。
基于HTML界面的集成

除了在基础数据操作的层面提供支持，OSLC还提供了崭新的集成方式，即“UI的无缝集成”。OSLC规定的UI集成方式包括“UI Preview” 和 “Delegated UI”。“UI Preview” 主要用于信息的预览。“Delegated UI” 主要用于工件的选择和创建。

3.3 OSLC核心规范详解

3.3.1 服务发现

服务发现是OSLC重要特性之一，也是不太容易理解的地方。OSLC技术规范中的服务接口不是以“固定API”的形式标识，而是通过服务发现的方式由客户端进行层层解析得出。对于客户端而言，只需要知道基础服务的入口地址，即可根据OLSC协议，逐步发现所需要的服务。
OSLC Discovery.

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协议的语义用于对资源的存储操作。

OSLC Discovery.

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中的资源。

UI-SELECT

场景B: 用户希望在工具A中无缝的创建工具B中的资源。

UI-CREATE

3.3.6 UI Preview

UI Preview 主要是用于解决跨工具的数据预览问题。假设存在需求管理工具A和测试管理工具B，两款工具间存在一条从测试用例到需求的链接关系。如下图：

那么，用户期望从测试管理工具中查看用例所关联的需求的信息。如何才能实现：用户在测试管理工具中能够直接获得与之关联的需求信息，而不需要进入到需求管理系统中查看呢？？？基于这种场景，我们称之为 “数据预览”。而OSLC中的UI Preview正是满足了这一场景。基于 UI Preview 实现的集成场景如下图所示：
SystemEngineeringLab