RSARTE Connexis Users Guide翻译

Connexis User’s Guide
Connexis 是一个库，可以用于使用 Rational Software Architect RealTime Edition (RSARTE) 构建分布式实时应用程序。本文档将介绍如何使用 Connexis 以及它提供的可能性。本文档的读者被假定已经阅读了文档“在 RSARTE 中建模实时应用程序”，该文档涵盖了在本文档中更详细地解释的许多概念。本文档使用的是 RSARTE 10.3。所有的屏幕截图都是在 Windows 平台上捕获的。

这就是 Connexis 的作用所在。Connexis 提供了一种进程间通信机制，允许在不同进程中运行的capsule实例之间发送带有或不带有数据的消息。Connexis 的传输层负责消息及其数据对象的实际传输。该层建立在当前行业标准技术的基础上，例如 UDP 和 TCP，但您也可以使用任何其他自定义传输协议。下面的图片显示了 Connexis 的结构。CDM 意味着“Connexis 数据报消息”，使用 UDP 构建，而 CRM 意味着“Connexis 可靠消息”，使用 TCP 构建。

Connexis Model Library

Connexis 实现为 RSARTE 模型库。要使用它，您只需将模型库项目导入到您的工作区中，就像导入任何其他模型项目一样。从该模型库生成的 C++ 代码可以使用该项目的“C++库”转换配置构建为一个 C++ 库。但是，只有在您想要更改 Connexis 实现（例如实现自定义传输协议）或者如果您的应用程序应该构建为不存在预构建 Connexis 库的平台时，才需要执行此步骤。RSARTE 包含多个平台的预构建 Connexis 库（请参见支持的平台）。

使用 Connexis 进行进程间通信使用未连接的端口。这些端口使用 Connexis 特定的注册字符串向 TargetRTS 注册。除此之外，在模型级别上使用 Connexis 完全透明。这使得将现有的单块应用程序转换为分布式应用程序变得很容易，只需用未连接的端口替换少数已连接的端口即可。一旦这些未连接的端口已被注册，发送和接收它们的消息的方式与不使用 Connexis 的 UML 模型完全相同。

Connexis Benefits

Connexis 编程模型提供了显著的价值：
• Built for real-time
自动将 UML 通信端口映射到高性能软件背板。
• 适合产品但具有灵活性
软件一旦安装便可立即运行，但可适应处理应用程序特定需求。
• 易于使用的编程模型
支持客户端/服务器类型的名称绑定和异步消息传递。
• 支持容错
检测故障并提供处理故障的框架。

Access Transparency

Connexis 具有灵活的编解码策略，因此可以在不同类型的硬件环境中工作。目标环境的数据字节序对执行应用程序是透明的。

Location Transparency

Connexis 定位器服务为分布式应用程序提供位置透明性。应用程序使用服务名称引用正在连接的终端点。因此，这些终端点的物理地址永远不必向应用程序公开。定位器功能可用于在集成传输地址上发布的服务。Connexis 还支持许多不同的分发选项，使应用程序的设计非常灵活。
以下是支持的最常见的连接类型：

Local connections

对于同一进程内的本地连接，Connexis 优化通信以像直接连线端口一样高效。本地连接的终端点使用服务名称进行注册，Connexis 负责将终端点绑定在一起。一旦绑定，这些本地连接具有与绑定在一起的两个有线端口相同的性能特征。

Explicit endpoint connections

Connexis 接受在注册字符串中使用显式终端点地址的注册。如果应用程序知道它要访问的服务的位置，可以使用这种方法。通过这种方式，客户端可以使用显式位置和所需服务的服务名称绑定到服务。

Locator connections

Connexis Locator 服务可用于在分布式应用程序的任何地方查找服务（给定服务名称）。一旦启动了 Locator，连接的一侧将其注册为发布者，另一侧将其注册为订阅者。Connexis Locator 找到匹配的终端点，并将它们反馈给连接服务，当两个终端点都可用时，连接服务建立连接。

Configuration

Connexis支持多种配置选项。这使得Connexis的使用非常灵活，能够适应不同的目标环境。例如，配置选项可以：
• 配置连接审计
• 调整缓冲区计数和大小
• 调整线程优先级和堆栈大小
• 调整消息传递的时间特性

