Christian Weyer's Blog

You think WCF needs more of ‘you’? Go and vote for your most desired features now

The WCF team has set up a uservoice page for voting on WCF v-Next features. Go ahead and influence WCF!

thinktecture WSCF.blue has hit the 10,000 downloads landmark on CodePlex

After thinktecture StarterSTS has hit the 5,000 downloads mark a few weeks ago (congrats again, Dom!), we now have hit 10,000 for our WCF-based Web Services contract-first tool WSCF.blue.

[Want to learn more about it and the idea behind it…? Read this MSDN Magazine article]

Thanks to a great team!

thinktecture StarterSTS now officially ‘powered by Windows Azure’

A few hours ago I got the final notice that StarterSTS is now officially allowed admittance to the Azure Cloud olymp:

 

OK, Dominick: up to releasing 1.5…

Microsoft Most Valuable Professional (MVP) for Windows Azure [Architecture]

Thanks to Microsoft for being part of this community.

Whitepaper: The ins and outs of data type interop between .NET/WCF and Java – add it to your [web] services tool belt

Recently, Buddhike and I wrote a whitepaper for MSDN which details the mapping of .NET/WCF and Java data types in a XML/XSD-ruled world.

As a developer it’s almost inevitable running into XML-based Web Services these days. Literally, they are everywhere. Web Services are often available as either REST style services or SOAP messaging style services built using various tools and running in different operating environments. Therefore, a number of standards have been defined over the years in order to ensure seamless interoperability between Web Services running in different operating environments. However, it is still somewhat challenging to develop interoperable Web Services because of how different platform vendors support industry standards. This whitepaper is written based on an interoperability analysis carried out between .NET 4 and three major Java based platforms - IBM Web Sphere, Oracle WebLogic and Oracle Metro (referred as Java client/server systems hereinafter).

Interoperable Web Services use universal type system - XML Schema Definition (XSD) constructs to define the data and message structures used for communication. However, the advanced tools and runtimes used for Web Service development usually abstract the details of XSD (and other protocols) from the developer. As a result developers can elaborate their Web Services using the programming language artifacts they are familiar with and leave the heavy lifting to the tooling/runtimes to translate those into the standard format. Even though some developers favor developing their type system using XSD (also known as schema first development), interoperability issues still arise due to limitations in various platforms for some XSD features. In this whitepaper, our analysis primarily focuses on the interoperability problems that occur while translating XSD artifacts to various platform level artifacts and vice versa.

[…]

Some illustrations used in paper are considered as bad practices for designing Web Service contracts. This paper acknowledges those shortcomings but provides those samples nevertheless to demonstrate the consequences.

Topics being covered:

• Primitive Types
  • .NET Server to Java Clients Mapping
  • Java Server to .NET Client Mapping
• Arrays and Abstract Data Types
• Date & Time
• Guid
• List
• Dictionary
• Queue
• Stack
• Tuple
• Binary Data
• Programming Language Constructs
  • Inheritance
  • Generics
  • Interfaces
    

Hope this article helps someone out there.

Using JSON.NET as a default serializer in WCF HTTP/Web/REST (vNext)

Just yesterday a client walked up to me and asked how to replace the default JSON serializer in WCF’s web programming model (whether in .NET 3.5 or 4.0).
Honestly, this is not too easy – if you aim at adding a different JSON engine - like the wonderful JSON.NET – to the WCF pipeline you won’t have too much fun. A lot of plumbing works needs to be done. A more practical approach is to use Message or Stream as the response/request type and apply the serialization/deserialization inside the service façade operation implementation.

I thought there should be an easier and more HTTP/Web/Rest-style way to do this.

Good news: I found one.
Bad news: it is based on the WCF HTTP Preview 1 (and thus non-RTM bits)

To get you up and running with the ideas of WCF HTTP vNext please refer to the master–of-disaster-PM Glenn Block’s blog

 

So, in order to support JSON.NET all I had to do is to write a custom media type processor by deriving from MediaTypeProcessor. Please also refer to Cibrax’ great blog entry about versioning REST services with processors.

Here is a little sample for the JsonNetProcessor class::

