Justin Smith's Blog : WCF

enableWebScript, UriTemplate, and HTTP methods

justinjsmith — Sat, 16 Feb 2008 02:55:28 GMT

A little while ago I ran into an interesting set of errors that may be of interest to you. Consider the following service contract snippet:

[OperationContract]
[WebGet(UriTemplate="foobar/{value}")]
String GetData(String value);

If you add the enableWebScript behavior to an endpoint that is using the WebHttpBinding, you will see this exception when the ServiceHost starts:

System.InvalidOperationException: Endpoints using 'UriTemplate' cannot be used with 'System.ServiceModel.Description.WebScriptEnablingBehavior'.

The reason for this error is rooted in the origin of the enableWebScript behavior. One of it's design objectives was to simplify working with the ASP.NET AJAX stack (Javascript proxy, JSON messages, etc). The AJAX stack doesn't have the equivalent of the UriTempalte type. It simply puts parameters in query strings (gets) and constructs entity bodies (posts). This is the default behavior of the WCF stack when the WebGet / WebInvoke annotations do not have a value for UriTemplate. Since any value of UriTemplate would be incompatible with the ASP.NET AJAX stack, we throw when it's present.

If you want JSON messages from a contract and you want to use the UriTemplate niceness, you can change your contract to:

[OperationContract]
[WebGet(UriTemplate="foobar/{value}", ResponseFormat=WebMessageFormat.Json)]
String GetData(String value);

Then, instead of using the enableWebScript behavior, use the WebHttpBehavior. You'll lose compat with the ASP.NET AJAX client stack (and the JS proxy), but you have the URI you are looking for.

The same is true if you are using the WebInvoke attribute and any HTTP method other than POST. The AJAX client stack only knows GET and POST...

MySpace does WCF

justinjsmith — Fri, 01 Feb 2008 07:12:37 GMT

My friend Vittorio has posted that MySpace will be talking about WCF at Mix 2008 (see it here). This promises to be a good session!

Life of a WCF Demo, Part 1

justinjsmith — Wed, 23 Jan 2008 02:24:00 GMT

I thought it might be mildly interesting to document the lifecycle of a demo. Over the next week or so I have to design, build, and deploy a demo that shows off some of the web-centric features of WCF in the .NET Framework 3.5. First, let me state the constraints:

1) it has to be lightweight - a person in the field or in the community must be able to run it with a bare bones setup (VS only)

2) it has to be "codable" from the ground up in a short period of time w/o much practice

3) it has to show off the new HTTP programming model, Syndication, and JSON messaging.

4) it should also bring to the surface other WCF features like new tooling, flexible configuration options, etc.

5) ideally, a silverlight client consumes the services.

I'm not sure how many parts it will take to blog this. Time will tell.

Since the demo is supposed to be lightweight and it has to be codable, it is going to lack the "real life" aspect. Simplicity and demos and reflecting real world scenarios are often in conflict in demos. Since this is not going to be a keynote, there is no need to dwell on it too long.

With that in mind, I will build an album metadata sharing service. The service just returns information about albums in a store and provides consumers with some ability to create side effects (add, change, or delete an album). Because the demo is supposed to be codable, we will keep the album type definition simple, maybe just a few fields.

There will likely need to be a backing store for the album data, so we have to decide where to store album data. Since DB connections can be annoying to deploy to lots of people, I will opt for an XML File in a VS project.

In regards to project structure, the VS solution will have 2 projects: AlbumService (WCF Service) and AlbumClient (Silverlight app). If we are feeling spunky, we can also build an ASP.NET AJAX app that uses the service.

Now it's time to code. I've found it's important to document any hiccups that occur along the way, and be certain those get communicated to the people that may present the demo in the future. I use a simple MS Word document. In this case, I am using LiveWriter, and posting it to my blog :).

Step 1: Create a VS Solution

Easy enough.

Step 2: Create a WCF Class Library Project

VS 2008 includes some new WCF tooling. You basically go to File->New->Project->WCF->WCF Service Library.

In keeping with the VS Tradition, several files are created for you that have mildly annoying names like IService1, Service1, and some random namespace. Even though the names are a bit annoying, the project will compile and run as is.

