Provide Feedback on this Broadcast

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Rajan Dwivedi: Welcome, ladies and gentlemen. My name is Rajan Dwivedi, and today I will be presenting message queuing in BizTalk Server 2004. I work in Premier Services. So without any further delay, I will start today's session.

So let us quickly see what our agenda is today (slide 2). I will be introducing MSMQT, and then we'll look at some differences between MSMQT and MSMQ. Then we'll look at some configuration concepts. Then, last, I will go over some recommendations, FAQs, tips, and tricks about MSMQT when it comes to integration with BizTalk Server 2004.

For those of you who have come from different backgrounds or who have already played with MSMQ (slide 3), I would just like to cover some inherent benefits of MSMQ. As you know, today we are building a lot of applications that are distributed in nature. If we look at the distributed application reality, then it's very harsh, because we have applications, and that requires machines. Machines may be reliable or they may not be reliable.

We have networks, and some of the networks are up 100 percent of the time, and some of the networks are not online 100 percent of the time. Sometimes when a machines fails, a network fails, and our failure scenarios multiply. These failures can be expensive.

Mobile computing is another aspect of business that is becoming more important every day. So with that in mind, MSMQ can provide you a lot of benefits, like connectionless or offline capabilities. And when your workload needs to be prioritized, you can set the priority of the messages. You can have some delivery guarantees. You can have your transactional messages.

Apart from these benefits, you also get some other benefits, like routing, which is another major plus, as well as security, which is very tightly integrated with Microsoft Windows operating systems.

As a transport protocol, MSMQ is robust, and it offers you several features, including logging, auditing, and recovery of failure messages.

So when you implement MSMQ, you get these benefits. You can build applications that can run in different geographies and that can run in different time zones, and you can have instances where applications may not be online all the time.

So you may have seen typical implementation scenarios for message queuing, like a ticket sales scenario, or where any kind of publisher or subscriber implementation is required, like news, wire services, or financial data, or any kind of banking scenario or stock brokerage scenario.

Let's move to the next slide (slide 4). So what is MSMQT? We have seen and we have played with MSMQ in the past, and MSMQT is something new. This is the method of the BizTalk Server message queuing transport. MSMQT is the acronym that is used for describing the MSMQ adapter in BizTalk Server. The "T" in MSMQT stands for transactional.

MSMQT is shipped as a core internal component of the BizTalk Server product, and it is not available as a standalone product, like MSMQ. It is one of the many protocols that are available in BizTalk Server 2004. To start using MSMQT, you have to manually activate MSMQT first. It starts listening on two ports. By default, it is not activated, for security reasons. We don't want to leave any open doors or security holes. So that's why it is disabled by default.

How does it fit in the architecture of the BizTalk Server 2004? You will see a diagram on your screen (slide 5). This diagram is the high-level view. At the bottom, it has different adapters, and you will see that there are several ways of communicating with BizTalk Server 2004, like HTTP, SOAP, Web services, or FTP adapter. And MSMQT is one of them. So after you receive the message, or after you want to send the message, you have to use MSMQT as the adapter.

BizTalk Server can take the message. If the message is coming in through MSMQT, you can use a pipeline to decode the message or to decrypt the message, or check the signature or authentication of the messages. So after you perform certain operations, you can parse the message, and the message can be stored in the BizTalk MessageBox, which is the universal MessageBox.

Then there can be several subscriptions waiting for this message, like business processes or schedules. We call them orchestrations. They can consume the message. That's how MSMQT interacts with BizTalk Server. It is one of the opening gates that provides you the capability to send the message to the MessageBox, or to take out the message from the MessageBox.

There are some other blocks that are shown in this diagram that are related to the BizTalk Server architecture. On the right side, you will see that you get some benefits out of this architecture, like business activity monitoring (BAM), business intelligence, reporting, or message monitoring using the Health and Activity Monitoring Tool (HAT). On the left side you see some tools that are available within BizTalk Server, like the admin tool, deployment wizard, or Trading Partner Management.

With that, let's see why MSMQT is important and why we had to come up with the separate transport, apart from MSMQ, in BizTalk Server 2004 (slide 6).

