Was sind Webdienste? ArchiStruktur, Typen, Beispiel

Wie funktionieren WebServices?

Das obige Diagramm zeigt eine sehr vereinfachte Ansicht, wie ein Webdienst tatsächlich funktionieren würde. Der Client würde eine Reihe von Webdienstaufrufen über Anfragen an einen Server aufrufen, der den eigentlichen Webdienst hosten würde.

Diese Anforderungen werden über sogenannte Remoteprozeduraufrufe gestellt. Remote Procedure Calls (RPC) sind Aufrufe an Methoden, die vom entsprechenden Webdienst gehostet werden.

Als Beispiel, Amazon bietet einen Webdienst, der Preise für Produkte bereitstellt, die online über amazon.com verkauft werden. Das Frontend oder die Präsentationsschicht kann in .Net oder Java aber jede Programmiersprache wäre in der Lage, mit dem Webdienst zu kommunizieren.

Der Hauptbestandteil eines Webservice-Designs sind die Daten, die zwischen dem Client und dem Server übertragen werden, und zwar XML. XML (Extensible Markup Language) ist ein Gegenstück zu HTML und eine leicht verständliche Zwischensprache, die von vielen Programmiersprachen verstanden wird.

Wenn also Anwendungen miteinander kommunizieren, kommunizieren sie tatsächlich in XML. Dies bietet eine gemeinsame Plattform für Anwendungen, die in verschiedenen Programmiersprachen entwickelt wurden, um miteinander zu kommunizieren.

Webdienste verwenden zum Senden der XML-Daten zwischen Anwendungen etwas, das als SOAP (Simple Object Access Protocol) bekannt ist. Die Daten werden über normales HTTP gesendet. Die Daten, die vom Webdienst an die Anwendung gesendet werden, werden als SOAP-Nachricht bezeichnet. Die SOAP-Nachricht ist nichts anderes als ein XML-Dokument. Da das Dokument in XML geschrieben ist, kann die Clientanwendung, die den Webdienst aufruft, in einer beliebigen Programmiersprache geschrieben werden.

Warum brauchen Sie einen Webservice?

Moderne Geschäftsanwendungen verwenden eine Vielzahl von Programmierplattformen, um webbasierte Anwendungen zu entwickeln. Einige Anwendungen können in Java, andere in .Net, während andere in Angular JS, Node.js usw. sind.

Meistens ist für diese heterogenen Anwendungen eine Art Kommunikation zwischen ihnen erforderlich. Da sie in unterschiedlichen Entwicklungssprachen erstellt werden, ist es sehr schwierig, eine genaue Kommunikation zwischen den Anwendungen sicherzustellen.

Hier kommen Webdienste ins Spiel. Webdienste bieten eine gemeinsame Plattform, die mehrere Anwendungen ermöglicht, die auf verschiedenen Plattformen basieren Programmiersprachen die Fähigkeit zu haben, miteinander zu kommunizieren.

Art des Webdienstes

Es gibt hauptsächlich zwei Arten von Webdiensten.

1. SOAP-Webdienste.
2. RESTful-Webservices.

Damit ein Webdienst voll funktionsfähig ist, müssen bestimmte Komponenten vorhanden sein. Diese Komponenten müssen unabhängig davon vorhanden sein, welche Entwicklungssprache für die Programmierung des Webdienstes verwendet wird.

Schauen wir uns diese Komponenten genauer an.

SOAP (Simple Object Access Protocol)

SOAP ist als transportunabhängiges Nachrichtenprotokoll bekannt. SOAP basiert auf der Übertragung von XML-Daten als SOAP-Nachrichten. Jede Nachricht enthält etwas, das als XML-Dokument bezeichnet wird. Lediglich die Struktur des XML-Dokuments folgt einem bestimmten Muster, nicht jedoch der Inhalt. Das Beste an Webdiensten und SOAP ist, dass alles über HTTP gesendet wird, das Standard-Webprotokoll.

Hier erfahren Sie, woraus eine SOAP-Nachricht besteht

• Jedes SOAP-Dokument muss über ein Stammelement namens verfügen Element. Das Stammelement ist das erste Element in einem XML-Dokument.
• Der „Umschlag“ ist wiederum in 2 Teile geteilt. Der erste ist der Header und der nächste ist der Body.
• Der Header enthält die Routing-Daten, also im Wesentlichen die Informationen, die dem XML-Dokument mitteilen, an welchen Client es gesendet werden muss.
• Der Textkörper enthält die eigentliche Nachricht.

Das folgende Diagramm zeigt ein einfaches Beispiel für die Kommunikation über SOAP.

Wir werden SOAP hier ausführlich besprechen Lernprogramm.

WSDL (Beschreibungssprache für Webdienste)

Ein Webdienst kann nicht genutzt werden, wenn er nicht gefunden wird. Der Client, der den Webdienst aufruft, sollte wissen, wo sich der Webdienst tatsächlich befindet.

