imported>SchlurcherBot: Bot: http → https

2026-04-15T18:22:37Z

Bot: http → https

Neue Seite

'''WS-Routing''' ist eine Spezifikation im Bereich der [[Webservice]]-Technologien, die von [[Microsoft]] entwickelt wurde, um die Funktionalität von [[SOAP]] zu erweitern. Sie stellt einen Mechanismus zur Verfügung, der den Pfad einer Nachricht durch mehrere Zwischenstationen in einer Webservice-Architektur definiert. Dies geschieht durch das Hinzufügen eines Routing-[[Header]]s zur SOAP-Nachricht, der Informationen über den Absender, den Empfänger und mögliche Zwischenstationen enthält. Der Hauptzweck von WS-Routing liegt in der Ermöglichung [[Asynchrone Datenübertragung|asynchroner Nachrichtenübermittlung]] in Web-Service-Umgebungen, was besonders für langlebige [[Geschäftsprozess]]e von Bedeutung ist. Die Spezifikation adressiert dabei mehrere Herausforderungen, darunter Transportneutralität, Flexibilität, [[Informationssicherheit|Sicherheit]], [[Interoperabilität]] und Lastverteilung. Trotz seiner Vorteile hat WS-Routing auch einige Herausforderungen und Einschränkungen, wie erhöhte Komplexität und [[Overhead (EDV)|Overhead]]. Im Laufe der Zeit wurde WS-Routing zunehmend durch neuere Standards wie [[WS-Addressing]] abgelöst, die ähnliche Funktionalitäten auf flexiblere Weise bereitstellen.

== Funktionsweise ==
WS-Routing erweitert die Funktionalität von [[SOAP]], indem es einen Mechanismus zur Verfügung stellt, der den Pfad einer Nachricht durch mehrere Zwischenstationen definiert.<ref name="ballinger" /> Dies geschieht durch das Hinzufügen eines [[Routing]]-[[Header]]s zur SOAP-Nachricht. Dieser Header enthält Informationen über den Absender, den Empfänger und mögliche Zwischenstationen, die die Nachricht passieren soll.<ref name="ibm" />

Der Routing-Header besteht aus mehreren Elementen:<ref name="ibm" />
* '''From:''' Gibt den ursprünglichen Absender der Nachricht an.
* '''To:''' Definiert den endgültigen Empfänger der Nachricht.
* '''Via:''' Beschreibt die Zwischenstationen, die die Nachricht passieren soll.
* '''Action:''' Spezifiziert die auszuführende Aktion beim Empfänger.

Jede Station auf dem Weg der Nachricht kann den Routing-Header lesen und entsprechend handeln. Sobald eine Station die Nachricht verarbeitet hat, entfernt sie ihren Eintrag aus dem Via-Element und leitet die Nachricht zur nächsten Station weiter.<ref name="ibm" />

== Zweck ==
Der Hauptzweck von WS-Routing liegt in der Ermöglichung [[Asynchrone Kommunikation|asynchroner Nachrichtenübermittlung]] in [[Webservice|Web-Service]]-Umgebungen. Dies ist besonders wichtig für langlebige [[Geschäftsprozess]]e, die nicht auf sofortige Antworten angewiesen sind. WS-Routing adressiert dabei mehrere Herausforderungen:<ref name="ballinger" />
* '''Transportneutralität:''' WS-Routing ermöglicht die Verwendung verschiedener [[OSI-Modell|Transportprotokolle]] für unterschiedliche Abschnitte des Nachrichtenpfads.<ref name="ballinger" />
* '''Flexibilität:''' Es erlaubt die dynamische Anpassung des Nachrichtenpfads basierend auf den aktuellen Bedingungen im [[Netzwerk]].<ref name="ibm" />
* '''[[Informationssicherheit|Sicherheit]]:''' Durch die Spezifikation des genauen Pfads kann die Sicherheit der [[Nachrichtenübertragung|Nachrichtenübermittlung]] erhöht werden.<ref name="ballinger" />
* '''[[Interoperabilität]]:''' WS-Routing fördert die Zusammenarbeit zwischen verschiedenen Web-Service-Implementierungen, indem es einen standardisierten Mechanismus für die Nachrichtenübermittlung bereitstellt.<ref name="ibm" />
* '''Lastverteilung:''' Das [[Kommunikationsprotokoll|Protokoll]] ermöglicht eine effiziente Verteilung der Last auf verschiedene [[Server]] oder Dienste.<ref name="ballinger" />