As you know, BizTalk Server 2004 integrates applications that are distributed in nature, which are scattered. The messages may be coming from heterogeneous platforms. So MSMQT is one of the reliable transport handlers that is available in BizTalk Server 2004.

This is the only reliable transport that comes out of the box, without requiring any kind of plumbing. You can achieve the same thing through Web services or other protocols, but it will require some kind of report from your side.

So MSMQT is designed specifically to interact with internal components that are available in BizTalk Server 2004. This is based on the robust asynchronous protocol of the already available MSMQ infrastructure. So this is the protocol that MSMQT is implementing, and it is using MessageBox as a storage media.

As far as interaction between MSMQT and MSMQ is concerned, MSMQT can receive messages from MSMQ, and it can also send messages to MSMQ without any difference.

MSMQT can also work with other environments, like MQSeries, or any other environment where you need to have message-oriented middleware. So ultimately, as the bottom line, MSMQT does not replace MSMQ, but it is the efficient way to use MSMQ transport within the BizTalk Server 2004 environment.

So now let's see some differences between these two standards (slide 7). One of them is for BizTalk Server exclusively, and the other one is available through Windows operating systems. Both implement the MSMQ asynchronous transport protocol, and MSMQT is part of BizTalk Server 2004. But MSMQ is standalone product, and it can be used as a general-purpose component.

As you have already seen, MSMQT provides you integration with the message store, which is available in BizTalk Server 2004. MSMQ uses an on-disk proprietary database, which is based on memory-mapped files. And sometimes it's limited in its scale-out capabilities, and it is hard to manage. It has a quota, like 1.8 gigabytes (GB) on Windows operating systems.

But MSMQT is implemented on SQL Server™ 2000 storage. It has better scale out capabilities on multiple servers. And it acts as the central repository for all the user-specific data or application-specific data.

MSMQT does not have a message size limitation, whereas MSMQ has a 4-megabyte (MB) message size limitation. That's for MSMQ 3.0, which is available on the Windows Server™ 2003 operating system.

MSMQT does not require admin tools (slide 8). For MSMQ, you can go to computer management and track the content of the queues and what is available when the message arrives, like a date/time stamp. This is by design, because MSMQT is a virtual entity, and messages for MSMQT finally end up in the database.

If you have already seen some features of BizTalk Server 2004, you can recollect that the MessageBox database is strictly a publisher and subscriber model. As soon as the message goes in the database, it fulfills the subscription. It publishes the data to all the subscriptions that are waiting for the message, the message is removed from the MessageBox, and it is placed in the workQ.

So, unlike MSMQ, the messages are not kept in storage for a long period of time. They are there for some period of time, and then they are given to the subscriptions. If there are no subscriptions, then the message is removed, and it is put in the suspended queue. So that is why you don't require any admin tools, because you can track the message using HAT, which is the Health Activity Tracking tool, which is provided out of the box with BizTalk Server 2004.

So, the next question is how MSMQT works with the MSMQ infrastructure or MSMQ protocol. It supports the queues in its programming interfaces. So that means the same programming interfaces are available for MSMQT. You can send the message through the receive location, and remote servers cannot tell the difference between MSMQ and MSMQT servers.

In MSMQ, you don't send messages to a physical queue, but you send messages to the receive location. The receive location sends the message to the MessageBox, and hence the messages are given to the subscriptions. So that is a model of how MSMQT works, which is quite different from MSMQ.

Now, unlike MSMQ, MSMQT does not support any public queues (slide 9). You cannot receive messages into MSMQT as a public queue, because that is not a BizTalk scenario. All the queues in MSMQT are private queues, although MSMQT can send the message to any other public queue that exists in an infrastructure.

There are some other limitations and some fine-tuning required when it comes to a side-by-side installation of MSMQ and MSMQT. By default, if you have a single network card, and you have dynamic addresses, then MSMQ and MSMQT cannot be installed in the same box. There are certain scenarios where our partners and our customers want to install MSMQT and MSMQ side-by-side. They can install it using some specific configurations that are required for this installation.

