This project is read-only.

Does MSE like MTOM?

Dec 5, 2008 at 11:07 AM
Edited Dec 5, 2008 at 11:13 AM

We're having problems with a .net 3.5 client consuming an MSE endpoint that's a facade over a basichttp service utilising MTOM with additional parameters.

Here's the concrete service interface:

    [ServiceContract]
    public interface IEventService
    {
        /// <summary>
        /// Public service operation for callers to send event data.
        /// </summary>
        /// <param name="uploadPackage">Input parameter type containing members
        /// for vehicle data identification and payload.</param>
        /// <returns>UploadResult type containing 3 string types. Only returnCode
        /// used in this implementation and returns success or failure
        /// code.</returns>
        [OperationContract]
        [FaultContract(typeof(ArgumentNullException))]
        [FaultContract(typeof(ArgumentException))]
        UploadResult SendEventData(UploadPackage package);
    }
       
    /// <summary>
    /// Have to implement Message Contract as Operation Contract only supports
    /// single stream parameter when using MTOM with WCF.
    /// see <a "http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/1810d663-0e9c-4c83-9a1b-1b5793bd9e7b">this</a>.
    /// </summary>
    [MessageContract]
    public class UploadPackage
    {
        [MessageHeader]
        public string fleet;

        [MessageHeader]
        public string unitNumber;

        [MessageHeader]
        public string dateTime;

        [MessageBodyMember]
        public Stream eventStream;
    }

    /// <summary>
    /// Return type must match header send parameters with message contracts.
    /// </summary>
    [MessageContract]
    public class UploadResult
    {
        [MessageHeader]
        public string returnCode;

        [MessageHeader]
        public string unitNumber;

        [MessageHeader]
        public string dateTime;
    }

In our client app, if we add a reference directly to the concrete service the resulting SendEventData call expects the 4 parameters as expected.
However if we add a reference to the mse service the resulting SendEventData call expects only the messagestream parameter.

It's as if when MSE virtualised the service it didn't recognise the other parameters in the message header? BTW I've had to define a message contract directly as this is the only way I knew how to define a service that could accept an MTOM stream as well as additional parameters - perhaps it's this that MSE doesn't like?

Dec 6, 2008 at 11:35 PM
MTOM should flow through the MSE ok.  The problem you are experiencing is infact related to message headers.  The MSE currently isn't projecting WSDL's properly for operations that use message headers.  Note however that you can still send the message through MSE with the headers and the headers will flow through to the service implementation.  One workaround could be to perform the add service reference to the concrete service and then update the endpoint information in the generated client application to point to the MSE hosted endpoint.
Dec 8, 2008 at 9:03 PM
Thanks botto, I did a similar work around for a basic soap client so I can understand how that might work.
Dec 10, 2008 at 3:02 PM
It worked by adding a service reference to both the MSE and concrete services, instantiating a service client for the concrete service and updating the endpoint address and binding to that of the MSE service, a bit like this:

myService.Endpoint.Address = 

 MSEService.Endpoint.Address;

 

myService.Endpoint.Binding = MSEService.Endpoint.Binding;

We think this is an acceptable work around for now as we're not implementing the concrete service, just using it as a reference for the service client and then updating the endpoint (and thefore implementation) at runtime.

Botto - we're trying to hide the concept of concrete services from our developers so the sooner MSE can project WSDL's correctly for message header operations the better - is this something that can be added to the change log?

Dec 10, 2008 at 5:00 PM
I've created an issue for this.