O WCF:(MTOM) existe alguma forma de alterar o esquema utilizado no xop:Conteúdo referência uris gerado pelo WCF?

Question

O WCF utiliza http://tempuri/1/number para o Conteúdo de ID de referências uri ao manusear transmitido MTOM pedidos.

Existe alguma maneira de como forçar o WCF para usar um diferente Conteúdo de ID de referências para o xop:Include?

Plano de fundo do problema:

Eu estou construindo .Rede cliente para MTOM habilitado jax ws java web do serviço de que trata transmitido de dados grandes carregamentos.Eu tenho trabalhado à mão o serviço e dados de contatos (o WSDL gerado contratos não foram corretas e não permitir streaming).

O problema é que o serviço da web (jax ws) não recebe o corpo do pedido contendo os dados.

Ele recebe os dados que são transferidos em cabeçalhos.

Nós construímos um cliente em java para o ws - este funciona.

Eu capturados e comparou o tráfego HTTP de quando a emissão de pedidos de java e do wcf, e a única diferença está na forma como o Conteúdo de ID de referência é gerada quando postagem com várias partes de dados:

• O WCF utiliza http://tempuri/1/... O conteúdo de ID de referências que o rendimento no valor codificado, como href="cid:http%3A%2F%2Ftempuri.org%2F1%2F634019957020047928"

• Java usa o cliente de e-mail "estilo" uris, como href="cid:3f3ec388-8cd9-47aa-a603-fb1bc17935b8@example.jaxws.sun.com"

Estes rendimento no seguinte xop-inclui (Dados é o único elemento no corpo de soap) (XOP inclui a especificação)

---

//WCF:
<Data>
   <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:http%3A%2F%2Ftempuri.org%2F1%2F634019957020047928" />
</Data>

//JAVA:
<Data>
    <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:3f3ec388-8cd9-47aa-a603-fb1bc17935b8@example.jaxws.sun.com"/>
</Data>

mais tarde, em várias partes de dados, o conteúdo é referido por unencoded de ID de Conteúdo:

--uuid:7e166bb7-042f-4ba3-b6ef-98fbbc21244b+id=1
Content-ID: <http://tempuri.org/1/634019957020047928>
Content-Transfer-Encoding: binary
Content-Type: application/octet-stream

Eu acho que há pode ser um bug no serviço da web jax-quadro e ele não está reconhecendo o WCF-gerada+urlencoded Conteúdo de ID de referências uri.

Existe alguma maneira de como forçar o WCF para usar um diferente Conteúdo de ID de referências para o xop:Include?

---

EDITAR:Achei o XmlMtomWriter que tem o GenerateUriForMimePart método, esta é utilizada para gerar Conteúdo-IDs.

public static string GenerateUriForMimePart(int index)
{
    return string.Format(CultureInfo.InvariantCulture, 
"http://tempuri.org/{0}/{1}", new object[] { index, DateTime.Now.Ticks });
}

Não parece que a geração de ID é, de qualquer forma substituível.

Um problema semelhante é descrito aqui, as respostas fornecidas não ajuda: http://social.msdn.microsoft.com/Forums/en/wcf/thread/f90affbd-f431-4602-a81d-cc66c049e351

Answer 1

Aumentando para mim mesma após uma longa investigação: não é possível sem reimplementar todo o xmlmtomwriter e outras camadas e preocupações relacionadas no WCF - quase tudo envolvido na implementação do MTOM é interno.

Answer 2

Eu sei que é uma pergunta antiga. Mas estou enfrentando o mesmo problema há dois dias.

Encontrei uma maneira que funciona, mas é um hack muito sujo (eu sei disso. Pensei em não publicá -lo aqui, mas talvez ajudasse alguém.) Espero que você não me culpe por isso.

O contentID é formatado com o uso de culturaInfo.invariantculture. Não encontrei uma maneira oficial de substituí -lo por um CultureInfo personalizado. Mas com a ajuda da reflexão, consegui correndo. A implementação a seguir é apenas para .NET 4.0.

public class NoTempUriInvariantCultureInfo : CultureInfo, ICustomFormatter
{
   private static CultureInfo originalCulture;
   private static object originalCultureLock;
   private static int enableCounter;

   private NoTempUriInvariantCultureInfo(CultureInfo invariantCulture)
      : base(invariantCulture.Name)
   {
      originalCulture = invariantCulture;
   }

   public static void Enable()
   {
      if(originalCultureLock == null)
         originalCultureLock = new object();

      lock (originalCultureLock)
      {
         if (enableCounter == 0)
         {
            var mInvCultField = typeof (CultureInfo).GetField("s_InvariantCultureInfo", BindingFlags.NonPublic | BindingFlags.Static);
            mInvCultField.SetValue(null, new NoTempUriInvariantCultureInfo(CultureInfo.InvariantCulture));
         }
         enableCounter++;
      }
   }

   public static void Disable()
   {
      lock (originalCulture)
      {
         if (enableCounter == 0)
            return;

         enableCounter--;
         if (enableCounter == 0)
         {
            var mInvCultField = typeof (CultureInfo).GetField("s_InvariantCultureInfo", BindingFlags.NonPublic | BindingFlags.Static);
            mInvCultField.SetValue(null, NoTempUriInvariantCultureInfo.originalCulture);
         }
      }
   }

   public override object GetFormat(Type formatType)
   {
      var result = originalCulture.GetFormat(formatType);
      return result ?? this;
   }

   public string Format(string format, object arg, IFormatProvider formatProvider)
   {
      if (format == null)
         return System.Text.RegularExpressions.Regex.Replace(arg.ToString().Replace("http%3A%2F%2Ftempuri.org%2F1%2F", ""), "http[:][/][/]tempuri[.]org[/][0-9]+[/]*", "");
      return String.Format("{0:" + format + "}", arg);
   }
}

Eu habilitei minha própria "invariante" apenas antes de uma ligação da WCF.

NoTempUriInvariantCultureInfo.Enable();
try
{
    // make your call
}
finally
{
    NoTempUriInvariantCultureInfo.Disable();
}

CultureInfo.invariantculture é um objeto de estado global. Habilitar minha própria invariante afeta todos os outros tópicos. Novamente, é um hack sujo. Mas funciona.

Answer 3

Ambas as XOP inclui exemplos que você indicou são corretas e aceitáveis de acordo com o W3C.Me refiro a eles como o formato de URL e e-Mail formato respectivamente.

Eu não sou um programador JAVA, mas lembrar de um problema semelhante quando uma interface com um determinado JAVA web service.Me lembro que há um erro em uma determinada versão JAVA e depois que eles (os desenvolvedores JAVA) atualizado para a próxima versão, esse problema simplesmente foi embora.Eu desejo que eu poderia fornecer-lhe mais detalhes, mas na época, não foram suficientes problemas para mim o endereço do meu extremidade do fio e eu estava muito feliz por ter menos um item sobre o defeito de log.

//WCF: using URL format
<Data>
   <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:http%3A%2F%2Ftempuri.org%2F1%2F634019957020047928" />
</Data>

//JAVA: using EMAIL format
<Data>
    <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:3f3ec388-8cd9-47aa-a603-fb1bc17935b8@example.jaxws.sun.com"/>
</Data>