As dramatic as it may sound, the Web was not invented sort of 20 years ago to deliver rich pages and applications--at least, in the today's acceptation of terms like rich pages. The Web was designed and implemented to share documents and to link one document to a related one published to the same network. HTML and HTTP, respectively the markup language and transportation protocol, were tailor-made to serve plain text with a bit of formatting, sparse images and a few hyperlinks.
The Web became officially a public resource in 1993; 15 years later, we're still using HTML and HTTP to create true applications with a rich presentation layer and sophisticated back ends. And then we complain about bandwidth, slow rendering, and an overall cumbersome model of interaction between the user and the system. The growing demand for rich Internet-based applications has brought to the conclusion that only a new generation of applications can let Web architects keep up with it. The AJAX paradigm is definitely a quantum leap for Web architects. AJAX solves many problems, but it also raises new problems and sharpens existing, but partially latent, issues. But AJAX is a paradigm for enriching traditional Web applications-based on HTML and powered by script languages. But unfortunately, HTML and JavaScript are not necessarily the ideal tools to rely on when you want rich graphics, animation, media capabilities, and programming power.
Well 10 years ago Microsoft made a first attempt to give developers a rich programming environment for the Web. It was in late 1990s when the ActiveX technology came along. All in all, ActiveX was a bit ahead of time and, more importantly, had serious flaws in key areas for Web applications, such as interoperability and security. Similar in the overall idea of being a browser plug-in, but cross-platform and with a better security model, Adobe Flash imposed itself as the de facto standard for rich interface over the Web. In September 2007, Microsoft released version 1.0 of an analogous product-Silverlight-which is clearly a competitor to Flash but with some good arrows in the quiver.
Today, both Flash and Silverlight are evolving into something different that goes beyond the role of the player for some graphically rich content. Flex and Silverlight 2.0 are expected to deliver more programming power to be consumed within the boundaries of the browser, but rigorously on the client. It's like having a new type of client for the front-end of our enterprise applications-the rich client browser.
Enter Silverlight
Formerly code-named WPF/Everywhere, Silverlight is a free browser plug-in that is currently available for the Windows and Mac platform under a variety of operating systems including Windows Server 2003, Windows Vista, Windows XP SP2, Macintosh OS X 10.4.8 and newer versions for both Power PC-based and Intel-based hardware. Silverlight supports all major browsers available on these platforms such as Firefox, Netscape, Safari, Internet Explorer.
As you can see, there's currently no support for Linux, mobile systems, and some older versions of Windows. However, this is not necessarily a situation destined to last for too long. Silverlight support for Linux systems is coming through the efforts of the Mono group. You can read more on the progress by visiting http://www.mono-project.com/moonlight. Support for mobile systems is being experimented at this time. Microsoft also has announced to have plans to support Silverlight on Windows 2000. You have no hopes, however, to ever install Silverlight successfully on, say, Windows 98.
The mission of Silverlight is clearly explained by its former code-name: WPF/Everywhere. That's what Silverlight really does: it brings the power of Windows Presentation Foundation-the presentation subsystem of the .NET Framework 3.x-to the Web. The idea is hosting the Silverlight engine into the browser to let it process WPF content aptly downloaded from a remote URL.
Silverlight is not intended to replace the browser, but is designed to be hosted in the browser as a plug-in. For this reason, designing some Silverlight content is a two-step operation. First, you create the WPF content you want to deliver through the Web. Second, you prepare a host Web page where you reference and configure the Silverlight plug-in. Users just navigate to a Web page and if the page requires Silverlight they are automatically prompted to install it and proceed with the features designed for the page. This model is nothing new and is fairly familiar to most Web users; see Figure 1.
Let's dig out the nitty-gritty details of how the Silverlight engine is referenced and configured by page developers. Before going any further, though, I feel I need to add something on the versions of Silverlight currently available. As mentioned, Microsoft released version 1.0 in September 2007; at the same time, Microsoft also leaked to the Web the alpha of version 1.1. Late in 2007, the version number of the alpha was changed to 2.0 and a beta for version 2.0 has been released as of Spring 2008. Version 2.0 represents a huge step forward in terms of functionality. However, the hosting model, that is the way in which you reference and activate the engine from within Web pages, will not undergo significant changes.