So, if one is giving this demo live, you could literally press F5, see the autohost and new WCF client start, and talk to those for as long as you felt compelled. I think the following points are important:

1) the autohost is a dev-only thing. It is all about getting a feedback loop going. It's kindred spirits with Cassini.

2) the autohost also lets you defer the choice of hosting. It may be the case that you aren't sure which host you will use. This autohost model helps you avoid (but doesn't prevent) you from creating frivolous dependencies on a type of host.

3) the test client makes it easy to pass basic data back to the service and check the results. Again, this is about a feedback loop.

4) The App.config created by the project creates 2 endpoints: a wsHttpBinding endpoint and a metadata exchange endpoint. It may be worth talking about how simple it is to setup endpoints that adhere to these complex protocols. It depends on the audience. Some of the more militant RESTafarian sects may well try to light your hair on fire if you bring up WS-*.

5) You can change the config options using a new tool (WCFConfigEditor.exe). You get to that tool by right clicking the App.config file. This only works for the WCF Service library project. If you are trying to edit a config file in a project that was not created from that template, then you can go to the Tools menu, then select WCF Service Configuration Editor. After you do that, subsequet request for the context menu will work.

In part 2, I will run through the code and config changes.

PictureServices and BizTalk Services

justinjsmith — Sat, 19 Jan 2008 03:47:00 GMT

Previous posts have talked a bit about PictureServices. Now I'd like to run through what it took to bring PictureServices to the BizTalk Services. I've talked a bit in other posts about BizTalk Services, but it has some interesting and very useful messaging features. For starters, BizTalk Services has an endpoint that can do HTTP transforms on messages. It goes like this:

MyApp connects to BizTalk Services
BizTalk Services and MyApp use WS-* security, coupled with the WCF binary message encoding.
Other clients (Java, PHP, Ruby, whatever) can hit an HTTP endpoint hosted in the BizTalk Services "mesh". We will call this endpoint the HTTP Endpoint.
Upon receipt of a message, the HTTP Endpoint tries to dispatch that message (or request) to MyApp.

If we use this set of steps with PictureServices, then you have a way to serve local pictures over the internet. If you just look at this task, there are lots of other ways to do this. I'm not suggesting that BizTalk Services is the next cool way to share photos. Instead, I think there are lots of cool apps that can take advantage of this kind of feature set.

Down to nuts and bolts - the service contract. PictureServices defines a service contract with operations for RSS, ATOM, and Simple list extensions. For the sake of time, I opted to have a single feature: get an RSS feed. Here's what the service contract looks like:

[ServiceContract]
interface IBTSPictureSyndication
{
  [OperationContract(Action="GET", ReplyAction="GETRESPONSE")]
  Message GetFeed();
}

The return type is System.ServiceModel.Channels.Message because the BizTalk Services SDK does not have full parity with the .NET Framework 3.5's capabilities. This will happen over time. To be honest, most of the head scratching I went through was due to the disparity between these two APIs.

Another interesting bit is the implementation of the GetFeed method. The syndication, the images, and all the thumbnail HTTP GETs (remember they are transformed) are going to flow through this one method. As a result, we have to test the requested address to determine which resource is being requested.

For that we turn to our new best friend: the UriTemplate. This is a new type introduced in .NET 3.5 - it makes URI parsing much easier (among other things).

There are 3 conditions I test for:

1) a request for the whole feed

2) a request for an image

3) a request for a thumbnail.

Here's the implementation:

[ServiceBehavior(AddressFilterMode=AddressFilterMode.Prefix)]
sealed class BTSPictureSyndication : IBTSPictureSyndication
{
    String feedUri = "/Feed/";
    String pictureUri = "/Feed/Picture/{pictureId}";
    String thumbnailUri = "/Feed/Picture/t/{pictureId}";

    PictureService service = new PictureService();

