Interakcja WCF z webservices Java wydaje się zaskakująco problematyczna. Jakieś dobre zasoby?

W ramach ostatniego projektu nasz zespół deweloperów oparty na .Net otrzymał zadanie integracji z całym szeregiem serwisów internetowych opartych na Javie na całym świecie i naprawdę mieliśmy zaskakująco (cóż, z pewnością nie jesteśmy zaskoczeni) dużą liczbę problemów ponieważ XML wygenerowany przez WCF nie jest akceptowany przez usługi Java.

Wydaje się również, że tak naprawdę nie ma zbyt wielu dobrych informacji na ten temat, otrzymaliśmy kilka dobrych wskazówek z doskonałego bloga WCF Yarona Nave'a, http://webservices20.blogspot.com , a także na forum MSDN WCF http: //social.msdn.microsoft.com/Forums/en-US/wcf/threads .

Czy jest tu ktoś, kto naprawdę czuje, że to zrozumiał, i zna ostateczne zasoby na ten temat? Byłbym zainteresowany poradami na temat książek, blogów lub jakichkolwiek stron internetowych.

Edycja:
Jestem rozdarty przy ustawianiu odpowiedzi akceptowanej w tym wątku, ponieważ każda z dwóch najlepszych odpowiedzi ma pewną wartość:
1. Prawdopodobnie skończymy z wdrażaniem większej liczby implementacji HTTP HTTP zamiast walczyć z WCF.
2. Ale WCF Express Interop Bindings 1.0 był również bardzo sensowną wskazówką.

Ach tak ... MYDŁO, nawiedzony święty graal komputerów. Lingua franca, która obiecała współpracę między systemami na całym świecie.

Następnie przechodzisz do różnic między implementacjami SOAP w Javie, PHP i .NET. Lub nawet między usługą WebSphere SOAP a klientem Apache SOAP. Nie wspominając o różnych standardach kompatybilności WS-I. Teraz powiedz mi, dlaczego potrzebujesz standardu kompatybilności dla protokołu zbudowanego dla kompatybilności , mów o ironii (i mam na myśli prawdziwą ironię, a nie ironię marki Alanis Morrissette ).

Jedyny raz, kiedy nie napotkasz problemów z uzyskaniem komunikacji z dwoma punktami końcowymi SOAP, to kiedy oba znajdują się na tej samej platformie iw większości przypadków platforma będzie miała bardziej wydajny protokół zdalnej obsługi.

Mówię tutaj, że w większości przypadków SOAP jest bezużyteczne. Teraz małe mydło, używam go codziennie i jestem wdzięczny, że większość ludzi robi to samo.

Biorąc to pod uwagę, jeśli nalegasz na uderzenie głową o ścianę z cegieł. Oto dobre miejsce na rozpoczęcie Microsoft ma zestaw powiązań, które umożliwiają interopację z większością głównych serwerów Java. Zabawną częścią jest oczywiście sprawdzenie, które z nich współpracują z usługami, które integrujesz.

Moim zdaniem twoja obserwacja jest dość dokładna. Implementacje wysokiego poziomu komunikacji opartej na XML zwykle nie są kompatybilne z różnymi platformami, nawet jeśli oba są nazywane „SOAP”. Subtelne różnice we wdrożeniu, prawdopodobnie zarówno w zakresie wdrożonego standardu, powodują problemy w rzeczywistym użytkowaniu.

Moja rada dla dostawców usług: używaj prostej implementacji zamiast bardzo złożonej i teoretycznie lepszej implementacji. Na przykład nie dołączaj żadnych bardzo złożonych schematów uwierzytelniania, jeśli ich nie potrzebujesz.

Moja rekomendacja dla usługobiorców (zakładam, że): komunikując się z implementacją wysokiego poziomu na innej platformie niż Twoja, degraduj do implementacji niższego poziomu. Nagle staje się to dość proste, jeśli po prostu zorientujesz się, jaki jest rzeczywisty kod XML do wysłania, a następnie użyjesz normalnych dobrych praktyk kodowania, aby to osiągnąć, jako alternatywę dla nalegania na użycie implementacji wysokiego poziomu własnej platformy.

Mam nadzieję, że to nie było zbyt abstrakcyjne. Krótko mówiąc , gdy jesteś na platformie .NET łączącej się z platformą Java, możesz po prostu złożyć nagłówki i plik xml w HttpWebRequest i wysłać go w ten sposób.

Będziesz miał te same problemy z korzystaniem z usług sieciowych PHP.

Naszą jedyną odpowiedzią na to było zmiana typu protokołu na REST zamiast SOAP. Nigdy nie udało nam się współpracować z SOAP, tyle tylko dla Simple!