基于中间件的soap over http/jms混合请求-应答模型

我们的一个产品实现了以下单向Web服务结构:

Server <--------------------- Middleware <---------------- Client
        SOAP over JMS (queue)              SOAP over HTTP

在这个模型中,客户机通过http向我们的中间件(progress sonicmq)发送soap消息。消息由sonicmq推送到jms队列中,服务器从那里获取它们。但是,正如您所看到的,服务器不向客户端发送响应(异步JMS)。

我们希望实现对此模型的响应通道。通常建议的解决方案是在中间件中创建一个临时replyto队列(动态),允许服务器向该队列发送响应。然后,客户端可以获取响应,并关闭答复队列。这听起来很方便,但不幸的是,我们的客户在纯HTTP上运行,而不是JMS,所以他们的客户不能轻易地设置回复队列。

在这种混合http/jmsoap模型中实现响应通道的一种方法是,配置中间件以在每次成功的soap接收上打开replyto队列,将replyto队列和发送者信息附加到soap消息并将消息推送到队列中,服务器将从何处获取它。在接收并处理消息之后,服务器可以向中间件中指定的replyto队列发送响应。最后,中间件将通过使用来自SOAP消息的数据(在请求首次被接收时插入到中间件程序中的数据)将HTTP上的响应(SOAP)发送回原始客户端。

虽然可以说,这听起来有点老套。所以问题是:在我们的案例中,有没有更干净的方法来实现这种请求/响应模型?服务器端已在Java中实现。

解决方案:

progress sonicmq支持“content reply send”http接受器,它允许轻松发送jms应答。内容回复发送接受程序的工作方式如下:

• acceptor接收客户端发送的http消息
• 接受程序创建临时jms队列
• acceptor构建一个包含http主体的jms消息,并将临时队列的标识添加到新创建的jms消息中。
• 接受方将jms消息推送到其目标队列(而不是临时队列)
• 接受者开始使用临时回复队列
• 当客户端从原始目标队列获取消息时,它包含设置的对队列的应答标识
• 客户端使用消息
• 客户端将应答发送到应答队列
• 接受者从队列接收消息
• 接受程序将消息作为http发送到最初发送http消息的客户端

如果使用者(在我们的例子中是“服务器”)失败并且没有发送导致超时的应答,sonic的http接受器会向客户端发送一条指示超时的http消息。这是sonicmq的一个非常标准的特性。我想它也存在于其他产品中。

这允许在“服务器”端使用标准的soap over jms(参见skaffman的答案),避免了在中间件中进行任何自定义编程。

不过,我仍然看到jms模型中存在一些问题,但这绝对是一个改进。

更新2009-11-05:

在进一步研究这个问题之后,我发现我对http<--gt;中间件<--gt;jms的怀疑是相关的。

这个模型中有几个关键问题。带有中间件的同步异步模型并不方便。要么让两端都实现jms连接(它应该是rock),要么在两端都使用http。把它们混在一起只会导致头痛。在这两者中,soap over http比soap over jms更简单,也更受支持。

再次:如果你正在设计这样一个系统…不要。