Web Services

Introduction to Service-Oriented Computing Layers: Resource management ↔ application logic ↔ presentation (↔ client) Distributed Systems: Laufen zeitgleich auf mehreren computern und kommunizieren über Netzwerk Austausch erfolgt über jeweiligen application logic layer. Oft schwierig wegen Verwendung unterschiedlicher Betriebssysteme, Progammiersprachen, etc.

Lösung: Service-Oriented Computing, d.h. Kommunikation über eigens eingerichteten Service. Vergleichbar mit facade software pattern.

Wichtige Begriffe (Web) Services: Eigenständige Module, welche auf XML-Basis über ein Netzwerk aufgefunden, beschrieben, programmiert, orchestriert und veröffentlicht werden können. Service providers: Organisationen, welche Implementierungen, Beschreibungen und Support für einen Service anbieten. Service clients: Nutzer und Organisationen, welche Services Nutzen. Service aggregators: Organisationen, welche mehrere Services zu einem neuen vereinen. Service-oriented architecture (SOA): Art, software so zu designen, dass Services, über veröffentlichte und auffindbare interfaces, angeboten werden.

Characteristika von Web Services (WS) Erfüllung einer einzigen Aufgabe als abgeschlossenes Modul (zB Input PLZ, Output Wetter) Teilen eines formalen Vertrags, welcher Informationsaustausch klar regelt Abstrahierung der darunterliegenden Programmlogik, diese bleibt verborgen Schwache Koppelung: Service interface unabhängig von Programmiersprache, Plattform etc.. Kann leicht ausgetauscht werden. Wiederverwendbarkeit durch andere Applikationen Dynamische Einbindbarkeit und Auffindbarkeit durch andere Applikationen Beschrieben durch standard description language (WSDL/WADL), functional- und non- functional requirements Verbreitet über das Internet durch bestehende Protokolle wie HTTP

Funktionale Charakteristika geben genauere Auskunft über das Verhalten des Services, z.B. wie er aufgerufen oder lokalisiert wird, wie die Struktur des Nachrichtenaustausches ist. Frage des Systemdesings. Nicht-Funktionale Charakteristika beziehen sich auf Qualitätsindikatoren, wie Antwortzeit, Sicherheit, Authentifikation, etc.. Frage der Systemarchitektur.

SOA weist im Vergleich zu Java geringe Kopplung auf, etwa wegen asynchroner Kommunikation, unterschiedlichen darunterliegenden Plattformen, dynamisch gebundenen Services, Unabhängigkeit von Betriebssystem und Programmiersprache1

Typen von Web Services SOAP/WSDL basiert: Service interface exponiert durch WSDL Dokumente, Nachrichtenaustausch über SOAP, client code kann über WSDL Beschreibung generiert werden. Ist mittlerweile fast schon überholt. REST (Respresentational State Transfer): Einfache Kommunikation mit Web Services,

1 Vollständige Gegenüberstellung: siehe WebServices-Vortrag-2016.pdf F 13 Resourcen durch URIs identifiziert, deren Status über HTTP durch GET, PORT, PUT, DELETE manipuliert wird. Sehr populär.

Anwendungsgebiete von (Web) Services liegen zwischen Organisationen/Geschäftspartnern, und auch innerhalb einer Organisation, z.B. als Schnittstellen zwischen veralteten Systemen und neuen ERP-Systemen

Vorteile von Web Services Interoperabel: Verbindung unterschiedlicher Systeme, Nutzung üblicher Standards Ökonomisch: Keine Installation, Wiederverwendbarkeit von Komponenten Automatisch: Kein menschliches Zutun nötig Zugänglich: Zugang zu veralteten Systemen und internen Anwendungen Verfügbar: Unabhängig von Endgerät, Zeit und Ort Lösung von Integrationsproblemen; Vervollständigung automatisierter Infrastruktur

Service Oriented Architectures ...sind ein abstraktes Pattern, welches auf viele Web Services zutrifft SOA ist schwach gekoppelt mit business functions als geteilte und wiederverwendbare services Rollen: Service(Rg), -Requestor und -Provider Publish: Bereitstellung einer Beschreibung Find: Abrufen der Beschreibung Bind: Requestor stellt Interaktion mit Service her, indem die „binding details“ in der Beschreibung angewendet werden (Lokation, Kontaktierung, etc.)