    public Message GetFeed()
    {
        // get the To address and the base address
        Uri to = OperationContext.Current.RequestContext.RequestMessage.Headers.To;
        Uri baseAddress = new Uri(ConfigurationManager.AppSettings["baseAddress"]);

        // check to see if it's a request for the main feed
        UriTemplate feedTemplate = new UriTemplate(feedUri);
        UriTemplateMatch feedMatch = feedTemplate.Match(baseAddress, to);

        if (feedMatch != null)
        {
            return GetMainFeed();
        }

        // check to see if it's a request for a picture
        UriTemplate pictureTemplate = new UriTemplate(pictureUri);
        UriTemplateMatch pictureMatch = pictureTemplate.Match(baseAddress, to);

        if (pictureMatch != null)
        {
            String pictureId = pictureMatch.BoundVariables["pictureId"];
            return GetPicture(pictureId);
        }

        // check to see if it's a request for a thumbnail
        UriTemplate thumbnailTemplate = new UriTemplate(thumbnailUri);
        UriTemplateMatch thumbnailMatch = thumbnailTemplate.Match(baseAddress, to);

        if (thumbnailMatch != null)
        {
            String pictureId = thumbnailMatch.BoundVariables["pictureId"];
            return GetPictureThumbnail(pictureId);
        }

        // we don't know what it is, so throw
        throw new InvalidOperationException(String.Format("the address {0} was not matched", to.ToString()));

    }

    // use the service object to get the picture
    private Message GetPicture(String pictureId)
    {
        return StreamMessageHelper.CreateMessage(OperationContext.Current.IncomingMessageVersion,

        "GETRESPONSE", service.GetPicture(pictureId));
    }

    // use the service object to get a thumbnail
    private Message GetPictureThumbnail(String pictureId)
    {
        return StreamMessageHelper.CreateMessage(OperationContext.Current.IncomingMessageVersion,

        "GETRESPONSE", service.GetPictureThumbnail(pictureId));
    }

    // get the main feed (RSS)
    private Message GetMainFeed()
    {
        Rss20FeedFormatter formatter = service.GetPicturesAsRss();

        MemoryStream stream = new MemoryStream();
        XmlWriter writer = XmlWriter.Create(stream);

        formatter.WriteTo(writer);

        writer.Close();
        stream.Position = 0;

        return StreamMessageHelper.CreateMessage(OperationContext.Current.IncomingMessageVersion, "GETRESPONSE", stream);
    }
}

Another thing that's worth pointing out is the presence of the AddressFilterMode property on the ServiceBehavior attribute annotation. This setting tells the WCF dispatching infrastructure to allow prefix matches to filter through to the method. In practical terms, this means that a request to http://foo/bar/baz would get dispatched to the same method as http://foo/bar. That's how we are returning the full feed, the image, or a thumbnail.

Here's a zipped version of the project (note that you must also have PictureServices).

XML namespace declarations in SyndicationFeed objects

justinjsmith — Wed, 16 Jan 2008 12:12:00 GMT

Following on the heels of Steve Maine's post about namespaces in Syndication objects (Feeds, items, etc.), I thought it wise to plug the new stuff in PictureServices.

At the moment, PictureServices implements SLE (Simple List Extensions), and does a pretty crude job of it at that. Time permitting, I will add more support for field and group customization. For now, it serves as an example more than a carrier grade implementation. In any event, I used extension methods in the following type definition to make it easy to insert the right namespace declarations in the feed:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel.Syndication;
using System.Xml;

namespace Microsoft.DPE.Samples.SyndicationExtensions
{
    // adds custom namespaces to an item or a feed
    public static class SyndicationNamespaceHelper
    {
        public static void DeclareNamespace(this SyndicationFeed feed, 
                                                 String prefix,
                                                 String ns)
        {
            XmlQualifiedName key = new XmlQualifiedName(prefix, NamespaceUris.XMLNamespace);
            feed.AttributeExtensions.Add(key, ns);
        }

        public static void DeclareNamespace(this SyndicationItem item, 
                                                 String prefix,
                                                 String ns)
        {
            XmlQualifiedName key = new XmlQualifiedName(prefix, NamespaceUris.XMLNamespace);
            item.AttributeExtensions.Add(key, ns);
        }
    }
}

The usage model is simple - just new up a feed or an item, then call DeclareNamespace. Piece of cake.

PictureServices updated to VS 2008 RTM

justinjsmith — Tue, 15 Jan 2008 06:18:34 GMT

