3.7 Example 7: Server Farm

  • Article

This example demonstrates the sequence of events for messages in a server farm, as described in the Send Message to Queue – Application (section 2.5.3) and Receive a Message from a Queue – Application (section 2.5.6) use cases.

Prerequisites

See the common prerequisites that are described in section 3.

  • The queue exists.

  • The application is authorized to send messages to the queue.

  • If a Directory Service is not being used, the application is configured with the address of the queue prior to the send operation.

  • The receiving application is authorized to receive messages from the queue.

Initial System State

Each agent's computer is operating in the queue server role, and the Intermediary Server is operating in the supporting server role. The analysis servers are operating in the application role.

The queue manager on the Intermediary Server is initialized to contain a transactional queue and configured to accept only authenticated messages. The queue manager on each agent's computer is initialized to contain queues to which response messages are sent by the analysis applications.

Final System State

The final states of the queue managers are equal to their initial states. The intermediary server queue manager contains a transactional queue, and the queue is in a ready state. Each agent's queue manager contains a queue, and the queue is in the ready state.

Sequence of Events

The following figure shows the sequence of events for the server farm messages.

Message sequence for server farm

Figure 25: Message sequence for server farm

  1. The sales program application creates an MSMQMessage CoClass ([MC-MQAC] section 3.17) instance and initializes the object as specified in [MC-MQAC] section 3.17.3 to transfer the data into the message.

  2. The sales program application creates a new unique transactional unit of work identifier XACTUOW ([MS-MQMQ] section 2.2.18.1.8) structure, encapsulates the message in an MSMQ message, and sends it to the Queue Manager on the Agent's Server, as described in steps 1 through 2 of Example 1: Disconnected Data Entry (section 3.1). The Queue Manager on the agent's server stores the message in its outgoing queue.

  3. The Queue Manager on the agent's server encrypts the message, as specified in [MS-MQQB] section 3.1.7.1.5, authenticates the message, as specified in [MS-MQQB] section 3.1.5.8.3, and generates the Send User Message Event ([MS-MQQB] section 3.1.7.1) to send the message to the intermediary server Queue Manager.

  4. The analysis program application creates a new unique transactional unit of work identifier XACTUOW structure and receives the message from the intermediary server Queue Manager, as described in steps 8 through 9 of Example 1: Disconnected Data Entry.

  5. The analysis program analyses the received message.

  6. The analysis program application sends the response message to the intermediary server Queue Manager by invoking the rpc_ACSendMessageEx ([MS-MQMP] section 3.1.5.2) method of the qmcomm2 interface, providing a ptb input parameter initialized with the XACTUOW structure created at step 4.

  7. The intermediary server Queue Manager stores the response message in its outgoing queue.

  8. The intermediary server Queue Manager generates a Send User Message Event to send a response message to the Queue Manager on the agent’s server.

  9. The sales program application receives the message from the Queue Manager on the agent’s server by invoking the rpc_ACReceiveMessageEx ([MS-MQMP] section 3.1.5.3) method of the qmcomm2 interface, providing a ptb input parameter initialized with the XACTUOW structure created at step 2.

  10. The sales program application processes the received message to get the analysis result.