I’ve written a few times about the Amazon Web Services (AWS) offerings and in this post, want to briefly show you the new web-based interface for configuring the Simple Notification Services (SNS) product.
I’m really a fan of the straightforward simplicity of the AWS service interfaces, and that principle applies to their web console as well. You’ll typically find well-designed and very usable tools for configuring services. AWS recently announced a web interface for their SNS offering, which is one of the AWS messaging services (along with Simple Queue Service [SQS]) for cloud-based integration/communication. These products mirror some capabilities of Microsoft’s Windows Azure, but for both vendors, their are clear feature differences. SNS is described by Amazon as:
[SNS] provides developers with a highly scalable, flexible, and cost-effective capability to publish messages from an application and immediately deliver them to subscribers or other applications.
SNS uses a topics and subscribers model where you publish messages to SNS topics, and subscribers are pushed a message through a protocol of their choice. Each topic can have policies applied which may include granular restrictions with regards to who can publish messages or which subscriber protocols the topic will support. Available subscriber protocols include HTTP (or HTTPS), email (straight text or JSON encoded), or AWS SQS. SNS has “at least once delivery” and it appears that, like Windows Azure AppFabric, SNS doesn’t have a guaranteed delivery mechanism and they encourage developers to publish from SNS to SQS if you need a higher quality of service and delivery guarantees. If you want to learn more about SNS (and I encourage you to do so), check out the SNS product page with all the documentation and such. The SNS FAQ is also a great resource.
Ok, let’s take a look at setting up a simple example that requires no coding and only web console configuration. I’ve logged into my AWS web console, and now see an SNS tab at the top.
I’m then shown a large, friendly message asking me to create a topic, and because they asked nicely, I will do just that.
When I click that button, I’m given a small window and asked to name my topic. I’ll end up with a SNS URI similar to how Windows Azure AppFabric provides a DNS-like addressing for it’s endpoints.
After the topic is created, I get to a Topic Details screen where I can create subscriptions, view/edit a topic policy, and even publish a message to the topic.
I’ve chosen to view my topic’s policy, and I get a very clean screen showing how to restrict who can publish to my topic, and what people, endpoints and protocols are considered valid topic subscribers. By default, as you can see, a topic is locked down to just the owner.
Next up, I’m going to create a new subscriber. As you can see below, I have a number of protocol options. I’m going to choose Email. Note that JSON is the encoding of choice in SNS, but nothing prevents me from publishing XML to an HTTP REST endpoint or sending XML in an email payload.
Every subscriber is required to confirm their subscription, and if you choose an email protocol, then you get an email with a link which acknowledges the subscription.
The confirmation email arrived a few moments later.
Clicking the link took me to a confirmation page that contained my specific subscription identifier. At this point, my SNS web console shows one approved subscriber.
I’ll conclude this walkthrough by actually sending a message to this topic. There is a Publish to Topic button on the console screen that lets me enter the text to send as a notification. My notification includes a subject and a body message. I could include any string of characters here, so for fun, I’ll throw in an XML message that an email poller (e.g. BizTalk) could read and process.
When I choose to Publish Message, I get a short confirmation message, and switch back to my inbox to find the notification. Sure enough, I get a notification with the data payload I specified above. You will notice that I get an email footer that I’d have to pre-process out or have my automated email poller ignore.
Just so that I don’t leave you with questions, I’ve also configured an Email-JSON subscriber to compare the type of message sent to the subscriber. I mentioned earlier that JSON is the preferred encoding, and you can see that in action here. Because JSON encoded messages are expected to be processed by systems vs. humans, the email notification doesn’t include any additional footer “fluff” and only has the raw JSON formatted message.
Pretty nice, eh? And I didn’t have to think once about cost (it’s free up to a certain threshold) or even leave the web console to set up a solution. Take note, Microsoft! At some point, I’ll mess around with sending an SNS notification to a Windows Azure AppFabric endpoint, as I suspect we’ll see more of these sophisticated cloud integration scenarios in the coming years.
I encourage you to check out the AWS SNS offering and see if this sort of communication pattern can offer you new ways to solve problems.
Richard Seroter's Architecture Musings 
One thought