Das Web als Kommunikationsschicht

(1)

Clemens Düpmeier, 03/09/2022

Das Web als Kommunikationsschicht

(2)

REST und RESTful-Services

• REST (Representational State Transfer) ist ein

– Architekturprinzip für Verteilte, Internet-basierte Service-orientierte Anwendungen

– erstmals beschrieben von Roy Fielding in seiner Dissertation

Architectural Styles and the Design of Network-based Software Architectures

– Kernüberlegung: Wie muss eine Service-orientierte Architektur

aufgebaut sein, wenn sie den grundlegenden Prinzipien des Web folgt.

• RESTful Web-Services sind dann zugehörige Serviceschnittstellen,

die nach den REST Prinzipien realisiert sind

(3)

3 Gruppe WebUIS | IAI | 03.02.2009

RESTful Services

• Services zum Zugriff auf "Resourcen", die über Internet erreichbar sind

– Resourcen

• haben eine URI als eindeutigen Identifier

• Können verschiedene Repräsentationen haben

– HTML, XML, JSON, PDF

– Inhaltlich beliebige Dinge

• z.B. Objekte, wie Kontakte, Bücher, CD’s, …

• Nutzen HTTP zur Definition der Aktionen auf Resourcen

– GET "Gib mir Repräsentation der Resource"

– PUT "Führe Update der Resource aus", erzeuge Sie bei Bedarf – POST "Erzeuge neue Sub-Resource

– DELETE "Lösche Resource"

• RESTful Services sind zustandslos

Contact ID=2467

Client http://addressbook.org/contact/2467

GET

...

</contact>

XML-Repräsentation

Resource

(4)

Struktur von URL’s

• URL's zum Aufruf von Services

– http://contact.org/contacts

• Rückgabe der Liste aller Kontakte

– http://contact.org/contacts?lastname=Düpmeier

• Rückgabe der Kontakte, bei denen „lastname“ den Wert „Düpmeier“ hat (Suchinterface)

– http://contact.org/contacts?id=2467

• nicht gut!

– http://contact.org/contacts/2467

• Rückgabe von Informationen zum Contact mit Id „2467"

• Fazit:

– Direkte Adressierung (Benennung) von Ressourcen sollte über URL's (ohne Query-Parameter) erfolgen

– Query-Parameter dienen u. a. zur Filterung, Einschränkung oder

(5)

Content Negotiation und Inhaltstypen

• Client sendet "Accept"-Header mit gewünschten bzw.

akzeptierten Inhaltsformaten (z.B. application/xml)

– Service sendet bestmögliche Repräsentation zurück

• Inhaltstypen sind

– über Mime-Typen definiert, also z.B.

• text/plain, text/html

• text/xml, application/xml

• application/json

• image/gif, image/jpeg

(6)

Weitere Eigenschaften

• Security

– Nutzung der HTTP-Security Mechanismen

• Verschiedene Authorisierungsformen

• Nutzung von HTTPS falls sichere Übertragung

• unabhängig vom Service selbst definierbar

• Fehlerbehandlung

– über Standard HTTP-Mechanismen

• Fehlercodes und Fehlermeldungen in Response

• Caching und bedingte Requests

– Kann HTTP Mechanismen, wie "If-Modified-Since", ETags Header nutzen

– Client kann daher Ressourcen cachen (größere Performance)

(7)

Weitere Eigenschaften (2)

• Addressability

– Jede für einen Client sinnvolle Ressource ist direkt adressierbar – D.h.: Alle solche Ressourcen können über URI direkt erreicht

werden

• Connectedness

– RESTful Services nutzen das Hypertext Prinzip

– Ressource-Repräsentationen "verlinken" untereinander

• In XML Repräsentationen z.B mit "xlink:href" Konstrukten

– Man muss nicht alle Information in eine Ressource-Repräsentation verpacken

• Unterscheidung zwischen Übersicht oder Detailansicht

• Auf in Beziehung stehende Objekte verlinken, statt einbetten, etc.

(8)

Rückgabeformate und Verlinkung

• RESTful Services geben Informationen über Ressourcen (Repräsentationen) in strukturierten Formaten zurück

– Z.B. XML oder JSON

• Dabei werden auch Möglichkeiten zur Verlinkung mit weiteren Ressource-Repräsentationen genutzt

<contact id="2467">

<lastname>Düpmeier</lastname>

<surname>Clemens</surname>

<birthday>10.07.1955</birthday>

<mother xlink:href="http://contact.org/contacts/33447">

Anna Nobel </mother>

</cd>

(9)

Hypertext As The Engine Of Application State (HATEOAS)

• Rückgabeformat enthält Links zu weiteren ausführbaren Funktionalitäten

