Introduction

In many distributed applications there is a requirement for messaging. The data transfer could involve simple form posts or it could involve complex binary data exchange. In this article I’ll look at a method to pass binary and textual data over a network using SOAP, a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment, and the Message Transmission Optimization Mechanism (MTOM). The process also involves Web Services Enhancements (WSE 3.0), a tool provided by Microsoft which supports MTOM. The beauty of SOAP lies in its ability to encapsulate XML data within a SOAP message. This gives SOAP the flexibility to contain data from any XML schema, which is a powerful capability. Since it is XML based, SOAP is not very flexible in holding binary data, we need to rely on some other mechanism to hold the binary data. The MTOM specification which leverages XML-binary Optimized Packaging (XOP) can be used to transfer data, which can include binary data. MTOM defines how XOP is layered into the SOAP HTTP transport.

I will also discuss the way MTOM is structured and explain some strategies that will allow you to efficiently transfer data using some simple settings with WSE. I will concentrate on building a sample application to demonstrate the capabilities of MTOM and how it fits with web services and how it can work closely with SOAP and WSE. In the follow-up article, a client application is created to send binary and textual data to the web service that was created in the first part. The application also demonstrates the exchange of secure data between a client and server.

After reading this article you should:

• Understand the basics of MTOM


• Be able to use WSE 3.0 to transfer data


• Understand how SOAP messages work with MTOM


• Create a Web Service which can consume MTOM data

System Requirements

To run the sample application for this article you should have the following:

• IIS 5.0 or later running on Windows 2000 or later


• The .NET Framework version 2.0


• Visual Studio .2005


• MSDE 200X /SQL Server 200X


• Web Service Enhancements 3.0

You can download WSE 3.0 at http://msdn.microsoft.com/webservices/webservices/building/wse/default.aspx. For details on how to setup WSE 3.0 and its different capabilities please refer to the online help manuals.

Also it is assumed that the reader is comfortable with the basics of web services and messaging based on SOAP. Don t worry about the details on how these things are implemented – I’ll go a little deeper when it is required during the course of this article.

Installing and Compiling the Sample Code

Included with this article is a download that contains a set of SQL scripts, VB code and web service code. To set it up, simply unzip the files onto your local drive. The Readme.txt has step by step details on how to setup the sample application. The application is extremely easy to follow once you’ve loaded everything from the download.

Data Transfer Problems

Let’s consider the options for transferring textual and binary data from a client application to a remote server. These days, for any messaging routines, XML is the de facto standard at least in the non-legacy world. Since XML has a textual nature, it is easy to work with and portable. Now we need to look at the possibilities of sending binary data along with the SOAP XML request or response payload. When we add binary data, the situation becomes more complex. But over the years the W3C has suggested many proposals for dealing with this real problem.

The current solutions include encoding the binary data using a proper encoding mechanism like base64 or hex. However, encoding and decoding results causes performance issues, and in addition, encoding to base64 or hex increases the payload size of the binary data contained in the XML message. Furthermore, the problem with encoding is that it requires decoding at the other end, thus making the process slow on both ends, and for huge binary data, it is also inefficient for XML parsers to resolve embedded coded stream and extract the attachment while parsing the SOAP message. The other solution is to use Multipurpose Internet Mail Extensions (MIME), which allows binary data to be sent and received. SOAP with Attachments is also a possibility that defines how SOAP messages can be carried within a MIME "multipart/related" message, as a compound SOAP document. The first MIME part is the SOAP envelope, subsequent parts contain attachments. SOAP with Attachments addressed the problem of reducing payload overhead, but because of some arcane requirements of MIME, did not provide a formal way to associate attachments with the SOAP message. Then came Direct Internet Message Encapsulation (DIME), a specification submitted by Microsoft and IBM to IETF and it defined a lightweight, binary message format that can be used to encapsulate one or more application-defined payloads of arbitrary type and size into a single message construct. But the specification failed to apply WS-Security and as a result Microsoft has removed the specification from recommended status.

How MTOM Fits In