== Implementierung ==
Die Implementierung von WS-Routing erfordert die Unterstützung durch die Web-Service-Infrastruktur. Entwickler können WS-Routing-Informationen in ihren [[Jakarta XML Web Services|JAX-WS]]-Anwendungen durch die Verwendung von [[Annotation (Java)|Java-Annotationen]] festlegen. Diese Annotationen ermöglichen es, das [[WS-Addressing]]-Verhalten zur [[Laufzeit (Informatik)|Laufzeit]] zu konfigurieren und spezifische Aktionen für Web-Service-Operationen oder Fehlerantworten zu definieren.<ref name="ibm" />

Beispielsweise kann die Annotation @Addressing verwendet werden, um anzugeben, dass ein Service die WS-Addressing-Unterstützung aktivieren soll. Dies ist ein wichtiger Schritt, da WS-Routing eng mit WS-Addressing verknüpft ist und oft in Kombination verwendet wird.<ref name="ibm" />

== Herausforderungen und Einschränkungen ==
Trotz seiner Vorteile hat WS-Routing auch einige Herausforderungen und Einschränkungen:
* '''Komplexität:''' Die Implementierung von WS-Routing kann die Komplexität von Web-Service-Architekturen erhöhen, insbesondere in großen, verteilten Systemen.<ref name="ballinger" />
* '''[[Overhead (EDV)|Overhead]]:''' Das Hinzufügen von Routing-Informationen zu jeder Nachricht kann zu einem erhöhten [[Datenverkehr]] führen.<ref name="ballinger" />
* '''Standardisierung:''' Obwohl WS-Routing von [[Microsoft]] veröffentlicht wurde, gab es bisher keine Bemühungen, es als offiziellen Standard zu etablieren.
* '''Konkurrenz:''' Andere Spezifikationen wie WS-Addressing, WS-Reliability und WS-Reliable Messaging haben teilweise die Funktionen von WS-Routing übernommen und es damit in gewissem Maße obsolet gemacht.

== Technische Details ==
=== Funktion ===
WS-Routing verwendet einen SOAP-Header namens „path“, um Routing-Informationen für eine Nachricht zu spezifizieren. Dieser Header enthält eine geordnete Liste von Zwischenstationen, die die Nachricht auf ihrem Weg zum Ziel passieren soll. Jede Station in der Liste wird durch einen Eintrag mit einer „to“-Adresse und optional einer „action“ repräsentiert.<ref name="ethz" />

Der Routing-[[Algorithmus]] funktioniert wie folgt:<ref name="ethz" /><ref name="pp" />
# Der Absender erstellt die Nachricht und fügt den „path“-Header mit der Liste der Zwischenstationen hinzu.
# Jede Station auf dem Weg verarbeitet den Header:
## Sie entfernt ihren eigenen Eintrag aus der Liste.
## Sie leitet die Nachricht an die nächste Station in der Liste weiter.
# Die letzte Station in der Liste ist der endgültige Empfänger.

