Was sind Webdienste? ArchiStruktur, Typen, Beispiel

Was ist ein Webdienst?

Webservice ist ein standardisiertes Medium zur Verbreitung der Kommunikation zwischen Client- und Serveranwendungen im WWW (World Wide Web). Ein Webdienst ist ein Softwaremodul, das zur Ausführung einer bestimmten Reihe von Aufgaben konzipiert ist.

• Webdienste im Cloud Computing können über das Netzwerk gesucht und auch entsprechend aufgerufen werden.
• Wenn der Webdienst aufgerufen wird, kann er die Funktionalität dem Client bereitstellen, der diesen Webdienst aufruft.

Wie funktionieren Webdienste?

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 Anfragen erfolgen über sogenannte Remote Procedure Calls (RPC). RPCs sind Aufrufe an Methoden, die vom jeweiligen Webdienst bereitgestellt 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 JavaAber beide Programmiersprachen wären 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 (Erweiterbare Auszeichnungssprache) ist das Gegenstück zu HTML und eine leicht verständliche Zwischensprache, die von vielen Programmiersprachen verstanden wird.

Wenn Anwendungen miteinander kommunizieren, tun sie dies in XML. Dadurch entsteht eine gemeinsame Plattform, über die Anwendungen, die in verschiedenen Programmiersprachen entwickelt wurden, miteinander kommunizieren können.

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 nutzen eine Vielzahl von Programmierplattformen zur Entwicklung webbasierter Anwendungen. Einige Anwendungen können in … entwickelt werden. Java, andere in .NET, während einige wiederum in Angular JS, Node.js usw. arbeiten.

In den meisten Fällen benötigen diese heterogenen Anwendungen eine Form der Kommunikation untereinander. Da sie mit unterschiedlichen Entwicklungssprachen erstellt wurden, gestaltet sich die Gewährleistung einer reibungslosen Kommunikation zwischen den Anwendungen sehr schwierig.

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.

Arten von Webdiensten

Es gibt im Wesentlichen 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 sind unabhängig von der verwendeten Programmiersprache erforderlich. Betrachten wir diese Komponenten im Detail.

SOAP (Simple Object Access Protocol)

SOAP ist ein transportunabhängiges Messaging-Protokoll. Es basiert auf der Übertragung von XML-Daten in Form von SOAP-Nachrichten. Jede Nachricht enthält ein sogenanntes XML-Dokument. Nur die Struktur des XML-Dokuments folgt einem bestimmten Muster, nicht aber der Inhalt. Der größte Vorteil von Webdiensten und SOAP ist, dass die gesamte Kommunikation über HTTP, das Standard-Webprotokoll, erfolgt.

Eine SOAP-Nachricht besteht aus Folgendem:

• 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 die Informationen, die dem XML-Dokument mitteilen, an welchen Client es gesendet werden soll.
• 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 (Webdienste Descriptionische Sprache)

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