Today I updated PictureServices to work with the RTM release of Visual Studio 2008 and the .NET Framework 3.5 (what a mouthful). My testing rigor for this release was less than perfect. Please let me know if you find any bugs.

For what it's worth, the changes in the API made the simple list extensions implementation simpler. Honestly, I was skeptical at first, but it really is pretty straightforward.

Check out the new version here.

PictureServices status update

justinjsmith — Mon, 14 Jan 2008 20:13:43 GMT

I've received several mails about PictureServices and RTM. As some of you know, the Syndication API changed before RTM. The were subtle, but they did have an impact on the Picture Services project. Specifically, the simple list extensions part of Picture Services isn't up to date with the RTM bits. I will update the bits this week and repost...

WCF Syndication article in MSDN Magazine...

justinjsmith — Sun, 23 Dec 2007 17:28:00 GMT

It seems that the RSS/Atom article I wrote for MSDN magazine was just published: http://msdn.microsoft.com/msdnmag/issues/08/01/WCFinOrcas/default.aspx

The RTM version of .NET 3.5 was not available when I wrote the article, so I avoided the extensibility capabilites of the API. Perhaps that's fodder for another article.

Setting HTTP Headers in WCF (.NET 3.5)

justinjsmith — Wed, 22 Aug 2007 20:41:04 GMT

One of the cool parts of WCF in the .NET 3.5 is the simplified support of the REST architectural style. URIs, HTTP verbs, and HTTP headers are 1st class citizens in the programming model. Each of these citizens is interesting. I'll focus a bit on HTTP headers here.

HTTP headers dictate a wide array of characteristics of how a server responds to a request and how a client reacts to the response sent by the server. A full discussion is beyond the scope of my blog post, but this stuff has been around for quite a while. You should be able to do a Live Search on HTTP Headers to dig up more info on their uses.

There's two uses that are particularly interesting from a services perspective: Content-Type and Cache-Control.

Content-Type serves as a way for the server to indicate the data format and is expressed as a MIME type label. SOAP / WS-* services generally express data format in terms of schema and WSDL. Schema and WSDL are highly expressive, whereas Content-Type is dramatically simpler. The web tends to rely on Content-Type.

The Cache-Control response header indicates how long a response is valid. It also can include instructions regarding how the client should validate their cache. You can get the particulars straight from the horses mouth: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html

The easiest way to set the value of these headers in a WCF application is via the WebOperationContext type. An object of this type is normally available in a method of a service object, and follows the usage pattern demonstrated in .NET 3.0's OperationContext type.

Here's how you can set he Content-Type header in a method of a service object (for the HTTP wonks, I've omitted charset):

1  public String SomeMethod(Int32 someNumber) {
2   // normal implementation would go here
3 
4   // set the Content-Type
5   WebOperationContext.Current.OutgoingResponse.ContentType = "text/html";
6 
7   // return something
8   return someNumber.ToString();
9 }

Here's how you could set the Cache-Control response header and the validation HTTP headers:

 1 public String SomeMethod(Int32 someNumber) {
 2     
 3     // normal implementation would go here
 4 
 5     // set the Content-Type
 6     WebOperationContext.Current.OutgoingResponse.ContentType = "text/html";
 7 
 8     // call a helper method that sets cache-control header
 9     SetCaching(WebOperationContext.Current, DateTime.Now, 120);
10 
11     // return something
12     return someNumber.ToString();
13 }
14 
15 private void SetCaching(WebOperationContext context, DateTime lastModifiedDate, Int32 maxCacheAge){
16     
17     // set CacheControl header
18     HttpResponseHeader cacheHeader = HttpResponseHeader.CacheControl;
19     String cacheControlValue = String.Format("max-age={0}, must-revalidate", maxCacheAge);
20     context.OutgoingResponse.Headers.Add(cacheHeader, cacheControlValue);
21 
22     // set cache validation 
23     context.OutgoingResponse.LastModified = lastModifiedDate;
24     String eTag = context.IncomingRequest.UriTemplateMatch.RequestUri.ToString() + lastModifiedDate.ToString();
25     context.OutgoingResponse.ETag = eTag;
26 
27 }

There are lots of different options available for caching and validation. If there's interest, I will dive into those in a future post. It's hard to gauge what's common knowledge about these headers.

