NathanA's Mostly Web Services Blog

WCF Express Interop Binding on App Fabric TV

2011-07-27T16:34:00Z

Here’s a new video I’m in from App Fabric TV doing a demo of the Express Interop Bindings.

The wizard and bindings are available for download here: http://wcf.codeplex.com/releases/view/68276

And all those great interop resources are here: http://msdn.microsoft.com/en-us/netframework/webservicesinterop.aspx

Windows Azure AppFabric June CTP released

2011-06-21T19:56:19Z

Hurry over to http://portal.appfabriclabs.com/ to sign up, space is limited.

This release showcases the new container, management and tooling for creating reliable, scalable applications in Windows Azure. A complete introduction to all of the features and links to more resources is on the AppFabric Team Blog.

Exciting new bindings for WCF<->Java Interop

2011-06-21T16:11:03Z

When configuring web services you have a lot of choices. You have security algorithms, token types, encodings, reliability and many other settings to worry about. Now when your clients and services are written using different stacks the challenge becomes finding configurations that both share. The good news is generally there are configurations that will work between many of the major web services stacks. The bad news is it is often difficult to figure out what these configurations are and then it’s a challenge to configure both sides correctly.

I’m a little bit late to this party, but last week we released a set of new bindings along with Visual Studio 2010 integration that makes finding matching configurations and applying that configuration to WCF as simple as navigating a wizard. All this goodness, the WCF Express Interop Bindings, is available on codeplex right now. These bindings along with our previously released white papers provide a road map to achieving interop over some the most difficult WS-* standards (security, secure conversation, reliable messaging, MTOM). Here’s what others are saying:

http://wso2.com/blogs/thesource/2011/06/connecting-microsoft-services-to-wso2-just-got-a-whole-lot-easier/

http://webservices20.blogspot.com/2011/06/test-drive-shiny-new-wcf-interop.html

http://blogs.msdn.com/b/appfabric/archive/2011/06/13/announcing-wcf-express-interop-bindings.aspx

http://weblogs.asp.net/cibrax/archive/2011/06/13/interop-bindings-for-wcf-released-in-codeplex.aspx

Text Encoding and WCF

2011-04-05T18:24:45Z

For the most part setting the encoding (UTF-8, UTF-16, etc.) on a WCF service is pretty simple: set textEncoding on basicHttpBinding/wsHttpBinding or encoding on a textMessageEncoding in a customBinding. It works in almost all cases, but there’s a surprising number of ways of indicating the encoding of message:

the content type of the message
an XML declaration at the start of the message
a BOM (byte order mark) that is the first 2 or 3 bytes (depending on encoding) of the message

Next an encoding of UTF-16 doesn’t specify a single encoding. It could be either big endian or little endian.

We can glean a few rules from RFC 3023 - XML Media Types:

The encoding in the content type should take precedence over any other encoding indications. If the content type is UTF-8 but the XML declaration is UTF-16, the message should actually be UTF-8. For example, a router could receive a UTF-16 message and reencode it as UTF-8 to save bandwidth. The router would change the content type but would keep the actual text of the entire message unchanged.
When the encoding is specified as UTF-16, there must be a BOM.
When the encoding is specified as UTF-16LE or UTF-16BE, there must not be a BOM.
An XML declaration is optional in the presence of other indications of encoding.

The TextMessageEncoder that ships with WCF is a little too strict in a couple of ways:

When encoding is specified as UTF-16, it requires an XML declaration.
The content type and the encoding specified in the XML declaration must be consistent.

This can lead to problems in interoperability. Other web service clients can produce messages violating those WCF restrictions and the result is a 400 Bad Request with no additional information. To work around this we will need a custom message encoder.

First we can start with the CustomTextMessageEncoder sample. This sample allows you to specify any .NET supported encoding for an endpoint instead of just UTF-8 and UTF-16 but doesn’t do anything about the restrictions above. Additionally it is necessary to specify which encoding you’ll use when deploying your endpoint.

The new text message encoder I’ll show will accept UTF-8 and UTF-16 encoded messages and workaround those restrictions. I’ll focus on the message encoder since that is where the action happens, but there is additional boilerplate necessary. You will also need a MessageEncoderFactory (called by the framework to create instances of the MessageEncoder), MessageEncodingBindingElement (used to plug this into the channel stack and allow the framework to create instances of the MessageEncoderFactory) and BindingElementExtensionElement (allows it to be used in config, this is optional). The CustomTextMessageEncoder sample has excellent examples of each of these.

