After a two-day period of intense hacking, I’ve got the basic architecture of a replacement for our messaging engine working in Service Broker. It’s fast, lock contention isn’t an issue, and I’m very hopeful that we can not only use Service Broker to replace our messaging engine, but also to reduce our dependence on external apps that poll the database for changes.
Service Broker is not particularly difficult to understand, but getting the syntax right can be tricky. I ran into several minor stumbling blocks, which I was luckily able to get over quickly:
- I did not specify the “no encryption” option on the conversations I opened, so initially messages weren’t being sent due to the fact that I didn’t have a master key set up for the database in question.
- My first cut at implementation used the “fire and forget” pattern, where the initiator terminates the conversation immediately after sending. This is a problem because if the far side needs to return error information to the initiator, it can’t, since the initiator has already jumped ship. The fix for this is to let the target terminate the conversation and to put a little activated stored procedure on the initiator side to handle any error responses.
After getting past these issues, it was smooth sailing. I expect to be able to implement the routing logic today, after which it will just be a matter of cleaning it up for inclusion in our software. We could potentially be running with it in about a week, at least in its 1.0 version, particularly if I go with straight text for the RPC messages rather than have to mess around with XML serialization. If I were using C# it would be a no-brainer to use XML, but the options available under C++/MFC are less than stellar.