From a debugging perspective, know that Fiddler is your best friend. When you are watching headers on localhost services, you won't see the sessions in Fiddler unless you use the full machine name in the request. The machine name forces the request to go through the fiddler proxy.

Check out Picture Services

justinjsmith — Tue, 21 Aug 2007 01:23:32 GMT

A few days ago we released a new sample called Picture Services. As the name implies, this sample centers on pictures. More specifically, it demonstrates how to use the WCF API in the .NET Framework 3.5 to syndicate images from your local machine and expose them via a REST endpoint.

There's been a fair amount of buzz recently around REST development. With the .NET Framework 3.5, REST constructs are now 1st class citizens in the WCF programming model.

We've tried to make the sample easy to understand, but still have enough complexity to warrant investigation. Features highlighted include: simple syndication, Simple List Extensions, HTTP GET programming, as well as some of the new tooling and hosting options. Check it out and let me know what you think.

To download the sample, just go here, select "Source Code", and then "Download". Alternately, you can simply go here.

ASP.NET, WCF, and Asynchronous Programming

justinjsmith — Thu, 02 Aug 2007 00:57:00 GMT

Jeffrey Richter told me once that a CPU was a terrible thing to waste. I don't know if he was the one to coin the term - in fact, I think he told me someone else coined that term. Regardless of where it came from, the principle behind that phrase is solid. All too often, developers do I/O synchronously, thereby wasting CPU time, and making their applications less scalable and responsive. Terrible.

Often the excuse is that one expects the I/O to happen quickly. One seldom (if ever) can predict how fast any I/O is going to take, so this is a non-starter. Never do synchronous I/O. Never ever. Read Jeff Richter's CLR Via C# for an eloquent explanation of why.

This premise surfaces in WCF programming from within an ASP.NET application. Consider this scenario:

A Page_Load event handler needs to send a message to a web service and do something with the result.

Simply put, the ASP.NET application needs to do I/O. If the web service call is synchronous, the thread that is executing the Page_Load event (and the web service call) blocks until the web service call returns. That thread cannot be used to process other requests while waiting, and the web server will soon return 503 errors. Since the web service call takes a long time (try not to quibble that it is usually fast), you are wasting threads and CPU time. Terrible.

If, however, you use ASP.NET Async pages and an asynchronous call to the web service, you are not wasting the CPU. Very good. For more info on the async capabilities of ASP.NET 2.0, see Jeff Prosise's most excellent article: http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/. With WCF, you would do something like:

 1 public partial class _Default : System.Web.UI.Page 
 2 {
 3     IService1 proxy;
 4     ChannelFactory<IService1> factory;
 5 
 6     protected void Page_Load(object sender, EventArgs e)
 7     {
 8         WSHttpBinding binding = new WSHttpBinding();
 9         EndpointAddress address = new EndpointAddress("http://localhost:8080/Service1");
10 
11         // you could also reuse a proxy...
12         factory = new ChannelFactory<IService1>(binding, address);
13 
14         this.AddOnPreRenderCompleteAsync(
15             new BeginEventHandler(BeginAsyncOperation),
16             new EndEventHandler(EndAsyncOperation)
17         );
18     }
19 
20 
21     IAsyncResult BeginAsyncOperation(Object sender, EventArgs e,
22         AsyncCallback cb, Object state)
23     {
24         proxy = factory.CreateChannel();
25         return proxy.BeginGetData(TextBox1.Text, cb, state);
26     }
27 
28     void EndAsyncOperation(IAsyncResult ar)
29     {
30         String output = proxy.EndGetData(ar);
31         Label2.Text = output;
32     }
33 }

Line 24 is where is I/O starts. BeginGetData returns an IAsyncResult and the thread goes into back into the thread pool. When the result comes back, the EndAsyncOperation method is called, and the proxy's end method can be called.

The model isn't hard, and it greatly improves the scalability of your ASP.NET application. On top of that, it doesn't waste the CPU...

The full code sample is here

WCF, ASP.NET AJAX, and JavaScript Proxies

justinjsmith — Tue, 24 Jul 2007 07:35:00 GMT