Rollen aus geschäftlicher bzw. technischer Sicht Service-Provider: Owner eines Services bzw. Plattform, welche den Service bereitstellt Service-Requestor: Geschäft bzw. Applikation Service-Registry: Durchsuchbares Register von Service-Beschreibungen

SOA-Layers: Operational Systems (DBs, ERP, …) → Komponentenbasierte Servicerealisationen → Infrastruktur Services → Business Services → Business Processes → Business Domain

Standards SOAP (W3C) – Nachrichtenaustauschformat. „Simple Object Access Protocol“ WSDL (W3C) – Zur Beschreibung was zwischen Provider und Requestor ausgetauscht wird. „Web Service Description Language“ UDDI (OASIS) – Basis für ein Datenverzeichnis Service. „Universal Description Discovery and Integration“

SOAP Andere Protokolle verlangten gewisse Implementierungsvoraussetzungen von Sender/Empfänger. Besteht aus Envelope: Beschreibt Nachrichteninhalt und Zugriff darauf Encoding Rules: bzgl. anwendungsdefinierter Datentypen Conventions: Für die Darstellung von Prozeduraufrufen und -antworten Beschreibt wie eine Nachricht formatiert ist, aber nicht wie sie bereitgestellt wird SOAP-Nachricht muss in Transport-Protokoll (meist HTTP) eingebettet sein SOAP transferiert Nachrichten zwischen Serviceinstanzen, die durch WSDL beschrieben werden Fundamentale WS-Nachrichtenaustauschpatterns:

Strukur einer SOAP-Nachricht: Envelope ← (Header← Header Entries) (optional) ← Body ← Body Entries

Nachrichten werden entlang SOAP-Nodes (transmit, receive, process, relay) geleitet. SOAP-Kommunikationsmodell unterstützt (2*2=)4 Styles 2 Kommunikationsstyles: Remote Procedure Calls (RPC) und Document Exchange (nur Nachrichten) 2 Encodingstyles: Encoded (Datentypen verschlüsselt in Nachricht) und literal (verweist auf XML-Schema) Relevant sind jedoch nur document/literal und RPC/literal

RPC-Style Web Services erscheinen für client als remote Objekt. Requests werden durch Methodenaufrufe mit bestimmten Parametern ausgeführt => Starke Kopplung durch hardwireing 111<...

Document-Style Web Services sind nachrichtengetrieben. Request als Document von Client an Service, Antwortnachricht erfolgt synchron oder asynchron ...

Error Handling in SOAP über env:Fault Element mit Kindern . Bei Error wird env:Fault in Body retourniert.

SOAP & HTTP: Client sendet POST mit SOAP Nachricht → Service Listener empfängt → Service Proxy decodiert Nachricht → Anwendung erhält function call, arbeitet ab, returned Wert → Service Proxy codiert Nachricht → Service listener sendet Antwort → Client erhält HTTP mit SOAP Antwort

Vorteile von SOAP: Einfach (XML), plattformunabhängig, firewallfreundlich, Nutzung offener Standards, interoperabel (XML ist programmiersprachenabhängig), akzeptiert, beständig Nachteile von SOAP: Geringe Performance, stateless (requester muss sich immer neu „anmelden“), keine Serialisierung nach Referenz (Objekte nicht synchronisiert mit nicht Lokalen) WSDL Web Service Description Language ist ein XML-basiertes Spezifikationsschema. Es beschreibt die Schnittstelle eines Web Services, dient als Vertrag zwischen provider und client und beschreibt weiters was ein Service macht, wo er zu finden ist und wie er aufgerufen werden kann

WSDL gliedert sich in abstrakten (Interface) und konkreten (Implementierung) Teil. Das Interface beschreibt die generelle Struktur, Operationen, Parameter und abstrakte Datentypen des WS. Types – messages – operations – port types. Die Implementierung bindet das Interface an konkrete Netzwerkadresse, Protokoll und Datenstrukturen. Ein Client kann eine Bindung zu einer Implementierung herstellen. Bindings – services and ports.

Signaturen und I/O messages in . Bestehend aus

