API

Webservice

In der heutigen Zeit gibt es Anwendungen wie Sand am Meer. Nicht wenige erkennen Synergiepotenziale bei einer Zusammenarbeit von Applikationen.

Beispiel: Auf der einen Seite gibt es Shopsysteme und auf der anderen Seite gibt es Anbieter, die online Zahlungsdienste anbieten. Es wäre für den Shopsystem Hersteller sinnvoll mit dem Zahlungsdienstanbieter zusammen zu arbeiten. Wieso? Somit kann er sich auf sein Kerngeschäft / Kernsystem auf das Shopsystem konzentrieren und muss nicht den Aufwand treiben einen eigenen Zahlungsdienst aufzubauen. Nur bei wenigen Fällen macht diese Eigenentwicklung Sinn.

Ein Webservice ermöglicht die Kommunikation von Maschinen basierend auf HTTP-Protokoll über das Internet. Daten werden ausgetauscht und Funktionen können aufgerufen, von und aus verschiedenen Anwendungen heraus.

Somit wird mittels eines Webservice eine Kommunikation von mehreren Anwendungen, die auf verschiedenen Sprachen implementiert sind.

Ein Webservice besitzt:

  • Uniform Resource Identifier (URI)
  • Schnittstellenbeschreibung (als XML Artefakt z.B. WSDL)

 

Client Programme senden ein request an ein Webserivce. Der Webservice antwortet auf die Anfrage mit den gewünschten Informationen und Daten. Ein Webservice orientiert sich an der SOA Architektur.

Die drei wichtigsten Teile der Zusammenarbeit zwischen Client und Server sind:

  • Zusammenfinden
  • Binden
  • Datenaustausch

Ein Webservice ist stets über einen URI (uniform resource identifier) erreichbar.

Zwischen dem Client und dem Server werden Daten als XML Daten ausgetauscht. Anwendungen reden miteinander auf XML.

In diesem Artikel betrachten wir ein Webservice nach SOAP und REST:

Webservice Komponenten

SOAP (Simple Object Access Protocol)

Es liegen jede Menge Anwendungen geschrieben auf Java, .Net, PHP etc. vor. Miteinander zu kommunizieren kann XML verwendet werden, da alle gängigen Programmiersprachen diese XML Sprache verstehen.  Einen Standard hierfür gibt es leider nicht. SOAP wurde entwickelt mit XML über http Requests zu funktionieren.

SOAP ist ein Nachrichten-Protokoll, womit XML Daten ausgetauscht werden. Alle Nachrichten werden via das http Standard Web Protokoll versendet

SOAP (Simple Object Access Protocol) Nachricht:

  • <Envelope> Dieses Element wird verwendet um die Details von SOAP Nachricht einzubetten. Der Anfang und das Ende einer SOAP Nachricht wird mit diesem Element definiert. Jedes Envelope muss ein Body und maximal einen header enthalten.
  • Die Elemente <header> und <body> müssen ebenfalls vorliegen. Das <header> Element enthält die header Informationen wie Authentifizierung Schlüsseln, Parametern oder auch komplexe Objekte.

Beispiel für ein komplexes Objekt:

<xsd:complexType>

<xsd:sequence>

<xsd:element name=“Tutorial Name“ type=“string“/>

<xsd:element name=“Tutorial Description“  type=“string“/>

</xsd:sequence>

</xsd:complexType>

  • <body> enthält die eigentliche Nachricht. Aufruf und Antwort -Informationen sind in einem body Element enthalten. Hierbei stehen die eigentlichen Daten. Anbei ein Beispiel:
  • <soap:Body>
  • <GetTutorialInfo>
  • <TutorialName>Webservices</TutorialName>
  • <TutorialDescription>All about Webservices</TutorialDescription>
  • </GetTutorialInfo>
  • </soap:Body>

 

Elemente einer SOAP Nachricht:

Diese Nachrichten werden automatisch vom Service generiert, wenn der Webservice gerufen wird.

Die Client- Anwendung ruft eine Methode im Webservice auf und der Webservice generiert die SOAP Nachricht mit den relevanten Informationen.

Warum SOAP?

  • SOAP ist das Protokoll Daten zwischen Anwendungen auszutauschen.
  • Das SOAP Protokoll wurde auch von W3C empfohlen
  • SOAP ist Sprach- und Betriebssystem unabhängig
  • SOAP funktioniert auf das http Protokoll

 

Fehler Nachrichten

Wenn eine Anfrage an den SOAP Webservice vorliegt, kann entweder eine erfolgreiche Antwort verschickt werden oder auch eine Fehlernachricht (http 500 – Fehler). Die Fehlernachricht enthält folgende Elemente:

