IBM WebSphere MQ - 如何仅读取 MQMT_REQUEST 消息
我正在开发有两个目的的 Windows 服务。
- 它是WebSphere MQ的代理，用于请求其他请求的Web应用程序 系统 - 它发送请求和第二个系统回复。
- 它是一个应该响应其他系统请求的服务器 - 其他系统发送请求，服务响应。
在场景 1 中，我正在等待具有特定相关 ID 的响应。但是，在场景 2 中，我正在等待任何请求消息。如何避免读取场景 2 中的响应并将其视为场景 2 中的请求的情况？我想将我在场景 2 中读取的消息仅过滤为具有消息类型 MQMT_REQUEST 的消息。
预先感谢您的帮助。
I'm developing windows service that serves two purposes.
- It is a proxy to WebSphere MQ for web application that asks other
systems - it sends request and second system replies. - It is a server that should respond to other system requests - other system sends request, the service responds.
In scenario 1 I'm waiting for response with specific correlation ID. However, in scenario 2 I'm waiting for any message that is a request. How can I avoid situation that I will read the response from scenario 2 and treat it like a request in scenario 2? I would like to filter the messages that I read in scenario 2 only to messages that have Message Type MQMT_REQUEST.
Thanks in advance for help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用两个不同的输入队列。当存在混合消息类型时，从程序逻辑和 WMQ 索引方面来说，从队列中选择正确消息的开销比简单创建两个队列要大得多。
通常，在面向服务的体系结构中，服务端点队列是众所周知的，而回复队列要么是动态的，要么至少不是众所周知的，因为服务提供者只需要查看返回地址的回复字段。在这种情况下，您的应用程序既是服务提供者又是服务使用者。它用作其提供的服务端点的队列应该是所有客户端向其发送消息的众所周知的队列。它用于回复其服务请求的队列应该是一个完全不同的队列。
一个很好的例子是，增强服务时为新版本提供不同的端点队列是很常见的。例如，根据帐号返回客户名称的服务可能位于队列
SVC.CUST.LOOKUP.V01中。如果该服务得到增强，则可以在SVC.CUST.LOOKUP.V02上提供新版本。然后，服务请求者就可以按照自己的计划从V1队列迁移到V2队列，而不是要求它们立即全部转换。在这种情况下，您肯定不希望应用程序的回复队列与其服务端点队列关联。两者服务于完全不同的功能，受到完全不同的变更控制和增强计划等的约束。
Use two different input queues. The overhead of selecting the right messages from the queue when there are mixed message types is considerably greater, in terms of program logic and WMQ indexing, than to simply create two queues.
Typically in a Service Oriented Architecture, the service endpoint queues are well-known and the reply-to queues are either dynamic or at least not well-known since the service provider needs only to look at the reply-to fields for the return address. In this case your application is both a service provider and a service consumer. The queue it uses as an endpoint for the service it provides should be a well-known queue that all of its clients send messages to. The queue it uses for replies to its service requests should be an entirely different queue.
One good example of why is that it is common when enhancing a service to provide a different endpoint queue for the new version. For example a service that returns a customer name based on an account number might live on a queue
SVC.CUST.LOOKUP.V01. If the service is enhanced a new version can be made available onSVC.CUST.LOOKUP.V02. Requestors of the service then have the ability to migrate from theV1queue to theV2queue on their own schedule rather than requiring them all to convert at once.You would definitely not want your application's reply-to queue to be associated with its service endpoint queue in this situation. The two serve entirely different functions, are subject to entirely different change control and enhancement schedules, etc.
如果是相同的服务，请从队列中的一个位置读取消息（可能是您的主循环，对吧？），当消息到达时，检查其相关 ID 并查看它是否是场景 1 响应。根据该测试决定执行哪个处理。
If it's the same service, read messages from the queue in one place (probably your main loop, right?), when a message arrives check its correlation ID and see if it's a scenario-1 response. Decide which processing to perform based on that test.