Introducing the .NET Framework 3.0

  • Article

 

David Chappell
Chappell & Associates

July 2006

Applies to:
   .NET Framework 3.0 (formerly WinFX)
   Windows Development

Summary: Version 3.0 of the Microsoft .NET Framework provides a diverse set of technologies, each addressing a significant challenge in application development today. (29 printed pages)

Contents

Describing the .NET Framework 3.0
Applying the .NET Framework 3.0: A Scenario
Understanding the .NET Framework 3.0: The Technologies
Getting the .NET Framework 3.0: Distribution Options
Conclusion
For Further Reading

Describing the .NET Framework 3.0

The goal in application development is always the same: create the best possible software in the least amount of time. Yet the bar is continually raised, as the platforms on which developers build get better and better. In Windows, for example, the original Win32 interface has been subsumed by the much more functional .NET Framework. Both version 1.0 of the Framework, released in 2002, and version 2.0, released in 2005, provide a significantly better and more productive environment for people who design and write Windows software.

The .NET Framework 3.0 (formerly known as WinFX) is the next step in this progression. Applications built on this new version of the Framework can be created with Visual Studio 2005, making it feel familiar to most Windows developers. But the .NET Framework 3.0 is also an evolution, adding more to what version 2.0 of the Framework already provides. Scheduled to be released in late 2006, the .NET Framework 3.0 will be available for Windows Vista, Windows Server 2003, and Windows XP.

This paper provides a big-picture view of the .NET Framework 3.0 and its components. The goal is to make clear what this new release is, examine how its technologies can be used, and provide brief explanations of those technologies.

Building Modern Applications: The Challenges

Creating a typical application today is not a simple task—the requirements are substantial. Traditional concerns such as working with stored data and allowing access through a Web browser are still important, but they're no longer enough. Modern applications also present a range of new challenges, including the following:

  • Organizations are increasingly taking a process-oriented view of what they do. Since most applications automate some part of a business process, it can be useful to make the steps in this process explicit in the code. An effective way to do this is by using workflow technology, an approach that requires support for workflow-based applications.
  • Applications commonly communicate with other applications, both inside and outside the organization. Modern applications also must often fit into a service-oriented architecture (SOA), exposing some of their functionality as interoperable services accessible by other software. Achieving these goals requires support for service-oriented applications.
  • The people who use an application commonly need a way to convey information about who they are. Many different technologies for defining and using a digital identity are in use, and problems such as phishing are common. Given this, a modern application and the people who use it can benefit from consistent user control of digital identities.
  • The requirements for a modern user interface have grown significantly. Providing real business value can commonly require working with various kinds of documents, using two- and three-dimensional graphics, displaying video, and more. All of this also needs to be available for both native Windows clients and Web browsers. Meeting these needs requires a unified approach to diverse user interfaces.

Given that today's applications commonly need to tackle some or all of these challenges, the platform those applications are built on should also address all of them in a coherent and usable way. The goal of the .NET Framework 3.0 is to do exactly this for Windows applications.

Addressing the Challenges: What the .NET Framework 3.0 Provides

As figure 1 shows, version 3.0 of the .NET Framework builds on the previous release. In fact, nothing in version 2.0 of the .NET Framework is changed, so existing applications created for this foundation will continue to work as always. The .NET Framework 3.0 does add four new components, however: Windows Workflow Foundation, Windows Communication Foundation, Windows CardSpace, and Windows Presentation Foundation. This section takes a brief look at what the .NET Framework 2.0 and each of these new components provides.

Figure 1

The .NET Framework 2.0: A General-Purpose Foundation for Windows Applications

While it's still possible to write software that directly uses the Win32 interface, the .NET Framework has become the mainstream environment for new Windows applications. Among its most important parts are the following:

  • ASP.NET, which supports the creation of Web-accessible applications.
  • ADO.NET, allowing applications to access relational and other types of data.
  • Windows Forms, supporting the creation of graphical user interfaces (GUIs) for Windows applications.
  • System.XML, which lets applications work with XML-defined data, including using XSLT and XPath.

Version 2.0 of the Framework added several useful things to its predecessor, including substantially improved technology for creating ASP.NET Web applications, support for 64-bit applications running on 64-bit versions of Windows, and a new approach to handling transactions. While some parts of the .NET Framework 2.0 are largely superseded by the new components added in version 3.0, as described later, the technologies in version 2.0 remain a fundamental part of this new release.

Windows Workflow Foundation: Support for Workflow-Based Applications

A workflow is a simple idea: it's just a series of steps performed in some order. One might even argue that every application implements a workflow, since every application executes some process. Yet the traditional approach to creating an application using C# or Visual Basic or some other programming language is to make the steps in this process implicit in the code. This certainly works, but it also embeds the process itself deeply into a program's logic, making that process more difficult to implement and to change.

Using workflow technology to implement process logic can be an effective way to address this problem. Rather than intertwining the logic in ordinary code, each step in the process is explicitly defined, then executed by a workflow engine. The result is a clean implementation of the process itself.

Workflow engines are not a new idea; several are available today for Windows and for other systems. Microsoft even provides workflow engines embedded in some of its products. Yet because workflow is becoming a mainstream approach to creating applications, providing a single workflow technology for Windows makes sense. This is exactly what's done by Windows Workflow Foundation (the official acronym for which is WF). By providing a common workflow technology for Windows, WF gives any workflow-based application the same foundation to build on. Software provided by Microsoft will use WF, including the Microsoft Office 2007 system and Windows SharePoint Services, as will applications created by others.

Providing a common workflow technology presents some challenges, however. For instance, how can a single approach meet the diverse set of requirements presented by different workflow applications? The answer adopted by WF is to take a very general view of workflow. As figure 2 shows, a WF workflow is just a group of activities that are executed by the WF engine. Each activity is actually a class, and it can contain any work that the workflow's creator deems necessary. Activities can potentially be reused across different workflows, making it easier to create automated solutions to new problems.

Figure 2

Another challenge in providing a common workflow technology stems from the traditional division between human-oriented and system-oriented workflows. Workflow applications that are used primarily by people need to be flexible, allowing things such as on-the-fly changes to the process. Those used primarily by systems, that is, by software, tend to be more static, but must be as efficient as possible. WF is intended for both kinds of uses, and so it includes human-oriented features, such as the ability to make changes to a running workflow, along with support for more system-oriented behaviors.