SOAP – ENV VersionMismatch à ungültiges Zeichen beim SOAP Envelope Element

SOAP- ENV: MustUnderstand à Fehler beim Kind Element vom Header Element

SOAP-ENV: Client à  Die Nachricht was nicht korrekt formatiert oder enthält falsche Information

SOAP – ENV: Server à Ein Fehler mit dem Server liegt vor

<faultString>

<faultActor>

<detail>

 

SOAP Kommunikationsmodell:

Marshalling (Client):  Der Client formattiert den Auftrag in eine SOAP Nachricht und sendet diesen an den Server als ein HTTP Request. Das „encapsulating“ (einkapseln) der Daten in eine SOAP Nachricht nennt man marshalling.

Demarshalling (Server): Das Auspacken einer Anfrage vom Client versteht man als demarshalling.

WSDL (Webservices description language)

Ein Webservice muss lokalisiert werden, bevor man diesen nutzt. WSDL ist bekannt als die Sprache für die Beschreibung eines Webservice. Diese ist eine XML basierte Datei, welchen dem Client sagt, was eigentlich ein Webservice macht. Der client erfährt wo der Webservice vorhanden ist und wie dieser zu nutzen ist. Folgende Tags sind wesentlich bei einer WSDL Deklaration:

  1. <message>   definiert Datenelemente für header Operation durch den Webservice
  2. <portType> beschreibt die eigentliche Operation, welche vom Webservice durchgeführt wird
  3. <binding> enthält das verwendete Protokoll

Ein Webservice hat eine Beschreibungssprache, WSDL genannt. Eine WSDL Datei wird verwendetet um zu verstehen was der Webservice eigentlich macht. Diese Datei enthält den Ort und die Methoden vom Service. Eine WSDL Datei ist wie folgt strukturiert:

  • Definition
  • TargetNamespace
  • DataTypes
  • Messages
  • Porttype
  • Bindings
  • service

Die Nachricht, welche von SOAP Protokoll ist, wird im WSDL Dokument definiert. WSDL Datei ist wie eine Postkarte, welche die Adresse vom Webservice besitzt und welche alle notwendigen Funktionen enthält.

<!– WSDL definition structure –>

<definitions

name=“Guru99Service“

targetNamespace=http://example.org/math/

xmlns=http://schemas.xmlsoap.org/wsdl/>

<!– abstract definitions –>

<types> …

<message> …

<portType> …

 

<!– concrete definitions –>

<binding> …

<service> …

</definition>

 

Struktur einer WSDL Datei

 

Definition:

  • type — message
  • porttype – operation, input, output

 

  • Binding:
  • Service: port
  • <types> wird verwendet Datentypen zu definieren
  • <messages> definiert die Nachricht, welche zwischen der Client-Anwendung und dem Webserver ausgetauscht wird
  • <portType> wird verwendet, um input und output Nachrichten in einzubetten
  • <binding> wird verwendet um Operation zu einem Port-Typ zu verbinden. Port Typen sind wie Schnittstellen.
  • <service> ist der gegebene Name an den Webservice. Eine Webanwendung ruft nach einem Webserivce mit Hilfe des Namens.

Mit WSDL kann eine Java Klasse den Output eines .Net Webservices konsumieren.

  • WSDL – Message

Beschreibt die Daten, die zwischen der Anwendung und dem Webservice, ausgetauscht werden. Jeder Webservice enthält 2 Typen von messages einen für den Input (welche Inputparameter akzeptiert werden) und einen für den Output vom Service.

Das Element <part> wird verwendet um die Input und Output Parameter zu beschreiben.

 

Port type beschreibt die komplette Operation, welche vom Webservice angeboten wird.  Die Input und Output Nachricht aggregieren zu einer kompletten Operation. <binding> Element definiert wie die Nachrichten ausgetauscht werden. Mit den Informationen in binding verbindet sich die Anwendung mit dem Webservice. Erst dann können die Funktionen vom Webservice verwendet werden. Der „transport layer“ wird hierbei ebenfalls gesetzt.

 

UDDI: ist ein Standard einen Webservice zu beschreiben, veröffentlichen und zu entdecken. UDDI schafft ein Repository, wo WSDL Dateien gehosted werden. Die Client-Anwendung hat Zugriff auf UDDI, welche wie eine Datenbank für die WSDL Dateien fungiert. Bildlich kann man UDDI wie ein Telefonbuch vorstellen, der die relevanten Informationen zu einer Person enthält.