So, if you're interested in a side-by-side installation of MSMQ and MSMQT, let's see, in the next slide (slide 10), how this can be done. This side-by-side installation is not one of the easiest installations. It requires some specific operating systems, like Windows Server 2003, Windows 2000 Server with Service Pack 4, or Windows XP with Service Pack 2. As stated, it will require you to have two network cards and two IP addresses, or you can have two static IP addresses on the same network adapter. So when you have two IP addresses on the same NIC card, you have to have the same subnet.

Now, after you have the two IP addresses for the machine, you can configure your DNS server, and you can remove the autoregistration. You can manually edit two IP addresses, and you can map them: one for the computer name and one for the BizTalk Server name.

Then you have to update some registries so that the listening ports for both services are different. And the registry settings are given on your slide. You also create MSMQTBindingIP, and you assign the IP address so that MSMQT should listen on a specific IP address, and MSMQ should listen on a separate IP address.

When it comes to communication between MSMQ and MSMQT on the same machine, they can talk to each other through MSMQ router. They use a specific format name, and direct format names are not supported when MSMQT and MSMQ want to talk to each other on the same machine.

There are several scenarios where our partners and customers are interested in configuration, specifically network load balancing or clustered services. In this case you can host MSMQ on one machine and let's say MSMQT on the other machine; or MSMQT can be on both machines. So you can have physical IP addresses for all the machines, and you will have virtual IP addresses for the entire cluster.

In this case, MSMQT can be replaced by the BizTalk Server group name; so let's say if you create a specific group for the BizTalk server, you can reference the MSMQT infrastructure with the BizTalk Server group name. So this is the typical configuration that you have to implement when you are using network load balancing and when there are multiple machines, which may be heterogeneous in nature, like MSMQ and MSMQT running on two or three separate machines inside a BizTalk Server group's environment.

Say you need to communicate to MSMQT; in this case you can use certain format names. On the slide (slide 12) I have listed direct operating system-level communication, or you can use the TCP protocol and reference the queue. If you are using messages for sending purposes, then you can use public or private monikers to send the message to the infrastructure.

Some of the other formats are not supported, like HTTP, because there is a separate adapter for that. And you can use those adapters to communicate to MSMQ through HTTP. MSMQ supports the HTTP protocol, and there is a specific, separate adapter for HTTP in BizTalk Server 2004.

Now, as I stated earlier, by default MSMQT is now activated, and you have to create this adapter. To create this adapter you have to use the BizTalk Server Administration console (slide 13). You can launch the Administration console and then click the list of adapters. Then right-click that adapter, and you can create a new adapter. You can select MSMQT as the transport protocol. That way it will allow you to create the MSMQT adapter. After you create this adapter, that will be available for you to use for reliable messaging.

To use MSMQT transport, you have to create a receive location (slide 14). To create a receive location, you have to choose a queue name. If you are relying on the Windows operating system for authentication or for security integration, then you can choose MSMQ authentication. This will allow you to make sure that messages are coming from specific users, that those users belong to a Windows domain, and that they are authenticated.

When you are creating a queue, you can also choose the transactional behavior, whether the messages are going to be transactional or non-transactional in nature. There is also the concept of a queue number. There are certain queue numbers that are reserved, like 1 through 16, and you can use a specific queue number for referencing your queues at the index.

So this is required when you want to receive the message in your MessageBox through receive locations. MSMQT is the underlying adapter for this kind of message.

Let's say you want to send the messages to MSMQ, or from MSMQT to some other location. You can use a destination queue (slide 15). And this destination queue can be a BizTalk messaging queue, or it can be a simple MSMQ queue. Similar to receive location, you can choose the MSMQ authentication mechanism. If the delivery order is important, then you can select the check box that allows you the guaranteed order of delivery.

So this property is read-only for all other transports that are available. As soon as you choose MSMQT, this becomes activated, and you can choose the order of delivery.

This is the send port that allows you to send the messages to some other ports, like MSMQ or MSMQT, within the BizTalk Server, in the same environment.

So now let's see some recommendations (slide 16) for new users when they are using MSMQT. Because it is quite different, compared to MSMQ. So by default, we're first using the default settings that are part of the initial configurations of BizTalk Server. If you want to use MSMQT, then you have to activate the MSMQT Transport.

