SOAP Webservice in Delphi?

[Elrond]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389750)

Zitat:

Zitat von Elrond (Beitrag 1389740)

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:

Zitat von Bernhard Geyer (Beitrag 1389750)

Zitat:

Zitat von Elrond (Beitrag 1389740)

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.

[MichaelT]

Delphi kann mit MTOM und WS* praktisch nicht wirklich umgehen, nicht out of the box.

Jo mei. Im Prinzip haben sich MS und SUN auf den Standard in eher trauter Zweisamkeit geeinigt. Es ist deren Zeug und geht uns mal prinzipiell nichts an.

Integrationsschnittstellen und damit verbundene Technologien gibt es zum Säuefüttern. Ich hätte mal kein Problem damit, dass ich ein .net oder Java Artefakt mitausliefere. Kommt aus dieser Welt, gehört in die Welt.

Musst du halt ausprogrammieren und grad im Umfeld von SOAP wurde dieses 'Ausprogrammieren' eher seitens der Werkzeuge am Ende durch Generierung unterstützt. Dafür brauchst du eine eigene Variante von Eclipse (Add-In) für jeden Schas, das ist die Kehrseite.

WS* hat eigentlich nur genervt und tut es heute auch noch.

Der SOAP Service allein ist in dem Technologiewulst noch nicht genug. Das geht viel weiter in diese absurden Konstrukte von verschachtelten XML Schema Definitionen, XSLT usw... Es haben viele Leute irgendetwas zur Praxis erhoben, das so nicht gemeint war.

Auf eine Third-Party Lösung wirst du zurückgreifen müssen in deinem Fall. Es ist vermutlich der pragmatischere Zugang.

Nicht falsch verstehen. Man kann nicht hergehen und jede vorstellbare Abhängigkeit welche nicht konsequent befriedigt wird in Richtung eines 'Delphi kann nix' auslegen.

Delphi ist in dem Umfeld XML/Java like ergänzt um .net WCF welches selbst seitens Java nicht mehr in letzter Konsequenz unterstützt nicht recht berühmt aufgestellt. In der Praxis gibt es die Ebene Infrastruktur die eigentlich solche Probleme sollte handeln. Die Realität schaut mal so aus, dass eine Applikation sich mit der Vermittlung von Nachrichten nicht hat anzupatzen. Es hat sich allein im Umfeld von Windows und Applikation dies eingebürgert.

Man kann auch die Kenntnis der Facebook API als Kompetenz ansehen, aber sobald nur genug solche Schnittstellen da sind, ändert sich die Sicht eher auf vergebene Liebesmüh.

Zitat:

Zitat von Elrond (Beitrag 1389269)

Hallo Zusammen,
ich versuche mich aktuell an der Implementierung eines SOAP Clients in Delphi.

[Bernhard Geyer]

Zitat:

Zitat von Elrond (Beitrag 1389760)

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:

Zitat von Bernhard Geyer (Beitrag 1389768)

Zitat:

Zitat von Elrond (Beitrag 1389760)

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.

[MichaelT]

Prinzipiell kommt mal die 'Message' Philosophie aus der U.S. Logistik. Bspw. war der Message Broker ein Unternehmenstyp welcher alle Message in Empfang genommen hat, zumeist konvertiert hat und hernach weiterversandt.


Als ein Relikt blieb die EAI Idee.

Ich persönlich habe mal probiert die EAI Patterns inkl laufendem Server Environment umzusetzen und ehrlich, es ist zuviel 'Hockn' (österr. für Arbeit). Das entschuldigt zwar nicht die Abwesenheit dieser Funktionalität in Delphi, ... Weise Voraussicht war nicht der Treiben, aber es war schon zu Zeiten von Delphi 7 REST stammt aus 2000 und SOAP 1.0 und 1.1 waren damals noch aktuell. Borland hatte damals eher REST im Foku und möglw. .net im Focus mit Delphi 2005. Vermutung meinerseits.

Weswegen auch im Falle von SOAP ein SOAP Proxy habe mir zu Gemüte und der aus Deutschen Landen von Thomas Bayer ist bis heute noch immer die erste Wahl. Membrane EAI

Ehre wem Ehre gebührt.

Ich habe damals auch alle möglichen und gängigen auf Java aufbauenden Stacks inkl. deren Erweiterungen mit ins Kalkül aufgenommen und dann wird die Sache schon massiv aufwendig. Eine WSDL ist eine Sache und ob ein Feld optional oder zwingend hängt stark von der Serverseite ab. SAP sofern der Server in ABAP implementiert pfeift sich auf dem Eck exakt gar nichts. Mittlerweile ist der externe RFC Server und der gepufferte RFC für so manchen Methodenaufruf schon wieder eine wesentlich praktikablere Option.

Leider hat die inkonsequente Umsetzung dazu geführt, dass eine saubere Defintion einer WSDL in der Praxis ad absurdum wurde geführt.

Damit muss man die Messages wieder 'mit der Hand' anpassen.

Es hat sich allein herausgestellt, dass die ursprüngliche Vision der User mapped die Nachrichten selbst ins kanonische Unternehmensmodell (sofern so eines überhaupt existiert) in Ermangelung von Werkzeugen defakto nicht praktikabel ist. Damit wurde auf einmal wieder die Programmierung interessant. Der Trend ist eher bezogen auf WS* eher neu (wenn auch schon lange her). CAMEL Umfeld ...