目标代理和 Connexis Locator 服务不必是每个 Connexis 应用程序的一部分。如果您的应用程序不使用 Locator 服务，则可以将这些组件从可执行文件的配置中排除。这有助于最小化 Connexis 代码在可执行文件中的链接大小。

目
Connexis允许使用相同的服务名称注册多个端口。这一点，再加上对端口多重性的标准RSARTE支持，使得Connexis能够支持几种常见的分发模式。不直接支持的模式通常可以很容易地在RSARTE中实现。

Connexis模型库附带完整的源代码。如果自定义目标配置需要，可以重建库（请参阅将连接移植到新目标配置）

Connexis允许使用相同的服务名称注册多个端口。这一点，再加上对端口多重性的标准RSARTE支持，使得Connexis能够支持几种常见的分发模式。不直接支持的模式通常可以很容易地在RSARTE中实现。

Connexis模型库附带完整的源代码。如果自定义目标配置需要，可以重建库（请参阅将连接移植到新目标配置）。

Fault-tolerance and Reliability

容错和可靠性对于大多数实时系统来说是至关重要的。Connexis在设计时就考虑到了这些要求。以下是增强容错性和可靠性的不同Connexis功能的列表：

•定位器服务可以在单工或双工模式下运行。二进制选择器用于确定主定位器的健康状况。这提供了冗余，可以避免分布式应用程序中的“单点故障”。
•Connexis是为真正的非阻塞行为而设计的。所有潜在的阻塞系统调用都由一组用户可配置的辅助线程来处理。名称解析是一个使用辅助线程的操作示例。
•心跳式审计用于基于UDP的连接，以检测连接、进程或处理器故障。此审计是可调整的，因此可以在各种环境中使用。审计非常高效，因为它监视用户消息以收集状态信息。这样就可以避免出现明确的“你还活着吗？”消息。当使用明确的“你还活着吗？”消息时，可以限制每单位时间发送的此类消息的数量，以确保审计不会过度利用系统资源。当使用面向连接的协议（如TCP）时，只使用一个非常基本的“连接是活动的吗？”协议。
•可以在UML异步消息控制器和流控制传输消息路由器之间配置缓冲策略。这样可以确保您的模型不会因传输连接缓慢或中断而挂起。当队列填满时，消息将从系统中正确删除。
•很容易构建一组满足特定应用程序的容错和可靠性要求的组件。所有Connexis端口都支持标准的通用事件rtBound和rtUnbound，但这些通知可以在每个端口的基础上启用，并由应用程序以最小的额外复杂性使用。
•当不满足某些服务质量参数时，应用程序只需注销未注册的端口，就可以覆盖底层的“永远尝试”算法。
•可以使用Connexis作为底层分发机制来实现分发模式。例如，单个发布者实际上可以隐藏到复制服务的多个分布式连接。
•可以对服务的发布者施加资源限制，以限制每个发布者的订阅人数。
•将未连接的端口分配给capsule由设计者控制，由于将capsule部署到线程上也由应用程序控制，因此应用程序可以动态控制正在使用的资源。
•服务可以根据首选的使用顺序进行排名。这种排名是通过对资源限制的全面、动态更新的知识来完成的。如果具有特定级别的给定服务已满，则将使用较低级别的服务（如果可用）。
•可配置系统审核验证整个系统的内部系统连接状态是否匹配。

Supported Platforms

RSARTE包含用于以下平台的预构建Connexis库：
• LinuxT.x64-gcc-12.x (Linux 64 bit with gcc 12.x)
• WinT.x64-MinGw-12.2.0 (Windows 64 bit with MinGW 12.2.0)
• WinT.x86-VisualC+±17.0 (Windows 32 bit with Visual Studio 2022)
• WinT.x64-VisualC+±17.0 (Windows 64 bit with Visual Studio 2022)
• WinT.x64-Clang-16.x (Windows 64 bit with Clang 16.x)

要为另一个平台构建Connexis，请按照将Connexis移植到新目标配置一章中提供的说明进行操作。

Connexis术语和定义

CDM Connexis Datagram Messaging

Connexis数据报消息。UDP之上的层，为连接审核和服务质量参数提供额外支持。

CRM Connexis Reliable Messaging

Connexis可靠消息。TCP之上的层，为连接审核和服务质量参数提供额外支持