For that, you have to make sure that you don't have MSMQ installed on the machine. If you have MSMQ installed, then you can disable it; or you can stop the services and start using MSMQT. Otherwise, you can use the side-by-side installation that we just covered in the previous slides.

When you are using network load balancing, in that case you have to use the BizTalk group name as the computer name, so that all the callers who are calling the machines that are participating in the same cluster can use the single name, which is the BizTalk Server group name, as the computer name.

When you register the server in the DNS, in that case computer names become editable, and you can change the computer name so that it can have a friendlier name.

Let's say when you want to integrate MSMQT with your Active Directory®. After you register your server in Active Directory, then you can select the router, so that the router should use MSMQT in the MSMQ forest. For side-by-side installations, auto-DNS registrations should be disabled, and you have to manually create the entries for each IP address that is required for the same machine, for using MSMQ and MSMQT in side-by-side mode.

So let's look at some misconceptions about MSMQT (slide 17). I've heard a lot of people saying that MSMQT is the future and it is going to replace MSMQ. Or sometimes people say that MSMQT is a new version of MSMQ. This is a misunderstanding. MSMQ is an integral part of Windows Server 2003, and it will be supported until 2010. Right now, our Indigo team owns it.

We recommend for you to use MSMQ if you are building your typical enterprise application integration (EAI) solutions. For that, MSMQ is a general-purpose component, and you can use it anywhere. It is provided as part of Windows operating systems.

Coming to the second misconception, people say that "I have MSMQT installed, and I'm using .NET System.Messaging APIs to send the messages, and I cannot send these messages to MSMQT, because I am receiving some run-time errors."

Just to clarify, System.Messaging APIs, COM APIs, or C++ APIs all require the MSMQ infrastructure or MSMQ installations. So that's why, after MSMQ is installed, MSMQT cannot work. These APIs have been created specifically or exclusively for MSMQ. So what you can do is send the message from MSMQ to MSMQT, like a remote queue from your machine.

The other misconception that a lot of people have is that MSMQT is no good because it does not provide an admin console. So, as I explained earlier, you cannot see messages in the MSMQT queue, because there are no physical queues, and queues in the MessageBox are virtual entities. Messages finally end up in a SQL Server database. And they are there for a very short period of time. As soon as the subscriptions are filled, the message is removed.

So unlike MSMQ, it does not have an admin console. MSMQ has physical queues, and these queues store the messages. These messages may move forward from one queue to another queue, or they may just sit there in outgoing queues. So if the machine comes online, it can send the message to the other queue, through the queue managers. So in MSMQT, you can track the messages in real-time by using HAT. That is the right place to track or monitor your messages.

There are some other facts that we should clarify before I move on (slide 18). MSMQT does not implement the components that allow you to remotely read a message, because that is not a BizTalk Server scenario. What you have to do is send a message to a local queue, and then BizTalk Server can consume the message from that point in time.

If your client runs on a different machine that has, let's say, MSMQ installed, or if that client wants to send a message to MSMQT, then you can use System.Messaging, COM components, or C++ APIs. Then they can send the messages by calling the queue and by using a send operation.

For MSMQ machines or MSMQ clients, there is no difference between any MSMQ queue that exists in MSMQ infrastructure or MSMQT, because both are exactly the same type of queue, from the API's perspective.

So let's say you want to send the message to a remote queue. In that case you can create a send adapter using MSMQ transport. And send ports can send the message to a remote queue.

Now I would recommend that you remember that an MSMQ queue is not a MessageBox. It's not a BizTalk MessageBox. And a BizTalk MessageBox is not an MSMQ queue. So, to describe it a little bit further, the MSMQ queue is a physical disk-based storage system, and MessageBox is for all the messages. It is universal storage for BizTalk Server 2004, which can store messages not only from MSMQT, but also from all the adapters or from all the gates that are sending messages to BizTalk Server 2004.

Another thing is that MSMQ is a transport. It is not a storage media. So it is a protocol that allows you to reliably send messages to different applications. It is message-oriented middleware, and it allows you to send the messages. Applications communicate through messages. They do not communicate directly. They communicate through queues.