Let’s start with ReadMessage:

   1: public override Message ReadMessage(ArraySegment<byte> buffer,

   2:                     BufferManager bufferManager, string contentType)

   3: {

   4:     this.contentType = contentType;

5:

   6:     byte[] msgContents = new byte[buffer.Count];

   7:     Array.Copy(buffer.Array,

   8:                 buffer.Offset, msgContents, 0, msgContents.Length);

   9:     bufferManager.ReturnBuffer(buffer.Array);

  10:     // most interoperable to include the xml declaration

  11:     this.writerSettings.OmitXmlDeclaration = false;

  12:     // save the encoding for when we write the response

  13:     this.writerSettings.Encoding = GetEncoding(contentType, msgContents);

14:

  15:     Encoding xmlDeclEncoding = GetXmlDeclEncoding(

  16:                                 writerSettings.Encoding, msgContents);

17:

  18:     // xml declaration encoding doesn't match, need to reencode

  19:     if (xmlDeclEncoding != null &&

  20:         xmlDeclEncoding.WebName != this.writerSettings.Encoding.WebName)

  21:     {

  22:         msgContents = Encoding.Convert(

  23:                         this.writerSettings.Encoding,

  24:                         xmlDeclEncoding, msgContents);

  25:     }

26:

  27:     MemoryStream stream = new MemoryStream(msgContents);

  28:     XmlReader reader = XmlReader.Create(stream);

  29:     return Message.CreateMessage(reader, maxSizeOfHeaders, MessageVersion);

  30: }

This does a couple of things. It uses some helper functions to help determine the actual encoding of the message and stores that in the XmlWriterSettings that will be used in the response. Unfortunately, there isn’t an implementation of XmlReader that ships with .NET that will ignore the encoding specified in the XML declaration so if the content type and XML declaration disagree the message needs to be reencoded to match the XML declaration. Finally XmlDictionaryReader is the source of the restrictions above so we use XmlReader.Create to avoid that.

Now let’s look at the encoding helper functions:

   1: Encoding GetXmlDeclEncoding(Encoding contentTypeEncoding, byte[] message)

   2: {

   3:     // get a possible xml declaration from the message

   4:     string contents = contentTypeEncoding.GetString(message, 0, 100);

5:

   6:     // capture the encoding from the xml declaraion

   7:     string pattern =

   8:         "<\\?xml\\sversion=\"1.0\"\\sencoding=\"(?<encoding>[\\w|-]+)\"";

9:

  10:     Match m = Regex.Match(contents, pattern, RegexOptions.ExplicitCapture);

11:

  12:     if (m.Groups["encoding"].Success)

  13:     {

  14:         return Encoding.GetEncoding(m.Groups["encoding"].Value);

  15:     }

16:

  17:     return null;

  18: }

GetXmlDeclEncoding tries to find an encoding pseudoattribute in a possible XML declaration at the beginning of the message. Since the message must be encoded as specified in the content type we use that encoding to decode the byte array. XmlReader provides ways to determine values specified in the XML declaration, but as mentioned above it will throw when it discovers the specified encoding doesn’t match the actual encoding. A regular expression match is used to avoid this. We only decode the first 100 bytes to minimize overhead.

   1: Encoding GetEncoding(string contentType, byte[] message)

   2: {

   3:     Encoding encoding;

   4:     string charSet = new ContentType(contentType).CharSet.ToLower();

   5:     if (charSet == "utf-8")

   6:     {

   7:         encoding = new UTF8Encoding();

   8:     }

   9:     else if (charSet == "utf-16")

  10:     {

  11:         if (message[0] == 0xff && message[1] == 0xfe)

  12:         {

  13:             encoding = new UnicodeEncoding(false, true);

  14:         }

  15:         else if (message[0] == 0xfe && message[1] == 0xff)

  16:         {

  17:             encoding = new UnicodeEncoding(true, true);

  18:         }

  19:         else

  20:         {

  21:             throw new InvalidOperationException("No byte order mark " +

  22:                 "detected.  The byte order mark is required when " +

  23:                 "charset=utf-16.");

  24:         }

  25:     }

  26:     else if (charSet == "utf-16le")

  27:     {

  28:         encoding = new UnicodeEncoding(false, false);

  29:     }

  30:     else if (charSet == "utf-16be")

  31:     {

  32:         encoding = new UnicodeEncoding(true, false);

  33:     }

  34:     else

  35:     {

  36:         // this could be replaced by a call to Encoding.GetEncoding

  37:         throw new InvalidOperationException("Unrecognized charset: "

  38:                     + charSet);

  39:     }

40:

  41:     return encoding;

  42: }

