Hauptseite: Unterschied zwischen den Versionen
| Zeile 150: | Zeile 150: | ||
== Fachlich == | == Fachlich == | ||
FachlicheKomponente, die sich vor allem mit folgenden Themenpunkten beschäftigt. | |||
=== Domänenschnitte === | === Domänenschnitte === | ||
=== Migration von RClassic auf RNext === | === Migration von RClassic auf RNext === | ||
== Technisch == | == Technisch == | ||
Version vom 5. November 2018, 08:26 Uhr
Was ist RNext?
BiPRO-RNext oder einfach RNext ist der Codename für die nächste Release-Generation von BiPRO-Schnittstellen.
Powered by
https://bipro.net/
RNext stellt die nächste BiPRO Normengeneration dar und wurde in einem ersten Proof Of Concept untersucht. Aktuell gibt es verschiedene Herausforderungen im Bereich BiPRO-Implementierung. Neben einer hohen Komplexität der BiPRO-Datenmodelle, gibt es einige Hürden, die einer reibungslosen Umsetzung der BiPRO-Normen und somit einem flächendeckenden Ausrollen im Wegen stehen. Hier sind einige Lösungsansätze, die im Rahmen der ersten RNext-Labs realisiert werden sollen:
Artefakte als Basiskomponente bereitstellen
Bis dato wurden BiPRO-Normen hauptsächlich, als eine Art Richtlinie bereitgestellt. Es gibt zwar Artefakte in Form von *.eap(UML) evtl. sogar WSDL. Allerdings müssen sicht die Implementierter selbst um die Erstellung von Datenmodellen bzw. der Serviceschicht kümmern. Dabei gibt es viele Interpretationsspielräume, sodass eine einhundertprozentige BiPRO-Konformität nicht ohne weiteres zu leisten ist. Die Idee von RNext ist vor allem, dass BiPRO-Normen mit konkreten Artefakten ausgeliefert wird. Diese wiederum können sowohl den Implementierungsaufwand reduzieren, als auch die Normenkonformität steigern. Da alle Datenmodelle und die Service Endpoints genormt sind, kann man die Framework spezifischen Basiskomponenten generieren und diese in Public oder Private Package-Repositories veröffentlichen. Somit kann der Implementierer eine BiPRO-Basis, als Package für das jeweilige Programmierframework beziehen und muss lediglich die Domainspezifik als Delta implementieren. Der Implementierungsaufwand wird dadurch deutlich reduziert. Und die Norm wird maximal eingehalten. Es sollen kleine, atomare Artefakte generiert werden, sodass der Anwender, je nach Zweck, nur den tatsächlich benötigten Funktionsumfang in seiner Anwendung nutzen kann.
WEB API / REST Service
Auch wenn eine BiPRO-Norm als ein technologieübergreifendes Konstrukt angedacht ist, so ist eine gewisse Nähe zum SOAP-Protokoll unverkennbar. Im Laufe der vergangenen Jahre haben sich allerdings die technischen Rahmenbedingungen massiv verändert. Heute werden immer häufige REST Services als Web-APIs eingesetzt. Diese ermöglichen ein schlankeres Übertragungsformat in Form von JSON Daten. Des Weiteren können die komplexen Datenstrukturen in kleineren atomaren Lese- und Schreibeoperationen verarbeiten. Dabei werden vor allem die SOA Prinzipien durch die Verwendung der Micro Service Patterns ergänzt. Eine der wesentlichen Herausforderungen ist es, die BiPRO-Norm für den aktuellen und den zukünftigen Stand der Technik fit zu machen. Es gibt immer mehr Clients, vor allem im Mobilen Bereich, die ausschließlich auf REST-Services setzen. Vor allem mit Hilfe der Open API Spezifikationen werden die heutigen Service Schnittstellen definiert: https://github.com/OAI/OpenAPI-Specification https://www.openapis.org/ Damit wird ermöglicht, die Schnittstellen und die dazugehörigen Datenmodelle deklarativ nach einem technologieübergreifenden Standard zu modellieren. Ein Großteil des anwendungsspezifischen Codes wird dabei durch die Generatoren erzeugt. Die Technologien, wie z.B. RAML oder SWAGGER, haben sich bereits als ein nachhaltiges aktives Ökosystem in diesem Bereich erfolgreich etabliert.
BiPRO Datenmodelle
Einen Großteil der BiPRO-Normen stellen die objektorientierten Datenmodelle dar. Genaugenommen besteht das Datenmodell aus einem generischen spartenübergreifenden Teil und aus den jeweiligen spartenspezifischen Ausprägungen. Vor allem auf der Konsumentenseite ist die Anbindung einer BiPRO-Schnittstelle immer noch eine große Herausforderung. Um z.B. fünf Felder an den Service zu schicken, müssen oft komplexe Objektbäume instanziert werden, damit anschließend das hierarchische Konstrukt mit den eigentlichen Daten befüllt werden kann. RNext soll die Komplexität solcher hierarchischeren Datenmodelle reduzieren, sodass die Anbindung von BiPRO-Services einfacher und intuitiver werden soll.
BiPRO Datenmodelle
Einen Großteil der BiPRO-Normen stellen die objektorientierten Datenmodelle dar. Genaugenommen besteht das Datenmodell aus einem generischen spartenübergreifenden Teil und aus den jeweiligen spartenspezifischen Ausprägungen. Vor allem auf der Konsumentenseite ist die Anbindung einer BiPRO-Schnittstelle immer noch eine große Herausforderung. Um z.B. fünf Felder an den Service zu schicken, müssen oft komplexe Objektbäume instanziert werden, damit anschließend das hierarchische Konstrukt mit den eigentlichen Daten befüllt werden kann. RNext soll die Komplexität solcher hierarchischeren Datenmodelle reduzieren, sodass die Anbindung von BiPRO-Services einfacher und intuitiver werden soll.
BiPRO Norm Lifecycle Management
Der Normierungsprozess könnte wie gewohnt mit dem Erstellen des Datenmodells im EA beginnen und mit dem publizieren der Artefakte in die entsprechende Package-Repositories enden. Am Ende des Normierungsprozesses stehen alle Normen in Form von verschiedenen Artefakten dem Implementierer zur Verfügung. Der Implementierungsaufwand reduziert sich erheblich, da man die BiPRO-spezifischen Komponenten nicht mehr programmieren muss. Die Norm wird dabei maximal eingehalten, da die äußerste Schicht des Services bzw. des Konsumenten immer gleichbleibt. Wenn man die Artefakte in den Public Repositories publiziert, dann hat man den Vorteil, dass ein Ökosystem mit verschiedenen BiPRO Tools entsteht. Dieses Ökosystem sorgt wiederum für eine breite Akzeptanz der BiPRO-Norm und für eine nachhaltige Weiterentwicklung durch die Community.
FAQ zu RNext
Hier gibt es eine lange Liste von FAQs rund um das Thema RNext. Die BiPRO-Geschäftsstelle, sowie die Arbeitsgruppe RNext versuchen diese Sammlung stets up-to-date zu halten: FAQs.
Tools in RNext
OpenAPI Specification 3.0
In früheren Version synonym mit Swagger. Ist eine Spezifikation zur Beschreibung von RESTful Webservices in RAML (RESTful API Modeling Language). Das Tool Swagger kann online verwendet werden oder als Client heruntergeladen werden. Hier der Link zur Online-Version: https://editor.swagger.io
GitLab
Jenkins
Nexus
Onboarding für Mitglieder der Arbeitsgruppe RNext
Hilfe zur Benutzung und Konfiguration der Wiki-Software findest du im Benutzerhandbuch.
Grundlagen
Design Principles
Use before Re-use
Jedes Element eines Normierungsartefaktes (Attribute) muss praktisch eingesetzt und verstanden werden, bevor es Teil der Norm wird (Inkubationsphase); kein Front-UpEngineering (Overhead, Komplexität, Mismatch mit der Realität).
Ein digitaler Standard ist Software
Die Erzeugung von reinen Papiernormen erzeugt keinen Mehrwert für die Digitalisierung unserer Branche. Regellogik, die heute in den Normen oder im Datenmodell als Prosa beschrieben ist, kann durch Regeln in ausführbaren Code (also Beschreibung durch eine Programmiersprache) überführt werden. Diese Logik ist dann interpretationsfrei und kann direkt in den Consumerund Provider-Implementierungen genutzt werden. Die Wahl der konkreten Beschreibungssprache sollte sich am Markt-Mainstream orientieren, ist aber nicht die entscheidende Frage, weil auch heute die Übersetzungsarbeit von Prosa in Programmlogik in jeder Implementierung erfolgen muss, d.h. das Konzept führt auf keinen Fall zu einer Verschlechterung der Situation.
Modularisierung - Domain Driven Design
Normen und ihre Artefakte werden domain-spezifisch beschrieben und ausgerollt. Die Artefakte können eigenständig weiterentwickelt werden. Dieses fachliche Design bietet demnach die Grundlage für die Entwicklung von Microservices. Normierungsartefakte, die tatsächlich in unterschiedlichen Domänen wiederverwendet werden können, werden in ein Basismodell verschoben. Dies bedeutet de facto die Aufgabe des Prinzips einer vollkommenen Redundanzfreiheit. Beispiele für Domänen: Komposit vs. LV/PKV, TAA vs. Bestandsänderungen vs. Schadenprozesse.
Lokale Erweiterungen (DE-AT)
Für die Ableitung in den lokalen Märkten, werden länderspezifische Normierungsartefakte in eine lokale Erweiterung des Standards verschoben. Dieses Prinzip kann domänen- und prozessspezifisch angewandt werden (d.h. der Schieberegler für Global und Lokal kann unterschiedlich gesetzt werden): Deutschland und Österreich haben viele grundlegende Gemeinsamkeiten, aber viele Unterschiede im Detail. Zu den Unterschieden gehören andere Datentypen, wie Schlüssellisten, oder andere Regeln, wie die Länge einer VSNR. Unterschiedlich sind aber auch gesetzliche Anforderungen (anderes VVG) und länderspezifische Produkte (z.B. Riester etc.). Daher sollte das Basisdatenmodell kontextlos sein. Das Basis-DM sollte für DE und AT identisch sein und durch abgeleitete Datenmodelle mit Kontext ergänzt werden.
Trennung von Technik und Fachlichkeit
Die notwendigen technischen Basisstandards orientieren sich an der faktischen Begebenheit in der fachlichen Domäne oder dem Prozess (vgl. IoT-Protokolle versus Nutzung von MQ in Schadennetzwerken). Eine allgemeine Zukunftsprognose der Formate und Protokolle ist herausfordernd (vgl. Trend zu asynchroner Kommunikation in Microservices). Das heißt: Wir sehen potentiell unterschiedliche technische Protokoll-Stacks für unterschiedliche Domänen vor, wobei wir am Ziel festhalten, die Anzahl der Stacks auf das notwendige Mindestmaß zu reduzieren.
Technik beschreibt Interoperabilitätsprinzipien eines kompletten Services, nicht nur Standardisierungsprinzipien der Schnittstelle
Wesentliches Merkmal digitaler Standards ist die Fähigkeit, mit anderen Ökosystemen interoperabel agieren zu können. Dies bedeutet eine Reduktion auf den absoluten Marktmainstream der digitalen Kommunikation und die breite Unterstützung dieser Prinzipien durch Open Source Software. Ein wesentliches Grundprinzip für die Service-Implementierung ist die Einhaltung von Cloud-native Prinzipien (beispielsweise 12-Factor App). Da davon auszugehen ist, dass die Geschwindigkeit der technischen Innovation mindestens die Geschwindigkeit hält, ist ein agiler Standard die Voraussetzung, um im Markt bestehen zu können.
Agiles Normierungs-Setup
Agile Team-Aufstellung = Product Owner, Designer und Entwickler (DevOp) per Product Wie passt das zu unserem Gremien-Setup des Vereins (vgl. Entwicklungen in der Allianz oder Nürnberger die Linienhierarchie aufzugeben)? Wir benötigen verstärkt auch nebenläufige Normierungsprozesse, um die Marktgeschwindigkeit zu halten (vgl. Open Source Entwicklungsprojekte auf Basis Github) “Governance by contribution” -> Mitmachen!
Agiles Release-Management
Domain-spezifische Normen können in sehr kleinen Inkrementen (Sprints) ausgerollt werden. Durch die agile Software-Entwicklung gibt es die Forderung nach einer sehr kurzfristigen Bereitstellung von Sub-Releases mit benötigten Change Requests.
Quelle:
- BiPRO-RNext - Design Principles (Thesenpapier, April 2017, PDF-Dokument)
Realisierung von RNext
Um RNext in der vollen Gänze zu verstehen, ist es sinnvoll dieses in drei Komponenten zu unterteilen.
Organisatorisch
Organisatorische Komponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
Projekt/Lab/DiO-Vorgehen
Gremien/Teams Koordination
Fachlich
FachlicheKomponente, die sich vor allem mit folgenden Themenpunkten beschäftigt.
Domänenschnitte
Migration von RClassic auf RNext
Technisch
Authentifizierung
Buildpipeline
Ergebnisse der Arbeitsgruppe RNext