Summarizing the Evolution: The .NET Framework 3.5 and its Predecessors
The .NET Framework 3.5 is the latest step in the evolution of Microsoft’s flagship development platform, with each step building on what came before. This most recent release is a superset of the .NET Framework 3.0, and it brings no breaking changes. Similarly, the .NET Framework 3.0 was a superset of the 2.0 release, and it also contained no breaking changes. To help make the stages in this evolution clear, the figure below shows what’s been added in the 30 and 3.5 releases.
Everything in the .NET Framework depends, as it always has, on the Common Language Runtime (CLR). A large group of classes, known as the .NET Framework class library, is built on top of the CLR. This library has expanded with each release, as the figure shows. The .NET Framework 2.0 provided the fundamentals of a modern development environment, including the base class library, ASP.NET, ADO.NET, and much more. The .NET Framework 3.0 didn’t change any of this, but it did add four important new technologies: WCF, WF, WPF, and Windows CardSpace.
The changes in the .NET Framework 3.5 affect several parts of the 3.0 release. ASP.NET gets AJAX support, while LINQ is available for use with ADO.NET and in other ways. Various additions were made to the base class library, such as addition of a type supporting sets—unordered collections of unique elements—and improved encryption support. WCF, WF, and WPF each get enhancements as well, as described later in this overview. The set of operating systems on which the Framework runs was also updated: The .NET Framework 3.5 runs only on Windows Server 2008, Windows Server 2003, Windows Vista, and Windows XP.
Because each release adds to its predecessor, the need to retest applications built for earlier releases is minimized. Also, because all three of these versions can run simultaneously, it’s still possible to run applications on older versions of the Framework if desired. Visual Studio 2008 even allows creating projects that target a particular version of the Framework. An application built in this way will use only the binaries for that version, and the developer will see only those aspects of Visual Studio and the Framework itself that work in this older world. A developer who chooses to build a new application targeting the .NET Framework 2.0, for example, can make his world look just as if only this older version of the Framework were available.
Applying the .NET Framework 3.5: A Scenario
One way to understand how a group of technologies work together is to look at an example of how they can be used. Imagine, for example, an application that lets customers and agents submit insurance applications. If it were implemented using the .NET Framework 3.5, this application might look something like the figure below.
The application’s business logic, shown in the upper left of the diagram, is implemented using a WF workflow. Handling an application for insurance is a multi-step process, including evaluating the application against this organization’s underwriting rules, perhaps checking the applicant’s credit, and maybe even getting a manager’s approval. The workflow implements each of these steps as an activity, relying on other software as needed. To access stored data, the activities in this workflow use a LINQ option for issuing SQL queries.
This insurance company provides a call center, allowing its customers to apply for insurance over the phone. The client software used by the people staffing that call center, shown in the upper right of the diagram, is implemented as a standalone WPF application. This client communicates with the application’s business logic via WCF, using a binary protocol optimized for WCF-WCF communication. As the figure shows, the call center workers rely on Windows CardSpace to select the identity they will use when logging into this application.
Customers can also apply for insurance via the Web. To allow this, the application uses ASP.NET AJAX to communicate with Web browsers, providing a responsive user interface for customers. As shown in the lower left corner of the diagram, a customer accessing this application via a Web browser can use CardSpace to select the identity he wishes to present.
Insurance agents who access this application over the Internet may well need a more functional interface than what customers see. Accordingly, they can rely on an XBAP rather than an AJAX interface. As shown in the lower center of the diagram, this gives those agents a large share of the user interface functionality provided by the WPF desktop application used in the call center. Both are built on the same foundation, and so the application’s developers can reuse the same code in the two types of clients. And as with the other kinds of clients, agents can use CardSpace to select the identity they wish to present to the application.
Finally, it’s likely that this application will need to access and be accessed by other applications. If approving a customer requires a credit check, for example, this will most likely be done through a call to an external service. Or perhaps the application accepts requests directly from other software, exposing services that these external applications can invoke. For cases like these, shown in the lower right of the figure, the application relies on WCF to communicate using standard Web services. Whatever technology these applications are built on, WCF’s support for SOAP makes interacting with them straightforward.
This scenario illustrates how some of the .NET Framework 3.5’s components might be used in a typical application. Quite a few options have been omitted, and so don’t view this simple example as a complete illustration of what this technology family provides. Instead, the goal is to give a clear idea of how the various parts of the .NET Framework can be used together to address real business problems.