und Nachrichten. Definiert SOAP style (RPC/Document) und SOAP Protokoll Definiert konkrete Operationen für referenzierten Port. Zudem die Kodierung (literal/encoded). Default: literal. Definiert ports des WSReferenziert existierendes binding URL des Services<... Beispiel F 49ff

Messaging Patterns One-way: Sender –SOAP request→ Empfänger

Request/response: Sender –SOAP request→ Empfänger Sender ←SOAP response– Empfänger

Notifications: Sender ←SOAP request– Empfänger

Solicit/response: Sender ←SOAP request– Empfänger Sender –SOAP response→ Empfänger

UDDI Universal Description Discovery and Integration. „Gelbe Seiten für Web Services“. XML-Basiert. 3 Hauptsäulen: white pages – Adresse, Kontakt und bekannte Identifier yellow pages – Industrielle Klassifikation green pages – Metainformation über Services

Wurde nie richtig populär, weil es sehr limitiert ist (keine komplexen Queries), rein technischen Fokus hat (keine Integration von Produktdaten, etc.), zu generisch ist und zu viele Fun-Einträge hat.

Intraorganisational trotzdem noch brauchbar. (ERP ↔ EDI ↔ …). Java API for XML Web Services (JAX-WS) Einsatz von POJOs mit speziellen Annotationen (@WebService, @SOAPBinding, @WebMethod, @WebParam, @WebResult, @OneWay) XML-Verarbeitung durch JAX-B (Java Architecture for XML Binding) Marshalling: Java-Objekt → XML; Unmarshalling: XML → Java-Objekt

Anwendungsentwicklungsvarianten Contract First: WSDL to Java. Besser für komplexe Web Service Projekte mit vielen Stakeholdern/Partnern. Tool: wsimport Contract Last: Java to WSDL. Besser geeignet für kleinere Projekte mit beschränkten Anforderungen. Tool: wsgen

Es gibt eine kaum überschaubare Anzahl anderer WS-Standards, daher wird immer mehr mit reinem XML oder JSON gearbeitet

RESTful Web Services REpresentational State Transfer. Basiert auf Ressourcen und der Manipulation deren Status (=Variablenbelegung zu gegebenem Zeitpunkt). Designprinzipien: REST-Server bietet Zugang zu Ressourcen. Client manipuliert diese über HTTP Methoden. Verzeichnisartige Struktur von URIs zur Adressierung von Ressourcen. Transfer von XML/JSON Daten, um Status der Ressourcen zu ändern. Statelessness – Verantwortung für State-Management liegt zur Gänze beim Client.

Änderung von Resourcen über HTTP: GET, PUT (update), POST (create), DELETE.

Über MIME-Types im HTTP Accept Header kann Format der gewünschten Inhalte angegeben werden (application/json, application/xml, …)

JSON: Wertzuweisung: „identifier“ : „value“ Objekt: „identifier“ : { … } Array: „identifier“ : [ {…}, {…}, … ]

Java API for RESTful Web Services (JAX-RS) Einsatz von POJOs mit speziellen Annotationen (@GET, @PUT, @POST, @DELETE, @Path, @Produces, @Consumes, ...)

HEAD and OPTION Request (siehe F81)

Summary Web Services unterstützen interoperable Interaktion zwischen Maschinen Web Services können Teil von Webanwendungen sein, haben selbst aber kein GUI Web Services werden zur Integration eingesetzt 3 Kernstandards: SOAP, WSDL, UDDI RESTful services sind eine mächtige Architektur für Maschineninteraktion Linked (Open) Data

Introducing Open Data Open Data sind Daten, welche von jedem für alles möglich kostenlos genutzt, modifiziert und geteilt werden können. Dadurch sollen Innovation, neue Produkte und ökonomischen Wachstum vorangetrieben werden. Prinzipien: Verfügbarkeit und Zugriff – Vollständig, vorzugsweise über Internet, in geeigneter Form Wiederverwendbarkeit und -verteilung müssen gestattet sein Universelle Partizipation – Alle müssen sie nutzen dürfen, auch kommerziell vs Big Data: Volume (wird immer noch größer), Variety (unterschiedliche Datensätze/ Metadaten/Formate), Velocity (ständige Veränderung: neue Daten kommen, alte gehen) Open Government Data (OGD) – Weltweite Bewegung, um öffentliche Daten zugänglich zu machen Open (Government) Data Prinzipien: Vollständig, aus erster Hand, zeitnah, zugänglich, für Maschinen lesbar, für Alle zugänglich, in nicht exklusivem Format, lizenzfrei, dauerhaft, kostenlos Beispiel für Nutzung: Eversport – Verbindung von Open, 3rd party und own Data. Unterschiedliche Formate und Angaben sind jedoch problematisch in der Verarbeitung

