by Don Jones

There’s a misperception by many in the industry that “cloud computing” refers only to Web applications. That’s not entirely true; cloud computing does require that at least some of the application be cloud based, but the application might not ever involve a Web browser.

Let’s consider for a moment how a more traditional, in-house application works. Typically, there’s a client application, which might be written in Java, or Microsoft’s .NET Framework, or some other language. This is usually a graphical user interface (GUI) application, designed for use by end-users. This client application may communicate directly with a back-end database server, such as Microsoft SQL Server or Oracle or IBM DB2 or something. In other models, the client application may communicate with an application server, which processes business logic and sits between the client and the database. These two models each create a stack:

CLIENT
DATABASE

Or:

CLIENT
APPLICATION SERVER
DATABASE

A key thing is how these elements communicate. In a very traditional application, the client might use Open Database Connectivity (ODBC) protocols to communicate with a database, or might use something like Microsoft’s Distributed Component Object Model (DCOM) to communicate with an application server. Another option — even for in-house applications — would be to use a Web service.

A Web service needn’t actually involve the public World Wide Web. Web service simply describes an application that utilizes Web-centric technologies, such as the Hypertext Transport Protocol (HTTP) used to transmit Web pages on the public Internet. Two commonly-used types of Web service, SOAP and REST, are designed to facilitate communication between application layers. For example, an application server might use a small (or even embedded) sort of Web server, receive information from clients via HTTP requests, and send information to clients via HTTP responses. This isn’t logically any different from using ODBC or DCOM; it’s just a different set of protocols — ones which are designed to operate well over a public network as well as a private one. Web service does not imply the use of a Web browser, although obviously a Web browser could be used as a client application in lieu of a custom-written GUI application.

Because the application elements are communicating by means of Web-friendly protocols, portions of the application can now be moved into the cloud. For example, it’s common to move the application server and database elements into the cloud, provided the application server code is written in a language that can be executed by your cloud provider. But it’s just as valid to simply move the database into the cloud, and to re-write client applications to use whatever protocol is needed to communicate with the database in its new location.

Why not simply use ODBC or DCOM or whatever? Simply because those protocols don’t work well in a highly-routed public network like the Internet. SOAP and REST were developed around HTTP, which does work well in a highly-routed environment that may have some transmission latencies.

In the end a “cloud” application is not distinguished by the use of a Web browser as a client; a cloud application need not be a “Web application” at all. It does use Web-friendly protocols to communicate between application elements, and it does host a portion of the application stack in a Web server-like environment, but in all other ways a cloud-based application can look and feel like any other application.

About the Author

Don Jones has more than a decade of professional experience in the IT industry. He's the author of more than 30 IT books, including Windows PowerShell: TFM; VBScript, WMI, and ADSI Unleashed; Managing Windows with VBScript and WMI; and many more. He's a top-rated and in-demand speaker at conferences such as Microsoft TechEd and TechMentor, and writes the monthly Windows PowerShell column for Microsoft TechNet Magazine. Don is a multiple-year recipient of Microsoft's "Most Valuable Professional" (MVP) Award with a specialization in Windows PowerShell. Don's broad IT experience includes work in the financial, telecommunications, software, manufacturing, consulting, training, and retail industries and he's one of the rare IT professionals who can not only "cross the line" between administration and software development, but also between IT workers and IT management. Don is a co-founder of Concentrated Technologies, and serves as author and series editor for Realtime Publishers.