Zweitens muss die Clientanwendung wissen, was der Webdienst genau tut, damit sie den richtigen Webdienst aufrufen kann. Dies geschieht mithilfe der WSDL, auch bekannt als Webdienstdefinition. DescriptDie WSDL-Datei ist wiederum eine XML-basierte Datei, die der Clientanwendung im Wesentlichen die Funktionsweise des Webdienstes beschreibt. Mithilfe des WSDL-Dokuments kann die Clientanwendung ermitteln, 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 dient dazu, die verschiedenen Datenelemente für jede vom Webdienst ausgeführte Operation festzulegen. Im obigen Beispiel des Webdienstes gibt es zwei Nachrichten, die zwischen dem Webdienst und der Clientanwendung ausgetauscht werden können: die Operation „TutorialRequest“ und die Operation „TutorialResponse“. Die „TutorialRequest“ enthält ein Element namens „TutorialID“ vom Typ String. Ebenso enthält die Operation „TutorialResponse“ ein Element namens „TutorialName“, ebenfalls vom Typ String.
2. Dies beschreibt die Operation, die vom Webdienst, in unserem Fall „Tutorial“, ausgeführt werden kann. Diese Operation benötigt zwei Nachrichten: eine Eingabenachricht und eine Ausgabenachricht.
3. Dieses Element enthält das verwendete Protokoll. In unserem Fall definieren wir es als HTTP (http://schemas.xmlsoap.org/soap/http). Wir legen außerdem weitere Details für den Nachrichtentext fest, wie den Namespace und ob die Nachricht kodiert werden soll.

Wir werden „WSDL“ in diesem Abschnitt ausführlich besprechen. 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, so enthält das UDDI-Register die relevanten Informationen für den Webdienst.damit eine Clientanwendung weiß, wo sie zu finden ist.

Vorteile von Webdiensten

Wir verstehen bereits, warum Webdienste überhaupt entstanden sind: um eine Plattform bereitzustellen, die es verschiedenen Anwendungen ermöglicht, miteinander zu kommunizieren. Doch sehen wir uns nun die Vorteile von Webdiensten an, um zu verstehen, warum deren Nutzung so wichtig ist.

1. Geschäftsfunktionalität im Netzwerk verfügbar machen Ein Webdienst ist eine verwaltete Codeeinheit, die Clientanwendungen oder Endbenutzern Funktionen bereitstellt. Diese Funktionen können über das HTTP-Protokoll aufgerufen werden, also auch über das Internet. Da heutzutage fast alle Anwendungen im Internet laufen, gewinnen Webdienste zunehmend an Bedeutung. Das bedeutet, dass ein Webdienst überall im Internet erreichbar sein und die benötigten Funktionen bedarfsgerecht bereitstellen kann.
2. Interoperabilität zwischen Anwendungen Webdienste ermöglichen es verschiedenen Anwendungen, miteinander zu kommunizieren und Daten und Dienste auszutauschen. Alle Arten von Anwendungen können miteinander kommunizieren. Anstatt also spezifischen Code zu schreiben, der nur von bestimmten Anwendungen verstanden wird, kann man nun generischen Code schreiben, der von allen Anwendungen verstanden wird.
3. Ein standardisiertes Protokoll, das jeder versteht Webdienste nutzen ein standardisiertes Industrieprotokoll für die Kommunikation. Alle vier Schichten (Diensttransport, XML-Messaging, Dienst) DescriptDie Schichten ion und Service Discovery verwenden wohldefinierte Protokolle im Protokollstapel der Webdienste.
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.

Web Services Architektur

Jedes Framework benötigt eine gewisse Architektur, um sicherzustellen, dass das gesamte Framework wie gewünscht funktioniert. Ähnlich verhält es sich bei Webdiensten. Web Services Architektur besteht aus drei verschiedenen Rollen, wie unten aufgeführt:

1. Provider – Der Anbieter erstellt den Webdienst und stellt ihn Clientanwendungen zur Verfügung, die ihn nutzen möchten.
2. Anforderer – Ein Requestor ist nichts anderes als die Client-Anwendung, die einen Webservice kontaktieren muss. Die Client-Anwendung kann eine .Net-, Javaoder jede andere sprachbasierte Anwendung, die über einen Webdienst nach einer bestimmten Funktionalität sucht.
3. Makler Der Broker ist nichts anderes als die Anwendung, die den Zugriff auf die UDDI ermöglicht. Wie bereits erwähnt, ermöglicht die UDDI der Client-Anwendung, den Webdienst zu finden.

Das folgende Diagramm veranschaulicht die Interaktion zwischen Dienstanbieter, Dienstanforderer und Dienstregister.

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

Webdienstmerkmale

Webdienste weisen die folgenden besonderen Verhaltensmerkmale auf:

1. Sie sind XML-basiert Webdienste verwenden XML zur Datendarstellung auf der Darstellungs- und Datenübertragungsschicht. Durch die Verwendung von XML entfallen Abhängigkeiten von Netzwerken, Betriebssystemen oder Plattformen, da XML eine allgemein verständliche Sprache ist.
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.

Häufig gestellte Fragen