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.
Hallo Zusammen,
ich versuche mich aktuell an der Implementierung eines
SOAP Clients in Delphi.