ما هي أفضل طريقة لفضح خدمة WCF بحيث يمكن استهلاكها بسهولة من Java / CXF؟

Question

لقد كتبنا خدمة WCF لاستخدامها بواسطة متجر Java، يستخدم CXF لتوليد المحولات. نحن لسنا على دراية بجافا، لكننا كشفت عن الخدمة باستخدام basichttpbinding، SSL، والمصادقة الأساسية. تظهر اختبارات التكامل أن عميل .NET يمكن أن يستهلك الخدمة جيدة فقط. ومع ذلك، فإن متجر Java يواجه مشكلة في استهلاك الخدمة. على وجه التحديد، يتحصلون على خطأ Jaxb التالية: تصريحان يسببان تصادما في الفئة الموضوعية. عادة ما يكون هذا هو عادة ما إذا كانت العمليات لها نفس الاسم واسم مساحة الاسم عندما يحاول CXF إنشاء فئات محول.

لا يمكننا العثور على أي أسماء أو عملية عملية يجب أن تسبب أي نوع من الاصطدام. لقد أوقفنا أن جميع الأنواع المخصصة تحدد مساحة الاسم، ولم يتم تحديد tempuri.org في أي مكان في WSDL. المشتبه في متجر Java الخطأ هو أن WSDL الذي تم إنشاؤه يحتوي

لذلك، أسئلتي:

• هل هناك أي طريقة أفضل من CXF لمتجر Java تستهلك خدمة WCF؟ يبدو مشروع Tango مثيرا للاهتمام، لكنني لا أعرف ما يكفي لإخبارهم بالنظر في استخدامه. هو CXF قياسي Defacto في جافا؟
• BasichTTPBinding / SSL / AUTH AUTH / الأساسي هي MS الموصى بها لسيناريوهات Interop، ولكن لا يزال لدى العميل مشاكل داخلية. هل يجب علينا النظر في ارتباطات أو إعدادات أخرى لجعل هذا أسهل للاستهلاك؟
• هل هناك طريقة لتكوين WCF لإخراج WDSL واحد مع عدم وجود واردات مخطط؟

Answer 1

عادة ما لا علاقة لي بإعلانين في التصادم في الطبقة الموضوعية الفئة الموضوعية مع الواردات. هذه رسالة خطأ JAXB عادة ما تكون ناتجة عن وجود عناصر متعددة أو مماثلة تتسبب في أن تكون أسماء الحقول التي تم إنشاؤها هي نفسها. على سبيل المثال، إذا كان لديك عناصر مثل:

u003Celement name="Foo" .../>وu003Celement name="foo" .../>

يمكن أن يسبب هذا الخطأ. آخر يستخدم شيء مثل الواصلات والسفذيد والذي يتم القضاء عليه عادة + توج:u003Celement name="doFoo" .../> وu003Celement name="do_foo" .../>

مع 2.1.4، يمكنك محاولة تشغيل WSDL2JAVA مع علم -Autonameresolution. هذا يساعد في بعض الأحيان مع هذا، ولكن ليس دائما. لسوء الحظ، فإن المعلومات التي تعطيها jaxb في هذه الحالات لا قيمة لها تقريبا والكثير من الأوقات مجرد تجربة وخطأ للعثور على الأنواع المتضاربة. :-(

Answer 2

لقد قمت بتطوير WCF مع عملاء AXIS2. أساليب المصادقة التي استخدمتها بنجاح هي basichttpbinding / SSL / SSL (النقل) والأمن WS مع اسم المستخدم (و MTOM).

يتم استخدام تطبيق مترو من قبل Sun و Microsoft لاختبار Interop:http://weblogs.java.net/blog/aroldcarr/archive/2007/11/motro_web_servi.html.

آسف لا أدنى فكرة عن الاستيراد الناتج عن WCF تعريف المخطط.

Answer 3

أنا عميق في التشغيل البيني جافا و WCF. كما قال شخص آخر، عليك أن تتسطح WSDL الخاص بك إذا كنت تعمل مع ملف WSDL المستند إلى الملفات. ومع ذلك، استخدم Netbeans 6.5 وإذا أشرت إلى عنوان URL الحقيقي مثل http: // myservice /؟ WSDL ، يمكن للشبارك التعامل بسهولة مع WSDL الافتراضي الذي تم إنشاؤه بواسطة WCF. في الحياة الحقيقية أشياء أخرى تحتاج إلى مراعاةها هي إصدار الخدمة، Datamembers اختياري (لا تسير على ما يرام في Java، لذلك أقترح جعل جميع Datamembers isrequired = True)، النظام وما إلى ذلك.

الشيء الصعب الحقيقي للحصول على الذهاب الأمن. اضطررت إلى جعل مصادقة الشهادة المتبادلة تعمل ولا يزال لها بعض المشكلات.

Answer 4

الطريقة الوحيدة لعميل Java الخاص بك للتحدث مع مكون WCF ستكون واحدة من أساليب HTTP - BasichTTPGinding، WS *، وما إلى ذلك تماما كما توصي MS. لا يمكن ل Java التحدث إلى WCF عبر TCP أو NARTPIPES أو MSMQ، إلخ.

سأبدأ مع مكون WCF بسيط للغاية - شيء به طريقة واحدة يبصق السلسلة. الحصول على هذا العمل مع جافا ثم العمل في طريقك. تأكد من أن كل شيء تعرضه يعمل مع أنواع أساسية أو كائنات [DataContract] المعرفة جيدا.

Answer 5

المشكلة مع XSD: الاستيراد شائع جدا. لا يمكن أن تعامل بعض أدوات الأدوات أو الجريدة التعامل مع ذلك. لمعالجة هذا، يمكنك تسوية WSDL التي يتم إنشاؤها بواسطة WCF. يفحص هذا المشنور.

فيما يتعلق بما إذا كان CXF هو مكدس Java الصحيح - لم أسمع عنه أبدا؟ لقد استخدمت المحور بنجاح، وكذلك JAX-WS. كلاهما كان واضحا جدا.

Answer 6

هذه مشكلة Jaxb. ركضت في نفس المشكلة ولكنها تستخدم خيار XMLBeans بدلا من ذلك في جيل العميل WSDL2JAVA. أن نكون صادقين، يبدو أنني أفضل كائنات XMLBeans أكثر عبر Jaxb بقدر المستهلك إلى هذا Webservice.