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.

Gregor Hohpe weighs in on the WS-AlphabetSoup debate with a new ‘ramble’ that provides some guidance on how to approach the WS-* standards.  He recommends focusing on the intention behind the standards (benefiting from the knowledge and experience of the specification authors) and using them as a checklist for designs. 

… Instead of focusing on [the details of the standard], look at what problem the standard is trying to solve. More likely than not, it is a problem that you are going to have when you go to implement your architectural vision. For example, not knowing where SOAP messages come from and where they are going makes debugging and diagnostics very hard. Not being able to reliably send asynchronous messaging is likely to result in a brittle and not very scaleable "RPC-over-the-network" model.  … I propose to many of my clients to use the WS-* standards as a checklist for their designs. I generally do not recommend they use WS-Addressing or WS-ReliableMessaging (or at least not right out of the gate). I do, however, challenge them by asking, "What is your strategy to track messages in case of error?" or "How do you intend to support asynchronous messaging?" The answer has sometimes little to do with Web Services. For example, the answer to reliable asynchronous messaging might be to use JMS or MQ or another middleware [e.g MSMQ] that ensures guaranteed delivery of asynchronous messages. And that's OK.

I like Gregor’s last point that sometimes the best current solution may not be web services.  This highlights that concept services, or applications based on principles of service orientation, do not have to use web services.  It’s important not to let the WS-* hype and churn delay the creation and deployment of service-oriented systems today. 

Microsoft announced on Friday that Indigo is all set to ship in 2006, with the planned support for Windows XP and Windows Server 2003.  This is great news.  With Whidbey shipping next year, with improved ASMX support (see Christian’s series), and WSE 3.0 some time between now and Longhorn it looks like there’ll be plenty of reasons to keep targeting Windows as the platform of choice for developing service-oriented applications.

Christian Weyer shows how to host WSE’s SoapReceiver within EnterpriseServices.  This came up while we were watching Keith Ballinger do a code-driven presentation on WSE messaging.

The demo was illustrating using SoapReceiver within a Windows Form application, which highlights that SOAP messages can be received inside any .NET assembly.  While this demo makes the point (and suggests some interesting application designs, such as having a user interface app host a service and listen for messages, as John Cavnar-Johnson mentions in the comments), this may not be an appropriate hosting situation, esepcially if you want it to run the application on a server, without user intervention.  Don Box has a great series on the major hosting options within .NET (IIS, DCOM/ES and Windows Services) and the advantages and disadvantages of each.  Christian’s question was ‘Can I host SoapReceiver within a ServicedComponent?’ 

Here’s my version of a solution to this problem, with all the steps you need to get to the spinning balls.  The server code looks like this:

using System;
using System.EnterpriseServices;
using System.IO;
using System.Net;
using System.Reflection;
using Microsoft.Web.Services2.Addressing;
using Microsoft.Web.Services2.Messaging;
[assembly : AssemblyKeyFile("keys.snk")]
[assembly : ApplicationName("WSE Hosting Example")]
[assembly : ApplicationActivation(ActivationOption.Server)]
[assembly : ApplicationAccessControl(false)]

public class WSESoapService : ServicedComponent, IProcessInitializer
{
      #region IProcessInitializer Members

      public void Shutdown()
      {
            Logger.LogMessage("Shutdown");
      }

      public void Startup(object punkProcessControl)
      {
            Uri uri = new Uri("soap.tcp://" + Dns.GetHostName() + ":4545/");
            EndpointReference epr = new EndpointReference(uri);
            // Add our WSE SoapService to the static collection of receivers,
            // giving the address we want to listen on and the CLR type that
            // will receive this message.
            SoapReceivers.Add(epr, typeof (MyService));
            Logger.LogMessage("Startup");
      }

      #endregion
}

// Here's our service that will receive messages
public class MyService : SoapService
{
      [SoapMethod("ReceiveMessage")]
      public void ReceiveMessage(string message)
      {
            Logger.LogMessage(message);
      }
}

internal class Logger
{
      internal static void LogMessage(string message)
      {
            // Log the messages to a file.
            StreamWriter writer = new StreamWriter(@"c:\wsemessages.txt", true);
            writer.WriteLine(message + "," + DateTime.Now);
            writer.Flush();
            writer.Close();
      }
}

To compile this code, save it in a file called WSESoapService.cs, then use the following command lines (assuming that you’ve got the Microsoft.Web.Services2.dll in the compilation directory since csc.exe wont look in the GAC for assemblies):

sn –k keys.snk
csc /target:library WSESoapService.cs /r:Microsoft.Web.services2.dll
regsvcs WSESoapService.dll

Then go to the computer manager and start the WSE Hosting Example COM+ application.

The client code looks like this:

using System;
using System.Net;
using Microsoft.Web.Services2.Addressing;
using Microsoft.Web.Services2.Messaging;

public class App
{
      public static void Main(string[] args)
      {
            Uri uri = new Uri("soap.tcp://" + Dns.GetHostName() + ":4545/");
            EndpointReference epr = new EndpointReference(uri);
            MySoapClient proxy = new MySoapClient(epr);
            proxy.SendMessage("Here's a message");
            Console.Write("Message Sent!  Press any key to continue ...");
            Console.Read();
      }
}

// Proxy class to call the SoapReceiver Service
internal class MySoapClient : SoapClient
{
      public MySoapClient(EndpointReference epr) : base(epr){}

      public void SendMessage(string message)
      {
            base.SendOneWay("ReceiveMessage", message);
      }
}

Then save this file as client.cs and compile it from the command-line as follows:

csc /target:exe client.cs /r:microsoft.web.services2.dll