WCF Express Interop Bindings

Something that might come as a surprise for somebody who worked with WCF (even for years) but never had to interoperate with another platform than .NET is how much WCF isn’t interoperable out-of-the-box.

It isn’t WCF fault really.  It’s SOAP’s fault and its lousy specs.  Well…  not so much lousy as big, complicated and extremely flexible.  The result is that each vendor implements a subset of those or at least expose a subset as the default configuration for web service.  So although you’re using a platform that is interoperable, the web services you are exposing are not.

Of course, if you’re exposing your web service using basic http binding with no security, no reliability, no session and plain old XML (even for big binary payload), you are probably interoperable (and pretty unsecure).  If you use a fancier bindings, chances are you won’t be able to interoperate with another platform.

But rest assure, instead of mocking around binding configuration until you can talk to this Java server over there, Microsoft gives us the WCF Express Interop Bindings on CodePlex.  Take a look at this picture (from the site) and reflect on how “Universal” SOAP is when you have platform technology names on both side of the diagram!

clip_image001_2

Globalization and web services

I always found that globalization is the poor child of computer literature.  In any .NET book, you won’t hear specifically about globalization before chapter 23.  You can even tell it’s not shooting high on the radar when you look at the ways globalization was implemented in the three main front-end Frameworks of .NET:  WinForm (great!), ASP.NET (retrofitted in sub-optimal way in .NET 2.0) & WPF (totally Byzantine and not even in line with the rest of .NET Framework).

Since I work in Montreal –a bilingual city in a bilingual country– I’m confronted to globalization on nearly every projects I’m involved in.  So with time you do build up your bag of tricks & patterns around globalization.

I recently posted a blog talking about the W3C globalization specs for SOAP endpoints, WS-I18N.  I found that spec quite interesting because it describes a standard way to handle globalization at a web service level.

Actually, the most common approach I’ve seen (or architected myself) with globalization & web services is to not localize it.  For the time zone, you can usually get away by returning time in standard GMT and let the client localize it.  For languages, if your application is only bilingual (as is often the case in Canada), you can get away by returning the localized data in both languages since you will typically have properties such as FrenchTitle & EnglishTitle in your data contracts.

This approach has a lot of advantages.  First is simplicity of course.  But you also get other advantages.  For instance, if your application needs to flick between languages in a real-time fashion, with this approach you do not need to interrogate web services again (and potentially get different data, which would make the change language feature a refresh feature at the same time, which is weird).  It’s also easier to implement caching if you do not have out-of-band parameters also.

Sometimes you won’t have that luxury.  For instance, the project I’m currently working on is multi-lingual in the sense the number of supported cultures is open.  We therefore have to model our database with localized value in a vertical way (one row per culture).  For the services we were still lucky.  The only localized values are list of values (lookups) ; for those we manage them explicitly in the respective service.  The other services aren’t localized:  the content is in the language the user punched it in.  Also, we raise SOAP faults with English-message.  The architecture guideline there is that the services aren’t producing user-messages, they are APIs, they can raise faults, but it’s up to the application to interpret the fault and inform the user accordingly.

I think it’s important to think about the role of your services in your application, system, enterprise or context in general.  If it’s an API for smart applications to use, I would really aim at not localizing them.  This way you can rip the benefit of simplicity but also, you won’t get into confusion of an application being in culture X calling services in culture Y.  If your services are meant to be use by themselves or by thin applications (e.g. something doing an xslt-transform on the data returned by your services), you should manage the culture at the service layer.

Globalization Patterns in WCF (WS-I18N implementation)

I recently came across a good Code Project article:

Globalization Patterns in WCF (WS-I18N implementation)

written by Pablo M. Cibraro.

Basically, there exists a standard specs (WS-I18N) describing how to pass international information (e.g. locale & time zone) to a SOAP endpoint in order for that web service to return you localized data.

An interesting aspect of that spec is that it passes the international information out-of-band in the soap header.  It therefore doesn’t contaminate your web service signature and if you skip that header, you gracefully get data in the default locale & time zone.

