Java Webservice mit WCF konsumieren - Welches Binding in der app.config?

Hallo,
ich habe eine Frage zu WCF und Java (ich hoffe hier gibt es auch ein paar Java Experten).
Ich möchte eine Java Webservice mittels WCF .net 4.0 und C# konsumieren. Dazu habe ich mir mittels SVCUTIL die Proxy Klassen und die App.config generieren lassen.
In der App.config, die SVCUTIL erzeugt hat steht basicHttpBinding (siehe unten). Der Kunde sagte mir allerdings, um den Webservice benutzen zu können, muss man **setMaintainSession(true) **(in Java); auf true setzen. Man bekommt also eine Session zugewiesen. BasicHttpBinding unterstützt aber keine Session und **<reliableSession /> **(funktioniert nicht). Da kommt die Fehlermeldung:

Fehlermeldung:
Addressing Version 'AddressingNone (
> )' is not supported.

Kann mir da einer helfen, wie ich die App.Config anpassen muss, damit ich mit diesem System arbeiten kann.

App.Config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="TestWS_wsSoap" />
            </basicHttpBinding>
            <customBinding>
                <binding name="TestWS_wsSoap12">
                    <textMessageEncoding messageVersion="Soap12" />
                    <httpTransport />
                </binding>
            </customBinding>
        </bindings>
        <client>
            <endpoint address="http://Rechner/Webservices.TestWS.asmx"
                binding="basicHttpBinding" bindingConfiguration="TestWS_wsSoap"
                contract="TestWS_wsSoap" name="TestWS_wsSoap" />
            <endpoint address="http://RechnerWebservices.TestWS.asmx"
                binding="customBinding" bindingConfiguration="TestWS_wsSoap12"
                contract="TestWS_wsSoap" name="ManagementWS_wsSoap12" />
        </client>
    </system.serviceModel>
</configuration>

Sieht das hier nach einer Lösung für dein Problem aus? (ich denk schon, bin aber unsicher^^)

http://stackoverflow.com/questions/4598837/wcf-basichttpbinding-400-error

LaTino

Hi,

soweit ich das bis hierhin verstanden hatte macht Java das mit einem Cookie, dass automatisch generierte Klassen wohl schlicht nicht mit machen.

Gemäß http://www.codeproject.com/Articles/35119/Using-Session-State-in-a-Web-Service musst du hierfür dem Service einen CookieContainer verpassen.

LG

Vielen Dank für den Tip!

Ich habe

<binding name="TestWS_wsSoap12" allowCookies="true" />

gesetz, aber leider ohne Erfolg. Ich kann den Service zwar aufrufen, bekomme aber keine "maintain session". Hat noch jemand einen Tip?

Thx ogre

Was hat denn die Entfernung der beiden "überflüssigen" SOAP-Header beim Client gebracht?

LaTino

... was meinst du mit "überflüssigen" Soap Header?

Du kannst hier im Forum viele Aussagen zu Java und WCF finden; dass diese beiden Technologien nicht in allen Ecken kompatibel sind.
Ich selbst hab die Erfahrung gemacht, dass gerade Authentifizierungen von Java and WCF ein grauß sind und dies mit .NET viel einfacher zu handlen ist.

Das ist übrigens ein Mitgrund, wieso WCF bei Technologie-unabhängigen Services wie WebAPIs langsam am Sterben ist und sich echte, Technologie-unabhängige Services auf REST-Basis durchsetzen.
Die Typisierungsfreundlichkeit kann hierbei OData übernehmen.

Die SOAP-Header, die der Javadienst nicht erwartet. Der ist ja laut Fehlermeldung so eingestellt, dass er ws-addressing nicht erlaubt. War mein erstes Posting oben.

LaTino
[EDIT]@Abt: das sehe ich anders. Die Kompatibilitätsprobleme treten zu nahe 100% nur auf, weil die Dienste und Clients unterschiedliche Vorstellungen vom Format der Nachrichten haben. Sind die ausgeräumt, dann funktioniert das einfach. REST eliminiert einfach die Meta-Informationen der Nachrichten durch eine nicht nicht veränderbare Vereinbarung über die Gestaltung der Endpunkte, ist also weniger flexibel. Hier erkauft man sich Kompatibilität mit Flexibilität.

Nö. Das stimmt so gewiss nicht.
REST (u.a. mit OData) ist um Welten, wenn nicht gar Universen flexibler als WCF. Und die Kompatibilität ist ohnehin aufgrund der Natur deutlich höher.

