Das Web als Präsentations- / Kommunikationsschicht

Präsentation zum Thema: "Das Web als Präsentations- / Kommunikationsschicht"—  Präsentation transkript:

1 Das Web als Präsentations- / Kommunikationsschicht
Clemens Düpmeier,

2 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 Clemens Düpmeier,

3 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) Clemens Düpmeier,

4 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 Clemens Düpmeier,

5 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 Clemens Düpmeier,

6 Service-orientierte Anwendung
SOA- Anwendung Browser Browser Browser Internet Firewall Intranet Web-Server DBMS Service-API HTML-Gen. Komm.schnittst. Zugriff auf App.logik Businesslogik Datenzugriff Web-Container stellt HTML-Oberfläche und Service-API bereit Applikationsserver enthält Businesslogik Datenbank Clemens Düpmeier,

7 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, ... Clemens Düpmeier,

8 Services / Serviceschnittstellen
Beispiel: RESTful Services Clemens Düpmeier,

9 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 9 Gruppe WebUIS | IAI |

10 RESTful Services RESTful Services sind zustandslos
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 Resource GET <contact id="2467"> </contact> Client XML-Repräsentation 10 Gruppe WebUIS | IAI |

11 Struktur von URL’s URL's zum Aufruf von Services
Rückgabe der Liste aller Kontakte Rückgabe der Kontakte, bei denen „lastname“ den Wert „Düpmeier“ hat (Suchinterface) nicht gut! 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 11 Gruppe WebUIS | IAI |

12 Rückgabeformate und Verlinkung
<contact id="2467"> <lastname>Düpmeier</lastname> <surname>Clemens</surname> <birthday> </birthday> <mother xlink:href=" Anna Nobel </mother> </cd> 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 12 Gruppe WebUIS | IAI |

13 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 13 Gruppe WebUIS | IAI |

14 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) 14 Gruppe WebUIS | IAI |

15 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. 15 Gruppe WebUIS | IAI |

16 Beispieldaten und Mapping
in Datenbank id lastname surname birthday 2467 Düpmeier Clemens Objektrelationales Mapping @Entity @XmlRootElement public class Contact { @ID long id; String lastname; String surname; Date birthday; } Java To XML Mapping (JAXB) XML-Darstellung zum Übertragen <contact> <id>2467</id> <lastname>Düpmeier</lastname> <surname>Clemens</surname> <birthday> </birthday> </contact> Clemens Düpmeier,

17 Progr. von RESTful Service über Jersey
@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 String id) { return contactDao.getContact(id); Die Pfadangaben definieren, welche Methode bei welcher URL aufgerufen wird Das zurückgegebene Objekt wird automatisch nach XML serialisiert, wenn das Objekt JAXB gemappt ist 17 Gruppe WebUIS | IAI |

18 Serviceaufruf durch mobilen Client
JSON GET Content-Type: application/json { "id":"2467", "lastname":"Düpmeier", "surname":"Clemens", "birthday":" " } Kontakte-Server JPA->XML->JSON Clemens Düpmeier,

19 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 19 Gruppe WebUIS | IAI |

20 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) 20 Gruppe WebUIS | IAI |