What's Linked Data Suchkeywords werden nicht mehr nur durch abgleich mit anderen Zeichenfolgen, sondern im Sinne des „Semantik Web“ wird deren Bedeutung miteinbezogen, z.B. „good“ - bestimmtes Rating, „neighborhood“ - Umkreis, „pizza“ - italienisches Restaurant Semantic Web: Informationen sollen auch für Maschinen les- und verstehbar sein. Identifikation durch URIs, aufzeigen der Bedeutung durch Metadaten. Prinzipien: Alles (Personen, Themen, …) hat eine URI, über HTTP erreichbar sein, mit brauchbarer Information versehen sein und weiter zu mehr Informationen führen Vorteile: Bedeutungen werden automatisch verarbeitet, heterogene Daten können zusammengeführt werden, Gewinnung impliziter aus expliziter Information Representierung von Daten mittels RDF (Resource Description Framework) Abfrage mittels SPARQL

Das Web 1989: URIs – Links zwischen Dokumenten (href) – HTTP Das Web of Data 2015: URIs – Links mit Typen zwischen Entitäten (RDF) – HTTP

Eine Ontologie ist eine genau definierte, maschinenlesbare Spezifikation eines abstrakten Modells über das Konsens herrscht.

Marrying Linked Data and Open Data into Linked Open Data Linked Open Data macht Alles zu einer Resource, Alles kann annotiert werden, Daten können über das Web hinweg publiziert werden. Linked Open Data ist einfach erweiterbar, zu vereinen, (wieder) zu verwenden und erlaubt komplexe Queries. Vorteile: Wenig Replikation, Wiederverwertung von Daten, Klarheit über Ähnlichkeit von Datensätzen, mehr Innovation durch neue In-Beziehung-Setzung, Wissensgenerierung durch In-Beziehung-Setzung 5 Star Rating Schema für die Einordnung der Qualität von Linked Open Data: 1 – Daten sind im Web mit offener Lizenz, 2 – zzgl. Maschinenlesbares Format, 3 – zzgl. nicht-proprietäres Format (z.B. CSV statt Excel), 4 – zzgl. W3C Standards zur Identifikation (z.B. RDF), 5 – zzgl. Link zu anderen Datensätzen

Linked Open Data Beispiel:

JPA and Hibernate

JDBC Java DataBase Connectivity dient dem Zugriff auf relationale Datenbank von Java Programm aus.

Nachteile: Viel code auch für einfaches CRUD, manuelles mapping von ResultSet zu POJO, manuelle synchronisation bei DB Änderungen.

JPA/Hibernate Object Relational Mapping (ORM) ermöglicht Fokussierung von Geschäftskonzepten an der DB statt, abstrahiert von manueller DB-Kommunikation, übernimmt Synchronisation, ist weitgehend DB unabhängig, übernimmt Performance Fragen Java Persistence API (JPA) ist eine Spezifikation für Persistenzmanagement und O/R mapping mit Java. JPA bildet POJOs auf relationale Datenbanken ab und ist Standardisiert. Hibernate ist eine JPA-Implementierung mit zusätzlichen features. Achtung: Vieles wird im Unsichtbaren ausgeführt, daher sollte man Datenbanken gut verstehen und mit SQL-DDL prüfen, was Hibernate mit den Annotationen wirklich macht. Selbiges geht für Queries mit in persistence.xml Annotierte POJOs bilden üblicherweise einen TABLE, Attribute Spalten und Zeilen konkreten Entitäten. Annotationen @Entity - Klasse ist eine Entität @Id – Primary Key @Temporal – Muss für typen java.util.Date/Calendar angegeben werden @TemporalType – Für spezielles Mapping von Temporals als DATE/TIME/TIMESTAMP @Transient – Feld wird nicht persistiert

