对于触发器，sql server 中的这个概念应该用的最多，很多人担心性能太差，而不予采用。

而 msmq 中的trigger 则相反，比自己写代码轮询一个queue 中的消息，则方便很多。

适合的场景：

各种各样的客户端通过调用web service 或者remoting， 提交定单信息。服务端将这些消息发送到对应的各个队列中。

后台的应用程序监视队列，retrieve 队列中的消息，做处理。

只所以采用队列，而不是采用一个文件或者数据库作为缓冲，主要考虑以下因素：
1。msmq 其实是一种reliable messaging。所以很多soa 应用中，都会提到用queue 作为一个中间件
2。msmq 本质上是异步的
3。msmq 也提供了transactional messaging ，这个跟sql 2005总的 service broker 很想。

对于上面提到的后台程序，一种方式是用一个windows 服务，轮询队列中的消息，read 然后处理。

另外一种方式就是使用msmq 3.0提供的trigger。
在消息队列的管理界面，管理人员可以创建规则（比如monitor什么样的消息，优先级，label等），监视那个队列的名称。

这样一旦有消息来的时候，后台的msmq trigger 服务就会把这个消息传递给你指定的com或者exe。如果是com，会自动的实例化一个类，调用你指定的方法，然后destroy。这里有几点需要注意：
1。.NET 的class library也可以使用，不过要通过ccw创建一个com 可以调用的类。
2。queue 收到message 的时候有三种 retrieve 方式， peek，retrieval， transaction retrieval。的三种最有用，应为你的com 在处理改消息的时候可能会出错，这时候他会自动rollback 改消息到队列中。
3。transactional retrieval 只对com有效，对exe没有用。这一点，需要特别注意。后台的trigger service 并不会创建一个类似mts 一样的context 给你的exe。