MSDN Magazine - January 2008 - (Page 77)

these two types in a WCF service. The goal was to offer a simple and intuitive way to map URI segments and query string parameters into application functionality. I think the model as shown in the following code fits the bill: [ServiceContract] public interface IPictureService { [OperationContract] [WebGet(UriTemplate = “picture/{pictureId}”)] Stream GetPicture(String pictureId); Figure 2 Creating a Template-Based URI // create a URI bound to the template Uri baseAddress = new Uri(@”http://localhost:2000”); UriTemplate template = new UriTemplate(“{artist}?album={album}”); Uri boundUri = template.BindByPosition(baseAddress, “Northwind”, “Overdone”); Console.WriteLine(boundUri.ToString()); // retrieve the value of the artist segment UriTemplateMatch match = template.Match(baseAddress, boundUri); String bandName = match.BoundVariables[“artist”]; Console.WriteLine(“the name of the artist is {0}”, bandName); } [OperationContract] [WebGet(UriTemplate = “picture/t/{pictureId}”)] Stream GetPictureThumbnail(String pictureId); The UriTemplate surfaces as an instance property on the WebGetAttribute, which, in turn, is applied to a service contract. Notice that the token between the curly braces maps to the name of the method parameter. Though this sample shows only one parameter, you can add many parameters, arrange them in any order, add them as query string parameters, and even use wildcards. At run time, the value of the UriTemplate property is passed to the UriTemplate constructor. Both the Client runtime and the Dispatcher use the UriTemplate property value in this manner. The Dispatcher uses it to match incoming messages to an operation, and the Client uses it to ensure that a method on a proxy gets sent to the right URI. It’s an easy-to-use, simple, and effective way to “embrace the URI” in your services. Figure 3 Using WebInvokeAttribute [ServiceContract] public interface IPictureService { [OperationContract] [WebGet(UriTemplate = “picture/{pictureId}”)] Stream GetPicture(String pictureId); [OperationContract] [WebGet(UriTemplate = “picture/t/{pictureId}”)] Stream GetPictureThumbnail(String pictureId); [OperationContract] [WebInvoke(UriTemplate=”update”, Method=”POST”)] void UpdatePictureInfo(PictureInfo info); } HTTP Verbs in WCF Contracts HTTP programming with WCF in the .NET Framework 3.5 makes it easy to map operations in a service contract to HTTP verbs. As you can probably tell from the name, applying the WebGetAttribute to an operation makes that operation available via an HTTP GET. As you saw in the previous code snippet, the WebGetAttribute defines an instance property named UriTemplate. There are other instance properties on the WebGetAttribute type. The most notable are RequestFormat and ResponseFormat. As their names imply, the values of these properties dictate the message format for the operation. The RequestFormat and ResponseFormat properties are of type WebMessageFormat, an enumerated type that has two values: Xml and Json. The WCF infrastructure uses the values of these properties to set up the channel stack with the appropriate message encoder. A property value of WebMessageFormat.Xml will result in a channel stack that uses the XML encoder. Setting the value to WebMessageFormat.Json will result in a channel stack that uses the JSON encoder included in the .NET Framework 3.5. Since there are properties for both sides of the HTTP message exchange, it is possible for an application to receive an XML message and return a JSON message (or vice-versa). The other attribute related to HTTP verbs is WebInvokeAttribute. Applying this attribute to an operation makes that operation available by any HTTP verb other than HTTP GET. The separation in the object model between HTTP GET and all other verbs reflects the frequency HTTP GET is used versus the other HTTP verbs. The WebInvokeAttribute object model is similar to the WebGetAttribute, but it includes an instance property named Method. The value of this property associates a particular HTTP verb to the operation. The Method property is of type String, so you can set the value to any standard HTTP verb, and even non-standard HTTP verbs. Figure 3 illustrates how to use the WebInvokeAttribute in a service contract. The UpdatePictureInfo method has a parameter of type PictureInfo. At run time, a serialized version of a PictureInfo object is the payload of an HTTP POST message. Passing data this way allows applications to ship complex data types that are not otherwise expressible in a URI. WCF in the .NET Framework 3.5 also makes it easy to interact with HTTP headers. Request and response HTTP headers are exposed via the System.ServiceModel.Web.WebOperationContext type. The WebOperationContext type is an extension of the System.ServiceModel.OperationContext type introduced in WCF in the .NET Framework 3.0, and its usage pattern is similar. Both are intended to be used within the implementation of a service object. The WebOperationContext type exposes members that simplify reading or setting HTTP header values, as well as retrieving information about the URI used to access the service object. The HTTP headers are stored as a collection, and the most common ones are exposed as individual properties. This example shows how to use the WebOperationContext type to follow the data model of the Web by setting the Content-Type header for an HTTP response: public Stream GetPicture(string pictureId) { // retrieve the Stream (omitted) Stream stream; // set the Content-Type to image/jpeg WebOperationContext.Current.OutgoingResponse.ContentType = “image/jpeg”; } return stream; WCF Syndication january2008 77

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2008

MSDN Magazine - January 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Cutting Edge IIS 7.0 - Enhance Your Apps with the Integrated ASP.NET Pipeline World Ready - Around the World with ASP.NET AJAX Applications WCF Syndication - HTTP Programming with WCF and the .NET Framework 3.5 Wicked Code Foundations Extreme ASP.NET {End Bracket}

MSDN Magazine - January 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.