跳转到主要内容
Cloud Information Model 一个开放且与应用无关的数据模型,用于连接企业云端及本地应用程序。

本站部分链接为联盟营销链接:如果您通过这些链接购买,我们可能会获得佣金,且不会增加您的成本。这绝不会影响我们的推荐建议。详情请参阅我们的联盟披露声明。 联盟营销披露.

资源

页面是任何想要了解、采用或贡献云信息模型 (CIM) 的人的入口点。 CIM 是一个开源的、与应用程序无关的数据模型,由 Linux 基金会管理,它定义了业务实体的共享词汇表,以便云和本地系统可以交换数据,而无需每个集成团队重新发明自己的架构。此页面收集了评估 CIM 所需的工件、它支持的格式、模型所在的存储库以及参与渠道。如果您正在针对替代方案评估 CIM,我们的应用程序无关数据模型 指南是一个很好的起点。

要点

  • CIM 是一个共享的、供应商中立的数据模型,而不是产品或数据库——它描述了多个应用程序可以映射到的实体、属性和关系。
  • 主要技术资产位于 CIM GitHub 组织中,其中模型定义和工具已进行版本控制并公开许可。
  • CIM 以多种标准格式表示,因此可以由不同的工具链使用,而不是将您锁定在一种序列化中。
  • 演示文稿、常见问题解答和新闻页面是在深入技术研究之前构建业务案例和回答利益相关者问题的最快方式。
  • 通过 GitHub 存储库和贡献者 Web 表单进行贡献;该模型是通过社区审查而不是单个供应商的路线图来发展的。

云信息模型实际上是什么

CIM 最好被理解为“规范模型”:业务概念(客户、帐户、订单、产品、联系人以及它们之间的关系)的中立、商定的表示,位于您已运行的系统之间。您不必强制每个应用程序都使用其他应用程序的方言,而是将每个系统映射到 CIM 一次,然后 CIM 就成为交换点。

这与企业集成中反复出现的架构模式相同:中心辐射型规范模式,而不是点对点映射的网格。从概念上讲,它与用于文档的 OASIS 通用业务语言 (UBL)、用于业务消息的开放应用程序组集成规范 (OAGIS) 以及用于网络规模词汇的 schema.org 等工作相关。 CIM 的独特之处在于它与应用程序无关,并且是为大多数企业实际运营的云加本地现实而设计的。

实际的回报是减少了映射蔓延。如果您有 n 个系统,并且每个系统都必须相互通信,那么您将面临数量级为 n² 的映射。引入规范模型,工作量就会减少到n个映射——每个系统一个到共享模型。这种减少是采用 CIM 的核心经济理由。

CIM 演示

CIM 演示文稿是推荐给内部构建案例的任何人的起始工件。它旨在向混合受众(架构师、数据治理主管和业务发起人)展示,并涵盖共享模型的动机、CIM 定义的范围以及它如何适应现有的集成环境。

使用方法如下:

Related: — The fully pipeline that just keeps running.

  • 对于高管和赞助商: 以地图蔓延问题和供应商中立性论点为主导。该演示文稿将 CIM 视为降低风险,而不是推倒重来。
  • 对于架构师和工程师: 使用它来设置上下文,然后立即移至 GitHub 存储库以获取实际的模型定义。
  • 对于治理和合规性利益相关者: 使用它来开启有关所有权、版本控制以及如何审查模型更改的对话。

演示文稿是对话的开始,而不是规范。将其视为入口,并将存储库视为事实的来源。

CIM 格式

CIM 有意支持多种标准和格式,而不是单一的专有序列化。这很重要,因为企业工具链是异构的:您的建模工具、ETL 平台、API 网关和文档生成器可能各自喜欢不同的表示形式。

该领域常见的相关格式系列包括:

Our pick: — that business teams can actually build on.

  • 实体关系和概念符号,用于人工审查和设计研讨会。
  • 基于 JSON 的架构表示,用于 API 和应用程序使用。
  • RDF 和本体风格表示,用于语义和知识图谱用例。
  • 用于数据仓库和 ETL 管道的关系和表格映射。

