MSMQ and SOA Conference RFID
I like queues. I used them first in 1997 for a electronic commerce project in the UK. I created a mini message pump that would read and forward messages in both directions. The service operated on multiple queues in pairs - kind of like a in and out tray.
This week Mick Badran and I were creating the RFID demo. We picked up Gen 2 tags thanks to UMD on Friday and thanks to equipment from Intermec we managed to read, write and process RFID tag information via rules and a simple business process. No mean feat I can assure you. We can safely say that doing this again would be less problematic but the sheer challenge of manually writing 200+ tags in 1 day and testing them was stressful.
So queuing, the last hurdle of our journey. I'd written a nice XAML application using the Expression Designer that would animate buttons (as bubbles) bouncing around the screen with identification information. It took the id from the liable and body of messages on the queue as some periodic interval.
In our demo the queue was local and the writer was a remote server (over adhoc wireless) . The remote server was reading information send (over adhoc wireless) from a remote handheld mobile. The remote handheld mobile device communicated via a "light pipe" to the gun like RFID reader (with trigger). My machine is running Vista therefore the firewall is pretty strict around what is allowed over MSMQ and as MSMQ communicates (by default) over TCP 1801 various rules have to be set so the outgoing queues talk to each other. We found that writing from the Vista machine to the Windows 2003 Server would trigger the outgoing queue pairs once the firewall rules had been laxed for queuing.
So demo went well, but our presentation, whilst covering all the bases could have been slicker. More from RFID later. Here are the links I used for MSMQ diagnosis:
Tool for analysis:
https://www.geekproject.com/tools.aspx
When MSMQ transfers outgoing messages from your machine to a remote destination machine, the following happens:
· As soon as you send a message to a remote queue, for example, by specifying a format name such as "DIRECT=OS:remotehostname/private$/queuename," MSMQ will create a so-called "outgoing queue" on the sender's machine.
· All messages that your client application sends to the remote queue will first be stored in this outgoing queue. Your client application never directly communicates with the remote server; it only talks to the local MSMQ instance running on your client machine. This allows for completely asynchronous decoupling, which is one of the great benefits of using MSMQ: your client can send messages whether the server is running or not.
· MSMQ will then contact the remote server and will transfer the messages using an optimized internal protocol.
https://download.microsoft.com/download/3/d/8/3d89f9e8-1c1b-4a8b-8c9d-1322c1728d45/MSMQB2B.doc
The firewall hint we found in the following answer
https://www.codeproject.com/dotnet/msmqpart2.asp
To send message to the remote machine, the TCP/IP port should not be blocked in the targeted machine. So first open the port and use the same code. It will work.
And from MSDN:
Default value is 1801.
Machine TCP/IP port that MSMQ is monitoring. This port is set to 1801 by the registration utility.
Do not change the port setting.