Інтерроп WCF до Java для веб-сервісів здається напрочуд проблематичним. Якісь хороші ресурси?

З недавнього проекту наша команда розробників .Net отримала завдання інтегруватись із цілим рядом веб-сервісів на базі java по всьому світу, і ми насправді мали напрочуд (ну ми вже точно не дивуємось) великій кількості питань оскільки XML, створений WCF, службами Java не приймається.

Також здається, що насправді не так багато корисної інформації можна знайти в цьому питанні, ми отримали кілька хороших порад з чудового блогу WCF Yaron Nave, http://webservices20.blogspot.com , а також на форумі MSDN WCF http: //social.msdn.microsoft.com/Forums/en-US/wcf/threads .

Чи є тут хтось, хто насправді відчуває, що вони це знищили, і знає остаточний ресурс з цього питання? Були б цікаві поради щодо книг, блогів чи будь-яких веб-сайтів.

Редагувати:
Я налаштований на налаштування відповіді, прийнятої в цій темі, тому що кожен з двох найкращих відповідей має деяке значення:
1. Ми, мабуть, закінчимося робити більше реалізацій HTTP Webrequest замість боротьби з WCF.
2. Але WCF Express Interop Bindings 1.0 також був дуже розумним підказом.

Ага так ... SOAP, хвалений святий граал обчислень. Лінгва франка, яка обіцяла взаємодію між системами по всьому світу.

І тоді ви потрапляєте у відмінності між реалізаціями SOAP на Java та PHP та .NET. Або навіть між службою WebSphere SOAP та клієнтом Apache SOAP. Неважливо мати справу з різними стандартами сумісності WS-I. Тепер, скажіть, будь ласка, навіщо вам потрібен стандарт сумісності для протоколу, який був побудований для сумісності , поговоріть про іронію (і я маю на увазі справжню іронію, а не бренд іронії Alanis Morrissette ).

Єдиний раз, коли ви не зіткнетеся з проблемами отримання двох комунікаційних кінцевих точок SOAP - це коли вони знаходяться на одній платформі, і в більшості випадків платформа матиме більш ефективний протокол віддаленої роботи.

Я говорю тут, що здебільшого SOAP марний. Зараз мило нижнього регістру я використовую щодня і я вдячний, що більшість людей робить те саме.

Це сказано, якщо ви наполягаєте на тому, щоб бити головою об цегляну стіну. Ось гарне місце для запуску Microsoft має набір прив’язок, що дозволяє взаємодіяти з більшістю основних серверів Java. Найцікавіше, звичайно, - з’ясувати, які з них працюють, із якими послугами ви інтегруєтесь.

На мою думку, ваше спостереження досить точне. Реалізації високого рівня на основі XML зв'язку, як правило , не сумісні з різними платформами, навіть якщо вони будуть так званими «SOAP». Тонкі відмінності у впровадженні, ймовірно, як в рамках стандарту, що впроваджується, створюють проблеми в реальному житті.

Моя рекомендація для постачальників послуг: Використовуйте просту реалізацію, а не дуже складну та теоретично кращу реалізацію. Наприклад, не включайте надзвичайно складні схеми аутентифікації, якщо вони вам не потрібні.

Моя рекомендація для споживачів послуг (ви, я припускаю): Коли ви повідомляєте про реалізацію високого рівня на іншій платформі, ніж ваша, перейдіть до рівня нижчого рівня. Це раптом стає досить простим, якщо ви просто зрозумієте, що таке фактичний XML для надсилання, а потім використаєте звичайні добрі практики кодування, щоб досягти цього, як альтернативу наполягати на застосуванні на високому рівні власної платформи.

Сподіваюся, це було не надто абстрактно. Коротше кажучи , коли ви перебуваєте на платформі .NET, що підключається до платформи Java, ви можете просто зібрати заголовки та xml у HttpWebRequest та відправити їх таким чином.

У вас будуть ті ж проблеми, що і веб-сервіси PHP.

Нашою єдиною відповіддю на це було змінити тип протоколу на REST, а не SOAP. У нас ніколи не було взаємодії з SOAP, настільки просто для Simple!