Vorteile eines Webservice:

  • Funktionen erhalten eine hohe Reichweite
  • Kommunikation zwischen Anwendungen vereinfacht
  • Standardisiertes bekanntes Protokoll
  • Internet ist ausreichend um eine Webservice zu implementieren

 

Webservice Architektur

  • Provider – erstellt den Webservice
  • Requestor – Client Anwendung, der die Funktion benötigt via eines Webservices
  • Broker – schafft den Zugang zum UDDI

 

Eigenschaften eines Webservice:

  • Basieren auf XML
  • Funktionieren synchron und asynchron
  • Unterstützen Remote Procedure Calls (RPCs)
  • Unterstützt Dokumentenaustausch

 

Prinzipien einer SOA

  • SOA vereinfacht DIE Zusammenarbeitet von Software Komponenten
  • Standardisierte Serviceverträge
  • Funktionsänderungen beeinträchtigt die Zusammenarbeit mit dem Webservice nicht
  • Abstrakter Service
  • Service wiederverwendbar
  • Service sollten Standards nutzen um den Service nutzbar zu machen
  • Services sollten mehrere Module je Problem haben

 

 

 

 

 

 

 

 

 

 

 

RESTful Webservices

Wartbare und skalierbare Webservice sollten mit REST gebaut werden. Das Protokoll für REST lautet http web Protokoll. REST ist ein Weg um Ressourcen, die auf einer Umgebung vorliegen, zuzugreifen.

Schlüsselelemente einer RESTful Implementierung

  • Ressources
  • Requests Verbs — GET (erhalten einer Liste), POST (Erstellen einer Einheit in einer Liste), PUT (Aktualisierung einer Einheit), DELETE (Löschen einer Einheit)
  • Request Headers – zusätzliche Anweisungen mit dem Request
  • Request Body – Daten welche zusammen mit dem Request gesendet werden
  • Response Body – Hauptteil einer Antwort
  • Response Status codes – 200 OK

 

Ähnlich wie SOAP lässt auch REST die Kommunikation zwischen Anwendungen verschiedener Sprachen zu. Besonders Cloud basierte Architektur arbeiten gut mit dem REST Prinzip.

 

Restful Architektur

  1. Zustand und Funktionen sind unterteilt in verteilte Ressourcen; Ressourcen sollten über http Befehle zugänglich sein.
  2. Die Architektur ist ein Client und Server basiertes; Der Client fragt nach Informationen und der Server liefert die Antwort. Sequentiell geht es so weiter und der Server merkt sich die vergangenen Fragen und Antworten nicht.
  3. Client à Cache à Server lautet die Architektur um wiederholende Fragen über Cache sich antworten zu lassen

 

SOAP vs REST

SOAP REST
SOAP ist ein Protokoll. Sie schließt eine WSDL Datei ein, welche die notwendigen Information zum Webservice besitzt REST kann nur angewendeten werden wenn Client-Server Architektur vorliegt.
SOAP kann REST nicht nutzen REST kann SOAP anwenden
SOAP verwendet Schnittstellen um Funktionen zu Webanwendungen zu zeigen REST verwendet Uniform Service locator um Bestandteile von Hardware.

http://checkideas.com/Mitarbeiter

SOAP enthalten viel Informationen zu den messages. REST benötigt nicht viel Bandbreite, da die requests werden als JSON Objekte versendet
SOAP sorgt auch für WS Security um Sicherheit bei einem Webservice zu schaffen

WS Security kann mit Name und Passwort aufgerufen werden oder mit einem binären Zertifikat für die Authentifizierung

 

 Bei REST kann Sicherheit mit https Verbindung aufgebaut werden

 

 

  • API – Application Programming Interface wird vom Client und Server angeboten.
  • REST API – Mangel an Sicherheit; Mangel an Zustand (Warenkorb merken kann nicht)

 

Andere Remote Access Techniques -> RPC (remote procedure call)

  1. DCOM – Distributed Component Object Model à Microsoft Technologie um auf Client remote Komponenten zuzugreifen.  Client Anwendung muss Ressourcen befreien, falls nicht mehr notwendig! Bei Java müssen weitere Java Codes geschrieben werden.
  2. Java RMI Java Remote Method Innovation kann nur auf Java Virtual Maschine laufen
  3. Cobra (Common Object Request Broker Architecture) Eine weitere Sprache muss erlernt werden, um die Kommunikation zwischen den Anwendungen

Alle oben genannten Technologien basieren nicht auf HTTP Protokoll. Teilweise müssen sogar auf verschiedenen Ports müssen zugegriffen werden

Was sagen die anderen zu der Idee?