基本上,应用程序将是通过服务层(无论是WCF还是普通的Web服务)读取/写入数据的几个网站(内部通过LAN或通过Internet外部).然后,此服务层将执行以下两项操作之一：1.将数据写入数据库2.和/或通过在队列中放置消息来触发后台进程. 3.显然它也可以从数据库中检索数据.队列另一端的小代理(Windows服务)将监视队列并根据任务命令执行.
与RPC或分布式执行或其他任何方式相比,此体系结构将非常容易扩展(添加更多队列和代理)并且易于实现.并且代理处理不需要是实时的.代理和服务层是单独的应用程序,除了它们共享公共域对象和存储库等.
你怎么看？欢迎对上述要求的架构建议.谢谢！
WCF在MSMQ上添加了一个抽象.实际上,一旦定义了兼容的合同(操作必须是OneWay),您就可以透明地在配置中切换出MSMQ. (例如,您可以切换到正常的HttpWS或NetTcp绑定.)您应该评估其他WCF的好处,例如安全性等,以了解这些好处如何适合您的需求.同样,他们应该合理地透明你在下面使用MSMQ的事实.例如,添加SOAP安全性等应该“正常工作”,与使用MSMQ无关.
(虽然,IIRC,你仍然需要在使用MSMQ的每台机器上登录桌面,使用MSMQ的服务帐户,在机器本地配置文件中生成证书.然后,它不能很好地工作IIS6,因为没有加载用户配置文件.一般来说真的很痛苦,但与WCF没有任何关系.)
除此之外：
你看过SQL Server Service Broker吗？在使用MSMQ WCF和SSSB之后,我认为SSSB更容易配置和管理. SSSB可以在任何SQL客户端上使用T-SQL命令(我在Mono上使用它,在Linux上使用事务).它还会为您提供事务性发送/接收,甚至远程(我认为MSMQ 4现在允许这样做).消息排队真的需要很多痛苦,如果你已经使用SQL Server了……
SSSB经常被忽视,因为SQL Management Studio没有GUI设计器,但它并不难,而且是一个很好的选择.一个缺点是,如果您想要本地发送功能(即网络中断时的队列消息),您将需要运行本地SQL Express实例.