none
How do you set up distributed message queuing?

    Question

  • I have written a VB.NET application that automatically creates AD accounts for college students directly from the college MIS system.

    The (simplified) process is this, a student record created in the MIS DB (SQL) triggers an XML  message to be created in a SQL Service Broker Queue on the MIS DB server(A).

    The SQL service broker sends the message across the network to another SQL Service Broker Queue on another server(B).

    Server(B) processes the message and creates the user account in AD along with email and all the other good stuff.

    I would like to replace the SQL Service Broker messaging with MSMQ messaging......(Gasp.. is he mad?)

    The reason is that whilst the SQL Service Broker works perfectly and is ideal for this, it relies on SQL being at both ends of the system, it is rather messy to set up and is a bit of an overkill for this simple app.

    I have searched the net for ideas and examples of how you would go about actually setting up and configuring the queues on servers at both ends and get messages to transfer between them and whilst I see plenty of info that leads me to believe what I want to do is possible, I do not yet understand how to connect the two queues together and get them to transfer messages.

    Can someone either explain to me how to get say a public queue(Q1) on server(a) to transfer a message to say a public queue(Q2) on server(b), or point me to some documentation that will explain this (in simple terms).  I have read docs that refer to redirection XML files in say Windows\System32\MSMQ\Mapping is this how it is done? or is there some other configuration options I am missing somewhere.

    We have AD 2008. Server(a) and server(b) are in the same AD site but in different AD domains, each server in a member server in its domain.

    The message transfer only needs to go one way from Server(a) to Server(b).

     

    Thanks All

     


    Dave.
    Friday, June 10, 2011 11:25 AM

Answers

  • The docs that come with the product should cover the basics really well.

    Nothing wrong with swapping Service Broker for MSMQ, or vice versa. You pick the best product for the environment and tasks involved.

    You need to write two applications - one to create and send messages; the other to receive them.

    App one sends a message to the remote queue (actually delivered by the local queue manager to the remote queue manager).

    App two polls the queue for incoming messages although it may be easier to use the MSMQ Triggers service to monitor the queue for you,

    Both ends need MSMQ installed.

    You do not have a persistent queue on each machine and move messages between them.

    Instead you have a temporary outgoing queue on the server and a permanent queue on the destination machine.

    You do not need public queues - private queues are fine in most cases. If you use private queues, you don't need to worry about AD.

    The docs that talk about redirection XML files are for when you send MSMQ messages over the HTTP protocol to a website that is not the final destination machine.

    Cheers

    John Breakwell




    • Marked as answer by Dave Rob Monday, June 13, 2011 8:29 AM
    Saturday, June 11, 2011 9:15 PM

All replies

  • The docs that come with the product should cover the basics really well.

    Nothing wrong with swapping Service Broker for MSMQ, or vice versa. You pick the best product for the environment and tasks involved.

    You need to write two applications - one to create and send messages; the other to receive them.

    App one sends a message to the remote queue (actually delivered by the local queue manager to the remote queue manager).

    App two polls the queue for incoming messages although it may be easier to use the MSMQ Triggers service to monitor the queue for you,

    Both ends need MSMQ installed.

    You do not have a persistent queue on each machine and move messages between them.

    Instead you have a temporary outgoing queue on the server and a permanent queue on the destination machine.

    You do not need public queues - private queues are fine in most cases. If you use private queues, you don't need to worry about AD.

    The docs that talk about redirection XML files are for when you send MSMQ messages over the HTTP protocol to a website that is not the final destination machine.

    Cheers

    John Breakwell




    • Marked as answer by Dave Rob Monday, June 13, 2011 8:29 AM
    Saturday, June 11, 2011 9:15 PM
  • John,

    Thanks for the swift reply and your advice has certainly pointed in me the right directon.  It all makes a lot more sense to me now.

    I have been developing the Proof of Concept for this in isolation on my Dev machine before I move it into a test LAN environment for field trials.

    I have developed a small .NET SQL CLR assembly that will fire a message into a MSMQ of my choice via a SQL trigger and a small MSMQ listener that picks up the message and processes it from a target queue.

    All of this is running on a local queue on my dev machine.

    I have fired a message at a (disconnected) remote queue and seen the temporary queue created on my Dev machine but still had it in my head that MSMQ would be configured in a similar manner to the Service Broker, in that you would connect and route queues using defined and configured settings, and therefore missed the point completely, so thanks for clearing that up for me.

    I will try firing the message at a remote queue that is actually available this time and I guess that will allow everything to work as I expected it to.

    Thanks for the pointer regarding the use of local queues, again I hadn't picked up on that.  I should learn to read things properly and not just try and skim them for salient points ( should also learn to read what a dialog box actually says and not what I think it says - that would save me some heartache as well).

    Regards

    Dave

     

     


    Dave.
    Monday, June 13, 2011 8:29 AM
  • You will always get an outgoing queue for a remote destination, regardless of whether the remote machine is online or offline.

    This, for example, is to accommodate when the sending application can create messages faster than the local MSMQ queue manager can put them onto the wire.

    You don't get an outgoing queue when sending to a destination queue on the same machine as the sending application.

    Cheers

    John Breakwell

    Tuesday, June 14, 2011 8:13 PM