Motley Queüe

Queue names for WAS hosted WCF service

2010-04-10T01:13:00Z

On WCF forums, I have noticed a common issue that developers face when hosting their WCF service in WAS. The issue is that the service does not get activated. Often, the reason is that the queue name does not match the service endpoint name. This msdn article talks about this behavior. In a nutshell “It's important to note that the activation of MSMQ endpoints only works correctly if the queue has the same name as the .svc file (minus the machine name). That means that if your service endpoint is /server/app/service.svc, the queue name must be app/service.svc.” This is a pre-requisite for using WAS for hosting WCF services that interact with MSMQ.

Performance optimization when using MSMQ with WCF

2010-04-03T04:06:00Z

There are a number of factors that can affect the performance of your enterprise application that uses MSMQ with WCF. Nicholas Allen discusses some of these design decisions in his Optimizing MSMQ article.

Another good reference is Best Practices for Queued Communication. This article also talks about how you can use WCF and MSMQ to implement the Request-Reply enterprise messaging pattern.

Checklist for using MsmqIntegrationBinding

2010-03-31T19:58:00Z

The MsmqIntegrationBinding allows users to create WCF applications that send and receive messages to and from existing MSMQ applications that use System.Messaging or other MSMQ APIs.

The operation contract should be one-way i.e. IsOneWay = true.
Action property should be specified in the operation contract to indicate a service operation handles all messages that the service receives but cannot be directed to a service operation i.e. Action="*".
The service operation should take a single argument MsmqMessage<T>, where T is a serializable type. You can use the [Serializable] attribute in front of the class definition or use a WCF data contract.
Type T should be specified using the ServiceKnownType attribute on the service contract e.g. [ServiceKnownType(typeof(PurchaseOrder))].

[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]
[ServiceKnownType(typeof(PurchaseOrder))]
public interface IOrderProcessor
{
[OperationContract(IsOneWay = true, Action = "*")]
void SubmitPurchaseOrder(MsmqMessage<PurchaseOrder> msg);
}

A double negative System.Messaging exception

2010-03-23T07:35:00Z

Message message = new Message();
message.CorrelationId = Guid.NewGuid().ToString();

The above code snippet compiles but when you execute it, you get a System.InvalidOperationException with an ambiguous message:
"Identifier is not in the incorrect format."

There is a typo in the exception above and it should actually say:
"Identifier is not in the CORRECT format."

The InvalidOperationException is thrown because the CorrelationId property cannot be assigned just any string. It takes a string value in a specific format, the same as that of the Id property of System.Messaging.Message. The following code executes successfully.

        Message message1 = new Message();
        Message message2 = new Message();
        message1.CorrelationId = message2.Id;

Dealing with PRIVATE= formatnames

2010-03-20T18:20:00Z

If your MSMQ environment has AD Integration installed, you can use PUBLIC= formatnames for public queues and PRIVATE= formatnames for private queues. PUBLIC= formatnames are pretty easy to work with: if you know the path of the queue, you can get or construct a PUBLIC= formatname, and if you have a PUBLIC= formatname, you can get the path of the queue.

PRIVATE= formatnames aren't so easy. You can't construct a PRIVATE= formatname, the way you can a PUBLIC= formatname. The syntax of the formatname is PRIVATE=qmguid\queueID. You can get the qmguid, which identifies the queue manager hosting the queue, but the queueID is a number internal to the queue manager, and the only way to get it is by extracting it from a PRIVATE= formatname. It is not exposed as a queue property.

So, if you have the path to a private queue and you want a PRIVATE= formatname, what can you do? If it's a local queue, you can pass the path to MQPathNameToFormatName and it should return a PRIVATE= formatname. If it's not a local queue, you're out of luck. I was actually bitten by this while writing a test, and the only solution I found was to write a a little program which runs on the remote machine, performs the MQPathNameToFormatName call, and saves the result somewhere where the rest of the test can get at it!

It's a little easier if you have a PRIVATE= formatname and want to get the path of the queue. Start out by calling MQGetQueueProperties with the formatname and retrieving the PROPID_Q_PATHNAME property. If it's a local queue, you're done; if not, you'll get an error back and it gets complicated. First, you have to figure out what machine the queue is on! You can extract the qmguid from the formatname and pass it to MQGetMachineProperties, retrieving the PROPID_QM_PATHNAME property, which gives you the name of the remote computer. That gives you one of the inputs required for MQMgmtGetInfo, and the other one is QUEUE=formatname. Call MQMgmtGetInfo to retrieve the PROPID_MGMT_QUEUE_PATHNAME, and if the queue is "active", you'll have the path.

Configuring a Remote WAS-hosted Queue

2010-03-13T01:49:00Z

Creating a reliable service for MSMQ has been made simpler with the introduction of Windows Process Activation Service (WAS). Your deployment scenario may make it easier to have WAS running on a separate machine from where the MSMQ queue of interest is located. This post will go through the steps to get a simple sample running under these circumstances. We will be assuming setup through the IIS manager GUI for the instructions.

