Further notes on the subscription issue - the more I read on the newsgroups, the more I appreciate how important the pub-sub model underlying BTS is to understanding problems with messaging.
I spent a day with some developers just starting out with BTS last week, and I found that showing the SubscriptionViewer application whilst enlisting and unenlisting orchestrations and send ports was invaluable in attempting to explain BizTalk's murky interior.
This is an extract from a recent posting to a query about messages being suspended (unresumable) when the matching CBR send port is unenlisted, and why they won't resume when the port is re-enlisted.
(Ok, so it's my own answer, but if I can't quote myself on my own blog, where can I?)
"The subscription required for the message to be processed is created when the [send] port is enlisted. When the receive location picks up the message, it is delivered to the messagebox, where the message agent runs through the subscription table to see if there are any services subscribing to the message.
If not, it is marked as suspended (unresumable). If there is a subscriber, but it is stopped, then the messages is suspended (resumable.) Restart the send port, and the message should clear.
If the send port was not enlisted, then there will have been no available subscriber for the message when it arrived, so BizTalk cannot process it. It is actually quite logical to suspend these messages and terminate the pipeline, as the alternative would require BizTalk to save every single message it ever received, on the premise that someone might at some point want to subscribe to it.
It's a bit like TiVo - you can pause live tv, but you can't go back to a show that was on last week if you didn't record it!"