DCS Distributed Connection Service

这是用于连接和管理连接中不同方的关键组件。这也是Connexis模型库的名称。

DNS Domain Name System (or Service)

一种将域名转换为IP地址的互联网服务。因为域名是字母数字，所以更容易记住；然而，互联网实际上是基于IP地址的。每次使用域名时，DNS服务都必须将该名称转换为相应的IP地址。例如，域名www.example.com可能翻译为198.105.232.4。

duplex locator service

指其中有两个定位器的配置。在正常操作中，一个定位器充当活动定位器（主定位器），另一个充当备用定位器（备用定位器）。此配置用于防止定位器成为单一故障点。

endpoint

端点是用于查找对等对象的显式网络地址。它由一个协议、一个冒号和一个协议地址组成。例如：cdm://ipaddress:port.端点被实现为在指定的网络主机上运行的可执行文件，并侦听指定端口上的消息。

ILS

内部层服务。这是建立在RSARTE的TargetRTS中的连接服务。它只能用于在端口之间建立进程内连接。

IPC

进程间通信。这是一个广泛的术语，用于描述进程之间共享信息的任何机制。这可以是像共享内存这样简单的东西，也可以是像CORBA这样复杂的东西。

Locator

Connexis定位器服务是一种可配置的服务，用于查找给定对象服务名称的对象的物理位置

notification

用于描述向capsule实例发送消息以通知其某个端口何时已连接到（rtBound）或断开与（rtUnbound）对等端口的连接的过程的术语。

SAP

服务接入点。用于描述作为订阅者（在客户端容器上）参与连接的未连接端口的术语。

simplex locator service

指只有一个定位器的配置。此配置不提供冗余。另请参阅双工定位器服务

SPP

服务提供点。用于描述作为发布者（在服务器封装上）参与连接的未连接端口的术语。

TargetRTS

目标运行时系统。也称为RT服务库。一个C++库，用于实现从RSARTE生成的应用程序所需的所有UML-RT服务。

TCP/IP

传输控制协议/互联网协议。基于连接的传输协议。

Transport

用于在通信对象之间传递消息和数据的底层协议

Transport Integration Framework(TIF)

一个允许第三方（包括开发人员）添加额外传输以在Connexis中使用的框架。

UDP

用户数据报协议。无连接传输协议。

UML

统一建模语言。一种用于对面向对象软件系统建模的行业标准建模语言

UML-RT

UML实时性。UML的扩展子集，为构建基于状态事件的实时应用程序提供有用的服务。应用程序是在RSARTE中设计的（带或不带Connexis），用于对正在构建的软件进行建模。

unwired port

未连接端口是一个UML对象，它可以使用注册字符串指定连接。这些字符串可以在设计时或运行时指定。未连接的端口是SPP端口或SAP端口，在运行时，可以动态连接这两个不同类型的端口，以实现消息和数据交换。

virtual circuit

virtual circuit是指在两个端点之间建立的连接。这是指单个订阅者（SAP端口）和单个发布者（SPP端口）之间的连接。Connexis对跨越过程边界的虚拟电路的最大数量有一个静态（但可配置）限制。

wired port

有线端口是一个UML对象，它可以在设计时指定显式连接（到另一个有线端口）。连接将在系统初始化时建立，或者如果端口包含在可选或插件的封装中，则在运行时建立

Connexis Application Layers

Connexis允许以稳健可靠的方式连接多个RSARTE生成的可执行文件。可执行文件通过跨流程边界连接未连接的端口而联网

使用Connexis实现进程间通信的RSARTE应用程序具有如下所示的高级架构。所示的控制路径指示在UML应用程序中注册和注销端点所涉及的组件。在启用了Connexis的应用程序中，在端点之间发送的所有数据都通过传输组件

让我们来看看这些不同的应用程序层。

UML Application

在UML应用程序中，端口用于在模型中的capsule之间发送消息。有不同种类的端口。最常见的端口类型是有线端口。有线端口通过连接器明显连接到其他有线端口。有线端口以图形方式表示，在端口图标的椭圆形部分有两个相连的正方形。

