Question

I’m developing windows service that serves two purposes.

1. It is a proxy to WebSphere MQ for web application that asks other
   systems – it sends request and second system replies.
2. 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.

Answer 1

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 on SVC.CUST.LOOKUP.V02. Requestors of the service then have the ability to migrate from the V1 queue to the V2 queue 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.