(10)

Hypertext As The Engine Of Application State (HATEOAS)

• Diese Links sind abhängig vom Zustand der Ressource

• Da das Konto überzogen ist, können nun keine Abbuchungen

mehr vorgenommen werden

(11)

Implementierung?

(12)

Objekte auf Repräsentationen mappen

@Entity

@XmlRootElement

public class Contact {

@ID

long id;

String lastname;

String surname;

Date birthday;

}

<contact>

<id>2467</id>

<lastname>Düpmeier</lastname>

<surname>Clemens</surname>

<birthday>10.07.1955</birthday>

</contact>

Objektrelationales Mapping

Java To XML Mapping (JAXB)

id lastname surname birthday

2467 Düpmeier Clemens 10.07.1955

in Datenbank

XML-Darstellung zum Übertragen

(13)

Progr. von RESTful Service über Jersey

• Die Pfadangaben (@Path) definieren, welche Methode bei welcher URL aufgerufen wird

• Das zurückgegebene Objekt wird automatisch nach XML serialisiert, wenn das Objekt JAXB gemappt ist

@Produces({"application/xml","application/json"}) public class ContactResource {

@EJB

ContactDao contactDao @GET

@Path("/contacts/")

public List<Contact> getListOfContacts() { return contactDao.getContacts();

} @GET

@Path("/contacts/{contactId}")

public Contact getContact(@PathParam(“contactId") String id) { return contactDao.getContact(id);

} }

(14)

Serviceaufruf durch mobilen Client

GET http://contact.org/contacts/2467 Accept: application/json

{

"id":"2467",

"lastname":"Düpmeier",

"surname":"Clemens",

"birthday":"10.07.1955"

}

Kontakte-Server JPA->XML->JSON

JSON

(15)

Clients

• RESTful-Services sind unabhängig von

Programmiersprache, einfach zu handhaben und eine sehr offene Technologie

– Clients + Server können in "allen" Sprachen und für alle Plattformen geschrieben werden

– Auf Clientseite ist nur ein minimales Framework notwendig

• Muss URL-Aufrufe an Server schicken und das Rückgabeformat interpretieren können

– Also z.B. XML oder JSON verarbeiten können

• Zur weiteren Vereinfachung für Servicenutzer wird häufig gleich Client-seitige API in Zielsprache bereitgestellt

– z.B. in Form einer objektorientierten Javascript-Library für die Anwendung in Web-Applikationen

• Google Maps API, OpenSocial API, Amazon API, Flickr API, etc.

– Oder in Form von Java oder .NET Klassenbibliotheken

(16)

Anwendung(en)

• Als Schnittstelle zur Anbindung von Client-seitigen Anwendungen an Server-seitige Dienstinfrastrukturen

– RIAs = Rich Internet Applications

– Mobile Anwendungen (Beispiele IPhone oder Android Apps)

• SOA (Service Oriented Architecture) Anwendungen

– z.B Business-to-Business Kommunikation

• Zur Implementierung der Kommunikationsschnittstellen von Microservices

• Cloud-Computing

– In Clouds ist "everything a service"

• Infrastructure as a service (IAAS)

• Software as a service (SAAS)

(17)

Klassische SOAP-basierte Web-Services

(18)

Standard Web-Services

• Basieren auf der Übertragung XML basierter Nachrichten über Protokollen wie HTTP / SMTP

• SOAP definiert Format für Nachrichtenübertragung

– SOAP RPC Konvention definiert dann spezielle Nachrichten für RPC-Kommunikation (Nachricht für Methodenaufruf,

Returnwert, Fehlerbehandlung)

• Über eine XML-basierte Interface-Beschreibungssprache (WSDL) kann man einen Web-Service formal als Menge von Interfaces (Ports) und Operationen an Ports (Methoden)

beschreiben

• Der W3C Web-Service Standard definiert sprachunabhängige,

interoperable Serviceschnittstellen (.NET, JEE JAX-WS)

(19)

Prinzipielle Architektur von Web-Service Laufzeitinfrastrukturen

SOAP

Clientseitige Web-Service Infrastruktur,

SOAP Framework

Laufzeitsystem ^Server

(z.B. in Servlet Engine)

Container

Client-gen. Code (Proxy / Stub)

Client Code Web-Service

Endpunkt (Server Objekt)

WSDL Dokument

Serverseitige Webservice Infrastruktur

HTTP

SOAP Nachricht

TCP/IP Netzwerk

Interfacebeschr.

(20)

Was genau ist SOAP?

• SOAP definiert die folgenden Dinge:

– Ein XML-basiertes Nachrichtenformat für Einweg-Kommunikation

• definiert, wie beliebige Nachricht in XML-Rahmen eingepackt werden kann

– Ein Prozessierungsmodell, dass festlegt,

• welcher Teil einer Message von wem bearbeitet werden soll

– Ein Erweiterungsmodell, wie neben der Nachricht beliebige weitere Informationen (z.B. Sicherheitsinformationen) mitübertragen werden können

– Ein Protokoll-Binding Mechanismus, der es erlaubt, SOAP über verschiedene Protokolle zu übertragen

– Konventionen, um über SOAP RPC-Aufrufe zu übertragen

(21)

SOAP als Nachrichtenframework

• SOAP != RPC

– SOAP ist Nachrichtenframework und primär kein RPC Framework

• SOAP ist leichtgewichtig

– definiert zustandslose, one-way Nachrichtenübertragung

• Komplexere Interaktionen Aktionen können "on-top" deklariert werden, z.B

– RPC ist on-top implementiert als "SOAP RPC representation"

• SOAP abstrahiert vom Nachrichtentransport

– HTTP, SMTP nur zwei von vielen Möglichkeiten

– TCP Transport ist auch möglich

(22)

SOAP Verkehr über mehrere Knoten

• SOAP erlaubt, dass Nachrichten über mehr als einen Übertragungsknoten gehen

– Die Zwischenknoten nennt man auch Relays – Knoten können evtl. Nachrichten verändern

– Knoten nehmen eine gewisse "Rolle", z.B.

Relay ein

– Prozessierungsinformationen in der SOAP Nachricht (im SOAP Headerteil) bestimmen, welche Informationen für welchen Knoten / Knotenart bestimmt ist

Sender

Relayknoten

(23)

Aufbau von SOAP Nachrichten

• MIME-basiertes Email Format

– optional mit Attachments

• Nachrichtenrumpf ist SOAP Message = SOAP Envelope

– SOAP XML format – besteht selbst aus

• SOAP Header

– Metadaten, wie Security, Sessioninformation, etc.

• S OAP Body

– Nutznachricht(en)

Primärer MIME Nachrichtenrumpf

Attachment Attachment

Attachment SOAP Message

...

SOAP Envelope

Header Eintrag Header Eintrag

Rumpf Eintrag

...

SOAP Header

SOAP Body

(24)

SOAP Message – RPC Anfrage

POST /StockQuote HTTP/1.1

Host: www.stockquoteserver.com

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn SOAPAction: "Some-URI"

<SOAP-ENV:Envelope xmlns:SOAP-ENV=

"http://schemas.xmlsoap.org/soap/envelope"

SOAP-ENV:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding">

<SOAP-ENV:Header>

<t:Transaction xmlns:t="some-URI"

SOAP-ENV:mustUnderstand="1">5</t:Transaction>

</SOAP-ENV:Header>

<SOAP-ENV:Body>

<m:GetLastTradePriceInput xmlns:m="Some-URI">

<symbol>DIS</symbol>

<m:GetLastTradePriceInput>

</SOAP-ENV:Body>

(25)

SOAP-Message – RPC Antwort

HTTP/1.1 200 OK

Content-Type: text/xml; charset="utf-8"

Content-Length: nnnn

<SOAP-ENV:Envelope xmlns:SOAP-ENV=

"http://schemas.xmlsoap.org/soap/envelope"

SOAP-ENV:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding">

<SOAP-ENV:Body>

<m:GetLastTradePriceOutput xmlns:m="Some-URI">

<price>34.5</price>

<m:GetLastTradePriceOutput>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

(26)

Web Service Definition Language (WSDL)

Beschreibung der Schnittstellen von

Web-Services

(27)

part

XMLSchema

input output

soapAction soap:binding

soap:body soap:body

input output

port

operation operation Type System

Message

Port Type

Binding

Service

(28)

WSDL Interfacebeschreibung (Teil 1)

<xml version=21.0">

<definitions name="StockQuote"

targetNamespace="http://www.my.com/stockquote.wsdl"

xmlns:tns="http://www.my.com/stockquote.wsdl"

xmlns:xsd1="http://www.my.com/stockquote.xsd"

xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap"

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

<types>

// Hier kommen Typdefinitionen

</types>

// Hier kommen Definitionen von message(s) // Hier kommen Definitionen von port(s)

// Hier kommen Definitionen der Bindungen an einen Transport // Hier kommt die Definition des Services

(29)

Beispiel WSDL – Inhalt Tag <types>

<schema xmlns="http://www.w3.org/2000/10/XMLSchema">

<element name="TradePriceRequest">

<complexType>

<all>

<element name="symbol" type="string"/>

</all>

</complexType>

</element>

<element name="TradePrice">

<complexType>

<all>

<element name="price" type="float"/>

</all>

</element>

</schema>

(30)

WSDL Beispiel - Messages

<message name="GetLastTradePriceInput">

<part name="body" element="xsd1:TradePriceRequest"/>

</message>

<message name="GetLastTradePriceOutput">

<part name="body" element="xsd1:TradePrice"/>

</message>

Zwei Messages bilden üblicher Weise eine Methode:

Die eine Message GetLastTradePriceInput transportiert die Argumente der Methode

Die ander Message GetLastTradePriceOutput transportiert den oder die Returnwerte

Argumente und Returnwerte sind dabei die part-Teile einer Message

(31)

WSDL Beispiel – Port(s)

<portType name="StockQuotePortType">

<operation name="GetLastTradePrice">

<input message="tns:GetLastTradePriceInput"/>

<output message="tns:GetLastTradePriceOutput"/>

</operation>

</portType>

PortType Deklarationen in WSDL entsprechen Interfaces Ein "Interface" kann mehrere operation (Methoden) haben

Jede Methode (operation) wird üblicher Weise durch input bzw. output

message beschrieben

(32)

WSDL Beispiel - Bindung

<binding name="StockQuoteBinding" type="tns:StockQuotePortType">

<soap:binding style="document"

transport="http://schemas.xmlsoap.org/soap/http">

<operation name="GetLastTradePrice">

<soap:operation

soapAction="http://www.my.com/GetLastTradePrice"/>

<input>

<soap:body use="literal"

namespace="http://www.my.com/stockquote.xsd"

encodingStyle="http://schemas.xmlsoap.org/soap/encoding"/>

</input>

<output>

<soap:body use="literal"

namespace="http://www.my.com/stockquote.xsd"

encodingStyle="http://schemas.xmlsoap.org/soap/encoding"/>

</output>

</operation>

</binding>

(33)

WSDL Beispiel - Service

<service name="StockQuoteService">

<documentation>My first Web Service</documentation>

<port name="StockQuotePort" binding="tns:StockQuoteBinding">

<soap:address location="http://www.my.com/stockquote"/>

</port>

</service>

Eine Web-Service Definition besteht aus ein oder mehreren port Angaben

Jede port Angabe wird über ein Binding mit einem portType (Interface) und dessen konkreten Umsetzung über Soap Messages assoziiert

Weiter werden Angaben zur Dokumentation und Adresse gemacht

(34)

Operationen in WSDL

• typisch sind Anfrage-Antwort Formen von Operationen als synchrone Operationen

• Aber es sind auch möglich:

– Einwegoperationen (Anfragen ohne Antwort)

– Pollen der Antwort zu einem späteren Zeitpunkt

– Notifikation

(35)

JAX-WS

• Web-Service Technologie von JEE ab Version 1.5

• Einfaches, Komponenten-basiertes Programmiermodell

• Verdeckt alle komplizierten Details unter einfach zu bedienenden Schnittstellen

• Basiert auf SOAP und WSDL und bietet über diese Interoperabilität

• verwendet Annotations zur einfachen Definition von Web-Services über annnotierte Klassen

• Verwendet JAXB zur Codierung von JavaBeans in

XML Typen

(36)

Architektur JAX-WS Web-Service Framework

• Client greift über generierte Service-Klasse auf Web-Service zu

• Service Klasse liefert als Fabrik dynamische Proxy-Objekte zum Zugriff auf Web-Service Interfaces (Ports)

• Runtime implementiert Anfrage / Antwort Protokoll über SOAP Nachrichtenaustausch

• JAXB wird als Transformationstechnologie Java <-> XML benutzt

Client Code Proxy / Port JAX-WS Runtime

Service Endpunkt Implementierung JAX-WS Runtime SOAP

Nachricht

WSDL- Beschr.

HTTP

(37)

Implementierungsklasse mit Annotation(en)

• Implementierungsklasse ist normale Java Klasse; kein Interface notwendig

• annotiert mit Annotation @WebService

• importiert javax.jws.WebService

• sollte nicht das Default Package verwenden

package hello;

import javax.jws.WebService;

@WebService

public class CircleFunctions {

public double getArea(double r) {

**return java.lang.Math.PI * (r * r);**

}

public double getCircumference(double r) { **return 2 * java.lang.Math.PI * r; }**

}

(38)

JAX-WS Annotationen

• @WebService

• endpointInterface Parameter zur optionalen Angabe eines Interfaces

• name Parameter zum Ändern des Namens der WebServices innerhalb der WSDL

• serviceName Parameter zum Ändern des port (Interface Namens)

• ...

• @WebMethod

• Parameter exclude, um Methode von Web-Service Interfaces auszuschließen

• ...