Amazon Web Services and Platform as a Service: The New Enterprise Java

Written by: Hannah Inman
7 min read

I've been working on a project that I'd like to share: happily, this brings together two technology trends that I believe most people will agree are important - and which are also passions of mine.

  1. The first is cloud computing: specifically, the combination of Platform as a Service (PaaS), which is radically changing the deployment model for enterprise applications, and Infrastructure as a Service (IaaS), of which Amazon Web Services (AWS) is the best known and most widely adopted and mature example.

  2. The second is the rise of mobile applications: traditional web applications are still important (I'm actually going to build some as part of these blogs), but for many development teams the primary devices through which users will access your apps are smartphones, tablets and the like.

One (perhaps the most important) of the factors that drove the explosive growth of Java in the early part of the last decade was the availability of standard APIs for essential enterprise architecture patterns through the J2EE (later Java EE) specs. Take messaging as an example: a message-oriented approach is both natural and effective for many types of application and JMS, for all its limitations, was the standard that enabled message producers and consumers to interoperate. However, the necessary infrastructure to support those messaging architectures was often highly-specific to the app server vendor and scaling out to the degree required to support millions of connected devices across the world (which is what mobile apps are all about) was costly and hard.

If you're from the Java world (like I am), then I imagine that you're probably pretty familiar with the javax.* class hierarchy : lots of folks I know still have those posters on their office walls. That was all very well back in the day, but times have changed and now we need a new (and please, this time, shorter) set of APIs for standard services like messaging, push notification, identity management and various forms of data management, one that is suited to the massive scale of cloud computing. Well, I think that com.amazonaws.* is the newjavax.* and if I had a poster of those classes, I'd put it on my wall.

Think about it from the viewpoint of the mobile application developer: you want to send messages to a queue for back-end processing, or subscribe to notifications about some topic or other and you need to have that scale on-demand, from any device anywhere in the world. You're not going to want to have every single action going back to the server (the old servlet/webapp model) - that's just going to create performance problems, network latencies and so on. On the contrary, you want the app to interact directly with the messaging/notification infrastructure. Your back-end services (properly decoupled from the client applications) can process the information where and when you choose. Amazon Web Services (AWS) is the answer: those com.amazonaws.* classes.

Remember that these are infrastructure services: there's a lot more to application platforms than just the APIs that are available. How you build, deploy and scale the applications in the cloud is a whole other question and Platform as a Service (PaaS) is what abstracts away the low-level details and allows you to focus on delivering your applications. Don't confuse the two: Infrastructure as a Service (IaaS) is the essential underpinning for Platform as a Service, but the application platform is ultimately what delivers application services to your users. Amazon understands that: they have their own PaaS layer (Amazon Elastic Beanstalk ), which is completely separate from the infrastructure services exposed by the AWS APIs. Which application platform is right for you is going to depend on what services you need at the PaaS layer and what you need to support - it could be Beanstalk, Heroku or CloudBees, but that's a completely separate discussion. The point is that you can use the AWS infrastructure from anywhere, where that means mobile devices or applications running on a PaaS platform.

To illustrate this and (I hope) help you to get going with the combination of Amazon's AWS and Java applications on the CloudBees platform, I decided to take as an example the Token Vending Machine model that Amazon includes with both the AWS SDK for Android and the AWS SDK for iOS . I'll go into much more detail on this in a later blog, but in a nutshell this is designed to address the problem of providing temporary credentials that allow mobile users to access AWS services in a secure, controlled manner. The solution uses the Amazon AWS Secure Token Service (STS) and Identity and Access Management (IAM) services and I'll show how to access these and other AWS APIs from applications running on the CloudBees PaaS.

Here's a preview of what I'll be covering in these blogs:

Building Apps with Maven and Eclipse

The TVM service is going to run as a web application on the CloudBees PaaS, so I'll start with a quick look at how to set up and build applications using Amazon AWS with Maven and Eclipse (my IDE of choice, but you should be able to translate pretty easily if you use something different). Amazon has done a good job with tooling for the Eclipse IDE, but you still need to understand how this fits with the Maven/Eclipse model. We'll also take look at how to pass AWS access credentials to an application using the CloudBees RUN SDK's config:* commands.

Identity Management and the Secure Token Service

In this blog, we'll drill down into Amazon's Identity and Access Management (IAM) infrastructure and look at the Secure Token Service (STS), which is the basis for the TVM implementation. I'll look at the key concepts behind Amazon's Token Vending Machine example and go through how to set this up to run as a service on the CloudBees PaaS.

iOS and Android Mobile Clients

In the third part, I'll walk you through how to use the TVM service with iOS/Android mobile clients from the Amazon SDKs, using Android and iOS emulators from Eclipse/ADT and Xcode. I'll explain exactly what you need to do to make your mobile clients work with your own TVM service deployed in the cloud.

Putting it All Together

Finally, we'll get the whole solution running and try it out - and I'll show you some fun things you can try that will probably get you thinking about how powerful the combination of PaaS and the AWS APIs really is.

Please follow along - sign up here for a free development account at CloudBees (no credit card required: it's free to develop and you can also run your demo apps free of charge, using our shared pools). Please do let me know if you have any questions or if there are any other, related areas that you'd like me to cover.

Here are some links to various Amazon resources that will be helpful:

Authenticating Users of AWS Mobile Applications with a Token Vending Machine

Credential Management for Mobile Applications

Token Vending Machine for Anonymous Registration

Token Vending Machine for Identity Registration

I have put my versions of the Token Vending Machine, together with the simple AWS webapp example, on GitHub - the original Amazon source code is provided as a ZIP download from the two links given above:

Finally, you may want to download the Amazon SDKs for iOS and Android, which have the source code for the mobile clients used in the later blogs - you'll need Eclipse plus the Android ADT to build the Android examples, and MacOS with Xcode to build the iOS examples:

Amazon SDK for Android

Amazon SDK for iOS



Mark Prichard, Senior Director of Product Management

Mark Prichard speaks and blogs regularly as an evangelist for CloudBees and Platform as a Service. He came to CloudBees after 13 years at BEA Systems and Oracle, where he was product manager for the WebLogic Platform. A graduate of St John's College, Cambridge and the Cambridge University Computer Laboratory, Mark works for CloudBees in Los Altos, CA. Follow Mark on Twitter and via his blog Clouds, Bees and Blogs.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.