Another thing is, and this can be a little bit awkward, after you add the MSMQT adapter, you cannot delete it and you cannot rename it. So just keep in mind, when you are activating the adapter, that you note which ports it is listening on. Typically it listens at TCP port 1801 and RPC 135 or 2101. In this case you know these ports are open, and you can deactivate the ports. You cannot delete the adapter, after it is added, in BizTalk Server 2004.

I received a lot of questions, during the early adopter program for BizTalk Server 2004, where a lot of developers wanted to send messages programmatically to MSMQT (slide 19). In this case what you can do is install MSMQ on the remote computer, because it is part of the Windows operating system. Then you can create your typical client, maybe in .NET or Visual Basic 6.0, using COM components. They can just refer the queue. They can refer the queue's location, like a typical MSMQ queue, and they can send it using MSMQ APIs. MSMQ APIs will be able to deliver it to the MSMQT receive location in BizTalk Server 2004.

There are some other ways to send the message to MSMQT. If you are not interested in sending it programmatically, or you want to send without installing MSMQ, then your program can drop a file to a receive location where BizTalk Server 2004 is monitoring for the messages. And then the receive location can be configured for another send port, for content-based routing. So the filters can be set up so that as soon as the message comes to a receive location, content-based routing (CBR) will send the message to the MSMQT port. And the MSMQT port can finally pick up the message, and it will route it to the MessageBox for the waiting subscriptions.

There are also some people who had some problems creating an MSMQT adapter. To elevate this issue, you have to ensure that you are a member of the admin group or are a Single Sign-On (SSO) admin. Single Sign On is another feature that is available in BizTalk Server 2004. So you have to make sure that you belong to that user group.

In some cases, when developers are writing client applications and they are communicating with MSMQT, they want to ensure that they are going to get ACKs or NACKs (slide 20), which are acknowledgements or negative acknowledgements, when they communicate with MSMQT. So MSMQT implements the same protocol. It implements the same APIs and the same calls for notifications.

So when there is any error — let's say you want to wait for the acknowledgement — then you can also get the acknowledgement. Similarly, if there is any kind of transmission failure, then MSMQT will fire a negative acknowledgement. You can use a typical try/catch block in your application to determine the outcome of the transmission.

In some cases, I've heard from our partners or customers that they've mistyped the MSMQT adapter name. They wanted to write to their MSMQT, but let's say they've typed something like MSMQX. Right now you cannot rename or delete the MSMQ adapter.

The adapter is marked as delete-protected. In this case, you have to be careful that you type it correctly, otherwise there is no way to rename it directly. There was a lot debate and argument over this, but there are some good reasons why you cannot rename the adapter after it is added.

I'm not sure if you've already played with the EAP builds, but there was a problem in the EAP builds, before the RTM builds. And we have solved the problem related to the large messages. When sending very large messages, not only 4 MB, but let's say 10 MB or 20 MB, we had some problems in the EAP builds. We had a lot of customer queries around that.

Just to clarify, we support tracking of the large messages. This problem has been fixed in the RTM build. The HAT was not able to check messages larger than a certain size when these messages were coming from MSMQT. So now that problem is fixed in the RTM builds.

Another question is, can you receive messages from a remote MSMQ queue (slide 21)? A remote read is never transactional, even in the MSMQ infrastructure. If you want to read a message remotely in a transactional manner, then there are certain tricks that are involved. The easiest way is to send a message in a transactional manner to a local private queue. Because remote send operations, in a transactional manner, are allowed by MSMQ. After the message is available in the local queues, you can read it in the transactional manner, using MSMQT APIs.

Another question is about integration with Active Directory, because in some enterprises you may have some sites — MSMQ forest or MSMQ infrastructure — already in place with Active Directory. So, MSMQT can also be integrated with Active Directory. For that, you have to create a computer object. Then you have to create some child objects for the permissions, and that will allow you to integrate MSMQT in the Active Directory.

So after you are integrated with Active Directory, like typical MSMQ, you will get all the benefits, like authentication, where if the queue requires messages coming from the authenticated users, or they are specifically signed, then the signatures can be verified from the certificate stored in Active Directory. Or you can get some routing benefits, because the cost of the routing can be calculated. The shortest path to send messages can be determined, whether the queue is an MSMQ queue or it is an MSMQT queue.