@MappedSuperclass – Annotationen werden an Subklassen weitergegeben @GeneratedValue – z.B.: @GeneratedValue{strategy=GenerationType.AUTO)

@Embedded – Feld mit Instanz einer Embeddable Klasse @Embeddable – Klasse deren Instanzen als Teil einer anderen Klasse gespeichert werden „Owner“ ist von zwei in Beziehung stehenden Entitäten diejenige, die eine Referenz auf die andere enthält, d.h. wo der foreign key gespeichert wird.

Relationen: Es muss stets der Owner angegeben werden @One-to-One – wo auch immer der foreign key gespeichert werden soll @One-to-Many, @Many-To-One – auf der Many Seite @Many-To-Many – auf irgendeiner der beiden Seiten

@JoinColumn Spezifiziert den Column, welcher den Foreign Key hält

Attribute (…=..., …) fetch FetchType.LAZY Referenzierte Entität wird erst geladen, wenn nötig FetchType.EAGER Sofortiges Laden der Entität cascade CascadeType.ALL impliziert PERSIST, MERGE, REMOVE, REFRESH, DETACH; default is CascadeType.NONE mappedBy „...“ referenziert Feld im Owner

Persistence Concepts Persistence Unit (PU) ist eine Sammlung von Entitätsklassen. Mapped Klassen zu Datenbank. Werden in persistence.xml definiert. Persistence Context (PC) ist eine Sammlung von gemanageten Entitätsinstanzen. Entity Manager (EM) ist eine API zur Interaktion mit dem PC, manipuliert PC, erstellt, löscht und findet Instanzen von Entitäten und führt Abfragen aus. Z.B.: em.persist(studentEntity), em.find(Student.class, 13).

Entity Lifecycle: new() Enstehen der Entity→ persist() Hinzufügen zu PC → detach()/merge() aus/zu PC || remove() || Transaktioncommit und damit Speicherung in DB

Java Persistence Query Language (JPQL), Hibernate Query Language (HQL) Für komplexe Anfragen. JPQL queries sind auch immer in HQL valide, umgekehrt nicht. Ausführung via EntityManager em.createQuery bzw. em.createNativeQuery ähnlich SQL, bezieht sich aber auf Entitäten der Applikation und nicht auf die tatsächlichen Tables. Gibt Entitäten zurück, keine ResultSets.

Static Query: Spezielle Query mittels Annotation in abzufragender Klasse. Nützlich um query cache besser zu nutzen. @NamedQuery(name=“queryName“, query=“SQLQuery ...“). Nutzung z.B.: em.createNamedQuery(„queryName“, Entity.class).getResultList(). Alternativ zu JPQL: Criteria API.

JPA/Hibernate vs JDBC Mit JDBC 100% Kontrolle, Nutzung nativer DB features, JPAs Datenbankunabhängigkeit oft irrelevant, da sich DB selten ändert, Hibernate-Session-management mühsam in MVC Umfeld

Social Software

Social Software at a glance Auch bekannt als Web 2.0, umfasst Social Software internetbasierte Kommunikations- und Kollaborationstools. Inhalte sind meist usergeneriert. Fokus auf Userinteraktion. Beispiele: facebook, Google, XING, amazon, skype, youtube, PayPal, WhatsApp, Twitter.

Twitter API Twitter ist ein Microblogging service, mit dem Ziel allen die Möglichkeit zu geben Ideen und Informationen sofort und ohne Barrieren zu verbreiten. Twitter4J ist eine Java library um Zugriff auf die Twitter API zu geben.

Client-Side Javascript Development – Angular JS

Overview Ember.js, Backbone (template engines), ReactJS (UI framework), AngularJS.

AngularJS Im Vergleich zu einer CRUD Applikation mit MVC Pattern, bringt verchiebt AngularJS auch Model (DB) und Controller (Logik) zum Client. AngularJS ist also clientseitige Technologie für dynamische WebApplikationen. Baut auf HTML auf, nutzt MVC clientseitig. Gut geeignet für CRUD, für z.B. Games weniger.

