Wer nutzt noch Uralttechnik?

[Bizzi]

Ja, bereits langjährige Software ist schwer umzustellen...

Aber es wird sicherlich noch jemand geben der das ganze als neue Basis für Software nutzt, weil man halt eben nichts anderes kennt, es gewohnt ist oder man sich einfach nicht in neuer Materie einlesen will.

Wo wird das ganze überhaupt noch Produktiv genutzt?
Ja, das leidige Thema der Webserver. Aber es ist ja nicht alles Urplötzlich aktiviert, es muss ja einen Grund haben das diverse Methoden im Webserver integriert und enabled sind.

Und wer das ganze als SOAP-Zeugs nutzt, da gibt es sicherlich Alternativen oder etwa nicht? Ich mag da eine Aufklärung, weil ich da gerade etwas auf dem Schlauch stehe :D

[Tigtor]

Bizzi schrieb:
--------------------------------------------------------------------------------
> Ja, bereits langjährige Software ist schwer umzustellen...
>
> Aber es wird sicherlich noch jemand geben der das ganze als neue Basis für
> Software nutzt, weil man halt eben nichts anderes kennt, es gewohnt ist
> oder man sich einfach nicht in neuer Materie einlesen will.
>
> Wo wird das ganze überhaupt noch Produktiv genutzt?
> Ja, das leidige Thema der Webserver. Aber es ist ja nicht alles Urplötzlich
> aktiviert, es muss ja einen Grund haben das diverse Methoden im Webserver
> integriert und enabled sind.
>
> Und wer das ganze als SOAP-Zeugs nutzt, da gibt es sicherlich Alternativen
> oder etwa nicht? Ich mag da eine Aufklärung, weil ich da gerade etwas auf
> dem Schlauch stehe :D

Ich weiß nicht ob Webserver wirklich das ding sind. Generell muss man als weborogrammierer davon ausgehen, dass alles was nicht vom Server selbst kommt potentiell böse ist, dazu gehört auch XML/AJAX, und sollte entsprechend vorsichtig behandelt werden, egal ob verschlüsselt oder nicht.
Für den reinen Datenaustausch wäre XML auch noch eine Option aber hier sehe ich keinen Grund den Webserver direkt zu füttern, dass geht auch über SCP/SSH und dann einen parser drüber laufen lassen.

Wo benutzt man noch XML mit evtl. Verschlüsselungsbedarf?

So dawn goes down to day.
Nothing gold can stay.

[PeterNeter]

Hey,

das kommt alles noch intensiv in der (va. Autombil) Industrie bei Liefervoranmeldungen etc. zum Einsatz, Stichwort EDI: https://de.wikipedia.org/wiki/Elektronischer_Datenaustausch

:-)

[OhYeah]

XML ist voll cool, vor allem bei positionsabhängigen child nodes!

[Anonymer Nutzer]

shibboleth bzw. saml verwenden xml und xml encryption. wird von vielen universitäten als identity provider verwendet.

[derPhiL]

Nehmen wir die Mexikanische Regierung als Beispiel. Jede Rechnung wird via XML authentifiziert bevor der Kunde sie bekommt. Dieses XML ist wie die hier beschriebene Technik teilsigniert.

[Tigtor]

Wieder was gelernt.

So dawn goes down to day.
Nothing gold can stay.

[luckyiam]

Was ist denn mit XÖV? (XML in der öffentlichen Verwaltung)

[ayngush]

Der im ITC (Insurance Trust Center) beheimatete ISTS (Insurance Security Token Service) der TGIC (Trusted German Insurance Cloud) der GDV (Gesamtverband der deutschen Versicherungswirtschaft) basiert auf SAML2 Auth-Tokens (Signierte Challenge-Response, Verschlüsseltes SAML Token).

http://www.gdv.de/2015/10/wie-funktioniert-das-pilotprojekt-maklerkommunikation-4-0/

Ich meine, das ist für Cloud Services auch das aktuelle Standardverfahren.

[NERO]

Bizzi schrieb:
--------------------------------------------------------------------------------
> Und wer das ganze als SOAP-Zeugs nutzt, da gibt es sicherlich Alternativen
> oder etwa nicht? Ich mag da eine Aufklärung, weil ich da gerade etwas auf
> dem Schlauch stehe :D

Die Alternative zu SOAP ist REST. SOAP ist sehr stringend, da klar sein muss, wie Request/Response aufgebaut sind (XML oder JSON ist da nebensächlich, außer das JSON unstrukturiert ist). Bei SOAP kommuniziert man mit dem Webserver ohne zu wissen wo die Daten herkommen. REST hingegen adressiert direkt das Dokument/Asset, wobei die Struktur nicht definiert ist. Ist Ansichtssache was man verwendet. SOAP war ja auch zuerst da, ist aber wie gesagt, recht stringend. Daher gab's dann später REST. Selbst Mark Logic als XML Enterprise DB setzt eher auf REST denn SOAP.

»The sky above the port was the color of television, tuned to a dead channel.«

[1nformatik]

SOAP und damit all die XML Verschlüsselung wird bei Banken und Versicherungen immer noch als Standard eingesetzt. Dies wird auch eine Weile (leider) so bleiben.

Bei SOAP wird durch WS-Security bzw. durch verschiedene XML Signatur Möglichkeiten alles standardisiert, bei REST gibt es einen solchen Standard nicht bzw. es würde unterschiedliche Implementierungen der Signatur geben, bspw. im HTTP-Header, im Body als neuer XML/JSON Knoten, in der URI, ...

Es ist leider nicht alles so hip wie man denkt :(