By providing a common workflow technology for Windows in WF, the .NET Framework 3.0 makes this useful paradigm for building software generally available to developers. As a process-oriented view of software continues to gain in popularity, the use of workflow will likely grow as well.

Windows Communication Foundation: Support for Service-Oriented Applications

Whether they're built using workflow or with some other approach, most applications need to communicate with other applications. How this communication is done has taken a big step forward in the last few years. After decades of disagreement, all of the major vendors have agreed to support the same protocols for application communication. Based on SOAP, this global agreement on Web services makes interoperability between applications built on different technology platforms, such as J2EE and the .NET Framework, significantly simpler than it has been in the past. It also makes the idea of service-oriented architecture much more plausible for most organizations.

Plenty of approaches to communication already exist, of course. In the .NET Framework 2.0, for example, the choices include the following:

  • ASP.NET Web Services, providing interoperable SOAP-based communication.
  • .NET Remoting, focusing on communication between .NET applications.
  • Enterprise Services, offering support for scalable, transactional applications.
  • System.Messaging, supporting queued messaging through Microsoft Message Queuing (MSMQ).
  • Web Services Enhancements (WSE), an extension to ASP.NET Web Services that provides support for more recent specifications such as WS-Security.

All of these technologies have value, and all have had a role to play. Yet why are there several different solutions to address what is essentially the same problem? Why not instead create a single foundation for application communication based on interoperable services?

This is exactly what's done by Windows Communication Foundation (WCF). Rather than requiring developers to use a different technology with a different application programming interface for each kind of communication, WCF (originally code-named "Indigo") provides a common approach using a common API. In the .NET Framework 3.0 environment, most applications that might have used one of the technologies just listed will instead use WCF for communication.

WCF provides strong support for interoperable communication through SOAP, an essential part of modern computing. This includes support for several of the WS-* specifications, including WS-Security, WS-ReliableMessaging, and WS-AtomicTransaction. WCF doesn't require SOAP, however, and so other approaches can also be used, including an optimized binary protocol, queued messaging using MSMQ, and simple REST-based communication. WCF also takes an explicitly service-oriented approach to communication. Rather than attempt to provide transparent communication between objects, WCF interposes the slightly different abstraction of a service between the communicating parties. One result of this is to loosen some of the tight couplings that can exist in distributed object systems, making interaction less error-prone and easier to change.

Communication between applications, whether within an organization or across organizations, is a fundamental part of modern software. The .NET Framework 3.0 addresses this challenge by using the service-oriented approach of WCF.

Windows CardSpace: Consistent User Control of Digital Identities

Think about how people represent themselves today on the Internet. In the majority of cases, a person's digital identity is expressed as a simple username. Combined with a password, this identity is used to access email accounts, Internet merchants, and even on-line banks and other financial institutions. Yet despite their simplicity (and ubiquity), usernames and passwords have several drawbacks. Here are the two most important:

  • People have a hard time remembering all of the usernames and passwords they've chosen for different sites. Many people use the same values for different sites, easing the memory problem but increasing the security risk.
  • Usernames, passwords, and other personal information can be stolen by phishers. By sending deceptive emails, phishers entice their victim to log in to a Web site that looks just like, say, the site of the victim's bank. The site is actually controlled by the phisher, however, and so once the victim enters his username and password, the phisher can use this information to masquerade as the user at the real site.

Reducing the severity of these problems requires a new approach to managing digital identities. Windows CardSpace, originally code-named "InfoCard," is an important part of that approach. To help people keep track of their digital identities, CardSpace represents each identity as a distinct information card. If a Web site accepts CardSpace logins, users attempting to log in to that site will see a CardSpace selection screen like the one shown in figure 3. By choosing a card, users also choose a digital identity that will be used to access this site. Rather than remembering a plethora of usernames and passwords, users need only recognize the card they wish to use. Different cards can also contain different information, allowing users to control exactly what each site learns about them.

Figure 3

The identities represented by these cards are created by one or more identity providers. Any organization can offer an identity provider, and rather than relying on simple usernames and passwords, the identities each one provides will typically use stronger cryptographic mechanisms to allow users to prove their identity. CardSpace itself also includes a self-issued identity provider that runs on client machines. With this provider, users can create their own identities that don't rely on passwords for authentication. Web sites can accept these self-issued CardSpace identities rather than relying on the usual password-based approach, reducing the problems that passwords bring.

If passwords aren't used to log in to a site, phishers can't steal those passwords. Still, if phishers can trick a user into logging into a bogus site, they might be able to acquire other information from the user, such as sensitive medical information. Preventing this requires that users be able to distinguish real sites from the look-alike fakes created by phishers. To allow this, the organization that owns a Web site can get a high-assurance certificate. Unlike today's simple SSL certificates, acquiring this new kind of certificate involves a much more rigorous process, including stronger proof that the organization applying for it actually is who it claims to be. A high-assurance certificate can also carry a company's logo and other information to help the user correctly determine whether a site using this certificate is legitimate. When a user accesses a new site, CardSpace always displays the information in that site's certificate using a standard screen. Based on the strength of the certificate received, this screen will indicate different levels of assurance of the site's identity. The goal is to force users to make an explicit decision to trust a site, then help them make the right choices about which sites to trust.

Windows CardSpace is actually part of a larger identity metasystem. Based entirely on open, public protocols, this metasystem defines a way to use different digital identity technologies consistently across diverse platforms (including operating systems other than Windows) and diverse applications (including Web browsers other than Internet Explorer). By providing a common way to select identities and more for Windows, CardSpace fills a key role in the metasystem. And by addressing the fundamental problem of identity, CardSpace also plays an important part in the .NET Framework 3.0.

Windows Presentation Foundation: A Unified Approach to Diverse User Interfaces

The user interface is an important part of nearly every application. Yet what users expect from those interfaces has advanced significantly. Traditional menu-driven GUIs are still required, of course, but applications may also need to display video, run animations, use two- and three-dimensional graphics, and work with various kinds of documents. And all of this must be possible whether the application is accessed from a stand-alone desktop client or through a Web browser.

