RNextBasisTechnisch
Technische Grundlagen
RNext stellt die nächste BiPRO Normengeneration dar und wurde Anfang 2018 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-Schritte realisiert wurden:
Artefakte als Basiskomponente bereitstellen
Bis dato werden BiPRO-Normen hauptsächlich als eine Art Richtlinie bereitgestellt. Es gibt zwar Artefakte in Form eines EA-Projektes (*.eap, UML) bzw. daraus generierter XML-Schemas, sowie WSDL-Vorlagen, allerdings müssen sich die Implementierer selbst um Serialisierung und Adaption der Datenmodelle bzw. um die Erstellung der Service-Schicht kümmern. Dabei gibt es Interpretationsspielräume, sodass eine hundertprozentige BiPRO-Konformität nicht ohne Weiteres hergestellt werden kann.
Die Idee von RNext dagegen ist, dass BiPRO-Normen mit konkreten Artefakten ausgeliefert werden. Diese wiederum können sowohl den Implementierungsaufwand reduzieren als auch die Normkonformität verbessern. Da alle Datenmodelle und die Service-Endpunkte normiert sind, können Framework-spezifische Basiskomponenten generiert werden und diese in public oder private Package-Repositories veröffentlicht werden. Somit kann der Implementierer eine BiPRO-Basis, als Package für das jeweilige Programmierframework beziehen und muss lediglich Spezifika der Domäne 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. Derzeit sind sämtliche Package-Repositories hier zu finden: https://nexus.rnext.org, es wird noch evaluiert, welche Artefakte normrelevant sind und bereitgestellt werden.
WEB API / REST Service
Auch wenn eine BiPRO-Norm als ein technologie-übergreifendes Konstrukt angedacht ist, so ist die Nähe zum SOAP-Protokoll unverkennbar. Im Laufe der vergangenen Jahre haben sich allerdings die technischen Rahmenbedingungen massiv verändert. Heute werden immer häufiger 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 Schreiboperationen verarbeitet werden. Dabei werden die SOA-Prinzipien durch die Verwendung von 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 mithilfe der Spezifikationen von OpenAPI 3.0 werden moderne Service-Schnittstellen definiert.
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 Generatoren erzeugt. OpenAPI 3.0 hat sich bereits als nachhaltiges aktives Ökosystem in diesem Bereich erfolgreich etabliert, ebenfalls setzt RNext genau darauf auf.
BiPRO Datenmodelle
Einen wesentlichen Teil der BiPRO-Normen stellen die objektorientierten Datenmodelle dar. Das Datenmodell besteht aus generischen sparten-übergreifenden Bestandteilen und aus sparten-spezifischen Ausprägungen. Vor allem auf der Consumer-Seite 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 das hierarchische Konstrukt anschließend mit den eigentlichen Daten befüllt werden kann.
RNext reduziert die Komplexität solcher hierarchischeren Datenmodelle, sodass die Anbindung von BiPRO-Services einfacher und intuitiver erreicht werden kann.
Continuous Integration/Deployment
CI/CD sind in der heutigen Welt der Softwareentwicklung feste Bestandteile des Application Lifecycle Management (ALM). Damit wird eine dezentrale Entwicklung, einfachere Versionierung und vor allem kürzere Release-Zyklen ermöglicht.
Eine zentrale Build- und Deployment-Pipeline validiert die eingecheckten Swagger-Files und baut daraus einen generischen Microservice, so dass Resultate der Modellierung sofort sichtbar sind. Zudem kann gegen diesen zentralen Service (Sandbox) getestet werden.
BiPRO Norm Lifecycle Management
Der Normierungsprozess beginnt mehr oder weniger wie gewohnt mit der Erstellung eines Datenmodells und endet mit der Publizierung der Artefakte in Package-Repositories. Am Ende des Normierungsprozesses stehen alle Normen in Form von verschiedenen Artefakten dem Implementierer zur Verfügung. Der Implementierungsaufwand reduziert sich erheblich, da die BiPRO-spezifischen Komponenten nicht mehr implementiert, sondern nur integriert werden müssen. Die Norm wird maximal eingehalten, da die äußerste Schicht des Services bzw. der Consumer-Applikation immer gleich bleiben.
Die Publikation der Artefakte in public Repositories hat 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.