Webservices via HTTP(S) bereitstellen

Mit der zentralen Webservice-Schnittstelle lassen sich Technical Processes als Webservices via HTTP(S) bereitstellen, z. B. für ReSTful-Webservices oder SOAP-Webservices. Die einzelnen Ressourcen eines Webservices lassen sich dabei von außen über einen HTTP-URL (Uniform Resource Locator) ansprechen.

Basis-URL und Funktionsweise

Die Basis-URL der zentralen Webservice-Schnittstelle lautet http://<server>/X4/httpstarter/ReST (z. B. http://localhost:8080/X4/httpstarter/ReST).

HTTP-Anfragen werden von der zentralen Webservice-Schnittstelle unmittelbar verarbeitet und als XML-Dokument an einen Prozess übergeben. Das Ergebnis des Prozesses, z. B. ein erzeugtes Dokument, kann direkt zurückgegeben werden.

Konfiguration

Webservices werden im X4 Designer über den grafischen Webservice Configuration Editor konfiguriert.

Rückgabewerte

Als Rückgabewert liefert die Webservice-Schnittstelle den aktuellen Statuscode (z. B. 201 Created) und je nach Anfrage die identifizierte Ressource.

Unterstützte Webservice-Typen

ReSTful-Webservices: Representational State Transfer (ReST) ist ein Architekturstil, bei dem sich jede Ressource eines Informationssystems unter einem eigenen URI z. B. über HTTP ansprechen lässt. Ziel von ReSTful Services im X4 Server ist dementsprechend, Pfadstrukturen eines URI nachvollziehbar und transparent auf Prozesse abzubilden.
Für ReSTful-Webservices lassen sich pro Ressource mehrere Operationen bzw. HTTP-Methoden zuordnen und mit jeweils einem Prozess verknüpfen, z. B. für Zugriffe per GET, POST oder DELETE. Hierbei werden folgende HTTP-Methoden unterstützt:

- GET
- PUT
- POST
- DELETE
- sowie beliebige weitere Methoden, die aus gültigen XML-Zeichen bestehen.
Beim Webservice-Aufruf wird standardmäßig eine bestimmte XML-Datenstruktur an den X4-Prozess übergeben, siehe ReSTful-Webservices: Input-XML-Struktur. Zudem erwartet die Webservice-Schnittstelle ein XML-Dokument als Ergebnis, das gemäß einer definierten Struktur aufgebaut ist und eine Reihe von Optionen bietet.
Die übertragenen Daten müssen in Base64 oder Base16 (hexadezimal) kodiert werden, da über HTTP nur Bytes übertragen werden. Um Probleme bei der Interpretation des Inhalts im Element <Body> zu vermeiden, wird dort direkter Text oder XML unterstützt. Der Text bzw. das XML-Dokument muss also zunächst in Bytes umgewandelt und Base64/Base16-kodiert werden, damit Sie die volle Kontrolle über die Bytes besitzen, die als Antwort zurückgegeben werden.

Weiterführende Informationen zum ReST-Architekturstil finden Sie in der englischsprachigen Dissertation von Roy T. Fielding unter http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
SOAP-Webservices: SOAP ist ein vom W3C standardisiertes Nachrichtenprotokoll (http://www.w3.org/TR/soap), welches eine standardisierte Kommunikation zwischen verteilten Anwendungen ermöglicht. SOAP-Webservices können in verschiedenen Varianten bereitgestellt werden, u.a. mit externer WSDL-Definition oder ohne WSDL-Definition, im RPC-Stil oder im Document-Modus. Als Nachrichtenformat wird bei SOAP-Webservices typischerweise XML für Anfrage (Request) und Ergebnis (Response) genutzt, und Binärdaten werden ggf. per MIME anhängt (MTOM).
SOAP-Webservices lassen sich auf die gleiche Weise wie ReSTful-Services via HTTP(S) bereitstellen, siehe SOAP-Webservices bereitstellen.
Der Service-Typ SOAP unterstützt die Standards SOAP 1.1 und SOAP 1.2. SOAP-Service-Definitionen können beliebig mit HTTP-ReST-Webservice-Definitionen und mit File-Webservice-Definitionen kombiniert werden.
File-Webservices: Mit der zentralen Webservice-Schnittstelle lassen sich auch statische Datei-Ressourcen aus dem Repository bzw. dynamisch per X4-Prozess erzeugte Dokumente als Service via HTTP-GET bereitstellen, siehe File-Webservice bereitstellen.