WCF: (MTOM) non v'è alcun modo per cambiare lo schema utilizzato in XOP: URI di riferimento contenuto generato da WCF?

Question

WCF utilizza http://tempuri/1/number per Content-ID riferimenti URI quando si maneggiano streaming richieste MTOM.

C'è un modo come forzare WCF per utilizzare un diverso riferimenti Content-ID per il XOP:? Includere

Sfondo del problema:

Sto costruendo un client .NET per MTOM abilitato servizio web WS JAX Java che gestisce in streaming grandi caricamenti di dati. Ho lavorato a mano i contatti di servizio e di dati (il WSDL generato contratti non erano corrette e non ha permesso lo streaming).

Il problema è che il servizio Web (WS JAX) non riceve il corpo della richiesta contenente i dati.

Esso riceve i dati che vengono trasferiti nelle intestazioni.

Abbiamo costruito un client java per l'ws -. Questo funziona

Ho catturato e confrontato il traffico HTTP quando l'emissione di richieste provenienti da Java e WCF, e l'unica differenza è nel modo in cui viene generato riferimento Content-ID durante la pubblicazione dei dati multipart:

• WCF utilizza http://tempuri/1/... riferimenti Content-ID che danno valore codificato, come href="cid:http%3A%2F%2Ftempuri.org%2F1%2F634019957020047928"

• client Java utilizza "email-style" URI, come href="cid:3f3ec388-8cd9-47aa-a603-fb1bc17935b8@example.jaxws.sun.com"

Questi rendimento nella seguente XOP-include (dati è l'unico elemento del corpo sapone) ( XOP comprende specifiche )

---

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

In seguito, nei dati più parti, il contenuto è nominato da non codificata Content-ID:

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

Credo che ci possono essere un bug nel quadro servizio web jax e non riconosce WCF-generati + Content-ID riferimenti URI urlencoded.

C'è un modo come forzare WCF per utilizzare un diverso riferimenti Content-ID per il XOP:? Includere

---

EDIT:. Ho trovato il XmlMtomWriter che ha il metodo GenerateUriForMimePart, questo è usato per generare Content-ID

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

Non mi sembra che la generazione ID è in alcun modo override.

Un problema simile è descritto qui, la risposta fornita non aiuta: http://social.msdn.microsoft.com/Forums/en/wcf/thread/f90affbd-f431-4602-a81d-cc66c049e351

Answer 1

Asnwering a me stesso dopo una lunga indagine:. Non è possibile, senza reimplementare l'intero XmlMtomWriter e altri strati e preoccupazioni in WCF correlate - quasi tutto ciò che riguarda l'attuazione MTOM è interno

Answer 2

Lo so che è una vecchia questione. Ma sono di fronte lo stesso problema due giorni fa.

Ho trovato un modo che funziona, ma è un hack molto sporco (lo so. Ho pensato di non pubblicarlo qui, ma forse sarebbe aiutare qualcuno.) Spero che non mi biasimare per questo.

Il ContentID è formattato con l'uso di CultureInfo.InvariantCulture. Non ho trovato un modo ufficiale per la sua sostituzione con un costume CultureInfo. Ma con l'aiuto di riflessione ho preso in esecuzione. La seguente applicazione è solo per .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);
   }
}

abilito la mia "InvariantCulture" solo prima di una chiamata WCF.

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

CultureInfo.InvariantCulture è un oggetto stato globale. L'attivazione di mia InvariantCulture colpisce ogni altro thread. Anche in questo caso, si tratta di un hack sporco. Ma funziona.

Answer 3

Sia del XOP include campioni che avete indicato siano corrette e accettabili secondo il W3C. Mi riferisco a loro come il formato URL e il formato e-mail, rispettivamente.

Io non sono uno sviluppatore Java, ma ricordo un problema simile quando si interfaccia con un particolare servizio Java Web. vi ricordo essere un bug in una particolare versione JAVA e dopo (gli sviluppatori Java) aggiornato alla versione successiva, questo problema semplicemente se ne andò. Vorrei poter fornire maggiori dettagli, ma, al momento, ci sono stati abbastanza problemi per me rivolgermi dal mio capo del filo ed ero solo felice di avere un elemento in meno sul registro difetto.

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