Traditionally, all of these aspects of the user interface have been provided in different ways on Windows. For example, a developer can use Windows Forms, part of the .NET Framework, to build a Windows GUI. Creating a Web browser interface requires using HTML and perhaps Java applets or JavaScript code. Displaying video might rely on Windows Media Player or software such as Adobe's Flash Player, while document formats might be defined by Microsoft Word or Adobe's PDF or something else. The challenge for developers is clear: building a coherent user interface for different kinds of clients using diverse technologies isn't simple.

A primary goal of Windows Presentation Foundation (WPF), originally code-named "Avalon," is to address this challenge. By offering a consistent technical underpinning for all of these user interface aspects, WPF makes life simpler for developers. By taking a more modern approach, including support for video, animation, two- and three-dimensional graphics, and various kinds of documents, WPF can let users work with information in new ways. And by providing a common foundation for desktop clients and browser clients, WPF makes it easier to build applications that address both.

The example interface shown in figure 4, containing images, live graphics, three-dimensional views, and more, illustrates some of what WPF provides. Rather than requiring developers with skills in diverse technologies, user interfaces like this one can now be created in a more consistent way.

Figure 4

One challenge that has long faced the creators of user interfaces stems from the different roles required for building effective interfaces. Software developers are needed to create the logic behind the interface, but they're rarely the best people to define the interface's look and feel. Designers, specialists in human/machine interaction, are typically a much better choice for this role. Yet older technologies such as Windows Forms are focused entirely on the developer. There's no truly effective way for developers and designers to collaborate. To address this problem, WPF relies on the eXtensible Application Markup Language (XAML). An XML-based language, XAML allows specifying a user interface declaratively rather than in code. This makes it much easier for tools to generate and work with an interface specification based on the visual representation created by a designer. In fact, Microsoft is providing a new product, Expression Interactive Designer, to do exactly this. Designers will be able to use this tool (and others provided by third parties) to create the look of an interface, then have a XAML definition of that interface generated for them. The developer imports this definition into Visual Studio, then creates the logic the interface requires.

When developers create a stand-alone WPF application, one that runs directly on Windows, they have access to everything WPF provides. To create a client that runs inside a Web browser, however, developers can build an XAML browser application, commonly referred to as an XBAP. Built on the same foundation as a stand-alone WPF application, an XBAP allows presenting the same style of user interface within a downloadable browser application. The same code can potentially be used for both kinds of applications, which means that developers no longer need different skill sets for desktop and browser clients. As is typical for this kind of rich Internet application, an XBAP downloaded from the Internet runs in a secure sandbox, which limits what the application can do. Still, a large subset of the user interface functionality available to a stand-alone WPF application can also be used in an XBAP.

Both WPF stand-alone applications and XBAPs can take advantage of WPF's modern graphics support, including the ability to use hardware acceleration, support for vector graphics, and more. By providing support for more powerful graphics, WPF makes possible a range of data visualization options that aren't possible with Windows Forms or other earlier technologies. WPF also provides the foundation for the XML Paper Specification (XPS), which defines a standard format for viewing, distributing, and printing fixed-format documents.

User interfaces are a complex and important part of modern applications. Through WPF, the .NET Framework 3.0 presents a more complete and consistent solution to the challenges these interfaces present. The goal is to let people who create user interfaces—both developers and designers—do their jobs more effectively.

Applying the .NET Framework 3.0: A Scenario

One way to understand how a group of technologies works 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.0, this application might look something like figure 5.

Figure 5

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, for instance, the activities in this workflow use ADO.NET.

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 stand-alone WPF application. This client communicates with the application's business logic using 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 over the Web, and insurance agents can submit applications, as well. To allow this, the application uses ASP.NET to communicate with Web browsers. As shown in the lower left corner of the diagram, customers using Internet Explorer to access this application through an ordinary HTML interface can still use CardSpace to select the identity they wish to present. Third parties can also implement an identity selection mechanism for other client operating systems and browsers, allowing the identity metasystem to extend to non-Windows clients and Web browsers.

Insurance agents who access this application over the Internet may well need a more functional interface. Accordingly, they can rely on an XBAP rather than a simple HTML interface. As shown in the lower center of the diagram, this gives those customers 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.0's most important 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 3.0 can be used in concert to address real business problems.

Understanding the .NET Framework 3.0: The Technologies

To really get a feel for what the .NET Framework 3.0 provides, it's useful to dig a little deeper into each of its constituent technologies. This section provides a short tutorial on each of the five parts of the .NET Framework 3.0. For a more detailed introduction to each one, see For Further Reading at the end of this paper.

The .NET Framework 2.0

Figure 6

The .NET Framework 2.0 is a fundamental part of Windows development today, and it's also the foundation of the .NET Framework 3.0. Figure 6 illustrates the Framework's two parts: the Common Language Runtime (CLR) and the .NET Framework class library. Some components of the .NET Framework 3.0, including WF, WCF, and WPF, are implemented largely as extensions to the .NET Framework class library. As described earlier, however, while many parts of the class library remain an important part of a developer's world, others are subsumed by new technologies provided by the .NET Framework 3.0. ASP.NET, for example, is still the foundation for creating browser-accessible applications, and ADO.NET is still used to work with stored data. .NET Framework 3.0 developers might use WPF rather than Windows Forms to create a native Windows GUI, however, and they'll typically prefer WCF over ASP.NET Web Services, .NET Remoting, or Enterprise Services. Despite these changes, it's important to understand that even in a NET Framework 3.0 world, the previous version of the Framework remains a central part of a developer's life.

Windows Workflow Foundation

A process-oriented design, driven by a workflow, can be the right approach for a significant fraction of Windows software. The purpose of WF is to let developers create and execute these workflow-based applications. Figure 7 shows the components WF provides to do this.

Figure 7

As described earlier, every workflow is built from some number of activities. Both workflows and activities are just classes, so both can be created directly in code. WF also provides the Workflow Designer, a Visual Studio-hosted graphical tool for constructing workflows. However a workflow is created, its activities can be drawn from the Base Activity Library (BAL) provided with WF or from any other source.

Once a workflow has been defined, it's eventually executed by the WF runtime engine. This engine relies on a group of runtime services for persisting the workflow's state, tracking the workflow's execution, and more. All of these things—the runtime services, the runtime engine, and the workflow itself—are contained within some host process. This process can be any Windows process, ranging from a simple console or WPF application running on a desktop to a scalable server process.

