Modularity-Patterns mit Java 9 / Jigsaw

Transkript

1 Modularity-Patterns mit Java 9 / Jigsaw MARTIN LEHMANN, DR. v.3.12 v.3 1 Java Forum Stuttgart, 5. Juli 2018

2 Abstract Java Forum Stuttgart Mit Java 9 kam im September 2017 (endlich!) das lange angekündigte und lang ersehnte Modulsystem Jigsaw. Jigsaw ist eine grundlegende Strukturänderung von Java-Plattform und -Sprache, mit deren Auswirkungen man sich möglichst früh beschäftigen sollte. Komponentenbasierte Software ist nichts Neues. Mit Java 9 steht nach über 20 Jahren Java- Entwicklung nun direkt ein natives Sprachmittel zur Verfügung, um Komponenten zu definieren und in der Architektur zu verankern. Was bisher nur mit Tools wie Maven oder Ivy bzw. durch statische Code-Analyse möglich war, ist nun direkt als Sprachfeature verfügbar. Wir betrachten verschiedene bekannte Modularity-Design-Patterns und zeigen, wie man diese mit Jigsaw umsetzen kann, darunter Patterns zu Architektur- und Komponentenschnitt, Patterns zu Abhängigkeiten, Patterns zu Test, Patterns zu Erweiterbarkeit und zur Evolution / Migration. Welche Patterns werden gut unterstützt, welche erfordern zusätzliche Klimmzüge oder gar eigene Erweiterungen? Welche Features kann Jigsaw in Java 9 noch nicht (Beispiel: Modul- Versionierung)? 2

3 Martin Lehmann, Accso - Accelerated Solutions GmbH Cheftechnologe Martin Lehmann ist Diplom-Informatiker und arbeitet als Cheftechnologe und Softwarearchitekt bei der Accso - Accelerated Solutions GmbH. Seit Ende der 90er-Jahre wirkt er als Software-entwickler und -architekt in der Softwareentwicklung in diversen Projekten der Individual-entwicklung für Kunden verschiedener Branchen. Seit den Zeiten von Java 1.0 beschäftigt er sich mit Java als Programmiersprache und als Ökosystem. Kristine Schaal, Accso - Accelerated Solutions GmbH Softwarearchitektin Dr. Kristine Schaal ist als Softwarearchitektin bei der Accso - Accelerated Solutions GmbH tätig. Sie arbeitet seit 20 Jahren in der Softwareentwicklung und ist in Projekten der Individualentwicklung für Kunden verschiedener Branchen unterwegs, technisch überwiegend im Java- Umfeld. 3

4 4 Project Jigsaw seit Java 9: JSR 376 und seine Ziele JSR 376 für das Java Platform Module System (JPMS) Project Jigsaw seit Java 9-Release vom 21. September 2017 enthalten. Aktuell: Releases und JEP 261, 200, 201, 220, 260, 282 mit Modulsystem, modularisiertem JDK und der Kapselung interner APIs Strong Encapsulation Eine Komponente kann ihr öffentliches API definieren und den Zugriff auf Implementierungsgeheimnisse verhindern. Reliable Configuration Ablösung des Classpath (fehleranfällig, wenn Klassen mehrfach enthalten sind Reihenfolgeprobleme). Scalable Java SE Platform Die Java-Plattform ist nun modularisiert. Man kann individuell angepasste, schlanke Plattformen bauen.

5 Wichtige Anforderungen aus der JPMS-Spec Module mit Dependencies, Resolution, Encapsulation, Non-Interference: In allen Phasen (Compile, Laufzeit). Exports müssen von außen überschreibbar sein. Resource Encapsulation Services: Binding, Selective Binding Java Platform Modularization Interoperabilität mit anderen Modulsystemen (OSGi explizit genannt) Refactoring: Module aufspaltbar / zusammenlegbar, ohne Auswirkungen auf Clients Whitebox-Tests müssen möglich bleiben Schrittweise Migration, Weiterbenutzung von existierenden Tools wie Maven Linking, um optimierte Plattform bauen zu können Keine Verschlechterung der Performance Versionierung ist explizit ausgeklammert (Modul hat nur einen Versionsstring!) 5

6 Modularity Patterns Der Pattern- Katalog 6

