SOAP Webservice in Delphi?

[Elrond]

Hallo Zusammen,

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

Die wenige offizielle Hilfe von Embarcadero lässt bereits schlimmes vermuten, aber ich bin noch optimistisch das ich einfach die ganze tolle Magie in Delphi noch nicht gefunden habe.

Wie in der Delphi Hilfe steht, habe ich die benötigte WSDL Importiert und die erste Anfrage abgesendet, scheint ja genauso einfach zu sein wie in Java. Leider hat es nicht ansatzweise Funktioniert, die komplette Policy Deklaration der WSDL wurde ignoriert. Weder kam ein Fehler das eine Signatur nicht möglich ist, noch wurde der geforderte Timestamp oder Empfänger hinzugefügt, es war eine einfache nackte Anfrage.

Auf Anhieb habe ich auch keine vorgesehene Möglichkeit gefunden um die benötigten Punkte auszukonfigurieren. Es gibt nur die Basisklasse TSOAPHeader, keine einzige Ableitung davon. Es kann aber doch nicht sein das ich mich jetzt selber darum kümmern muss.

[Sherlock]

Ich hatte bisher keine Probleme mit Delphi als SOAP Client. Welche konkrete Fehlermeldung bekommst Du? Oder was genau geht nicht?

Sherlock

[Elrond]

Zitat von Sherlock:

Ich hatte bisher keine Probleme mit Delphi als SOAP Client. Welche konkrete Fehlermeldung bekommst Du? Oder was genau geht nicht?

Sherlock

Es fehlen alle geforderten SOAP Header. Im Detail fordert die WSDL ws-addressing und zum Teil darauf aufbauend ws-security für die Signatur über den Timestamp- und Empfängerknoten.

[hoika]

Hallo,
zeig uns doch mal die WSDL, Delphi hat in der Tat bei komplizierteren Strukturen Importprobleme.

[Elrond]

Zitat von hoika:

Hallo,
zeig uns doch mal die WSDL, Delphi hat in der Tat bei komplizierteren Strukturen Importprobleme.

Ich kann euch gerne die WSDL zur Verfügung stellen, jedoch denke ich, dass das Problem nichts mit der direkten WSDL zu tun hat.


Es geht um diesen allgemeinen Abschnitt der die Sicherheitsanforderungen des Webservices beschreibt:

Code:

<wsp:Policy>
    <wsp:ExactlyOne>
        <wsp:All>
            <sp:TransportBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <wsp:Policy>
                    <sp:TransportToken>
                        <wsp:Policy>
                            <sp:HttpsToken RequireClientCertificate="false"/>
                        </wsp:Policy>
                    </sp:TransportToken>
                    <sp:AlgorithmSuite>
                        <wsp:Policy>
                            <sp:Basic256/>
                        </wsp:Policy>
                    </sp:AlgorithmSuite>
                    <sp:Layout>
                        <wsp:Policy>
                            <sp:Strict/>
                        </wsp:Policy>
                    </sp:Layout>
                    <sp:IncludeTimestamp/>
                </wsp:Policy>
            </sp:TransportBinding>
            <sp:EndorsingSupportingTokens xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <wsp:Policy>
                    <sp:X509Token
                            sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                        <wsp:Policy>
                            <sp:RequireThumbprintReference/>
                            <sp:WssX509V3Token10/>
                        </wsp:Policy>
                    </sp:X509Token>
                    <sp:SignedParts>
                        <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/>
                    </sp:SignedParts>
                </wsp:Policy>
            </sp:EndorsingSupportingTokens>
            <sp:Wss11 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <wsp:Policy>
                    <sp:MustSupportRefThumbprint/>
                </wsp:Policy>
            </sp:Wss11>
            <sp:Trust10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
                <wsp:Policy>
                    <sp:MustSupportIssuedTokens/>
                    <sp:RequireClientEntropy/>
                    <sp:RequireServerEntropy/>
                </wsp:Policy>
            </sp:Trust10>
            <wsaw:UsingAddressing/>
        </wsp:All>
    </wsp:ExactlyOne>
</wsp:Policy>

Meine Erwartung aus Java und C# wären das mein Client nach den Import der WSDL Datei fast vollständig konfiguriert ist. In diesen Beispiel würde nur noch die Nennung des Signaturzertifikats fehlen.

In Delphi passiert jedoch nichts, es wird kein einziger geforderte SOAP Header mitgeschickt wie z.B. der Timestamp:

Code:

    
<wsu:Timestamp wsu:Id="TS-59e35d1a-97e3-45c0-a6e5-850e107005b4">
    <wsu:Created>2017-12-19T13:57:53.340Z</wsu:Created>
    <wsu:Expires>2017-12-19T14:02:53.340Z</wsu:Expires>
</wsu:Timestamp>

Es geht mir nicht um den SOAP Body, der wird richtig erzeugt.

[Union]

WS-Security wird nicht vom WsdlImporter unterstützt.

[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 von Elrond:

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

[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 . 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 von Elrond:

Hallo Zusammen,

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