Udostępnij za pośrednictwem

Life of a WCF Demo, Part 1

  • Artykuł

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.

img1

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.

img1

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

Comments

  • Anonymous
    April 03, 2008
    PingBack from http://underground.infovark.com/?p=7

  • Anonymous
    May 07, 2008
    This was a great part 1. Any hope for a part 2, or does that fall on the new WCF Evangelist :-)

  • Anonymous
    October 18, 2009
    blog is informative.could you please write a blog for service behaviors and transactions too..

  • Anonymous
    August 07, 2011
    This Article is very nice .It is Helpful Every one.