Understanding WF requires knowing at least a little about all of its components. The following sections take a brief look at each one.

Workflows

Stripped to its essentials, a workflow is nothing more than a group of activities. WF provides built-in support for two styles of workflow:

  • Sequential workflows, which execute activities in a defined order. Like a traditional flow chart, a sequential workflow can contain branches, loops, and other control structures. By default, however, activities execute in sequence, one after another.
  • State machine workflows, which implement a traditional finite state machine. Like any state machine, which activity executes at a particular time is determined by the combination of the current state and whatever event has been received.

The sequential option is useful for well-defined workflows, such as those used in purely software-based processes. They're relatively simple to create and understand, and they initially feel more natural to most developers. State machine workflows are a better choice when the path of execution is less predictable. A good example of this is a workflow that involves interactions with people, any of whom can cancel the workflow at any point. Addressing this situation with a sequential workflow is possible, but every step could be a branch: Do this if the workflow isn't cancelled, do something else if it is cancelled. Modeling this kind of behavior using a state machine is significantly simpler, since a request to cancel the workflow is just another event that can be received and handled at any point.

Support for state machine workflows is one example of how WF attempts to provide support for human as well as system workflow. Another example of this is WF's support for changing a running workflow. People can be capricious, and it's not uncommon for someone involved in a workflow to wish to add a step, delete a step, or make some other change in the process while it's underway. To accommodate this in a controlled way, WF allows the developer who creates a workflow to specify whether and how that workflow can be modified while it's executing.

The Base Activity Library

Developers are free to create custom activities. In fact, Microsoft's goal is to foster the growth of a WF ecosystem full of reusable activities. Still, starting with a common set of fundamental activities makes life simpler for everyone. Providing this common set is the role of the Base Activity Library (BAL).

A workflow isn't required to use anything from the BAL. Still, many developers will find that the BAL makes their lives simpler, especially at first. Among the activities contained in the BAL are the following:

  • IfElse: executes the activities contained in two or more possible paths based on whether a condition is met.
  • While: repeatedly executes one or more activities as long as a condition is true.
  • Sequence: executes a group of activities one at a time in a defined order.
  • Parallel: executes two or more groups of activities in parallel.
  • Code: executes a defined chunk of code.
  • Listen: waits for a specific event, then executes one or more activities when that event is received.
  • InvokeWebService: calls a Web service.
  • State: represents a state in a workflow's state machine.
  • EventDriven: defines a transition containing one or more activities that should be executed when a specific event is received while in a particular state.
  • Policy: allows defining and executing business rules using a WF-supplied rules engine.

Rather than define a particular language for specifying workflows, WF instead takes the more general approach of using activities. The BAL provides one "language," but everybody using WF is free to define their own, as well.

Tools for Windows Workflow Foundation: The Workflow Designer

One of the advantages of creating applications using workflows is the ability to define the workflow graphically. WF's Workflow Designer allows this, as shown in figure 8. By default, the activities in the BAL appear in the Toolbox, letting a developer drag and drop them onto the tool's design surface to create a workflow.

Figure 8

Some developers prefer to write code—they don't like graphical designers. WF allows this approach, too (and sometimes requires it: activities are generally built directly in code). It's also possible to combine the two approaches, creating a workflow using both the Workflow Designer and direct coding. The goal is to let developers use the approach that's most productive for them. And to allow broader tool support, workflows can also be expressed in XAML, the same language used by WPF. In fact, workflows created using the Workflow Designer default to a XAML definition.

The Runtime Engine and Runtime Services

As described earlier, the WF runtime engine has the job of executing the activities in a workflow. As part of doing this, it relies on a group of runtime services. WF includes standard implementations of these services, but ambitious developers can replace them if desired. These services support a few different things, but two stand out as most interesting:

  • Persistence: A workflow that's blocked waiting for some event can use this service to have its in-memory state automatically persisted to disk. When the event occurs, the service will automatically reload the workflow's state and restart execution. This is especially useful for workflows that involve people, since hours, days, or more might elapse while waiting for a response.
  • Tracking: The activities in a workflow cleanly demarcate the execution of the process they implement. WF's tracking service allows a developer to cause information about the workflow's execution to be automatically written to a database. For example, a developer might wish to track when a workflow starts and ends, when each of its activities starts and ends, and other information.

Windows Workflow Foundation and Other Microsoft Technologies

Introducing new approaches inevitably influences what already exists. The new technologies in the .NET Framework 3.0 are no exception, and each one has an impact on other Microsoft technologies. With WF, the initial impact is felt most strongly by Windows SharePoint Services, the Microsoft Office 2007 system, and BizTalk Server.

To let developers more easily create workflow applications for document collaboration and other kinds of information sharing, Windows SharePoint Services, version 3 hosts the WF runtime. Office SharePoint Server 2007, part of the Office 2007 system, builds on the WF support in Windows SharePoint Services. Among other things, adding this server allows displaying InfoPath forms directly in Office 2007 client applications and using a set of pre-defined workflows for common scenarios such as approving a document.

Anyone familiar with BizTalk Server has certainly noticed by now the similarity between this product's orchestration capabilities and what WF provides. In fact, the release following BizTalk Server 2006 will replace the product's existing orchestration function with WF, providing tools to help migrate existing orchestrations to WF workflows. It's important to understand, however, that WF and BizTalk Server 2006 address quite distinct problems:

  • WF provides a general framework for creating workflow-based Windows applications. It can be hosted in any process, use any kind of activities, and address any kind of business problem, including both human and system workflows.
  • BizTalk Server is a licensed product focused on enterprise application integration, business-to-business integration, and managing business processes. It offers a large set of adapters for connecting to diverse systems and software, accelerators for implementing standards such as RosettaNet and SWIFT, and support for business activity monitoring. BizTalk Server also provides a management infrastructure and tools, along with support for increased scalability.

Because it's the standard workflow technology for Windows, WF may well show up in other Microsoft products and technologies in the future. Whatever Microsoft chooses to do, WF will certainly find a home in a number of applications created by its customers.

Windows Communication Foundation

The change to service-oriented communication marks a shift in how applications interact. Explicitly designed to support service-oriented applications, WCF reflects this shift. This section describes the most important aspects of WCF, including services and clients, communication options, and support for security, reliable communication, and transactions.

