Web service providing notifications over multiple transports

Question

I want to enable event notifications for my customers. There are many possible ways to send notifications: emails, sms, XMPP/other IM, pre-recorded voice messages over SIP, phone-specific message push services, REST callbacks etc.

I don't want to develop all these transports myself, so I need a web service that can manage those notifications for customers. Also I don't want to store emails/phones/other personally identifiable information.

The notifications are transactional (i.e. it's not mass delivering same message to everyone). Paid solutions are welcome.

There is http://pagerduty.com but it is

• designed to work within enterprise and not with outside customers
• focused on full cycle of incident response as opposed to simple message delivery

So it puts more burden on respondents and I want something that requires zero effort for the users to setup.

Monitis is another example. It has multiple transports including Twitter, but again it's designed for insiders and not for service subscribers coming in bulk numbers.

Amazon SNS seems to be too low-level as it only manages delivery of push notifications, but for diplaying them I have to write a mobile app which I don't want.

XMPP servers as described in How best to deliver notifications to various IM / notification services? have traditionally supported the idea of different transports, but I'd like a third-party hosted service.

Twilio has only 2 transports: SMS and voice call and more oriented on full 2-side communications.

I cannot even find the right google keywords to search for the service/SaaS I want.

The question is, are there any such services? A sample of a few would give me an idea of what to look for.

Varus

What do you think of plain twilio? – Memoried

It has only 2 transports: SMS and voice call. Email and IM are not addressed. So it offers little advantages to choosing an sms and a voice provider separately. – Varus

Answer 1

This comes very late, perhaps too late but...

You should not need to implement any of the transport but you may be required to build some of the gateways and you will most likely need to assembly the application which talks to each of the gateways. You are not likely going to find a single service for this.

You've already outlined the strategy. You basically have these pieces:

1. transports
2. gateways
3. application

Each of the transports is accessed through some client via either an API or a CLI - so you'll need to figure out what your environment is. Java is probably a good choice but other cross-platform environments would likely work. Existing infrastructure like Apache ServiceMix has support for some of these transports:

https://cwiki.apache.org/confluence/display/SM/Components+list

and there may be other middle-ware with similar, distinct transports.

You will likely want a gateway for each provider for each transport type. You may be able to find a provider which adequately services multiple transports, e.g. Twilio's SMS and voice, but that will likely be the exception. You may also find that because of the differences in transports (and therefore functionality), it's more convenient to build a gateway for each transport type. So, you might have two configured providers in your SMS gateway, one for Twilio and one for Kannel, and you might have your Twilio account used in the SMS gateway and in the SIP gateway.

The final step is assembling your application into something meaningful. This might be something like:

sent.......: "Thanks for your purchase, ${username}!"

sent to the channels (i.e., provider-transport pair) configured, perhaps, by the user and being able to collect the response from the user:

response...: "It was a pleasure! --Bob"

You will need to store the basics of the each transport's endpoint, e.g., phone number for SMS, username for chat, etc., so if you have PII security issues to address you'll need to think though that. One option may be to turn all the PII over to each provider but you'll still need to keep each account for your users in each provider, and you will likely need to know something about the user, like "${username}" above, to personalize your notification appropriately within your application. So, removing all PII from your application seems unlikely.

I'm not sure how much this help but perhaps it gives you some ideas.

Bitch