Recently someone asked me what is the best way of sending a file to a webservice, given that we know that MTOM is the way forward and Soap with Attachments (SwA) and WS-Attachments/DIME are now deprecated.  I agree with many others that using base64 encoding to send the attachment within the SOAP message is the best approach (until we get MTOM).

Background
For those who haven’t followed the attachment saga (Omri has a good overview or the whole sorry story), the basic problems with the previous ways of sending attachments was that they were slow to process and more importantly, placed the attachments outside of the envelope, making it hard to compose attachments with the SOAP processing model and WS-Security specifications.  MTOM solves this by defining the rules that allow the content to be sent outside the message as binary (rather than base64) data, but using ‘includes’ to allow that content to be treated as part of the SOAP envelope XML Infoset.

(As an aside, does anyone else find it funny that even though SOAP was based on the analogy of an envelope, the original spec didn’t define where to put the address (hence WS-Addressing) and the three initial attempts at attachments didn’t think to put the attachments inside the envelope?  But, I digress.)

MTOM to the rescue (soon)
The future looks bright since WSE 3.0 and Indigo will support MTOM but what’s the best approach today? 

One way is to use WSE 2.0’s support for WS-Attachments/DIME, another is to look at SwA (though as Matt Powell points out, SwA was only ever a W3C Note and even that has expired). Since Microsoft doesn’t have any product support for SwA you would have to write your own, or contact a group who have already developed a .NET SwA solution.

Base64 encoding: a good solution for today
Another approach that will work today is to stick with base64 encoded text rather than using SwA or DIME.  There are several benefits to using this approach.  Martin Gudgin says the schema definition for ‘[an] element definition will work with both XML 1.0 based SOAP services and those that support MTOM as a serialization format.’  Simon Fell agrees that base64 encoding will make it easier to change in future.  Matt Powell summarises it well in his great MSDN Article on Web Services, Opaque Data and the Attachments problem when he says:

Base 64 encoding is probably the best way to pass opaque data if transport size efficiency is not your first concern. It will work seamlessly with higher-level WS-* protocols and is smaller than a standard XML encoding.

So the only disadvantage is that the content is base64 encoded which means that it is larger (by about 4/3).  Though, as Marc Hadley mentions, you’d have to Base64 encode an attachment even with MTOM if you wanted to sign it.

Simple implementation
Another benefit is that base64 encoding is simple to implement.  Here’s an example ASMX endpoint that accepts one way messages containing a file.  As you can see the file is defined as a Byte array:

[WebMethod]
[SoapDocumentMethod(OneWay=true)]
public void SaveFile(Byte[] file)
{
   // Write the Byte array out using a FileStream
}

The message then looks like this on the wire.  As can be seen the content is all inside the envelope, making it easy to use WSE and WS-Security to sign and encrypt the attachment if required.

<xml version="1.0" encoding="utf-8" ?> 
   <soap:Envelope
      xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:xsd="http://www.w3.org/2001/XMLSchema">
     <soap:Body>
         <SaveFile xmlns="urn:benjaminm.net:sendbinary">
            <file>R0l…slyvLIbabN mzMbAtjJsyfPgAA7file> 
         </SaveFile>
      </soap:Body>
</soap:Envelope>

Stu Charlton writes about ‘Microsoft, Service and Patents’ concluding that:

Even if Indigo is the all singing, all dancing thing that Microsoft hopes it will be, it doesn't mean people will adopt it en masse and quickly. Firstly, it's a Windows-only technology. That's a big limit to start with. Second, it's very new and rich. There's a learning curve. Third, other vendors are not sitting still. They can and will compete.

His first point, that Indigo may not be adopted because it’s a Windows-only technology, misses the difference between a programming model and the messages that it creates/consumes.  Indigo is a programming model that can send messages, which are based on the WS-* specifications, to any other endpoint that can understand these messages.  Yes, you have to use Windows to program with the Indigo programming model, but given that many other vendors were involved in creating these specifications and participating in feedback and interop workshops (more info here), it is likely that many Indigo applications will be built to interoperate with applications hosted in non-Windows environments.

His second point is that Indigo is a new programming model.  This is true, but viewed another way it is just the combined next version of the existing distributed technology stacks at Microsoft (DCOM, Enterprise Services, MSMQ, Remoting, ASP.NET Web Services, WSE).  Many of the Indigo team were involved in building these existing products.  So it is new, but it is based on a strong foundation of experience developing other distributed technology stacks.  As Steve Swartz comments:

it's important to think about Indigo not as a big change or something new and completely different, but rather as a replacement of infrastructure which you only have to look at if you're the kind of person who likes it, but an evolution of the programming model, a simplification and a unification. [Emphasis mine]

In terms of the learning curve, there’s no doubt that any programming model designed to support distributed computing will be complex. Having said that though, it's interesting to note how much time the Indigo team have devoted to refining the usability of the API to ensure the minimal learning curve for developers.  If you compare what was announced at the PDC with what was shown on the Indigo .NET Show for instance you can see that they've been trying to simplify and refine the model and reduce the number of concepts a developer needs to know in order to be productive.  In fact one of the reasons I’m so excited about Indigo is this focus on designing the programming model with developer usability as a goal.  As Steve Swartz, the Program Manager responsible for the Indigo programming model, describes his role: 

My job is to figure out how to make the whole thing approachable without having to know anything about the [WS-*] specs  … One of my design goals is to make a programmer familiar with any one of those products [DCOM, Enterprise Services, MSMQ, Remoting, ASMX, WSE] look at Indigo and say ah, that's the next step in my product, mine was the winner. So I'd like a .NET remoting guy to be able to walk up here and say ah, this looks very familiar. Similarly with the Enterprise Services and ASP.NET people … What we're trying to do is to bring all those useful things together in one model.

Finally, in terms of the other vendors not standing still and competing - this is excellent.  I would love to see other vendors try and offer a more usable and flexible API to develop WS-* compliant applications – this can only be a good thing for distributed application developers.

As David Gristwood and Mike Shaw note, on October 4 in London there’s a free Microsoft Technical Briefing Day with sessions on IT security with Steve Ballmer presenting a keynote at the end of the day.  Rafal Lukawiecki, a security guru and one of the top-rated speakers from TechEd Amsterdam, will be presenting on Threat Modelling as well as XP SP 2.  There’s also a session that I’m particularly interested in on practical lessons learnt with WSE 2.0 on the UK Government Gateway project:

In February this year, a new release of the Government Gateway went live using WSE2.0 to deliver WS-Security, WS-Trust and WS-Policy for UK cross-government authentication and authorisation. With over 4 million users, the Gateway's authentication and messaging facilities provide the backbone of the e-government agenda - and also one of the biggest WS-* implementations to date, coded in just 8 weeks. Find out the good, bad (and ugly) of using WS-Security - hot tips on what makes for good design, and what pitfalls to avoid.

You can register for the event here.

I’ve been head-down coding for several weeks (not quite to the ‘having other people feed me’ stage, but close).  I’m currently working on a VB.NET 2003 API for a large product and am missing refactoring tools.  To make up for it, I’ve been improving my regular expression skills and using Visual Studio's Search and Replace dialogue.  The VSEditor blog has a lot of good content on this feature (including a three part series).  The search and replace dialogues (both regular and the ‘in files’ versions) have a nice drop-down that displays the regular expression characters along with a description of what they do.

It’s a poor replacement for decent automated refactoring tools but it has made my life considerably easier over the last few weeks.