在上一篇文章《互操作消息统一管理系列：Message Bank》中，我们了解到在Message Bank中，消息均以半结构化（XML）或非结构化（Stream）的形式保存，因此无法与客户端的结构化消息一样，直接支持基于索引的检索。为此，需要在Message Bank中定义Search Table以支持查询。关于Search Table的定义和作用，请查阅https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI.Page.cls?KEY=EEDI_search_tables。

一. 在Message Bank中查询消息的特殊之处

大家如果使用过消息查看器，则能够了解IRIS自动持久化消息并提供界面让大家能够根据消息头中（如发生事件、来源、目标等）或消息体中（如患者姓名、诊断名称等消息的具体属性）来查询消息。 而在Message Bank上进行查询时，如果直接使用消息查看器，能够查询的是Message Bank的Production中传输的消息，而若不是在源系统中出现的消息，这一点一定不要混淆。 Message Bank提供了消息仓库查看器供大家查询源系统中的消息

一. 企业信息库简介

企业信息库（MessageBank）是一个可选的远程归档设施，可以从多个来自不同实例的互操作性Production中收集信息、事件日志项目和搜索表项。如下图所示：

这套环境由两种角色的实例构成： 企业信息库服务器，它本身也是一个Production，完全由Message Bank服务组成，接收来自任何数量的客户Production提交的消息、日志等。

客户端Operation（Message Bank Operation），将其添加到一个正在运行的Production中，并用企业信息库服务器的地址进行配置。如连接通畅，消息和日志即可自动转发到Message Bank并在其中存储。

为了使你能方便地看到信息库中的信息，InterSystems IRIS®提供了以下附加选项。

对于企业信息库实例，管理门户自动包括企业监控器页面，在那里你可以监控客户端Production的状态，浏览消息库，并对被监控客户的消息进行检索。

对于每个客户端实例，你在消息库实例中配置一个到企业监控器的链接。

如下所示：

二. 常见应用场景

消息归档

2020 年席卷全球的新冠疫情使每个人都在关注与 COVID-19 有关的新闻和数字。

为什么不趁这个机会去创造一些简单直观的东西，来帮助关注全球的疫苗接种数量呢？

为了应对这一挑战，我使用了 Our World in Data 提供的数据，他们的使命是提供解决全球最大问题所需的研究和数据。

他们在 Github 上有一个专门的 COVID-19 数据仓库，我采用了疫苗接种数据来完善我的跟踪器。

如果你不了解他们，去调查一下吧，这值得你花上一些时间。 Github 仓库

应用程序 iris-vaccine-tracker 有三个不同页面。

1. 主仪表板
2. 数据表，其中包含仪表板中呈现的数据的详细信息。
3. 热图

仪表板

主仪表板提供全球疫苗接种情况的快速概览。

第一个小组件提供以下信息：

• 用于接种人群的疫苗数量
• 提供疫苗接种信息的国家/地区数量
• 迄今已接种的疫苗总数。

第二个小组件提供了一个疫苗接种时间线视图，其中包括疫苗接种数量最多的前 10 个国家/地区。

第三个小组件提供了排名靠前的国家/地区的条形图，显示迄今为止的疫苗接种总数。

最后一个小组件展示疫苗的分布情况，哪些疫苗正在被使用以及所占的百分比。

数据表

数据表显示主仪表板汇总数据的详细信息。

热图

IRIS 中支持的四种方式：

SQL、Objects、REST 和 GraphQL  

卡济米尔·马列维奇，《运动员》(1932) 

>

> “你当然无法理解！ 习惯了坐马车旅行的人怎么可能理解乘坐火车或者飞机旅行的人的感受和印象？”
>

> >

> 卡济米尔·马列维奇 (1916)
>

## 引言

我们已经讨论过为什么在主题领域建模使用对象类型优于使用 SQL。 当时得出的结论和总结的事实如今依然适用。 那么，我们为什么要退后到对象和类型之前的时代，讨论将对象的操作拖回到使用global的技术？ 我们又为什么要鼓励面条式代码？难道是为了用它难以跟踪的错误考验开发者的技能熟练度？ 

目前有几种观点支持通过基于 SQL/REST/GraphQL 的 API 传输数据，而不是将其表示为类型/对象：