I spent this weekend tinkering around with the JSON messaging capabilities of WCF new in the .NET Framework 3.5 (Orcas). The object model is changing substantially between Beta1 and Beta2, and I think the changes make for an easier to use system.

To better understand the JSON messaging features of WCF, check out some of the general requirements they were built to:

1) Config-free deployment for JSON endpoints

2) ASP.NET AJAX developer experience consistent with ASMX endpoints

3) Give service developers the same WCF developer experience as WCF v1

I am sure there were more, but these were the big ones related to developer experience.

Now, lets look at some code. A good place to start is the contract.

The Service Contract

[ServiceContract]
public interface IWCFAjaxService {
    [OperationContract]
    [WebInvoke(Method = "POST", UriTemplate = "ShowServerDate")]
    String ShowServerDate();
}

The only thing that is different in this contract from a WCF contract from WCF v1 is the presence of the WebInvoke attribute. Simply put (almost pun intended), this attribute indicates that the operation will be accessible via the HTTP verb indicated by the Method instance property. In this case, the HTTP verb is POST.

The Service Type

This is pretty straightforward, so I'll just show it for completeness:

public class WCFAjaxService : IWCFAjaxService {
    public string ShowServerDate()    {
        return DateTime.Now.ToString();
    }
}

The SVC file

SVC files are an activation target for WCF services hosted in IIS. Since this example is showing a web page that calls a WCF service, IIS is the natural host. The svc file is simple:

<%@ ServiceHost Language="C#" Debug="true" Service="WCFAjaxService" Factory="System.ServiceModel.Activation.WebScriptServiceHostFactory" %>

Notice the presence of the Factory part of the directive. This indicates that the ServiceHostFactory to be used is the WebScriptServiceHostFactory. This is a new type that ships with .NET Framework 3.5. It creates a ServiceHost that has the right endpoint (behaviors, binding, etc) that will work for AJAX integration.

The ASPX file

 1 <%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
 2 
 3 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 
 4                     Transitional//EN" 
 5                     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 6 <html xmlns="http://www.w3.org/1999/xhtml">
 7 <head id="Head1" runat="server">
 8     <title>WCF Ajax Demo</title>
 9 
10     <script type="text/javascript">
11     
12       function GetServerTime(){
13         var proxy = new tempuri.org.IWCFAjaxService();
14         proxy.ShowServerDate(OnSucceeded, null, null);
15       }
16   
17       function OnSucceeded(result)
18       {
19         var RsltElem = document.getElementById("Results");
20         RsltElem.innerHTML = result;
21       }
22     
23     </script>
24 
25 </head>
26 <body>
27     <form id="form1" runat="server">
28     <div>
29         <asp:ScriptManager ID="scriptManager" runat="server">
30             <Services>
31                 <asp:ServiceReference Path="~/Service.svc" />
32             </Services>
33         </asp:ScriptManager>
34         <h2>
35             Server Time</h2>
36         <p>
37             Calling a service that returns the current server time.</p>
38         <input id="DateButton" type="button" value="GetTime" 
39                    onclick="GetServerTime()" />
40     </div>
41     <div>
42         <br />
43         <span id="Results"></span>
44     </div>
45     </form>
46 </body>
47 </html>
48

The important parts of this code snippet are lines 29-33 (ScriptManager) and lines 12-15 (proxy call). In you are new to AJAX development, I encourage you to visit http://www.asp.net for more info.

The ScriptManager is the main integration point for web services and ASP.NET AJAX. Adding a Service node in the Services collection will create a JavaScript proxy, and you can all that JavaScript proxy from other functions in your page.

See the JavaScript Proxy

When I first tackled this, I could not get the proxy to generate, and I could not seem to find out the name of the proxy. The trick is to navigate to the svc url, then add a JS to the URL.

If your starting URL is http://localhost/WCFAjaxService/Service.svc, then the JavaScript proxy URL is http://localhost/WCFAjaxService/Service.svc/js. When you download that file, you'll see that the name of the proxy follows the naming convention of your service contract's XML namespace (hence tempuri.org in lines 12-15)

The complete sample is below.

Syndication formats, endpoints and config files

justinjsmith — Wed, 18 Jul 2007 20:54:46 GMT

I got a question via email today that forced me to look back through some older emails for the answer. It may make sense to share the question / answer in a broader sense.

