In the beginning there were no adapters. In BizTalk 2000 and 2002 they were called AICs – Application Integration Component. MSMQ AIC for BizTalk 2002 used MSMQ API from Windows Message Queuing and that was it. Windows Message Queuing was doing the network related job and it also stored intermediately messages in MSMQ queues on the machine before they were read by MSMQ AIC of BizTalk or sent to the world over the network.
It was simple and straightforward, but it had a few problems on its own:
These and few other reasons were considered when making the decision to create MSMQ/T Adapter for BizTalk 2004. MSMQ/T Adapter is a full implementation of MSMQ Server that lives in BizTalk. When BizTalk 2004 starts, it also starts a subprocess that listens to port 1801, the port for MSMQ protocol. MSMQ/T adapter is based on Windows Message Queuing server 2.0 and it is actually done by the same people who implemented Message Queuing in Windows.
Now a lot of things become much nicer:
MSMQ/T also had a few limitations:
· It was based on 2.0 code and hence it did not had most of the 3.0 features, including message queuing over HTTP and few others. When MSMQ/T work had started, MSMQ 3.0 code base was simply not yet developed.
· It implemented only transactional, exactly-once-in-order (EOIO) delivery. The thinking was more or less along the lines, “If a user does not need transactional, why does he need message queuing?”
· No remote read from MSMQ/T “queues”. The reason was that while BizTalk receive locations played the role of a logical MSMQ queue, there was no physical queues in MSMQ/T. Once the message was received, it was at the same time in the same transaction routed to destinations, hence BizTalk “queues” were by definition always empty.
The advantages of MSMQ/T had their trade offs:
As already mentioned, a serious advantage of MSMQ/T was the ability to pass large messages. However, while passing large messages between two BizTalk machines was an attractive feature, it did not looked like a really huge winner. What would be great is passing large messages between BizTalk and MSMQ applications.
The problem was solved by providing MQRTLarge.dll that exposed an API similar to regular MSMQ and allowed regular MSMQ applications to send/receive large messages to communicate with BizTalk.
MQRTLarge.dll was supposed to be dropped on a non-BizTalk machine and used by MSMQ applications, and hence it is located in BizTalk 2004 SDK utilities. Because the API was slightly different to accommodate for large messages, the users had to update the MSMQ application code and rebuild it to take advantage of this feature, but other than that it was really nice. It still is.
The only deficiency of MQRTLarge.dll is that it accumulates the whole message in memory and hence available memory was an effective limit of how large message you can pass with it. We were able to pass messages up to 2Gb in size, but it required a good machine. Also, if two applications would send large messages at the same time, their memory demands will combine, which was another problem. But anyway, to have this problem we talk about really large messages several hundred megabytes in size. Most users, we know of, needed to push 4Mb limit of MSMQ just a little to 5-20 Mb, and so they never noticed this problem.
BizTalk 2004 SDK also contained an MSMQ/C adapter sample that used standard Windows Message Queuing just like MSMQ AIC for BizTalk 2002. It was just a sample with limited functionality, it was never tested extensively for performance, stress or load, and it never was supposed to be used in the production environment, although we’ve heard of customers who did that. Again, it was just a sample.
Late in BizTalk 2004 development cycle we realized that customers will also need a traditional MSMQ adapter, and so we started to build it. At this time it was already customary to refer to “the other MSMQ adapter” as MSMQ/C, that’s why this adapter also sometimes informally called MSMQ/C Adapter. I actually did that in this blog before. However, it is not the same thing as the sample. We’ve put roughly a year of development and extensive testing into creating it.
MSMQ Adapter for BizTalk is available as a free download from Microsoft.com Download Center.
It has roughly the same advantages and the same problems as MSMQ AIC for BizTalk 2002, but provides richer functionality. In particular, it supports large messages using MQRTLarge.dll. The 2Gb message mentioned above was successfully passed through MQRTLarge.dll when testing MSMQ Adapter. The adapter has the same limitations as MQRTLarge.dll, and to avoid processing of two large messages at the same time, there is a “Serial Processing” flag on MSMQ port properties.
MSMQ Adapter is the recommended way to use MSMQ transport with BizTalk.
Here are some advantages of MSMQ Adapter over MSMQ/T:
Things you need to keep in mind when selecting MSMQ Adapter for your project:
In BizTalk 2006, MSMQ Adapter is the main recommended way to handle MSMQ transport. BizTalk 2006 supports NT cluster, hence there is a solution for high availability. Also, in BizTalk 2006 you can setup MSMQ port for the end-to-end ordered delivery (you need to set correctly MSMQ port, MSMQ queue, and the receiving application/send port).
MSMQ/T adapter is deprecated in BizTalk 2006. It means that it is still there and fully supported, but it’s a warning that it may disappear in the next version of BizTalk beyond BizTalk 2006. So, it may be not a good idea to consider it for new projects, unless you have a really strong reason.
MQRTLarge becomes a part of MSMQ Adapter and hence supported the same way as the adapter itself. Notice, that although you technically can make two MSMQ applications exchange large messages, the only officially supported scenarios are where one or both communicating sides are BizTalk MSMQ or MSMQ/T Adapters.