Wcf interoperability wish list

@YaronNaveh

If you have already filled your duty please share it in the comments. Here is my take.

My WCF 4.0+1 interoperability wishlist:

Be more forgiving. In so many cases I have sent a good request to the server, got a correct response, and had to workaround a non happy proxy complaining on "timestamp missing in the response", "expected to get serialized token" etc. If I do not explicitly require this I do not want Wcf to do it for me.

Low level extension point. Ok, so I got a wrong certificate reference from the other party, I just need to change it in the incoming message so Wcf will not throw some exception. I googled for "changing wcf message" and got a nice link about message inspector. Too bad it cannot change the security applied message. I had to use a custom encoder, which is really much harder to implement / maintain.

Better error messages. When you compile a VS project you sometimes get an error message like this:

The type X could not be found (are you missing an assembly reference?)

I wish Wcf would also have this. For exmple:

The EncryptedKey clause was not wrapped with the required encryption token 'System.IdentityModel.Tokens.X509SecurityToken'. Are the client and server certificates in sync?

I have actually posted a series of posts titled "Cryptic WCF error messages" which tries to supply the most common cause for many errors.

Better trace / debug. Wcf trace is really great and today we can already debug into the framework. So what do I want here? I'm not sure yet, I just know these are essential tools for interoperability and I want them easier and better.


And more...

In addition there are some lower level requirements that are not supported today. Not all are priority zero, but I have seen all of them in interoperability scenarios.

Encrypting / Signing specific elements in the message body (e.g. using xpath)

Control over xml signature algorithm / transformations

Support of the DSA algorithm

User / Pass authentication at the message level with a password hash + control over the nonce / created fields

WS-Addressing August 2004

Mime, SwA, Dime (probably a bigger effort than the others...)

Control over the security element mustUnderstand attribute

Native support for JKS (Java Key Store)

Keeping alive binding converter from the evil Azure trial expiration...

Some people require to use specific namespace prefixes in their Xml. Don't ask me what is it good for, but Wcf should allow it. I have seen this especially in interoperability scenarios.

Better coverage of wsdls - even today not all are parsed or pass code generation. Some examples last back to the old the 2.0 days and are easy to identify and fix.

I'm pretty sure I have more somewhere but this should be enough for one version :)

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

Serialization should eat its own dog food

@YaronNaveh

An enum in c# can be used as a bit field by adding the Flags attribute:

[Flags]
public enum Groups
{
   Admins = 1,
   Users = 2,
   Guests = 4,
   RemoteUsers = 8
}

We can then define a class that uses it:

[DataContract]
public class User
{
   [DataMember]
   public Groups Groups {get; set;}
}

When we serialize an instance of the class, with either .Net 2.0 serialization or data contract serialization, we get something like this:

...
<Groups>Admins RemoteUsers</Groups>
...

assuming the active flags are Admins and RemoteUsers.

If we deserialize this back to the class everything works fine. But what if the xml needs to be manually parsed for some reason and we need to do something like this:

Enum.Parse(typeof(Groups), "Admins RemoteUsers");

We would get this exception:

Requested value 'Admins RemoteUsers' was not found.

The reason is that Enum.Parse expects a comma between the values and not a space. So this fails:

Enum.Parse(typeof(Groups), "Admins RemoteUsers");

while this work:

Enum.Parse(typeof(Groups), "Admins,RemoteUsers");

Since a space is not valid inside an enum member we can safely do this when reading from the xml:

Enum.Parse(typeof(Groups), value.Replace(" ", ","));

Which will work.

However in the general case manually deserializing a value is dangerous. For example the enum may contain serialization flags:

[Flags]
public enum Groups
{
   [XmlEnum(Name="administrators")]
   Admins = 1,
...
}

This will affect the resulting xml:

...
<Groups>administrators RemoteUsers</Groups>
...

and Enum.Parse will fail. So it is always better to let whoever generated the xml from the first place to eat its own dog food and deserialize it back.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

Is there "too much interoperability"?

@YaronNaveh

The recent survey and my wish list had led me to some philosophical reflections...

In my mind having a good interop support by a web services toolkit is a paradox. Interoperability with every other toolkit in the market would mean supporting new and emerging standards as well as old and aging, pushing for best practices and instustry standards along side with used-to-be-best-practices and proprietary standards.

One example for the last point is Wcf support of clear username and password in the message. Since this is a worse practice to send user/pass on the clear, Wcf did not allow it initially. But if you are a developer instructed to consume a third party which uses exactly that - the last thing you want to hear from your toolkit is "The provided URI scheme is invalid". For this reason I have written ClearUsernameBinding and for the same reason Wcf 4.0 now supports an "insecured transport" mode.

So are we doomed to stay with worse practices just because of interoperability? And will we need forever legacy standards such as DIME or WS-Addressing draft august 2004 just for the sake of backward compatibility? I hope not. So I expect Soap stack vendors (or Rest-stack for the matter) to do a smart phase-out of these standards / practices.

One attempt was back in .net 2.0 days where a web service would have a best practice mode (WSI compliance) and in order to use non WSI stuff you had to explicitly turn off some flag or get a compilation error. This is not good enough - it makes the bad practice too easy. I hope in the next version of Wcf we will not see too many "allow insecure" / "no validation" flags, nor support for sunsetting standards. Instead the SDK should supply detailed and functioning examples on how to extend Wcf to do this. Will it shout to developers "you're doing something bad" if they try to create a new service using these samples more than a "no interop" flag or compilation error? I believe so since developers know they do something wrong when they see too much code to maintain... And these samples will allow interoperability where absolutely required.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

Wcf Interoperability Survey

@YaronNaveh

Microsoft has published an online survey on web services interoperability using Wcf . If you have ever surved / consumed Wcf from another platrofm (including .Net 2.0) you probably have one or two pains to share. This survey is your chance to be heard.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!

Wcf Security Interoperability Series

@YaronNaveh

If you are a fan of Wcf security interoperability blogs - and if you read my blog you must admit you secretly are - you do not want to miss dhurba's series on WCF security interoperability.

As a side note, in the last weeks there is a bug with MSDN hosted blogs (as dhurba's) where I am sometimes prompted for a password when surfing there. This mostly happens with Chrome, but sometimes also in IE. This is usually solved by restarting the browser (better chances with IE) but is really annoying.

@YaronNaveh

What's next? get this blog rss updates or register for mail updates!