SOAP Webservice in Delphi?

[Bernhard Geyer]

Zitat von Elrond:

Aktuell handhabe ich das auch so, das ganze erzeugt aber eine unnötige Komplexität und die Kunden sind auch nicht begeistert warum jetzt noch Java/.net mitgeliefert wird.

Net ist doch eh auf jedem Windows-Rechner drauf.
Aber müsste nicht Windows einen Importer haben, um aus einer SOAP-Schnittstelle ein COM-Interface zu erstellen das du dann nutzen kannst.
Leider kann ich dir keine weitern Infos dazu geben, da im Delphi-Umfeld mir SOAP seit langen nicht mehr begegnet ist (Hätte es vor Jahren mal gebraucht - hat sich dann aber anderweitig erledigt)

Zitat von Elrond:

Für mich ist das wieder ein weiterer Sargnagel für Delphi.

Wohl eher ein Sarg-Nägelchen.
Viele Firmen verlassen den SOAP-Weg (u.a. wegen der Komplexität u.a. bei Sicherheitsanforderungen) und wechseln auf REST/JSON und Co.
Schau mal nach ob es für deine Anforderung auch diese moderner Schnittstelle gibt?

Zitat von Elrond:

In den letzten Tagen habe ich noch die Clever Internet Suite ausprobiert.

Probier auch mal die IPWorks-Komponenten aus: http://cdn.nsoftware.com/help/IP9/dlp/SOAP.htm
Wir setzen von IPWorks die Komponenten für http(s)/ftp(s) ein und sind sehr zufrieden damit.

[Elrond]

Zitat von Bernhard Geyer:

Zitat von Elrond:

Für mich ist das wieder ein weiterer Sargnagel für Delphi.

Wohl eher ein Sarg-Nägelchen.
Viele Firmen verlassen den SOAP-Weg (u.a. wegen der Komplexität u.a. bei Sicherheitsanforderungen) und wechseln auf REST/JSON und Co.
Schau mal nach ob es für deine Anforderung auch diese moderner Schnittstelle gibt?

Deine Aussage erscheint mir widersprüchlich, die Firmen verwenden kein SOAP mehr aufgrund der Komplexität bei den Sicherheitsanforderungen. Soweit ich weiß bietet REST aber überhaupt keine einheitliche Sicherheitsanforderungen. In der WSDL steht beschrieben wie die Signatur und Verschlüsselung der Inhaltsdaten zu erfolgen hat, für REST existiert meines Wissens nach sowas überhaupt nicht. Damit könnte jeder REST Service sein eigenes Süppchen kochen, was die Komplexität enorm steigern würde. Eher benötigen die meisten Webservices nicht mehr als eine Transportverschlüsselung und dafür wäre SOAP zu viel.

Zitat von Bernhard Geyer:

Zitat von Elrond:

In den letzten Tagen habe ich noch die Clever Internet Suite ausprobiert.

Probier auch mal die IPWorks-Komponenten aus: http://cdn.nsoftware.com/help/IP9/dlp/SOAP.htm
Wir setzen von IPWorks die Komponenten für http(s)/ftp(s) ein und sind sehr zufrieden damit.

Danke, werde ich mir anschauen.

[Bernhard Geyer]

Zitat von Elrond:

Deine Aussage erscheint mir widersprüchlich, die Firmen verwenden kein SOAP mehr aufgrund der Komplexität bei den Sicherheitsanforderungen. Soweit ich weiß bietet REST aber überhaupt keine einheitliche Sicherheitsanforderungen. In der WSDL steht beschrieben wie die Signatur und Verschlüsselung der Inhaltsdaten zu erfolgen hat, für REST existiert meines Wissens nach sowas überhaupt nicht. Damit könnte jeder REST Service sein eigenes Süppchen kochen, was die Komplexität enorm steigern würde. Eher benötigen die meisten Webservices nicht mehr als eine Transportverschlüsselung und dafür wäre SOAP zu viel.