(Slide 22) So let's say you integrate with the MSMQ infrastructure or with Active Directory. In that case, there are several questions, like can you publish your MSMQT receive location in Active Directory? So this is typically required when you create a public queue, and this is supported for MSMQ. But MSMQT queues are all private queues.

Public queues are not a BizTalk scenario. So MSMQT does not support the creation of public queues. What you can do is send the message directly to the MessageBox, or you can send the message first to a local MSMQ queue, which can send the message back to the MSMQT queue. But just to summarize, MSMQT queues are always private queues.

Then there is another question about the MSMQT adapter, about using HTTP messaging. Right now, MSMQT does not support the MSMQ HTTP protocol. This is supported in MSMQ 3.0 and later versions for Windows operating systems. That can, in fact, be used by MSMQT. If you want to send a message to a message queue using HTTP as a protocol, then you can send it to a MSMQ 3.0 queue. And that queue can send a message to MSMQT in BizTalk Server 2004.

Another way to receive messages from the HTTP protocol is to use another adapter. You can use the SOAP adapter or the HTTP adapter as an alternative for BizTalk Server 2004.

Then there is a question of larger messages. As you know, MSMQ has a limitation on message size, because the messages were based on the memory mapped files. They were based on the file system. And the messages were divided into multiple files, like a single message was always stored in a single file. But the message from one queue may end up in four or five files. Similarly, messages from four or five queues may end up in a single file. So there was a limitation of 4-MB messages. But right now, if you consider the differences between MSMQT and MSMQ, you can recall that MSMQT implements SQL Server 2000 as storage. In this case, it does not have any kind of message size limitation. Using MSMQT, you can send messages of any size to BizTalk Server 2004.

Let's say MSMQ wants to send a message larger than 4 MB. In that case, BizTalk Server 2004 provides you a .dll that you can use on the machines to shrink, merge, or assemble the message based on the multiple messages in MSMQ infrastructure. This .dll is called Mqrtlarge.dll. You can send the messages from MSMQ to MSMQT, and vice versa, to handle the large-sized messages.

So, with that, I'm pretty much done. Just to give you highlights on some resources that are available: in early March 2004 we are going to release BizTalk Server 2004. We have already released the bits to manufacturing. We are going to have a large launch event in March.

