ASAM ODS 6.0 next technology science + computing ag IT-Services and Software in complex computing environments Tuebingen Munich Berlin Duesseldorf
Agenda science + computing ag auf einen Blick Motivation Anforderungen Tests und Untersuchungen Interessante Technologien Fazit Diskussion Page 2
science + computing auf einen Blick Gründungsjahr 1989 Standorte Tübingen München Berlin Düsseldorf Ingolstadt Mitarbeiter 275 Hauptaktionär Atos SE (100%) Umsatz 2014 32,16 Mio. Euro Partner Daikin Industries, Japan NICE srl, Italien IBM, USA Centrify, USA Seite 3
Kunden der science + computing ag Bremen, Hamburg Wolfsburg Beelen Duisburg Geschäftsstelle Düsseldorf Geschäftsstelle Berlin Alzenau Köln Aachen Mannheim Servicestandort Frankfurt Geschäftsstelle Ingolstadt Stuttgart Zentrale Tübingen Geschäftsstelle München Seite 4
Ausgangssituation Die Kommunikation zwischen ODS-Server und Client findet über Corba statt (sofern die OOAPI verwendet wird) Corba löst zwei wichtige Fragen Wie werden die Daten verpackt (Serialisierung) Wie werden auf der Gegenseite Funktionen aufgerufen Seite 6
Motivation Corba altert Entwicklung von Implementierungen stockt Nur noch wenige Nutzer Nicht besonders Firewall-freundlich Zentrale IT in Großunternehmen nicht immer begeistert Unterstützung neuerer Sprachen wie C# rudimentär Daher: Ersatz wird gesucht ODS-Arbeitsgruppe beschäftigt sich damit Page 7
Suche nach Alternativen Es gibt sehr viele Tools, die auf der Corba Schnittstelle aufsetzen Alle sollten mit erträglichem Aufwand portiert werden können! Multiplatform Windows Linux Sprachunterstützung C++ Java.net (C#) Page 8
Anforderungen Neue Technologie Muss ODS-Daten effizient übertragen können Verlustfreie Übertragung Übertragung großer Datenmengen muss möglich sein Lebendiger Standard Lebendige Implementierungen Firewall-Freundlich Verschlüsselung Authentififizierung und Authorisierung Interoperablitität Open-Source-Lizenz, kommerziell verwendbar Bibliotheksanforderungen einigermaßen verträglich Page 9
Auszutauschende Mechanismen Trennung von RPC- und Serialisierungsmechanismen RPC-Mechanismus: wie wird die Kommunikation zwischen Client- und Server organisiert und Aktionen ausgelöst? Serialisierungsmechanismus: wie werden die Daten verpackt? Manche Bibliotheken bringen beides mit Vermutlich sinnvoll, dann beides zu verwenden, um Abhängigkeiten zu reduzieren Rein theoretische Analyse nicht ausreichend, ausprobieren nötig! Page 10
Tests Benchmarks von typischen ODS-Aktionen Zunächst implementierungsunabhängige Definition, welche Aktionen mit welchen Paramtern getestet werden Komplexe Queries Übertragung von Messdaten Übertragung von Dateien (noch nicht wirklich ODS) Simulation verschiedener Leitungsgeschwindigkeiten Komplette Abdeckung sämtlicher Kombinationen nicht möglich, da exponentiell viele. Daher (sinnvoll erscheinende) Einschränkungen nötig. Seite 11
Weitere Untersuchungen Wie gut integriert sich die Technologie in verschiedenen Sprachen/Systemen (Bibliotheksabhängigkeiten, usw) Wie ist die Unterstützung der Implementierungen? Wie ist die Unterstützung des Standards Kommerzieller Support verfügbar? Wie gut ist die Dokumentation? Unterstützung aller relevanten Datentypen? Parallelisierbarkeit? Tiefe Strukturen möglich? Seite 12
Interessante Technologien RPC REST Avro Thrift grpc Serialisierung Protobuf Avro Thrift Protobuf Page 13
REST Programmierparadigma für Webschnittstellen, kein Framework Nur RPC-Mechanismus Prinzipien Adressierbarkeit Verschiedene Repräsentationen Operationen Zustandslosigkeit Zustandslosigkeit schwierig mit Features wie Sessions zu vereinen. Seite 14
Avro RPC und Serialisierungsmechanismus Stammt aus Apache Hadoop (Big Data) Kein RPC unter C++ Schema-Definition wird mit übertragen Seite 15
Thrift RPC und Serialisierung Stammt ursprünglich von Facebook Ebenfalls Teil des Apache Projekts Unterstützt evtl. nur Doubles, keine Floats Seite 16
grpc und Protobuf Entwicklung durch Google grpc ist sehr neu (im Februar erstmalig vorgestellt) Protobuf zur Serialisierung ist etabliert HTTP/2 Ist die Unternehmens-IT schon so weit? Seite 17
Fazit Es muss tief gegraben werden, um die beste Technologie für die nächsten 10 Jahre ODS zu finden. Momentaner Plan: erst mal eine Technologie tiefer ansehen Zusätzlich soll die API überarbeitet werden (separates Projekt) Seite 18
Fragen? Page 19
Thank You For Your Attention Talk given by: science + computing ag www.science-computing.de Phone: +49 89 35 63 86-843 E-Mail: f.schmitt@science-computing.de