Oracle 消息传递云服务简介

作者:Phil Wilkinsace-associate

2017 年 8 月

消息传递始终是系统间集成的一项长期任务。作为集成技术领域中的不起眼的一员,消息传递相继受到 SOAP/WSDL 和基于 REST 的 Web 服务的压制。这种情况是由多种因素造成的:

  • 消息传递并不使用通常已经开放的网络端口(即用于网络流量的网络端口),因此当流量需要跨越安全边界时,需要说服安全和网络人员开放相关端口。
  • 每个消息传递服务器都是不同的,因此需要部署相关供应商的 Java 库来确保 JMS API 标准的实现。
  • 不同 JMS 实现之间的桥接可能混乱不堪。
  • JMS 通常无法与 Web 客户端很好地协同。

所有这些因素导致了,与集成云服务、流程云服务和其他 Oracle PaaS 产品相比,Oracle 消息云服务 (OMCS) 鲜被提及。然而,在创建 OMCS 的过程中,Oracle 为消息传递处理带来了一些新特性,让它能够在云时代发挥一些非凡的效用。本文将介绍此消息传递引擎背后的 OMCS Web API,并将介绍 OMCS 如何让消息传递在 21 世纪中闪耀自己的光芒。

可以简单地认为 OMCS 是具有 REST 皮肤的 JMS,这是一种大体正确的说法,但它忽视了该服务的一些优势。我们先来谈谈这个新的 REST 皮肤,因为它本身为 OMCS 的普及提供了许多支持。

REST API 在很大程度上反映了 JMS 生命周期,即传输或接收消息的步骤顺序,如图 1 所示。

wilkins-omcs-fig01
图 1

由于 API 是基于 REST 的,因此可以轻松使用 cURL 等命令行工具与消息传递平台进行交互以执行各种任务,包括创建测试脚本以及通过集成甚至端到端流程来推送或拉取测试数据。您还可以将 OMCS 挂接到您的首选监视工具,并在脚本中使用 cURL 收集操作状态信息,甚至将 REST 调用挂接到监视工具。

对于新的 Oracle iPaaS 解决方案,OMCS 的 REST 接口文档在目前来说是非常优秀的。但还是有一些差距,因此我们将通过一系列命令来介绍执行消息传递任务是多么轻松。(这也有助于说明在前端客户端等轻量级环境中使用 OMCS 以及为微服务提供有效的通信骨干网是多么容易)。

为了安全起见,我们对可唯一标识服务器的凭证和信息进行了模糊化处理。

wilkins-omcs-fig02
图 2

首先发出的 cURL 命令用于建立一个连接。您可以看到,该命令以 -u 开头,后面跟着 <用户名>:<密码>。然后,我们为 X-OC-ID-TOKEN-STATUS 提供一个 HTTP 头部属性,用于禁用跨站点请求伪造 (CSRF) 攻击缓解。之所以能够关闭 CSRF,是因为我们正在从单一位置发起通信,不需要建立额外的令牌详细信息和令牌验证的开销。-c-b 参数均指向一个 cookie 文件,因为消息会话信息与 HTTP(S) 会话绑定,所以这是必需的。如果没有 cookie,下一个 REST 调用将无法链接到我们的连接,因此会以失败告终。我们在示例中使用的最后一个参数是 -write-out %{http_code},它确保显示 HTTP 响应代码和相关的消息。这一点非常重要,因为一些 REST 接口仅返回 HTTP(S) 响应代码。我们发起的所有调用中都将使用这些参数。

接下来是要调用的 URI。URI 字符串一直到 v1 的部分在调用中将始终保持不变,包括区域和域名。在 URI 的其余部分中,我们将创建(即 PUT)一个连接,接下来称作 myConnection。该参数告诉 OMCS 立即启动连接。您可以看到,响应包括代码 20;这是前面提到的 http_code。2xx 代码都与成功的操作相关,201 具体指“已创建”。

我们现在已经建立了一个连接,下一步是创建使用以下 REST 调用的会话对象:

wilkins-omcs-fig03
图 3

您可以看到,这次 URI 路径通往会话,并使用命名所使用连接的参数来标识 mySession。然后,我们看到另一个 201 响应,表示会话已经成功创建。

建立会话后,我们现在可以使用以下命令创建一个队列:

wilkins-omcs-fig04
图 4

我们有一个响应代码指示队列创建成功,并且可以看到所有可用的队列。遵循 REST 的设计原则,对队列执行 GET 操作应当提供关于所有队列的信息,这正是屏幕截图中的第二条 cURL 语句所实现的。

因此,通过 3 行 cURL 脚本,我们连接并创建了一个队列,并在第 4 行中检查队列是否存在。OMCS 不仅限于队列,它还可以处理临时和持久的问题。

建立队列后,只需用一个额外的 REST 调用来定义一个消息生产者(我们称之为 MyProducer),使用会话和目标参数将此生产者附加到特定队列(下例中的第一个调用),然后开始通过生产者将消息添加到队列中。为了便于阅读,我们在 cURL 中实现了这一任务,指定 REST 正文是 -T <文件名> 文件的内容。事实上,在这个小小的演示中,我们用三个简单但不同的负载实现了此目的,如下所示。由于添加消息被认为是对生产者的修改,因此可以看到调用是 HTTP POST。这确实给我们带来了 OMCS 的一项限制:消息大小不得超过 512kb。这不应该成为一个问题,即便是 AIA、OAGIS 和 ART 等所使用的大型、完全填充的规范 XML 模式也在努力突破这一限制。只不过,您在传递媒体内容时会受到限制。在这种情况下,我建议将媒体直接放在存储中,传递指向文件位置的消息。

