2011-12-14 62 views
0

我试图为排队的消息传递系统实现会话上下文数据。异步(排队)消息传递和关联的会话数据

会话处理过程如下: 前端应用程序对自身进行身份验证并接收会话标识。 之后,会话标识被包括在消息标题中,所以消息处理程序被提供有用于例如安全检查和审计日志记录。如果客户崩溃并继续工作,客户可能会选择一个会话。

所以现在我们要将键/值对与会话ID关联起来。但是,如果会话数据发生变化,会产生许多并发问题,因为消息处理程序使用的会话数据应该是发送消息时的数据。

我看到了两个可能的解决方案:

  1. 将相关的会话数据,每一个消息头
  2. 商店版本数据库的会话数据,并在邮件标题中使用的版本号。

第一个使消息更大,第二个使会话数据库更大并创建大量的基础结构代码。我必须将最新的值保存到数据库中,所以如果客户端崩溃或连接丢失,客户端可能会继续工作。

还有其他解决方案吗?我倾向于使用第一种解决方案,但希望首先获得一些反馈。

其他人如何处理这个问题(例如JMS/NServiceBus/Masstransit)?

根据答案更新: 我选择了说服我的团队成员仅在前端使用会话数据并将其放入消息中(如果消息处理程序需要)。

回答

1

您没有真正详细说明为什么要将键/值对与会话概念相关联。

来自NServiceBus和Udi Dahan关于SOA和服务边界的建议,这种类型的会话概念往往会让我误以为是错误的。我的感觉是,消息处理程序在很大程度上应该在时间方面相当确定。也就是说,它现在应该运行得很好,或者排队等待一段时间,并在将来的某个时刻以完全相同的方式执行。

所以,我的建议是,出于安全考虑,如果有必要,请继续使用消息标题。在NServiceBus中,您可以引入来自IT/Ops Service的消息处理程序,这些消息处理程序被配置为首先在处理程序链中执行,验证安全性以及与实际业务逻辑无关的东西。在这种情况下,标题信息仅影响消息是被处理还是被拒绝。

当你得到会话类型信息时,我想仔细分析这些需求并将相关的部分放入消息模式本身。

同样,首先了解会话数据背后的动机会有所帮助。如果你编辑你的问题,也许我们可以找出你可以重新组织这些需求的方法。

+0

你对消息架构是正确的。会话数据应该保留在前端并且仅存储用于恢复。将相关业务数据放在标题或外部会话数据库中是错误的。 – sanosdole 2011-12-16 16:20:18