ODS 6.0 Schnittstelle

Transkript

1 ODS 6.0 Schnittstelle Dieter Müller Server Developer 1

2 Architektur ODS-Schnittstelle Vergleich ODS 5.x <-> ODS 6.0 ODS 5.x ODS 6.0 ODS Client ODS Server ODS Client ODS Server Stub ORB IIOP Generiert aus CORBA IDL Skeleton ORB Protobuf RESTFul Webservice Generiert aus Protobuf IDL HTTP 1.1 Protobuf RESTFul Webservice 2

3 Übersicht Protocol Buffer (Protobuf) Serialisierung von strukturierten Daten Eigene Schnittstellen-Beschreibungssprache Ziel: Einfachheit und Performance Entwicklung von Google seit 2001(seit 2008 Open Source mit Apache 2.0 Lizenz) Plattformneutral und Sprachenneutral Direkt unterstütze Sprachen: Java, C++, Python, JavaNano, Ruby, Objective-C, und C# Binärformat im Gegensatz zu XML und JSON Im Vergleich zu XML: 3-10 mal kleinere Nachrichten und 20 bis 100 mal schneller Aktuelle Version (3.0 liegt als Beta-Release 2 vor) ODS verwendet 3.0 aufgrund der verfügbaren Sprachen 3

4 Übersicht REST (REpresentational State Transfer) Architekturstil für verteilte Systeme (Wurde 2000 in der Dissertation von Roy Thomas beschrieben Bedingungen: Client Server: Trennung der Zuständigkeiten in Client (UI) und Server (Datenmanagement) Stateless: Jede Operation muss in sich abgeschlossen sein. Zustand wird im Client gespeichert oder vom Server in einen Ressourcenstatus umgewandelt.) Caching: Rückgabedaten können als cacheable markiert werden, -> Reduzierung des Datenvolumens Uniform Interface (Einheitliche Schnittstellen): Eindeutige URI s zur Identifikation von Ressourcen Bearbeitung von Ressourcen unabhängig der Darstellung (XML, HTML, JSON,..) Selbstbeschreibende Nachrichten mit allen Informationen, die zur Verabeitung notwendig sind (zum Beispiel bei HTML: Funktion, Content-Type) HATEOAS (Hypermedia as the engine of application state). Die Anwendung führt den Client durch die möglichen Interaktionen. Layerd System: Zwischen Client und Server können weitere Systeme vorhanden sein (zum Beispiel für Load Balancing) Code on Demand: Client kann Code vom Server laden bei Bedarf 4

5 Übersicht RESTFul Webservice RESTFul Webservice Umsetzung des REST Architekturstils auf Basis des HTTP(s) Protokolls. Verwendung der HTTP-Funktionen: GET, POST, PUT, DELETE Methode sicher idempotent cachefähig Verwendung GET X X X Anfordern von Ressourcen POST Java API: JAX-RS (Implementierungen: Jersey, RESTEasy, ) Update von Ressourcen PUT X Anlegen von Ressourcen DELETE X Löschen von Ressourcen 5

6 Übersicht RESTFul Webservice Nachrichtenaufbau HTTP-Request Verb URI HTTP Version HTTP-Response Response Code HTTP Version Request Header Response Header Request Body (Entfällt bei GET) Response Body Verb: HTTP-Funktion, GET, POST, DELETE, PUT URI: Uniform Resource Identifier, zur Identifizierung der Ressource HTTP Version: Beispiel HTTP v 1.1 (z.b. Request Header: Metadaten im Key/Value Format (z.b.: Content-Type: application/x-protobuf ) Request Body: Parameter für den Service Status/Response Code: Rückgabewert mit dem Status vom Server (z.b.: 200 für O.K.) Response Header: Enthält Metadaten im Key/Value Format Response Body: Enthält bei korrekter Verarbeitung, die angeforderten Informationen. 6

7 ODS 6.0 Anforderungen an die neue Schnittstelle Keine Daten in der URL (nur im Payload) Authentifizierung und Session Management Superuser Session Ein Client kann mehrere Sessions (Connections) öffnen Anfordern des Basis- und Applikationsmodells über die Schnittstelle Unterstützung von HTTPS ODS-Api muss nicht der Definition eines RESTFul Webservices entsprechen 7

8 ODS 6.0 Offene Punkte Authentifizierung (Aufgabe des HTTP-Servers, Verwendung von Basic Authentication ) Zuordnung zwischen HTTP-Benutzerkennung und ODS-Benutzerkennung notwendig Session-Verwaltung Wie sollen Authentifizierungs- bzw. Sessioninformationen übergeben werden (URL oder Payload) Maximale Nachrichtengröße von Protobuf ist 64 MB Definition sinnvoller Defaultwerte um Datentransfer zu reduzieren Verwendung von GET oder POST bei Abfragen (GET ist `cacheable` hat aber keine Nutzdaten) Soll eine Abstrahierung der Serveradresse ähnlich dem CORBA-Nameservice verwendet werden Übertragung von Metadaten und Massendaten zusammen oder in separaten Requests Notifications (NEW, MODIFY, DELETE, MODEL, SECURITY) 8

9 Notifications Vorschlag von HighQSoft Verwendung von ServerSentEvents SSE Registrierung über Webservice Aufruf Bestätigung der Registrierung ODS Client Event 1 ODS Server Event 2 Event 9

10 ODS 6 im Hands-On Zugriff auf ODS 6.0 Schnittstelle mit Java Vorbereitungen: Protobuf Compiler (Version 3) herunterladen und entpacken ( Java Bibliotheken in das entsprechende Verzeichnis kopieren Generieren der Javadateien aus den Protobuf Beschreibungsdateien protoc --java_out=src/main/java -I../src.. /src/asam/ods/ods.proto protoc --java_out=src/main/java -I../src../src/google/protobuf/descriptor.proto protoc --java_out=src/main/java -I../src../src/google/protobuf/timestamp.proto Hinweis: Zur Verwendung von Java Basis Datentypen muss die Generierung mit --javanano erfolgen und die Java Nano Bibliothek herunterladen und in das entsprechende Verzeichnis kopiert warden. 10

11 ODS 6 im Hands-On Zugriff auf ODS 6.0 Schnittstelle mit Java (Teil 2) Beispiel für einen Client (Abfrage der Applikationselemente ohne Session-Verwaltung) 11

12 ODS 6 im Fazit Hands-On Erste Zugriffsimplementierungen im Hause waren schnell und gut zu erledigen. 12

13 ODS 6 im Fazit Performanz Der Zugriff auf Daten in Oracale ist (gleich) Der getestete Datentransfer (bis 64 MB) ergab Protobuf ist um einen Faktor 2 schneller aber die Testumgebungen sind nicht 1:1 vergleichbar es wurde kein JacORB verwendet umgekehrt ist eine weiterer Performanzschub durch die Defaultwerte zu berücksichtigen Die ODS 6.0 Schnittstelle wird erwartungsgemäß genauso performant wie die jetzige. 13