• 这些技术经过深入研究，相当易于部署。
• 知名度非常高，已在便捷的开源软件中广泛实现。
• 您通常别无选择，只能使用这些技术，尤其是在网络和数据库中。
• 最重要的是，API 仍然使用对象，因为它们提供了在代码中实现 API 的最适途径。

在讨论实现 API 之前，我们先来看一下底层的抽象层。 下图显示了数据在永久存储位置与处理并向应用程序用户呈现的位置之间的移动方式。

InterSystems API Manager (IAM) 版本1.5已正式发布。

IAM容器，包括从原有IAM版本升级的所有相关工件, 现在可以在 WRC 软件发布网址 组件区下载。

该版本的小版本号是 IAM 1.5.0.9-4。

InterSystems API Manager 1.5 使管理API通讯、与你的环境集成、加载API用户更加容易。它包含很多新特性，包括:

• 改进的用户体验
• 新的开发者门户工具
• 对Kafka connectivity的支持

这个版本基于Kong Enterprise version 1.5.0.9。之前的IAM版本包括一个贴牌版本的Kong Enterprise, 在本版本中的Kong Enterprise不再贴牌。 这个变化让我们可以更快的节奏带给您新的版本，并更有效地利用Kong提供的文档和其它资源。

请在 这里 查看IAM 1.5 的文档。这个文档仅说明IAM特殊的元素。产品中的文档链接直接打开Kong Enterprise的文档。

从IAM 0.34-1 升级需要通过3个中间版本累积升级，在 文档中有详细的说明。

大家可能已经听说过，我们近期推出了InterSystems API管理器 (以下简称IAM)。InterSystems IRIS数据平台™新增了一项功能，支持用户监视、控制和管理IT基础架构中基于Web的API间通信。

在本文中，我将向大家展示如何设置IAM，并重点介绍IAM中可用的一些功能。InterSystems API管理器可提供你所需的一切功能。

我们不必等待SAM发布才开始规划和试用该API来监控IRIS实例。在以后的文章中，我将更深入地探讨可用的指标及其意义，并提供一些交互式仪表板的示例。首先，我将介绍一下相关背景和一些问题及答案。

IRIS（和Caché）一直在收集自身及其运行平台的数十个指标。收集这些指标来监控Caché和IRIS的方法向来有很多。我发现，很少有安装软件使用IRIS和Caché的内置解决方案。譬如，History Monitor作为性能和系统使用指标的历史数据库，已经推出很长时间了，但它没有简便方法可实时显示这些指标和仪表系统。

IRIS平台解决方案（以及整个业界）正在从仅在一些本地实例上运行的单体式应用程序过渡到“随处”部署的分布式解决方案。在许多用例中，原有的IRIS监控方案并不适用于这些新的模式。InterSystems没有做重复工作，而是将目光投向当前流行的、经过验证的监控和告警开源解决方案。

在最近的项目里，多方同时连接同一个数据库并执行增删改查等各项数据操作。研发人员不时发现一些数据在不合规的情况下被新增甚至删除。因此，在实际工作中会有监控数据操作以便识别和处理异常操作的需求。本文将以监控和识别删除操作为例，介绍如何通过IRIS的审计功能实现对数据操作的监控和查询。

注意事项

在应用审计功能之前，必须注意的是：

在这个由三个部分组成的系列文章中，介绍了如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。 

第一部分介绍了一些OAuth 2.0背景知识，以及IRIS和IAM的一些初始定义和配置，以帮助读者理解确保服务安全的整个过程。 

第二部分详细讨论和演示了配置IAM所需的步骤——验证传入请求中的访问令牌，并在验证成功时将请求转发到后端。 

本系列的最后一部分将讨论和演示IAM生成访问令牌（充当授权服务器）并对其进行验证时所需的配置，以及一些重要的最终考虑事项。 

如果您想试用IAM，请联系InterSystems销售代表。 

场景2：IAM作为授权服务器和访问令牌验证器  

与上个场景不同的是，该场景中将使用一个名为“OAuth 2.0 Authentication”的插件。 

如果要在资源所有者密码凭证流中将IAM作为授权服务器使用，客户端应用程序必须对用户名和密码进行身份验证。只有在身份验证成功时，才能发出获取IAM访问令牌的请求。 