Directive: Neu definiertes HTML-Attribut mit eigener Funktionalität → Z.B. Listener für ein Element; verändert also DOM elemente. Matching über Namen: ngBind = ng-bind = ng:bind = data-ng-bind = x-ng-bind =ng_bind. {x-, data-} werden also entfernt, {:, -, _} werden durch camelCase ersetzt. Vorderfinierte directives werden entweder nur ng Präfix gekennzeichnet, oder ersetzen einfach bereits vorhandene, wie z.B.

oder . Beispiele2: ng-hide/show Versteckt/zeigt ein ng-bind Ersetzung des Inhalts eines Elements Element basierend auf mit expressionwert einer expression ng-if Entfernt/stellt Teile des ng-click Definieren von Verhalten bei Klick DOM-Baums basierend auf einer expression her ng-controller Bindet controller an view ng-class Dynamisches setzen von CSS Klassen

Two-way data binding: Template mit HTML und directives bestimmt View anfangs, danach automatische Datensynchronisation zwischen Model und View → Updaten sich gegenseitig bei Veränderungen.

2 Siehe AngularJS Folie 8 für mehr Beispiele Scopes: AngularJS-Applikationen haben genau ein root scope. Child scopes – ähnlich der DOM- Struktur - können z.B. durch directives kreiert werden, um den Ausführungskontext von expressions zu bestimmen. Lifecycle: Creation → Watcher Registration → Mutation (Veränderungen)→ Mutation Observation (grobe Prüfung) →Destruction.

Expressions: z.B. title=“{{attrBinding}}“ oder ng-click=“functionExpression()“. Beziehen sich immer auf $scope, für globalen scope $window. Werfen keine errors, erlauben keine control flow functions, wie if/else, oder Objektdeklarationen, akzeptieren Filter. One-time expressions, beginnend mit ::, werden reevaluiert bis das Ergebnis nicht- undefiniert ist. Z.B.:

Controller: Setzen einen Initialstatus und fügen einem Scope-Objekt spezielles Verhalten hinzu. Wird über einen Konstruktor in .js definiert und in .html über ng-controller eingebunden. Mit dem Controller wird somit auch der entsprechende scope im $rootScope platziert. In sich geschachtelte scopes haben Zugriff auf parent scopes. Dort wird auch gesucht, geschrieben (Variablen) aber immer nur im aktuellen scope.

Modul: Ist ein container für unterschiedliche Teile, wie Controller, Services, Filter oder Directives. Durch sie kann Code über Applikationen hinweg wiederverwendet werden. In .js: var someModule = angular.module('modName', []) someModule.controller(…) In .html:

Service: Kapselt View-unabhängige Logik, welche über Applikationen hinweg verwendet werden kann. Z.B.: angular.module['finance', []).factory('currencyConverter', function() {… ng-repeat: Wiederholt Elemente. Z.B.: iteriert über Collection.

Filter: Formatiert Werte von Expressions durch {{expression | filter }}. Kann Argumente haben. In .html: {{greeting| reverse}}

Vorderfinierte Filter, z.B. filter (subsets Array), currency, date, json (in jeweiliges Format) Filter werden vorzugsweise in Controllern verwendet, damit diese nur, wenn Daten from Back-End geladen werden oder wenn sich der Filterausdruck ändert, aufgerufen werden.

$http service Zur Integration eines Back-Ends in die clientseitige Angular Web Applikation. Der Service $http ist ein Wrapper um das XMLHttpRequest Objekt und eine Funktion, welche die Konfiguration als Argument nimmt und ein promise zurückgibt. Die Daten werden weitgehend in JSON gesendet und können mit $.params in form data konvertiert werden. promise: Repräsentiert das eventuelle result einer asynchronen Operation. States: Pending, Fulfilled (promise hat value), Rejected (promise hat reason für Fehler). Fulfilled XOR Rejected, kann sich auch nicht mehr ändern. Interaktion mittels then: promise.then(onFulfilled, onRejected) http$3 Methoden liefern alle ein HTTPPromise Objekt als Antwort. Einige haben shortcuts nach dem Schema name(url, [config]) und zwar: get, delete, head, jsonp, post, put, patch.

Web Browser verhindern in der Regel, dass Webseiten scripts von anderen Domains holen bzw. ausführen. Same-origin policy erlaubt ausdrücklich scripts von derselben Seite. JSONP: Mittels