7 Kirk Knoernschild Java Application Architecture Modularity Patterns with Examples Using OSGi Series: Robert C. Martin Series Paperback: 384 pages Publisher: Prentice Hall; 1 edition March 25, 2012 ISBN-10: ISBN-13:

8 8 Base Patterns Manage Relationships Module Reuse Cohesive Modules Dependency Patterns Acyclic Relationships Levelize Modules Physical Layers Container Independence Independent Deployment Usability Patterns Published Interface External Configuration Default Implementation Module Facade Extensibility Patterns Abstract Modules Implementation Factory Separate Abstractions Utility Patterns Collocate Exceptions Levelized Build Test Module Design module relationships Emphasize reusability at the module level Module behavior should serve a singular purpose Module relationships must be acyclic Module relationships should be levelized Module relationships should not violate the conceptual layers Modules should be independent of the runtime container Modules should be independently deployable units Pattern Catalog Make a module s published interface well known Modules should be externally configurable Provide modules with a default implementation Facade as a coarse-grained entry point to fine-grained underlying implementation Depend upon the abstract elements of a module Use factories to create a module s implementation classes Place abstractions and the classes that implement them in separate modules modularity/pattern-catalog/ Exceptions should be close to the classes that throw them Execute the build in accordance with module levelization Each module should have a test module that validates it s behavior and illustrates it s usage

9 Base Pattern Manage Relationships Design module relationships 9

10 Base Pattern Manage Relationships 10 Pattern Komponenten = wiederverwendbare Software- Bausteine Wohldefinierte Schnittstellen Eingehende Schnittstellen Ausgehende Schnittstellen Der Grad der Abhängigkeiten bestimmt die Komplexität einer Anwendung maßgeblich. Vorteile Komponenten brechen den Monolithen auf. Nachvollziehbare Auswirkungen von Änderungen Es wird nur geladen, was wirklich benötigt wird. Nachteile Es wird nur geladen, was wirklich modelliert wurde.

11 Ein Module als First-Class-Citizen in Java Module := Menge von Java-Packages & Resources Wird in ein Modular JAR kompiliert. Dieses liegt im neuen Module-Path. Module-Namen müssen eindeutig sein (erlaubt sind. und _, aber nicht -) Im Module-Deskriptor stehen: Name Abhängigkeiten Zugriffsschutz Keine weiteren Syntax- oder Sprachkonstrukte! module moda { requires modb; exports pkg1; opens pkg2; } moda/module-info.java 11

12 Ein Module als First-Class-Citizen in Java Module := Menge von Java-Packages & Resources read -Abhängigkeitsbeziehungen zu anderen Modulen modb read moda exports : Welche Packages des Modules werden exportiert? (Default: nichts!) pkgb inter nal pkg b exports pkga 12

13 Base Pattern Manage Relationships 13 Pattern Komponenten = wiederverwendbare Software- Bausteine Wohldefinierte Schnittstellen Eingehende Schnittstellen Ausgehende Schnittstellen Der Grad der Abhängigkeiten bestimmt die Komplexität einer Anwendung maßgeblich. mit Jigsaw Module-Deskriptor Module-Name Abhängigkeiten Zugriffsschutz Keine weiteren Syntax- oder Sprachkonstrukte!

14 Base Pattern Manage Relationships Pattern Komponenten = wiederverwendbare Software- Bausteine Wohldefinierte Schnittstellen Eingehende Schnittstellen Ausgehende Schnittstellen Der Grad der Abhängigkeiten bestimmt die Komplexität einer Anwendung maßgeblich. mit Jigsaw Komponente als Module Beziehungen Keine Scopes (wie in Maven) Statische Bindung über Namen Dynamische Bindung zur Startzeit Nutzung Statische Aufrufe Dynamisch per Reflection 14

15 Manage Relationships Explizite Abhängigkeiten Ein Module kann ein anderes Module nur benutzen, wenn es eine read -Beziehung zu ihm hat (aka: requires ). modb modc read moda module moda { // read auf modb requires modb; } 15 Das Module moda hat eine read-beziehung zu Module modb, jedoch keine zu modc moda kann nur auf modb zugreifen.

16 Base Pattern Manage Relationships Vertiefte Konzepte Optionale Abhängigkeiten? Transitive Abhängigkeiten? Ja! Ja! mit Jigsaw Versionierung? Gruppierungen? Hierarchien? Remote oder lokal? Checks zu Compile-Time? Checks zu Start/Runtime? Nein (nur informell)! Nicht einfach*! Nicht einfach*! Nur lokal, keine Verteilung! Ja! Ja! *) Zumindest nicht wie in Maven mit group-id. Nicht-triviale Lösungen über Aggregrator-Modules und ModuleLayer. 16