另一种类型的端口是未连接端口。未连接端口是建立Connexis连接的主要方法。一旦您创建了一个未连接的端口，您就可以通过向TargetRTS注册端口来指定它将使用的连接服务、协议和端点地址。此注册可以自动完成（设计时），也可以通过应用程序代码完成（运行时）。下图所示的连接服务是Connexis的分布式连接服务，即DCS是连接服务的一种实现方式。

Distributed Connection Service

分布式连接服务（DCS）是Connexis提供的连接服务。它负责维护已注册的未连接端口的信息。DCS是系统的一部分，负责在未连接端口之间建立连接。它通过解析注册未连接端口时传入的注册字符串来实现这一点。

Transport

传输是负责在进程之间发送和接收数据的组件。它管理任何传入或传出的数据缓冲区，并对数据进行编码和解码。传输组件的更详细分解如下所示。

Locator

健壮分布式系统的另一个关键组件是容错名称服务。名称服务用于找到给定预定服务名称的服务的实际位置。名称服务的一个众所周知的例子是在互联网上广泛使用的域名服务（DNS）。名称服务的主要功能是在给定服务名称时查找特定地址。这将调用应用程序与网络组件物理寻址的更改隔离开来。在Connexis中，定位器服务提供名称服务功能。

定位器服务实际上做的不仅仅是作为名称服务器操作。定位器可以配置为在提供相同服务的多个端点之间进行仲裁，也可以设置为以双工模式运行，这允许备份定位器在主定位器出现故障时自动接管

端点被定义为传输协议和分布式应用程序中对象的特定端口地址的组合。例如cdm://address:port.如果提供了显式端点，则不需要定位器服务，客户端将尝试直接连接到指定端点位置的服务器。但是，如果没有提供明确的端点，则会联系定位器。Locator返回一个端点，然后Connexis使用该端点来选择适当的服务提供商或对等方。引用端点的服务名称被指定为该端点的注册字符串的一部分。

Connexis定位器服务同时支持主定位器和备份定位器。通过这种方式，可以确保名称服务器不会成为单一故障点，从而使分布式应用程序更加健壮。

The Connexis HelloWorld Sample Model

RSARTE包含一个示例Connexis模型，该模型演示了Connexis定位器服务的使用，以及如何使用它在分布式环境中提供备份定位器服务。通过执行“文件-新建-示例”打开示例模型。在“UML Capsule Development”类别下，选择“Connexis_HelloWorldOverflowToBackupService”示例。

将Connexis库模型导入到您的工作空间（“文件”-“导入”-“常规”-“现有项目到工作空间”）。要导入的项目位于RSARTE安装中，位于rsa/rt/Conecaxis/DCS下。

Connexis HelloWorld示例模型包含两个服务器、一个客户端和Connexis Locator服务，每个服务器都作为独立的应用程序运行。服务器使用不同的语言（英语或法语）。最初，客户端绑定到最先出现的服务器。绑定后，客户端会定期向服务器发出请求，服务器会用所说的语言发回问候语。

如果客户端绑定到的服务器变得不可用，则会通知客户端连接丢失。然后，它重新绑定到备份服务器，备份服务器开始用它所说的语言响应客户端请求。例如，如果客户端最初绑定到英语服务器，它将开始接收英语问候语。如果您随后终止英语服务器，连接将立即丢失。然后，客户端将反弹到法语服务器，过一会儿，客户端将开始接收法语问候。

这个示例演示的另一件事是溢出处理。英语服务器被赋予更高的级别，因此它充当主服务器。客户端连接到主服务器，直到主服务器达到其全部容量（本例中为2个客户端）。随后启动的任何客户端都将连接到法国备份服务器。

Tutorial: Building a Distributed Application with Connexis

学习如何使用Connexis的最好方法是构建一个使用它的小型分布式应用程序。本教程将带您完成创建、构建和执行启用Connexis应用程序所需的步骤。遵循本教程的唯一先决条件是安装了带有Connexis的RSARTE（请注意，Connexis是一个可选的安装组件，默认情况下不会安装）。

Overview

本教程中要创建的应用程序是一个简单的“乒乓”应用程序。每个客户端都会向服务器发送一条“ping”消息，服务器会以一条“pong”消息进行响应。下面的序列图显示了Ping（客户端）capsule实例和Pong（服务器）capsule实例之间发送的消息。

