Yesterday, I gave a presentation suggesting that instead of choosing one or the other technology, consider leveraging the strength of each.
For example, you could use SSNS for atomic notifications that don’t require complex business rule processing (examples include sending an e-mail to subscribed individuals, or making a web service call). SSNS has many desirable features, including rule-based filtering and threshold support, support for single occurrence of a condition and for aggregation (span across records), queue management, retry logic, flooding avoidance, batch processing, scheduling, fall-behind logic, time-zone handling, per-device formatting, per-language formatting, caching, etc. And, of course it supports multiple delivery protocols such as HTTP, SMTP, file; is built with extensibility in mind by providing support for custom event providers and distributors, has excellent performance characteristics, supports scale-out and failover, it is secure and reliable.
But in cases where you require things like complex rule-based filtering, message transformations (think: would BizTalk mapper be useful here?), correlation to running orchestrations, or in cases where notification is part of a complex workflow, especially when compensating transactions are required, etc. – BizTalk pub/sub implementation may be your better bet.
What I’m trying to say is that you could build a BizTalk <-> SSNS Adapter that acts as subscriber and provider of SSNS events:
Let me know your thoughts on this by submitting your feedback…