Over the past couple of years, an idea has emerged (some might argue it's an old idea) that software will be transformed into being used as services, rather than as monolithic applications tied to a specific machine or platform. Rather than install software onto computers every time we need some functionality, an end user or corporation can reuse other application assets over the network. The idea expands into the notion of just-in-time delivery of applications. "Software as services" is a big idea. It holds the promise of introducing radical new economies of scale into the manufacturing and distribution of software applications. From an end-user perspective, it's the idea that users can access information and applications anytime, anywhere, and from any device.

This is a powerful set of ideas. It's the idea that the value that we create in software can be freed from any single delivery platform. It's the idea that rich applications can be used easily across platforms and devices. How close are we today to realizing this set of ideals?

The Web Services Industry Today
The phenomenal focus on Web services over the past year is interesting in contrast to the actual set of technology available to fulfill this vision. In comparing the broader vision for software as services to the world of Web services technologies, such as protocols like SOAP and formats like WSDL, it looks like we're perhaps 25% of the way toward fulfilling that vision.

Today, Web services are primarily talked about through the lens of specific protocols - SOAP and WSDL, perhaps UDDI (though I have yet to find a customer who's really using UDDI in any significant way). This early focus and discussion is great - finding the holy grail of a common protocol for exchanging objects and data between platforms is an incredible achievement, and the fact that the industry is so focused on it gives us hope for the future of interoperable and open software.

But even the current crop of technologies implemented around these standards has problems and challenges. In the Web services model, application logic is well-structured, often as component services. The need to deliver well-structured applications has largely eluded Web application development. In fact, we all know that close to 75% of Web applications are not well structured - they're conglomerations of dynamic pages, including scripting languages, database code, and presentation logic all together.

There is a huge disconnect between the necessity of well-structured Web services and the reality that most Web applications are built using 4GL scripting languages, are usually unstructured, and rarely meet the requirements of thoughtfully designed, object-oriented systems.

Let's assume for a moment that Web services are strictly defined as the middleware standards for messaging and object marshaling - e.g., SOAP and WSDL. Even in that world, the majority of Web application developers aren't well positioned to both create and consume Web services without becoming full-on system programmers using complete object-oriented environments such as Java or .NET. The back-end world of Web services needs to evolve to make it simpler for RAD or scripting-level developers to easily create and consume Web services. It would be a huge victory for the industry if those 75% of Web applications built with scripting languages could also share their value and data with other applications.

However, the focus on Web services through this lens largely relegates the topic to discussions of classic back-end middleware, rather than a more holistic view of how to deliver software as a service. Strikingly absent from the discussion is any notion of what the end-user experience is of these "software services." In part, this is due to the type of vendors thinking about Web services - e.g,. traditional enterprise middleware companies - but it is also because of the hard work required by interoperable messaging and object protocols - these are necessary conditions to any future for software as services.

Getting back to the original vision of "software as services," it's apparent that we need a more holistic discussion and framework for thinking about Web services, one that actually includes end users using them. What would an end-to-end model for Web services look like?

The Missing Piece: Rich Clients and Web Services
Many of the early visions of Web services centered on the idea that, in the future, software could be used as a service, rather than as monolithic applications that needed to be installed and used on our desktop computers. While the Web has made progress on delivering applications easily to browsers, the world of Web services will deliver the experience of desktop-quality software that can be consumed as a service. Visions of using "productivity applications" as services were common interpretations by the industry. Examples such as Hotmail and Salesforce.com were cited as leading indicators - in this world of software services, end users could easily access rich applications from any desktop computer. These applications would always have their personal information, would be interconnected with back-end systems, and could even be portable across devices. This new world, however, would leave behind the document-based or page-based model of the Web for one that was much richer in terms of application capability, and that extended beyond the browser onto desktops and devices.

So, what is the user experience of Web services? What's the model for combining rich interfaces with back-end middleware to deliver exceptional new value for end users and the companies that serve them?

I believe that the perfect complement to "Web services as middleware" is the emerging category of rich clients. Indeed, it may well be that rich clients and Web services are two sides of the same coin - combining to enable this world of "software as services." What are these rich clients, and what do they require to transform the user experience and provide the logical front-end to back-end Web services?

Rich clients should combine rich content, applications, and communications in a single client environment. By rich content, I mean richly formatted text, graphics, audio, and video. By applications I mean rich, complex user interfaces - the kind we expect from a modern desktop computer - as well as application logic and data deployed in the network. And by communications I mean the ability for end users to interact with each other through these clients - to share data, text, audio, and video, in real time and non-real time. Rich clients should provide these capabilities in an integrated manner, where the applications that can target them far exceed what is possible in the world of HTML documents.

Rich clients should allow applications to run not only in browsers, but also as standalone applications on desktops and laptops. They should also support running on devices. To support these new Internet-connected application types, they should handle offline data storage, enabling occasionally connected devices and applications.

Most importantly, rich clients should anticipate the emerging world of back-end Web services by using a services-oriented architecture for integrating business logic and data across the network, whether that's simply contained in an application server, or actually a distributed Web service exposed through a protocol like SOAP.

Rich clients and Web services combined hold the promise of fulfilling the broader vision that the industry has for deploying software as services. The combination will enable rich, business-connected productivity applications. It will transform what's possible on the Internet today.

Software as Services: Make It Real
My company, Macromedia, is passionate and excited about using software as services. We believe in a holistic view that encompasses both the front-end user experience and the back-end integration layer. We hope that by making Web services approachable and affordable we'll all be able to take advantage of what they have to offer, not just the legions of advanced programmers and classic middleware developers. And remember, building for the next generation of the Internet should be fun - let's make the Internet interesting again.