Software as a Service

Robert Hess

Microsoft Corporation

January 8, 2001

One of the common phrases you'll hear connected with .NET, is "software as a service." But what does that mean? There are a number of different ways that this idea can take form, so let's look at them and see how they might affect both the application developer as well as the end-user.

The most simplistic approach is to think of software as a service as correlating directly to what you get with something like cable TV or your local phone company. Both of these provide a service you subscribe to, and the precise level of service and offerings provided depends on your needs. As long as the TV is plugged into the cable, you get to watch any of the channels that your subscription includes. As long as your phone is plugged into the wall, you get access to the phone system, which might include voice mail, caller ID, call waiting, and various other additional services.

So software as a service can be a mechanism by which users subscribe to some of the software they use, and select how much or how little of the full application they want access to. The Web is already providing some rudimentary notions of this sort of capability. Subscribing to an Internet Service Provider (ISP) such as MSN or AOL is an obvious example of computer users subscribing to a service. And you can subscribe to online newspapers, financial services, and various other such sites that might require a monthly fee in order to access the information that they provide. However, all of these are simplistic examples of a service-oriented approach to computer usage.

People are constantly joking about how large such applications as word processors have become. It's easy to list features within these applications that you have never used, and probably never will, but likewise there are other users out there who will never use some of the features that you use constantly. Most of the features in these applications have been added in order to satisfy some segment of the user community. But what if you could set the application up so that it only included the features that you used? And not only would you pay just for the features you used, but you could also further reduce the expense by only paying as often as you used a particular feature. Perhaps you only use mail merge once a year to send out your infamous Christmas letter; why pay for it the other 364 days of the year?

Luckily, one notion of software as a service addresses this sort of functionality. The software could be dynamically installed off the Web, you would only install the portions of the application you wanted to use, and you'd only pay for what you installed. Or perhaps the application actually lives on the Internet, much like Web-based e-mail does today. You connect to the Internet, browse over to your document, and start editing. This means that no matter where you might be, or which computer you are using, you can still access your documents and information.

The tighter level of interaction between the customer and the software developer would also allow patches, updates, and upgrades to be communicated to the user more easily, and it also would allow software developers a better understanding of exactly which features are used most often. Which, in turn, would help them focus their attention on those parts of their applications that provide users with the most value.

Many aspects of .NET allow applications to be better exposed as dynamic and subscribeable services. One of these is the new notion of assemblies as part of an application. In this way, applications can retain within themselves a manifest of exactly which components they need and where to install them from. While this isn't specifically an Internet-based feature, it does provide the groundwork from which applications can make much better use of remote and diverse components without falling prey to some of the current problems that users encounter with incompatible DLLs and dependencies. For more information on how assemblies work within the .NET framework, you can refer to Simplifying Deployment and Solving DLL Hell with the .NET Framework.

For information on how the .NET framework can help you develop a Web-based application with rich features and capabilities, look at ASP .NET and how this makes it easy to expose dynamic and interactive Web sites to users. Here are a few good links for further information:

MSDN ASP .NET Developer Resources

The MSDN Show: ASP .NET

The Voices column Nothin' but ASP .NET

The other side of software as a service is more of a business-to-business opportunity in which the service is not exposed as a Web site or other form of user interface, but instead is a programmatic interface to specific processing logic provided by an application running on a server. This allows a company that specializes in a very focused capability to expose that capability as a set of "interfaces" (function calls) that other applications use to gain access to this service.

A key benefit of providing your service as a programmatic interface is that you can focus on your core competencies without having to concern yourself with designing a "pretty" user interface or adding capabilities the user might expect if you were offering a full-fledged application. If your specialty is creating highly accurate currency conversions for virtually any country in the world, then you can focus on developing functions that other Web sites would call into in order to provide converted prices to their users. In this way, a variety of services can be combined to provide an end user with a richer and more expansive experience on the Web.

Today, most Web applications are developed in the spirit of being an island unto themselves. If Web site developers want to support credit card negotiations, then they need to either develop the necessary software themselves or purchase it from somebody else. If they want to provide image manipulation, they again need to provide for this themselves. As .NET makes programmatic interfaces over the Web more commonplace, we'll gradually be able to see applications sharing and expanding on the functionality provided by a community of Web-based services.

One of the key technologies that allows Web sites to expose programmatic interfaces to their services is Simple Object Access Protocol (SOAP). This is a way of using XML to describe the properties, methods, and events that a Web site supports, as well as the form in which other applications can call into them. For more information about SOAP, you can refer to Simple Object Access Protocol (SOAP) 1.1 Specification and SOAP Developer Resources.

For information about how SOAP is integrated into .NET in general, and Visual Studio .NET in specific, you can refer to SOAP in the Microsoft .NET Framework and Visual Studio .NET.And for a good starting point for .NET developer information in general, you might want to check out the MSDN .NET Developer Center.

I hope this has provided you with an introduction to what software as a service means and how it relates to .NET. End-users, other businesses, and individual developers can all realize its benefits. By providing a robust and scaleable method to connect multiple services, we also can empower the small developer to provide significant value to a much larger community. This allows everybody to play an important role in how applications are used on the Internet. Robert Hess hosts the MSDN Show.