Services and Clients

Figure 9

As figure 9 shows, the fundamental idea of WCF is simple: a service exposes an interface that can be accessed by a client. That interface can be defined using the Web Services Description Language (WSDL), then turned into code, or it can be defined directly in a language such as C# or Visual Basic. For a simple interface exposing an insurance application service, the latter approach might look something like this:

[ServiceContract]
interface IInsuranceApplication
{
 [OperationContract]
 int Submit(int policyType, string ApplicantName);

 [OperationContract]
 bool CheckStatus(int applicationNumber);

 [OperationContract]
 bool Cancel(int applicationNumber);
}

The definition of this C# interface is marked with the ServiceContract attribute. This attribute indicates that WCF can expose methods in this interface as remotely-callable operations. Which of the interface's methods are exposed depends on which are marked with the OperationContract attribute. In this simple example, every method is marked with this attribute, and so all of them will be exposed to remote callers. This isn't required, however—it's legal to apply OperationContract to only some of an interface's methods. Whichever choice is made, some class in the application must implement this interface, providing actual code for the methods the interface defines. Once this is done, WCF automatically makes the methods marked with OperationContract accessible to clients of this service.

Figure 10 gives a slightly more detailed view of how a service is actually exposed to its clients. Rather than access an interface directly, a client instead connects to a specific endpoint. A service can expose multiple endpoints, potentially allowing different clients to access it in different ways.

Figure 10

As the figure shows, each endpoint specifies three things:

  • A contract describing the operations that can be invoked using this endpoint. The contract can be identified using just the name of the interface that defines these operations, which here is IInsuranceApplication.
  • A binding defining how the endpoint's operations can be invoked. Each binding defines several things, including what protocol should be used to invoke the operations, what kind of security should be used, and more. WCF includes a set of pre-defined bindings, such as the BasicHttpBinding shown here, for the most common cases, and it's also possible to define custom bindings. Because a single service can expose multiple endpoints, it can simultaneously allow access to different kinds of clients over different protocols and with different security options.
  • An address indicating where this endpoint can be found. As shown in the figure, the address is represented as a URL.

The basics of WCF are simple. As with most communication technologies, the details can get complex—there are many options—but creating ordinary WCF applications isn't hard.

Communication Options

Different kinds of applications built by different kinds of developers need different ways to communicate. The simplest approach for most developers is remote procedure call (RPC), which lets a client invoke remote operations much like local ones. Given the interface shown earlier, for example, a client could invoke any operation in the usual synchronous way, waiting patiently until a response comes back. This option is easy for developers, and it's the right choice in some circumstances.

WCF also provides several other options, however. They include the following:

  • Calls that have no response. Marked with the attribute OneWay, this kind of communication can be useful for sending events or other one-way interactions.
  • Asynchronous message-based communication, using direct sends and receives with XML messages.
  • Explicit manipulation of SOAP messages, including the ability to insert elements directly in the SOAP header.

WCF also allows developers to control various local aspects of how a service behaves. Using the ServiceBehavior attribute, for example, they can set whether the service is single or multi-threaded, whether a new instance of the service is created for each call, and other options.

Security, Reliability, and Transactions

Basic communication—the ability to move data between systems—is useful, but it's rarely enough. Most applications need more. For example, the great majority of distributed applications need some kind of security. Providing security can be complex, given the range of different approaches and diversity of technologies in use today. To let developers create secure distributed applications without forcing them to understand all of the details, WCF relies primarily on bindings for security. For example, the BasicHttpBinding shown earlier can be configured to use HTTPS rather than plain HTTP, and other bindings provide more security options. WsHttpBinding, for instance, supports WS-Security, allowing interoperable SOAP-based authentication, data integrity, and data confidentiality. Developers can also create a custom binding that provides the exact security services their application needs.

Making sure that communication is reliable is also essential for many applications. The traditional Web services approach, sending SOAP over HTTP, is sufficient in some cases, and it's what's done when the BasicHttpBinding is used. There are plenty of situations, however, in which this widely-used choice isn't enough. Messages that go through one or more SOAP intermediaries, for instance, can't rely on this simple approach for end-to-end reliability. For these cases, WCF implements WS-ReliableMessaging. By choosing a binding that supports this option, such as WsHttpBinding, a developer can automatically get interoperable reliable message transfer.

Distributed transactions can also be important in some applications. WCF builds on System.Transactions, part of the .NET Framework 2.0, to allow the creation of transactional software. A method can use the OperationBehavior attribute to indicate that it requires a transaction and to define how that transaction behaves. To allow distributed transactions that are interoperable across vendor boundaries, WCF relies on the WS-AtomicTransaction specification. Using the technology defined in this multi-vendor agreement, WCF applications can participate in transactions that span diverse technologies, including J2EE and others.

Windows Communication Foundation and Other Microsoft Technologies

As mentioned earlier, WCF supersedes several earlier Microsoft technologies for creating distributed applications. Most applications that would have been built using ASP.NET Web Services, .NET Remoting, Enterprise Services, System.Messaging, or WSE will instead be built on WCF. WCF applications can interoperate with ASP.NET Web Services applications—both support standard SOAP—as well as applications built on Enterprise Services, MSMQ, and version 3.0 of WSE. WCF can also be used by BizTalk Server 2006, and a future version of BizTalk Server will build even more directly on what WCF provides.

It's important to understand that even though new .NET Framework 3.0 applications won't commonly use them, all of the technologies that WCF supersedes are still part of this version of the Framework, and they'll all be supported as usual. Applications built using earlier versions of these technologies will also continue to run normally; installing and using the .NET Framework 3.0 won't break existing code.

Windows CardSpace

Whether it's through a Web browser or some other kind of client, users routinely access applications across a network. Since these applications commonly require users to identify themselves in some way, the inescapable corollary is that people are regularly forced to acquire and present identity information to remote software. Accessing Internet applications through a browser provides a very common example of this, and users on intranets commonly face the problem as well.

As described earlier, people most often rely on usernames and passwords for digital identities today, with all of the problems this entails. Windows CardSpace, part of the larger identity metasystem, offers an alternative approach to addressing these problems. To get a deeper understanding of how CardSpace does this, the place to start is with the basic concepts of the identity metasystem.

Windows CardSpace and the Identity Metasystem