Ich rede von der Form. REST (OData natürlich ebenso) baut darauf auf, den Zugriff auf Ressourcen zu standardisieren, insofern dass pro Ressource ein URI da ist, der dann eben den Zugriff auf diese Ressource regelt. Und das ist eine Einschränkung, die es erlaubt, den riesigen Overhead an Metainformationen abzuwürgen, den du eben brauchst, wenn du für Ressource XY nicht eben eine Adresse zuweisen und dann standardisiert darauf zugreifen kannst. Dass die Inhalte genauso flexibel sind - geschenkt. Aus meiner Sicht war die OData-Initiative nur deshalb notwendig, weil die Konfiguration von nicht-REST-Services mit allem, was daran hängt, viel zu komplex für schnelle Implementierungen ist. Besonders, wenn service und consuming client in unterschiedlichen Händen sind. Das dürfte auch der Grund für den vergleichsweise schnellen Erfolg von OData sein.

Ich halte aber die Einstellung "ach, das ist mir zu kompliziert, dann mach ich es eben RESTful über http" für prinzipiell schädlich.

LaTino

Ich nicht. Ich halte es für den richtigen Weg.

Ich nicht. Ich halte es für den richtigen Weg.

Okay, über Meinung kann man nicht diskutieren, da hast du Recht 😄.

@ogre: Kurzversion war: entferne die Soap-Heaer "To" und "Action" mittels MessageVersion. Und meine Frage war, ob das was gebracht hat (sollte eigentlich).

LaTino

Vielen Dank für die Anregung und Diskussion.
Ich werde mir mal anschauen, wie das funktioniert mit dem "To" und "Action" entfernen.

thx ogre

Ungetestete Lösung:

Binding auf CustomBinding umstellen (natürlich kein leeres, sondern eon CustomBinding, das genau das macht, was dein jetziges Binding macht, dazu kannst du http://webservices20.blogspot.com/ benutzen).

Attribut MessageVersion des Elements textMessageEncoding (genaue Groß- und Kleinschreibung nachschlagen!) auf "Soap12" setzen. Also fast, wie du's schon hattest.

Fertig.

LaTino

.. aber das habe ich doch schon (siehe oben). Oder, fehlt da noch was?

 <customBinding>
   <binding name="TestWS_wsSoap12">
      <textMessageEncoding messageVersion="Soap12" />
      <httpTransport />
   </binding>
</customBinding>

... vielleich kann jemand was mit dem StackTrace anfangen> Fehlermeldung:

at System.ServiceModel.Channels.WsrmIndex.GetActionHeader(AddressingVersion addressingVersion, ReliableMessagingVersion reliableMessagingVersion, String element)
at System.ServiceModel.Channels.ClientReliableSession..ctor(ChannelBase channel, IReliableFactorySettings factory, IClientReliableChannelBinder binder, FaultHelper faultHelper, UniqueId inputID)
at System.ServiceModel.Channels.ReliableRequestSessionChannel..ctor(ChannelManagerBase factory, IReliableFactorySettings settings, IClientReliableChannelBinder binder, FaultHelper faultHelper, LateBoundChannelParameterCollection channelParameters, UniqueId inputID)
at System.ServiceModel.Channels.ReliableChannelFactory2.OnCreateChannel(EndpointAddress address, Uri via) at System.ServiceModel.Channels.ChannelFactoryBase1.InternalCreateChannel(EndpointAddress address, Uri via)
at System.ServiceModel.Channels.ChannelFactoryBase1.CreateChannel(EndpointAddress address, Uri via) at System.ServiceModel.Channels.ServiceChannelFactory.ServiceChannelFactoryOverRequestSession.CreateInnerChannelBinder(EndpointAddress to, Uri via) at System.ServiceModel.Channels.ServiceChannelFactory.CreateServiceChannel(EndpointAddress address, Uri via) at System.ServiceModel.Channels.ServiceChannelFactory.CreateChannel(Type channelType, EndpointAddress address, Uri via) at System.ServiceModel.ChannelFactory1.CreateChannel(EndpointAddress address, Uri via)
at System.ServiceModel.ChannelFactory1.CreateChannel() at System.ServiceModel.ClientBase1.CreateChannel()
at System.ServiceModel.ClientBase1.CreateChannelInternal() at System.ServiceModel.ClientBase1.get_Channel()
at ManagementWS_wsSoapClient.UserLogin(String UserName, String Password)
at WindowsFormsApplication1.Form1.btnLogin_Click(Object sender, EventArgs e)

Oh, Mann....Asche auf mein Haupt, ich hab' dir offenbar den falschen Link gepostet. In dem hier gings eigentlich drum, wie man im Code die Eigenschaften des CustomBindings so ändert, dass der Fehler behoben wird. Wie gesagt, hab's nicht selbst ausprobiert, auch mangels greifbarem Java-Service 😉.

LaTino