Converter prefixos de namespace XML com C#?

Question

Eu encontrei um problema de exasperador para que um cliente de serviço Java se comunique com sucesso com um serviço WCF. Eu superei muitos obstáculos e acredito que este é o meu último. O problema se resume a como o eixo java + wss4j parece lidar com namespaces XML. A plataforma Java parece ser muito rígida no que eles esperam para os prefixos de namespace XML e, como tal, não entendem as mensagens de resposta do WCF.

Meu problema em poucas palavras é o seguinte. Eu tenho uma resposta XML semelhante à seguinte do meu serviço WCF:

<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>

Essa resposta usa prefixos simples de namespace de um caractere para a maioria das coisas, como 'S' para envelope de sabão, 'a' para o endereço de WS, 'O' para 'WS-Security', etc. O cliente Java, ou seja, WSS4J, parece para esperar o seguinte:

<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>

Após o recebimento da minha mensagem de resposta, o cliente Java e o WSS4J parecem querer procurar elementos por seus próprios aliases XML internos, como 'WSA' para addressing WS e 'WSSE' para extensões de segurança WS. Como nenhum desses namespaces está presente na resposta real XML, as exceções são lançadas.

Gostaria de saber se existe alguma maneira simples de transformar um documento XML de um conjunto de espaços para names em outro conjunto usando C#, .NET e System.xml Namespace. Eu cutuquei um pouco com o XMLNamesPacemanager, mas ele não parece apoiar completamente o que preciso ... ou pelo menos, não consegui encontrar exemplos realmente úteis e não tenho certeza de como funciona. Estou tentando evitar escrever algum processo pesado para lidar com isso manualmente, pois não quero impactar drasticamente o desempenho de nossos serviços quando chamado por um cliente Java Eixo/WSS4J.

Answer 1

Esse problema em particular parecia resultar de uma versão antiga e de buggy do WSS4J. Versões mais recentes não parecem ter esse problema, e não é mais um problema.