Zweitens muss die Clientanwendung wissen, was der Webdienst tatsächlich tut, damit sie den richtigen Webdienst aufrufen kann. Dies geschieht mit Hilfe der WSDL, der sogenannten Web-Services-Beschreibungssprache. Bei der WSDL-Datei handelt es sich wiederum um eine XML-basierte Datei, die der Clientanwendung grundsätzlich mitteilt, was der Webdienst tut. Mithilfe des WSDL-Dokuments wäre die Clientanwendung in der Lage zu verstehen, wo sich der Webdienst befindet und wie er genutzt werden kann.

Beispiel für einen Webdienst

Nachfolgend finden Sie ein Beispiel für eine WSDL-Datei für Webdienste.

<definitions>	
   <message name="TutorialRequest">
      <part name="TutorialID" type="xsd:string"/>
   </message>
     
   <message name="TutorialResponse">
      <part name="TutorialName" type="xsd:string"/>
   </message>

   <portType name="Tutorial_PortType">
      <operation name="Tutorial">
         <input message="tns:TutorialRequest"/>
         <output message="tns:TutorialResponse"/>
      </operation>
   </portType>

   <binding name="Tutorial_Binding" type="tns:Tutorial_PortType">
      <soap:binding style="rpc"
         transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="Tutorial">
         <soap:operation soapAction="Tutorial"/>
         <input>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </input>
         
		 <output>
            <soap:body
               encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
               namespace="urn:examples:Tutorialservice"
               use="encoded"/>
         </output>
      </operation>
   </binding>
</definitions>

Bei den oben genannten WSDL-Deklarationsbeispielen für Webdienste sind folgende wichtige Aspekte zu beachten:

1. – Der Nachrichtenparameter in der WSDL-Definition wird verwendet, um die verschiedenen Datenelemente für jede vom Webdienst ausgeführte Operation zu definieren. In den obigen Webdienstbeispielen haben wir also zwei Nachrichten, die zwischen dem Webdienst und der Clientanwendung ausgetauscht werden können, eine ist die „TutorialRequest“ und die andere die „TutorialResponse“-Operation. Die TutorialRequest enthält ein Element namens „TutorialID“, das vom Typ String ist. Ebenso enthält die TutorialResponse-Operation ein Element namens „TutorialName“, das ebenfalls vom Typ String ist.
2. – Dies beschreibt eigentlich den Vorgang, der vom Webdienst ausgeführt werden kann, der in unserem Fall Tutorial heißt. Dieser Vorgang kann zwei Nachrichten annehmen; eine ist eine Eingabenachricht und die andere ist die Ausgabenachricht.
3. – Dieses Element enthält das verwendete Protokoll. In unserem Fall definieren wir es also für die Verwendung von http (http://schemas.xmlsoap.org/soap/http). Wir geben auch andere Details für den Hauptteil der Operation an, wie den Namespace und ob die Nachricht codiert werden soll.

Wir werden hier ausführlich auf „WDSL“ eingehen Lernprogramm.

Universal- Description, Discovery und Integration (UDDI)

UDDI ist ein Standard zum Beschreiben, Veröffentlichen und Erkennen der Webdienste, die von einem bestimmten Dienstanbieter bereitgestellt werden. Es stellt eine Spezifikation bereit, die beim Hosten der Informationen zu Webdiensten hilft.

Im vorherigen Thema haben wir WSDL besprochen und wie es Informationen darüber enthält, was der Webdienst eigentlich tut. Aber wie kann eine Client-Anwendung eine WSDL-Datei finden, um die verschiedenen von einem Webdienst angebotenen Vorgänge zu verstehen? UDDI ist die Antwort darauf und stellt ein Repository bereit, in dem WSDL-Dateien gehostet werden können. Die Client-Anwendung hat also vollständigen Zugriff auf UDDI, das als Datenbank fungiert, die alle WSDL-Dateien enthält.

So wie ein Telefonbuch den Namen, die Adresse und die Telefonnummer einer bestimmten Person enthält, verfügt das UDDI-Register über die relevanten Informationen für den Webdienst. Damit eine Client-Anwendung weiß, wo sie zu finden ist.

Vorteile von Webdiensten

Wir verstehen bereits, warum Webdienste überhaupt entstanden sind, nämlich die Bereitstellung einer Plattform, die es verschiedenen Anwendungen ermöglicht, miteinander zu kommunizieren.

Aber schauen wir uns die Liste der Vorteile von Webdiensten an, um herauszufinden, warum die Verwendung von Webdiensten wichtig ist.

1. Geschäftsfunktionalität im Netzwerk verfügbar machen – Ein Webdienst ist eine verwaltete Codeeinheit, die Clientanwendungen oder Endbenutzern eine bestimmte Funktionalität bereitstellt. Diese Funktionalität kann über das HTTP-Protokoll aufgerufen werden, was bedeutet, dass sie auch über das Internet aufgerufen werden kann. Heutzutage befinden sich alle Anwendungen im Internet, was den Zweck von Webdiensten noch nützlicher macht. Das bedeutet, dass der Webdienst überall im Internet verfügbar sein und bei Bedarf die erforderliche Funktionalität bereitstellen kann.
2. Interoperabilität zwischen Anwendungen – Webdienste ermöglichen es verschiedenen Anwendungen, miteinander zu kommunizieren und Daten und Dienste untereinander auszutauschen. Alle Arten von Anwendungen können miteinander kommunizieren. Anstatt also spezifischen Code zu schreiben, der nur von bestimmten Anwendungen verstanden werden kann, können Sie jetzt generischen Code schreiben, der von allen Anwendungen verstanden werden kann
3. Ein standardisiertes Protokoll, das jeder versteht – Webservices verwenden standardisierte Industrieprotokolle für die Kommunikation. Alle vier Schichten (Service Transport, XML Messaging, Service Description- und Service Discovery-Ebenen) verwenden gut definierte Protokolle im Webservices-Protokollstapel.
4. Reduzierung der Kommunikationskosten – Webdienste verwenden das SOAP-über-HTTP-Protokoll, sodass Sie Ihr vorhandenes kostengünstiges Internet für die Implementierung von Webdiensten nutzen können.

1. Provider – Der Anbieter erstellt den Webdienst und stellt ihn der Clientanwendung zur Verfügung, die ihn nutzen möchte.
2. Anforderer – Ein Requestor ist nichts anderes als die Client-Anwendung, die einen Webservice kontaktieren muss. Die Client-Anwendung kann eine .Net-, Java, oder jede andere sprachbasierte Anwendung, die über einen Webdienst nach einer Art Funktionalität sucht.
3. Makler – Der Broker ist nichts anderes als die Anwendung, die den Zugriff auf das UDDI ermöglicht. Wie im vorherigen Thema erläutert, ermöglicht das UDDI der Clientanwendung, den Webdienst zu finden.

Das folgende Diagramm zeigt, wie der Dienstanbieter, der Dienstanforderer und die Dienstregistrierung miteinander interagieren.

1. Veröffentlichen – Ein Anbieter informiert den Broker (Service Registry) über die Existenz des Webservices, indem er die Veröffentlichungsschnittstelle des Brokers nutzt, um den Service für Clients zugänglich zu machen
2. Finde – Der Anforderer konsultiert den Broker, um einen veröffentlichten Webdienst zu finden
3. Binden – Mit den Informationen, die er vom Broker (Dienstregister) über den Webdienst erhalten hat, kann der Anforderer den Webdienst binden oder aufrufen.

Web-Service-Eigenschaften

Webdienste weisen die folgenden besonderen Verhaltensmerkmale auf:

1. Sie sind XML-basiert – Web Services verwenden XML, um die Daten auf den Darstellungs- und Datentransportebenen darzustellen. Durch die Verwendung von XML werden jegliche Abhängigkeiten von Netzwerken, Betriebssystemen oder Plattformen eliminiert, da XML die gemeinsame Sprache ist, die von allen verstanden wird.
2. Locker verbunden – Lose gekoppelt bedeutet, dass der Client und der Webdienst nicht aneinander gebunden sind. Das bedeutet, dass sich die Art und Weise, wie der Client den Webdienst aufruft, auch dann nicht ändern sollte, wenn sich der Webdienst im Laufe der Zeit ändert. Die Einführung einer lose gekoppelten Architektur macht Softwaresysteme tendenziell besser verwaltbar und ermöglicht eine einfachere Integration zwischen verschiedenen Systemen.
3. SyncSynchrone oder asynchrone Funktionalität - SyncChronizität bezieht sich auf die Bindung des Clients an die Ausführung des Dienstes. Bei synchronen Vorgängen wartet der Client tatsächlich darauf, dass der Webdienst einen Vorgang abschließt. Ein Beispiel hierfür ist wahrscheinlich ein Szenario, in dem ein Lese- und Schreibvorgang in einer Datenbank ausgeführt wird. Wenn Daten aus einer Datenbank gelesen und anschließend in eine andere geschrieben werden, müssen die Vorgänge sequenziell ausgeführt werden. Asynchrone Vorgänge ermöglichen es einem Client, einen Dienst aufzurufen und dann parallel andere Funktionen auszuführen. Dies ist eine der häufigsten und wahrscheinlich am meisten bevorzugten Techniken, um sicherzustellen, dass andere Dienste nicht angehalten werden, wenn ein bestimmter Vorgang ausgeführt wird.
4. Möglichkeit zur Unterstützung von Remote Procedure Calls (RPCs) – Webdienste ermöglichen es Clients, mithilfe eines XML-basierten Protokolls Prozeduren, Funktionen und Methoden für Remoteobjekte aufzurufen. Remoteprozeduren stellen Eingabe- und Ausgabeparameter bereit, die ein Webdienst unterstützen muss.
5. Unterstützt den Dokumentenaustausch – Einer der Hauptvorteile von XML ist die generische Darstellungsweise nicht nur von Daten, sondern auch von komplexen Dokumenten. Diese Dokumente können so einfach sein wie die Darstellung einer aktuellen Adresse oder so komplex wie die Darstellung eines ganzen Buches.