设计原则是可移植性:以开放格式表达的模型可以通过标准工具进行转换、比较、版本控制和验证。当您为您的组织评估 CIM 时,要问的问题不是“它使用哪种格式?”但是“我可以通过我的工具所需的格式来回传输我的模型而不会造成损失吗?”如果格式转换默默地放弃关系基数或属性约束,那么这是值得尽早测试的真正集成风险。

如何决定采用哪种格式

将此作为快速决策指南:

如果您的主要消费者是……赞成这样的表述……留意……
应用程序/API 开发人员JSON 样式架构平面 JSON 中关系语义的丢失
数据仓库/ETL 团队关系或表格映射需要桥接表的多对多关系
知识图谱/语义团队RDF/本体表示工具成熟度和查询性能
设计和治理研讨会概念/ER 符号图表和机器可读模型之间的偏差

最后一行是最常见的失败模式:团队维护的漂亮图表不再与版本化模型匹配。保持从存储库工件生成的图表,或者至少与存储库工件进行协调。

CIM 新闻

“新闻中的 CIM”部分汇总了外部报道(公告、分析师评论和社区文章),因此您可以了解项目本身之外如何接收 CIM。这很有用,原因有两个。

首先,它提供第三方验证。当您建议采用共享模型时,引用独立报道比引用项目自己的营销更有说服力。其次,它展示了核心文档可能未涵盖的真实世界采用故事和集成模式。

批判性地阅读新闻报道。公告通常描述意图和合作伙伴关系,而不是部署的生产使用情况。区分“组织 X 加入了这项工作”和“组织 X 在生产中为系统 Y 运行 CIM”。前者较为常见;后者是对构建与采用决策至关重要的证据。

Related: — Push-down ELT built for cloud data warehouses.

CIM GitHub 组织

GitHub 组织是内容所在。对于技术读者来说,这是最重要的目的地。期望发现:

  • 模型定义 — 构成 CIM 的实体、属性、关系和约束。
  • 工具 — 用于从模型验证、转换和生成工件的脚本和实用程序。
  • 版本控制和历史记录 — 提交历史记录显示模型如何演变以及原因。
  • 问题和讨论 — 提案、问题和决定的工作记录。

一些实用的习惯使存储库变得更加有用:

  • 固定到版本或标签而不是跟踪默认分支,因此您的映射不会在项目中期转移。
  • 在采用您关心的实体之前阅读它们的提交历史记录。一年内变化 3 次的区域表明该区域不稳定。
  • 检查每个存储库上的许可证。开源项目有时会混合使用工具和模型内容的许可证。
  • 针对歧义提交 Issue。 如果关系的基数不清楚,这种含糊性将困扰每个下游团队;尽早提出它可以改善每个人的模型。

对于具有严格供应链或来源要求的组织,请以检查任何第三方依赖项的方式检查存储库:许可证、维护活动、贡献者多样性和发布节奏。依赖于单个维护者的模型与具有广泛组织支持的模型具有不同的风险状况。

If you are shopping: — for hybrid cloud-to-on-prem integration.

常见问题

云信息模型是我可以购买的产品吗?

不是。CIM 是一个开源数据模型——一组定义和支持工件——由 Linux 基金会管理。您可以通过将您的系统映射到它并使用已发布的模型定义来采用它;模型本身不收取许可费。供应商可以构建支持或嵌入 CIM 的产品,但该模型不是商业产品。

我是否必须更换现有系统才能使用 CIM?

不,这就是重点。 CIM 被设计为作为规范交换模型位于系统之间。您保留应用程序、数据库和仓库,并构建从每个系统到 CIM 的映射。这是渐进式的:您可以从单个高价值集成开始,并随着时间的推移扩大覆盖范围。

我应该使用哪种格式来使用 CIM?

这取决于你的消费者。 API 和应用程序团队通常喜欢 JSON 样式的模式表示;数据仓库和 ETL 团队喜欢关系或表格映射;语义和知识图谱团队青睐 RDF/本体表示。关键测试是无损往返——在提交之前验证格式之间的转换是否保留了关系和约束。

CIM 与 UBL 或 OAGIS 等其他标准有何关系?

它们占据相邻的问题空间。 UBL 和 OAGIS 重点关注各方之间交换的业务“文档”和“消息”,而 CIM 则强调应用程序映射到的共享“实体模型”。在实践中,它们可以是互补的:规范实体模型可以告知您如何填充文档标准。评估特定用例的重叠,而不是假设一个用例替代另一个用例。