注册是使用定位器服务完成的。还介绍了启动应用程序所需的命令行选项。
此应用程序分两次迭代创建：
Iteration 1: Creating the Application Model
创建使用有线端口连接Ping和Pongcapsule的基本体系结构。这还涉及第三个capsule，其充当 Ping and Pongcapsule的容器。

Iteration 2: Use Connexis to Make the Application Distributed
在应用程序中进行修改，以便Ping和Pong通过使用Connexis连接的未连接端口进行通信。

Iteration 1: Creating the Application Model

首先创建一个新的模型项目（文件-新建-模型项目）。将新项目命名为“Connexis_PingPong”。

在项目资源管理器中找到创建的项目，然后选择顶部的PingPong包。使用上下文菜单命令AddUML-Package在PingPong包下创建四个包。

对于像这样的小型和琐碎的应用程序来说，使用包来组织应用程序的元素可能不是必要的，但对于较大的应用程序，将相关元素分组到包中会有所帮助。

3. 选择PingPongClient包并在其中创建一个Pingcapsule。（在上下文菜单中添加UML-capsule）
4. 在PingPongServer包中创建一个Pongcapsule。

在这个应用程序中，Pingcapsule扮演客户端的角色。它之所以被称为客户端，是因为它只管理一个连接。应用程序的服务器端负责管理多个连接（连接到的每个客户端一个）。Pongcapsule在此应用程序中扮演服务器的角色。请注意，在现实世界中的分布式应用程序中，对于不同的通信场景，同一对象同时扮演客户端和服务器的角色并不罕见。然而，在这个简单的应用程序中，Pingcapsule实例始终是客户端，而单个Pongcapsule实例就是服务器。

5. 在Container包中创建一个Containercapsule。
   您现在拥有此应用程序所需的全部三个capsule：
   

6. 现在是时候通过创建一个协议来定义Ping和Pongcapsule之间的通信了。选择Common包并使用上下文菜单命令AddUML-Protocol创建一个名为“PingPong”的协议。

7. 在协议中创建两个事件；一个名为“pong”的输入事件和一个名“ping”的输出事件
   我们在这里使用的约定是从客户端的角度定义协议。这就是为什么“pong”是In Event，因为它将由客户端接收，而“ping”是Out Event，因为其将由客户端发送。请注意，这种定义协议的方式只是一种约定。它还可以从服务器的角度定义协议。最重要的是，您在整个应用程序中保持一致，以使模型更易于理解。然而，从客户端的角度定义协议的一个好处是，您只需要共轭一个端口（服务器中的端口），而所有客户端端口都可以保持非共轭。客户端端口通常比服务器端口多，这就是为什么这种约定意味着更少的建模工作

8. 将顶部PingPong包中的Main类图重命名为“Architecture”。将所有三个capsule拖放到类图上，并创建从Container到Ping和Pong的组合关联。通过这样做，您可以在容器中添加两个capsule部分（“ping”和“pong”）。

9. 将“ping”capsule部分的多重性设置为5。保持“pong”capsule部分的多重性不变。这意味着我们将在应用程序中有5个Ping客户端和1个Pong服务器
   

如果你打开Containercapsule的结构图，你也可以在那里看到capsule parts。

10. 在Ping和Pongcapsule中创建一个端口。这可以通过多种方式实现，例如，将乒乓协议拖到体系结构类图上，然后创建从乒乓到乒乓协议的组合关联。保留从协议名称派生的默认端口名称（“pingPong”）。

11. 将Pongcapsule中端口的多重性设置为5，以便它可以连接到5个不同的Ping客户端。此外，使用“属性”视图，将该端口标记为共轭端口。这交换了协议中输入事件和输出事件的含义，以便Pong可以接收“ping”输出事件并发送“Pong”输入事件。
    

12. 在Ping和Pongcapsule中创建一个端口“日志”。使用预定义的日志协议键入此端口。Ping客户端在从服务器接收到“pong”事件时将使用此端口写入日志消息，而pong服务器在从客户端接收到“Ping”事件时会写入日志消息。请注意，与“pingPong”端口相反，这些端口不应该是服务端口，因此在“属性”视图中取消标记“服务”复选框。非服务端口不是capsule通信接口的一部分，只能由capsule本身使用。

