WCF: (MTOW) ist es eine Möglichkeit, die Regelung in xop verwendet zu ändern: Content Referenz uris von WCF erzeugt?

Question

WCF verwendet http://tempuri/1/number für Content-ID uri Verweis beim Umgang MTOM Anfragen gestreamt.

Gibt es eine Möglichkeit, wie WCF zu zwingen, eine andere Content-ID Referenzen für die xop zu verwenden:? Fügen Sie

Hintergrund des Problems:

Ich baue ein .NET-Client für MTOM aktiviert JAX ws Java-Webservice, dass Griffe große Daten Uploads gestreamt. Ich habe Hand die Service- und Datenkontakte gefertigt (die WSDL generierten Verträge waren nicht korrekt und nicht erlauben Streaming).

Das Problem ist, dass der Web-Service (JAX ws) die Anforderung nicht Körper erhält die Daten enthält.

Sie empfängt die Daten, die in Header übertragen wird.

Wir haben ein Java-Client für die ws gebaut -. Dieser funktioniert

Ich habe gefangen genommen und den HTTP-Verkehr im Vergleich, wenn Anfragen von Java und wcf Ausgabe, und der einzige Unterschied besteht darin, wie Content-ID Referenz erzeugt wird, wenn das Multipart Daten veröffentlichen:

• WCF Anwendungen http://tempuri/1/... Content-ID Referenzen, die Ausbeute in codiertem Wert, wie href="cid:http%3A%2F%2Ftempuri.org%2F1%2F634019957020047928"

• Java-Client-Anwendungen "E-Mail-style" uris, wie href="cid:3f3ec388-8cd9-47aa-a603-fb1bc17935b8@example.jaxws.sun.com"

Diese Ausbeute in der folgenden XOP-includes (Data ist das einzige Element in dem Seifenkörper) ( XOP umfasst Spezifikation )

---

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

später, in den mehrteiligen Daten, der Inhalt von nicht-codierter Content-ID bezeichnet wird:

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

Ich denke, es kann ein Fehler in dem JAX Web-Service-Framework sein, und es ist nicht zu erkennen WCF-generated + urlencoded Content-ID uri Referenzen.

Gibt es eine Möglichkeit, wie WCF zu zwingen, eine andere Content-ID Referenzen für die xop zu verwenden:? Fügen Sie

---

EDIT:. Ich habe die XmlMtomWriter gefunden, die die GenerateUriForMimePart Methode hat, diese verwendet wird 'Content-IDs zu generieren

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

Es scheint nicht, dass die ID-Generation in irgendeiner Weise außer Kraft gesetzt werden.

Ein ähnliches Problem wird hier beschrieben, sofern die Antwort nicht hilft: http://social.msdn.microsoft.com/Forums/en/wcf/thread/f90affbd-f431-4602-a81d-cc66c049e351

Answer 1

Asnwering mich nach langer Untersuchung:. Nicht möglich, ohne den gesamten XmlMtomWriter und andere damit zusammenhängende Schichten und Anliegen in WCF Neuimplementierung - fast beteiligt alles in der MTOM Umsetzung intern

Answer 2

Ich weiß, es ist eine alte Frage. Aber ich bin vor dem gleichen Problem 2 Tage gegenüber.

Ich fand einen Weg, der funktioniert, aber es ist ein sehr, sehr schmutzig Hack (Ich weiß das. Ich dachte nicht, dass es hier zu veröffentlichen, aber vielleicht wäre es jemand helfen.) Hoffentlich werden Sie nicht mir die Schuld dafür.

Die contentid ist mit der Verwendung von CultureInfo.InvariantCulture formatiert. Ich habe keinen offiziellen Weg finden, es mit einem benutzerdefinierten Culture ersetzen. Aber mit Hilfe der Reflexion habe ich es laufen. Die folgende Implementierung ist nur für .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);
   }
}

ermogliche meine eigenen "InvariantCulture" nur vor einem WCF-Aufruf.

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

CultureInfo.InvariantCulture ist ein globales Statusobjekt. Eigene InvariantCulture Enabling wirkt sich auf alle anderen Thread. Auch hier ist es ein schmutziger Hack. Aber es funktioniert.

Answer 3

Sowohl der XOP enthält Beispiele, dass Sie angegeben sind richtig und akzeptabel nach dem W3C. Ich beziehe mich auf sie als das URL-Format und E-Mail-Format sind.

Ich bin kein Java-Entwickler, aber daran erinnern, ein ähnliches Problem, wenn sie mit einem bestimmten JAVA Web-Service-Schnittstelle. Ich erinnere mich, es ist ein Fehler in einer bestimmten JAVA-Release und mehr, nachdem sie (der Java-Entwickler) auf die nächste Version aktualisiert, dieses Problem einfach ging. Ich wünschte, ich könnte Ihnen mehr Details liefern, aber zu der Zeit gab es genug Probleme für mich zu Adresse von meinem Ende des Drahtes und ich war nur froh, einen kleinen Punkt auf dem Defektprotokoll zu haben.

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