我如何为 CIM 做出贡献?

贡献主要通过 CIM GitHub 组织(问题、拉取请求和讨论)以及从此站点链接的贡献者 Web 表单进行。由于该模型是由社区管理的,因此提案会被公开审查。从小事做起:澄清不明确的定义或添加具有明确理由的缺失属性,并在提出大型结构更改之前与维护人员接触。

非技术利益相关者应该从哪里开始?

从 CIM 演示文稿和常见问题解答开始,然后浏览“CIM 新闻”了解第三方背景。这些为您提供动力和词汇,而无需您阅读模型定义。一旦有了候选集成进行试点,就将技术团队引入,并让他们在 GitHub 存储库中工作。

参与和进一步阅读

采用共享模型既是一项技术工作,也是一项组织工作。最成功的 CIM 计划往往从单一的、边界明确的集成开始——其中两个系统目前需要脆弱的自定义映射——证明规范模型方法,然后进行扩展。治理很重要:尽早决定谁拥有您的内部 CIM 映射、如何处理模型版本升级以及如何解决业务定义之间的冲突。

有关管理和开放治理背景的背景信息,请参阅 Wikipedia 上的 Linux 基金会。对于相关标准工作,在比较规范模型方法时,OASIS 通用业务语言 和 schema.org 是有用的参考点。为了更深入地进行语义建模,万维网联盟 (W3C) 发布了支持本体风格表示的 RDF 和 OWL 规范。

使用此网站上的导航可以访问演示文稿、常见问题解答、格式文档、新闻综述和 GitHub 存储库,并在您准备好参与塑造模型时使用贡献者 Web 表单。

Frequently asked questions

云信息模型是我可以购买的产品吗?

不会。CIM 是一个开源数据模型——一组定义和支持工件——由 Linux 基金会管理。您可以通过将您的系统映射到它并使用已发布的模型定义来采用它;模型本身不收取许可费。供应商可以构建支持或嵌入 CIM 的产品,但该模型不是商业产品。

我是否必须更换现有系统才能使用 CIM?

不,这就是重点。 CIM 被设计为作为规范交换模型位于系统之间。您保留应用程序、数据库和仓库,并构建从每个系统到 CIM 的映射。这是渐进式的:您可以从单个高价值集成开始,并随着时间的推移扩大覆盖范围。

我应该使用哪种格式来使用 CIM?

这取决于你的消费者。 API 和应用程序团队通常喜欢 JSON 样式的模式表示;仓库和 ETL 团队喜欢关系或表格映射;语义和知识图团队青睐 RDF/本体表示。关键测试是无损往返——在提交之前验证格式之间的转换是否保留了关系和约束。

CIM 与 UBL 或 OAGIS 等其他标准有何关系?

它们占据相邻的问题空间。 UBL 和 OAGIS 重点关注各方之间交换的业务文档和消息,而 CIM 则强调应用程序映射到的共享实体模型。在实践中,它们可以是互补的:规范实体模型可以告知您如何填充文档标准。评估特定用例的重叠,而不是假设一个用例替代另一个用例。

我如何为 CIM 做出贡献?

贡献主要通过 CIM GitHub 组织(问题、拉取请求和讨论)以及从此站点链接的贡献者 Web 表单进行。由于该模型是由社区管理的,因此提案会被公开审查。从小事做起:澄清不明确的定义或添加具有明确理由的缺失属性,并在提出大型结构更改之前与维护人员接触。

非技术利益相关者应该从哪里开始?

从 CIM 演示文稿和常见问题解答开始,然后浏览“CIM 新闻”了解第三方背景。这些为您提供动力和词汇,而无需您阅读模型定义。一旦有了候选集成进行试点,就将技术团队引入,并让他们在 GitHub 存储库中工作。参与和进一步阅读 采用共享模型既是一项技术工作,也是一项组织工作。最成功的 CIM 计划往往从单一的、边界明确的集成开始——其中两个系统目前需要脆弱的自定义映射——专业


See how Boomi handles your hybrid integration map

Enterprise iPaaS for hybrid cloud-to-on-prem integration