GetEncoding is a fairly straightforward implementation of the rules above. For undifferentiated UTF-16 it checks the BOM and creates the proper encoding that will include a BOM. For UTF-16LE/BE it creates the proper encoding and suppresses the BOM (it ignores whether a BOM is included making a bit looser on read). This only recognizes UTF-8 and UTF-16, but it could be modified to call Encoding.GetEncoding to get any supported encoding.

Finally let’s look at writing a message:

   1: public override ArraySegment<byte> WriteMessage(Message message,

   2:                 int maxMessageSize, BufferManager bufferManager,

   3:                 int messageOffset)

   4: {

   5:     MemoryStream stream = new MemoryStream();

   6:     XmlWriter writer = XmlWriter.Create(stream, this.writerSettings);

   7:     message.WriteMessage(writer);

   8:     writer.Close();

9:

  10:     byte[] messageBytes = stream.GetBuffer();

  11:     int messageLength = (int)stream.Position;

  12:     stream.Close();

13:

  14:     int totalLength = messageLength + messageOffset;

  15:     byte[] totalBytes = bufferManager.TakeBuffer(totalLength);

  16:     Array.Copy(messageBytes, 0, totalBytes, messageOffset, messageLength);

17:

  18:     ArraySegment<byte> byteArray =

  19:         new ArraySegment<byte>(totalBytes, messageOffset, messageLength);

  20:     return byteArray;

  21: }

22:

  23: public override void WriteMessage(Message message, Stream stream)

  24: {

  25:     XmlWriter writer = XmlWriter.Create(stream, this.writerSettings);

  26:     message.WriteMessage(writer);

  27:     writer.Close();

  28: }

These are actually identical to the WriteMessage implementations in the custom encoder sample. They simple use the writerSettings populated by ReadMessage to write out the message.

This will require a CustomBinding to use. It is possible to do it in code:

   1: var messageEncoding = new ImprovedTextMessageBindingElement

   2: {

   3:     // any message version is supported

   4:     MessageVersion = MessageVersion.Soap12

   5: };

6:

   7: var transport = new HttpTransportBindingElement();

8:

   9: var binding = new CustomBinding(messageEncoding, transport);

Or config:

   1: <customBinding>

   2:     <binding>

   3:         <improvedTextMessageEncoding />

   4:         <httpTransport />

   5:     </binding>

   6: </customBinding>

7:

Deciphering a SOAP fault with a 400 status code

2011-03-31T23:55:19Z

Recently working with a partner I came across a solution for a limitation in WCF error handling. The root of the issue is a difference between SOAP 1.1 and SOAP 1.2 in the allowed HTTP status codes when a SOAP fault is returned. For SOAP 1.1, the status code must be 500 “Internal Server Error”. For SOAP 1.2, it varies based on the type of the SOAP fault. For env:Sender, the status code is 400 “Bad Request”, but for anything else it is 500 like SOAP 1.1.

When WCF receives an HTTP error code it wraps it in an exception, FaultException in the case of 500 and ProtocolException in the case of 400. This means when a service returns a SOAP fault with a 400 status code, all the information about it is lost instead of showing up in a nicely populated FaultException. Actually it isn’t lost, it’s just hidden. The InnerException of the ProtocolException is a WebException generated by the HTTP response. And on the WebException, lo and behold, is the the actual WebResponse with that SOAP fault just waiting to be read out of the stream. So with a little manipulation you can turn these ProtocolExceptions into FaultExceptions:

        1: static FaultException ParseProtocolExecption(ProtocolException ex)

       2: {

       3:     try

       4:     {

       5:         System.IO.Stream stream = (ex.InnerException as WebException).Response.GetResponseStream();

       6:         System.Xml.XmlReader xmr = System.Xml.XmlReader.Create(stream);

       7:         Message message = Message.CreateMessage(xmr, (int)stream.Length, MessageVersion.Soap12);

       8:         MessageFault mf = MessageFault.CreateFault(message, (int)stream.Length);

       9:         FaultException fe = new FaultException(mf);

      10:         message.Close();

      11:         return fe;

      12:     }

      13:     catch (Exception)

      14:     {

      15:         return new FaultException(ex.Message);

      16:     }

      17: }

