Justin Smith's Blog : Syndication

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.

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.

Hamsters, Robots, and Services

justinjsmith — Fri, 14 Dec 2007 22:49:10 GMT

This is one of the more interesting videos I've seen in a while:

http://www.irobot.com/create/videos/bionic%20hamster.html

I've been poking around a bit in the Microsoft Robotics Studio on and off for the past few months, and I'm intrigued by their approach to services, tasks, and coordination. From what I can tell, it seems just plain brilliant.

Since things around here are slowing down quite a bit for the holidays, I think I am going to dig into the Robotics Studio and runtime (on vacation time). Hopefully I will have something useful to show in January.

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.

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.

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.

BizTalk Services CTP is Public

justinjsmith — Wed, 25 Apr 2007 18:06:37 GMT

The BizTalk Services CTP is available for all to play with. In general, the concept is services in the cloud. It's a gross understatement, but enough for now. It's way cool because it opens the door for some innovative service scenarios. I plan on blogging quite a bit about these services in the near future. More soon.

Syndication - Beyond the News

justinjsmith — Wed, 18 Apr 2007 22:59:43 GMT

The next version of the .NET Framework (Orcas) includes support for web programming via WCF. In this context, web programming is the inclusion of web-centric protocols and constructs into the WCF programming model. Specifically, the WCF-related parts of Orcas support HTTP GET-style programming, HTTP OTHER-style programming, URI-centric resource mapping, rich content-type support, JSON message encodings, and the ability to create and consume syndications. This post relates to syndication. I'll talk about the other WCF features in subsequent posts.

When most of us think about syndication, we think about RSS and/or ATOM news/blog feeds. From experience, most of us don't consider any other uses for syndication.

Consider, for a moment, what syndication actually is. It is simply a set of data that is represented in some format. The format can be RSS, ATOM, SSE, <insert new format here>.

If syndication is the representation of some data, what kinds of data can we syndicate? As it turns out, there is quite a bit: the canonical purchase order example, package deliveries (consider UPS tracking-like capability), moves in an instance of a game, contact lists, <I could go on but won't>. The point here is that syndications are applicable far beyond our instinctual association with news.

We use aggregators (Outlook, IE7, others) to render syndications in a palatable format. If syndications are useful outside of getting the news, do we ever need more than a simple aggregator to consume syndications? The answer is "more than likely". Undoubtedly, many will continue to use standard aggregators to consume feeds (news and other interesting data). These aggregators are not enough for all applications. To be truly useful, we have to be able to consume a syndication and take action based on the contents of that syndication.

If you find yourself wondering "Self, why is there syndication support in Orcas? Is Microsoft trying to make it easier to create and consume news/blog feeds?"

The answer is that we (here at Microsoft) think syndication is a useful way to represent some sets of data. Furthermore, we (here at Microsoft) want to provide a set of tools that provide feature rich, easy, and flexible syndication capabilities.