Teil 1: Intuitiver Überblick
Mehrere Konzepte von WebService:
Basierend auf dem HTTP-Protokoll und ausgeführt über XML Framework/Komponenten für die Client-Server-Kommunikation
Zwei wichtige Punkte:
1. Vom Server bereitgestellte Funktionen, beschrieben durch XML
2. Die Im ersten Schritt beschriebene Funktionen sind in das HTTP-Protokoll eingebettet und ermöglichen die Kommunikation über das HTTP-Protokoll [sog. SOAP].
Das Diagramm kann wie folgt dargestellt werden:
Abbildung 1: Kurze Darstellung von WebService
Der Hauptzweck der Verwendung dieser beiden Technologien ist:
1. Plattform können Hosts und Server, die das HTTP-Protokoll unterstützen, Kommunikationsverbindungen herstellen, und die meisten Hosts und Server (mehr als 99,999 %) unterstützen das HTTP-Protokoll. Im Allgemeinen muss die Kommunikation zwischen verschiedenen Zielhosts über eine Firewall erfolgen und einen bestimmten Port öffnen. Der Vorteil des HTTP-Protokolls besteht darin, dass Firewalls im Allgemeinen Port 80 nicht blockieren, sodass die Kommunikation bequem und sicher sein kann.
2. Sprachübergreifend unterstützt jede Sprache die XML-Textanalyse. Der Zweck besteht darin, die Kommunikation zwischen verschiedenen Sprachen zu erreichen Auf diese Weise können Sprachbarrieren überwunden werden, d. h. der Client kann über C auf einen in Java entwickelten Server zugreifen und kann über Java, VB usw. darauf zugreifen und umgekehrt.
Teil Zwei: Grundprinzipien und Architektur
Natürlich ist die Architektur komplexer als das von uns erwähnte Diagramm Aufgrund der Komplexität veranschaulicht das Obige nur die Eins-zu-Eins-Kommunikation. In tatsächlichen Situationen müssen die folgenden Probleme berücksichtigt werden:
1 Dienstleistungen. Registrieren Sie, genau wie bei der Gründung eines Unternehmens (d. h. eines Serveranbieters), die Firmenadresse und -art bei der Industrie- und Handelsverwaltung. Der Zweck besteht darin, dass andere, die die Dienste des Unternehmens in Anspruch nehmen möchten, Ihre Adresse vom Büro für Industrie- und Handelsverwaltung erfahren. Ein solcher einheitlicher Ansatz ist für alle Unternehmen und alle Kunden praktisch, die die vom Unternehmen bereitgestellten Dienstleistungen benötigen. Und diese Informationen werden im größtmöglichen Umfang offengelegt.
2. Der Kunde (Anforderer) geht zum Registrierungszentrum (Registrierung), um die grundlegenden Informationen des Unternehmens zu erhalten, das Unternehmen zu finden und dann die vom Unternehmen bereitgestellten Dienste zu nutzen.
Abbildung 2: Grundlegendes Flussdiagramm der WebService-Architektur
Achten Sie auf die obige Abbildung Die Bezeichnungen der grundlegenden Schritte werden wie folgt erklärt
1. Nachdem der Anbieterknoten den Dienst bereitgestellt hat, registriert er sich zunächst bei der Knotenregistrierung
2 und 3. Der Anfordererknoten geht zur Registrierung Knoten, um die Informationen zu überprüfen und den erforderlichen Anbieter und den von ihm bereitgestellten Dienst zu finden
4. Der Antragsteller nutzt den vom Anbieter bereitgestellten Dienst
Eine genauere Einführung finden Sie unter In der Referenz [2] wird im Wesentlichen Folgendes aus dieser Referenz übersetzt:
Abbildung 3: Detailliertes Schrittdiagramm
Diese Dinge im obigen Bild Stellen Sie den gesamten Prinzipprozess von WebService vollständig dar:
1. Der Kunde hat einen Bedarf und möchte einen Dienst aufrufen, weiß aber nicht, wo er ihn aufrufen soll. Er weiß jedoch, dass er in der UDDI-Registrierung zu finden ist .
2. Tatsächlich zeichnet UDDI auf, dass ein Server namens Webserver A einen solchen Dienst bereitstellen kann.
3. Der Client geht also zu Webserver A und fragt nach der genauen Aufrufmethode.
4. Nachdem Webserver A die vom Client vorgeschlagene „exakte Methodenabfrage“ sieht, gibt er ihm sofort ein von WSDL beschriebenes XML-Dokument zurück, das die verschiedenen Methodenschnittstellen aufzeichnet, die er bereitstellen kann.
5. Nachdem der Client dies gelernt hat, kapselt er diese XML-Schnittstellenmethoden in HTTP-Anforderungen und sendet sie an Webserver A. Diese Kapselungsmethoden verwenden die Standard-SOAP-Methode, bei der es sich im Wesentlichen um einige SOAP-Nachrichten handelt, die das HTTP-Protokoll erfüllen.
6. Webserver A antwortet auch auf das SOAP-Paket des HTTP-Protokolls. Auf diese Weise erfolgen die Anfragen und Antworten beider Parteien völlig reibungslos.
Was wir oben sehen, ist das schematische Diagramm der Anwendung. Wenn wir tiefer gehen, finden wir das folgende Protokollarchitekturdiagramm:
Abbildung 4: Protokollstruktur
Wir haben oben viel Energie darauf verwendet, den Discovery Service (UDDI), Service Provider, einzuführen Der gesamte Prozess der Schnittstellenbeschreibung (WSDL), des Aufrufservices (SOAP) und der Übertragung (HTTP). Daher wird auf eine Einführung verzichtet. Der Kern dieser Technologie ist SOAP.
Teil 3: WebService üben
Das obige Bild zu sehen ist so kompliziert Tatsächlich ist das SOAP+HTTP-Protokoll ausgereift genug, und wir müssen kein HTML-Skript mit SOAP-Änderungen über XML generieren. Es gibt viele Tools, die uns dabei helfen können. Tatsächlich ist die Entwicklung recht einfach.
Situation A: Es ist bekannt, dass ein Webdienst vorhanden ist, und die Client-Entwicklung kann über die folgenden Schritte durchgeführt werden:
1. Suchen Sie über UDDI den Standort von der vom Client-Programm benötigte Webdienst
2. Suchen Sie die WSDL-Schnittstellenbeschreibungsdatei über WebService
3. Verwenden Sie das Tool, um einen Client-Stub aus der in Schritt 2 erhaltenen WSDL-Datei zu generieren ist im Wesentlichen Code, also ein Stapel. Führen Sie diesen Stub-Code in das Client-Programm ein.
Situation B: Die serverseitige Entwicklung muss auch keine so mühsamen Dinge wie das Parsen von SOAP tun, das Framework erledigt das für uns. Die allgemeinen Schritte sind wie folgt:
1. Implementieren Sie alle Funktionen, die WebServer bereitstellen muss
2. Verwenden Sie WSDL-Dateien (oder IDL), um Server Stub zu generieren Empfangen von Anfragen von der Außenwelt und Weiterleiten an die Service-Implementierung (Implementierungscode) des Webservers. Wenn der Service-Implementierungscode verarbeitet und die Ergebnisse generiert werden, werden die Ergebnisse an den Server-Stub übergeben, und dann kann der Server-Stub eine SOAP-Antwort generieren. Server-Stub + Server-Implementierung werden miteinander kombiniert und werden als Web-Service-Container bezeichnet. Diese Sache ist, dass HTTP-Anforderungen, die an WebService gesendet werden, direkt an Server Stub gesendet werden sollen.
Abbildung 5: Aufrufe in praktischen Anwendungen
Weitere Informationen zur Einführung, zu den Prinzipien und zur Verwendung von WebService finden Sie auf der chinesischen PHP-Website!