复杂软件系统中的协调机制剖析

# 复杂软件系统中的协调机制剖析 ## 1. 生产自动化中的挑战与场景概述 生产自动化面临的主要挑战是需要具备灵活性，以快速有效地应对不断变化的业务和市场需求。一种实现快速响应的方法是对托盘进行优先级排序，即代理需要优先处理高优先级产品的特殊部件，而不是低优先级的托盘。 简化后的场景可概括为： - 按写入顺序对条目进行排序，并根据写入条目的优先级进行分组。 - 从优先级最高的非空组中移除最先写入的条目。 - 传送带的可用空间有限，具体取决于传送带的长度。 为了解决这些问题，下面将基于 SBC 的架构与基于 JMS 消息中间件或 Linda 元组空间的架构进行比较。 ## 2. Java 消息服务（JMS） ### 2.1 JMS 队列在生产自动化系统中的应用 在生产自动化系统中，JMS 队列适用于代理之间的通信。对于上述优先级排序问题，有两种可能的实现方式： #### 2.1.1 每个优先级一个队列 当代理（Agent A1）要将条目放入队列时，它会查找条目的优先级，并执行相应队列的发送操作（操作 1、2 或 3）。这意味着应用程序组件需要管理三个不同的队列连接。在放入条目之前，代理需要检索队列的大小，如果存储的消息数量超过允许的最大值，发送者需要寻找替代路由路径。 在接收端，代理（Agent A2）有两种接收条目的方式： - 轮询：从优先级最高的队列开始轮询，如果队列为空，则访问下一个优先级的队列，直到找到非空队列并处理其中的条目。 - 通知：当有条目写入队列时，JMS 会通知代理，消息会被推送给订阅的代理。但在这种情况下，队列的概念需要从 QueueSession 和 QueueReceiver 更改为 TopicSubscriber 和 MessageConsumer，这会触发代理实现逻辑的更新。 这两种方法的主要区别在于谁控制代理。如果代理被通知，则必须立即处理推送的条目；如果代理轮询队列，则可以更自主地决定何时访问队列以及采用何种策略（例如配置轮询速率）。 #### 2.1.2 单个队列使用选择器 在这种实现中，代理（Agent A1’和 A2’）访问单个队列，通过使用选择器指定要访问条目的优先级。与第一种实现不同的是，这里需要使用三个不同的选择器，而不是三个不同的队列连接。 ### 2.2 基于 SBC 架构的“PRIO - FIFO”协调器 在提出的 SBC 架构中，使用“PRIO - FIFO”协调器允许软件开发人员向代理透明地指定协调策略。写入操作需要一个优先级参数和条目，条目的存储方式由软件开发人员决定，与应用程序组件无关。 由于协调策略体现在协调器中，代理的获取操作已经反映了优先级限制的语义，因此获取操作不需要任何参数，协调器会返回优先级最高的条目。从获取操作迁移到写入条目通知时，概念上不会有任何变化，应用程序组件只需执行通知操作并指定回调方法。 下面是 JMS 两种实现方式的比较表格： | 实现方式 | 连接管理 | 发送操作 | 接收操作 | 控制权 | | ---- | ---- | ---- | ---- | ---- | | 每个优先级一个队列 | 管理三个队列连接 | 根据优先级选择队列发送 | 轮询或通知 | 轮询时自主，通知时被动 | | 单个队列使用选择器 | 一个队列连接，使用三个选择器 | 单个队列，用选择器指定优先级 | 类似轮询或通知 | 类似轮询时自主，通知时被动 | ## 3. Linda 元组空间 ### 3.1 Linda 元组空间实现优先级队列 在 Linda 中实现队列需要在元组空间中放置两个额外的元组：一个表示队列的第一个索引（in - token），另一个表示队列的最后一个索引（out - token）。每个元组在空间中必须遵循特定的结构，要么是包含索引类型、队列优先级和实际索引值的索引元组，要么是包含类型（消息）和队列中索引的消息类型。 当一个元组放入队列时，需要取出最后一个索引元组，写入新的元组和更新后的索引元组（索引加 1）。当需要读取或取出第一个元组时，需要找到第一个索引元组，读取其索引，并根据该信息检索或取出消息，然后写入更新后的索引元组。如果无法检索到消息，则表示当前队列为空，需要重复该过程，直到找到较低优先级的消息