If you are looking for resources (slide 23), then there is the beta site (http://www.microsoft.com/biztalk/beta/), where you can download the beta content. There are some public newsgroups (http://communities.microsoft.com/newsgroups/default.asp?icp=biztalk2004beta&slcid=us) for discussions. You can also get the airlift DVD, from December 2003 (https://msptr.com/PartnerTraining). This may be restricted to certain partners, but you can try it. You can check this DVD for some great content on BizTalk Server 2004.

Otto Cate: Thank you very much for the presentation. Before we jump into the Q&A, I'd like to share a couple of quick program notes with our listeners. For more information on future events, or to review any of our sessions on demand, feel free to visit our main Support WebCast site at support.microsoft.com/webcasts/. There you will be able to find the on-demand streaming media for this particular live session, within 24 hours. We also plan to have a full transcript posted there within three weeks.

We'd also like to ask for any feedback, as well, on the events that we produce — on the subjects that you'd like to see in the future, for instance. You can always submit the feedback through the Contact Us page at support.microsoft.com/servicedesks/webcasts/feedback.asp.

So with that, let's answer some of the questions that were submitted during the presentation. The first question is: What exactly is an MSMQ router?

Rajan: Good question. I am not sure if the person who has asked the question has ever installed the MSMQ infrastructure in their enterprise, but they are typically certain "flavors" of the installations that are available. The easiest one is independent client. That does not require any infrastructure. That means you can install MSMQ on your local machine. That way other applications can communicate with other queues.

So let's say you have an MSMQ server installed that requires the Active Directory, and you can have multiple MSMQ servers on your network. In that case there is a router required to route the messages. It calculates the cost of the message in terms of hops or in terms of site gates or links.

So you may have multiple sites and multiple MSMQ servers, and a lot of queues or queue managers in place. So what happens is this router helps you out in calculating the costs that you already established in terms of network bandwidth, the cost, and the expense. So it's a factor. In a network, costs and all these things are calculated using the MSMQ router, which is an Active Directory-based calculation.

Otto: Will an adapter for connecting to standard Windows MSMQ be created or released in the future?

Rajan: This is a good question. MSMQT was created exclusively for BizTalk Server 2004. It is to provide you a way or a mechanism to communicate with MSMQ queues. So I'm not sure of this question. With MSMQT, you can still communicate with any MSMQ that exists on your network, within your enterprise, or within your MSMQ sites. So that is still available using MSMQT adapter.

Similarly, other MSMQ machines can send the message to MSMQT. So there is no difference, as far as communication is concerned, between MSMQT versus MSMQ. There is no separate adapter required exclusively for just MSMQ. MSMQT takes care of interaction with MSMQ.

Otto: It looks like a related question here: Do you have the listing of other commercial products that are currently on the market that provide the capabilities of MSMQT or that essentially interface with it?

Rajan: I have not seen anything that provides this kind of activity, but we have many adapters that are coming for BizTalk Server, like adapters for BAN, FTP, MQSeries, and SAP. So for MSMQ, MSMQT is the adapter that is provided by Microsoft. There may be something down the line, but I'm not sure. As of now, I am not aware of any other third-party adapters.

Otto: Do ACKs and NACKs have to be explicitly programmed in the BizTalk 2004 orchestration, or does that occur behind the scenes?

Rajan: So what happens is, when you send the messages, let's say you have a client trying, or MSMQ by itself may be trying, to send a message to BizTalk Server 2004.

The problem can happen at multiple stages. The queue may be nonexistent, or let's say the problem is on the wire. Let's say the network goes out, or there are no subscribers, or messages line up in the queue, but still there are no subscribers.

So what happens is you can catch all of these problems in different stages. When you are sending the messages using your client, you can test it under a try/catch block. That is the part of the APIs that gives you the information, whether the transmission was successful or was not successful.

But let's say the message lines up correctly, but there are no subscriptions, and you have to check the message in the suspended queue. So you won't get programmatic acknowledgement immediately. For that, there is some kind of reconciliation that is required.

But for other issues — like the message queue is wrong, or let's say some problem occurs during the transmission, because of network issues — in that case, of course, you are going to get an acknowledgement or a negative acknowledgement.

Otto: Regarding third-party support, just a clarification: Do you happen to know if IBM's MQSeries can send messages or communicate directly to BizTalk?

Rajan: That's another good question. So right now, at Microsoft, we are going to provide an adapter for MQSeries. We are in the process of writing that adapter, and it is in beta stages right now. So, after BizTalk Server is available on the market, that adapter is going to come out one or two months later. That adapter will be available. So one way of communicating with MQSeries is by using the MQSeries adapter. Another way is by using the MSMQ infrastructure.

Let's say you have some Level 8 based gateways where MSMQ can communicate with MQSeries. Or you can use Host Integration Server, HIS. So there are multiple ways to communicate with MQSeries. But of course the best way, I think, for this kind of communication, would be to use the native adapter that is going to be available for BizTalk Server 2004.

Otto: The description of the partner version of BizTalk indicates that it is currently limited to one CPU. Does that mean that MSMQT and all of the elements of BizTalk must reside on the same machine? And does hyperthreading count as two CPUs?

Rajan: I think I will have to do some research on this question, because I cannot remember the exact licensing requirement. But I believe that with hyperthreading, if you have a single physical CPU, then it probably is counted as one CPU [Editor's note: See the follow-up answer]. BizTalk Server has to be installed on a single machine in that case.

But with BizTalk Server, apart from this question, just to clarify the configuration, you can delegate certain tasks of BizTalk Server, let's say orchestration, or receive locations, or pipelines on different machines. And they can act like a single distributed BizTalk Server group under the BizTalk Server hosts. That way you can achieve scalability. But I believe, in this situation, a single CPU means a single CPU on the machine. But I will come back later on for this question.

Follow-up answer: Everything must be on the same processor box. There are a couple exceptions that are called out explicitly in the EULA: client tools, development/administration/monitoring tools, and BAS may be installed separately. In addition, we allow one processor of the Single Sign-on Master Secret Server component to be installed on a separate box (for security purposes). Hyperthreaded processors show up as two logical processors, and are treated as two processors. BizTalk Server Partner Edition will affinitize to one logical processor. You can also download the FAQs from http://www.microsoft.com/biztalk/howtobuy/pricing.asp.

Otto: Next question: Will the .NET Framework acquire an API for MSMQT to perform the same functions as System.Messaging?

Rajan: If you want to use System.Messaging or any other MSMQ APIs that are available as part of COM or C++, those are exclusively for MSMQ APIs. Although MSMQT implements the same APIs, it does not have a physical queue, and it has substantial differences, compared to MSMQ. But those APIs can be used by MSMQ.

If your target is to read messages or to send messages, then those APIs can be used. MSMQ can send the message to MSMQT. But if you need to read the message, then those need to be in a side-by-side installation mode, so that you can use the API on the same machine. Because a remote read operation is not allowed by MSMQT.

Otto: Can you elaborate on the message transport and data security capabilities in MSMQT? For instance, encryption?

Rajan: This is another good question. There are multiple ways to handle security. If you are looking exclusively at MSMQT, you can encrypt the message. The message can be decrypted. You can even sign the message with your digital signature. That digital signature can be verified. If you are using a Windows operating system, then it can also integrate with NTFS security or Windows-based user groups or user roles.

So it can work with Windows security, and it can work with the digital signatures. You may need to verify your messages. Or let's say the messages are encrypted with the special algorithm, then you will need to decrypt your messages in the pipeline stages. But, yes, messages can be encrypted and they can be authenticated. Or they can be digitally signed.

Otto: Can Mqrtlarge.dll be used for MSMQ-to-MSMQ messaging for messages that are larger than 4 MB, instead of using MSMQ to MSMQT?

Rajan: To get this component, you have to have BizTalk Server 2004. That .dll is available, and it is up to you how you want to use it. I have not seen any restrictions. And I have not even seen people using it in this scenario. But if it helps you out in MSMQ-to-MSMQ communication versus MSMQ-to-MSMQT, or vice versa, then you should use it. I have not seen any restrictions in that area.

Otto: When setting the values in the service window for MSMQT RetryCount and RetryInterval, they don't seem to work. Do these values perhaps not apply to MSMQT?

Rajan: I'm not sure of the context of this message. I'm not sure if this person can elaborate a little bit further. But in general, when you create your receive locations or send out a port, in that case you can specify a primary protocol, and you can also specify a secondary protocol. You can specify a number of counts there: if the primary fails, let's say, two times or three times, then you can use the second one.

MSMQT is a reliable transport. Let's say the message comes and it fails — I have not checked this personally. I'm not sure if the person has used it in the past, before the RTM builds or RC builds, but that should work for any other ports or receive locations, irrespective of the type of transport, whether it is MSMQT, file, or FTP. After a number of tries, if that fails, then you can choose a backup transport mechanism to consume the message or to send the message.

Otto: Regarding network load balancing, our network team does not support this, because of the requirements for a hub. We're wondering if there are any alternatives to network load balancing?

Rajan: So, let's say you're exclusively looking for network load balancing with MSMQT; in that case, you can have different computers. And you can activate MSMQT on specific machines. You can have, let's say, MSMQ activated on the other machines, if your purpose is to communicate to both of them and use both of them in a network load balancing solution.

The key, as I described earlier, is you have to have a BizTalk Server group name to reference your MSMQT infrastructure. If you are using the side-by-side installation mode, in that case your virtual IP address and BizTalk Server's group name should be referred for MSMQT. For MSMQ infrastructure, you have to use your computer name, which is your machine name for the different IP address.

Otto: It looks like that was the final question, so I'm going to wrap up the session here.

I wanted to thank Rajan for coming out and giving us a great presentation, and rolling through the Q&A with us. As always, I'd like to thank you, our listeners, for coming out and joining the event. We certainly hope that this information was useful to you and your business. And we look forward to seeing everyone again in the near future.

Thank you, and have a great day.