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

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, 28.03.2017

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, 28.03.2017

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, 28.03.2017

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, 28.03.2017

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, 28.03.2017

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, 28.03.2017

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

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 | 03.02.2009

RESTful Services RESTful Services sind zustandslos http://addressbook.org/contact/2467 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 | 03.02.2009

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 11 Gruppe WebUIS | IAI | 03.02.2009

Rückgabeformate und Verlinkung <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> 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 | 03.02.2009

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 | 03.02.2009

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 | 03.02.2009

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 | 03.02.2009

Beispieldaten und Mapping in Datenbank id lastname surname birthday 2467 Düpmeier Clemens 10.07.1955 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>10.07.1955</birthday> </contact> Clemens Düpmeier, 28.03.2017

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 getContact(@PathParam(“contactId") String id) { return contactDao.getContact(id); 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 17 Gruppe WebUIS | IAI | 03.02.2009

Serviceaufruf durch mobilen Client JSON GET http://contact.org/contacts/2467 Content-Type: application/json { "id":"2467", "lastname":"Düpmeier", "surname":"Clemens", "birthday":"10.07.1955" } Kontakte-Server JPA->XML->JSON Clemens Düpmeier, 28.03.2017

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 | 03.02.2009

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 | 03.02.2009