wilkins-omcs-fig05
图 5

我们可以根据需要浏览队列,就像是将光标移至数据库上的效果,每次调用浏览时都会返回下一条消息,并返回 HTTP 200。如果到达队列的末尾,将返回一个空的消息正文。

除了浏览之外,我们还可以使用消息。几乎和生产者一样,这需要实例化一个使用者,使用参数来识别要使用的目标以及要链接的会话。

wilkins-omcs-fig06
图 6

使用者命名为 q1Consumer(和前面一样,名称是 URI 的最后一部分)如果需要,与 JMS 一样,您可以对使用者应用筛选器,但是此处仅接收应用了任何头部属性筛选的消息。然后,我们可以用使用者来检索消息。请注意,对于每次调用,我们都提供 1 秒(1000 毫秒)的超时时间,避免长时间被锁定等待响应。

wilkins-omcs-fig07
图 7

每个响应都会在其正文中返回消息。请注意,响应输出与输出 HTTP 响应代码的 cURL 指令之间没有换行符,因此 HTTP 响应代码紧随响应内容输出之后。

虽然这展示了使用 REST 接口可以轻松地与消息传递服务器交互,但是 OMCS 真正绝妙的功能是能够定义作为 REST 端点接收消息的监听器。这种监听器被称为推送监听器,因为 OMCS 需要主动调用指定的 REST 端点。这意味着,我们可以将使用 JMS 的旧式应用与 Java 连接,而接收者是现代 REST Web 服务。

推送监听器框架进一步提升了安全性,我们稍后再讨论。与发布消息内容一样,最简单的方法是通过在 cURL 中指定文件来提供消息正文,从而为推送监听器提供配置信息。在下面这个简单的例子中,我们定义了一个监听器 (myListener),它会监听 myFirstQueue 消息上的消息,然后调用由所使用的 URL 和 HTTP 方法标识的 Web 目标(可以选择 PUT 和 POST):

  <listener>
<version>1.0</version>
<name>myListener</name>
<source>
<type>queue</type>
<name>myFirstQueue</name>
</source>
<target>
<uri>http://targetURL/OMCS</uri>
<method>PUT</method>
</target>
</listener>


本例非常简单,我们并未定义当 REST 服务调用失败时的任何错误操作以及故障行为操作等。如果我们连接到一个主题,就必须提供关于连接是否持久等方面的更多信息。

创建推送监听器时需要提供一些额外的信息,因为 OMCS 实施了一个简单的验证机制来确认 REST 服务是否等待调用,客户端是否合法。这是通过对 REST URI 的第一次调用实现的,该 REST URI 仅包含一个头部属性 (X-OC-MPL-CHALLENGE) 和(可选的)调用中一个额外的参数来建立监听器,该参数随后会作为一个额外的头部值来传递,名为 X-OC-MPL-VERIFICATION。在第一个 REST 调用中,响应必须在其正文中包含 X-OC-MPL-CHALLENGE 提供的值。此验证步骤的存在可确保 Oracle 服务不会被标识为拒绝服务攻击的来源,因为接收者必须主动确认质询。我们来看看用于建立消息推送监听器的 cURL 调用。

wilkins-omcs-fig08
图 8

为了展示处理所述安全质询的逻辑,我们使用了 webscript.io 服务的试用版本,这样我们就能够轻松定义 REST 端点,并使用该服务的脚本语言(看起来很像 JavaScript,但实际上基于 LUA)来创建响应。我们来看看脚本:

wilkins-omcs-fig09
图 9

请注意,如果我们直接在 cURL 中调用 Webscript,会按原样接收头部属性(本例中全是大写字母),但是当通过 OMCS 发送时,Webscript 则会按骆驼拼写法接收头部属性。虽然我们可以通过一些奇特的头部属性字符串操作来简化条件,但我们还是选择了同时检查两种格式。您可以看到,当质询头部属性被识别时,它会被返回(这构成了响应正文)。如果没有返回任何内容,我们默认返回一个包含 HTTP 状态码为 200 的空响应。

可以在 Webscript 中查看的初始调用纯粹是一个确认调用,其验证和质询如下所示:

wilkins-omcs-fig010
图 10

所生成的响应将质询包含在正文中,如下图所示:

wilkins-omcs-fig011
图 11

完成此调用之后,REST 服务调用将针对我们发送的消息,如下所示:

wilkins-omcs-fig012
图 12

您可以看到,建立推送监听器非常简单。需要通过一些工作来处理质询机制,但也很容易实现。在现实世界中,可能会用到一个 API 网关,或者通过容器云服务实现一个简单的代理来完成这项质询任务。

如前所述,配置工作远比想像中复杂。不过 OMCS 提供了一个很好的平台来连接消息传递与基于 Web 的集成解决方案,尤其是当涉及混合云或云环境时。

关于作者

Oracle ACE Associate Phil Wilkins 是 Capgemini 的高级顾问,主要负责 iPaaS、中间件和 Oracle 技术。他与人合著了《实施 Oracle 集成云服务》(2017 年,Packt),并且经常为 OTN、UKOUG Oracle Scene 和其他一些刊物撰写文章。


本文谨代表作者的专业见解、结论和意见。Oracle 发布本文旨在鼓励社区内就此类信息进行广泛交流,并促进同行的评估和评论。相关 Oracle 产品团队尚未审查本文是否符合 Oracle 的标准和实践,其发布不应被解释为 Oracle 对其中所表述内容的认可。