Contents 2 Describing the. Net framework 5 3

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

Understanding the .NET Framework 3.5: The Technologies

To get a better feel for what the .NET Framework 3.5 provides, it’s useful to dig a little deeper into its components. This section provides a short tutorial on each of the technologies spotlighted earlier.


ASP.NET is one of the today’s most popular technologies for creating Web-based applications. AJAX is becoming a dominant approach for designing those applications. These two realities imply that ASP.NET AJAX will be one of the most widely used parts of the .NET Framework 3.5. The figure below illustrates the two main components of this technology.

As the figure shows, an ASP.NET application can use the ASP.NET 2.0 AJAX Extensions. These provide a set of server-side controls for interacting with code in a Web browser. The most important of these controls is UpdatePanel, which allows updating only part of a user-visible page rather than replacing the whole thing. The ASP.NET 2.0 AJAX Extensions also provide Web services that browser code can invoke to access information provided by the application.

For clients, ASP.NET AJAX provides the Microsoft AJAX Library. This library implements a framework for creating client scripts, and it runs in Internet Explorer, Firefox, Opera, and Safari. As in all AJAX implementations, this client code can use an object provided by the Web browser called XMLHttpRequest. By calling a method in this object, a script can request data via HTTP from an application built using ASP.NET or another technology, such as PHP. This request can be made asynchronously, allowing data to be retrieved without forcing the user to block while waiting for a response. The data it returns can then be accessed as XML using the Document Object Model (DOM). Along with XML, ASP.NET AJAX also allows exchanging data represented using the JavaScript Object Notation (JSON).

The AJAX style of Web application was a good idea when the notion first surfaced in 1999. While we’ve had to wait several years for this approach to find its way into the mainstream, AJAX applications are now becoming the norm. Microsoft’s decision to include ASP.NET AJAX in the .NET Framework 3.5 is certain to help speed adoption of this useful approach.

Language-Integrated Query

Creating a common approach for accessing diverse data isn’t an easy task. Making that approach comprehensible to developers—not bogging them down in more complexity—is even harder. To address this, LINQ relies on a common and quite familiar syntax for working with data.

Here’s a simple LINQ query, expressed in C#, that reads data:

var exampleQuery =

from s in Students

where s.Gender == "M"

select s.Name
This query returns the names of all male students as a list of strings stored in the variable exampleQuery. To print out that list, a program might do this:

foreach (string name in exampleQuery) {


The syntax of the query is reminiscent of SQL, today’s standard language for accessing relational data. This makes sense, since SQL is a widely used language, one that many developers know. Yet it’s important to understand that even though it looks somewhat like SQL, the LINQ query shown above isn’t an embedded SQL statement. Instead, it’s pure C#, part of the language itself. This means that the query can use other program variables, be accessed in a debugger, and more. The name of this technology is “Language-Integrated Query” for a reason: the statements for querying diverse kinds of data are integrated directly into the programming language.

And despite its similarity to SQL, this example query isn’t limited to accessing only relational data. In fact, the .NET Framework 3.5 includes several different LINQ variations, all of which use the same basic syntax for queries. Those variations include the following:

LINQ to ADO.NET: Provides object/relational (O/R) mapping. This aspect of LINQ includes two options. The first, LINQ to SQL, translates a query like the one above into a SQL query, then issues it against tables in a SQL Server database. The second option, LINQ to DataSet, executes a query like the one shown above on the contents of a DataSet returned by ADO.NET

LINQ to Objects: Allows querying collections of in-memory data structures, such as object hierarchies. The query above could also be issued against this kind of data—despite its similarity to SQL, it’s not limited to accessing only data in tables.

LINQ to XML: Allows querying XML data. This approach uses a slightly different syntax, reflecting the unique needs of mapping between the world of XML and a programming language, but the basic structure of a LINQ query remains the same.

Like SQL, LINQ also defines other operators for queries. They include things such as OrderBy, which determines how results are ordered; GroupBy, which organizes selected data into groups; and arithmetic operators such as Sum. And once again, these can be used generally across the LINQ varieties—they’re not just for the LINQ to SQL option.

LINQ’s creators aimed at several targets, including providing O/R mapping for .NET applications, allowing a common syntax for working with different kinds of data, integrating that syntax directly into the programming language, and more. As with everything else described in this introduction, the goal is to make life better for developers working with Visual Studio 2008 and the .NET Framework 3.5.

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

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:


interface IInsurance



int Submit(int policyType, string ApplicantName);

bool CheckStatus(int applicationNumber);

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.

The figure below 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.

As the figure shows, each endpoint specifies three things:

An address indicating where this endpoint can be found. As shown in the figure, the address is expressed as a URL.

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, each with a different binding, it can simultaneously allow access to different kinds of clients over different protocols and with different security options.

A contract describing the operations that can be invoked via this endpoint. The contract can be identified using just the name of the interface that defines these operations, which here is IInsurance.

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.

Support for REST and RSS/ATOM

In its original release in the .NET Framework 3.0, WCF’s Web services support was focused on SOAP. Another approach to Web services can be better in some cases, however. Known as Representational State Transfer (REST), it’s built directly on the technology of the Web itself. Rather than defining a new protocol, as did the creators of SOAP, REST relies on the built-in operations in HTTP: GET, POST, and others. And rather than identify the information to be accessed with parameters defined in XML, as SOAP typically does, REST assumes that everything is identified with a URL.

To support this approach, WCF in the .NET Framework 3.5 adds a new binding, WebHttpBinding, that sends information directly over HTTP. It also adds two new attributes, as this example shows:


interface IAccount




int GetBalance(string account);


int UpdateBalance(string account, int amount);

This simple interface exposes a RESTful service for reading and updating a bank balance. To indicate that a call to GetBalance should be conveyed directly via an HTTP GET, this operation is marked with the WebGet attribute. Similarly, because the UpdateBalance operation is marked with the WebInvoke attribute, it will be conveyed via an HTTP POST. (It’s also possible to specify that an operation marked with this attribute should use some other HTTP operation, such as PUT or DELETE.) Rather than using SOAP and the WS-* protocols, this simpler RESTful style adheres to the traditional fundamentals of Web-based communication. Because each approach makes sense in some situations, WCF in the .NET Framework 3.5 supports both.

The ability to send the XML formats defined by RSS and ATOM has also become more important since WCF first appeared. Accordingly, the .NET Framework 3.5 version of WCF provides built-in support for these two formats. Information structured using either one can be sent over any WCF binding, although the new WebHttpBinding is likely to be the most common choice. Using WCF-supplied formatters, a .NET Framework 3.5 application can create or consume an RSS or ATOM feed, making it straightforward to work with this increasingly important kind of content.

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 over MSMQ.

Explicit manipulation of SOAP messages, including the ability to insert elements directly in the SOAP header.

WCF also allows a developer to control various local aspects of how a service behaves. Using the ServiceBehavior attribute, for example, she 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. A developer can also create a custom binding that provides the exact security services his 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, where 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, originally released in the .NET Framework 2.0, to allow creating 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.

Tool Support

Good tools make every developer’s life better. Accordingly, the version of WCF included in the .NET Framework 3.5 has support in Visual Studio 2008 for things such as the following:

Project types to help developers get started creating WCF applications. These include projects for building:

A Website or Web application that hosts a WCF service;

A library implementation of a WCF service;

A WCF application that exposes syndication feeds using RSS or ATOM;

A WCF service designed for use by an AJAX client. This service is automatically configured to use WebHttpBinding with the JavaScript Object Notation (JSON), one of the encoding choices this binding provides.

A WCF Autohost that can automatically host a library-based WCF service.

The Service Configuration Editor, a tool that makes creating and modifying WCF configuration files easier.

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, 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. And even though new .NET Framework 3.5 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 continue to run normally; installing and using the .NET Framework 3.5 won’t break existing code.
1   2   3   4   5

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

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