Note if there isn’t a SOAP fault in the response, this will throw again, you’ll want to handle that in the best way for your application.

TestApi v0.3 released

2009-07-27T19:45:00Z

TestApi is a collection of test and utility API's written to make testing WPF, WinForms, .NET, and Win32 applications easy. I made some contributions to last week's release (combinatorial variation generation). Also new is a fault injection engine. Previous features have included:

Command line parsing
Visual verification
Application control
Several WPF utilities

You can check it out here: http://testapi.codeplex.com/

XAMLFest

2009-05-22T18:49:00Z

If you're interested in what XAML can do for you today and what tooling is available, check out XAMLFest. There's a whole series of web seminars on WPF, Silverlight, Blend, and Visual Studio.

New XAML features in .NET 4.0 Beta 1

2009-05-22T17:51:00Z

There's a whole new XAML stack in the recently released beta 1 (download here) with a bunch of exciting new features making XAML even more expressive. You can check out Rob's blog and Channel 9 for an overview. I thought I'd discuss some new features for designing new types (Activities, Services, etc) in XAML. Sorry, this isn't supported for WPF as of now.

When you fire up Visual Studio 2010 and create a new WCF or WF project, you'll see there's now a XAML file that defines your workflow or service.

For WCF, the service is actually "loose" XAML. It doesn't create a new type and will simply be instantiated by your service host with the equivalent of XamlServices.Load.

For WF, the workflow is defined as a new type that will be compiled as part of your project, if you look at the XAML in the new project there'll be something like this:

<p:Activity x:Class="WorkflowConsoleApplication1.Sequence1" ...

Nothing new here except x:Class is applied to a WF type instead of WPF. Now lets add some arguments to the Activity:

<p:Activity x:Class="WorkflowConsoleApplication1.Sequence1" ...>

<x:Members>

<x:Property Name="Input" Type="p:InArgument(x:String)" />

<x:Property Name="Output" Type="p:OutArgument(x:String)" />

<x:Property Name="Temp" Type="x:String" />

...

Here's where we see some of the new XAML features. x:Members defines a collection of new members to add to this type. x:Property adds a property. Name and type are specified here, visibility (public, protected, etc) can be specified with the Modifer property. We can also see the new generics support as p:InArgument(x:String) refers to the type InArgument<string>. All of the new language features mentioned in Rob's post can be used in this XAML.

Lots of new WCF REST resources available

2008-10-30T23:58:00Z

A new developer center just for WCF REST is now live at MSDN: http://msdn.microsoft.com/wcf/rest.

Plus the WCF REST Starter kit with oodles of goodies is available at Codeplex: http://www.codeplex.com/aspnet/Wiki/View.aspx?title=WCF%20REST.

There's also a forum to discuss the starter kit: http://forums.asp.net/1180.aspx

PDC is coming

2008-10-07T23:38:00Z

Uncloaking after a long absence, here's some of what is new and exciting for the next release of WCF and WF: everything can be done in XAML.

http://blogs.windowsclient.net/rob_relyea/archive/2008/09/30/pdc08-xaml-talk.aspx

http://channel9.msdn.com/pdc2008/TL36/

WCF Web Programming Help Page

2007-09-17T19:51:00Z

When developing a WCF service using the new web programming features, it's natural to make sure all the basics are taken care of by entering the service address into a browser. When the service is running correctly, this page is returned:

This indicates the service is running but little else. There's lots of other information that would be useful to include, maybe something like this (I'm not an html wizard so this could be greatly improved:)

This is made possible by including an OperationContract like this in the ServiceContract:

[WebInvoke(UriTemplate = "*", Method = "*")]

[OperationContract]

Message Help(Message m);