namespace Microsoft.ServiceModel.Http
{
    using System;
    using System.Collections.Generic;
    using System.IO;
    using System.ServiceModel.Description;
    using Microsoft.Http;
    using Newtonsoft.Json;
    public class JsonNetProcessor : MediaTypeProcessor
    {
        private Type parameterType;
        public JsonNetProcessor(HttpOperationDescription operation, MediaTypeProcessorMode mode)
            : base(operation, mode)
        {
            if (this.Parameter != null)
            {
                this.parameterType = this.Parameter.ParameterType;
            }
        }
        public override IEnumerable<string> SupportedMediaTypes
        {
            get
            {
                return new List<string> { "text/json", "application/json" };
            }
        }
        public override void WriteToStream(object instance, Stream stream, HttpRequestMessage request)
        {
            var serializer = new JsonSerializer();
            
            using (var sw = new StreamWriter(stream))
            using (var writer = new JsonTextWriter(sw))
            {
                serializer.Serialize(writer, instance);
            }
        }
        public override object ReadFromStream(Stream stream, HttpRequestMessage request)
        {
            var serializer = new JsonSerializer();
            using (var sr = new StreamReader(stream))
            using (var reader = new JsonTextReader(sr))
            {
                var result = serializer.Deserialize(reader, parameterType);
                return result;
            }
        }
    }
}

 

Very straight-forward and actually almost too easy. As JSON.NET also supports binary JSON, named BSON, I added another class BsonProcessor for this as well:

namespace Microsoft.ServiceModel.Http
{
    using System;
    using System.Collections.Generic;
    using System.IO;
    using System.ServiceModel.Description;
    using Microsoft.Http;
    using Newtonsoft.Json;
    using Newtonsoft.Json.Bson;
    public class BsonProcessor : MediaTypeProcessor
    {
        private Type parameterType;
        public BsonProcessor(HttpOperationDescription operation, MediaTypeProcessorMode mode)
            : base(operation, mode)
        {
            if (this.Parameter != null)
            {
                this.parameterType = this.Parameter.ParameterType;
            }
        }
        public override IEnumerable<string> SupportedMediaTypes
        {
            get
            {
                return new List<string> { "application/bson" };
            }
        }
        public override void WriteToStream(object instance, Stream stream, HttpRequestMessage request)
        {
            var serializer = new JsonSerializer();
            
            using (var writer = new BsonWriter(stream))
            {
                serializer.Serialize(writer, instance);
            }
        }
        public override object ReadFromStream(Stream stream, HttpRequestMessage request)
        {
            var serializer = new JsonSerializer();
            using (var reader = new BsonReader(stream))
            {
                var result = serializer.Deserialize(reader, parameterType);
                return result;
            }
        }
    }
}

Well. This is it. No more buzz.

Now let’s register the new processor with the pipeline by implementing a custom host configuration:

public class MyResourceConfiguration : HostConfiguration
{
    public override void RegisterRequestProcessorsForOperation(HttpOperationDescription operation, IList<Processor> processors, MediaTypeProcessorMode mode)
    {
        processors.Add(new JsonNetProcessor(operation, mode));
        processors.Add(new BsonProcessor(operation, mode));
    }
    public override void RegisterResponseProcessorsForOperation(HttpOperationDescription operation, IList<Processor> processors, MediaTypeProcessorMode mode)
    {
        processors.Add(new JsonNetProcessor(operation, mode));
        processors.Add(new BsonProcessor(operation, mode));
    }
}

Done.

Looking forward to more Web/HTTP goodness for WCF vNext
(and yes, feel free to discuss with me why bother about WCF at all when it comes to
HTTP-close-to-the-metal-programming…).

Slides & Samples für meine Vorträge auf der BASTA! 2010 in Mainz

Wie immer war die BASTA! ein interessantes Erlebnis und ich bedanke mich bei allen Teilnehmern, die in meinen Vorträügen waren – es hat sehr viel Spaß gemacht und ich hoffe, Sie konnten viele neue Ideen und neu Gelerntes mit ins Büro und mit nach Hause nehmen. thinktecture war dieses Mal mit allen Experten vor Ort.

Hier finden Sie die Slides & Samples von meinen drei Vorträgen (außer die MonoTouch Samples):

• Scharfer Apfel: iPhone in Action mit C#
• WCF 4.0 SOAP Services: nachrichtenbasierte verteilte Anwendungen
• WCF 4.0 Web/HTTP Services: Verteilte Anwendungen nach Web-Machart

Bis zur nächsten BASTA!

"A highly recommended tool"

This is good to read – just feels good:

Was suprised at the lack of contract-first (from WSDL) support in WCF, but your tool came to the rescue. It allowed me to generate WCF proxies from a Java web service, getting all the attribute markup on the proxy correct first time. This saved me hours and hours of laborious manual trial-and-error. Thank you - a highly recommended tool

