Forschungszentrum Karlsruhe Technik und Umwelt Clemens Düpmeier, 16.02.2014 Das Web als Präsentations- / Kommunikationsschicht.

Forschungszentrum KarlsruheTechnik und Umwelt

Clemens Düpmeier, 11.04.2023

Das Web als Präsentations- / Kommunikationsschicht



Verteilte Anwendungen und das Web

• Webtechnologie bietet guten Präsentationslayer– für Anwendungen, die viele Anwender erreichen müssen

• wenige Voraussetzungen beim Anwender (Browser + Internetanschluß)

• Komplexere Resourcen, wie Datenbank, werden beim Anwendungsanbieter bereitgestellt

• Update, etc. der Anwendung einfacher

• Web-Services und Restful Web-Service-Technologien – sind besser als andere Verteilte Objekttechnologien für

Kommunikation über das Internet geeignet• da Firewall transparent• Dokument-Transfer über Web-Services (SOAP) ist weiter routebar

und bietet damit gute Message-Transfer Möglichkeiten über Internet



Verteilte Komponenten und Webtechnologien

• Ersetzen Webtechnologien die Verteilten Komponenten-Technologien?

– Nein, sie ergänzen diese nur

– In komplexen Business-Anwendungen stellt das Web nur eine

weitere Schicht dar

– Bei kleineren Anwendungen kann eine Webanwendung +

Datenbankschicht einen komplexeren Business-Layer

überflüssig machen

• Hier gibt es die Tendenz zu "leichgewichtigen" Business-

Modellen, wie Web-Beans (EJB lite)



Was ist SOA – Hat das was mit Web zu tun?• SOA (Service Oriented Architecture, dienstoriente Architektur) ist

– nur ein Architekturmodell, um Dienste von Mitarbeitern und

Organisationen zu strukturieren und über das Netzwerk zu nutzen

– hat nichts unmittelbar mit Web oder Web-Services zu tun• SOA ist durch allgemeine Merkmale gekennzeichnet

– Jeder Dienst ist in sich abgeschlossen und kann eigenständig genutzt

werden

– Der Dienst ist über Netzwerk verfügbar

– Bei der Nutzung reicht es, seine Schnittstelle zu kennen

– Der Dienst ist dynamisch gebunden: er wird erst zur Laufzeit lokalisiert

und eingebunden

– Plattformunabhängig und von keiner Programmiersprache abhängig



Was ist SOA – Hat das was mit Web zu tun? (2)• Prinzipiell weist CORBA einige Merkmale von SOA auf und

– könnte als Implementierung für SOA-Anwendungen genutzt werden,

allerdings gibt es da einige Probleme• CORBA Kommunikation ist nicht Internet-transparent

• CORBA ist schwer zu implementieren• Web-Services und Restful Web-Services haben viele der

Kommunikationseigenschaften, die SOA-Architekturen brauchen

– Plattform- und sprachunabhängig – leicht zu implementieren

– Internet-Transparenz

– Unabhängigkeit von Implementierung und dynamische Bindbarkeit

=> Eine Kombination von Verteilten Komponenten Implementierungen

mit Web-Service orientierten Schnittstellen nach außen bietet gute

Grundlage für SOA-Anwendungen



Service-orientierte Anwendung

Internet

Intranet

Browser Browser Browser

Firewall

HTML-Gen.

Zugriff auf App.logik

DBMS

Datenbank

Web-Server

BusinesslogikDatenzugriff

Komm.schnittst.

Applikationsserverenthält Businesslogik

Web-Container stelltHTML-Oberflächeund Service-API bereit

Service-API

SOA-Anwendung



Was bietet Java?

• Low Level Kommunikationsschnittstellen mit HTTP-Servern• Java-basierte Web-Applikationsserver

– Servlets, JSP, JSF (Web-Komponenten Technologien) als

Bestandteil von JEE

– Unzählige darauf aufsetzende Webframeworks von

Drittgruppen• Web-Service und Restful Web-Service Frameworks als

Bestandteil des JEE Standards• Auf JEE-Applikationsserver aufbauende SOA-Plattformen und

SOA-Technologien

– wie OpenESB, BPEL, ...



Services / Serviceschnittstellen

Beispiel: RESTful Services


9 Gruppe WebUIS | IAI | 03.02.2009

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



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

ContactID=2467

Client

http://addressbook.org/contact/2467

GET<contact id="2467"> ...</contact>

XML-Repräsentation

Resource



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

Spezialisierung der Rückgabe



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>



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



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)



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.


Beispieldaten und Mapping


@Entity@XmlRootElementpublic class Contact {

@IDlong id;String lastname;String surname;Date birthday;

}

<contact> <id>2467</id> <lastname>Düpmeier</lastname> <surname>Clemens</surname> <birthday>10.07.1955</birthday></contact>

ObjektrelationalesMapping

Java To XML Mapping (JAXB)

id lastname surname birthday

2467 Düpmeier Clemens 10.07.1955

in Datenbank

XML-Darstellung zum Übertragen



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); }}


Serviceaufruf durch mobilen Client


GET http://contact.org/contacts/2467Content-Type: application/json

{"id":"2467","lastname":"Düpmeier","surname":"Clemens","birthday":"10.07.1955"

}

Kontakte-ServerJPA->XML->JSON

JSON



Clients • RESTful-Services sind unabhängig von Programmiersprache

– 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



Anwendung(en)• Ideal für serverseitige Mashups

– Integration verschiedener Daten + Dienste im Internet zu neuen Webanwendungen

• 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

• Cloud-Computing

– In Clouds ist "everything a service"

• Infrastructure as a service (IAAS)

• Software as a service (SAAS)

• Programs as a service (PAAS)

Forschungszentrum Karlsruhe Technik und Umwelt Clemens Düpmeier, 16.02.2014 Das Web als Präsentations- / Kommunikationsschicht.

Documents