Sonderdruck von - Resilient Software Design Patterns Thorsten Maier, OIO Orientation in Objects GmbH
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Java aktuell
Ausgabe 01/2018
iJUG
Verbund
www.ijug.eu
Java aktuell
Resilient
Die Programmiersprache Go
Einfaches Deployment, hohe
Software
Continous Delivery
Design
Grundlagen des Jenkins-
Patterns
Praktische Erfahrungen
Crypto 101 für eine
Thorsten Maier, OIO Orientation in Objects GmbH
Performance Pipeline-Plug-ins sichere Verschlüsselung
- Artikel auf S. 55 - 59 im Originalheft -
Die Zukunft von
Praxis. Wissen. Networking. Das Magazin für Entwickler
Java EE
r d r u c k v o n
Sonde
www.oio.de
D: 4,90 EUR | CH: 9,80 CHF | A: 5,60 EUR | Benelux: 5,80 EUR
Fazit Ihr Expertenhaus für Java und JavaScript.
Dieser Artikel wird noch keinen Entwickler zum Grafikdesigner ma-
chen. Aber der Autor hofft, er konnte hier einen ersten Eindruck und
Rent-a-Team
einen Einstieg geben. Wenn das ein oder andere Missverständnis Aus unserem Schulungsprogramm:
in der Kommunikation mit Grafikdesignern in Zukunft leichter aus-
zuräumen ist oder es gar nicht erst auftritt,Architektur-
Resilient Software Design mit Java Java Performance
sind wir einen großen 1 Tag: 19.03. / 02.07.2018 € 695,- 2 Tage: 05.03. / 18.06.2018 € 1.255,-
Agile Software beratung zu schaf-
Schritt weiter, um gemeinsam eine bessere Anwendung Apache Kafka ECMAScript mit TypeScript
Factory
2 Tage: 15.02. / 29.05.2018 € 1.255,- 3 Tage: 11.06. / 24.09.2018 € 1.685,-
fen. Vielleicht möchte sich ja auch der eine oder andere tiefer mit Einführung in das Spring Framework JavaScript Intensiveinstieg
3 Tage: 16.04. / 25.06.2018 € 1.685,- 2 Tage: 08.02. / 17.05.2018 € 1.195,-
diesem Thema beschäftigen. schlüsselfertige Alexander (Sascha) Klein
Java 9 Update Angular
1 Tag: 07.03. / 20.06.2018 alexander.klein@codecentric.de
€ 695,- 3 Tage: 12.03. / 25.06.2018 € 1.685,-
Realisierung Java EE 8 Power Workshop Progressive Web Apps
5 Tage: 19.02. / 04.06.2018 € 2.490,- 1 Tag: 23.03. / 06.07.2018 € 695,-
Alexander (Sascha) Klein ist Niederlassungsleiter der codecentric
Continuous Delivery AG am Standort Stuttgart. Er ist seit etwa zwanzig Jahren im Java-
Software- Viele weitere Seminare finden Sie unter www.oio.de.
Umfeld
Alle Preise alssich
verstehen Entwickler,
zzgl. gesetzl.Architekt und Coach tätig. Seine Interessen-
Mehrwertsteuer.
Sanierung gebiete
Alle Seminare sindsind
auch UI-Entwicklung, Ergonomie, DSLs
als Inhouse- oder Individualschulungen und Produktivität in
möglich.
der Software-Entwicklung. Er ist bekennender Groovy-Jünger und
Committer beim)Open-Source-Projekt
Schulung ) Griffon.)
) Beratung ) Entwicklung )
OIO - Orientation in Objects GmbH I Weinheimer Str. 68 I 68309 Mannheim I Tel. +49 621 71839-0 I Fax +49 621 71839-50 I info@oio.de I www.oio.de
Resilient Software Design Patterns
Thorsten Maier, Orientation in Objects GmbH
Dieser Artikel beschreibt ausgewählte Entwurfsmuster zur Erstellung einer Software, die möglichst
widerstandsfähig (resilient) gegenüber dem Ausfall einzelner Teilsysteme ist. Die vorgestellten Muster sind
anhand einer kurzen Beispiel-Implementierung konkretisiert.
Software-Systeme werden immer komplexer. Eine klare Strukturierung und der Ausfall eines einzelnen Subsystems wird immer wahrschein-
und damit einhergehend eine Modularisierung ist die wichtigste Grund- licher. Ein Ausfall kann beispielsweise durch einen Programmierfehler
voraussetzung, um komplexe Systeme auch langfristig warten zu kön- bei einem Versionsupdate, die Störung des Netzwerks oder aber auch
nen. Mit steigender Komplexität steigt auch die Zahl der einzelnen Teile, durch die Überlastung der Datenbank entstehen.
Java aktuell 01/18 55
Abbildung 1: Asynchrone Kommunikation
Traditionell haben wir versucht, die Verfügbarkeit einer Software- JmsTemplate jmsTemplate = context.getBean(JmsTemplate.
Lösung durch eine möglichst hohe Verfügbarkeit der einzelnen Teile class);
jmsTemplate.convertAndSend("coffeeOrderQueue", new
zu maximieren. Ab einer gewissen Anzahl von Einzelteilen ist dieses CoffeeOrder("horsten", "Cappuccino"));
Vorgehen allerdings extrem aufwendig, da sich die Wahrscheinlich-
keit für einen Ausfall mit jedem Teil erhöht. Listing 1
Warum entwickeln wir unsere Software zukünftig nicht unter der
Annahme, dass der Ausfall eines Teilsystems nicht die Ausnahme, @JmsListener(destination = "coffeeOrderQueue")
sondern der Normalfall ist? Statt wie bisher zu versuchen, einen public void receiveMessage(CoffeeOrder coffeeOrder) {
System.out.println("Received ");
Fehler um jeden Preis zu verhindern, versuchen wir stattdessen, }
möglichst gut auf die auftretenden Fehler und Ausfälle zu reagieren.
Genau das ist die Grundidee des Resilience Software Design. Wir Listing 2
entwerfen ein Software-System, das möglichst widerstandsfähig
gegenüber Fehlern ist. Dabei helfen uns verschiedene wiederkeh-
rende Muster. Wahrscheinlichkeit ohnehin nicht alle Datensätze in einer sinnvollen
Zeit verarbeiten kann.
Grundprinzipien
Betrachten wir zunächst das grundsätzliche Vorgehen für den Ent- Um die Verfügbarkeit des Gesamtsystems weiter zu erhöhen, kön-
wurf eines widerstandsfähigen Systems. Grundlage sind dabei die nen die lose gekoppelten Teile zudem redundant ausgelegt sein.
vier wesentlichen Prinzipien des Resilience Software Designs: Da in einer widerstandsfähigen Anwendung ohnehin alle Prozesse
mit dem Ausfall der anderen Prozesse und somit der kurzzeitigen
• Isolation Nichtverfügbarkeit rechnen, ist die lastverteilte Umschaltung zwi-
• Lose Kopplung schen mehreren redundanten Kopien der logische nächste Schritt.
• Redundanz Zu guter Letzt ist mit einem Fallback-Verhalten auf der Seite des
• Fallback Aufrufers sichergestellt, dass zumindest ein wesentlicher Teil der
Funktionalität auch dann noch aufrechterhalten werden kann, wenn
Eine widerstandsfähige Anwendung kann nur entstehen, falls wir trotz Redundanz Teilsysteme vollständig ausfallen.
möglichst isolierte Fehlereinheiten entwerfen, die auch in einer in-
stabilen Umgebung ihren Dienst möglichst lange aufrechterhalten. Design-Muster
In jeder Fehlereinheit gelten alle umliegenden Teile per Definition Nachdem wir uns die abstrakte Vorgehensweise für die Erstellung
als instabil; daher sollte die Kommunikation nach außen auf ein einer widerstandsfähigen Anwendung angeschaut haben, folgt eine
Mindestmaß reduziert werden. Ist eine Kommunikation notwendig, Auswahl der wichtigsten Muster zur Umsetzung dieses Konzepts.
so sollte jede Einheit jederzeit mit einem Kommunikationsfehler Diese lassen sich grob in zwei Kommunikationsarten einteilen: Wir
rechnen und eine geeignete Reaktion vorsehen. Die angenomme- unterscheiden zwischen asynchroner und synchroner Kommuni-
ne Instabilität der Subsysteme bedeutet außerdem, dass bei einem kation. Asynchrone Aufrufe führen an sich bereits zu einer wider-
Aufruf von außen alle Aufrufparameter validiert werden müssen. standsfähigen Anwendung. Bei synchroner Kommunikation kann
Daraus potenziell entstehende Fehler lassen sich so möglichst früh man die Widerstandsfähigkeit mit Mustern wie Verzeichnisdienst,
unterbinden. Circuit Breaker oder clientseitigem Load-Balancing erhöhen.
Damit das Gesamtsystem trotz der Trennung in abgeschottete Alle Konzepte dieses Artikels sind mit einem kurzen Code-Beispiel
Einheiten seine Aufgabe erfüllen kann, sind definierte Schnittstel- verdeutlicht. Für die technische Umsetzung bietet sich Spring [1] an,
len zwischen den Teilen von entscheidender Bedeutung. Das Ziel da in diesem Framework sowie den zahlreichen Erweiterungen be-
der Schnittstellen ist die lose Kopplung der Teile, um deren Unab- reits all die vorgestellten Konzepte integriert wurden.
hängigkeit zu bewahren. Sie sollten möglichst freundlich mit ihren
Aufrufern umgehen, sodass das Auftreten von Fehlern im Client Asynchrone Kommunikation
möglichst unwahrscheinlich wird. Falls beispielsweise eine grafi- Vergleichbar mit den Schotten im Schiffsbau soll die Trennung zwi-
sche Benutzeroberfläche mehrere Millionen Datensätze aus einer schen den isolierten Teilsystemen dafür sorgen, dass niemals das
Datenbank-Tabelle anfordert, sollte die Menge der ausgelieferten System als Ganzes, sondern höchstens einzelne Teile funktionsun-
Datensätze entgegen dem Willen des Aufrufers auf einen sinnvollen fähig werden. Diese geforderte Isolation kann im einfachsten Fall
Wert beschränkt werden. Nur so kann die Reaktionsfähigkeit des erreicht werden, indem Sender und Empfänger lediglich indirekt
Gesamtsystems gewährleistet werden, da der Aufrufer mit hoher über Nachrichten kommunizieren (siehe Abbildung 1).
56
iii
iii
iii
www.ijug.eu
iii
Abbildung 2: Widerstandsfähige synchrone Kommunikation
Die Nachrichten werden in der Queue zwischengespeichert und so- zwar nicht unmöglich, aber durchaus anspruchsvoll ist.
mit kann der Sender unmittelbar nach dem Versand einer Nachricht
mit seiner Arbeit fortfahren; er muss nicht auf die Verfügbarkeit ei- Bei genauerer Analyse der Anwendungsfälle einer Anwendung soll-
nes Empfängers warten. Gleichzeitig ist auch der Empfänger nicht te man diese transaktionale Denkweise allerdings hinterfragen. Oft
auf die Verfügbarkeit des Senders angewiesen und kann die Nach- ist es ausreichend, wenn die Konsistenz der Daten nicht sofort, son-
richt zu einem für ihn passenden Zeitpunkt verarbeiten. dern erst zu einem späteren Zeitpunkt hergestellt werden kann. Im
Gegensatz zu „Strict Consistency“, bei der die Konsistenz am Ende
Kommen wir zur konkreten Implementierung. Der Versand einer jeder Aktion sichergestellt wird, reicht es bei „Eventual Consistency“,
asynchronen Nachricht in eine Queue wird bei Spring durch die Klas- dass die Daten schlussendlich in naher Zukunft konsistent sind.
se „JmsTemplate“ unterstützt (siehe Listing 1). Als Empfänger für die
Nachrichten einer Queue kann man sich mit der Annotation „@Jms- „Eventual Consistency“ lässt sich mithilfe asynchroner Kommunika-
Listener“ registrieren (siehe Listing 2). tion sicherstellen, während für „Strict Consistency“ auf synchrone
Kommunikation gesetzt werden muss. Im Blog-Artikel „Starbucks
Obwohl die Vorteile der asynchronen Kommunikation über Queues Does Not Use Two-Phase Commit“ [2] ist diese Thematik anhand
den meisten bekannt sein dürften, wird diese Art der Kommunikati- einer Kaffeebestellung sehr anschaulich erläutert. Zusammenfas-
on dennoch in traditionellen Systemen verhältnismäßig selten ein- send ist beschrieben, dass aus Gründen der Durchsatzoptimierung
gesetzt. Ein Grund dafür ist die unter Software-Entwicklern weit- und der Fehlertoleranz ein asynchroner Kommunikationsansatz
verbreitete „transaktionale Denkweise“. Damit ist gemeint, dass wir mit einer Becherwarteschlange beim Bestellvorgang eines Kaffees
darauf bedacht sind, unseren Datenbestand zu jedem beliebigen deutliche Vorteile bietet.
Zeitpunkt konsistent zu halten, und dass wir dies über Transakti-
onen sicherstellen müssen. Genau dies lässt sich mit asynchro- Was können wir daraus lernen? Wir sollten für jeden Anwendungs-
ner Kommunikation über mehrere Prozesse hinweg allerdings nur fall analysieren, ob „Eventual Consistency“ gegebenenfalls aus-
schwer erreichen, denn wir müssten unsere Transaktionsgrenze reichend ist. Dann können wir durch den Einsatz von asynchroner
über die beteiligten Prozesse hinweg aufspannen, was technisch Kommunikation ein deutlich widerstandsfähigeres Gesamtsystem
entwerfen.
Widerstandsfähige synchrone Kommunikation
@SpringBootApplication Selbstverständlich ist es nicht immer möglich, auf asynchrone Kom-
@EnableEurekaServer
public class Application {
munikation zu setzen. Daher müssen wir in diesen Fällen auf syn-
public static void main(String[] args) { chrone Aufrufe zurückgreifen. Der entscheidende Nachteil im Sinne
SpringApplication.run(Application.class, args); einer widerstandsfähigen Anwendung ist dabei, dass für eine erfolg-
}
} reiche Kommunikation beide Partner gleichzeitig kommunikations-
bereit sein müssen. Dies wiederum ist in einem System, in dem wir
Listing 3 alle Kommunikationspartner per Definition als unzuverlässig ein-
stufen, nicht immer gegeben. Wir benötigen daher Mechanismen,
mit denen wir auch diese Art der Kommunikation widerstandsfähig
org.springframework.cloud gegen Ausfälle machen können.
spring-cloud-starter-eureka
Abbildung 2 zeigt den schematischen Aufbau einer fehlertoleranten
Listing 4 synchronen Kommunikation. Dienst 1 möchte mit Dienst 2 kommu-
Java aktuell 01/18 57
nizieren. Die Widerstandsfähigkeit wird hierbei durch den Einsatz @HystrixCommand(fallbackMethod = "fallback")
public String readString() {
eines Verzeichnisdienstes, eines Circuit Breakers und eines client- return remoteServiceCall();
seitigen Load-Balancer erreicht. }
public String fallback() {
Verzeichnisdienst return "Fallback result";
Der Verzeichnisdienst sorgt dafür, dass Dienst 1 nicht wissen muss, }
wo Dienst 2 gerade ausgeführt wird. Soll eine Kommunikation auf-
gebaut werden, wendet sich Dienst 1 über den clientseitigen Load- Listing 5
Balancer – der im Anschluss noch vorgestellt wird – an den Ver-
zeichnisdienst und ruft von dort eine oder auch mehrere Instanzen
von Dienst 2 ab. Auch wenn Dienst 2 seit der letzten Kommunika- reagiert, kann der Circuit Breaker diese Fehlersituation erkennen
tion umgezogen ist oder durch eine andere Instanz ersetzt wurde, und eine Fallback-Antwort an den Aufrufer liefern. Für die prakti-
kann der anschließende, entfernte Aufruf trotzdem fehlerfrei aus- sche Umsetzung dieses Konzepts bedienen wir uns wieder einer
geführt werden. von Netflix zur Verfügung gestellten Open-Source-Bibliothek na-
mens Hystrix [5]. Listing 5 zeigt, wie wir damit eine solche Sicherung
Mit Eureka [3] können wir auf einen fertigen Verzeichnisdienst zu- per Annotation konfigurieren können.
rückgreifen, der bei Netflix zum Einsatz kommt und somit bereits
gezeigt hat, dass er auch für sehr große Systeme bestens geeignet Die Annotation „@HystrixCommand“ erstellt automatisch einen
ist. Mit Spring Cloud Netflix können wir Eureka auf einfache Art und Proxy, der zur Absicherung des entfernten Methodenaufrufs einge-
Weise in unsere bestehende Infrastruktur einbinden. Listing 3 zeigt die setzt wird. Falls der Aufruf „remoteServiceCall()“ nach einem konfi-
Erstellung eines Verzeichnisdienst-Servers als Spring-Anwendung. gurierbaren Timeout (Default: 1 Sekunde) kein Ergebnis liefert, wird
automatisch die Methode „fallback“ aufgerufen und deren Rückgabe-
Die einzelnen Dienste registrieren sich anschließend automatisch wert an den Aufrufer geliefert. Die mit dieser Annotation konfigurierte
während des Startvorgangs beim Eureka-Verzeichnisdienst. Damit Sicherung verwaltet einen internen Zustand und verfügt somit über
dies funktioniert, muss lediglich die passende Eureka-Client-Imple- eine gewisse Intelligenz. Abbildung 3 zeigt die möglichen Zustände
mentierung im Klassenpfad des Dienstes vorhanden sein. Listing 4 und die zugehörigen Zustandsübergänge.
zeigt die entsprechende Maven-Dependency.
Im Zustand „Geschlossen“ werden alle Aufrufe an den entfernten
Circuit Breaker Dienst weitergeleitet und dessen Reaktion abgewartet. Falls mehr
Durch den Einsatz eines Verzeichnisdienstes erreichen wir eine als 50 Prozent der letzten 20 Aufrufe länger als eine Sekunde ge-
Ortstransparenz für entfernte Dienste. Problematisch ist dies al- dauert haben, springt die Sicherung auf und wechselt in den Zu-
lerdings, wenn ein solcher Dienst unmittelbar nach dem Auffinden stand „Offen“. Dieser Zustandsübergang findet bewusst nicht bei
ausfällt oder umzieht. Für diesen Fall benötigen wir einen zweiten der ersten Überschreitung des Timeouts statt, damit einzelne Aus-
Sicherungsmechanismus. Zwischen den beiden Diensten kann zu- reißer keine Auswirkung auf das Verhalten des Systems haben.
sätzlich ein sogenannter „Circuit Breaker“ [4] eingesetzt werden.
Dieser überwacht die Kommunikation zwischen beiden Kommuni- Im Zustand „Offen“ wird versucht, den entfernten Dienst nicht un-
kationsseiten und entbindet den Aufrufer somit von der Fehlerbe- nötig mit Aufrufen zu belasten; daher werden fünf Sekunden lang
handlung. Falls der entfernte Dienst zu spät oder überhaupt nicht alle Anfrage mit dem Fallback-Wert beantwortet. Nach dieser War-
Abbildung 3: Hystrix-Zustände
58
iii
iii
iii
www.ijug.eu
iii
Wir suchen Dich!
Spannende Aufgaben zu vergeben für
* Java Senior Consultant (m/w)
* Java Consultant (m/w)
* Atlassian Consultant (m/w)
Mach mit im Expertenhaus für die Softwareentwicklung mit Java und
JavaScript in Mannheim.
Anspruchsvolle Entwicklungprojekte, täglicher Austausch mit anderen
Technologie-Begeisterten, unser hausinternes Schulungsprogramm
und vieles mehr erwarten Dich.
Auch java-erfahrene Studentinnen und Studenten sind bei uns immer
willkommen.
Nutze Deine Chance.
Werde Teil des bunten OIO-Teams.
Nähere Infos an unserem OOP-Stand 2.11.
) Schulung ) ) Beratung ) ) Entwicklung )
OIO - Orientation in Objects GmbH I Weinheimer Str. 68 I 68309 Mannheim
Tel. +49 621 71839-0 I Fax +49 621 71839-50 I info@oio.de I www.oio.detezeit findet ein automatischer Übergang in den Zustand „Halbof- Durch die ständige Analyse der Antwortzeiten reguliert sich das
fen“ statt. Nun stellt ein erneuter Zugriff auf den entfernten Dienst System selbstständig und kann daher auf eine zentrale Steuerung
fest, ob dieser wieder verfügbar ist. Ist dies der Fall, wird die Siche- verzichten.
rung geschlossen; andernfalls erneut geöffnet und es findet nach
weiteren fünf Sekunden Wartezeit der nächste Testaufruf statt. Die Fazit
Default-Werte für die Timeouts sowie für den prozentualen Anteil Eine Anwendung ist mithilfe der in diesem Artikel gezeigten Muster
der erlaubten Timeout-Überschreitungen lassen sich per Konfigu- widerstandsfähig gegenüber Fehlern. Am einfachsten gelingt dies
ration anpassen. durch den Umstieg auf asynchrone Kommunikation, da hierdurch
automatisch isolierte und nur lose miteinander gekoppelte Teilsys-
Clientseitiges Load-Balancing teme entstehen. Aber auch synchrone Kommunikation kann wie ge-
Durch den Einsatz des Verzeichnisdienstes und des Circuit Brea- zeigt unter Einsatz eines Verzeichnisdienstes, eines Circuit Breaker
ker konnten wir bereits eine gewisse Ausfallsicherheit erreichen. und durch clientseitiges Load-Balancing resilient gemacht werden.
Allerdings können wir damit noch nicht auf unterschiedliche Last-
anforderungen reagieren. Die Last kann auf mehrere redundante Neben den hier beschriebenen wichtigsten Mustern gibt es viele
Instanzen des entfernten Dienstes verteilt werden. Ist er zustands- weitere, die uns bei der Implementierung eines möglichst stabilen
los implementiert, lässt er sich problemlos mehrfach starten. Klas- Systems helfen können. Dazu gehören beispielsweise ein Konfi-
sischerweise hat man eine solche Lastverteilung durch die Zwi- gurationsserver, ein API Gateway und ein externer HTTP-Session-
schenschaltung eines getrennten Load-Balancer erreicht. Bei vielen Speicher. Zu bedenken ist allerdings wie immer, dass jedes neu ver-
einzelnen Diensten führt dies allerdings zu einem hohen Konfigu- wendete Muster Einarbeitungs- und Implementierungsaufwände
rationsaufwand. Daher wollen wir uns hierzu eine leichtgewichti- zur Folge hat und dass wir uns daher in jeder Anwendung auf ein
ge und dennoch widerstandsfähige Alternative anschauen. Dabei Neues für die richtigen Muster entscheiden müssen.
verwenden wir einen im Aufrufer eingebauten, clientseitigen Load-
Balancer. Dieser ruft sich vom Verzeichnisdienst alle zur Verfügung Weitere Informationen
stehenden Instanzen des Dienstes ab und verteilt dann selbststän- [1] http://projects.spring.io/spring-framework
[2] http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
dig die Aufrufe an die vorhandenen Instanzen. Listing 6 zeigt den [3] https://github.com/Netflix/eureka
Einsatz dieses Konzepts bei einem weiteren Netflix-Projekt mit dem [4] https://martinfowler.com/bliki/CircuitBreaker.html
Namen Ribbon [6]. [5] https://github.com/Netflix/Hystrix
[6] https://github.com/Netflix/ribbon
„RestTemplate“ ist eine Hilfsklasse von Spring, mit der per HTTP-
Aufrufen ein Rest-Service abgefragt werden kann. Die beiden Anno-
tationen „@LoadBalanced“ und „@RibbonClient“ sorgen nun dafür,
dass alle Instanzen von „dienst2“ über den Verzeichnisdienst abge-
rufen werden und der Aufruf der URL „http://dienst2/“ automatisch
auf diese Instanzen verteilt wird. Wann welche Instanz aufgerufen
wird, lässt sich über den konfigurierbaren Load-Balancer-Algorith-
mus beeinflussen.
Die „RoundRobinRule“ verteilt die Anfragen beispielsweise reihum;
„RandomRule“ wählt dagegen bei jedem Aufruf zufällig eine Instanz
aus. Am interessantesten für den Einstieg ist allerdings die „Weigh-
tedResponseTimeRule“. Dabei werden die Antwortzeiten der ver-
schiedenen Instanzen analysiert und die Aufrufhäufigkeiten diesen
Zeiten angepasst. Die schnellste Instanz bekommt verhältnismäßig
die meisten Aufrufe. Aber auch langsame Instanzen werden hin und
wieder aufgerufen, um die schnellen Instanzen nicht zu überlasten.
Thorsten Maier
@RibbonClient(name = "dienst2") Thorsten.Maier@oio.de
public class Application {
@LoadBalanced
@Bean Thorsten Maier arbeitet bei OIO Orientation in Objects GmbH in
RestTemplate restTemplate() { Mannheim. Er erschließt kontinuierlich bessere Wege, Software
return new RestTemplate(); zu entwickeln, indem er selbst als leidenschaftlicher Software-
} Entwickler mit Java und JavaScript unterwegs ist und anderen als
Berater, Trainer und Autor dabei hilft. Trotz seiner Begeisterung für
public String remoteServiceCall() {
return restTemplate().getForObject("http://di-
Neues sind ihm Menschen stets wichtiger als Technologien. Sein
enst2/", String.class); Hauptaugenmerk liegt daher auf der Frage, wie sich modernste
} Technologien in gewachsene Umgebungen einbinden lassen und
} wann man besser auf Bestehendes zurückgreifen sollte.
Listing 6
Java aktuell 01/18 59) Seminarprogramm )
1. Halbjahr 2018
Java Seminare Open Source Seminare
Entscheider Software Entwicklungsumgebung
Java für Java im Web NoSQL mit Java im Enterprise Java für Versionsverwaltung Versionsverwaltung Reporting mit
Git kompakt
Entscheider für Architekten Überblick Architekten mit Subversion mit Git Eclipse BIRT
Dauer: 1 Tag / Preis: € 805,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 1 Tag / Preis: € 695,- Dauer: 1 Tag / Preis: € 695,- Dauer: 2 Tage / Preis: € 1.255,- Dauer: 2 Tage / Preis: € 1.255,-
Termine: 05.02. / 14.05. / 10.09.. Termine: 21.02. / 06.06. / 19.09. Termine: 08.03 / 21.06. / 11.10. Termine: 19.02. / 04.06. / 17.09. Termine: a. A.. Termine: 08.03. / 21.06. / 11.10. Termine: a. A.. Termine: 22.02. / 07.06. / 20.09.
Grundlagen Vertiefung Das Buildtool Gradle Selenium - Test
Jenkins Grundlagen
Apache Maven für Java Builds von Webanwendungen
Java für
Einführung in Groovy Kotlin Refactoring Workshop
Programmierer Dauer: 1 Tag / Preis: € 695,- Dauer: 1 Tag / Preis: € 695,- Dauer: 1 Tag / Preis: € 805,- Dauer: 2 Tage / Preis: € 1.255,-
Termine: 08.05. / 04.10. Termine: 09.03. / 22.06. / 12.10. Termine: 07.05. / 05.10. Termine: 01.03. / 14.06. / 27.09.
Dauer: 5 Tage / Preis: € 2.125,- Dauer: 3 Tage / Preis: € 1.685,- Dauer: 2 Tage / Preis: € 1.195,- Dauer: 2 Tage / Preis: € 1.195,-
Termine: 05.02. / 14.05. / 10.09. Termine: 18.04. / 29.10. Termine: 09.07. / 01.10. Termine: 01.03. / 27.09.
Server / Frameworks
Entwicklung und Betrieb Einführung in das
Testen von Clean Code und Spring Boot Cloud Native mit Spring
Effective Java Design Patterns mit Java mit Wildfly 10 Spring Framework
Java Programmen Software Craftsmanship
Dauer: 3 Tage / Preis: € 2.055,- Dauer: 3 Tage / Preis: € 1.685,- Dauer: 2 Tage / Preis: € 1.255,- Dauer: 2 Tage / Preis: € 1.255,-
Dauer: 2 Tage / Preis: € 1.195,- Dauer: 3 Tage / Preis: € 1.685,- Dauer: 4 Tage / Preis: € 2.170,- Dauer: 2 Tage / Preis: € 1.120,-
Termine: 18.04. / 03.09. Termine: 12.03. / 25.06. / 15.10. Termine: 08.02. / 17.05. / 13.09. Termine: 15.03. / 28.06. / 18.10.
Termine: 12.02. / 04.10. Termine: 26.02. / 11.06. / 24.09. Termine: a. A. Termine: 14.06. / 22.11.
Docker
Java 8 Update - Reaktive Program- Resilient Software Einführung in GWT GWT Architekturen Das Vaadin Toolkit
Java 9 Update für Java-Entwickler
Lambda und Streams mierung mit Java Design mit Java
Dauer: 1 Tag / Preis: € 695,- Dauer: 2 Tage / Preis: € 1.255,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 3 Tage / Preis: € 1.685,-
Dauer: 2 Tage / Preis: € 1.255,- Dauer: 1 Tag / Preis: € 695,- Dauer: 1 Tag / Preis: € 695,- Dauer: 1 Tag / Preis: € 695,-
Termine: 07.03. / 20.06. / 10.10. Termine: 09.04. / 17.12. Termine: 11.04. / 19.12. Termine: 19.02. / 04.06. / 17.09.
Termine: 05.03. / 18.06. / 08.10. Termine: 07.03. / 20.06. / 10.10. Termine: 22.03. / 05.07. / 25.10. Termine: 19.03. / 02.07. / 22.10.
Java Enterprise Apache Camel Apache Cassandra Apache Kafka
Java EE 8 Enterprise JavaFX für moderne Dauer: 2 Tage / Preis: € 1.255,- Dauer: 2 Tage / Preis: € 1.255,- Dauer: 2 Tage / Preis: € 1.255,-
Java Performance
Power Workshop JavaBeans GUI-Clients Termine: 15.03. / 18.10. Termine: 28.06. / 06.12. Termine: 08.02. / 17.05. / 13.09.
Dauer: 5 Tage / Preis: € 2.490,- Dauer: 3 Tage / Preis: € 1.685,- Dauer: 2 Tage / Preis: € 1.255,- Dauer: 4 Tage / Preis: € 2.170,-
Termine: 19.02. / 04.06. / 17.09. Termine: a. A. Termine: 05.03. / 18.06. / 08.10. Termine: 12.02. / 17.12.
Java Persistence API Java Persistence CDI - Dependency In-
JavaServer Faces
(JPA) mit Hibernate Performance Tuning jection Standard für Java
Dauer: 3 Tage / Preis: € 1.685,-
Termine: 26.02. / 11.06. / 24.09.
Dauer: 2 Tage / Preis: € 1.460,-
Termine: 07.03. / 20.06. / 10.10.
Dauer: 3 Tage / Preis: € 1.685,-
Termine: 12.03. / 25.06. / 15.10.
Dauer: 1 Tag / Preis: € 695,-
Termine: a. A.
XML Seminare
Grundlagen Vertiefung
Java EE Web Services OSGi Microservices XML XML XSL und Transformation
Batch Applications mit SOAP und Java Service Platform mit Java Einführung Schema Formatting Objects und Styling mit XSLT
Dauer: 2 Tage / Preis: € 1.255,- Dauer: 3 Tage / Preis: € 1.685,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 3 Tage / Preis: € 1.575,- Dauer: 2 Tage / Preis: € 1.195,- Dauer: 2 Tage / Preis: € 1.120,- Dauer: 2 Tage / Preis: € 1.195,-
Termine: 16.04. / 06.09. Termine: 23.04. / 17.12. Termine: 23.04. / 01.10. Termine: 05.03. / 18.06. / 08.10. Termine: 12.03. / 25.06. / 15.10. Termine: 25.04. / 29.10. Termine: a. A. Termine: 15.03. / 28.06. / 18.10.
Seminare zur Web-Programmierung Seminare zur Methodik und Prozessen
Programmierung Methodik Soft Skills
JavaScript JavaScript ECMAScript Soft Skills
Angular SAFe® for Teams Leading SAFe®
Intensiveinstieg Engineering mit Typescript für Agile Projekte
Dauer: 2 Tage / Preis: € 1.195,- Dauer: 2 Tage / Preis: € 1.195,- Dauer: 3 Tage / Preis: € 1.685,- Dauer: 3 Tage / Preis: € 1.685,- Dauer: 2 Tage / Preis: € 1.590,- Dauer: 2 Tage / Preis: € 1.590,- Dauer: 2 Tage / Preis: € 1.460,-
Termine: 08.02. / 17.05. / 13.09. Termine: 01.03. / 14.06. / 27.09. Termine: 26.03. / 11.06. / 24.09. Termine: 12.03. / 25.06. / 15.10. Termine: a. A. Termine: 09.04. / 01.10. Termine: 11.04. / 01.10.
jQuery als JavaScript Webentwicklung Scrum Extreme Persönlichkeits-
Progressive Web Apps Node.js kompakt Domain Driven Design
Framework mit React Jumpstart Programming entwicklung
Dauer: 3 Tage / Preis: € 1.685,- Dauer: 1 Tag / Preis: € 695,- Dauer: 2 Tage / Preis: € 1.260,- Dauer: 2 Tage / Preis: € 1.255,- Dauer: 1 Tag / Preis: € 805,- Dauer: 1 Tag / Preis: € 805,- Dauer: 1 Tag / Preis: € 695,- Dauer: 2 Tage / Preis: € 1.460,-
Termine: a. A. Termine: 23.03. / 06.07. / 26.10. Termine: a. A. Termine: 15.03. / 28.06. / 18.10. Termine: 21.03. / 04.07. / 24.10. Termine: a. A. Termine: 20.03. / 03.07. / 23.10. Termine: 01.02. / 03.09.
Design
User Stories Kanban Kaikaku und Kaizen in Zeit- und
effektiv erstellen Jumpstart der Softwareentwicklung Selbstmanagement
Modernes Webdesign Modernes Webdesign Web Components
HTML 5 Update
mit HTML 5 und CSS 3 mit CSS 3 Grundlagen Dauer: 1 Tag / Preis: € 805,- Dauer: 1 Tag / Preis: € 805,- Dauer: 1 Tag / Preis: € 695,- Dauer: 1 Tag / Preis: € 805,-
Termine: 19.03. / 02.07. / 22.10. Termine: 22.03. / 05.07. / 25.10. Termine: a. A. Termine: 02.05. / 25.10.
Dauer: 3 Tage / Preis: € 1.685,- Dauer: 1 Tag / Preis: € 695,- Dauer: 2 Tage / Preis: € 1.120,- Dauer: 3 Tage / Preis: € 1.770,-
Termine: 05.02. / 14.05. / 10.09. Termine: 05.02. / 14.05. / 10.09. Termine: 06.02. / 15.05. / 11.09. Termine: a. A.
Architektur-Katas zum Grundlagen Führen und Managen
UML für Analytiker
Training agiler Teams Projektmanagement von Projektteams
Dauer: 3 Tage / Preis: € 1.685,- Dauer: 1 Tag / Preis: € 805,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 2 Tage / Preis: € 1.460,-
Termine: a. A. Termine: 23.02. / 08.06. / 21.09. Termine: 07.05. / 11.09. Termine: 26.04. / 20.12.
Entscheider Seminare
Werkzeuge
Architekten
Confluence Confluence - Bitbucket Server -
Java im Web NoSQL mit Java im Cloud Architektur-Katas zum für Anwender Fachliche Administration Enterprise Git
für Architekten Überblick für Entscheider Training agiler Teams
Dauer: 1 Tag / Preis: € 805,- Dauer: 1 Tag / Preis: € 805,- Dauer: 2 Tage / Preis: € 1.460,-
Dauer: 2 Tage / Preis: € 1.460,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 1 Tag / Preis: € 805,- Dauer: 1 Tag / Preis: € 805,-
Termine: 20.03. / 03.07. / 23.10. Termine: 21.03. / 04.07. / 24.10. Termine: 20.03. / 03.07. / 23.10.
Termine: 21.02. / 06.06. / 19.09. Termine: 08.03 / 21.06. / 11.10. Termine: 26.04. / 07.09. Termine: 23.02. / 08.06. / 21.09.
Jira Plattform - Jira Software Jira
Enterprise Java für Microservices Fachliche Administration für agile Projekte for Business
REST APIs
Architekten für Architekten
Dauer: 1 Tag / Preis: € 805,- Dauer: 1 Tag / Preis: € 805,- Dauer: 1 Tag / Preis: € 805,-
Dauer: 2 Tage / Preis: € 1.460,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 1 Tag / Preis: € 805,-
Termine: 22.03. / 05.07. / 25.10. Termine: 23.03. / 06.07. / 26.10. Termine: 19.03. / 02.07. / 22.10.
Termine: 19.02. / 04.06. / 17.09. Termine: 06.02. / 15.05. / 11.09. Termine: 08.03. / 11.10.
Projektleiter
Java für Führen und Managen Grundlagen Open Source Compliance Alle Seminare sind auch als Inhouse- oder Individualschulungen möglich.
Entscheider von Projektteams Projektmanagement Management kompakt
Dauer: 1 Tag / Preis: € 805,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 2 Tage / Preis: € 1.460,- Dauer: 1 Tag / Preis: € 805,-
* Alle Preise verstehen sich zzgl. gesetzl. Mehrwertsteuer. Änderungen vorbehalten.
Termine: 05.02. / 14.05. / 10.09. Termine: 26.04. / 20.12. Termine: 07.05. / 11.09. Termine: 02.03. / 04.05. / 28.09..
© Orientation in Objects GmbH ׀Weinheimer Str. 68 ׀68309 Mannheim ׀Tel. +49 621 71839-0 ׀Fax +49 621 71839-50 ׀info@oio.de ׀www.oio.deSie können auch lesen