Weites hat sich in der Praxis (nicht nur bei einem Kollegen in dessen Company) gezeigt, wenn der Client nicht auf einem Knopfdruck generiert wird fällt die Akzeptanz relativ schnell grad auch beim Programmierer. Ergänzt wurde das ganze noch um den Java Debugger welcher dann erlaube die Nachrichten zu debuggen.

Das alles ewig auf Stand halten ... und dann geht wieder einer auf einen andere Backentechnologie und es fehlt ein Stück vom Glück. Davon mal abgesehen hinkt man noch weiter hinterher als eh schon jetzt und so wechselfreudig sind die Infrastrukturbetreiber in dem Umfeld auch nicht mehr. Man muss ewig und 3 Tage mit Gott und der Welt kompatibel bleiben.

Alles andere bewegt sich stark in Richtung REST oder ähnlich gelagerten Alternativen wie als ein Beispiel unter einer Myriade erwähnt.

macchina.io im IoT Umfeld als ein Beispiel aus Kärnten.


Ewig und 3 Tage bleibt die Legacy eine Plage und die Kompatibilität wird eher über Infrastruktur am Leben gehalten. Im großen Bild ist eher eine der Infrastruktur nahe Lösung wahrscheinlicher.

Wenn ich von dem Bild ausgehe hätte einerseits kein Problem weder mit Third-Party noch mit jvm oder .net verwandten ausgelieferten Artfakten. Es wird in Europa halt noch dauern bis die Einsicht kommt, dass nicht jede Applikation mit jedem Backend können kann. Im Moment haben die kleinen Unternehmen bspw. aus dem Automotive Umfeld eine normierte Schnittstelle, aber nichts desto trotz schicken die ERP und 'WAWI' Software Hersteller allesamt auf ein Backend bei einem Message Broker der diese Nachrichten im Rahmen von Infrastruktur handelt.

Ich habe gearbeitet in einem E-Fullfillment Center in Los Angeles und dort habe ich zumindest mitbekommen was die tatsächlichen Probleme damals waren. Wenn mal die Trucks kommen zum Lagerhaus, ausladen auf einem Ende und am anderen wieder ein. Dazwischen werden ein paar Zehntausend Päckchen bis zu einer Mio. Pakete (Päckchen) mit eigenen Aufklebern werden versehen und wenn das Pickerl drauf ist, knattert eine Message raus übers Netz, dann sind wir eher in der Realität von dem was kommt. Ein paar hunderttausend mal ein paar Cent läppert sich :-D. Das war/ist das Geschäft der Message Broker und Converter.

Ich persönlich sehr Delphi und auch SOAP in dem Umfeld eher bedingt.

Ich selbst habe dann noch mit dem 4Tier Open-Mom Message Broker experimentiert usw... Ging, aber war ein wenig zu bald. Messages zu konvertieren war auch schon damals eine Python Domäne.

Mit dem Ansatz trenne die Applikation vom Message Routing selbst und meine Uni-Kollege mit seiner Company auf Dauer wesentlich besser gefahren.

Das mal Abseits der SOAP Frage ... allein da das Thema gut passt.

Zitat:

Zitat von Elrond (Beitrag 1389269)

Hallo Zusammen,

ich versuche mich aktuell an der Implementierung eines SOAP Clients in Delphi.

[Bernhard Geyer]

Zitat:

Zitat von Elrond (Beitrag 1389774)

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:

Zitat von Elrond (Beitrag 1389774)

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:

Zitat von Elrond (Beitrag 1389774)

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:

Zitat von Elrond (Beitrag 1389774)

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:

Zitat von Elrond (Beitrag 1389774)

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:

Zitat von Elrond (Beitrag 1389774)

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:

Zitat von Elrond (Beitrag 1389774)

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

:gruebel: 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:

Zitat von Bernhard Geyer (Beitrag 1389780)

Zitat:

Zitat von Elrond (Beitrag 1389774)

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:

Zitat von Elrond (Beitrag 1389789)

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:

Zitat von Elrond (Beitrag 1389789)

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:

Zitat von Elrond (Beitrag 1389789)

Beispielsweise während einer internen Weiterleitung

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

Zitat:

Zitat von Elrond (Beitrag 1389789)

und nur der Leser hat Zugriff auf den Inhalt.

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

Zitat:

Zitat von Elrond (Beitrag 1389789)

Soweit ich weiß gibt es in REST so etwas nicht

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

[Elrond]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

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.

Es ist für alle Fälle relevant wo die Transportverschlüsselung nicht mehr ausreicht. Wurde diese ausgehebelt, vielleicht durch eine MITM-Attacke, dann sind die Daten weiterhin geschützt durch ihre eigene Verschlüsselung. Auch eine Mehrfachverschlüsselung kann in Frage kommen um sicherzugehen das alle Leser "anwesend" sind. In meinen konkreten Fall werden sensible personenbezogene Daten übermittelt.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

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?

Das die Nachricht unterwegs nicht verändert wurde.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

Beispielsweise während einer internen Weiterleitung

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

Server (Empfänger) wurde kompromittiert, ist der Leser aber intakt kann die Sicherheit der Nachricht noch gewährleistet werden.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

und nur der Leser hat Zugriff auf den Inhalt.

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

Natürlich sollte die Transportverschlüsselung aktiv sein, aber wenn nicht, dann kann eben nicht jeder den Inhalt lesen, weil der Inhalt verschlüsselt und ggf. noch signiert ist.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1389793)

Zitat:

Zitat von Elrond (Beitrag 1389789)

Soweit ich weiß gibt es in REST so etwas nicht

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

Für die meisten ist es egal, wenn die Sicherheit jedoch solche Forderungen stellt, sieht es anders aus.