13. 为了让Ping和Pongcapsule进行通信，我们需要连接“乒乓”端口。目前，我们将使用连接器将它们连接起来，但在下一章（迭代2：使用Connexis使应用程序分布式）中，我们将使端口不有线，并使用Connexi斯建立通信路径。在Containercapsule的结构图中创建连接器。
    

现在是时候实施乒乓球capsule的行为了。我们使用状态机

14. 在“体系结构”类图或Containercapsule的结构图中选择Pingcapsule。从上下文菜单中执行命令“打开状态机图表”以打开Pingcapsule的状态机。它有一个默认的简单状态机，仅由一个状态和一个初始转换组成
15. 将状态重命名为“就绪”。
16. 选择初始转换，并使用“代码”视图输入以下效果代码：

pingPong.ping().send()；

这意味着，一旦Pingcapsule的实例被创建，并且其状态机开始执行，它就会在“pingPong”端口上发送“Ping”事件

17. 使用上下文菜单命令AddUML-Transition为“就绪”状态创建一个内部转换。
18. 使用Properties（属性）视图中的Triggers（触发器）页面为该转换创建触发器。当在“pingPong”端口上接收到“pong”事件时，应触发转换。还应将转换重命名为“ponng”。为了使状态机可读，通常最好根据触发转换的事件来命名转换，至少在这种情况下只能由一个事件触发时是这样。
19. 使用“代码”视图并为“pong”转换输入以下效果代码：

log.log("received a pong");
log.commit();
pingPong.ping().send();

Ping状态机现在应该是这样的：

为什么我们将“pong”创建为内部过渡，而不是从“就绪”状态绘制外部过渡线并返回到自身？因为我们希望状态机在处理“pong”事件时保持“就绪”状态。这既使状态机更容易理解，状态图更容易绘制，也使生成的应用程序运行得更快（无需先退出状态，然后再进入状态）。

现在重复上面的步骤来创建Pongcapsule的状态机。唯一的区别是，内部转换现在应该被称为“ping”，并在“ping”事件上触发。初始转换应该为空（因为服务器启动时不需要做任何事情），对于“ping”转换，您应该输入以下效果代码：

log.log("received a ping");
log.commit();
rtport->pong().reply();

在这里，我们使用了“rtport”，对于每个转换效果代码，它指的是接收触发转换的事件的端口。当你想在同一个端口上回复收到的事件时，“rtport”主要很有用。在这种情况下，你不必用它的名称来指代端口。如果您认为这会使代码更可读，那么可以使用与Ping状态机中相同的方式发送事件。

Build and Run the Model

要构建和运行您创建的模型，您需要一个转换配置（TC）。这是一个包含所有生成设置和其他属性的文件，这些属性控制如何将模型转换为可执行应用程序。您的模型项目包含一个名为“默认转换配置”的默认转换配置。它包含许多有用的默认设置，但在用于构建应用程序之前需要进行一些更新。

双击“Default Transformation Configuration”（默认转换配置）打开TC编辑器。设置以下TC属性：

1. 在Main选项卡上，单击“Automatically create and update target project”（自动创建和更新目标项目），并指定一个工作空间路径，用于创建带有生成的C++文件的CDT项目。例如

2. 在“代码生成”选项卡上，将“顶部capsule”属性设置为“容器”capsule。这指定了应用程序启动时将体现的封装。
3. 在“目标配置”选项卡上，设置“TargetRTS配置”属性以匹配您的目标平台（操作系统和编译器）。同时使用“生成类型”属性指定生成方言。

保存TC并使用上下文菜单命令build来构建它。C++代码将被生成、编译并链接到可执行文件中。可执行文件放在指定目标项目的“默认”文件夹中，称为“可执行文件”。

使用TC上下文菜单命令Run As-RealTime application运行应用程序。过了一会儿，您应该会在Console视图中看到日志消息打印输出：

这些打印输出显示您的乒乓球应用程序工作正常。这5个客户端中的每一个都发送一个“ping”，服务器则以“pong”作为回复。现在是时候使用Connexis将这个单片应用程序转换为分布式应用程序了。

Iteration 2: Use Connexis to Make the Application Distributed

在将迭代1中构建的示例PingPong模型转换为使用Connexis之前，您可能需要复制该项目并将其粘贴为“PingPong_Initeration1”项目。因此，您可以稍后比较分布式和单片PingPong应用程序的模型