=== Nachrichtenformat ===
Eine typische WS-Routing-Nachricht hat folgende Struktur:
<syntaxhighlight lang="xml">
<S:Envelope xmlns:S="http://www.w3.org/2003/05/soap-envelope">
<S:Header>
<wsa:To>http://example.com/final-destination</wsa:To>
<wsa:Action>http://example.com/some-action</wsa:Action>
<wsa:MessageID>uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff</wsa:MessageID>
<wsrm:path>
<wsrm:hop>
<wsrm:to>http://example.com/intermediary1</wsrm:to>
<wsrm:action>http://example.com/action1</wsrm:action>
</wsrm:hop>
<wsrm:hop>
<wsrm:to>http://example.com/intermediary2</wsrm:to>
</wsrm:hop>
</wsrm:path>
</S:Header>
<S:Body>

</S:Body>
</S:Envelope>
</syntaxhighlight>

In diesem Beispiel wird die Nachricht zunächst an „intermediary1“ gesendet, dann an „intermediary2“ und schließlich an die endgültige Zieladresse.<ref name="ethz" /><ref name="pp" />

=== Sicherheitsaspekte ===
WS-Routing bietet verschiedene Sicherheitsmechanismen:<ref name="ethz" /><ref name="pp" />
* '''[[Digitale Signatur]]en:''' Der gesamte „path“-Header kann digital signiert werden, um [[Integrität (Informationssicherheit)|Integrität]] und [[Authentizität]] sicherzustellen.
* '''[[Verschlüsselung]]:''' Teile der Nachricht oder die gesamte Nachricht können verschlüsselt werden.
* '''[[Zeitstempel]]:''' Ein Zeitstempel kann hinzugefügt werden, um [[Replay-Angriff]]e zu verhindern.

=== Interoperabilität ===
WS-Routing ist [[Kompatibilität (Technik)|kompatibel]] mit anderen Web Services-Spezifikationen wie [[WS-Security]] und [[WS-Reliable Messaging]]. Es kann in Verbindung mit diesen Protokollen verwendet werden, um sichere und zuverlässige Nachrichtenübertragung in verteilten Systemen zu gewährleisten.<ref name="ethz" /><ref name="pp" />

