Convert XML namespace prefixes with C#?

I have run into an exasperating problem getting a Java service client to communicate successfully with a WCF service. I have overcome many hurdles, and I believe that this is my last one. The problem boils down to how Java Axis + WSS4J seem to handle xml namespaces. The Java platform seem to be very rigid in what they expect for xml namespace prefixes, and as such, do not understand the WCF reply messages.

My problem in a nutshell is as follows. I have an xml response similar to the following from my WCF service:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:a="http://www.w3.org/2005/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <s:Header>
      <a:Action s:mustUnderstand="1" u:Id="_3">http://tempuri.org/IProcessor/DoProcessingResponse</a:Action>
      <h:CorrelationID xmlns:h="http://tempuri.org/">1234</h:CorrelationID>
      <a:RelatesTo u:Id="_4">uuid:40f800a0-9613-4f4a-96c5-b9fd98085deb</a:RelatesTo>
      <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <!-- WS-Security header stuff -->
      </o:Security>
   </s:Header>
   <s:Body u:Id="_1">
      <e:EncryptedData Id="_2" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:e="http://www.w3.org/2001/04/xmlenc#">
         <e:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
         <e:CipherData>
            <e:CipherValue>NfA6XunmyLlT2ucA+5QneoawHm+imcaCltDAJC1mRZOSxoB6YGpDLY1FyVykPbPGDoFGUESLsmvvbD62sNnRrgE+AuKPo+1CD3DF4LfurRcEv9A50ba9V+ViqlrhydhK</e:CipherValue>
         </e:CipherData>
      </e:EncryptedData>
   </s:Body>
</s:Envelope>

This response uses simple one-character namespace prefixes for most things, such as 's' for SOAP Envelope, 'a' for WS-Addressing, 'o' for 'WS-Security', etc. The Java client, namely WSS4J, seems to expect the following:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
   <soap:Header>
      <wsa:Action soap:mustUnderstand="1" wsu:Id="_3">http://tempuri.org/IProcessor/DoProcessingResponse</wsa:Action>
      <h:CorrelationID xmlns:h="http://tempuri.org/">1234</h:CorrelationID>
      <wsa:RelatesTo wsu:Id="_4">uuid:40f800a0-9613-4f4a-96c5-b9fd98085deb</a:RelatesTo>
      <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <!-- WS-Security header stuff -->
      </wsse:Security>
   </soap:Header>
   <soap:Body u:Id="_1">
      <xenc:EncryptedData Id="_2" Type="http://www.w3.org/2001/04/xmlenc#Content" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
         <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
         <xenc:CipherData>
            <xenc:CipherValue>NfA6XunmyLlT2ucA+5QneoawHm+imcaCltDAJC1mRZOSxoB6YGpDLY1FyVykPbPGDoFGUESLsmvvbD62sNnRrgE+AuKPo+1CD3DF4LfurRcEv9A50ba9V+ViqlrhydhK</xenc:CipherValue>
         </xenc:CipherData>
      </xenc:EncryptedData>
   </soap:Body>
</soap:Envelope>

Upon receipt of my response message, the Java client and WSS4J seem to want to look up elements by their own internal xml aliases, such as 'wsa' for WS-Addressing, and 'wsse' for WS-Security Extensions. Since neither of those namespaces are present in the actual response xml, exceptions are thrown.

I am wonderi开发者_JAVA技巧ng if there is any simple way to transform an xml document from one set of namespaces to another set using C#, .NET, and the System.Xml namespace. I've poked around with XmlNamespaceManager a bit, but it does not seem to fully support what I need...or at least, I have been unable to find any really useful examples, and am not fully sure how it works. I am trying to avoid having to write some heavy-duty process to handle this manually myself, as I do not want to drastically impact the performance of our services when called by a Java Axis/WSS4J client.

This particular problem seemed to stem from an old and buggy version of WSS4J. Newer versions do not seem to have this problem, and it is no longer an issue.