首先，将其添加到“SampleIRISService”中。正如下面截屏所示，需要填充一些不同的字段来配置此插件。 

首先，将“SampleIRISService”的ID粘贴到“service_id”字段中，这样就可以在服务中启用该插件。 

在这个由三部分组成的系列文章中，我们将展示如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。 

在第一部分中，我们介绍了一些OAuth 2.0背景知识，以及IRIS和IAM的初始定义和配置，以帮助读者理解确保服务安全的整个过程。 

现在，本文将详细讨论和演示配置IAM所需的步骤——验证传入请求中的访问令牌，并在验证成功时将请求转发到后端。 

本系列的最后一部分将讨论和演示IAM生成访问令牌（充当授权服务器）并对其进行验证时所需的配置，以及一些重要的最终考虑事项。 

如果您想试用IAM，请联系InterSystems销售代表。

场景1：IAM作为访问令牌验证器  

在该场景中，需要使用一个外部授权服务器生成JWT（JSON Web Token）格式的访问令牌。该JWT使用了RS256算法和私钥签名。为了验证JWT签名，另一方（本例中是IAM）需要拥有授权服务器提供的公钥。 

由外部授权服务器生成的JWT主体中还包括一个名为“exp”的声明（包含该令牌过期的时间戳），以及另一个名为“iss”的声明（包含授权服务器的地址）。 

因此，IAM需要先使用授权服务器的公钥和JWT内部“exp”声明中包含的过期时间戳对JWT签名进行验证，然后再将请求转发给IRIS。 

介绍 

目前，诸多应用程序通过开放授权框架（OAuth）来安全、可靠、高效地访问各种服务中的资源。InterSystems IRIS目前已兼容OAuth 2.0框架。事实上社区有一篇关于OAuth 2.0和InterSystems IRIS的精彩文章，链接如下。 

然而，随着API管理工具的出现，一些组织开始将其用作单点身份验证，从而防止未经授权的请求到达下游服务，并将授权/身份验证复杂性从服务本身分离出来。 

您可能知道，InterSystems已经推出了自己的API管理工具，即InterSystems API Management （IAM），以IRIS Enterprise license（IRIS Community版本不含此功能）的形式提供。这里是社区另一篇介绍InterSystems AIM的精华帖。 

这是三篇系列文章中的第一篇，该系列文章将展示如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。 

第一部分将介绍OAuth 2.0相关背景，以及IRIS和IAM的初始定义和配置，以帮助读者理解确保服务安全的整个过程。 

本系列文章的后续部分还将介绍两种使用IAM保护服务的可能的场景。在第一种场景中，IAM只验证传入请求中的访问令牌，如果验证成功，则将请求转发到后端。在第二种场景中，IAM将生成一个访问令牌（充当授权服务器）并对其进行验证。 

在本文中，我想谈一谈规范优先的 REST API 开发方式。

传统的代码优先 REST API 开发是这样的：

• 编写代码
• 使其支持 REST
• 形成文档（成为 REST API）

规范优先遵循同样的步骤，不过是反过来的。 我们先制定规范（同时兼做文档），然后根据它生成一个样板 REST 应用，最后编写一些业务逻辑。

这是有好处的，因为：

• 对于想要使用你的 REST API 的外部或前端开发者，你总是有相关且有用的文档
• 使用 OAS (Swagger) 创建的规范可以导入各种工具，从而进行编辑、客户端生成、API 管理、单元测试和自动化，或者许多其他任务的简化
• 改进了 API 架构。 在代码优先的方式中，API 是逐个方法开发的，因此开发者很容易失去对整体 API 架构的跟踪，但在规范优先的方式中，开发者被强制从 API 使用者的角度与 API 进行交互，这通常有助于设计出更简洁的 API 架构
• 更快的开发速度 - 由于所有样板代码都是自动生成的，你无需编写代码，只需开发业务逻辑。
• 更快的反馈循环 - 使用者可以立即查看 API，并且只需修改规范即可轻松提供建议 让我们以规范优先的方式开发 API 吧！

最近，我需要从持久类和序列类生成一个 Swagger 规范，所以我发布了我的代码（它并不完整 - 你仍然需要处理应用程序的细节，但这是一个开始）。 代码在这里。

假设你有下面的类：