WCF: (MTOM) هل هناك أي طريقة لتغيير المخطط المستخدم في XOP: Content Reference URIs الذي تم إنشاؤه بواسطة WCF؟

Question

يستخدم WCF http://tempuri/1/number بالنسبة إلى مراجع URI معرف المحتوى عند التعامل مع طلبات MTOM المتدفقة.

هل هناك أي طريقة لإجبار WCF على استخدام مراجع مختلفة لمحتوى محتوى لـ XOP: قم بتضمين؟

خلفية المشكلة:

أقوم بإنشاء عميل .NET لـ MTOM تمكين خدمة الويب Jax WS Java التي تتولى عمليات تحميل البيانات الكبيرة. لقد قمت بصياغة يدوي الخدمة والاتصالات البيانات (لم تكن العقود التي تم إنشاؤها من WSDL صحيحة ولم تسمح بالتدفق).

المشكلة هي أن خدمة الويب (JAX WS) لا تتلقى هيئة الطلب التي تحتوي على البيانات.

يتلقى البيانات التي يتم نقلها في الرؤوس.

لقد قمنا ببناء عميل Java لـ WS - هذا واحد يعمل.

لقد استولت على وحركة HTTP عند إصدار طلبات من Java و WCF ، والفرق الوحيد هو كيفية إنشاء مرجع معرف المحتوى عند نشر بيانات متعددة: Multipart:

• يستخدم WCF http://tempuri/1/... مراجع معرف المحتوى التي تعطي القيمة المشفرة ، مثل href="cid:http%3A%2F%2Ftempuri.org%2F1%2F634019957020047928"

• يستخدم عميل Java "على غرار البريد الإلكتروني" URIS ، مثل href="cid:3f3ec388-8cd9-47aa-a603-fb1bc17935b8@example.jaxws.sun.com"

هذه العائد في إدراج XOP التالي (البيانات هي العنصر الوحيد في جسم الصابون) (يشمل XOP المواصفات)

---

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

في وقت لاحق ، في البيانات المتعددة ، يشار إلى المحتوى من خلال معرف المحتوى غير المشفر:

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

أعتقد هناك مايو كن خطأً في إطار خدمة الويب Jax ، ولا يتعرف على مراجع URI التي تم إنشاؤها بواسطة WCF+URLencoded مع مراجع URI.

هل هناك أي طريقة لإجبار WCF على استخدام مراجع مختلفة لمحتوى محتوى لـ XOP: قم بتضمين؟

---

تحرير: لقد وجدت XMLMTomWriter الذي يحتوي على طريقة GenerateRiformImePart ، ويستخدم هذا لإنشاء معدات المحتوى.

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

لا يبدو أن توليد الهوية يمكن تجاوزه بأي حال من الأحوال.

تم وصف مشكلة مماثلة هنا ، لا تساعد الإجابة المقدمة: http://social.msdn.microsoft.com/forums/en/wcf/thread/f90afbd-f431-4602-a81d-cc66c049e351

Answer 1

Asnwering لنفسي بعد التحقيق الطويل: غير ممكن دون إعادة تنفيذ XMLMTomWriter بالكامل والطبقات الأخرى ذات الصلة والمخاوف في WCF - كل ما يشارك في تنفيذ MTOM داخلي تقريبًا.

Answer 2

أعلم أنه سؤال قديم. لكنني واجهت نفس المشكلة قبل يومين.

لقد وجدت طريقة تعمل ، لكنها اختراق قذرة للغاية (أعرف ذلك. فكرت في عدم نشرها هنا ، لكن ربما ستساعد شخصًا ما.) آمل ألا تلومني على ذلك.

يتم تنسيق المحتوى مع استخدام CultureInfo.invariantCulture. لم أجد طريقة رسمية لاستبدالها بثقافة مخصصة. ولكن بمساعدة الانعكاس حصلت عليه. التنفيذ التالي هو فقط لـ .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);
   }
}

أقوم بتمكين "InstariantCulture" الخاص بي فقط قبل مكالمة WCF.

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

CultureInfo.InvariantCulture هو كائن الدولة العالمي. يؤثر تمكين زراعة الثقافة الخاصة بي على كل خيط آخر. مرة أخرى ، إنه اختراق قذر. ولكنه يعمل.

Answer 3

يتضمن كل من XOP العينات التي أشرت إليها صحيحة ومقبولة وفقًا لـ W3C. أشير إليهم كتنسيق عنوان URL وتنسيق البريد الإلكتروني على التوالي.

أنا لست مطور Java ، لكنني أذكر مشكلة مماثلة عند التواصل مع خدمة ويب Java معينة. أتذكر أن هناك خطأ في إصدار معين من Java وبعد أن قاموا (مطوري Java) بالترقية إلى إصدار الإصدار التالي ، ذهبت هذه المشكلة ببساطة. أتمنى أن أتمكن من توفير المزيد من التفاصيل ، ولكن في ذلك الوقت ، كانت هناك مشاكل كافية بالنسبة لي لأتناولها من نهايتي من السلك وكنت سعيدًا فقط بوجود عنصر أقل في سجل العيب.

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