CIO — There's a lot of noise from vendors of every stripe about the cloud. Unfortunately, in the vendors' efforts to show how all their products are cloud-based, there's a lot of blurring about the specifics of what it means to be a cloud application. Consequently, this article will apply differently to every cloud vendor. (And for the purposes of this article, let's keep the discussion to SaaS and cloud-based apps from a vendor or integrator, not ones you build yourself, although some of the same principles apply.)

Cloud Computing: 2011 Predictions

With that disclaimer behind us, one of the distinguishing characteristics of cloud software is the variety of ways it can be integrated. As most cloud applications present themselves as a series of Web services, they lend themselves to a service-oriented architecture, even if they don't follow all the SOA protocols. With the right toolkits and development attitude, you can integrate cloud applications with a variety of techniques...and use as many of them concurrently as you like, even in the same application. Of course, you have to understand the limitations of each approach—but there's nothing wrong with getting things done quickly. Let's look at this as layers of an onion.

Layer 1: On-Screen Integration

Otherwise known as mashups, this style of integration is the ultimate in quick and dirty. The coding exercise is the construction of iFrames for the screen layout and URLs with lots of parameters for grabbing the goodies from the other cloud. This is the baseline method for pulling images, maps, news items, and data feeds from publicly available services like Google (GOOG) or Yahoo (YHOO). This method will become increasingly powerful (particularly for demos) as graphing packages and other document services become commonplace as cloud services. AJAX can give the pages a modern, intuitive, and responsive UI. Unfortunately, mashups don't inherently offer much in the way of security, so you'll have to look at tricky coding practices and server-side validation (for example, here) for sensitive data, and you'll probably want single sign-on or other authorization infrastructure to control access without irritating users. So the tradeoff at this layer is: simple code and read-only, or secured with complex code.

Layer 2: Presentation Layer Integration

Depending on the way your cloud application generates Web pages, you may have a programming layer on the server side which provides fertile ground for cloud integration. (In contrast, the mashup strategy works almost entirely in the browser.) While the mashup strategy is great for stitching together entire segments of a page (e.g., adding a map or graphic to a layout), integrating at the presentation layer shines in its ability to add individual fields within a section of a page. For example, it would be nice to add an indication of "how many days overdue is a customer payment" to the summary area of the CRM account page, but this field might only be available in your accounting system. Pulling this in at the presentation layer gives the users what they need to see, and is faster than doing a full-blown integration.

Of course, the strength of this approach is also its weakness: that payment overdue indicator would not be stored anywhere in the CRM system, so it wouldn't be available to support reports, alerts, or other functions. This approach is usually used for read-only data, as the presentation layer may not have the kind of security infrastructure available in the rest of the system. It all depends on the language you're using and the Web service security libraries available — but it usually doesn't make sense to attempt complex security mechanisms when integrating at the presentation layer.

Continue Reading