The method can be named anything and UriTemplate and Method can be tweaked to serve custom help for only certain situations. As shown, any message routed to the service that doesn't match another operation contract will call Help. To implement this method I created two classes, WebHttpHelpPageGenerator and WebHttpHelpPageMessage. WebHttpHelpPageGenerator handles collecting the information to display and WebHttpHelpPageMessage derives from Message and handles formatting that information into html. These are used to implement Help like this:

public Message Help(Message m)

{

return WebHttpHelpPageGenerator.GenerateHelpPage();

}

WebHttpHelpPageGenerator.GenerateHelpPage is able to accomplish its task by using OperationContext.Current.EndpointDispatch.ContractName and OperationContext.Current.Host.Description.Endpoints to find the current ServiceEndpoint which contains a list of Operations and the CLR type of the contract:

ServiceEndpointCollection endpoints = OperationContext.Current.Host.Description.Endpoints;

OperationDescriptionCollection operations = null;

Type contract = null;

foreach (ServiceEndpoint endpoint in endpoints)

{

if (endpoint.Contract.Name == OperationContext.Current.EndpointDispatcher.ContractName)

{

contract = endpoint.Contract.ContractType;

operations = endpoint.Contract.Operations;

break;

}

So with that list and a little reflection all the necessary information can be exctracted:

message.TitleTextString = contract.Name;

foreach (OperationDescription operation in operations)

{

WebGetAttribute get = operation.Behaviors.Find<WebGetAttribute>();

WebInvokeAttribute invoke = operation.Behaviors.Find<WebInvokeAttribute>();

if (get == null && invoke == null) continue;

MethodInfo method = contract.GetMethod(operation.Name);

OperationInfo info = new OperationInfo

{

OperationName = operation.Name,

Method = get != null ? "GET" : invoke.Method,

BodyStyle = get != null ? get.BodyStyle.ToString() : invoke.BodyStyle.ToString(),

UriTemplate = get != null ? get.UriTemplate : invoke.UriTemplate,

ReturnType = method.ReturnType.ToString(),

Parameters = GetFormattedParameters(method.GetParameters()),

RequestFormat = get != null ? get.RequestFormat.ToString() : invoke.ResponseFormat.ToString(),

ResponseFormat = get != null ? get.ResponseFormat.ToString() : invoke.ResponseFormat.ToString()

};

info.OperationName = operation.Name;

message.Operations.Add(info);

}

OperationInfo is just a helper class to encapsulate all the data collected. Finally the new WebOperationContext class is used to set the content type to text/html:

WebOperationContext.Current.OutgoingResponse.ContentType = "text/html";

This builds a general purpose framework that can be called from any service using the new web programming features, though I'm sure I missed plenty of corner cases (like async programming.)

WCF Web Programming or: How I Learned to Stop Worrying and Love Uri Templates

2007-09-14T00:52:00Z

Using WCF in web programming scenarios is much simplified in Orcas beta 2 (see http://hyperthink.net/blog/CategoryView,category,indigo.aspx and scroll down for more discussions). Maybe you want to write an app that searches Flickr, how can you use WCF? Well, define an interface that exposes the functionality you need:

[ServiceContract]

interface IFlickrSearch

{

[WebGet(UriTemplate="services/rest/?method=flickr.photos.search&api_key={appId}&tags={searchTerms}&extras={extras}&per_page={perPage}",

BodyStyle=WebMessageBodyStyle.Bare)]

[OperationContract]

[XmlSerializerFormat]

rsp Search(string appId, string searchTerms, string extras, int perPage);

}

The Flickr API is very rich, so this is just the tip of the iceberg, but just this little bit of code accomplishes a lot. We have all the WCF v1 attributes (ServiceContract, OperationContract) and some new stuff. WebGet says the request will be a GET and UriTemplate describes how the parameters will be turned into the uri for the request. This provides a great deal of flexibility in defining your interface to the service you're programming against. The Bare BodyStyle specifies to the serializer there won't be wrapper element named SearchResponse on the response. XmlSerializerFormat is another holdover specifying the XmlSerializer, and rsp is a type generated with xsd.exe to deserialize the response.

Now we're ready to call Flickr:

WebChannelFactory<IFlickrSearch> factory =

new WebChannelFactory<IFlickrSearch>(new Uri("http://api.flickr.com"));

IFlickrSearch channel = factory.CreateChannel();

rsp flickrRsp = channel.Search(AppId, searchTerms, Extras, perPage);

And that's it.

Maybe you're saying XmlSerializer is way too 20th century and you'd like use something more 21st, like XLinq.

[ServiceContract]

interface IFlickrSearch

{

[WebGet(UriTemplate = "services/rest/?method=flickr.photos.search&api_key={appId}&tags={searchTerms}&extras={extras}&per_page={perPage}",

BodyStyle = WebMessageBodyStyle.Bare)]

[OperationContract]

XElement Search(string appId, string searchTerms, string extras, int perPage);

}

We've just taken out the XmlSerializerFormat attribute and replaced the rsp type with XElement. Now we can use Linq and turn the Flickr search into a SyndicationFeed (another new WCF Orcas feature):

SyndicationFeed feed = new SyndicationFeed();

feed.Title = new TextSyndicationContent("Flickr search");

feed.Items =

from photos in flickrXml.Elements("photos").Elements("photo")

select SyndicationItemFromXElement(photos);

Just add this to a service and now you have a Flickr search you can subscribe to in the feed aggregator of your choice.

Getting started with LINQ

2007-09-12T19:28:00Z

Here's a great site with a bunch of samples if you've said to yourself "I'm pretty sure I can do this with LINQ, but I'm not quite sure how."

101 LINQ Samples

Custom SOAP Headers: WCF and ASMX

2007-05-29T23:59:00Z

First the good news, WCF clients should just work with ASMX services that use custom SOAP headers.

Now the not so good news, ASMX clients will work with WCF services that use headers, but the object model is pretty funky. Say you want to do something really crazy like have a header of type string. The ASMX client will represent that header with a class that looks like this:

[System.Xml.Serialization.XmlTypeAttribute(Namespace="http://www.w3.org/2001/XMLSchema")]
[System.Xml.Serialization.XmlRootAttribute("StringHeader", Namespace="http://xwsinterop/soapwsdl/headers", IsNullable=true)]
public partial class @string : System.Web.Services.Protocols.SoapHeader {

    private string[] textField;

    /// <remarks/>
    [System.Xml.Serialization.XmlTextAttribute()]
    public string[] Text {
        get {
            return this.textField;
        }
        set {
            this.textField = value;
        }
    }
}

To use this class, assign a new string array of length 1 to Text and then assign the value of the header to that element and it will work as expected. These sorts of classes will be generated by ASMX for any simple type, the workaround is to use wrapper classes around the headers on the WCF side. This will result in a somewhat clunky OM, but it will make sense.

Custom SOAP Headers: WCF and Java

2007-05-29T23:29:00Z

First the good news, WCF clients should just work with Java services that use custom SOAP headers.

Now the not so good news, Java proxies generated from the default WCF WSDL won't include the SOAP headers in the object model. The root problem is most Java platforms represent headers in WSDL differently than WCF. In WCF, the body and the headers are defined in different WSDL message elements:

<wsdl:message name="OneHeaderIntRequest">
<wsdl:part name="stringBody" element="tns:stringBody" />
</wsdl:message>
<wsdl:message name="OneHeaderIntRequest_Headers">
<wsdl:part name="IntHeader" element="tns:IntHeader" />
</wsdl:message>

but for most Java platforms, only one message with multiple parts is defined:

The workaround is to modify the WCF WSDL to mirror the Java-style WSDL (eliminate the OneHeaderIntRequest_Headers message and move the IntHeader part into the OneHeaderIntRequest message in this case). Unfortunately this is a manual process. Now to serve this wsdl requires setting the ExternalMetadataLocation property on the ServiceMetadataBehavior either in a service host or in config.

How do I get a DateTime from a UNIX timestamp?

2007-05-14T01:49:00Z

Often when consuming data from a web site, it will represent time with a UNIX timestamp. This is the number of seconds since January 1, 1970. It would be nice to turn this into a System.DateTime, but how?

DateTime FromUnixTime(Int64 unixTime)

{

DateTime time = new DateTime(unixTime * 10000000);

time = time.AddYears(1969);

return time;

}

The DateTime constructor takes the number of 100 nanosecond ticks since January 1, 0001, so multiplying by 10000000 translates seconds into 100 nanosecond intervals. But the Unix era begins in 1970 and DateTime in 1, so to translate that we add 1969 years.

Coming soon...

2007-05-14T01:14:00Z

I have done much posting in more or less forever, but I have some new stuff on deck. In the meantime, check out the recent posts at Steve Maine's blog for some of the stuff I've been working on.

WCF Interop Community

2007-02-19T23:45:00Z

There's no original content in this post, but here's what people are saying about WCF and ASMX interoperability in the Microsoft forums and other blogs over the last month or so:

ASMX

WCF method returning a strongly typed collection to a .NET 2.0 client

Trouble getting a WCF return a collection to a .NET 2.0 client

Issues with generating .net 2.0 client for consuming a WCF service

WCF method returning a strongly typed collection to a .NET 2.0 client

Making an asynchronous call from a .Net 2.0 client(asmx) to a WCF method

Java

netTcpBinding and Java Web Services

WCF and Java WS client

WCF bug in message deserialization?

Interop problem: WCF service & Java client

.NET/Java double-dimensional (jagged) array interop

Custom Binding requires a Timestamp

Accessing : <?xml version="1.0" encoding="UTF-8"?>

Other

Why your NetCF apps fail to call some web services

Security

How to Create a SAML token parsing the SOAP / RSTR Response

WS Security interoperability between Java and .NET web services(Urgent)

Sun

Interop Briefs: Begin at the Beginning...

New WSIT Plug-in coming

Sun understands WS-* very well!!!

SOA and WCF

Can Sun do WS-*?

Web Clients

Connecting to WCF from Javascript\XMLHTTP

calling a webservice from classic asp - what are the limitations?

SOAP Services and XML

.Net Framework 3.0 is live

2006-11-08T01:56:00Z

WCF and the other goodies are available for download here:

http://www.microsoft.com/downloads/details.aspx?FamilyId=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en

WCF and eBay

2006-10-12T19:20:00Z

eBay provides a very rich, though very complicated, SOAP API. It is possible to use WCF with eBay, but it takes a few tricks. First read this article. I'll wait. Ok, since that didn't scare you away I'll continue. Everything there is still necessary except the custom message encoder for removing the quotes around the content type. In fact the basicHttpBinding produced by svcutil.exe is just fine, though bumping up some of the quotas (maxNameTableCharCount, maxBufferSize, maxReceivedMessageSize) might not hurt. Now calling GeteBayOfficialTime just works, but graduating to say GetItem, there's another problem. GetItem returns a GetItemResponseType which derives from AbstractResponseType. After successfully calling GetItemResponseType, all the fields it inherits are correctly populated but the fields it defines haven't been. Looking at the response on the wire, those fields are there, for some reason they weren't deserialized. The problem is eBay defined the schema for AbstractResponseType with an xs:any, so the code generated for this type includes an array of XmlElements with the XmlAny attribute:

[System.Xml.Serialization.XmlAnyAttribute(Order=12)]

public System.Xml.XmlElement[] Any

When the response from eBay arrives the XmlSerializer happily begins populating all the fields in AbstractResponseType and anything it doesn't recognize gets put into Any. Now when it's time to populate the fields defined in GetItemResponseType there's no xml left. Given this knowledge it's an easy fix, but unfortunately it involves manually editing the generated proxy. All that's necessary is to change the XmlAnyAttribute to an XmlIgnoreAttribute. Now upon receiving the response, the XmlSerializer "saves" any elements that don't map to AbstractResponseType and uses them to populate GetItemResponseType.

Useful "knobs" for WCF <-> WSE interop

2006-05-19T21:45:00Z

Let's take the scenario of a WCF client and a WSE service using MTOM either with or without security, here's some of the settings that help make this possible. I'm going to focus mostly on code, but almost all or all of these are available via config.

First off, the proxy created for WCF will be missing pretty much all of the necessary configuration that would be present if this was a WCF service. This is because WSE doesn't support WS-Policy so the wsdl it generates doesn't say it uses MTOM and a specific security policy like a WCF wsdl. WCF will generate 2 bindings for a WSE service, a BasicHttpBinding for SOAP 1.1 and a custom binding for SOAP 1.2.

Without security, it's easiest to just modify the generated bindings. For SOAP 1.1 just changed messageEncoding from "Text" to "Mtom". For SOAP 1.2 replace the textMessageEncoding element with an mtomMessageEncoding element.

In code, SOAP 1.1 is just as easy:

binding.MessageEncoding = WSMessageEncoding.Mtom;

For SOAP 1.2, it's still conceptually simple but more code is required. The easiest approach is to search through the Elements collection on the binding for an element of type TextMessageEncodingBindingElement, and then replace it in the collection with an MtomMessageEncodingBindingElement.

Turning security on adds a couple more twists. The first one is WSE only supports WS-Addressing headers in the 8/2004 namespace but the default for WCF is 8/2005. Next to do signing only, for example, the setting for this isn't on the binding it's on the contract description of the proxy's endpoint, so the code would look like this:

proxy.Endpoint.Contract.ProtectionLevel = System.Net.Security.ProtectionLevel.Sign;

For the security case it's probably best to just start from scratch. Here's some code:

Binding GetNewBindingForSecurity(MessageVersion messageVersion)
{

// Create and configure security for binding

MessageSecurityVersion securityVersion =

MessageSecurityVersion.WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10;
SecurityBindingElement securityBE =

  SecurityBindingElement.CreateMutualCertificateBindingElement(securityVersion, true);
   securityBE.DefaultAlgorithmSuite = SecurityAlgorithmSuite.Default;
   securityBE.IncludeTimestamp = true;
   securityBE.MessageSecurityVersion = securityVersion;
   securityBE.SetKeyDerivation(false);
   securityBE.SecurityHeaderLayout = SecurityHeaderLayout.Lax;

AsymmetricSecurityBindingElement asymmetricSecurityBE =

            securityBE as AsymmetricSecurityBindingElement;
   if (asymmetricSecurityBE != null)
   {
      asymmetricSecurityBE.MessageProtectionOrder =

MessageProtectionOrder.SignBeforeEncrypt;
}

// Create and configure encoding element

   MtomMessageEncodingBindingElement encodingBE = new MtomMessageEncodingBindingElement();
   //messageVersion is either MessageVersion.Soap11WSAddressingAugust2004 or MessageVersion.Soap12WSAddressingAugust2004 to interop with WSE
   encodingBE.MessageVersion = messageVersion;

// Create and configure transport element

   HttpTransportBindingElement transportBE = new HttpTransportBindingElement();
   transportBE.MaxReceivedMessageSize = Int32.MaxValue;
   return new CustomBinding(securityBE, textBE, transportBE);
}

Three things are happening here. Security is configured (MutualCertificate in this case but it could be any of the WSE turnkey security assertions) with the proper settings. Mtom is configured with the proper message version, note the two values that will interop correctly. Finally a transport is selected. This could also be https, but then why are you using message level security, or possibly TCP.

WSE Quick Links

2006-02-23T00:06:00Z

If you haven't seen it, Pablo Cibraro has a lot of informative posts about WSE (and WCF). These include implementations of WS-Federation and WS-Polling among a great number of others, just keep scrolling.
Julie Lerman points out the number #1 cause of performance degradation with WSE: tracing has been on for a while and the trace files have gotten huge. This is always the first thing to check when WSE's performance has become sluggish. Be careful with Tip #2 though, particularly on the server side. ASP.NET explicitly forbids serving the default extensions for trace (.webinfo) and policy (.config) files, changing the extensions to .xml could lead to accidental information disclosure.

WinFX February CTP available

2006-02-22T20:43:00Z

The February CTP for WinFX is now available for download. Breaking changes are here.

Quick Links

2006-02-02T01:51:00Z

Aaron Skonnard has a new Service Station column all about the new web services features in .NET 2.0 (ASMX 2.0 and WSE 3.0) and how they fit with the impending release of WCF.
Kirk Evans has a great post about using WSE 3.0's policy framework to get WSE 1.0 to talk to WSE 3.0.
Another WCF Interop Plugfest is coming up March 7-9.

So you want to move a lot of data

2006-01-24T21:02:00Z

Yasser Shohoud has a great post up about moving large amounts of data with WCF. The solutions are WCF-specific but the discussion of the problems (bandwidth utilization, memory utilization, and error recovery) is general to any system using web services to transfer big chunks of data.