Contents 2 Describing the. Net framework 5 3

Дата канвертавання24.04.2016
Памер95.94 Kb.
  1   2   3   4   5

Introducing the .NET Framework 3.5

David Chappell, Chappell & Associates

September 2007

© Copyright Microsoft Corporation 2007. All rights reserved.


Contents 2

Describing the .NET Framework 3.5 3

The Challenges of Building Modern Applications 3

Addressing the Challenges: Spotlighting the .NET Framework 3.5 4

Summarizing the Evolution: The .NET Framework 3.5 and its Predecessors 10

Applying the .NET Framework 3.5: A Scenario 11

Understanding the .NET Framework 3.5: The Technologies 13


Language-Integrated Query 14

Windows Communication Foundation 15

Windows Workflow Foundation 19

Windows Presentation Foundation 24

Windows CardSpace 27

Conclusion 31

About the Author 31

Describing the .NET Framework 3.5

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 demands from customers increase. To meet these demands, the platforms developers build on and the tools they use must get better and better—they must evolve.

The .NET Framework provides a clear example of this. First released in 2002, version 2.0 of the Framework appeared three years later. The .NET Framework 3.0, released in 2006, was a major update that added a number of new technologies, while the latest version, the .NET Framework 3.5, includes more useful additions. Alongside this evolution, Microsoft’s flagship tool for creating .NET applications has also moved forward. The latest release, Visual Studio 2008, offers a range of improvements for creating .NET applications. Every step in this path has been aimed at providing a better and more productive environment for the people who create Windows software.

This overview provides a big-picture view of the .NET Framework 3.5. While a basic knowledge of the .NET Framework is assumed, this description focuses on the technologies added in the .NET Framework 3.0 and 3.5. The goal is to make clear what this widely used foundation for Windows applications provides today.

The Challenges of Building Modern Applications

Creating a modern application is not a simple task—the requirements are substantial. Traditional concerns such as creating effective business logic and allowing access via a Web browser are still important, but they’re no longer enough. Modern applications present a range of new challenges, including the following:

Users increasingly expect Web browser interfaces to act like installed Windows applications. Loading a new page whenever something has changed is no longer sufficient—it’s just too slow. What’s needed is better support for responsive browser applications.

Data remains central to most applications. How that data can be represented, however, has expanded considerably. Relational data is still important, as is mapping between objects and relations. Yet the amount of data represented using XML continues to increase, a trend that’s not likely to change. And even though it’s not always viewed in this way, a running program’s objects also contain data. A technology that allowed consistent access to diverse data would help developers create applications in less time and with fewer errors.

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.

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.

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. Meeting these needs requires a unified approach to diverse user interfaces.

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.

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. The goal of the .NET Framework 3.5 is to do this for Windows software.

Addressing the Challenges: Spotlighting the .NET Framework 3.5

The .NET Framework 3.5 contains a number of technologies that can help developers solve the problems just described. Some were part of the .NET Framework 3.0, while others are new with the 3.5 release. This section introduces the most important of these technologies.

ASP.NET AJAX: Support for Responsive Browser Applications

Web browsers are the most popular user interface for new applications. Still, they’ve traditionally suffered from a significant limitation: Each new request from a user requires a round-trip to the Web server, commonly resulting in loading a new page. A more intelligent—and faster—approach would be to access data in the background whenever possible, then update only those parts of the page that change. Users would see much more responsive applications, since they would spend less time waiting for new pages to be loaded.

This is exactly what’s done by the AJAX approach to building Web applications. Rather than load a new page for each user request, the browser asynchronously requests data in advance. The code that makes this request is typically written in JavaScript, and the data is often (although not always) formatted in XML. These three characteristics—Asynchronous JavaScript and XML—are the source of name AJAX.

Even though the core technologies that underlie AJAX first appeared in the 1999 release of Internet Explorer 5, this approach took several years to become popular. Today, however, AJAX is becoming the dominant style for new Web browser applications. Accordingly, the .NET Framework 3.5 now incorporates a technology called ASP.NET AJAX. An extension to the original ASP.NET, the goal is to make it easier for developers to create AJAX applications.

Language-Integrated Query: Consistent Access to Diverse Data

Most applications work with data in some way. That data can be represented in a variety of ways, including as tables in a relational database, in XML documents, and in objects held in memory. Accessing each of these kinds of data has traditionally required using a different approach. It’s common to use SQL to work with relational data, for example, XQuery for XML data, and custom code for in-memory data. Yet since the intent is the same—accessing information—why not provide a common approach for all of these cases?

This is the goal of Language-Integrated Query (LINQ), a technology that’s new with the .NET Framework 3.5. Rather than requiring specialized languages and a separate approach for each kind of data, LINQ adds a set of extensions to C# and VB that allow common access to diverse information. This technology covers a large area, including object/relational mapping and more. The goal is to make life simpler and more efficient for anybody who creates or maintains .NET Framework applications that work with data.

Windows Communication Foundation: Support for Service-Oriented Applications

From the beginning, the .NET Framework has provided plenty of approaches to communication. Those choices include the following:

ASP.NET Web Services (commonly known as ASMX), 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 via 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 had a role to play. Yet why have several different solutions to address what is essentially the same problem? Why not instead create a single foundation for application communication?

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 provides a common approach using a common API. Originally released as part of the .NET Framework 3.0, WCF is now Microsoft’s recommended approach for communication. Most applications that might have used one of the technologies just listed should instead use WCF for communication.

As the figure below shows, the basic model of WCF is simple: A client accesses some service, invoking operations as required. WCF doesn’t mandate any particular host, and so developers are free to use this communication technology inside any host process.

WCF provides strong support for interoperable communication via 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 a simpler REST-based approach built directly on HTTP.

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

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 create 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. With Windows Workflow Foundation (WF), Microsoft provides a common workflow technology for Windows, giving any workflow-based application a common foundation to build on. Since its release in the .NET Framework 3.0, WF has been used both in software provided by Microsoft, such as Windows SharePoint Services, and in applications created by other organizations.

But how can a single technology 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 the figure below shows, a WF workflow is just a group of activities that are executed by the WF engine in some order. 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.

By providing a common workflow technology for Windows, WF 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 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 standalone desktop client or via 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 something else, while document formats might be defined by Microsoft Word or PDF or in another way. 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 released with the .NET Framework 3.0, 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 below, 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.

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 provides Expression Blend to do exactly this. Designers can 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 reads this definition into Visual Studio, then creates the logic the interface requires.

When a developer creates a standalone WPF application, one that runs directly on Windows, she has access to everything WPF provides. To create a client that runs inside a Web browser, however, a developer can build a XAML browser application, commonly referred to as an XBAP. Built on the same foundation as a standalone 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 standalone WPF application can also be used in an XBAP.

Both WPF standalone 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 making it easier to create 3D graphics, WPF makes available 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.5 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.

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 popularity, 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 into 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 released with the .NET Framework 3.0, 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, a user attempting to log into that site will see a CardSpace selection screen like the one below. By choosing a card, the user also chooses a digital identity that will be used to access this site. Different cards can contain different information, allowing a user to control exactly what each site learns about her.

The identities represented by these cards are created by one or more identity providers. Any organization can offer an identity provider, and 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.

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.5.

  1   2   3   4   5

База данных защищена авторским правом © 2016
звярнуцца да адміністрацыі

    Галоўная старонка