Justin Smith's Blog : Web Programming with 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.

What is the Web 2.0?

justinjsmith — Tue, 31 Jul 2007 02:28:00 GMT

I often ask this question to people, and I've come to expect a wide array of answers. Last week I got one that may actually stand the test of time (we tend to re-define things in this industry).

Web 2.0 may very well be a service mark (http://www.theregister.co.uk/2006/05/26/web_2point0_battle/) owned by O'Rielly Media. Whoa.

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.

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);
}

Introduction to BizTalk.NET Services

justinjsmith — Sun, 10 Jun 2007 20:54:11 GMT

Background

BizTalk.NET Services (http://labs.biztalk.net) is a nascent and experiemental project that is all about generic, secure connectivity. Many WCF customers ask us how to notify client applications that something has happened in a service. If the client is addressable and listening, this is a fairly easy question to address. In fact, there is an SDK sample that addresses (pun intended) that exact scenario. However, when one of the clients is not addressable (behind a firewall or NAT), the problem becomes much harder. After all, how can a client receive incoming messages if it's listening address is virtually invisible outside the firewall or NAT?

This problem is not new. Connected applications like Groove, FolderShare, Skype, and all manner of Instant Messenger have had to solve this problem. Each of these applications has solved this problem in their own way, and with their own resources. Even though each of these business had to solve the problem, the physical characteristics of networks and the commonality of the requirement fostered (perhaps) similar design charachteristics. In the cases I am aware of, instances of these connected applications (i.e. clients) call out from behind a firewall or NAT to one or more servers in the internet. For the duration of that established socket, the server is able to send data back to the client. If, during the lifetime of that socket, another instance of the same connected application calls into the server, then the server is able to pass data from one instance of the connected application to another.

Though I don't have much emprical evidence to prove it across the board, my guess is that the connectivity quest undertaken by these development teams was not cheap or easy. Nonetheless, connected application vendors have all incurred this cost, and, in some form or fashion, solved the connected application problem in a proprietary manner. In some cases (like Live Messenger and Yahoo Messenger), some level or interoperability is possible, but they are generally point solutions.

Where does this leave organizations that don't have the budget, expertise, or time to implement a custom connectivity solution? This is the problem space where BizTalk.NET Services thrives. An organization can use BizTalk.NET Services to handle the connectivity, and frees up development resources to focus on the functionality of the application. The hope is that alleviating the connectivity burden allows organizations to deliver better applications faster and cheaper.

State of the Project

As of the date of this post, BizTalk.NET Services is in CTP form, and the team has adopted an Agile mindset. They drop code frequently, and alter the trajectory of the project based on feedback (and other things). As I understand it, the team had not committed to a release date, and there are many discussions internally regarding how these services will be made available to the community and customers.

In my discussions with the team, there is no doubt that they are eager to receive feedback about existing and non-existing features. As an example, the latest drop includes support for username / password security. Before this drop, the product had support for CardSpace security only. The inclusion of username / password security was largely driven by community feedback.

I encourage you to download the BizTalk.NET Services SDK and write some code with it. You can find it here (http://labs.biztalk.net). That site also includes links for how to provide feedback to the team.

How BizTalk.NET Services Surfaces to the Developer

In it's current form, BizTalk.NET Services is visible to developers via a new WCF binding (named the RelayBinding). The RelayBinding type utilizes WCF extensibility points and creates a channel stack that knows how to communicate with the BizTalk.NET Services servers in the cloud. More specifically, the RelayBinding creates a channel stack that includes a new transport channel that can connect with the BizTalk.NET Services servers in the cloud. The URI passed to this channel has a new scheme that helps distinguish it from other transports (sb://). The RelayBinding can be used with the existing ServiceHost implementations for listening, as well as the existing ChannelFactory<T> implementations to send messages to other messaging participants.

The transport channels do the heavy lifting of connecting to the servers in the cloud as well as participating in sending and receiving messages. The servers in the cloud do the heavy lifting of connecting applications. The compostion of the URI and the configuration of the RelayBinding object (and the resultant channel stack) dictate which applications are connected and how they are connected to one another.

Several types of connections are possible, and these will be the subject of another post (or several other posts).

One of the takeaways with this model is that user or applicaiton code is not hosted in the cloud. The services in the cloud broker the connections between instances of a client application.

Futures

As I understand it, the team's work items include furthering the scalability of this system, the inclusion of workflow into the services, and enhancing the security features of the services. Keep in mind that this project is nascent, and the team is intentionally agile. If you have opinions or feedback about any of these features, I encourage you to contact the team via the address shown earlier.

I fully expect to write much more about this cool new project, so stay tuned.

Podcast with Jon Udell

justinjsmith — Wed, 30 May 2007 21:33:22 GMT

Jon just published a podcast where we discuss how WCF in Orcas simplifies Syndication and RESTful style architectures. Hear it here.