When users access an application, whether from a Web browser or an application-specific client or something else, they commonly present some kind of digital identity. Digital identities come in many varieties, but virtually all of them are represented on the network by a security token. While a simple security token can be just a username, a more complex token might include an X.509 certificate or an XML document. However they're represented, security tokens are today's typical mechanism for representing digital identities on the network.

While it's tempting to believe that we'll all one day adopt a common security token format, the reality is that diverse approaches will continue to be used. Just as we today carry multiple identity cards in our wallet—drivers license, credit card, airline frequent flyer card, and more—we'll always have diverse digital identities represented by diverse kinds of security tokens. No single identity system can provide a universal answer, and so multiple security tokens will always be necessary.

Yet users still need some way to work consistently with their diverse digital identities. Even though no single identity system will suffice, it's possible to create a system of identity systems—an identity metasystem—that allows using a myriad of digital identities in a consistent way. Working with others, Microsoft has led the process of defining this metasystem. Based on open Web services technologies, such as WS-Security and WS-Trust, this metasystem defines how digital identities can be acquired and used, regardless of the type of security token they depend on.

The process of issuing, acquiring, and using digital identities can be thought of as requiring three distinct roles. Those roles are the following:

  • User: Sometimes called the subject, the user is the entity that has a digital identity.
  • Identity provider: An identity provider supplies a digital identity for a user. For the digital identity assigned to you by your employer, for example, the identity provider is typically a system such as Active Directory. For the digital identity you use with Amazon, the identity provider is effectively you, since you define your own username and password. Digital identities created by different identity providers can carry different information and provide different levels of assurance that users really are who they claim to be.
  • Relying party: A relying party is an application that in some way relies on a digital identity. A relying party will frequently use an identity (that is, the information contained in this identity's security token) to authenticate a user, then make an authorization decision, such as allowing this user to access some information. A relying party might also use the identity to get a credit card number, to verify that the same user is accessing it at different times, or for other purposes. Typical examples of relying parties include Internet Web sites, such as banks, online merchants, and auction sites, and any application that accepts requests through Web services.

These three kinds of entities interact in the identity metasystem. Figure 11 illustrates these interactions, along with where CardSpace fits in.

Figure 11

The process begins when a user accesses a relying party through a CardSpace-aware application. To learn what type of security tokens this relying party will request, the application must get the relying party's policy (step 1). For a browser accessing a Web site, which is likely to be the most common case, the site's policy is expressed in HTML and sent back as part of a Web page. For applications accessed through Web services, however, the application instead uses the industry-standard protocol defined by WS-MetadataExchange to ask the relying party for its policy. In this case, the policy is expressed using WS-SecurityPolicy, another industry standard. However the policy information is acquired, it always indicates what kind of security tokens this relying party will accept and what information those tokens must contain.

Once CardSpace knows what kind of security tokens the relying party needs, it displays the identity screen shown earlier. Each digital identity available to this user is represented as an information card on this screen. Cards issued by an external relying party are referred to as managed cards, while those issued by CardSpace's self-issued provider are known as self-issued cards. Both kinds of cards can be shown on this screen, and the user can potentially select one of either type. To make this decision easier, the screen indicates which identities meet the requirements of the relying party by graying out cards that don't qualify. The user then selects one of these as the digital identity he wants to use (step 2).

A card doesn't contain an actual security token, however. Instead, it holds the information necessary to locate a particular identity provider and request a security token for this user. (In fact, each card is originally created by some identity provider.) CardSpace uses the contents of the card selected by the user to request a security token from the identity provider that issued that card (step 3). This request is made using WS-Trust, another industry-standard protocol, and users authenticate themselves to the identity provider using Kerberos, an X.509 certificate and digital signature, or another mechanism. The token is returned in an encrypted form, which also contains a timestamp to prevent this token from being stolen off the wire and reused in the future.

Once the requested security token is returned, it's sent to the relying party (step 4). How the relying party uses the information in the token can vary. If the token contains an X.509 certificate, for example, and is accompanied by a digital signature, the relying party will likely use the token to authenticate the user. There's no requirement that tokens be used for authentication or for any other security-related purpose, however. (In fact, the term "security token" is a misnomer.) A token might carry information such as proof of a user's age, eligibility for a discount at an Internet shopping site, or anything else. Authentication is one important use for security tokens, but it's not the only option.

It's important to note that neither CardSpace nor the identity metasystem as a whole is aware of the format or technology used for the security token. Rather than trying to create a new single source for digital identities or a standard format for security tokens, the goal of the metasystem is to provide a coherent way to use any digital identity based on any kind of security token. By providing a Windows implementation of key parts of the metasystem, CardSpace plays an important role in making this general approach to digital identity a reality.

Fighting Phishing

Identity providers are often distinct from the user, such as when an identity is assigned by an employer. Yet there are plenty of situations in which the identity provider is actually users themselves. If CardSpace isn't used, for instance, accessing many Web sites requires giving a username and password, both of which are defined by users. Once the users have created this identity, they can later supply the username and password, then check their bank balance, buy a book, or do whatever else this site allows.

Because they depend on passwords, however, these kind of self-issued identities are targets for attackers, as described earlier. To help reduce these attacks, CardSpace provides an alternative way to create a self-issued identity. This self-issued identity provider runs locally on the user's Windows system. Rather than relying on a username and password, the security tokens created by the self-issued identity provider are defined using the Security Assertion Markup Language (SAML), an OASIS-defined standard. These tokens rely on public key technology rather than passwords to prove the user's identity, and if a relying party accepts them, they can play the same role as the traditional username and password. The advantage is that there is no longer a password for phishers to steal. Reducing the use of passwords, together with the stronger proof of a site's identity provided by the high-assurance certificates described earlier, can make phishing a much less serious problem.

Windows CardSpace and Other Microsoft Technologies

CardSpace is related to several other Microsoft technologies, including the following:

  • WCF: Because it relies on Web services standards such as WS-Security and WS-Trust, CardSpace uses WCF for communication. In fact, the creator of a WCF application can cause that application to use CardSpace just by specifying a particular binding.
  • Active Directory: Although it's not possible today, Active Directory will eventually be able to act as an identity provider in the metasystem.
  • Windows Live ID (formerly known as Passport): As with Active Directory, Microsoft has announced that its Live ID authentication system will also be modified to act as an identity provider. Note that CardSpace isn't a replacement for Live ID, since the two address quite different problems. Instead, Live ID will become part of the identity metasystem just like any other identity provider.

Microsoft also provides other identity-related technologies that address somewhat different problems than CardSpace. Active Directory Federation Services (ADFS), for instance, focuses on federating identities across organizations. This is an important challenge, and it's faced by many firms that need to work with other organizations. This problem is quite distinct, however, from the broader issues addressed by CardSpace and the identity metasystem.

Windows Presentation Foundation

Workflow-based logic, service-oriented communication, and identity are all important in modern applications. Yet users often care most about what they see: the user interface. The goal of WPF is to address the challenges of creating user interfaces for modern applications. As described next, WPF provides a range of capabilities to do this.

The Capabilities of Windows Presentation Foundation

A developer is free to create a WPF application's interface entirely in C#, Visual Basic, or some other CLR-based language. As described earlier, however, WPF also allows specifying an interface using the XML-based XAML. Elements and attributes in XAML map directly to the classes and properties that WPF provides. For example, here's a simple button defined in XAML:

<Button Background="Red">
 No
</Button>

This example creates a red button that contains the text "No." The exact same result could also be produced with the following code:

Button btn = new Button();
btn.Background = Brushes.Red;
btn.Content = "No";

However it's defined, virtually every WPF application follows the same basic model. The application inherits from WPF's standard Application object, which provides basic methods, events, and properties. A WPF application can have either a traditional dialog-driven interface or a navigational interface, letting it function much like a browser application. An application built in the latter style is typically implemented as a group of pages, each consisting of a user interface defined in XAML together with some logic defined in code. To link these pages together, XAML provides a Hyperlink element, much like HTML. The application displays one page at a time, lets a user move back and forth among its pages, maintains a history list, and more. Although a navigation application can run inside a Web browser as an XBAP, this isn't required; a developer is free to use this interface style in stand-alone WPF applications, as well. The goal is to create software that combines the best aspects of a browser interface and a native Windows interface.

Whatever style its interface uses, a WPF application can rely on panels for basic layout. Each panel typically contains controls, and those provided by WPF include Button, TextBox, ComboBox, Menu, and many more. How those controls are positioned depends on what type of panel is chosen. A Grid, for instance, allows positioning controls on a specified grid, while a Canvas lets the developer place controls anywhere within its boundaries. And as usual in a GUI, events generated by the user are caught and handled by the various controls and other classes in the application. It's also possible to apply styles and templates to groups of controls, which makes it easier for applications to have a uniform look.

WPF supports much more than these basic user interface functions, including the following:

  • Documents: A WPF application can display XPS documents using XAML's FixedDocument tag. An application can also display flow documents using the FlowDocument tag. A flow document can behave like a traditional on-screen document, allowing the user to scroll through its contents. By setting various attributes on this tag, however, a developer can make the document more adaptive to its surroundings. A document can display a page at a time, for example, freeing its reader from the need to scroll back and forth. WPF can also automatically determine how many columns a document should be broken into based on the size of the window in which it's displayed. The goal is to allow on-screen documents to be as readable as possible.
  • Graphics: WPF includes support for creating two-dimensional and three-dimensional vector graphics. For 2D work, WPF provides standard abstractions such as shapes, brushes, and pens, while allowing 3D graphics to define a model that can be assigned lighting and camera position information. Unlike earlier technologies such as Windows Forms, which relies on GDI+ for graphics, WPF graphics aren't partitioned off using a separate set of concepts that developers must understand. Instead, the XAML elements used for graphics can be combined naturally with those used for anything else in a user interface. Buttons can have graphical content, text and graphics can be combined, and more.
  • Images: Using XAML's Image tag, a WPF application can display images in various formats, including JPEG, GIF, and others. WPF relies on the Windows Imaging Component (WIC) to provide a standard framework for codecs, software that displays and stores images. As usual in WPF, an Image element can be combined with others, allowing things such as a button that displays an image rather than a simple text label.
  • Media: A WPF application can use the MediaElement tag to display video and audio in various formats, including WMV, AVI, and MPEG. Once again, this element can be combined with other XAML elements, allowing things such as a 3D cube that displays video on its sides.
  • Animation: WPF provides built-in support for animating most parts of a user interface. A circle can grow and shrink, for example, or a button can smoothly change size. Applications can also define storyboards containing timelines, allowing coordinated sequences of animations to occur.
  • Data Binding: Because many WPF applications display data, it's useful to have automatic support for mapping data to user interface elements. WPF provides this kind of data binding for information contained in objects and other sources. WPF data binding also allows sorting and filtering data before it's displayed.

Applying Windows Presentation Foundation

WPF provides a large set of user interface functionality, allowing developers and designers to create very appealing user interfaces. Yet no matter how lovely a client application looks, some organizations might resist using it because of deployment issues. If rolling out a new version of the client requires physically touching every desktop machine that this application is installed on, the cost of upgrades can be significant. One common way to avoid this problem today is to create browser-based clients rather than native Windows clients. Yet native Windows clients can generally have better, more responsive user interfaces than browsers. To address the challenge of deploying these clients, stand-alone WPF applications can be put into place using ClickOnce. A technology that first appeared in the .NET Framework 2.0, ClickOnce lets Internet Explorer users select an application over the Web, then have it automatically installed on their local machine. Once installed, the application can also be automatically updated when a new version is made available. The goal is to combine the simplicity and inexpensive deployment of a Web client with the power and functionality of a stand-alone WPF application.

Especially when they're deployed using ClickOnce, stand-alone WPF applications are a good client choice in many situations. Yet there are cases where this kind of application isn't appropriate, even when its users could benefit from the kind of interface that WPF allows. Think about the remote insurance agents in the scenario described earlier, for instance, or an Internet merchant that wishes to provide 3D graphics, video, and the other modern features that WPF supports. It often won't be reasonable to expect this application's users to install a native WPF application to access the site. A better solution would be to give users a WPF-style interface inside their Web browser.

XAML browser applications—XBAPs—are designed to do this. Rather than deploying a stand-alone WPF application, an Internet Explorer user can download an XBAP directly into the browser. Running inside Internet Explorer, this application can then present the user with a WPF-based user interface. Yet downloading and running code from Internet Web sites can be dangerous. To protect the user from malicious developers, all XBAPs downloaded from the Internet run in a partially trusted sandbox. Based on the code access security provided by the .NET Framework, this sandbox limits what XBAPs can do. For instance, an XBAP downloaded from the Internet can't create stand-alone windows or launch new windows, display a Save dialog launched by the XBAP itself, or access the file system except in an isolated storage area. Yet despite the restrictions imposed by the sandbox, an XBAP can still use a large fraction of WPF functionality, including 2D and 3D graphics, animations, on-screen documents, images, video, and more.

As described earlier, WPF lets applications display adaptive documents using XAML's FlowDocument element. Documents whose appearance changes based on how they're displayed aren't always the best solution, though. Fixed-format documents, which always look the same on a screen and a printer, are sometimes a better choice. WPF's XPS documents address this problem. Defined using a subset of XAML, XPS documents can be read on any system that provides an XPS reader. They also provide a new print format for Windows, allowing complex graphics to be printed with more fidelity. And to make working with different kinds of documents more consistent, both XPS documents and Office 2007 documents use Microsoft's Open Packaging Conventions, which define common ways to store document content, digitally sign documents, and more.

Tools for Windows Presentation Foundation

It's possible to create any WPF user interface directly in code and/or XAML using a basic text editor. Most people would prefer to work with better tools, however, and so Microsoft provides extensions to Visual Studio 2005 that let developers create WPF applications. The next release of Visual Studio, code-named "Orcas," will provide still more capability with the Visual Designer for Windows Presentation Foundation. Using this tool, developers will be able to graphically create the user interface they wish to see, then let the tool generate the code for this interface.

Yet developers often aren't the best people to define user interfaces. Designers are usually much better at this kind of work, since they specialize in communicating with people. Most designers don't write code, though, and so the Visual Designer for Windows Presentation Foundation, hosted inside Visual Studio, isn't an effective tool for this group. To let designers work effectively in the WPF world, Microsoft has created Expression Interactive Designer. A designer can use this tool to define the look and feel of an interface, specify animations, and more, then let the tool generate an XAML version of what is created. A developer can import this XAML into Visual Studio and add code for things such as handling events. Because both Visual Studio and Expression Interactive Designer use the same build system, it's possible for developers and designers to work on a project iteratively, each using the tool they're comfortable with. The goal is to help people from the divergent disciplines of design and software engineering work together effectively.

Windows Presentation Foundation and Other Microsoft Technologies

Like other .NET Framework 3.0 components, WPF has an impact on existing Microsoft technologies. The most important of these are the following:

  • Windows Forms: The .NET Framework's original approach for creating application GUIs, Windows Forms is used in many applications today. Recognizing this, WPF allows Windows Forms controls to be hosted in WPF applications and WPF controls to be hosted in Windows Forms applications. For example, a Windows Forms application might host a WPF control that provides three-dimensional data visualization. While there are some limitations, creating applications that use both technologies is certainly possible. Note too that existing Windows Forms applications will continue to work unchanged in a .NET Framework 3.0 world.
  • Win32 and Microsoft Foundation Classes (MFC): As with Windows Forms, it's possible to host WPF controls in existing applications built using these existing technologies, and vice versa. Interoperability is somewhat more complex than with Windows Forms, however, because unlike Windows Forms, Win32-based and MFC-based applications aren't build on the CLR. Accordingly, interoperability with WPF also requires mapping between CLR-based code and native Win32 code.
  • Direct3D: Part of the DirectX family of APIs, Direct3D lets applications create and display 3D graphics. With the advent of the .NET Framework 3.0, mainstream Windows applications can use the 3D capabilities in WPF rather than the more specialized approach that Direct3D provides. Still, some applications that need higher performance, such as 3D games, will continue to use Direct3D. In fact, under the covers, WPF relies on Direct3D for all rendering.
  • Windows Communication Foundation: As was shown in the scenario earlier, WPF applications can use WCF. XBAPs typically cannot use WCF, however, because WCF requires full trust. Every XBAP downloaded from the Internet runs in a partial trust sandbox, which prohibits it from accessing WCF. XBAPs can use ASP.NET Web Services, however, allowing them to make SOAP calls that interoperate with WCF and other Web services implementations.
  • "WPF/E": One more aspect of WPF is also worth mentioning here, even though it's not part of the .NET Framework 3.0. Code-named "WPF/E," its goal is to support WPF-style interfaces on systems that don't support WPF itself. As the "E" in its name suggests, this technology is meant to be available everywhere, including Macintoshes, small devices, and other systems. Scheduled to ship sometime after WPF itself, WPF/E will provide a subset of full WPF functionality, including 2D graphics, animation, and video.

Getting the .NET Framework 3.0: Distribution Options

For an application to use the .NET Framework 3.0, this version of the Framework must be installed on the machines this application runs on. For Windows Vista, this is straightforward: The .NET Framework 3.0 is installed by default. This means that new machines with Windows Vista installed or existing machines upgraded to Vista will automatically be able to run .NET Framework 3.0 applications. The .NET Framework 3.0 can also run on Windows XP and Windows Server 2003, however. To make the new .NET Framework 3.0 components available to existing users of these systems, Microsoft will make this software available as a free download.

Conclusion

The .NET Framework 3.0 is the evolution of the Windows programming model. Built on and extending the .NET Framework 2.0, its goal is to support the creation of modern applications. To do this, version 3.0 of the Framework provides a diverse set of technologies, each addressing a significant challenge in application development today. By building this diversity on a common foundation, Microsoft is striving to make the whole greater than the sum of the parts, letting developers create applications that use the various parts of the .NET Framework 3.0 in a coherent way.

Whatever aspects of this new release an organization chooses to adopt, the technology is certain to have a substantial impact on the world of Windows software. For anyone who works in this world—developer, architect, or decision-maker—the time to start understanding how to benefit from the .NET Framework 3.0 is now.

For Further Reading

Understanding .NET, Second Edition. David Chappell, Addison-Wesley, 2006

Introducing Windows Workflow Foundation

Introducing Windows Communication Foundation

Introducing Windows CardSpace

Introducing Windows Presentation Foundation: (In progress)

 

About the author

David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, he helps technology professionals around the world understand, use, and make better decisions about enterprise software.