Bei JSON/REST brauch ich keine in JSON/REST implementierte Sicherheitslösung/Spezifikation. Ich nehme einfach das, was es schon seit Jahrzehnten gibe.
Ich Ruf eine URL auf und ob ich diese Aufruf erlaubt ist wird außerhalb meiner JSON/REST-Schnittstelle gelöst. Ich kann mich voll und ganz auf die eigene Logik konzentrieren.
Und solche Security-Lösung auf URL-Basis gibt es wie Sand am Meer.

[Elrond]

Zitat von Bernhard Geyer:

Zitat von Elrond:

Deine Aussage erscheint mir widersprüchlich, die Firmen verwenden kein SOAP mehr aufgrund der Komplexität bei den Sicherheitsanforderungen. Soweit ich weiß bietet REST aber überhaupt keine einheitliche Sicherheitsanforderungen. In der WSDL steht beschrieben wie die Signatur und Verschlüsselung der Inhaltsdaten zu erfolgen hat, für REST existiert meines Wissens nach sowas überhaupt nicht. Damit könnte jeder REST Service sein eigenes Süppchen kochen, was die Komplexität enorm steigern würde. Eher benötigen die meisten Webservices nicht mehr als eine Transportverschlüsselung und dafür wäre SOAP zu viel.

Bei JSON/REST brauch ich keine in JSON/REST implementierte Sicherheitslösung/Spezifikation. Ich nehme einfach das, was es schon seit Jahrzehnten gibe.
Ich Ruf eine URL auf und ob ich diese Aufruf erlaubt ist wird außerhalb meiner JSON/REST-Schnittstelle gelöst. Ich kann mich voll und ganz auf die eigene Logik konzentrieren.
Und solche Security-Lösung auf URL-Basis gibt es wie Sand am Meer.

Irgendwie kann ich dir nicht ganz folgen, was gibt es bereits seit Jahrzehnten und warum ist es besser auf eine einheitliche Spezifikation zu verzichten? Wenn ich mich in meiner Anwendung auch noch um die Validität und Authentizität der Nachricht kümmern muss, dann ist es für mich das gegenteil von ganz auf die eigene Businesslogik zu konzentrieren. In SOAP ist dieses Verfahren genau spezifiziert und idealerweise kümmert sich ein Framework um alles weitere, auch sind die Anforderungen jeden Teilnehmer klar. Da REST zu diesen Thema keine Vorgaben macht (ist ja eigentlich mehr eine Architektur, darunter kann ich auch einfach SOAP Nachrichten verschicken) steigt die Komplexität. Der eine Service verwendeten den Standard X, der andere verwendet eine Eigenentwicklung usw.

[Bernhard Geyer]

Zitat von Elrond:

Irgendwie kann ich dir nicht ganz folgen, was gibt es bereits seit Jahrzehnten

z.b. Http Basic Authentication (über https)
Cookies and session management
Token in HTTP headers (z.B. OAuth 2.0)

Zitat von Elrond:

und warum ist es besser auf eine einheitliche Spezifikation zu verzichten?

Es wird doch nicht auf eine einheitliche Spezifikation verzichtet. Es wird halt einfach eingenommen die schon (teilweise) schon sehr lange existiert.

Zitat von Elrond:

Wenn ich mich in meiner Anwendung auch noch um die Validität und Authentizität der Nachricht kümmern muss,

Musst du nicht. Diese ist letztendlich komplett außen vor. In Delphi sind über die Jahre für die ganzen schon existierenden Verfahren (wie OAuth) Komponenten dazu gekommen, so das der Implementierungsaufwand sehr überschaubar wird.

Zitat von Elrond:

In SOAP ist dieses Verfahren genau spezifiziert

Vermutlich Leitet auch SOAP über ein Art Überspezifikation. Statt etwas zu verwenden das es schon gibt meint man es in SOAP neu erfinden zu müssen.

Zitat von Elrond:

und idealerweise kümmert sich ein Framework um alles weitere, auch sind die Anforderungen jeden Teilnehmer klar.

Dann nimm doch so ein Framework. Bei Delphi/Emba wird es in diesem Bereich sehr wahrscheinlich keine Erweiterungen geben. Dazu ist SOAP hinter JSON/REST und Co. mittlerweile relativ unbedeutend geworden ist. Die Zukunft ist JSON/REST. SOAP ist mittlerweilen (fast) CORBA 2.0 zu nennen.
Evtl. ist auch der Schlusssatz in diesem Heise-Artikel ganz gut

Zitat von Elrond:

Da REST zu diesen Thema keine Vorgaben macht (ist ja eigentlich mehr eine Architektur, darunter kann ich auch einfach SOAP Nachrichten verschicken) steigt die Komplexität.

Klar kannst du über normale http-Abfragen auch SOAP-Nachrichten verschicken.
Du kannst dich aber auch gleich ins Knie schießen. Kommt aufs gleiche raus.

Zitat von Elrond:

Der eine Service verwendeten den Standard X, der andere verwendet eine Eigenentwicklung usw.

Nö. Passiert eigentlich nicht. Es gibt eine Hand voll Standards die man Einsetzen kann. Aber den Aufwand einer Eigenentwicklung wird sich keiner antun.

[EmWieMichael]

Elrond, hast Du diesen Thread, insbesondere Seite 3, gesehen. Funktioniert bei mir seit Jahren einwandfrei im gesicherten Deutschland-Online-Netz (DOI), mit Client-Zertifikaten.
Vielleicht hilfts Dir...

[Elrond]

@MichaelT

Ein Interessanter Einblick, auch kommen mir einige Punkte bekannt vor.

Zitat von Bernhard Geyer:

Zitat von Elrond:

Irgendwie kann ich dir nicht ganz folgen, was gibt es bereits seit Jahrzehnten

z.b. Http Basic Authentication (über https)
Cookies and session management
Token in HTTP headers (z.B. OAuth 2.0)

Wir reden grad aneinander Vorbei, du bezieht sich die ganze Zeit auf den Transportweg und ich auf den Inhalt. Die WSS-Spezifikation beschreibt nicht nur wie der Transport zu erfolgen hat sondern auch die Anforderungen an den Inhalt. Die Validität und Authentizität der Nachricht ist auch nach den Empfang gegeben, Beispielsweise während einer internen Weiterleitung und nur der Leser hat Zugriff auf den Inhalt. Soweit ich weiß gibt es in REST so etwas nicht, da der Inhalt unabhängig ist, es ist wie soll ich sagen eine rein technische Schnittstelle.

[Bernhard Geyer]

Zitat von Elrond:

Die WSS-Spezifikation beschreibt nicht nur wie der Transport zu erfolgen hat sondern auch die Anforderungen an den Inhalt.

Und welche Teile davon? Und wann ist das IRL (in Real Live) relevant?
Für Viele Anwendungsfälle ist das einfach überspezifiziert.

Zitat von Elrond:

Die Validität und Authentizität der Nachricht ist auch nach den Empfang gegeben,

Was genau davon? Wenn ich ein Nachricht per https verschicke (und die Verschlüsselung/Sicheheit durch lokale Firewalls/Virenscanner kaputt gemacht wurde ist die Authentizität gegeben.
Jetzt wäre die Frage was du mit Validität genau meinst?

Zitat von Elrond:

Beispielsweise während einer internen Weiterleitung

Jetzt mal konkret. Was soll hier wie kaputt gemacht werden/gefälscht werden.

Zitat von Elrond:

und nur der Leser hat Zugriff auf den Inhalt.

Solange du keine Transportverschlüsselung aktiv hast kann jeder den Inhalt lesen

Zitat von Elrond:

Soweit ich weiß gibt es in REST so etwas nicht

Ich denke das was du bisher angesprochen hast wird von (fast) keinen vermisst.