Okay. Also, worum geht es mir?
Wenn, warum will man überhaupt Software integrieren? Ja,
ich weiß nicht, ihr kommt ja schon aus einer Zeit,
wo Software eigentlich integriert ist, als ich noch studiert habe.
Da hatte man kein Internet. Da hatte man auch keine verknüpften Applikationen.
Man hatte nur Einzelrechner, auf denen man Software hatte.
Eine Internet, nettlose Zeit könnt ihr euch wahrscheinlich
gar nicht mehr vorstellen, ne? Auf jeden Fall,
worum es hier geht, ist,
dass Anwender ein Softwaresystem auf ihrem Rechner haben und eigentlich
Funktionen aus mehreren Softwaresystemen aufrufen wollen sollen
Und was man dafür tun muss, ist relativ logisch.
Man muss die ganzen isolierten Applikationen integrieren.
Ich werde noch hübscher gemacht auf der Aufnahme.
Und hat dabei verschiedenste Probleme, mit denen man umgehen muss.
Man hat einmal das Problem, dass Netzwerke logischerweise langsam sind.
Man hat das Problem, dass Netzwerke unzuverlässig sind.
Die Applikationen sind verschieden in ihrer Art. Das geht schon damit los,
dass in der einen Applikation der Kunde die Kundennummer hat und
in der anderen die andere Kundennummer und Veränderungen bei den
einzelnen Systemen sind auch logischerweise unausweichlich
Ich glaube, das habt ihr ja auch schon in euren
ersten zwei Semestern von Axel bestimmt auch gehört,
dass eine Software, die nicht mehr verändert wird,
ist im Grunde tot, weil keiner mehr weiß,
was man daran machen soll, wie man sie verbessern soll.
Hallo? Nicht? Geht's weiter? Nein.
Software kaputt? Das geht noch. Gut,
ich werde euch mit euch vier Ansätze diskutieren,
wie man verschiedene Applikationen integrieren kann
Mir sind diese Ansätze für euch einfach fürs Verständnis sehr wichtig,
dass ihr also wisst,
okay, wenn ihr später in irgendeine Firma kommt,
werdet ihr irgendwas von diesen vier Dingen finden und ihr müsst einschätzen können,
was das für Vor- und für Nachteile hat und was es bedeutet,
wenn ihr dieses Konglomerat verändert.
Die allereinfachste Art Anwendung zusammen in irgendeiner Form zu integrieren,
ist, dass man Datentransfer macht,
dass man also in der einen Applikation regelmäßig irgendwelche Daten exportiert,
also ein File-Export macht und diese Daten in der anderen Applikation importiert.
Das wird heute ganz viel gemacht,
wir werden diese Ansätze gleich noch im Detail angucken,
Es wird heute immer noch sehr viel gemacht,
weil die meisten Systeme in der Lage sind,
irgendetwas in eine Datei zu schreiben.
Ja, komm aus separated file oder was auch immer
oder ein Textfeil, das können ganz viele.
Und was man heutzutage ja neumodisch macht, ist,
dass man irgendwelche XML-Files schreibt.
Ja, auch das ist im Grunde ja nur eine Methode,
um Daten zu transferieren. Ja, ich tue aus dem
einen Systemdaten raus und integriere ihnen das andere. Ja,
die nächste Form, verschiedene Applikationen zu integrieren, ist,
dass man zwei Applikationen, eine gemeinsame Datenbank nutzen lässt.
Das hat auch seine Vor- und Nachteile,
aber man hat dann zumindest schon mal den Datenbestand geteilt zwischen
beiden Applikationen
Dann gibt es was,
was ihr vielleicht auch schon mal gesehen habt in eurem Leben,
dass eine Softwareanwendung, nicht nur ihre Daten dem anderen zur Verfügung stellt,
sondern auch Funktionalität, die man aus der Ferne aufrufen kann.
Sowas nennt man einen Remote Procedure Envocation oder Remote Procedure Call. Ja,
das ist im Grunde dasselbe, was ihr tut,
wenn ein eins eurer, in ihren euren Klassen programmiert,
dass eins eure Objekte nachher ein anderes Objekt aufruft.
Das ist bei euch immer in einem Prozess, ja,
da wo ihr euer Java-Programm startet.
Und hier geht es über Prozessgrenzen und möglicherweise eben auch über Grenzen von Rechner.
Ja, also ihr könnt ja auf einem Rechner
mehrere Prozesse haben oder die sind verteilt
Gut, da hat man den Effekt,
dass die eine Anwendung schon Funktionalität von der anderen verwenden kann.
Und das Letzte, was ich euch noch mitgebracht habe,
ist, ist das nur sogenannte Messaging, das heißt,
Anwendungen tauschen Daten über Nachrichten aus.
Das kann man auch in Firmen vermehrt sehen,
in die Richtung geht auch so ein bisschen diese ganze Diskussion über Service-oriented Architecture,
also SOA, wenn ihr das schon mal als Schlagwort gehört habt.
So, ihr wisst ja, drei buchstabige Abkürzungen,
die Informatik erfindet täglich ungefähr zwei neue.
Einige muss man einfach wissen und so müsst ihr wissen,
Das ist heute in aller Munde, Sir, bis Oriented, Architecture.
Ja, also jedes Unternehmen,
was heute etwas auf sich hält, ist auf dem Weg,
ihre Anwendungslandschaft in Services umzubauen und eine Serviceorientierte Architektur zu haben.
Man kann es nicht lesen, aber wenn man weiß,
was ich hingeschrieben habe, dann kann man es gerade mal
so eben entwusziffern, glaube ich.
Gut, das Messaging ist so eine Grundlage für diese SOA-Architektur,
ich werde euch das gleich noch ein bisschen weiter erklären
Gut, wir gehen die im Einzelnen durch.
Ich habe immer erst mal so eine Folie,
wo draufsteht, was sind die Vor- und Nachteile?
Wie kann man das machen? Und dann habe ich ein Beispiel
euch mitgebracht aus einem Projekt, wo wir das auch eingesetzt haben,
damit ihr euch ein bisschen vorstellen könnt, wozu das gut ist.
Also bei einem Falltransfer, es geht ja immer darum,
dass ich zwei Applikationen sozusagen, die müssen irgendwie miteinander kommunizieren.
Und beim Falltransfer ist es ganz einfach,
die eine Applikation muss was exportieren,
dann haben wir irgendwelche Daten in irgendeinem Format und die andere muss das importieren.
Gut, was ist die Voraussetzung dafür?
Man muss ein gemeinsames Dateisystem haben, also einen gemeinsamen Zugriff
auf irgendetwas
Man muss sich über das Format einigen. Es ist ein Text,
weil es ist XML, ist es eine comma separated file.
Welche Kodierung habe ich? Das ist auch immer noch so eine hübsche Frage.
Und dann müssen der Exporter und der Importer das gleiche Format verstehen.
Das ist aber beherrschbar. Das mit dem gemeinsamen Dateisystem,
da muss man in der Regel mit den Administratoren von solchen Firmen reden.
Und das geht manchmal auch nicht so schnell,
weil die einen ganz anderen Fokus haben als irgendwas schnell hinzukriegen
für irgendeine Anwendung, sondern die betrachten eher das Gesamtsystem.
Aber an sich ist das eine einfach einfache Sache.
Das ist also einfach zu realisieren.
Man braucht keine weitere Software, man braucht keine Middleware
oder irgendwas
Braucht nur eine Programmiersprache, die in einen Pfeil schreiben kann,
als die erste Java-Version rauskam, da konnte Java das,
glaube ich, nicht.
Das gab es einfach noch nicht. Aber heute ist es
full fledged und kann das. Mir ist auch noch keine Programmiersprache begegnet,
die das nicht kann. Es ist eher dann ein Problem,
dass man auf verschiedenen Plattformen ist. Ich weiß nicht,
ob ihr schon mal zum Beispiel Wordtexte oder PowerPoint-Folien zwischen Mac
und PC und Windows hin und her transferiert habt.
Das sieht dann immer ein bisschen anders aus und das kann
euch an der Stelle natürlich auch passieren.
So, ein Vorteil ist noch, das Ganze ist asynchron.
Das heißt, Die Applikation B kann ausgeschaltet sein und
man kann das exportieren und kann es dann später importieren.
Zu dem Zeitpunkt, wo man gerade möchte.
Jede Applikation kann weiterarbeiten. Man hat also eine sehr,
sehr lose Kopplung. Das geht,
ohne dass der andere da ist und man muss eigentlich an
der Applikation nur irgendwo eine Möglichkeit schaffen, was zu exportieren.
Man muss also nicht an der Datenstruktur was ändern oder sonst
irgendwas machen oder Funktionen über das Netz zur Verfügung stellen,
sondern man braucht nur diesen Export bauen.
Alles, was die Applikationen im Internen macht,
bleibt alles verborgen
Ja. Der Nachteil ist natürlich, ich habe keinen
zeitnahen Datenabgleich. Ja, also wenn ich,
wenn meine Mitarbeiter ständig in Applikation A Daten eintippen,
dann kann ich das gar nicht so oft exportieren und importieren,
wie ich das vielleicht auf der anderen Seite brauche.
Also man muss sich immer fragen, wann ist das sinnvoll?
Ja, das ist auch was, was man mit dem
Kunden diskutieren muss, wenn der sowas möchte.
Reicht das? Reicht das? Einmal am Tag reicht es
einmal in der Stunde, reicht es alle zehn Minuten?
Reicht es alle Minute, dann ist es immer noch nicht zeitgenau.
Ja, einmal pro Minute ist zum Beispiel in meinem Hafenkontext
keine Möglichkeit. Ja, es muss schneller gehen,
man muss schneller wissen,
was los ist
Da sind Geräte hinten dran, das geht gar nicht.
So. Es sind ein paar Absprachen notwendig, Verzeichnisse, Dateinamen.
Ja, also man muss dabei zum Beispiel dran denken,
wenn man mal ältere Versionen wiederfinden will,
dann kann man nicht jedes Mal in denselben Dateinamen exportieren.
Ja, und da muss man vielleicht ein Datum dran machen.
Aber wenn man das dann mehrmals pro Tag macht,
dann braucht das Ding einen richtigen Zeitstempel, vielleicht sogar sekundengenau.
Ja, also der Dateiname muss in irgendeiner Form überlegt werden.
Wo ist das Verzeichnis, wo das hinkommt?
Wann werden die Exports eigentlich gelöscht? Wie merkt das System
B, dass System A fertig exportiert hat?
Also all solche Sachen muss man sich überlegen,
wie kriegt man das hin
So, und jedes System legt lokal,
also jede von diesen beiden Applikationen legt lokal fest,
was die Daten eigentlich bedeuten sollen.
Also was ist die Semantik von diesen Daten? Gut,
wir haben das bei uns in einem,
bei einer Firma gemacht, die gebrauchtwagen,
also erstmal die Autos vermietet und diese Autos werden dann später
verkauft und dafür gibt es eine Applikation, die das tut.
Ihr seht jetzt hier so ein Bildchen,
das so ein bisschen erklären soll, was da passiert.
Was machen die Leute? Es gibt ein Altsystem hier rechts,
aus dem kann man mit Hilfe eines Tools namens Fokus Daten exportieren.
Also man exportiert die Kfz-Daten von den Autos und was die eigentlich,
ob die kaputt sind, wie viel die kaputt sind.
So, und dann braucht man noch vom deutschen Autodienst eine Liste mit Kfz-Zubehör,
damit man sozusagen den Wert von diesen Autos berechnen kann und sagen kann,
was kriegt man noch dafür, was sollte man dafür kriegen.
So, und dann macht der Mitarbeiter,
wenn diese beiden Exports gelaufen sind,
dann erstellt er ein Angebot für das Auto in seiner Software und der Verkäufer,
der kann dann bestimmte Angebotskriterien eingeben und Kundendaten und kriegt dann Listen und zeigt dem Käufer sozusagen Angebote.
Also wenn sie das Auto kaufen mit der und der Ausstattung
und das hat schon ein paar Kratzer oder was auch immer,
dann wird das sie so und so viel kosten.
Dazu ist diese Applikation hier gut. Das ist also sozusagen eine von den beiden Applikationen,
die mit Daten, die Daten austauschen,
die andere verbirgt sich sozusagen hinter dem Altsystem, die sitzt da sozusagen drauf.
Und eigentlich will man die Daten zwischen den beiden austauschen und hier auch noch,
ja, zwischen dieser Applikation, die beim deutschen Autodienst läuft,
man will da also Daten austauschen und diese Applikation hier,
die speichert ihre Daten hier rein, ne,
in einer modernen Oracle-Datenbank,
das Altsystem hat irgendwas Propriesteres
So, und ich habe euch hier mal einen Ausschnitt aus dem User Manual mitgebracht,
was da steht also drin, wie man das jetzt machen soll,
ja, und dann schreibt, also steht in diesem User Manual,
you have different sources of Vehicledata, also es gibt verschiedene Quellen,
ja, der da imported into the system,
die werden also importiert in dieses System,
when you import the fire separatly,
the data is first only inserted into the data base,
after worlds, you need to synchronize to update the vehicle stockdata with the imported information.
So, das hört sich ja erstmal nochmal ganz gut an
und dann steht da Attention, ja,
also passen sie bloß auf,
Ein Import is a very sensitive action. Also ein sehr
sensible Aktion to Avoyd Conflicts. Also um zu vermeiden,
dass irgendwas schief geht, sollten sie sicherstellen,
dass niemand anders in dem System angemeldet ist.
Sonst geht es möglicherweise schief, weil der parallel die Daten bearbeitet.
Was ich euch nur deutlich machen wollte, ist,
das ist also keine komplett systemische Lösung, nicht?
Also die Leute importieren da was und man muss sicherstellen,
dass sie sich die Daten gegenseitig nicht kaputt machen.
Aber es funktioniert und mit diesem System wird gut gearbeitet.
Manchmal kriegen wir einen Anruf,
irgendwas geht nicht und man kann sicher sein,
90 Prozent der Fälle haben damit zu tun,
dass irgend so ein Import falsch gewesen ist,
weil die Leute das nicht richtig gemacht haben
Bitte. Ja, nee, ich meinte auch nicht,
dass zwei Leute gleichzeitig importieren, sondern ich meinte eher,
dass am Anschluss an den Import müssen die Daten aufbereitet werden in der Oracle-Datenbank.
Und wenn da zwischendurch jemand noch wiederum an den Daten arbeitet,
du kannst natürlich sagen, okay, die Datenbank muss Transaktionen haben und dann darf da nichts durcheinander gehen.
Also es gibt natürlich viele Mechanismen, um das zu verhindern,
dass da wirklich was schief geht. Aber also kannst dir trotzdem,
also es ist zumindest in der Applikation, wie wir damals hatten,
kannst du dir trotzdem was zerschießen, weil du dem anderen sozusagen,
der gerade mitten in einer Transaktion ist, musst du gucken,
ob du parallel dann importieren kannst oder was dann passiert,
dann geht es vielleicht gar nicht.
Du denkst, du hast importiert. Also das sind schon
komplexere Probleme. Aber natürlich hast du recht, man kann
mit Transaktionen und so weiter arbeiten, um sowas zu verhindern.
Das ist keine Frage. Gut,
es geht mir auch nicht darum zu sagen,
das ist alles ganz schrecklich, nur euch klarzumachen,
das ist lokal von Menschen dann jeweils importiert,
vielleicht sogar auch über eine Software.
Da kann man vieles tun. Aber das Entscheidende ist,
ich gehe nochmal zurück
Das Entscheidende ist, es ist in der Regel nicht zeitgenau.
Dann hätte man auch andere Methoden verwenden können,
um das zu machen, als so ein Pfeil-Ex und Import.
Aber ihr werdet in eurem Leben in vielen Firmen immer noch
als System begegnen, die gar nichts anderes können,
die man nicht an irgendeinen Messagespurs oder sowas anschließen kann.
Das wird euch begegnen. Gut,
was man noch machen kann, ist,
dass man mehrere Applikationen auf eine gemeinsame Datenbank oder ein
gemeinsames Datenbanksystem
Das ist natürlich nicht, das ist nicht,
keine Lösung, die man machen kann,
wenn man schon zwei Applikationen hat, die da laufen.
Das ist nur eine Lösung, normalerweise, die man
noch machen kann, wenn man eine neue Applikation schreibt.
Ja, dann kann man sich fragen, ob man die
jetzt auf die gleiche Datenbank aufsetzt, die da schon ist.
Ja, also die Frage ist, kann man das überhaupt, ja?
Geht das überhaupt? Und kann man mit dem Datenschema leben,
was die andere Applikation da schon für die andere Applikation da schon generiert worden ist?
Ja, versteht meine neue Anwendung diese Daten.
Ich werde euch aber auch gleich ein Beispiel zeigen,
wo wir das gemacht haben,
zumindest teilweise
Welchen Vorteil hat man, das geht so ein bisschen in die Richtung,
wo wir eben auch drüber geredet haben,
wenn zeitgleiche Updates passieren, dann hat man ein Transaktionsmanagement,
das verhindert, dass Leute gleichzeitig die Daten bearbeiten.
Das ist natürlich praktisch, wenn man auf einer Datenbank arbeitet.
Wir brauchen keine neue Software oder irgendwas. Wir haben in jeder Sprache
eigentlich Mepper, um Daten in irgendwelche Datenbanken zu kriegen.
OR-Mapper sind Object, relationale Mepper und SQL ist,
oh Gott, was ist denn das in Langform
Ist egal. Ist die Sprache, mit der man auf relationalen Datenbanken
Abfragen macht. Wird euch auch noch in Datenbanken begegnen.
SQL ist also sozusagen eine Datenbank-Abfragesprache. Query Language,
was ist das S? Structured Query Lange. Na,
seht ihr. Ihr wisst schon alles. Gut,
ein OR-Mapper ist das, was Objekte in Relation überführt.
Also, das gibt es, das gibt es genauso,
wie das Exportieren von Files.
Solche OR-Mapper für Java und für was nicht anderes.
Ich habe letztens irgendwann vor einer Weile zu euch mal
über Hybernade gesprochen. Das ist der Standard-OR-Mapper für Java.
The Stays
Gut, man hat den Vorteil, dass der Datenbestand immer konsistent und synchron
ist und dass alle dasselbe verstehen unter den einzelnen Daten.
Das ist total praktisch. Also semantische Dissonanzen sind,
wenn die eine Applikation, für die ein Kunde so und so,
ein Kundendatensatz so und so aussieht und für die andere anders,
ja, und man sollte jetzt abgleichen, das sind semantische Dissonanzen.
So, und was natürlich auch eine tolle Sache ist an
so einer Datenbank, man muss gute Datenmodellierung machen.
Ja, über die Grenzen von einer Applikation hinaus
Das hört sich so schön an. Das ist aber natürlich
auch ein Problem, weil es gab in den 90er Jahren
die Versuche, unternehmensweite Datenmodelle zu machen.
Also da haben sich die Leute in IT-Firmen hingesetzt und haben
gesagt, aber wir sind doch eine Bank.
Also muss in jeder Abteilung jedes Konto den gleichen Datensatz haben
oder so weiter und so fort. Das endete damit,
dass man riesige Datensätze hatte für die einzelnen Dinge und jede Applikation
hatte nur einen Teil da draus.
Auch nicht performant und nicht sinnvoll und auch nicht umsetzbar im Endeffekt.
Also dieser Zwang kann sich auch in was Negatives umdrehen und
das ist nämlich genau das,
was da steht
Ja, das Design eines universellen Datenbankschemas ist sehr schwierig.
Im Grunde nicht machbar. Ja, das kann man nur lokal machen.
Jede Applikation braucht vielleicht was anderes semantisch in ihren Daten,
mit der Schwierigkeit muss man umgehen. Wenn man verteilte Applikationen hat,
und das hat man heute, dann hat man das Problem,
dass man in der Datenbank,
weil es dann nur noch eine ist, Performance-Probleme kriegen kann,
da gibt es heute natürlich auch viele Ideen,
die zu verteilen und mit verschiedenen Prozessen zu bedienen.
Also ich würde mal behaupten, das Problem dass
die beiden Herren Wolf und Cope da beschreiben.
Es ist inzwischen nicht mehr so schlimm. Wobei,
ich kämpfe gerade mit einem System, das hat ein tierisches Performance-Problem.
Wir haben jetzt, wir sollen nachher 100 Clients an dem System haben,
wir haben jetzt 20 dran und das System bleibt minutenlang stehen,
die Leute können nicht weiterarbeiten.
Das ist also ganz gruselig. Also Performance-Probleme gibt es heute
immer noch und nöcher. Gut,
aber das finde ich eigentliche K.O.-Kriterium für dieses Ding hier ist,
dass Software, die ich nicht selbst herstelle,
meistens mit einer eigenen Datenbank kommt
Also und dann kann ich die wahrscheinlich überhaupt gar nicht auf
meine Datenbank aufsetzen. Also insofern, das wird häufig schwierig.
Oder mit ihrem eigenen Datenbankschema sozusagen mit der Vorstellung.
Und das passt dann nicht zu dem, was ich mache.
Daten werden ungekapselt ausgetauscht. Ja, ihr schreibt ja gerade,
objektorientierte Programme, um die Daten zu kapseln.
Ihr macht Schnittstellen für eure Klassen, Film, Platz,
keine Ahnung, kann man reservieren, kann man nicht reservieren.
Hoffe ich jedenfalls, dass ihr nicht so lauter Datensäckel nur baut mit lauter Settern und Gettern.
Und das ist natürlich hier weg. Und ich habe eine extrem hohe Kopplung,
wenn also irgendjemand auf die Idee kommt,
an dem Datenbankschema was ändern zu wollen,
dann ändert er ja hier unten und das betrifft alle.
Wahrscheinlich, potenziell. Das ist schwierig. Trotzdem haben wir
das gemacht. Wir haben also bei uns mehrere Applikationen auf
eine Datenbank aufgesetzt. Auch in diesem Kontext von diesem Autovermieter,
so ein Auto wird in der Regel für ein halbes Jahr
vermietet und dann muss es aus der Flotte herausgenommen werden.
Und dafür haben wir den Fahrzeugdisponenten, einen sogenannten Ausflotter gebaut.
Also ein Werkzeug, mit dem er für Fahrzeuge sagen kann,
okay, das ist jetzt auf dem und dem Carport,
das soll jetzt mit dem und dem Laster wegbefördert werden, da und dahin.
Also das ist ein Fett-Client und der arbeitet sozusagen auf einer Oracle-Datenbank,
wo die Fahrzeugdaten drin sind und gibt den Fahrzeugen Zustände und so weiter und so fort.
So parallel dazu gibt es einen Webclient für den Spediteur,
denn der Spediteur muss wissen, welche Autos er wo abholen soll und wohin bringen soll.
Also für den ist es wichtig,
dass er mit der Brille da drauf gucken kann,
das arbeitet auch auf derselben Datenbank und dann gibt es für die Carport-Mitarbeiter auch noch einen Webclient,
damit die allen geben können,
das Auto ist jetzt bei mir angekommen oder ist es weg oder es hat Schäden?
Ja, ihr könnt euch, ihr erinnert euch,
wir hatten am Ende noch der Kette noch diese andere Applikation,
die, mit der man die kaputten Fahrzeuge oder die ausgeflotteten Fahrzeuge verkaufen konnte.
Das beruht auch auf Informationen von diesen Carport-Mitarbeitern,
weil die dann eingeben, das Auto hat irgendwo einen Kratzer oder sowas.
Gut. Tja, was steht hier und das da?
Da steht ein wahrer Satz. Die Funktionalität wird in jeder
Anwendung dupliziert. Das ist ja nicht hübsch. Also der
eine hat hier eine Klasse in der Anwendung für Fahrzeuge
und der hat das auch
Und der hat das auch. Und da gibt es in
jedem Ding wieder irgendwelche Funktionalität, die da programmiert sind.
Das ist doch doof. Wir sind ja angetreten. F
soll für Fahrzeug stehen. Wir sind ja angetreten als Softwareentwickler
mit der Maßgabe Wiederverwendung. Wir bauen Software, die sich wiederverwenden lässt.
Teile lassen sich wiederverwenden. Ich bin ja skeptisch,
was diesen Traum angeht, denn den gibt es schon seit 30, 40 Jahren.
Und ich glaube, wir stecken immer noch in der Schwierigkeit
überhaupt etwas Verwendbares zu bauen, bevor wir uns an Wiederverwendung versuchen.
Aber nichtsdestotrotz gehen die Leute ja immer damit los.
Und hier gibt es sogar eine Alternative
Die sieht so aus. Da habe ich eben schon von gesprochen.
Man könnte nämlich eine serviceorientierte Architektur bauen. Man könnte also hier
aus dem System Services rausschälen. Ich gehe nochmal zurück,
dann zeige ich euch nochmal so, war es davor.
Alle greifen direkt auf die Datenbank. Dann bauen wir nochmal Services
ein. Eine serviceorientierte Architektur und können sogar noch weitergehen,
dass wir auf diesen grundsätzlichen Service noch andere aufsetzen,
die für die Webapplikation da sind.
Muss man mal sehen, wie die Schnitte gelingen, ob dieser Webservice,
der ganz sicherlich ja nur einen kleineren Teil der Funktionalität zur Verfügung stellt.
Der soll ja nicht so viel funktionieren
Zur Verfügung stellen, wie man hier dem Fettclient hat,
sondern es ist nur ein Teil,
ob der auf diesem Service hier aufsetzt oder auf diesen Services,
ist es unklar, ist das jetzt eine oder mehrere,
man kann das erst auch wegmachen, je nachdem,
wie man will.
Oder ob der direkt auf der Datenbank arbeitet. Ja,
das muss man sehen, wie sich das schneiden lässt.
So. Der Vorteil von solchen Serviceorientierten Architekturen ist,
dass sie die Nachteile von Shared Databases entschärfen, ja?
Denn was hatten wir? Wir können jetzt,
also wir hatten vorhin die Frage, warte mal,
ich gehe nochmal zurück, wir hatten vorhin hier eine ganze Menge Nachteile,
seht ihr hier, ja?
Diese Nachteile und um die geht es jetzt,
ob wir da Verbesserungen erzielen, da wollen wir mal gucken.
Ich glaube, ich habe das so schön animiert, nee,
habe ich nicht, da müssen wir das so machen.
Also, was haben wir erreicht? Die Daten werden
nicht mehr, das hier ist besser, ne?
Die Daten werden nicht mehr ungekapselt ausgetauscht zwischen diesen einzelnen Applikationen,
sondern die Services sind Kapseln, um die Daten.
Ja, das sind die Kapseln hier. So. Ja,
die Kopplung ist nicht mehr
so hoch
Denn wenn ich was hier am Datenbankschema ändere,
dann kann ich das hoffentlich unter dem Service verstecken.
Das ist natürlich immer so eine geäußerte Hoffnung von Software-Architekten,
die ist begrenzt. Denn warum ändere ich das Datenbankschema?
Weil ich irgendein neues Feld in irgendeine Datentabelle einführe.
Also hier mache ich irgendwie in irgendeine Tabelle, sind dann
nicht mehr nur die Felder, sondern das hier ist neu.
Da steht keine Ahnung was drin, irgendein Kennzeichen.
Ja, warum tue ich denn das in die Datenbank?
Weil ich will, dass der Mensch das oben an der Oberfläche
sehen kann. Und insofern führt so eine Änderung dazu,
dass sich die Operation hier die meinetwegen Get Fahrzeug heißt,
ändern muss, weil das Fahrzeug mehr Felder hat oder Setfahrzeug und keine Ahnung,
dass ich also hier oben auch meine geänderte Fahrzeugklasse haben werde.
Aber ihr werdet das Argument immer wieder hören, wenn ich
eine Kapsel habe, dann kann ich darunter ja was verstecken.
Das ist nur begrenzt tatsächlich. Aber ein bisschen besser ist
es. Ich könnte hier unten erstmal was ändern und es
erstmal nur nach hier zur Verfügung stellen,
also hier in die Richtung und in diese Richtung diese Veränderung noch gar nicht sichtbar machen.
Sowas kann ich tun. Also ein bisschen weniger Kopplung
habe ich
Das Problem hier habe ich nicht gelöst. Ich habe immer noch
keine Lösung dafür, dass eine Fremdsoftware vielleicht ihre eigene Datenbank hat.
Das ändert sich nicht. Wenn ich hier noch eine Applikation integrieren wollte,
die ihren eigenen Datentopf hat, dann helfen mir Services gar nicht.
So, da habe ich auch nichts dran verbessert.
Die semantischen Unterschiede habe ich in die Service-Schicht gezogen.
Also da ist es ein bisschen besser. So,
und ich brauche aber immer noch ein universales Datenschema,
denn diese Datenbank da unten hat ja immer noch nur ein Schema.
Also das ist auch nicht besser geworden.
Aber ich habe immerhin
ein paar Verbesserungen erzeugt
So, wenn ich so eine serviceorientierte Architektur habe.
Gut. Die dritte Variante nennt sich Remote Procedure Invocation und
das geht schon fast in die Richtung von dem,
was ihr eben gesehen habt mit dieser serviceorientierten Architektur.
Denn die Idee ist,
dass meine eine Applikation mit Hilfe von Stubbs und Skeletons,
das sind Sachen, die man generieren kann in Software,
übers Netz auf eine andere Applikation zugreift.
Was brauche ich dafür? Ich muss nutzbare Funktionalität in
irgendeiner Form veröffentlichen
Tja, reicht das, wenn ich an meiner Applikation sage,
das ist jetzt von außen zugreifbar?
Nein, das reicht natürlich nicht. Ich muss irgendwo etwas haben,
was das dann auch kennt und jemandem anderen zur Verfügung stellt.
Also ich brauche irgendeine Zentralstelle, die sowas möglich macht. Ihr wisst das,
im Internet gibt es natürlich auch Services,
die euch dann da hinruten, wo ihr hinwollt,
wenn ihr irgendeine Webadresse eingibt,
die ist ja nicht einfach mal so bekannt,
sondern es muss irgendeine Zentralstelle geben und sowas macht man in der Regel mit irgendwelchen Technologien,
die man da einsetzen kann,
werdet ihr alles noch kennenlernen in eurem Leben
Was können, also das ist Java hier,
Remote Method Invocation, das ist eine Bibliothek,
die im Java, die in Java drin ist,
die generiert für euch,
es gab so ein Skeletons und installiert dann in irgendeinem Prozess einen Manager und der,
bei dem meldet ihr euch an und dann kann man sich da Referenzen auf andere Applikationen in anderen Prozessräumen holen.
Corba ist, glaube ich, inzwischen schon fast nicht mehr existent,
aber doch, ich glaube, man benutzt es noch,
weil Aaron I oder AMI geht nur von Java nach Java,
wenn ihr aber verschiedene Programmiersprachen integrieren wollt,
dann müsst ihr was anderes verwenden und dafür kann man
Corba einsetzen
Da kommt man also von Java nach Sea Sharp oder CPlus Plus oder nach sonst wo.
So, kommen und nett sind Windows eigene Technologien dafür.
Und das hier ist eine Internet-Technologie. Lernt ihr alles noch kennen.
Müsst ihr jetzt nicht wissen, müsst ihr auch nicht auswendig lernen.
Ich habe das einfach nur euch hingeschrieben,
damit ihr irgendwann mal die Lücken damit füllen kennt.
So, und man muss natürlich bei seiner Programmierung,
und da geht es nämlich jetzt los, berücksichtigen,
dass es Ausfälle im Netzwerk geben kann.
Ja, das Netzwerk kann ausfallen oder die gerufene Applikation kann ausfallen.
Wir hatten heute gerade das Problem, dass die Datenbank irgendwie Schwierigkeiten hatte.
Und deswegen, wir haben die Geräte alle nicht weiterarbeiten konnten
auf unserem Terminal und die Fragen sind dann vielfältig.
Ist das Netz ausgefallen? Was ist eigentlich ausgefallen? Also
man schafft sich da eine Komplexität, die man natürlich,
wenn man Software hat, die nur in einem Prozess arbeitet oder auf meinem PC zu Hause nicht hat.
Aber die schafft man sich natürlich auch, weil man solche Dinge eben will.
Also das ist immer wieder ein charmantes Erlebnis,
wenn die Anwender sagen, aber das muss doch funktionieren hier,
ihr seid doch die Softwareentwickler und dann kann ich nur sagen,
ja, ja, ihr wollt aber auch was ganz schön kompliziertes hier.
Das, was ihr hier wollt, ist nicht einfach
Und da können so viele Fehler passieren. Da müssen wir
genau hingucken und müssen einfach in Kauf nehmen,
dass mal was ausfällt. Gut, was sind die Vorteile?
Die Vorteile von solchen Architekturen ist, dass man Funktionalität wiederverwendet.
Also ganz ähnlich wie bei der serviceorientierten Architektur,
die wir eben hatten. Die Daten sind lokal gekapselt,
jede Applikation hat ihr eigenes Format und kann dafür sorgen,
dass die Daten nicht durcheinandergebracht werden, nicht kaputt gehen.
Und das ist natürlich das, was alle Leute lieben.
Man kann Funktionen wiederverwenden
Man hat also potenziell weniger Code-Duplikate,
aber ich habe euch ja eben schon gesagt,
dass das mit der Wiederverwendung so eine Sache ist.
Also man kann nicht sicher sein, dass man die Funktion
tatsächlich so wiederverwenden kann, wie sie da ist.
Und dann müssen die Leute doch wieder was dran bauen.
Also immer vorsichtig mit der Wiederverwendung. Was man an Nachteilen bei solchen Architekturen gewinnt,
ist, dass man eine sehr enge Kopplung hat.
Ja, also wenn die eine Applikation nicht läuft,
dann kann die andere auch nicht ihre Arbeit machen,
denn die ruft das auf und will eine Antwort haben.
Wenn die andere nicht da ist,
dann hat man so so eine Sanduhr auf dem Bildschirm.
Und dann ist wieder die Frage, was kann die Software,
die ich habe? Also hat der Programmierer daran gedacht,
dass die andere Applikation weg sein kann oder dass das Netz ausfallen kann
und hat der sich überlegt, was seine Software dann tut?
Das ist nämlich, das ist nämlich was,
was alle Softwareentwickler machen, die bauen ihre Software für den Gutfall.
Die bauen die so, als würde es alles funktionieren,
was sie sich gedacht haben. Und die vergessen,
dass das ganz oft nicht so ist,
gerade wenn man etwas macht, was über Netzwerkgrenzen hinausgeht.
Also versucht euch klarzumachen, dass wenn ihr Software baut,
dass ihr dann eher auf Robustheit setzen müsst.
Ihr müsst etwas bauen, was mit Fehlern umgehen kann.
Ihr müsst natürlich das bauen, was den Gutfall erschlägt,
aber auf die anderen Fälle müsst ihr euch auch vorbereiten.
Und am besten baut ihr da nicht für lauter Lösungen,
dass das System in allen möglichen Fällen das Richtige tut,
sondern dass es dann vielleicht einfach mal gar nichts tut,
einfach robust ist.
Gerade wenn man mit Geräten zu tun hat,
dann ist es noch viel schlimmer. In dem Hafen,
wo ich da unterwegs bin, da fahren ja lauter Geräte rum,
so große Van-Carrier und Krane und was nicht alles.
Und die machen dauernd Fehler
Die gehen kaputt, die Brücken können nicht weiter arbeiten, schicken irgendwelche Signale nicht.
Das ist mit Geräten unglaublich normal, fahren zu langsam,
melden falsche Positionen, was die nicht alles machen.
Die Software muss damit robust umgehen. Also, man muss was bauen,
um mit den Ausfällen sich umzugehen. Und das andere,
was man natürlich noch hat, neben den Ausfällen,
ist, dass man auch Performance-Probleme kriegen kann natürlich.
Wenn man Sachen übers Netz macht, dann ist das
ein ungefähr ein Faktor von 25 im Vergleich zu dem,
was man in einem Rechner mit mehreren Prozessen machen kann
Ja, das muss man immer bedenken. Und was
diese Art der Konstruktion ja nahelegt, ist ein Synchrona-Aufruf.
Das heißt, ich rufe was auf von hier.
Und ich warte, der hier wartet. Und nichts passiert,
bis die Antwort kommt. Wenn ihr im Internet Applikationen benutzt,
dann wisst ihr, was ich meine, ne?
Das ist einfach so. Es dauert. Und die Frage ist,
geht das synchron oder kann man nicht auch was Asynchrones machen?
Das ist aber nicht so einfach.
Wenn dann hier die Entwickler von der Applikation B für ihre Kunden irgendwas ändern hier drin,
diese Funktionalität durch die ersetzen und das ist dann weg,
ja, dann muss das auch der Entwickler von dieser Applikation wissen,
weil der vielleicht gerade das da aufruft.
Oh, plötzlich ist es weg. Also man muss dann
als IT-Abteilung die eine Software entwickelt, auch immer an die anderen denken.
Also alle Aufrufer sind betroffen und das Problem bei so einer Konstruktion ist,
dass man in der Regel gar nicht weiß, wer einen alles aufruft.
Ja, weil man stellt ja Funktionalität zur Verfügung,
die irgendjemand benutzen kann
So, und wenn man nicht aufpasst, dann entsteht ein
kaum zu entwirrendes Knäuel von sich gegenseitig aufrufenden Applikationen.
Ja, also da hat man,
ich habe ja mit euch so über Qualität von Software gesprochen,
keine Zyklen und so, ja. Ja,
das haben wir jetzt vielleicht in den Applikationen auch im Griff,
aber dann bauen die Leute,
verbinden die Leute Softwaresysteme und das Knäuel wird dann auf der nächsten Ebene.
Da taucht es wieder auf. Also wenn ihr sowas macht,
es ist begeisternd, wenn man vorhin in einer Applikation eine andere aufrufen kann,
aber versucht, wenn ihr in die Architektenrolle geht,
immer zu schauen, muss das jetzt sein?
Ja, muss ich hier noch eine Verbindung einziehen?
Wird es dadurch nicht viel zu knäuelig und verkoppelt.
Also die Frage nach Struktur, die kommt auf jeder Ebene
wieder. So. Ein gutes Beispiel für sowas, ja,
dass Applikationen auf irgendwelche andere Funktionalität zurückgreift, sind so Standarddienste, ja.
Also wir haben damals zum Beispiel bei diesem Autovermieter ein System gebaut für die User-Anmeldung zur Autorisierung.
Ja, heute wird man irgendeinen Eldarp verwenden oder sowas,
ja, also irgendwelche Standardkomponenten, die es sogar schon gibt,
aber was haben wir damals gemacht? Oder wenn man zum Beispiel aus Programmen E-Mails verschicken will,
ja, oder Faxe oder sowas, das wollen Anwender ja auch oft,
dann wird man sicherlich nicht hier eine Faxkomponente bauen und hier noch eine,
ja, sondern man wird so einen Standarddienst, ja,
das will man nicht machen, ja,
sondern man wird so einen Fax-Service zur Verfügung stellen,
auf den die zugreifen können.
Muss man immer sehr genau gucken, ob das sich lohnt,
das selber zu bauen, weil es gibt natürlich unglaublich viele Komponenten irgendwo,
die sowas schon tun. Ich weiß zum Beispiel gar nicht,
ob es in Java ein automatisches Fax,
ob es da ein Fax-Framework gibt, keine Ahnung,
ja, was für E-Mails gibt es,
das weiß ich wohl
Ja, also es kann durchaus sein, dass man seine Standard-Komponente
gerade selber fertiggestellt hat und plötzlich hat die Programmiersprache das schon.
Oder irgendjemand hat ein tolles Open-Source-Framework gebaut, was das viel besser kann.
Ja, ich weiß nicht, ob ihr schon an dem Not-Invented-Hear-Syndrom leidet.
Ihr werdet das treffen in jeder Firma, die Leute wollen
alles selber machen. Wir brauchen was zum Faxen,
wir brauchen was zum E-Mail, wir brauchen was für irgendwas.
Ich baue das mal eben. Ist total schön.
Also macht auch total viel Spaß, so ein ganzes Zeug
zu bauen mal eben
Nur nachher in der Wartung, da wird das irgendwie anstrengend.
Weil das muss man dann ja immer weiter pflegen.
Neue Faxgeräte anschließen, neue Drucker, war es nicht alles.
Viel, viel besser ist es, bevor man sagt,
ich baue das mal eben, sich umzuschauen,
ob es sowas schon gibt.
Das ist natürlich total langweilig für jemanden, der gerne Software baut,
aber insgesamt für ein System ist das besser.
Ich sage damit nicht, dass ihr alle SAP-Komponenten einführen sollt
überall, das meine ich damit nicht.
Aber kleine lokale Standardlösungen. Nächste Woche bringe ich euch übrigens
einen Kollegen mit, der euch was über SAP erzählen werdet.
Ich bin auch selbst schon sehr gespannt da drauf.
Der arbeitet in einem SAP-Projekt, was er uns dazu
sagen kann
Aber hier bewegen wir uns jetzt noch in der Welt Integration von Systemen.
Und was ich euch mit diesem Beispiel nur deutlich machen will,
ist, dass es häufig in IT-Landschaften sinnvoll ist,
solche Standardkomponenten über solche Remote-Procedure-Calls dann anzuschließen.
Also wenn sich der Anwender dieser oder der bei dieser Applikation anmeldet,
dann macht die das nicht selbst,
sondern sie wendet sich an einen Standarddienst,
der die ganzen User-Daten hat und führt die Anmeldung da durch.
Und der macht das hier genauso. So,
wir haben das natürlich am Anfang, dass die erste Version von diesem Ding,
ja, die war natürlich in einer Version soll das heißen.
Die war in einem, in einem von diesen Software-Systemen drin. Ja,
die erste Version war hier in dem Uust-Car-System und wir hatten
das natürlich total toll gebaut, also so Komponenten und so.
Da war das dann ganz, ganz einfach,
das da rauszuholen und als Standardkomponente daneben zu stellen.
Ja, also das wird euch natürlich in eurem Leben auch immer wieder begegnen.
Ihr baut etwas und nach einer Weile baut ihr das nächste und merkt,
wow, da in dem ersten ist was drin,
das brauche ich jetzt auch. Schon deswegen solltet ihr also zusehen,
dass ihr eure Software in solche Scheiben und Schichten und so über das,
was wir immer geredet haben, Denn dann ist das ganz,
ganz einfach, diese Schicht hier oder diesen Schnitt hier als eigene Applikation wohin zu stellen.
Und es war übrigens auch so, wir hatten es so
gemacht und man konnte es tatsächlich ganz einfach da rausholen.
Stolz, genau. Gut. Das ist jetzt nochmal,
um zu sehen, okay, wie läuft das insgesamt?
Also man kann das parallel machen. Die eine Applikation verwendet
hier einen Standarddienst, die andere auch. Und gleichzeitig kann
man auch noch über einen Pfeil im- und Exportdaten austauschen.
Also man kann diese verschiedenen Modelle von Integration,
von Softwaresystemen kann man kombinieren, logischerweise.
Also es geht nicht nur das eine oder das andere
So. Gut. Und das vierte, was, glaube ich,
die Zukunft ist, womit die Leute arbeiten werden,
ist das sogenannte Messaging. Was bedeutet das? Das bedeutet,
man hat einen Message-Bus, das ist das Ding hier.
Und an dem hängen ganz viele Applikationen dran. Also es
gibt sozusagen einen einheitlichen Kanal, über den die Nachrichten austauschen.
So, das muss man natürlich erst mal hinkriegen.
Also man muss die Applikation da anschließen und man muss
entsprechende Technologie haben,
Java Messaging System ist sowas
IBM hat ein Webs 4 MQ, Message Q zur Verfügung gestellt.
Von Microsoft gibt es auch so was. MQ Series ist
was, was mehr so an Großrechner dran geht.
Und im Grunde Webservices, wenn sie asynchron sind,
sind auch so was. Und ihr seht schon,
der Anteil der Vorteile ist viel größer als der Nachteile.
Ich zeige euch hier nochmal,
also wenn ein System sozusagen von einem anderen was will,
dann schickt der eine Nachricht,
also eine Message in irgendeinen Kanal und da hinten kommt sie
wieder raus und das andere System hört sich das an oder tut was damit.
Gucken wir uns gleich noch im Detail an
Was hat man davon? Man hat lose Kopplung. Lose Kopplung,
weil der eine den anderen nicht kennt, nicht wirklich kennt.
Der kennt seinen Kanal, in den er seine Nachricht absetzt,
aber er muss nicht den anderen als entfernte Referenz kennen und den direkt aufrufen.
Also ähnlich wie beim Pfeiltransfer hat man hier eine lose Kopplung,
denn das Message-System ist ein eigenes System.
Ich kann also meine Nachrichten da reintun,
das Message-System kann die auch aufheben, kann die verwalten,
kann die dann zustellen.
Es ist so ein bisschen wie so ein Briefträger
Also meine Systeme sind lose gekoppelt. Das ist auch,
also was da noch hinzukommt, das ist nämlich asynchron das ganze Ding.
Ja, also ich schicke eine Nachricht los,
genauso wie wenn ihr einen Brief verschickt.
Das ist was anderes, als wenn ihr mit dem Telefon anruft.
Ich schicke also meine Nachricht los und ich weiß,
irgendwann bekomme ich eine Antwort. Wann weiß ich nicht.
Ja, das ist mit der SMS genauso.
Wir müssen ja gar nicht in das altertümliche Briefe schreiben,
uns zurückziehen oder so. Ja, SMS ist eine
asynchrone Kommunikation und ein Telefonanruf ist synchron. Ja,
wenn ihr anruft und der andere ist nicht da und kann
euch deswegen nicht sagen,
dass die Vorlesung heute hier ist und nicht da,
dann geht ihr zum falschen Ort
Wenn ihr in eine SMS geschickt hättet, hättet ihr vielleicht
eine Nachricht bekommen und dann wäre es anders gelaufen.
Okay. So, man hat eine höhere Ausfallsicherheit,
weil wenn eine Applikation nun gerade mal aus ist,
dann ist das Message-System in der Regel so gebaut,
dass es wartet, bis der andere sich wieder anmeldet.
Und dann wird er mit Nachrichten überhäuft. Ja,
das ist genauso wie bei euch, wenn ihr euer Handy ausschaltet,
wenn die SMS ja irgendwo aufgehoben und wenn ihr es anmacht,
dann kommen sie alle an.
Ja, genauso ist das hier auch.
Man hat weniger Performance-Probleme, weil man einfach sehr entkoppelt ist.
Jede Applikation macht so vor sich hin.
Man muss natürlich ein paar schnelle Rechner haben,
die dieses Messaging da machen
An sich sind die anderen Sachen ja auch Zeit verzögert.
Ja, also wenn ich einen entfernten Aufruf mache,
dann dauert das etwas länger, bis ich eine Antwort kriege.
Darüber haben wir ja eben gesprochen, als wenn ich direkt in einem Prozessraum bin.
Diese Art der Kommunikation ist per se asynchron. Ja,
also wenn ich meine Applikation entwickle und so eine Nachricht losschicke,
dann muss ich wissen, dass nicht sofort eine Antwort kommt.
Ja, ich muss das wissen und muss damit umgehen
und muss dem Anwender eben gegebenenfalls an der Oberfläche anzeigen,
dass es jetzt eine Weile dauert.
Also es ist sozusagen in der Programmierung inhärent.
Ich kann nicht so tun, als würde ich
die Nachricht sofort kriegen
Ja. So, und man kann mit solchen Nachrichten alles Mögliche anstellen.
Man kann einfach nur Daten verschicken. Man kann aber auch
eine andere Applikation mit einer Nachricht beauftragen, etwas zu tun.
Zum Beispiel was auszudrucken oder mir irgendwelche Berechnungen zu machen.
Also man ist mit diesen Nachrichten sehr flexibel. So,
was hat man für Nachteile? Asynchrone Kommunikation ist ganz schwer
zu beherrschen. Das ist eine andere Art der Programmierung.
Ich kann euch nur empfehlen,
wenn in eurem Studium es irgendwo die Gelegenheit gibt,
mal asynchron zu programmieren
Dann mach das. Geh dahin, lernt,
was das bedeutet, dass der eine doch nicht antwortet und dass
der andere dann oder schneller oder langsamer oder was auch immer.
Damit macht man sich so viele Probleme im Leben,
wenn man das nicht einmal verstanden hat.
Also wenn ihr irgendwie könnt bei den Verteilten, ich weiß nicht genau,
wo das in eurem Studium angesiedelt ist, aber geht da bloß hin.
Und wenn es ein Praktikum oder ein Projekt oder sonst was ist,
guckt euch das an. Das ist wichtig. So,
was natürlich immer noch so ist, ist,
dass es gibt kein universelles Datenmodell, das heißt,
der eine schickt eine Nachricht und meint,
der Kunde ist das und das und der andere erwartet was
ganz anderes oder versteht das nicht genau so,
wie der eine das schickt
Ja, in dem Hafenprojekt, wo ich jetzt gerade bin,
da haben wir an der einen Schnittstelle, glaube ich, 120 Nachrichten,
die da hin und her gehen und es ist unglaublich,
wie man missverstehen kann, was irgendeine Nachricht bedeuten sollte,
ja, weil diese Nachrichten bestehen immer aus Daten, ja,
und die haben einen Namen und das eine System denkt,
also die Entwickler in dem einen System denken,
dass diese Nachricht das und das bedeutet und die Entwickler in dem anderen System,
die die verschicken, denken,
die Nachricht bedeutet das und das und dann kommt nachher völliger Morgs raus,
im Gesamtkontext, ja, aber das ist sowieso ganz normal,
wenn ihr mal irgendwann in eurem Leben in so eine Rolle kommt,
dass ihr Architekt seid für ein größeres System,
dann müsst ihr euch klarmachen,
die Schnittstellen zwischen Systemen seien die nun so oder über entfernte Aufrufe oder sowas.
Das ist das aller, allerschwierigste. Und die Integration von mehreren Systemen
dauert kostenmäßig in der Regel nochmal genau so viel wie die Entwicklung.
Also wenn jemand von euch eine Schätzung haben will, ja,
sie bauen jetzt hier diese Software und dann integrieren sie das halt in unser System,
was kostet denn das?
Daneben berechnet die Entwicklungskosten und haut nochmal dasselbe obendrauf.
Die Integration kostet in der Regel so viel.
Was auch immer man da macht,
Messaging oder was
Gut, wie funktioniert sowas? So ein Messaging-System oder
man sagt auch oft, Mom dazu, Message-oriented middleware.
Ja, das funktioniert. Ich mache heute einfach mal
keine Pause, merke ich gerade.
Ist es okay? Oder müsst ihr eine Pause haben?
Wer jetzt nicht schreit, der muss durchhalten.
Okay, also das ist auf dem einen Computer hier.
Das ist der eine Computer, ja, da ist ein anderer Computer.
Hier ist eine Applikation, die, die eine Nachricht verschickt.
Was macht die, die erzeugt eine Nachricht?
Ja, also das ist eine Message mit Daten
In der Applikation sind die Daten vorhanden. Sie erzeugt
eine Nachricht und schickt die dann an einen anderen Prozess.
Diesen Grünen nehme ich hier, der auf dem Rechner läuft,
der das Messaging-System ist. Also das ist das Mom.
Und dann hat er seine Arbeit schon getan.
Deswegen ist eines der Grundskonzepte Sand and Forget. Ich schicke
eine Nachricht los und dann kümmere ich mich nicht mehr darum.
Außer ich will eine Antwort haben, dann muss ich mich
irgendwann mal darum kümmern. Aber in dem Moment ist es
für diese Applikation hier erledigt und die kann weiterarbeiten.
Also die kann dem Anwender auf dem Bildschirm weiter bedienen für
das,
was er will
So. Zum Beispiel, wenn man jetzt, wenn man sich vorstellt,
dass ihr vor irgendeiner Internetapplikation sitzt und ihr wollt,
keine Ahnung, irgendwas, drückt auf irgendeinen Knopf,
um irgendwelche Informationen zu bekommen, dann kann es zum Beispiel sein,
dass das Ding euch erstmal nur Teile der Daten anzeigt,
die es hat und dann unten irgendwie einen Bereich erst nach einer Weide nachlädt oder sowas.
Ja, also und irgendwie macht euch das Ding ja klar,
dass das eine Weile dauert. Ja,
also die heutigen Systeme im Internet sind ja schon so,
dass sie dann eben Teile nachladen,
an den Anfängen des Internets war es dann so,
du drücktest auf irgendwann, und dann saßt du davor,
ja, also so.
Ich weiß noch, als ich den Rechner von meinen Eltern
ans Internet angeschlossen habe und Was gab es denn da?
Da gab es DSL, genau. Das war sozusagen ganz neu.
Und dann habe ich meinen Eltern gleich den Rechner mit DSL angeschlossen.
Und irgendwann rief mich meine Mutter ein und sagte, Carola,
das funktioniert hier nicht. Und dann sage ich ja,
was funktioniert? Ja, ich drücke da drauf und dann kommt nichts.
So, ne, im Internet. Und dann habe ich mir das angeguckt,
wo sie, also ich habe dann gesagt, welche Webseite ist denn das,
haben wir das bei mir gemacht, habe da draufgedrückt,
habe gewartet zwei, drei Sekunden und dann kam was.
Und für mich sozusagen als jemand, der schon vor DSL
das Internet benutzt hat unglaublich langsame Antwortzeiten erlebt hatte,
war das ganz normal, dass man mal drei Sekunden wartet.
Meine Mutter hatte nur ihre DSL-Erfahrung und da war es normalerweise so,
wenn sie irgendwo draufglückte, dann kam gleich was.
Das ist natürlich gut. Also ihr wisst, dass es manchmal was dauert. Das heißt,
er schickt die Nachricht los,
gib mir mal die Bestelldaten zu diesem, ja,
ihr habt was bei Amazon bestellt und Amazon über irgendeinen Drittanbieter,
bei Amazon und Amazon,
muss dann den Zustand der Bestellung in dem System von dem anderen Anbieter erfragen.
Und wir stellen uns mal vor, die werden über so ein Message-System verbunden.
Dann würde also die Amazon-Webseite hier so eine Nachricht losschicken Und dieser Teil,
dieser Prozess hier auf dem Rechner von Amazon,
würde dann diese Nachricht entgegennehmen und würde sie zu dem Rechner schicken,
wo auch so ein Teil des Moms läuft und weiß,
dass da diese andere Applikation ist.
Und dieser andere Teil würde dann gucken,
ist der da, ist der da, arbeitet der,
ist der am Leben und würde ihm dann die Nachricht zustellen.
Und zwar immer, also dieser hier, der diese Nachricht verschickt,
der würde sie bei sich erst dann löschen,
wenn er von der anderen Seite die Nachricht bekommt,
ist angekommen,
habe ich gespeichert
Und hier wird die Nachricht auch erst gelöscht,
wenn der von oben sagt, ist da.
Also speichern und weiterleiten. Das ist das Prinzip. Und
was erreicht man dann? Oder wozu ist das alles gut?
Man hat lose Kopplung. Also die Kanäle sind separiert von
den Anwendungen. Die Anwendungen machen das nicht selbst.
Sodass man irgendwelche Abhängigkeiten von Orten und sowas,
die ist man einfach los, wo läuft die Software,
wo ist irgendwas?
Die Kanäle sind asynchron, dadurch ist man
nicht mehr zeitlich abhängig
So, und die Daten sind in Messages drin, also die werden,
da muss man sich nicht noch über das Datenformat einigen,
dass es sozusagen im Vorhinein klar.
So funktioniert das im Prinzip. Ich habe euch nochmal ein Beispiel mitgebracht,
wir stellen uns also vor, Programm Q,
P und Q sind hier und hier sind A und B,
ja, und dann geht's also los,
wir verschicken mal was, P, oh,
wieso ist er da nicht drin?
Meine hübsche Animation ist kaputt
Das ist ja traurig. Naja. Das kann nur der Wechsel
von, weiß ich nicht, na gut, egal.
Also eigentlich sollten die hier verschwinden, da reinwandern und dann da zugestellt werden.
Ja, so nacheinander. Ja. Das ist jetzt
ein einfaches Beispiel. Hier gibt es nur eine Cue durch
die mehrere Applikationen, was an andere schicken.
Das kann man ganz unterschiedlich aufsetzen. Ja,
also ich hatte euch ja, das allererste Bild,
hier, da gab es einen Message-Bus.
Also man könnte sich vorstellen,
jeder sitzt vor so einem Trichter und schüttet da seine Nachrichten
rein und hört an einem Trichter und kriegt sie da raus
Das macht man unterschiedlich, je nachdem, was man will.
Es gibt in der Regel immer in solchen Systemen einen Aero-Channel,
in denen können alle was reinpusten,
aber es gibt dann häufig auch direkte Kanäle zu anderen Applikationen,
wo man weiß, das geht nur dahin.
Und in der Regel einen hin und einen her,
sondern man verwendet die auch nicht in beide Richtungen gleichzeitig.
So, das haben wir jetzt hier alles durchgeklickt,
das muss ich mal wieder reparieren hier.
So, und das ist nochmal das Beispiel,
was wir vorhin hatten. Ihr erinnert euch,
wir haben unsere Anwendung für Gebrauchtwagen und wir haben unsere Anwendung,
um die Wagen aus der Flotte rauszukriegen.
Wir hatten gelernt,
es ist schön für Standardkomponenten
Sowas Standard. So eine, für die Autorisierung zum Beispiel
ist Faxen oder das E-Mail über Remote Procedure Call zu arbeiten.
Und wir hatten vorhin in dem Bild noch hier das hier
Pfeiltransfer war oben zwischen den Applikationen.
Und was man natürlich dann machen kann,
ist diesen Pfeiltransfer zum Beispiel durch so ein Messaging ersetzen.
Also wenn ein Auto ausgeflottet worden ist,
dann wird hier jetzt nicht mehr Pfeil exportiert,
sondern es wird eine Nachricht geschickt an diese Komponente.
Und die kann das Fahrzeug dann in ihre Datenbank aufnehmen
So kann man das lösen. Und das funktioniert natürlich,
selbst wenn hier keiner arbeitet, wenn der es runtergefahren ist,
wenn der Server abgeraucht ist, egal, dass Mom,
was hier zwischen sitzt, hebt das alles auf.
Und transportiert es dann weiter. Gut. Ich habe euch
schon gesagt, Asynchronität ist schwierig. Das ist auch eine
andere Art der Programmierung, weil das ist eine sogenannte eventgetriebene Programmierung.
Ich schicke eine Nachricht raus und ich weiß nicht,
wann dann etwas passiert.
Das ist anders, als ihr im Moment programmiert.
Ihr habt irgendwo ein Main-Programm,
in dem
ihr was startet
Und dann wisst ihr, was passiert. Das einzige,
wo ihr Event getrieben handelt, wo wisst ihr,
wo das ist bei euch in euren Applikationen, die ihr schon baut?
Wo ihr auf Ereignisse wartet und dann irgendwas tut?
An der Gui, genau. Da passiert euch das.
Ihr wisst nie, wann der Anwender, wo was klickt.
Deswegen ist Gui-Programmierung auch total schwierig. Wir haben bei uns,
also ihr lernt ja schon Unit-Tests und sowas,
ganz viel Spaß machen, Oberflächentests und noch mehr Spaß.
Da hinten schüttelt jemand den Kopf, noch mehr Spaß macht es,
wenn bei uns in der Firma jemand eine Software fertig gebaut
hat oder meint das.
Und dann lobt er
einen Kaputtspieltest aus
Das bedeutet, man bekommt irgendeine ganz besonders tolle Schokolade,
wenn man möglichst viele Fehler findet,
wenn man das System einfach mal so irgendwie klickt.
Das wird nämlich garantiert nachher passieren, dass irgendjemand mal einfach so irgendwie klickt.
Das macht Spaß, das macht Spaß, oder?
Sebastian, also, ja. Das macht dann doch Spaß
. Also, Kaputtspieltests sind echt klasse,
aber dazu muss man natürlich auch die Zeit haben.
Gut, ich wollte euch nur deutlich machen, was ist eventgetriebenes Programmieren.
Das ist also, dass man auf irgendwelche Ereignisse reagiert.
Aber sobald ihr in euer Gui unter dem Knopf seid und das programmiert,
was dann passiert, seid ihr nicht mehr eventgetrieben.
Und jetzt kommen auf einmal irgendwo anders Ereignisse her.
Nämlich irgendwo aus dieser Message-Bass, ja
Ihr seid sozusagen dann, ja,
ihr müsst irgendeinen Prozess bei euch in eurem System haben,
der da ständig dran horcht.
Und wenn da was kommt, etwas tut. Aber was
? Ja, wenn der Anwender gerade was anderes tut.
Also das ist nicht einfach. Das ist eine komplizierte Art der Programmierung.
Ja, ihr müsst irgendwelche Eventhändler haben, die dann was tun.
Also ihr müsst euer System eigentlich in Einzelteile aufteilen,
die synchron arbeiten können auf dem gleichen System.
Und ihr müsst anfangen über Prozessgrenzen zu debacken und das ist schwierig.
Und was kann man tun,
um dieses Problem nicht zu groß werden zu lassen
Die Antwort mit Tee, man kann schön viele Tests schreiben,
damit die Sachen in den einzelnen Prozessen wenigstens richtig funktionieren,
damit man das wenigstens weiß.
Gut. Es gibt spannende Sachen, zum Beispiel kann man
ein Mom so bauen, dass es eine Zustellgarantie gibt.
Ich habe euch ja eben gesagt, der eine tut die Nachricht
da rein und das Messaging-System sagt, habe ich, speichere ich.
Ja, dann kann die Applikation weiterarbeiten. Dann hat das Message-System
auf der einen Seite in meinem Rechner die Nachricht gespeichert,
schickt sie woanders hin zum anderen Ende und löscht sie erst,
wenn das andere Ende gesagt hat,
okay,
habe ich gespeichert
Über diese Methode kann man eine Zustellgarantie herstellen.
Und man kann auch sowas machen, dass es eine Antwort
geben muss, die nur sagt, Nachricht ist angekommen.
Man kann das so bauen, dass man immer sicher ist,
dass die Nachricht ankommt. Es gibt aber in solchen Systemen
in der Regel keine Garantie über die Reihenfolge der Nachrichten.
Das heißt, ich muss an dem Ende, wo ich sitze,
damit zurechtkommen, dass die Nachrichten in unterschiedlichen Reihenfolgen kommen.
Weil in der Regel habe ich in so einem messageorientierten System
ja nicht nur mich und den anderen,
sondern ich habe noch fünf weitere andere,
die auch Nachrichten schicken.
Und alle schicken sich Nachrichten kreuz und quer
und niemand kann sich über die Nachrichten irgendwas
Irgendwas mit Sicherheit sagen. Was aber,
was man deswegen tun muss, ja,
und wenn ihr dieses Buch mal,
wenn ihr irgendwann mal mit solchen Systemen zu tun hat,
solltet ihr das Buch von Hope und Wolf erst mal lesen,
weil da drin wird das erklärt, man muss dafür sorgen,
dass man in der Lage ist, die Nachrichten zu sequenzialisieren,
wieder nachträglich.
Ja, und dazu müssen die einen Zeitstempel haben und sie
verschickt worden sind oder irgendeine ID, irgendwas,
woran man die wieder in die richtige Reihenfolge kriegt.
Das haben sie in dem Mom auf dem Terminal,
wo ich arbeite, dummerweise vergessen.
Jetzt müssen die Systeme immer raten, was es bedeutet,
wie die Nachrichten da kommen.
Das macht
ganz viel Spaß
Ganz viel Spaß. Oder man fängt dann an,
Nachrichten doch nicht mehr durch verschiedene Kanäle zu schicken,
sondern dann doch wieder alle durch einen,
weil wenn die sich überholen, dann ja, ganz klasse.
Gut. Wenn es für Programmierer schon so schwierig ist,
asynchron zu denken, dann ist das für Anwender noch viel schwieriger.
Anwender gehen nicht davon aus, dass da irgendwas Asynchrones dahinter steckt.
Ihr müsst also der Anwendung beibringen, dass sie entsprechend reagiert,
dass sie dem Anwender irgendwelche netten Nachrichten schickt oder so Balken macht,
wie es weiterläuft oder was auch immer.
Also das Feedback für den Anwender wird nochmal
um Längen größer
Ja. Und dann gibt es noch den Punkt Performance.
Das ist mir auch sehr wichtig. In dem Hafenprojekt,
wo ich da mit so einem Momm zu tun habe,
da gibt es, es gibt ja,
das ist auch so ein Ding,
Entwickler denken immer an, wenn die Software dann läuft.
Wenn ihr mal so ein Konzept über die Entwicklung eines neuen Software-Systems schreibt,
dann ist eine Frage, die ihr immer stellen solltet,
wie kommen denn die Daten aus der alten Applikation in die neue?
Die Datenübernahme. Wie funktioniert das? Es ist schon klar
, dass das nur einmal passieren muss
Hoffentlich, weil in der Regel natürlich nicht.
Man baut die erste neue Version von dem System,
die hat dann Fehler, die soll erweitert werden.
Muss man die Daten immer noch mal übernehmen? Ja,
also die Datenmigration von der einen Version in die andere ist nicht einfach.
Und gerade beim Initialisieren von so einem System,
was über so ein Momm passiert, ja,
also das erste Mal starten. Da ist ein Einsystem,
das hat alle Containerdaten und jetzt ist da ein neues System.
Und das soll jetzt ein Teil der Arbeit machen.
Und das funktioniert auch ganz toll in der Vorstellung,
wenn diese beiden Systeme die ganzen Daten haben.
Aber wie kriegt das neue System die Daten das erste Mal?
Ja, was haben die Entwickler gemacht?
Die haben eine Nachricht geschrieben,
die heißt Complete Download
Die kann man also schicken anders als System. Und dann
gibt das Altsystem ein Wuff. 15.000 Containerdaten als Nachrichten.
Super. Das Altsystem arbeitet die ganze Zeit und betreibt die Anlage.
Und jetzt kommt jemand und sagt, gib mir doch mal 15.000 Datensätze.
Dann steht die Anlage. Weil das ist genug zu tun.
Fünf Minuten braucht das Altsystem mindestens, um das zu machen.
Und das ist noch wenig. Kann auch sein,
dass es abstürzt, weil es nicht genug Speicher hat,
um diese ganzen Nachrichten zu erzeugen.
Also da können gruselige Sachen passieren. Deswegen die Initialisierung von
Daten außerhalb solcher Morms machen
Irgendwie anders. Pfeiltransfer ist mir egal,
aber nicht durch das Ding dadurch. Denkt immer dran,
wenn ihr Software baut, das eine ist,
die Software zu bauen für den Gutfall,
da haben wir eben schon drüber geredet, ja,
denkt auch an die schlechten Fälle,
macht euer Ding stabil und das andere ist, wie geht der Anfang?
Wie geht es los? Wie kommt das Ding ins Leben?
Weil was macht ihr? Ihr baut euch irgendwelche Testdaten und baut
eure Software immer weiter auf und es wird immer mehr und
eure Testdaten werden immer mehr. Ja, und dann,
dann sind diese ganzen Daten, die der Kunde vorher benutzt hat,
in irgendwelchen Excel-Sheets oder sonst wo und dann sagt der Kunde,
ja, wieso,
das sind meine Daten,
die müssen doch jetzt in deine Software
Oh. Und dann ist die Frage,
ob ihr dann nochmal fünf Personentage nachfordern könnt oder ob ihr
das dann auf eigene Rechnung machen müsst, was dann ärgerlich ist.
Also, Initialisierung, immer Bedenken und nicht, nicht,
nicht, nicht, nein, nein, nein,
nicht über das Morm machen, wenn es geht.
Gut, und dann ist natürlich immer noch die Frage,
was für eine Plattform habe ich da überhaupt,
was für ein Mom ist da drauf?
Können alle Applikationen damit reden? Ja,
und es gibt natürlich einen Standard in Java, JMS,
Java Messaging Service oder System, weiß nicht,
System wahrscheinlich,
das ist Plattform unabhängig
Das ist erstmal schick, aber im Endeffekt wird man schnell merken,
dass es bestimmte Dinge gibt, die sind nicht im Standard
drin und die will man dann trotzdem nutzen.
Und dann macht man sich doch plattformabhängig. Weil im Hafen haben wir ja den Fall,
vielleicht habt ihr schon mal über die Elbe geguckt und diese ganzen Van-Carrier gesehen,
diese großen blauen Spinnenviecher,
die da mit den Containern rumfahren auf dem Terminal.
Davon gibt es 100 Stück auf dem Terminal.
Und was man am Anfang gemacht hat, ist,
dass man für jeden VC einen eigenen Channel zu der Software gemacht hat.
Unglaublich aufwendig, die alle zu verwalten, wenn irgendwas umzieht,
das wieder gerade zu biegen, völlig irre.
In dem Mom, was wir da benutzen,
gibt es aber eine Idee von hierarchischen
Channels, ja, oder Topics, so wie auch
immer man sagt. Das heißt, dass die VCs,
die werden Carrie ihre Nachrichten alle in einen Kanal werfen
können und der kriegt die am Ende alle raus,
ja, und wenn es sich um einen spezifischen handelt,
dann wandert das so weiter runter.
Aber es gibt generelle Nachrichten, die kann man an den
Gesamtkanal schicken. Das gibt es aber nicht im Standard,
sondern das gibt es nur in dieser Software-Lösung.
Wir brauchen das halt, ja. Schon ist es vorbei
mit der Unabhängigkeit vom Hersteller, also vom Standard,
dass man nur noch vom Standard abhängig ist.
Schon ist es vorbei. Und das passiert in der Regel
natürlich auch in Projekten. Man hat am Anfang das heere Ziel,
dass man irgendwelche Standards hat und schwuppdiwupp ist mal dann doch abhängig von der Datenbank,
die man hat, von dem Datenbank-Mepper, von den Momen,
von was auch immer.
Gut. Sagen wir noch zwei, drei Worte zu Synchron und asynchron.
Nur damit ihr das mal gesehen habt, das Linke ist ein synchroner Aufruf.
Ich habe eine Webseite, an der gebe ich eine neue,
einen neuen Auftrag ein. Das geht zu irgendeinem Order-Manager,
der Order-Manager ruft einen, was weiß ich,
auf und er ruft noch irgendwas auf und dann kommt die Antwort zurück,
tiff tiff tiff.
Und diese ganze Zeit hier steht mein System, Idle,
nichts passiert,
ich kann nichts machen
Das hier ist parallel. Ich kann meine Nachricht absetzen und
dann kann ich einfach weiterarbeiten. Die Kontrolle kommt zurück,
dann kann ich die nächste Nachricht absetzen und die da hinten
arbeiten einfach weiter. Ich habe also eine schnellere Verarbeitung,
aber ich habe ein viel schwierigeres Debugging, Debugging,
weil wenn ich hier die bugge, dann kann ich ja einfach mitwandern.
Sowas macht ihr ja auch, wenn ihr eure Systeme debuggt.
Obwohl, das müsst ihr ja gar nicht,
weil ihr schreibt ja alle so viele Tests,
dann müsst ihr das gar nicht machen.
Das ist das Schöne am Testen. Man muss fast nie mehr
debuggen. Genau. Aber wenn man in die Mehrprozesswelt kommt,
in das Asynchrone verarbeiten, Und dann fängt das an.
Man ruft hier was auf, hat einen Breakpoint gesetzt und
dann wird das hier verschickt. Und dann kommt dieser Prozess
zurück. Ich muss also auch in dem Prozess irgendwo im Source-Code
einen Breakpoint gesetzt haben, damit ich da auch anhalte.
Und das wird kompliziert. So. Und darüber haben wir
eben schon geredet, das Ergebnis muss sich irgendwie verarbeiten.
Ich muss also, irgendwo kommt ja hier die Antwort dann zurück.
Ja, der schickt sie los. Wahrscheinlich nach hier.
Und der schickt das dann nach hier weiter.
Und dann kommt hier die blaue Antwort an
Tja, da muss ich irgendwie mit umgehen. Hier in
dieser, in diesem Teil hier. Das muss irgendwie wissen,
wie es das kriegt und was es dann macht.
Und die Ausführungsreihenfolge ist unbestimmt, ne? Es kann sein,
dass die Antwort von dem Gelben schneller zurück ist,
warum auch immer, als die von dem Blauen, ja?
Und damit muss ich leben können, als derjenige,
der das da oben programmiert. Ja. Da stehen so
ein paar drauf. Es gibt auf Betriebs-Themaebene, was,
es gibt auf, es gibt Applikationsserver,
die so ein Messaging-System haben
Es gibt Sweets dafür, mit denen man sowas machen kann.
Die lernt ihr bitte alle unbedingt auswendig für die Klausur, das ist klar.
Gut. Alle machen Ähnliches, aber alle haben unterschiedliche Namen.
Wir sind ja noch eine junge Disziplin in der Softwareentwicklung
und es ist quasi egal, wo ihr hingeht.
Ob ihr Programmiersprachen vergleicht, ob ihr Methoden vergleicht,
ob ihr solche Sachen vergleicht. Es heißt immer heiß,
dasselbe irgendwo anders. Und man muss irgendwie lernen,
was wie heißt, habe ich hier nicht eine Tabelle?
Nee, habe ich nicht, wie schade.
Ich dachte, ich hätte eine Tabelle
Ich hatte mal eine Tabelle, die tue ich euch dann vielleicht noch rein,
wo man mal so sieht, wie das alles so heißt.
Also der eine sagt Q dazu,
zu der Verbindung zwischen zwei Applikationen, die andere,
das andere System sei es, sagt dazu topic.
Der eine sagt ein Message, der andere sagt Envelope,
irgendwas. Jeder sagt irgendwas anderes. Ja,
aber es ist immer wieder dasselbe Prinzip. Ja,
das ist mir nur wichtig, dass ihr das wisst.
Die Dinger machen alle ganz was Ähnliches.
Sie haben nur unterschiedliche Namen. So, das ist also
das schöne Buch von Hope und Wurf
Irgendwann lest ihr das mal, es gibt also,
das ist ein Buch, was aufgebaut ist mit nach Entwurfsmustern.
Ich habe euch ja mal ein bisschen was erzählt über Entwurfsmuster,
der hat also verschiedene Muster beschrieben, wie funktioniert so ein Kanal,
so ein Channel zwischen Systemen, hat da verschiedene Muster für beschrieben,
point-to-point-Channel und einen dauerhaften und der Invalid-Message-Channel,
also wo die Error-Nachrichten hinkommen und, und,
und.
Wie schließe ich eine Applikation da eigentlich an,
auf der einen Seite und auf der anderen Seite ist es dasselbe,
wie baue ich Nachrichten auf,
da gibt es hier also auch eine ganze Reihe von
verschiedenen Arten,
wie ich
Nachrichten aufschreiben will
Und das hier auch ganz wichtig, wie monitore ich überhaupt so ein System.
Ja, das ist auch so eine Frage,
die ihr nie vergessen solltet, wenn ihr Software baut.
Man baut ja dann die Software für so ein paar Anwender.
Und das ist erstmal das Wichtigste, denn man soll das ja fachlich unterstützen,
was die da machen wollen und so weiter.
Ja, aber wie gebe ich irgendjemandem noch ein anderes Blick,
einen anderen Blick auf dieses System?
Ja, ob das System richtig funktioniert,
wie kann das jemand in so einem großen Komplomarat beurteilen?
Kann der das in irgendeiner Form monitoren und bei so einem
Mom ist das unglaublich wichtig. Man muss sehen,
fließen die Nachrichten, wer schickt wie viele, ja,
damit ich merke, dass das System zu belastet ist,
damit ich irgendwelche Nachrichten woanders umleiten soll.
Und sowas macht im Grunde so eine Infrastrukturabteilung in so einer Firma
und die muss natürlich auch Werkzeuge haben, um sowas anzugucken.
In dem Kontext, wo ich arbeite, wisst ihr,
was da passiert? Die bauen sich solche Werkzeuge natürlich dann selbst.
Ist doch klar, ne? Weil das macht ja
so viel Spaß. Gut. Ich erzähle euch jetzt noch
ein bisschen was über Container-Terminals und ein Beispiel daraus,
damit ihr das noch so ein bisschen dieses Message-Ding auch so
ein bisschen an dem Beispiel in die Hand kriegt
Und das braucht eigentlich so ein Container-Terminal, um Container zu bewegen?
Schiffe, logisch. Kleine Schiffe,
das ist ein kleines Schiff da, das ist ein sogenannter Fieder,
der hat sehr viel weniger Boxen und hat auch noch seine eigenen Kräne da obendrauf,
um die Container auf in Häfen entladen zu können,
die kein Container-Terminal haben.
Also das sind so die kleinen Schiffe, die in die Ostsee fahren.
Man braucht die Bahn, hier ist so ein Zug,
sieht man nicht so doll, was sind die Bahnkräne davor,
man braucht eine Bahn, um Sachen im Land zu befördern und natürlich LKWs auch.
Das sind also die vier Transport, Ketten,
die auf so einem Container-Terminal zusammenlaufen und mit denen ein Container-Terminal arbeiten muss.
Und das Entscheidende ist, dass die Schiffe vom Hof kommen.
Das ist das Entscheidende. Und die Bahn.
Die LKWs sind am uninteressantesten. Deswegen gibt es dann auch
immer wieder Staus, was ärgert dann uns? Alle,
die wir durch den Elbtunnel fahren, aber das ist nicht so interessant.
Das ist auch nicht so beherrschbar. Gut, das ist das eine.
Dann braucht man noch mehr, denn man braucht Containerbrücken.
Ja, das ist das, um die Container darunter zu holen.
Wenn ihr mal die Chance habt,
auf so ein Container-Terminal zu kommen, dann fragt mal,
ob ihr mal auf eine Brücke dürft
Das ist klasse, das ist 50 Meter hoch ungefähr da oben.
Da kann man richtig gut mit seinem Höhenangst bekämpfen.
Und der Arbeitsplatz hier von dem Brückenfahrer, der ist am allertollsten,
weil der fährt nämlich mit seinem Ding immer vor und zurück
und hat so eine Glasscheibe unten und pickt damit,
also nimmt damit die Container auf.
Das ist ein schicker Arbeitsplatz. Und die ganzen Wege hier oben auf so einer Brücke,
die sind alle unten mit so einem Gittermetall, wo man durchgucken kann nach unten.
Das ist spannend. Oh, jetzt geht mein Geschmiere da nicht weg. Na gut,
das sind VCs, wenn Carrier, von denen ich eben gesprochen habe,
die sieht man immer rumfahren, wenn man wenn man guckt,
so, jetzt wird es gleich nicht besser.
Das sind die Bahnkräne, glaube ich, jedenfalls.
Achso, nee, achso, das sind die,
hier geht es um diese Viecher, diese kleinen Viecher hier.
Das sind sogenannte AGVs, Automated Guided Vehicles.
Das ist eine tolle Sache. Das sind kleine Autos,
ja, die keinen Fahrer haben und die nur von Software gesteuert über das Terminal fahren,
sich unter irgendeine Brücke stellen und dann macht die Brücke dann einen Container drauf,
dann fahren sie irgendwo anders hin,
dann nimmt ein Kran das weg und stellt es ins Lager und das funktioniert.
Das funktioniert richtig gut. Da ist man richtig waffne,
da sieht man, wo auf so einem Ding so
ein Container drauf sitzt
Und die blinken sogar, das ist das Allerhübscheste,
die blinken, obwohl das ja niemanden interessiert,
weil da fahren nur die Teile rum.
Naja, dann gibt es Lager, das ist so ein
typisches Lager von so einem Container-Terminal, das ist ein sogenanntes VC-Lager.
Was ihr da seht, sind die ganzen Container,
die aufeinander gestapelt sind und zwischen den Containern ist Platz.
Warum ist da Platz? Warum ist da wohl Platz dazwischen?
Damit die da so rüberfahren können, ne? Die Viecher hier
, hier sieht man das, da ist einer drin.
Seht ihr das? Die fahren da rein und holen
die Container raus. Deswegen kann man auch
nur drei Stockwerke hochstapeln
Ja, höher können die nicht. Dann, ne?
Drei hoch. Müsst ihr mal bei, bei Google ist
das total schick zu sehen, so ein Lager.
Und die Alternative zu so einem Lager ist das hier,
was ihr hier seht, das ist ein Automatiklager.
Kriege ich denn jetzt meinen Geschreibselmada weg irgendwie?
Das ist doch blöd. Kann ich das wegmachen? Naja
, nee, kann ich nicht. Also, das ist
ein Automatiklager hier. Und was hier hier dieses Ding,
diese Dinger, die ihr hier seht, das sind Kräne.
Die fahren über diese großen Reihen von Container hinweg und nehmen
die Container von oben weg.
Und deswegen kann man die viel enger stapeln und braucht keine
Van Carrier mehr
Das ist aber auch nur ein Problem, da wo man wenig Platz hat.
Und im Hamburger Hafen hat man logischerweise wenig Platz.
Es gibt also Container-Terminals in Amerika, da interessiert das keinen.
Die würden auch niemals sowas dahin bauen. Da stellen
die Container irgendwo hin, weil man hat genug Platz.
Die werden alle flach hingestellt. Ja, es ist also
eine Frage des Platzes, dass man sowas macht.
Und wenn ihr dann, ich weiß nicht,
ob ihr das sehen könnt, aber die können sechs hochstapeln.
Also man hat einerseits Platz in die Breite gewonnen,
weil man kann die so eng zusammenstellen und außerdem können diese Dinger sechs hoch.
Und die sind automatisch, da sitzen auch keine Leute drin.
Das ist also, die brauchen also keine Pause zwischendurch und sowas.
Also Hafenarbeiter haben alle vier Stunden, die sogenannte halbe,
da fahren sie also alle nach vorne und haben eine
halbe Stunde Pause
Da muss man immer bestimmte bezahlt, eine spezielle bezahlte Modelle machen,
damit die dann auch weiterarbeiten in der halben.
Und das Schiff dann schnell vom Hof kommt. Also solche
Automatikdinger sind sehr beliebt. Gut, was passiert also?
Hier am Wasser werden die Container mit der Brücke runtergenommen.
Dann werden sie hier Hunden auf diese Viecher, auf diese Wagen gesetzt,
werden in so ein Automatiklager getan, der lagert die da ein.
Und irgendwann sollen die vielleicht auf die Bahn oder auf den LKW,
dann werden die da wieder rausgeholt,
auf den LKW gestellt und der fährt damit weg.
Oder auf so einen Zwischentransport, der das an die Bahn transportiert.
So funktioniert das. Also grundsätzlich,
es ist eigentlich nicht schwierig, nur rein und raus,
aber die machen sich das natürlich nicht einfach
Denn diese LKWs muss man richtig abwickeln. Man muss sich
mit Zoll beschäftigen. Es gibt Gefahr, gut,
Container, die dürfen da nur an bestimmten Orten stehen.
Und es gibt kleine zusammengeklappte Container, die offen sind,
auf die man dann alles Mögliche verladen kann,
Schiffe und irgendwelche Teile von irgendwelchen Windrädern und weiß nicht was alles.
Also dann wird es kompliziert. Und es gibt Kühl,
Container, ja, das ist auch was ganz Schickes.
Es gibt Firmen, die holen ihre Kühlcontainer einfach nicht ab
auf dem Terminal. Ja, die bestellen Ware,
also irgendwie so ganz viel, keine Ahnung,
Dips fürs Blockhaus oder sowas,
Und man will eigentlich den Platz haben, damit man andere
Container dahinstellen kann. Aber die Kunden holen sie nicht ab,
weil die haben gemerkt, das Lagergeld ist günstiger,
als sich ein eigenes Kühlhaus anzuschaffen.
Also lässt man den Container auf dem Turnal so lange stehen,
bis man das Zeug halt dann mal braucht.
Und dann hat man vielleicht auch ganz viele Kühlcontainer.
Das ist total praktisch. Ist natürlich aber für so
einen Container-Turn irgendwie ganz schön doof.
Gut. Und in Hamburg gibt es die da.
Hier ist die Kühlbrandbrücke, über die ihr vielleicht manchmal fahrt.
Ja, das ist die Kühlbrandbrücke. Und da hinten,
da kommt der elf Tunnel raus und hier geht die war
sieben lang.
Und hier ist der alte Elbtunnel
Es wird niemals passieren,
dass jemand einen Container-Terminal hier hinten weiter an der Elbe bauen wird,
weil die großen Containerschiffe nicht über den alten App-Tunnel wegfahren können.
Der ist zu weit oben im Wasser sozusagen. Das heißt,
alle Container-Terminals sind hier, hier ist noch Eurogate,
das sieht man auch, wenn man da vorbeifährt.
So, mehr gibt es in Hamburg nicht. Ah,
nee, da mache ich mal, Masken mache ich mal jetzt weg,
weil wir sind schon fast durch mit unserer Zeit, ne?
Ich zahle euch euch mal ein Bild, wie das grundsätzlich funktioniert.
Man hat also Lagersysteme, man hat Container-Basissysteme und man hat
Planungssysteme, um das alles hinzukriegen.
Und die müssen alle miteinander kommunizieren. Und dafür setzt man
dann so eine Mom ein, ich mache mal hier
ganz viel weiter
Ich habe noch so ein schönes, genau. So,
wir haben also hier unser Lagersystem. Hier haben wir unser Containersystem,
hier haben wir unser Planungssystem und hier ist der Monitor,
um das alles zu beobachten. Und die sind alle über
solche Kanäle miteinander verbunden. Wir haben wieder so eine,
so ein Knäuel im Endeffekt, aber nun gut.
Und was passiert? Das Lagersystem erzeugt also eine Nachricht.
Der Inhalt wird irgendwie angereichert, sodass das,
sodass man zum Beispiel einen Zeitstempel da dran hat oder eine Reigenfolgennummer,
dann wird das in irgendein Format gepackt,
was das andere System am Ende dann lesen kann,
dann wird es in eine Nachricht eingepackt
Durch den Kanal geschickt. Am Ende wird die Nachricht geprüft.
Und es wird dann technisch sozusagen die Nachricht weitergeleitet an das andere System.
Das packt die Nachricht aus und verarbeitet die dann.
Ja, also so funktioniert das in alle Richtungen.
Und ihr seht schon hier das, was ich eben angedeutet habe,
man verwendet in der Regel so einen Kanal nur für eine Richtung.
Also nicht hin und her, sondern es gibt jeweils für
jede Richtung einen eigenen Kanal.
Gut. Was habt ihr heute gelernt? Ich hoffe,
ihr habt die vier Ansätze der Integration so ein bisschen
wahrgenommen.
Die sind wichtig
Wichtig, wichtig, Klausur wichtig irgendwie. Es gibt Pfeiltransfer,
es gibt Remote-Procedure invocation, es gibt Shared Data-Basis,
Messaging und alle haben Vor- und Nachteile.
Ganz besonders wichtig. Gut, und die stellen irgendwelche Herausforderungen
natürlich für Architekten und Programmierer dar. Und wenn ihr mal in eurem Leben,
und das werdet ihr mit Sicherheit auf solche Systeme stoßt,
gerade wenn es Messaging ist,
dann kauft euch das Buch von Hope und Wolf und lest das danach.
Oder erinnert euch, dass ich was darüber erzählt habe.
Gut. Timeout, ich hoffe,
ihr konntet was mitnehmen. Nächstes Mal ist es wieder am
anderen Ort