http://wscfblue.codeplex.com/releases/view/46259#ReviewBy-rob_levine

If you want to try out WSCF.blue be sure to download the latest version 1.0.10 here:
http://wscfblue.codeplex.com/releases/view/48529

Beautiful REST services URLs in Windows Azure with WCF4’s routing integration feature

Update: It turns out that the necessary WCF4 config sections for standardEndpoints are not present in Windows Azure, although we are using a .NET 4-based Azure role :( Thanks for my readers Piotr and Rene for the hint! The config below has been updated.

We all know how certain people hate the .svc in URLs when they are designing and building REST services with WCF. Just because I had a question from a customer today how to have ‘beautiful’ URLs for a WCF service being hosted in Windows Azure I thought I will write up the very simple and straight-forward solution.

The only pre-requisite you need is .NET 4.0 (and thus WCF4).

WCF4 has a nice feature I like really a lot. It is the integration into the System.Web.Routing engine when it comes to hosting your services. You can simply add a route to your service implementations in the global.asax file – as seen in the code below. No need for .svc files, yiha!

<%@ Application Language="C#" %>
<%@ Import Namespace="System.Web.Routing" %>
<%@ Import Namespace="System.ServiceModel.Activation" %>
<%@ Import Namespace="Thinktecture.TecTeacher.MediaServices" %>
<script runat="server">
    void Application_Start(object sender, EventArgs e) 
    {
        RouteTable.Routes.Add(
               new ServiceRoute(
                   "media", new WebServiceHostFactory(),
                   typeof(MediaService)));
    }          
</script>

Together with the also new automatic help page feature and the automatic response format selection in WCF4 you get a nice REST service hosted in IIS. And obviously this can also be used in a Windows Azure Web Role which leverages IIS’s hostable web core (HWC).

<?xml version="1.0"?>
<configuration>
  <configSections>
    <sectionGroup name="system.serviceModel"
                  type="System.ServiceModel.Configuration.ServiceModelSectionGroup, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="standardEndpoints"
               type="System.ServiceModel.Configuration.StandardEndpointsSection, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
    </sectionGroup>
  </configSections>
  <system.web>
    <compilation debug="false"
                 targetFramework="4.0" />
  </system.web>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>
    <standardEndpoints>
      <webHttpEndpoint>
        <standardEndpoint helpEnabled="true"
                          automaticFormatSelectionEnabled="true">
          <security mode="None"/>
        </standardEndpoint>
      </webHttpEndpoint>
    </standardEndpoints>
  </system.serviceModel>
</configuration>

 

 

This is how the service’s response looks like in XML…

…and this is the JSON formatting:

That’s it. As you can see there is nothing Azure-specific, just plain WCF4.
Download a small sample solution.

Hope this helps someone.

Some important and helpful security-related fixes for WCF (.NET 3.5/3.5 SP1)

Just found on support.microsoft.com:

FIX: A hotfix that adds a SecurityBindingElement.AllowInsecureTransport property that allows the mixed-mode secured message to be sent over an unsecured transport in WCF is available for the .NET Framework 3.5 SP1 (KB971831)

The hotfix that is described in the article adds an AllowInsecureTransport property in the SecurityBindingElement class for the Microsoft .NET Framework 3.5 Service Pack 1 (SP1). The default value of this property is set to False. When the property is set to True, the mixed-mode secured message can be sent over an unsecured transport in Windows Communication Foundation (WCF) services, such as HTTP. The property should be set to True only when the client and service are in a trusted environment.

A hotfix is available that adds an endpoint behavior that lets services use multiple threads to receive secure messages in the .NET Framework 3.5 SP1 (KB975955)

In the .NET Framework 3.5 Service Pack 1 (SP1), you can use only one thread to receive secure messages in a Windows Communication Foundation (WCF) service that uses message security. This hotfix adds the dispatcherSynchronization endpoint behavior that lets you use multiple threads to receive secure messages at the same time. Additionally, the behavior contains the maxPendingReceives property. This property enables you to set the maximum number of threads that receive secure messages at the same time.

FIX: The WCF security stack does not support the SHA-256 hashing algorithm in the .NET Framework 3.5 (KB973975)

In the Microsoft .NET Framework 3.5, the Windows Communication Foundation (WCF) security stack supports the SHA-1 hashing algorithm but does not support the SHA-256 hashing algorithm. This hotfix enables the WCF security stack to support SHA-256 so that service endpoints can support SHA-256 for SOAP messages.