17 Jigsaw-Module-Graphen z.b. mit DepVis java9-jigsaw-depvis Basiert auf GraphViz mit Java-API 17

18 Dependency Pattern Acyclic Relationships Module relationships must be acyclic 18

19 19

20 Dependency Pattern Acyclic Relationships Pattern azyklische Komponenten- Abhängigkeiten! Unterscheide: Zyklen zur Compile-Zeit Zyklen zur Laufzeit z.b. durch Aufruf per Reflection Auflösung von Zyklen Auslagern von Funktionalität Callback Nachteile von Zyklen Die Komponenten eines Zyklus bilden de facto eine einzige große Komponente. Hohe Koppelung zwischen den betroffenen Komponenten Eine Änderung an einer Komponente hat i.d.r. Auswirkungen auf alle anderen Komponenten des Zyklus. 20

21 Acyclic Relationships Jigsaw verbietet read-zyklen Statische read -Zyklen sind in Jigsaw verboten Compile-Fehler * Jigsaw erlaubt jedoch Zyklen zur Laufzeit (durch reflektive Aufrufe). read * Vorsicht: Compiler-Bug in findet nicht alle Zyklen! modb read moda modb\module-info.java:2: error: cyclic dependence involving moda requires moda; ^ 1 error 21

22 Dependency Pattern Acyclic Relationships Pattern azyklische Komponenten- Abhängigkeiten Unterscheide: Zyklen zur Compile-Zeit Zyklen zur Laufzeit z.b. durch Aufruf per Reflection Auflösung von Zyklen Auslagern von Funktionalität Callback mit Jigsaw Statische Zyklen mit requires in Modulen nicht erlaubt. Sie führen zu Compilerfehlern * Dynamische Zyklen zur Laufzeit (per Reflection) möglich * Vorsicht: Compiler-Bug in findet nicht alle Zyklen! 22

23 Usability Pattern Published Interface Make a module s published interface well known 23

24 Usability Pattern Published Interface Pattern Komponente definiert ihre öffentliche Schnittstelle. Nutzer verwenden die Komponente nur über diese Schnittstelle. Von außen ist kein Zugriff auf die Implementierung möglich. 24

25 Usability Pattern Published Interface Pattern Komponente definiert ihre öffentliche Schnittstelle. Nutzer verwenden die Komponente nur über diese Schnittstelle. Vorteile Fördert explizite Definition von Komponenten-Grenzen Dokumentation Von außen ist kein Zugriff auf die Implementierung möglich. Änderung der gekapselten Implementierung hat keine Auswirkung auf Nutzer. 25

26 Usability Pattern Published Interface Pattern Komponente definiert ihre öffentliche Schnittstelle. Nutzer verwenden die Komponente nur über diese Schnittstelle. Von außen ist kein Zugriff auf die Implementierung möglich. Nachteile Höhere Komplexität durch Indirektion zum Erzeugen der Implementierung Instabile Schnittstellen Abwärtskompatibilitätsfalle Law of Leaky Abstraction: All non-trivial abstractions, to some degree, are leaky. (Joel Spolsky) 26

27 Usability Pattern Published Interface Pattern Komponente definiert ihre öffentliche Schnittstelle. Nutzer verwenden die Komponente nur über diese Schnittstelle. Von außen ist kein Zugriff auf die Implementierung möglich. Abgrenzungen Manche Komponenten haben keine echte Schnittstelle, z.b. Datentypen-Komponenten. Reflektiver Zugriff durch Frameworks auch auf gekapselte Implementierung sinnvoll Vollständige Implementierung austauschen? Pattern Separate Abstractions 27

28 Was gehört zur Schnittstelle einer Komponente? Interfaces Factories zum Erzeugen der Implementierung Datentypen Exceptions public interface MyInterface { public MyData mymethod (String param) throws MyException; } 28

29 Published Interface exports von Packages modb read module modb { exports pkg.myapi; } pkg. myapi pkg. myimpl exports moda 29 Nur exportierte Packages eines Modules sind von außen zugreifbar. Per Default nichts exportiert. Export nur auf Package-Ebene möglich! Keine Wildcards möglich! Gerichteter Export an ein / mehrere Module mit exports to

