It's good to see that many custom transports are beign developped for use in WSE2. I already have seen support for MSMQ, SMTP, UDP and MSSQL, and i have developped two new: Memory Mapped Files (for use as pseudo inproc, for communication between process but not using the network stack) and Named Pipes.

What is not very happy is the way some of this transports serialize the SoapEnvelope object before sending, and the worst case i have seen is something like this:

string msgBody = message.OuterXml;

Later, for "deserializing" the following code is used:

SoapEnvelope env = new SoapEnvelope();

env.LoadXml(msgBody);

Well, this code has some serious problems related with the character encoding of the XML stream. It may work in some cases where the text representing the envelope is transmitted (or stored) using UNICODE, but this is not always the case. There is also another problem with this "technique": attachments are all forgotten, and will be lost without notice when sent.

A better (and safer) way to do the job is using the ISoapFormatter interface and a implementation of a soap formatter found in WSE2. You can use SoapPlainFormatter (if you don't care about attachments) or SoapDimeFormatter.

To serialize the SoapEnvelope we could use code like this:

In this case, we serialize the envelope and obtain a Base64 encoded version of the serialized envelope to be sure the content can be transmitted on every transport. It's also acceptable to use an UTF8 encoding for the transport if you are sure there will be not encoding problems.

To deserialize the previous content you may use the following code:

Well, i hope that this comments helps to give a better use to those new custom transports for WSE2 and eliminate the weird problems that can appear from encoding problems due to improper serialization, and the proper way to deal with DIME attachments.

Best Regards,

Andrés G Vettori
MCSE/MCSD/MCT
Leader of the C# Community of the Microsoft Users Group Argentina

No Comments