Now Pablo shows how to implement this pattern (or specs) in WCF.

He first shows the server-side, the hard way, using a message-contract where he defines the entire message format of a web-method, including the international header.

He then goes on and shows how you would set the header on the client-side, using message inspectors.

He finally shows a nicer server-side implementation where you do not use message contract (which are frankly annoying to use) but instead use inspectors to gather information from the header.  This hints toward a great system-strategy where you could set the culture of the request thread to the header-culture.

It’s all great stuff!

Using WCF for exposing and consuming OData

I just published a new article on CodeProject:

http://www.codeproject.com/KB/webservices/WCFDataServices.aspx

It hasn’t been reviewed yet.

In that article I do showcase different ways to use OData to expose your data using WCF Data Services.  The samples grow in complexity, going from the standard hello world of WCF Data Services (ie exposing your DB on a web endpoint), to more advanced scenarios (e.g. transforming your data or even exposing data not coming from a database).  I also show a way to consume OData in a .NET Client.

I believe OData is going to gain more and more tractions as different client and server products include support for it.  It’s a really neat way of exposing data that is queryable but from the middle tier, hence giving you much more flexibility than exposing a database server directly.

Consuming FaultContract with Restful WCF services

I’ve learned something new this morning while doing a proof-of-concept around WCF REST services.

I did a little WPF demo app both hosting and consuming web services.  I was trying to handle faults properly, using fault contracts.  I had experience with SOAP-based WCF web services, so I went the motions, starting by creating a fault contract:

[DataContract]
public class WrongInteger
{
    [DataMember]
    public int Value { get; set; }
}

A fault contract is just a data contract that you throw with an exception.

Then I declared that my service operation can raise that fault:

[WebInvoke(Method = "PUT")]
[OperationContract]
[FaultContract(typeof(WrongInteger))]
void PushInteger(int a);

Then I implemented the operation, throwing the usual fault exception:

  void IPushService.PushInteger(int a)
  {
    if (a == 2)
    {
        throw new FaultException<WrongInteger>(new WrongInteger { Value = 2 });
    }
  }

This code works fine if you’re using SOAP WCF services.  But with REST WCF services, your HTTP response will just be gibberish with an status of bad request.

Digging on the web I found there’s actually a new class, WebFaultException, derived from FaultException that you must use with REST web services:

void IPushService.PushInteger(int a)
{
    if (a == 2)
    {
        throw new WebFaultException<WrongInteger>(new WrongInteger { Value = 2 }, HttpStatusCode.InternalServerError);
    }
}

This will spit out the serialized fault contract into the http-response.  Now for the client side code

using (WebChannelFactory<IPushService> factory = new WebChannelFactory<IPushService>("myService"))
{
    IPushService service = factory.CreateChannel();

    try
    {
        service.PushInteger(2);
    }
    catch (WebFaultException<WrongInteger> ex)
    {
        Dispatcher.Invoke((Action)delegate
        {
            MessageBox.Show(string.Format("Expected exception:  {0}, {1}", ex.Message, ex.Detail.Value));
        });
    }
    catch (Exception ex)
    {
        Dispatcher.Invoke((Action)delegate
        {
            MessageBox.Show(ex.Message);
        });
    }
}

Well, another surprise, that doesn’t work either.  The thrown exception isn’t a fault exception, it’s a protocol exception.

I haven’t found a way to make this work.  Actually, I’ve read that you should craft HTTP request by hand and look at the http-response in order to get your fault.

Well, that’s a bit of a disappointment!  It seems that the fault scenario wasn’t taught through from the get-go.  For instance, the WebFaultException class is new in .NET 4.0.  So in .NET 3.5, you couldn’t fault:  your exceptions would just be generic exceptions.  Now we can transmit a fault but we can’t consume it.  Maybe in .NET 5.0…

It’s especially frustrating since it would be easy to write a WCF inspector to do that job…

If you find a more elegant way, please let me know!