Enter the W3C recommendation Message Transmission Optimization Mechanism (MTOM) as the solution. MTOM is a W3C recommendation that replaces DIME and SOAP with attachments as the mechanism for sending large amounts of data such as document files and images. You can use the MTOM specification, which uses XOP, to attach binary files and transfer them efficiently over the wire. The MTOM encoding transmits most XML in textual form, but optimizes large blocks of binary data by transmitting them as-is, without conversion to text.

The W3C suggests the optimization procedure in 3 steps:

1. The first step describes an abstract feature for optimizing the transmission and/or wire format of SOAP by selectively encoding portions of the message, while still presenting an XML Infoset (see http://www.w3.org/TR/xml-infoset/ for an explanation of XML Infosets) to the SOAP application.


2. The second step describes an optimized MIME multipart/related serialization of SOAP messages implementing the abstract SOAP transmission optimization feature in a binding independent way. This implementation relies on the XOP format.


3. The third step (HTTP SOAP transmission optimization feature) uses optimized MIME multipart/related serialization of SOAP messages for describing an implementation of the abstract transmission optimization feature for the SOAP 1.2 HTTP binding.

Abstract SOAP Transmission Optimization

The moment there is binary data involved in the XML, it needs to be base64 encoded to maintain the "XML ness". But abstract SOAP transmission optimization preserves the "XML ness" and it makes it possible to combine both binary and textual data. The abstract SOAP transmission optimization feature helps in the optimization of the SOAP message, while still presenting an XML infoset to the SOAP application. Optimization is available only for element content that is in a canonical lexical representation of xs:base64Binary data

MTOM implementations typically optimize by transmitting a compact representation of the value in place of the less compact character sequence. At the receiver, the character form can be reconstructed if necessary. When sending a SOAP message the abstract transmission optimization feature is used in combination with the SOAP request-response message exchange pattern or the SOAP response message exchange pattern. When receiving the optimized SOAP message, the receiving node must reconstruct an envelope infoset from the optimized SOAP message.

Optimized Serialization/Deserialization of SOAP Messages

XOP allows the serialization of an XML infoset containing base64-encoded data as a package. The package is still in an XML form, with the root of the package containing the XML document itself, while selected portions of the package content are base64-encoded binary data extracted and re-encoded (i.e., the data is decoded from base64) and placed into the package. The locations of those selected portions are marked in the XML with a special element that links to the packaged data using URIs. To be precise, XOP defines how to use MIME multipart/related as the underlying packaging system for an XOP package. Here the base64-encoded binary content has been serialized into separate MIME parts. The serialization and deserialization happens in few steps as shown in the Figure 1.

Figure 1. The steps in sending an MTOM Message

First the original XML infoset is taken and the base64 encoded binary content is processed. This is marked in Figure 1 by the number 1, circled. Selected portions of its content that have base64-encoded binary data are extracted and re-encoded (i.e., the data is decoded from base64) and placed into the package. This optimized content is removed from the infoset as depicted in step 2 of the Figure 1. This forms the XOP infoset. The locations of these selected portions are marked in the XML with a special element that links to the packaged data using URIs. Here the optimized content in the original infoset will be replaced by the xop:Include element. Then the XOP infoset with the optimized contents will be serialized as shown by step 3 of the Figure 1. Here the binary contents has been serialized in separate MIME parts and will not be part of the XOP infoset .This forms the XOP package containing the XOP document which in turn comprises the serialized XOP infoset and any optimized content. The XOP package acts as the alternate serialization of the original infoset. The receiving application can reconstruct the XML infoset from the XOP package by deserializing the contents for further manipulations as shown by step 4 in Figure 1.

It is important to note that normally in most applications, binary data need never be encoded in base64 form. If the data is available as binary then the application can directly copy that data into an XOP package, at the same time preparing suitable linking elements for use in the root part; when parsing a XOP package, the binary data can be made available directly to applications, or, if appropriate, the base64 binary character representation can be computed from the binary data.

If you look at the structure of MTOM, you’ll see it combines the composability of base 64 encoding with the transport efficiency of SOAP with attachments. Since the data lives within the SOAP envelope, all the WS-* specifications that Microsoft has developed with its partners will work seamlessly with MTOM. Transport efficiency with MTOM is increased with the fact that opaque data can be sent in its raw form without base 64 encoding. The opaque data is inherently dealt with and is simply streamed as binary data as one of the MIME message parts

The HTTP SOAP Transmission Optimization

MTOM defines a SOAP feature, i.e. an abstract piece of functionality extending the SOAP messaging framework that may be implemented to take advantage of the XOP optimizations for SOAP messages. The HTTP SOAP transmission optimization feature defines and enhances the SOAP 1.2 HTTP binding defined in SOAP 1.2 Adjuncts by carrying the SOAP message on the wire as a XOP package.

Now I am going to take an example and show you how the optimization is achieved using the MTOM specifications. Let’s assume following SOAP envelope snippet is an original XML infoset that needs to optimized:

<soap:Envelope
    xmlns:soap=‘http://www.w3.org/2003/05/soap-envelope’ 
    xmlns:xmlmime=‘http://www.w3.org/2004/11/xmlmime’>
  <soap:Body>
    <m:data xmlns:m=‘http://someexample.org’>
      <m:photo>/RTRfkgnflkgnf=fndslkfnkldsnfkldsnf43d5fwfsgs4ojojsfiodjs=


      </m:photo>
      <m:doc>GTERkdmdfmdkf=jkszndnsjdnsjkdnskjndkjsndkjsndks

      </m:doc>
    </m:data>
  </soap:Body>
</soap:Envelope>

Here if you look at the elements in the document you can identify that there are two binary structures to work on. One is represented by the photo element and the other is the doc element. When you send this message with MTOM, the root of the XOP package will be the SOAP envelope with the photo and the document attached in the other parts of the MIME package, appropriately based on the XOP optimization procedure. So the message looks like the following (I ve replaced some of the content by // comments to make it clearer):

MIME-Version: 1.0

Content-Type: Multipart/Related;boundary=MIME_boundary;
    type="application/xop+xml";
    start="<mymessage.xml@ someexample.org>";
    startinfo="application/soap+xml; action="ProcessData""

Content-Description: A SOAP message with a photo and document in it

—MIME_boundary

Content-Type: application/xop+xml; 
    charset=UTF-8; 
    type="application/soap+xml; action="ProcessData""

Content-Transfer-Encoding: 8bit

Content-ID: <mymessage.xml@someexample.org>

<soap:Envelope
    xmlns:soap=‘http://www.w3.org/2003/05/soap-envelope’
    xmlns:xmlmime=‘http://www.w3.org/2004/11/xmlmime’>
  <soap:Body>
    <m:data xmlns:m=‘http:// someexample.org/stuff’>
      <m:photo><xop:Include 
    xmlns:xop=‘http://www.w3.org/2004/08/xop/include’ 
    href=‘cid:http:// someexample.org/photo.jpeg’/></m:photo>
      <m:doc><xop:Include 
    xmlns:xop=‘http://www.w3.org/2004/08/xop/include’ 
    href=‘cid:http:// someexample.org/my.worddoc/></m:doc>
    </m:data>
  </soap:Body>

</soap:Envelope>

—MIME_boundary

Content-Type: image/jpeg

Content-Transfer-Encoding: binary

Content-ID: <http:// someexample.org/photo.jpg>

// binary octets for JPEG image

—MIME_boundary

Content-Type: application/msword

Content-Transfer-Encoding: binary

Content-ID: <http://someexample.org/my.worddoc>

// binary octets for document

—MIME_boundary—

The binary data is referenced inside the message using the xop:Include element. Here it contains a href attribute which is a representation of a URI referencing the part of the package containing the data logically included by the xop:Include element. The href value must be a valid URI per the Content-ID: URI scheme. In the message fragment shown above for the xop:Include element, consider this bit of code:

<xop:Include 
    xmlns:xop=‘http://www.w3.org/2004/08/xop/include’ 
    href=’cid:http:// someexample.org/my.worddoc/></m:doc>

	

This will have a corresponding MIME part with a Content-ID header field with a field value as shown below.

Content-ID: <http://someexample.org/my.worddoc>

// binary octets for document

This explains the simple way the binary octet data is referenced in the message stream. MTOM thus enables the referencing of binary data as it is without the requirement to do any encoding. Note also that the sample base64 data is smaller than would be typical and the binary octets are not shown; in practice, the optimized form is likely to be much smaller than the original.

In the subsequent sections of this article, you will see how you can generate an MTOM encoded message and pass it across to a web service. It is sometimes necessary for a client application to send a large file of text or binary data, such as an image file, in a SOAP message. A typical example would be a web service application consuming data fed in by insurance agents using their laptops which includes a lot of information about their clients. The data could include large binary information in the form of images. The MTOM specification solves this problem by defining a mechanism which selectively optimizes the data within the SOAP envelope, eliminating the need to encode the contents into XML.

Comparing MTOM and DIME

Let s spend some time discussing what MTOM has to offer which DIME fails to do. I am discussing this because of the fact that prior to the arrival of MTOM, Microsoft had recommended DIME. DIME is a lightweight binary message format for sending and receiving messages, and is ultimately just a specification for including multiple binary records within a single package. It has the ability to contain any kind of data, including image files, SOAP messages, or even MIME messages. To learn more on DIME and how it is used with WSE, please check out my ASP Today article Uploading Binary and Textual data using SOAP and DIME.

So why was MTOM created when at first sight it looks like there was already a solution for the problem? In fact there are a number of reasons for arguing that MTOM has some benefits – as explained in the following table:

DIME	MTOM
The message security can only be enforced at the transport level. Unless you use HTTPS, DIME is not secure and one cannot use message level security to protect the message.	Security can be enforced via WS-Security which turns out to be the standard for Web Services Security
Wire size based on the record length used. Still can be optimized using chunking	Reduced wire size. It uses an encoding algorithm that does not suffer from this size expansion and so the wire size is smaller
DIME does not impose an infoset data model over the message + attachments	MTOM preserves the original infoset and uses MIME as the interoperable framing mechanism.
Should use separate attachment collection to send multiple data fragments	Separate attachment collection is not required
DIME and WS-Attachments limits the ability of the higher-level Web service specifications to properly work upon a message.	The end result of an MTOM transfer is a SOAP envelope, so all higher-level Web service protocols work as designed.
DIME specification is not supported by W3C any more.	MTOM specification is supported and promoted by W3C.

The DIME approach to sending SOAP messages with attachments is technically a feasible solution. DIME can in some cases be more efficient when sending attachments as it employs record lengths for attachments (which enables chunking of records), and allows the content to be dumped as raw binary. However, supporting multiple specifications for achieving the same results is costly and potentially confusing. Due to its interoperability superiority, Microsoft is promoting MTOM for binary attachments and future SOAP tools and platforms which include Windows Communication Foundation (WCF).

The Sample Application

The sample application that you are going to see is a simple File Upload utility. The user can upload multiple files along with the filename to a web server using MTOM and SOAP. The application is comprised of a VB.NET client which consumes a web service. The web service is built with methods which help in the transfer of binary files between these applications and stores the information in an SQL Server database. In a real scenario, this setup could be extended to have data transfer between different applications.

Application Structure

Let s examine the structure of the sample application under consideration. You will see how this setup can:

• Create a web service application to receive data


• Create a custom UI to consume the web service


• Use MTOM to encode the data and transfer to the web service


• Insert the data into SQL Server 2000 on the server side

I will also explain this setup with an extension section which shows the transfer of data securely over the wire. The data received in the SQL Server database could be consumed by other applications, but these details are out of scope of this article. A pictorial representation of what the sample application will look like can be seen in Figure 2.

Figure 2. Sample application architecture

Data Persistence

Once data is extracted I use SQL Server 200X to persist the data on the server side. For this I have used a single table. The table can be created as part of any sample database that is shipped with SQL Server 200X. In this sample I have used the Northwind database to create the necessary table structure. The table has fields to hold the binary information of the file that is uploaded using the sample application. The table structure is simple and self explanatory as shown in Figure 3.

Figure 3. Table structure used to hold binary data

I will make use of this table when I implement the web service in the sections to follow. The complete SQL script is available as part of the code download. Please refer the Readme.txt to find more information on how to run the script.

MTOM Web Service

In this section you’ll see how to create a web service to extract the information from the SOAP message and update the database. If you are creating the project as you go along you should use VS 2005 to create the web service and change the name of the project to MTOM_Service. Also, change the name of the default Service1.asmx to MTOMService.asmx. With the advent of VS 2005 you can create this web service with the location that is HTTP-based or file system-based. I have chosen file system in this particular example. But it will work the same for an HTTP location as well. When you are using file system based access you are leveraging the new ASP.NET development server concept introduced with VS 2005. This will enable you to create and host your web services even without IIS installed on your machine.

Before discussing any more about how the web service is implemented, I need to step back a little to explain how the capabilities of MTOM are exposed to a .NET programmer. MTOM will not be available unless you install WSE (Web Service Enhancements) 3.0. You might be wondering what this WSE is.

Web Services Enhancements for Microsoft .NET (WSE 3.0) is a supported add-on to VS 2005 and the.NET Framework 2.0, which provides developers the latest advanced web services capabilities to keep pace with the evolving web services protocol specifications. WSE 3.0 is aligned with the same set of security specifications as WCF and hence is wire level compatible. This means that if you build and deploy secure web services with WSE 3.0, WCF clients can communicate with them. Equally WSE 3.0 clients can communicate with WCF Services. With WSE 3.0, you can secure your messages using digital signatures and encryption, send attachments, route messages through intermediaries, and more – so it helps you in sending attachments with SOAP messages. WSE 3.0 is downloadable from the Microsoft site and a link is provided with the related links for this article.

Let me walk you through the steps that you need to follow to configure WSE so that you could use MTOM messages. Even with WSE installed on your machine, there are a few additional MTOM-specific configurations that need to be made to an ASP.NET application in order to use MTOM-encoded data. After creating the web service project in Visual Studio, a reference to the Microsoft.Web.Services3.dll assembly needs to be added to the project. Now you can use the WSE Setting 3.0 menu item under the VS solution explorer to configure the SOAP extensions so that it will work for MTOM encoded data. The property dialog can be seen in Figure 4.

Figure 4. Settings for WSE 3.0

Please check both the checkboxes so that the system works the way it needs to work. Basically this operation will create an entry for the SOAP extensions in the Web.Config file:

<configuration>
    <system.web>
      …
    <webServices>
      <soapExtensionImporterTypes>
        <add type="Microsoft.Web.Services3.Description.WseExtensionImporter,
              Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, 
              PublicKeyToken=31bf3856ad364e35" />
      </soapExtensionImporterTypes>
      <soapServerProtocolFactory 
              type="Microsoft.Web.Services3.WseProtocolFactory, 
          Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, 
        PublicKeyToken=31bf3856ad364e35" />
    </webServices>
    </system.web>

</configuration>

The main idea of these extensions is to have the capability of modifying the SOAP messages. The first one helps to generate a WSE-enabled proxy class while the second is the class factory for the WSE protocol objects that are instantiated for every ASMX request. When a client calls a web method from the server, the request is serialized into a SOAP message and sent over the network as a SOAP request. The SOAP request is deserialized on the server side. The server then composes a SOAP message, serializes it, and it sends it over the network as a SOAP response. The SOAP response is deserialized at the client before the SOAP message is received by the client application. Therefore, serialization and deserialization occur both at the client and on the server. You could use the SOAP extension to perform various operations, before and after the serialization phases. In order to have the MTOM support in this application you need to use the WSE setting tool a little more so that the messages will be MTOM coded. So navigate to the Messaging tab in the WSE 3.0 settings and change the setting as shown in Figure 5.

Figure 5. WSE Settings on the Messaging Tab

Here MTOM settings specify whether SOAP messages are encoded using the MTOM or not. The different parameters that can be defined as part of the messaging element are as given below. The same updates will occur to the Web.config or App.config when the changes are applied as shown below.

<mtom 
  clientMode="on|off"
  maxMimeParts="64"
  requireSoapEnvelopeFirst="true|false"
  serverMode="always|never|optional"/>

The values will be generated in the Web.Config or App.config as:

  <microsoft.web.services3>  
    <messaging>
      <mtom clientMode="On" />
      …
    </messaging>


  </microsoft.web.services3>

The possible attribute values applicable for MTOM tags in the Web.Config or App.config files are listed in the table below.

Name	Value	Meaning
client Mode	on | off	This is an optional value that we need to set. It specifies the default for whether web service clients send SOAP messages that are MTOM encoded or not. If on specifies that SOAP messages are MTOM encoded unless client code explicitly sets the RequireMtom property of the proxy class to false. If off specifies that SOAP messages are not MTOM encoded unless client code explicitly sets the RequireMtom property of the proxy class to true.
maxMimeParts	Any number	It is an optional attribute. Specifies the maximum number of mime parts that can be in an incoming MTOM-encoded SOAP message. The default value is 64
requireSoapEnvelopeFirst	true|false	It is an optional attribute. Specifies whether the SOAP envelope must be the first MIME part in an MTOM-encoded SOAP message. Possible values are true and false. The default value is true.
serverMode	always|never|optional	It is an optional attribute. Specifies whether the Web service supports the MTOM specification. Possible values are always, never, and optional. The default value is optional. If message is marked as always then all message transmission should be MTOM coded. If there is a failure then HTTP error 415: "Media unsupported" is returned to the sender. If it marked as never then the message will not be MTOM encoded. When server mode is marked as optional then WSE processes incoming SOAP messages whether or not they are MTOM encoded. All SOAP responses and SOAP faults match the MTOM encoding of the incoming SOAP message.

These settings will be updated in the respective sections in the Web.config or App.config. These settings are very important for the functioning of MTOM based application messaging.

Before you can see how to get MTOM messages working, you need to add a web method so that your client can make use of it. You can rename the default HelloWorld() method under App_Code/Service.vb or you can create a new method. I have chosen to create a new method named UploadFile() to enable the new service to upload binary data to the server. Now I need to define the parameters for this function. It should accept the details of the file(s) that need to be uploaded. In order to facilitate this I have created the structure that follows:

Public Structure FileInfo
    Dim Filename As String
    Dim FileType As String
    Dim FileContents As Byte()

End Structure

The structure is very straightforward and self explanatory. Please note that FileInfo is an independent structure that I ve introduced to store file information; it is not related to the well-known System.IO.FileInfo class. In the structure, Filename is used to store the name of the file. The second element FileType is to define the MIME Type of the file that is getting uploaded. Finally the FileContents is used to embed the actual binary contents of the file. Here it is defined as an array of Bytes. To support multiple such files, I need to define a List of structures as a web method parameter. But before doing that let s see something new in .NET 2.0. One of the biggest changes in .NET 2.0 is the introduction of generics. In .NET 1.x, creating a flexible class or method that would use classes that are not known at compile time must be based on the Object class. With the Object class, there is no type safety during compile time and casting is necessary. Also, using the Object class for value types has a performance impact.

With generics being supported in .NET 2.0, the use of Object is no longer required in such scenarios. It is a great feature, especially with collection classes. Most of the .NET 1.x collection classes are based on the Object type. .NET 2.0 offers new collection classes that are implemented as generics. The main advantage of generics is on performance and type safety. For more information on generics, see the related links section for this article.

I will make use of generics to define the List of FileInfo objects. So the signature of the web method looks like the following:

<WebMethod()> _
    Public Function UploadFile (ByVal Files As List(Of FileInfo), _
                                ByRef ErrorInfo As String) _
                                As Boolean

Here the List class is the generic replacement for the ArrayList class. Similarly to ArrayList class, the List(Of) class can grow and shrink dynamically.

The second parameter ErrorInfo is used to pass the error information back to the client in case of an error situation. Ideally it is not advisable to have ByRef methods defined as part of a web method in an enterprise wide application. But since we are not raising SOAP exceptions, it s easy to maintain this simple structure. The method returns a True or False to the client and if in case of an error, the ErrorInfo variable can be checked for more details.

Let’s implement the UploadFile() method. The full code listing for the method is given below:

<WebMethod()> _
  Public Function UploadFile(ByVal Files As List(Of FileInfo), ByRef 
                             ErrorInfo As String) As Boolean
    Dim SoapContxt As SoapContext = RequestSoapContext.Current
    Try
    ‘ Verifies that a valid Soap Request is in place.  
    ‘ Otherwise error out
      If SoapContxt Is Nothing Then
        Throw New ApplicationException("Only SOAP requests are permitted.")
      End If
    ‘Insert the details to database
      StoreFilesInDatabase(Files)
      Return True
    Catch ex As Exception
      ErrorInfo = ex.Message
      Return False
    Finally
      SoapContxt = Nothing
    End Try
  End Function

You should ensure that the SoapContxt returns something and throws an exception otherwise. If there is no value that implies that a problem was encountered, the message will be passed on.

The StoreFilesInDatabase() function will be used to save the data to the database. In the code download you will find a table named MTOM as part of the SQL script which is used to store the file information. The table is created in the Northwind database and details are given in the accompanying Readme.txt. This is the only table that you will make use of in the application.

The StoreFileInDatabase() function is used to extract the contents of the file and upload the same to the database.

Private Sub StoreFilesInDatabase(ByVal MtomFiles As List(Of FileInfo))
  …
  FileContents = MTOMEnumerator.Current.FileContents
  FileName = MTOMEnumerator.Current.FileName
  FileType = MTOMEnumerator.Current.FileType
  Dim ParameterArray() As SqlParameter = New SqlParameter(2) {}
  objbroker = New DataBroker
  ‘ File Name of the File 
  ParameterArray(0) = New SqlParameter("FileName", SqlDbType.VarChar, 
                            50)
  ParameterArray(0).Value = FileName
  …
  Dbbroker.OpenConnection()
  ‘Call the helper class method to store the contents to the database
  Call Dbbroker.ExecuteQuery("InsertFile", ParmeterArray)  

Essentially that is the heart of the whole process to get the MTOM coded message out and extract the binary information. Once you have the raw data you can make use of the database helper class DataBroker to update the database with the relevant information. This utility class is a lightweight version of the Microsoft supplied Database Application Blocks. This utility class has functions which help in interacting with the database. Here the point to note is that you are actually storing the entire contents of the file rather that just the file path. A stored procedure named InsertFile is used to accomplish it. It is a simple stored procedure which accepts the file attributes and stores them in the MTOM table as shown below.

CREATE PROCEDURE InsertFile

(
  FileName Varchar(50),
  MimeType Varchar(50),
  FileContents    Image
)
AS	
BEGIN
  SET NOCOUNT ON
  INSERT INTO	MTOM
  ( 
    [FileName],
    [MimeType],
    [FileContents]
  )
  VALUES 		
  (
    FileName,
    MimeType,
    FileContents
  )

SET NOCOUNT OFF

END

Finally the UploadFile() method can now end with a response flag as True (or False if something went wrong).

  …
  ‘Insert the details to database
   StoreFilesInDatabase(Files)
   Return True

Catch ex As Exception
   ErrorInfo = ex.Message
   Return False

Finally
    SoapContxt = Nothing
   …

One of the noticeable differences that you will find in WSE 3.0 is that for enabling MTOM you do not have to use a separate attachments collection as with DIME in order to send the data. All you need do is write the service and then simply mark that the service supports MTOM encoding in the application’s configuration file as I have explained previously. In reality any byte() types used by the service are then MTOM-automatically encoded. This is a radical change in the way we used to work with the binary attachments in WSE 2.0. Obviously the choice there was to use DIME and create the DIME records one by one and embed that in the SOAP message. This is no longer required and the amount of code that you need to write to accomplish MTOM coding is much less.

Conclusion

In this article, I have explained the Message Transmission Optimization Mechanism (MTOM) specification, which defines a lightweight, binary message format that can be used to embed binary data into SOAP messages. In a nutshell, MTOM offers an alternate serialization of XML that just happens to look like a MIME multipart/related package, with an XML document as the root part. The root part is very similar to the XML serialization of the document, except that base64 encoded data is replaced by a reference to one of the MIME parts, which isn t base64 encoded. Together you found how Web Services Enhancements for Microsoft .NET offers the most complete solution for sending and receiving attachments with SOAP messages. The discussion also touched briefly on MTOM s superiority over DIME.

In the second part of this article I will demonstrate how you can consume the web service that was developed in this article. I will also examine how security can be enforced with some simple settings with WSE 3.0.