30 Published Interface exports von Packages modb read module modb { exports pkg.myapi; } pkg. myapi pkg. myimpl exports moda 30 Checks zu Compile-Zeit und zur Laufzeit: 1. neu: Readability (read) 2. neu: Accessibility (exports) 3. Sichtbarkeitsmodifier public, private, protected, <pkg> Gilt alles auch für System-Module (wie java.base)

31 Published Interface exports von Packages module modb { exports pkg.myapi; } modb pkg. myapi pkg. myimpl read exports moda Varianten zur Umsetzung des Patterns: API- und Implementierungsklassen in verschiedene Packages legen Oder Implementierung zur API dazulegen als package-sichtbar. 31

32 Published Interface Typensichtbarkeit public class Factory { public MyInterface create() { return new MyImpl(); } public class Caller { MyInterface myint = new MyFactory().create(); pkg. myapi modb My Fact ory MyIn ter face read exports moda pkga Call er Instanzen von MyImpl behalten ihren Typ auch über Modulegrenze hinaus, obwohl dessen Package nicht exportiert ist. pkg. myimpl My Impl 32

33 Published Interface opens von Packages exports erlaubt statische Zugriffe. opens öffnet für Deep Reflection mit setaccessible(true) Compile-Zeit Reflection (Shallow) Reflection (Deep) exports pkg erlaubt erlaubt nicht erlaubt opens pkg nicht erlaubt erlaubt erlaubt exports pkg und opens pkg erlaubt erlaubt erlaubt 33

34 Usability Pattern Separate Abstractions Place abstractions and the classes that implement them in separate modules 34

35 Usability Pattern Separate Abstractions 35 Pattern Trenne Implementierung von API in verschiedene Komponenten API-Komponente hat keine Abhängigkeit zu der Implementierung. Auswahl/Konfiguration einer Implementierung erfolgt außerhalb API-Komponente. Factories nicht enthalten. Vorteile Implementierung kann komplett ausgetauscht werden, erlaubt späte Wahl (zur Laufzeit). Beispiel: Nachteile Datenbank-Treiber Weitere Indirektionen Mehr Aufwand Höhere Komplexität, Zusammenspiel schwerer nachvollziehbar

36 Usability Pattern Separate Abstractions - 3 Ebenen IService1 pkg.service IService2 36

37 Usability Pattern Separate Abstractions - 3 Ebenen IService1 IFoo pkg.service pkg.foobar IService2 IBar 37

38 Usability Pattern Separate Abstractions - 3 Ebenen api IService1 IFoo pkg.service pkg.foobar IService2 IBar 38

39 Usability Pattern Separate Abstractions - 3 Ebenen blue.impl Impl1 FooImpl pkg.service.blue pkg.foobar.blue Impl2 BarImpl 39

40 Usability Pattern Separate Abstractions - 3 Ebenen green.impl OtherImpl 1 FooImpl pkg.service.green OtherImpl 2 pkg.foobar.green BarImpl 40

41 Usability Pattern Separate Abstractions - 3 Ebenen red.impl RedImpl1 pkg.service.red RedImpl2 41

42 Usability Pattern Separate Abstractions - 3 Ebenen client factory 42

43 Usability Pattern Separate Abstractions - 3 Ebenen Auswahl der Implementierung als ganze Komponente client factory 43

44 Usability Pattern Separate Abstractions - 3 Ebenen Auswahl der Implementierung in Teilen (einmalig oder nach Bedarf) client factory 44

45 Separate Abstractions mit Jigsaw-Modules exports blue.impl read api read red.impl read green.impl 45

46 Separate Abstractions 1. Factory-Module client blue.impl api red.impl factory green.impl 46

47 Separate Abstractions 1. Factory-Module client blue.impl read api red.impl factory read read green.impl 47

48 Separate Abstractions 1. Factory-Module Factory muss Implementierungsklassen kennen! client blue.impl api exports to red.impl factory exports to exports to green.impl 48

49 Separate Abstractions 2. DI-Module Zugriff per Reflection mit opens z.b. für Spring-Fwk client blue.impl opens to DI- Framework api opens to opens to green.impl red.impl 49

50 Separate Abstractions Split-Package-Problem 50 Vorsicht: Modules müssen disjunkte Packages haben. Ein Split eines Package auf mehrere Modules ist nicht erlaubt! Gilt auch, wenn das Package nicht exportiert ist!! Selbst dann, wenn es keine Klassen-Duplikate in den Modules gibt!!! api exports read read read blue.impl green.impl red.impl

51 Separate Abstractions 3. Dynamische Bindung Schnittstelle java.sql.driver Implementierung in Module java.sql im MySQL-Driver module java.sql { // Definiert und exportiert // Schnittstelle uses java.sql.driver; exports java.sql; } module com.mysql.jdbc { requires java.sql; // Implementiert Schnittstelle } provides java.sql.driver with com.mysql.jdbc.driver; Dynamische Bindung beim Start über ServiceLoader, also keine statische Auflösung über Module-Namen wie bei requires! 51

52 Usability Pattern Separate Abstractions 52 Pattern Trenne Implementierung von API in verschiedene Komponenten API-Komponente hat keine Abhängigkeit zu der Implementierung. Auswahl/Konfiguration einer Implementierung erfolgt außerhalb API-Komponente. Factories nicht enthalten. mit Jigsaw Trennung in verschiedene Jigsaw-Module möglich Split-Package beachten! uses-provides für dynamische Bindung zur Startzeit per ServiceLoader Eigene Auswahl der Implementierung möglich

53 Usability Pattern Module Facade Facade as a coarse-grained entry point to another module s underlying implementation 53

54 Usability Pattern Module Facade Pattern Vgl. GOF-Patterns Facade, Adapter, Decorator Eine Komponente dient als zentrale Facade zu anderen Komponenten. Abhängigkeit idealerweise nur zur Facade nötig, nicht zu den dahinter liegenden Komponenten Vorteile Kapselt dahinterliegende Details an zentraler Stelle Kapselt Schnittstellen Höhere Lesbarkeit Einfachere Nutzung Erzwingt Reihenfolgen erlaubt automatische Vor- / Nach-Bearbeitung 54

55 Module Facade mit eigenen Facade-Modules In eigenen Facade-Modules kann man andere Module kapseln. 55

56 Module Facade Transitive Abhängigkeiten In eigenen Facade-Modules kann man andere Module kapseln. Jigsaw ermöglicht auch, Abhängigkeiten transitiv weiterzugeben. module modfacade { requires modx; requires transitive mody; } 56

57 Module Facade Transitive Abhängigkeiten 1-transitiv 2-transitiv 57

58 Usability Pattern Module Facade Pattern Vgl. GOF-Patterns Facade, Adapter, Decorator Eine Komponente dient als zentrale Facade zu anderen Komponenten. Abhängigkeit idealerweise nur zur Facade nötig, nicht zu den dahinter liegenden Komponenten mit Jigsaw requires transitive in module-info reicht Abhängigkeit automatisch weiter Ermöglicht leere Aggregator- Modules Ermöglicht nicht die Kapselung dahinter liegender APIs: Im Gegenteil werden diese ja durchgereicht! 58

59 Utility Pattern Test Module Each module should have a corresponding test module that validates it s behavior 59

60 Utility Pattern Test Module Pattern Zu jeder Komponente eine korrespondierende Testkomponente erstellen. Blackbox-Test testet nur die öffentlichen Schnittstelle. Die Testkomponente hängt nicht von weiteren Komponenten ab (Mocking). Separate Integrationstestkomponenten erstellen Vorteile Komponenten sind unabhängig voneinander testbar, Fehler leichter lokalisierbar Dokumentation der Nutzung der Schnittstelle Nachteile Hoher Aufwand durch Mocks 60

61 Test Module Blackbox-Tests Blackbox-Tests werden in separates Jigsaw-Module ausgelagert. Dieses Testmodule benötigt keinen Zugriff auf interne Klassen. pkga exports moda pkga internal read pkg black test moda. test. black 61

62 Test Module Whitebox-Tests Whitebox-Test testet interne Klassen von moda aus pkgainternal. Verschiedene Varianten denkbar, z.b. Test-Module & exports to Besser: Testcode getrennt ablegen und für Compile der Tests und für Testdurchführung in das Module reinpatchen. pkga exports moda pkga internal pkga internal Test 62

63 Utility Pattern Test Module Pattern Zu jeder Komponente eine korrespondierende Testkomponente erstellen. Blackbox-Test testet nur die öffentlichen Schnittstelle. Die Testkomponente hängt nicht von weiteren Komponenten ab (Mocking). Separate Integrationstestkomponenten erstellen mit Jigsaw Blackbox als eigenes Test- Module gegen öffentliche API, Abhängigkeiten per Mocks Whitebox: Testcode auslagern und reinpatchen Integrationstests gegen öffentliche API ohne Mocks 63

64 Dependency Patterns Levelize Modules Physical Layers Levelized Build 64 Module relationships should be levelized Module relationships should not violate the conceptual layers Execute the build in accordance with module levelization

65 Komponenten sortieren sich in Schichten/Säulen ein. Säule 1 Säule 2 Säule 3 Schicht Präsentation Component Component Component Component Schicht Anwendungskern Component Component Component Component Schicht Persistenz Component Component Component Component 65

66 Jigsaw-Modules als gerichteter Graph 66 mit Jigsaw Jigsaw erstellt einen Abhängigkeitsgraph: Modellierung der Abhängigkeiten mit requires Keine zyklischen Abhängigkeiten Dieser Graph sollte auch die Schichten und Säulen abbilden. Eine Unterstützung durch Jigsaw gibt es dafür nicht.

67 Jigsaw-Modules als gerichteter Graph im Build mit Jigsaw Den Module-Graph sollte auch Build/Deployment/Test berücksichtigen. Die Graph-Abbildung unterstützt bereits Maven / Gradle (Modellierung von Abhängigkeiten; keine Zyklen erlaubt). Nur Teil-Build/DeploymentTest notwendig bei Änderungen von Modulen der unteren Stufen. 67

68 Module-Layer für Laufzeitgruppierung mit Jigsaw Jigsaw erlaubt Laufzeit-Gruppierung mit Module-Layer. Layer funktioniert ähnlich wie ein Container. Per Default: Alles im Boot-Layer Keine gute Unterstützung für Schichten/Säulen (Calls nur per Reflection über Layergrenzen) 68

69 Module-Layer für Laufzeitgruppierung mit Jigsaw Umgeht aber andere Einschränkungen Kein Split-Package bei Geschwister-Layern Module in verschiedenen Versionen nutzbar, wenn mit CL / Layer getrennt Komplexes Zusammenspiel von Configuration, Classloader, Layer 69

70 Wo gibt es Dokumentation? 70

71 Jigsaw-Dokumentation zum Nachlesen 71 Homepage Project Jigsaw OpenJDK: JDK 9 Oracle: JDK 9 Documentation Jigsaw-Issues Specification (2015) State of the Module System (2016) Quickstart Guide JSR376 JEPs The modular JDK 261 Module System 220 Modular Runtime Images 275 Modular Java App. Packaging 260 Encapsulate Most Internal APIs 282 jlink: The Java Linker Mailinglisten jigsaw-dev, jdk9-dev, jpms-spec-comments, jpms-spec-experts, jpms-spec-observers

72

73 heise/ix Sonderheft Java 2017 JavaSPEKTRUM- Sonderdruck Als PDF-Download bei 73 Accso Accelerated Solutions GmbH T E Berliner Allee 58 Moltkestraße 131a Balanstraße Darmstadt Köln München

74 Github Beispiele 74

75 Unsere Jigsaw-Beispiele stehen auf Github Läuft mit Java Release-Build b181 und 9.0.1, und JDK 10 Bash-Skripte für Compile, Run, Test (in Windows z.b. mit Babun nutzbar) Projektstrukturen für Eclipse Oxygen.3 Unsere 32 Beispiele zeigen alles Wissenswerte zu Jigsaw zu Requires, Exports, Exports-To, Requires-Static, Requires-Transitive, Blackbox-Test, Whitebox-Test, Uses, Provides, Maven-Integration, Opens, Open Module, Manifest-Optionen, versteckte Main-Klasse, Automatic Modules, Reflection, Resolved Modules (Configuration), Naming von Modulen, Unnamed Module (Classpath), Layer, Javadoc, Annotations, jlink etc. pp. usw. usf. 75

76 76

77 77

78 78

79 @mrtnlhmnn Accso Accelerated Solutions GmbH T E Berliner Allee 58 Moltkestraße 131a Balanstraße Darmstadt Köln München