=== Implementierungen ===
Verschiedene [[Framework|Softwareframeworks]] und [[Middleware]]-Plattformen unterstützen WS-Routing, darunter [[Apache Axis#Apache Axis2|Apache Axis2]], [[.Net-Framework|Microsoft .NET Framework]] und [[WebSphere|IBM WebSphere]].

Diese Implementierungen bieten [[Programmierschnittstelle|APIs]] und Konfigurationsmöglichkeiten, um WS-Routing in Anwendungen zu integrieren und Routing-Verhalten anzupassen.<ref name="pp" />

== Vergleich mit anderen Routing-Ansätzen ==
WS-Routing war eine frühe Spezifikation für das Routing von SOAP-Nachrichten in Webservice-Architekturen. Im Laufe der Zeit wurde es jedoch durch neuere Standards wie WS-Addressing abgelöst. Ein Vergleich mit anderen Routing-Ansätzen zeigt die Vor- und Nachteile sowie die Entwicklung in diesem Bereich.

=== Grundlegende Konzepte ===
WS-Routing basierte auf dem Konzept, Routing-Informationen direkt in SOAP-Nachrichten einzubetten. Dazu wurde ein spezieller SOAP-Header verwendet, der den vollständigen Routing-Pfad einer Nachricht enthielt. Dies ermöglichte ein dynamisches Routing auf Anwendungsebene.<ref name="tilkov" />

Im Gegensatz dazu arbeiten traditionelle Netzwerk-Routing-Protokolle wie [[Open Shortest Path First]] (OSPF) oder [[Border Gateway Protocol]] (BGP) auf tieferen Netzwerkschichten. Sie verwenden [[Routingtabelle]]n in den [[Netzwerkknoten]], um [[Datenpaket|Pakete]] weiterzuleiten, ohne den Nachrichteninhalt zu betrachten.<ref name="dargin" />

=== Vergleich mit WS-Addressing ===
WS-Addressing, der Nachfolger von WS-Routing, verfolgt einen etwas anderen Ansatz. Es definiert standardisierte Header-Elemente wie „To“, „From“ und „ReplyTo“, um Adressierungsinformationen in SOAP-Nachrichten zu [[Code|kodieren]]. Im Gegensatz zum vollständigen Routing-Pfad bei WS-Routing enthält WS-Addressing nur Start- und Zieladressen. Dies macht WS-Addressing flexibler, da die konkrete Routing-Entscheidung der Infrastruktur überlassen wird. Allerdings erschwert es auch die Implementierung von komplexen Routing-Szenarien auf [[OSI-Modell|Anwendungsebene]].<ref name="tilkov" />

=== Vor- und Nachteile ===
WS-Routing bot durch die Einbettung des vollständigen Routing-Pfads eine hohe Kontrolle über den [[Nachrichtenfluss]]. Dies ermöglichte beispielsweise die einfache Integration von Zwischenstationen (Intermediaries). Andererseits führte dieser Ansatz zu größeren Nachrichten und erforderte, dass alle Routing-Informationen bereits beim Absender bekannt waren. WS-Addressing ist in dieser Hinsicht schlanker und flexibler.<ref name="tilkov" />

=== Einsatzszenarien ===
WS-Routing eignete sich besonders für Szenarien mit komplexen, vordefinierten Nachrichtenpfaden. Ein Beispiel wären mehrstufige Geschäftsprozesse, bei denen eine Nachricht mehrere Stationen durchlaufen muss.<ref name="tilkov" /> WS-Addressing und modernere Ansätze sind dagegen besser für dynamischere Umgebungen geeignet, in denen sich Endpunkte häufiger ändern können. Sie passen besser zu serviceorientierten und mikroservicebasierten Architekturen.<ref name="ms" />

=== Integration mit anderen Standards ===
Ein wichtiger Aspekt beim Vergleich von Routing-Ansätzen ist ihre Integration mit anderen Web-Service-Standards. WS-Routing war ein eigenständiger Standard, der sich nicht immer nahtlos in andere Spezifikationen einfügte. WS-Addressing wurde dagegen von Anfang an als Teil der [[WS-*]]-Spezifikationsfamilie konzipiert. Es lässt sich dadurch besser mit Standards wie WS-Security oder WS-Reliable Messaging kombinieren.<ref name="tilkov" />

=== Performanz und Skalierbarkeit ===
In Bezug auf [[Rechenleistung|Performanz]] und [[Skalierbarkeit]] haben netzwerkbasierte Routing-Protokolle generell Vorteile gegenüber anwendungsbasierten Ansätzen wie WS-Routing oder WS-Addressing. Sie können Routing-Entscheidungen effizienter treffen und besser mit großen Netzwerken umgehen.<ref name="dargin" /> Allerdings bieten anwendungsbasierte Ansätze mehr Flexibilität und ermöglichen komplexere Routing-Logiken auf höheren Ebenen. Dies kann in bestimmten Szenarien die Performanznachteile aufwiegen.<ref name="ms" />

=== Sicherheitsaspekte ===
Bei der Betrachtung von Sicherheitsaspekten zeigen sich ebenfalls Unterschiede zwischen den Ansätzen. WS-Routing und ähnliche anwendungsbasierte Protokolle machen Routing-Informationen für die Anwendung sichtbar und manipulierbar. Dies kann einerseits zu Sicherheitsrisiken führen, andererseits aber auch feingranulare Sicherheitskontrollen ermöglichen.<ref name="tilkov" /> Netzwerkbasierte Routing-Protokolle sind in dieser Hinsicht robuster, da Routing-Entscheidungen für Anwendungen transparent erfolgen. Allerdings bieten sie weniger Möglichkeiten für anwendungsspezifische Sicherheitsmaßnahmen.<ref name="dargin" />

== Standardisierung und Akzeptanz ==
WS-Routing ist eine Spezifikation im Kontext von Webservices, die von [[Microsoft]] entwickelt wurde. Sie zielt darauf ab, einen konkreten Pfad für SOAP-Nachrichten vorzugeben und somit die Adressierung und Sicherstellung der Nachrichtenübermittlung zu verbessern. Die Standardisierung und Akzeptanz von WS-Routing verlief jedoch nicht reibungslos. Microsoft unternahm keine nennenswerten Anstrengungen, die Spezifikation durch anerkannte Standardisierungsgremien wie das [[World Wide Web Consortium]] (W3C) oder der [[Organization for the Advancement of Structured Information Standards]] (OASIS) standardisieren zu lassen. Dies führte dazu, dass WS-Routing weitgehend als proprietäre Spezifikation betrachtet wurde.<ref name="bsi" />

Im Laufe der Zeit wurden alternative Spezifikationen entwickelt, die ähnliche Funktionalitäten adressierten. Insbesondere WS-Addressing, WS-Reliability und WS-Reliable Messaging gewannen an Bedeutung und machten WS-Routing zunehmend obsolet. Diese Entwicklung zeigt, dass sich in der dynamischen Landschaft der Webservice-Standards oft mehrere konkurrierende Spezifikationen entwickeln, von denen sich letztendlich diejenigen durchsetzen, die eine breitere Unterstützung in der Industrie finden.<ref name="bsi" />

Die mangelnde Standardisierung von WS-Routing hatte Auswirkungen auf seine Akzeptanz in der Entwicklergemeinschaft. In der Praxis bevorzugten viele Entwickler und Unternehmen standardisierte und herstellerübergreifend unterstützte Spezifikationen, um Interoperabilität und langfristige Kompatibilität sicherzustellen.

WS-Routing wurde ursprünglich als Teil einer umfassenderen Strategie von Microsoft im Bereich Webservices konzipiert. Die Spezifikation sollte in Kombination mit [[WS-Referral]] verwendet werden, um erweiterte Routing-Funktionalitäten bereitzustellen. Jedoch konnte sich dieser Ansatz nicht gegen andere, offenere Standards durchsetzen.<ref name="bsi" />

In der Gesamtbetrachtung der WS-*-Spezifikationen wird deutlich, dass die Standardisierung und Akzeptanz einzelner Spezifikationen oft von komplexen Faktoren abhängen. Dazu gehören die Unterstützung durch führende Technologieunternehmen, die Kompatibilität mit bestehenden Systemen und die Fähigkeit, reale Probleme in der Praxis effektiv zu lösen. Trotz der begrenzten Akzeptanz von WS-Routing hat die Spezifikation einen Beitrag zur Entwicklung von Konzepten im Bereich des Nachrichtenroutings in verteilten Systemen geleistet. Einige der in WS-Routing adressierten Problemstellungen fanden Eingang in nachfolgende, breiter akzeptierte Standards.<ref name="bsi" />

== Obsoleszenz und Nachfolger ==
WS-Routing hat im Laufe der Zeit an Bedeutung verloren und wurde durch modernere Technologien ersetzt. Diese Entwicklung lässt sich auf mehrere Faktoren zurückführen, die zur [[Obsoleszenz]] von WS-Routing beigetragen haben.

=== Gründe für die Obsoleszenz ===
Ein wesentlicher Grund für die abnehmende Relevanz von WS-Routing war die Einführung von WS-Addressing. WS-Addressing bietet eine standardisierte Methode zur Paketierung von Routing-Informationen als [[Metadaten]] in SOAP-Headern, anstatt diese Informationen tiefer im Netzwerk zu verwalten. Diese Herangehensweise erwies sich als flexibler und effizienter, insbesondere in komplexen Netzwerkumgebungen. Darüber hinaus trugen die Entwicklungen im Bereich der zuverlässigen Nachrichtenübermittlung zur Verdrängung von WS-Routing bei. WS-Reliable Messaging etablierte sich als Standard für die Fehlerbehandlung zwischen Nachrichten, die über eine unzuverlässige IT-Infrastruktur übertragen werden. Diese Spezifikation bot robustere Lösungen für Szenarien, in denen die zuverlässige Zustellung von Nachrichten kritisch war.<ref name="redhat" />

=== Nachfolgende Technologien ===
Als Nachfolger von WS-Routing haben sich mehrere Technologien und Standards etabliert, die die ursprünglichen Ziele auf effizientere und flexiblere Weise erfüllen.

==== WS-Addressing ====
WS-Addressing hat sich als primärer Ersatz für WS-Routing durchgesetzt. Diese Spezifikation ermöglicht eine präzisere Steuerung des Nachrichtenflusses und eine bessere Integration mit anderen WS-*-Spezifikationen. WS-Addressing bietet Mechanismen zur eindeutigen Identifizierung von Webservice-Endpunkten und zur Übermittlung von Routing-Informationen innerhalb der SOAP-Nachrichten selbst.<ref name="redhat" />

==== REST-basierte Architekturen ====
Mit dem Aufkommen von [[Representational State Transfer]] (REST) als Architekturstil für verteilte Systeme hat sich die Art und Weise, wie Webservices konzipiert und implementiert werden, grundlegend verändert. REST-basierte APIs bieten eine schlankere Alternative zu SOAP-basierten Webservices und haben in vielen Anwendungsbereichen die Oberhand gewonnen. REST-Architekturen zeichnen sich durch ihre [[Zustandslosigkeit]], [[Cache]]barkeit und einheitliche Schnittstellen aus. Diese Eigenschaften machen sie besonders geeignet für moderne Anwendungsszenarien wie das [[Internet der Dinge|Internet of Things]] (IoT), [[Mobile App|mobile Anwendungen]] und [[Serverless Computing]].<ref name="redhat" />

==== Moderne Protokolle und Standards ====
Neben REST haben sich weitere Protokolle und Standards entwickelt, die die Funktionalitäten von WS-Routing in moderneren Kontexten abdecken:
* '''[[gRPC]]:''' Ein von Google entwickeltes [[Open Source|Open-Source]]-RPC-Framework, das auf [[Hypertext Transfer Protocol#HTTP/2|HTTP/2]] basiert und eine effiziente Kommunikation zwischen Diensten ermöglicht.
* '''[[GraphQL]]:''' Eine Abfragesprache für APIs, die es Clients ermöglicht, genau die Daten anzufordern, die sie benötigen, und nichts darüber hinaus.
* '''[[WebSocket]]s:''' Ein Protokoll, das eine [[bidirektional]]e, vollständige Kommunikation über eine einzige [[Transmission Control Protocol|TCP]]-Verbindung ermöglicht und besonders für [[Echtzeit]]-Anwendungen geeignet ist.<ref name="websockets" />

=== Auswirkungen auf die Industrie ===
Die Obsoleszenz von WS-Routing und der Übergang zu neueren Technologien haben signifikante Auswirkungen auf die [[Software-Industrie]]. Unternehmen und Entwickler mussten ihre Ansätze zur Implementierung von Webservices und verteilten Systemen überdenken und anpassen. In modernen Architekturen, insbesondere in [[Microservices]]-Umgebungen, werden Routing-Aufgaben oft von spezialisierten Komponenten wie API-[[Gateway (Informatik)|Gateways]] oder Service-[[Vermaschtes Netz|Meshes]] übernommen. Diese Komponenten bieten fortschrittliche Funktionen wie Lastausgleich, Sicherheit und Überwachung, die weit über die ursprünglichen Fähigkeiten von WS-Routing hinausgehen.<ref name="siemens" />

== Weblinks ==
* [https://msdn.microsoft.com/de-de/library/ms951272.aspx WS-Routing Specification]
* [https://windley.com/archives/2003/02/gxa_components_2.shtml Anschauliche Erklärung von WS-Routing]

== Einzelnachweise ==
<references>
<ref name="ballinger">
{{Internetquelle
|autor=Keith Ballinger
|url=https://www.oreilly.com/library/view/net-web-services/0321113594/ch12.html
|titel=Chapter 12. Messaging with Web Services: WS-Routing, WS-Referral, and DIME
|hrsg=O'Reilly Media
|abruf=2024-11-08}}
</ref>
<ref name="bsi">
{{Internetquelle
|url=https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Download/IT-GS-Bausteine/Webservices/Baustein-Web-Services-B5_24.pdf?__blob=publicationFile
|titel=B 5.24 Web-Services
|hrsg=Bundesamt für Sicherheit in der Informationstechnik (BSI)
|datum=2014
|format=PDF
|abruf=2024-11-08}}
</ref>
<ref name="dargin">
{{Internetquelle
|autor=Mark Dargin, David Jacobs
|url=https://www.computerweekly.com/de/feature/Statisches-versus-dynamisches-Routing-Die-Unterschiede
|titel=Die Unterschiede zwischen statischem und dynamischen Routing
|hrsg=ComputerWeekly.de
|datum=2024-09-08
|abruf=2024-11-08}}
</ref>
<ref name="ethz">
{{Internetquelle
|url=https://vs.inf.ethz.ch/edu/WS0001/VS/Vorl.VNetz00_12.pdf
|titel=Routing (4)
|hrsg=ETH Zurich
|format=PDF
|abruf=2024-11-08}}
</ref>
<ref name="ibm">
{{Internetquelle
|url=https://www.ibm.com/docs/de/was/8.5.5?topic=support-web-services-addressing-annotations
|titel=WS-Addressing-Annotationen
|hrsg=IBM Deutschland
|datum=2024-07-29
|abruf=2024-11-08}}
</ref>
<ref name="ms">
{{Internetquelle
|url=https://learn.microsoft.com/de-de/aspnet/core/fundamentals/routing?view=aspnetcore-8.0
|titel=Routing in ASP.NET Core
|hrsg=Microsoft Corporation
|datum=2024-11-07
|abruf=2024-11-08}}
</ref>
<ref name="pp">
{{Internetquelle
|url=https://pasta.place/ETIT/Wahlbereich/Internet_of_Everything_%5BTM%5D/Folien/WS-17-18/04.2_kommunikation_routing.pdf
|titel=Vorlesung Internet of Everything Wintersemester 2017/18: Kapitel 4.2 – Routing
|hrsg=Pasta Place
|format=PDF
|abruf=2024-11-08}}
</ref>
<ref name="redhat">
{{Internetquelle
|url=https://www.redhat.com/de/topics/integration/whats-the-difference-between-soap-rest
|titel=Was ist SOAP und REST und worin unterscheiden sie sich?
|hrsg=Red Hat
|datum=2024-02-05
|abruf=2024-11-08}}
</ref>
<ref name="siemens">
{{Internetquelle
|url=https://assets.new.siemens.com/siemens/assets/api/uuid:0d03e433-93fa-4d95-920f-700f105e4d46/bs-robuste-kommunikation-fuer-its-de.pdf
|titel=Robuste Kommunikation für intelligente Verkehrssysteme
|hrsg=Siemens
|datum=2017
|format=PDF
|abruf=2024-11-08}}
</ref>
<ref name="tilkov">
{{Internetquelle
|autor=Stefan Tilkov
|url=https://www.innoq.com/blog/st/2005/05/ws-addressing-and-the-next-hop/
|titel=WS-Addressing and the Next Hop
|hrsg=INNOQ
|datum=2005-05-31
|abruf=2024-11-08}}
</ref>
<ref name="websockets">
{{Internetquelle
|url=https://www.studysmarter.de/schule/informatik/webentwicklung/websockets/
|titel=Websockets
|hrsg=StudySmarter
|abruf=2024-11-08}}
</ref>
</references>

[[Kategorie:Webservice]]

WS-Routing - Versionsgeschichte

imported>SchlurcherBot: Bot: http → https