Earlier builds of Orcas surfaced a syndication format to an endpoint by way of a behavior. In essence, you could add a SyndicationBehavior to an endpoint, and that behavior dictated the syndication format for that endpoint (RSS or ATOM). With this model you can specify the syndication format in a config file.

The endpoint centric model for syndication formats is no longer in place. The current model centers on the return type for the operation that returns the syndication. If you want to return a syndication from an operation, you should return a SyndicationFeedFormatter<T> or one of it's derived types (RSS and ATOM types available). In the current incarnation, this removes the config options for syndication formats, but the benefit is worth it (in my opinion).

The motivation for this change (according to Steve Maine) has to do with the embrace of the URI in web-centric programming. Strapping an endpoint to a particular format has undesirable impacts on the URI structures of the service(s). Many customers wanted to serve RSS or ATOM from one URI, and vary the format based on the presence of a query string or an accept header. As a result, the SyndicationBehavior vanished.

IBM MQ Custom Channel

justinjsmith — Mon, 16 Jul 2007 21:25:46 GMT

I just saw a mail introducing an alpha release from IBM - an MQ series custom channel. It appears to be early stage, so don't throw this into production yet.

Several have asked me if it's possible to connect WCF to MQ - my answer is yes, but it requires a fair amount of custom code. If this channel makes it to a full-fledged release from IBM, you won't even have to do that.

Here's the link: http://www.alphaworks.ibm.com/tech/mqwcf/

WebServiceHost vs ServiceHost

justinjsmith — Mon, 02 Jul 2007 21:59:00 GMT

WCF in .NET Fx 3.5 introduces several types that simplify the creation of services that use the protocols of the web (read REST/Syndication/JSON). Among these are two hosting types: WebServiceHost and WebScriptServiceHostFactory. These types serve the same function as the ServiceHost and ServiceHostFactory type, but they are tailored for the web. For example, WebServiceHost automatically adds the right behavior and does some error checking to ensure http is the transport. Likewise, the WebScriptServiceHostFactory does similar error checking and adds a behavior that sets up the JSON messaging stack.

The WebScriptServiceHostFactory means that developers can setup an .svc file with no config (via directives), and the WebServiceHost means that web developers do not have to muck about with WCF behaviors.

These types automate with work one would otherwise have to do with the ServiceHost type. If, for some reason, you do not want to or cannot use these new types, you can always use the ServiceHost.

The code below shows how to expose a REST endpoint with both the ServiceHost and the WebServiceHost types:

sealed class Program : ISomeContract {

    static void Main(string[] args) {
        
        Uri baseAddress = new Uri("http://localhost:8000");

        HostWithServiceHost(baseAddress);

        HostWithWebServiceHost(baseAddress);
    }

    private static void HostWithServiceHost(Uri baseAddress) {
        
        ServiceHost host = new ServiceHost(typeof(Program), baseAddress);
        WebHttpBinding binding = new WebHttpBinding();

        ServiceEndpoint endpoint = host.AddServiceEndpoint(typeof(ISomeContract), binding, "ServiceHost");
        WebHttpBehavior httpBehavior = new WebHttpBehavior();
        endpoint.Behaviors.Add(httpBehavior);

        host.Open();

        Console.WriteLine(@"go to http://localhost:8000/ServiceHost/SomeOperation to test");
        Console.ReadLine();

    }

    private static void HostWithWebServiceHost(Uri baseAddress) {
        
        WebServiceHost host = new WebServiceHost(typeof(Program), baseAddress);
        WebHttpBinding binding = new WebHttpBinding();
        host.AddServiceEndpoint(typeof(ISomeContract), binding, "WebServiceHost");
        host.Open();

        Console.WriteLine(@"go to http://localhost:8000/WebServiceHost/SomeOperation to test");
        Console.ReadLine();
        host.Close();
    
    }

    public String SomeOperation(String input) {
    
        String reply = "You said: " + input;
        Console.WriteLine(reply);
        return reply;
    
    }
}

[ServiceContract]
interface ISomeContract {
    [OperationContract]
    [WebGet(UriTemplate="SomeOperation/{input}")]
    String SomeOperation(String input);
}