Here are the steps:

1. Create a queue on the ‘remote’ machine.

2. Create (or edit) a site in WAS to use for your application on the ‘server’ machine. Each site can only read queues from one logical machine.

3. Bring up the ‘Edit Bindings’ dialog for the site. Add (or edit) the net.msmq or msmq.formatname entry, setting the ‘Binding Information’ field to the name of the computer that will host the queue. For locally hosted queues, this field is usually set to ‘localhost’.

4. Create your application as you normally would – add your code, service file etc. Ensure that the NetMsmqBinding or MsmqIntegrationBinding that is being used for your service has the address of the remote queue (e.g. “net.msmq://remote-machine/private/myapplication/myservice.svc”).

5. Go to the Advanced Settings of your application. Under ‘Behavior’, edit the Enabled Protocols field to add in your MSMQ protocol of choice (comma separated, e.g. “http,net.msmq”).

6. Ensure that MSMQ is allowed through your firewall on both machines. If you’re using transactions, ensure that Distributed Transaction Coordinator (MSDTC) is also allowed through the firewall.

6a. If you’re using transactions, you’ll need to allow network access for MSDTC on both machines. If you run the command ‘dcomcnfg’, then go ‘Component Services’ -> ‘Computers’ -> ‘My Computer’ -> ‘Distributed Transaction Controller’ -> ‘Local DTC’ -> ‘Properties’ -> ‘Security’ tab, there are appropriate settings there.

7. By default, both the application pools and the listener service (called “Net.Msmq Listener Adapter” in the services pane) run under the ‘Network Service’ account. Both of these applications require access to the queue, so ensure that the appropriate users are given access to read from the queue.

This should be enough to get your application running. If you’re anything like me, sometimes it doesn’t ‘just work’. So here’s some simple troubleshooting steps to point you in the right direction:

· From an elevated command prompt, restart the listener adapter by using the commands ‘net stop netmsmqactivator’ and ‘net start netmsmqactivator’. It can take up to ten minutes for WAS to detect changes in queues, so this should force WAS to recheck the queues.

· Enable metadata exchange for your service. This involves enabling HTTP in the ‘Enabled Protocols’ of your site, and adding the following text to your config file (merging with existing sections, where necessary):

<system.serviceModel>

</behavior>

</serviceBehaviors>

</behaviors>

</system.serviceModel>

Ensure that the behavior “MyBehavior” gets added to the <service> tag as ‘behaviorConfiguration=”MyBehavior”’. Now browse to your service file. This can be done by finding the service file in the IIS manager view and clicking ‘Browse’. If the metadata doesn’t come up successfully (so you get a HTTP error or an exception), there is a problem with your service that you’ll need to resolve first.

· Try to give the accounts ‘Everyone’ and ‘Anonymous’ full control of your queue. If the service begins working, it is probably a security issue.

· Try to disable your firewall on both machines. If it begins working at this point, the exceptions in your firewall are not correctly configured.

--Nathan Healey

Queue Matching Behavior in WAS

2010-02-24T03:40:00Z

With the release of Windows Vista (and subsequently Windows Server 2008), a new way to host WCF services was introduced: Windows Process Application Service (WAS). Services that use MSMQ now have the option of being hosted in WAS. One of the most frequently asked questions relates to matching the service file (*.svc file) with the queue that needs to be monitored. This article explains most of the behavior, but this blog post aims to clarify some of the subtleties.

The queue is matched using two criteria: the virtual directory and the service file name. The virtual directory is the directory structure below the ‘wwwroot’ folder in the IIS directory. For example, if the path for a service file is ‘C:\inetpub\wwwroot\MyServices\ExampleService\ExampleService.svc’, the virtual directory is ‘MyServices/ExampleService/’. The service file name is the full name of the file, including the .svc extension. In this trivial example, the matching queue could be named ‘MyServices/ExampleService/ExampleService.svc’.

A complication arises when WAS discovers a service file in a virtual directory, whereby it considers all queues in that same virtual directory to be related to a service. If, in the previous example, there was a second queue named ‘MyServices/ExampleService/AnotherService’, this would cause an error. This queue can’t possibly match a service file (due to the lack of .svc extension), but is in an application virtual directory that has a service. This seems an unlikely scenario – any other virtual directory (or none at all) in the name of the queue would avoid this altogether.

This behavior may become problematic when you consider the root application – when the service file is placed directly into the wwwroot folder. The queue name now only has to match the service file name, as no virtual directory is appended. For example, a service file in ‘C:\inetpub\wwwroot\NewExampleService.svc’ would match a queue named ‘NewExampleService.svc’. WAS now considers the root virtual directory to contain a service. Any queue present on the machine that does not contain a forward slash (‘/’) and doesn’t match a service file will cause an error in WAS!

Queues that are not used by WAS rarely contain forward slash characters. It is important to consider this scenario when designing your system. Avoid placing services directly into the root directory, if possible. Only do so if the system will only ever have queues that are associated with WAS hosted services.

--Nathan Healey

WAS hosting on Windows 7

2010-01-20T09:03:00Z

IIS 7 allows isolation of web application pools from each other by providing the ability to run application pools as separate identities. The identity of an application pool is the name of the service account under which the application pool's worker process runs. Running an application pool under an account that has high-level user rights is a serious security risk. The application pools run under an unique account without having to create and manage domain or local accounts. The name of the application pool account corresponds to the name of the application pool. The ApplicationPoolIdentity can also be used as the account for Anonymous Authentication.

Application pools in IIS 7 run as "NetworkService" by default. NetworkService is a built-in Windows identity. In Windows 7 (IIS 7.5), the default identity of an IIS application pool is "ApplicationPoolIdentity". When WAS hosting your WCF service using NetMsmqBinding or MsmqIntegrationBinding, remember to grant "Receive Message" permission to "IIS APPPOOL\DefaultAppPool" on the MSMQ queue that the service is listening on. Here "IIS APPPOOL\DefaultAppPool" is nothing but "IIS APPPOOL\<name of the application pool on which your application is deployed>". Depending on your application, you may also need to configure the application pool to load the user profile by setting the "LoadUserProfile" setting to "true".

MSMQ and the Windows Firewall

2009-06-16T01:28:00Z

I was called on to assist recently in diagnosing why an MSMQ client was unable to send messages to a queue on a server. One of the things the owner of the machines did was take a network trace on the client of the connection attempt, and what I saw there sent me down the wrong path for a while due to the way MSMQ interacts with the Windows Firewall. To save everyone else the trouble, I thought I'd discuss how the MSMQ installation sets up the firewall to work with MSMQ and why I went astray.

The application in question was using MSMQ's native protocol, so the client was attempting to make a TCP connection to port 1801 on the server. When the client sends the first packet to start the connection process, one of three things will usually happen:

The server receives the packet, and a process (MSMQ's Queue Manager) is listening on port 1801, so the server sends a reply which continues the connection process.
The server receives the packet but no process is listening on port 1801, so the server sends a reply which aborts the connection process.
The server doesn't receive the packet, so there is no reply. The client tries a couple more times, then the connection process times out.

When I looked at the network trace, I could see the client making multiple attempts to start a connection to port 1801 on the server, and the server was not sending back any replies to those attempts, indicating that the network stack on the server wasn't receiving the packets at all. The client had no problem making other kinds of connections to the server, so we knew that the server's networking in general was OK. Selective deafness like that is usually the result of firewall problems, so we briefly went on a wild goose chase looking at the MSMQ-related firewall rules, only to find that they were present and enabled, just as they should be.

Here's the critical bit: when we think of firewalls, we normally think of opening ports, but that is not how the MSMQ installer sets up the firewall rules for MSMQ. Instead, it "whitelists" the mqsvc.exe process for certain network protocols, meaning that (for example) any TCP port which mqsvc.exe opens to listen on causes the firewall to automatically allow packets to that port. This approach was taken because the ports MSMQ uses aren't 100% fixed. This is particularly true of the ports it uses for RPC: MSMQ will automatically use alternate ports if its first-choice defaults are already in use. Other ports can be changed by the use of registry keys. By using these whitelist firewall rules, the firewall automatically adapts to whatever ports MSMQ uses, minimizing surprises and complexity.

The breakthrough in our diagnosing came when we discovered that MSMQ wasn't listening on port 1801, or any of its other usual ports, which quickly led us to discover that it had been inadvertently configured in hardened mode, in which it will only accept messages via HTTP. Since it wasn't listening on port 1801, the firewall wasn't allowing packets to that port, giving the appearance of a firewall problem even though it was doing exactly what we'd asked it to do.

The moral of the story is that, because of the way the MSMQ firewall rules are set up, what appears to be a firewall problem can be a symptom of issues elsewhere. Before you spend too much time staring at the firewall, check that MSMQ is listening on the expected address and port combinations.

JMS and MSMQ interoperability

2009-06-08T10:02:00Z

I have come across this question of whether JMS and MSMQ are interoperabe a number of times and so I decided to address it. Microsoft does not have a JMS provider for MSMQ so basically you will need to use a third party product or implement your own JMS provider.

I came across an interesting article called Enterprise Messaging in a Heterogeneous Environment. The article describes how to use web services as a proxy between MSMQ and a JMS implementation. The solution effectively implements a custom enterprise message bus using which heterogenous applications (.net and java) can communicate asynchronously with each other.

Another way of accessing MSMQ from Java applications is to use JNI (Java Native Interface) as described here. JNI can be used to call the C api that MSMQ exposes, from within Java applications.

MSDN also has some pointers on implementing asynchronous interoperability.