Ja. So überschaubar kann die Welt sein. Lustige drei Schichtenarchitektur,
wie so drei Schichten. Naja, was braucht man denn?
Man braucht also eine Datenbank, die braucht man auf jeden Fall.
Sonst muss man jeden Tag, wie heißt das,
täglich größtes Murmeltier, wieder alles von vorne anfangen.
Nein, also Persistenz, das braucht man auf jeden Fall.
Dann gibt es Leute, die gesagt haben, naja,
auch und auch noch eine eigene Schicht für die Funktionalität des Systems.
Okay, das ist also der sogenannte Middle-Tier. Und den
haben wir jetzt erstmal ausgestaltet hier als fachlichen Service. So,
das sind die, die, die Einhalten in unseren Entwürfen,
also nach dieser Wamm-Modellarchitektur, die einem sagen,
unabhängig von der Interaktion wird Funktionalität hier implementiert.
Und zwar als Service,
und wir haben jetzt schon so ein paar Eigenschaften von diesen Services angeschaut,
wir haben uns auch schon angeschaut, so ein, zwei,
drei kleine Beispiele und das werde ich heute nochmal weiter verdichten.
Also wie man sich so eine Servicearchitektur vorstellen kann. Wir haben dann auch schon darüber gesprochen,
so wie das so ist mit Services, werden über eine Service-Registry,
werden die bekannt gemacht und genutzt, also von anderen Services.
Das ist alles erstmal, soll so entworfen werden,
dass es völlig unabhängig ist von einer, von einer,
von der Art der Benutzung, die insbesondere auch eine interaktive Benutzung sein kann.
So, wir haben letztes Mal dann auch schon gesagt,
naja, so klassisch ist es so gewesen,
nicht klassisch, aber so eine Art von Architektur,
kleinen Serverarchitektur, so in der Ausprägung Rich Client,
wird viel Funktionalität,
also auch auf dem Client
Weil der Klient halt ja auch eine Rechenleistung mit sich bringt.
Und haben dann mal so diskutiert, dass das also auch unterschiedlich ausgeprägt sein kann. So,
bis hin zu den,
also das Gegenteil von Rich Client, die Fint Clients,
wo keine Funktionalität, also auf dem Klienten verfügbar ist,
sondern nur sowas wie ein Browser basiertes Frontend,
also was in der klassischen Variante dazu führt, dass also sämtliche Funktionalität,
also hier auf der Ebene eines Services bereitgestellt werden muss.
So, wenn man aber jetzt unterschiedliche Frontends, Arbeitsplatztypen,
den Zusammenhang haben wir ja auch schon,
kurz gestriffen
Verschiedene Frontends bedienen will,
dann braucht man also so diese Schicht in der Regel dazwischen,
den Interaktionsservice, der also wahlweise, je nachdem,
mit welcher Art von Klienten man es zu tun hat,
also auf dem Client oder auf dem Server implementiert werden kann,
der auch unterschiedlich,
also der ist jetzt hier so dick ausgeprägt wie die anderen,
so von der Masse der Implementation,
also wenn man ein Rich Client hat,
wird dieser Interaktionsservice eher dünn ausgeprägt sein,
so dünn im Sinne von, da wird nicht viel zu implementieren sein,
wenn man also hier noch viel Interaktionsverhalten, also dazu implementieren muss,
weil man da vorne am Klienten keine Rechenleistung zur Verfügung haben oder da nichts ausrollen will,
dann wird man also hier im Interaktionsservice noch viel Aufbereitung der Daten vornehmen müssen,
die vom fachlichen Service bereitgestellt werden.
Das ist erstmal so die prinzipielle Struktur, so einer Service-Architektur. Und was wäre jetzt,
wenn ich jetzt hier über Ritch client spreche,
eine andere Variante, wenn ich über Ritch klein spreche,
dann können Sie sich ja darunter sofort so etwas vorstellen wie das,
was wir so im Laufe der letzten Wochen ja auch besprochen haben,
dass also im Wesentlichen auf dem Klienten Werkzeuge und Materialien bereitlegen.
Also Werkzeuge, die interaktiv bedient werden und die auch dann
Also deren Funktionalität auch auf dem Klienten direkt bereitgestellt wird.
Welchen Teil eines Werkzeugs? Wir haben ja kurz darüber gesprochen,
welchen Teil eines Werkzeugs, welche Teile gibt es eigentlich?
Könnten Sie sich denn vorstellen, wird dann,
ist prinzipiell übertragbar, so vom Klienten auf ein Server?
Erstmal, welche Teile eines Werkzeugs können Sie unterscheiden?
Von der Implementation her, ja bitte.
Auf jeden Fall Funktionsuntertakt zur Frage
Sehr gut. Und was gibt es da noch?
So in der letzten Ausbaustufe. Wir haben noch so
die Präsentationskomponente. Da hatten wir noch über der Interaktionskompense,
über der Interaktionskomponente im Sinne von noch näher an der Oberfläche.
Okay, also die drei. Präsentation, Interaktion und Funktion
. So und jetzt kommen Sie auf die Idee,
das nimmt zu viel Rechenleistung auf dem Klienten.
Was bietet sich Ihrer Ansicht nach an,
es auf einen Server
zu übertragen
Funktionskomponente auf jeden Fall. Ja, vielleicht auch.
Die Detailsschutzkomponente von was? Klianten noch für sich Präsentationen.
Ja. Wie werden denn Funktions- und Interaktionskomponente miteinander verbunden?
Wie sind die miteinander verbunden, ja
Ja. Ja. Also ich stelle das, die lose Kopplung,
stelle ich mal so da. Also die Interaktionskomponente kennt,
die Funktionskomponente und ihrer vollen Schnittstelle, die hier,
also das ist die, das ist genau das,
was die gesagten, das Beobachtungsmuster.
Beobachtermuster, also das stellt dieses da so.
Und bei der, von PK zu IAK ist das genauso.
Das kann ich mir so in,
wenn das jetzt mal hier die, die kleinen Servergrenze,
also hier ist jetzt der fachliche Service.
Wie sieht es eigentlich jetzt, ich bin etwas,
gehe nochmal einen Schritt zurück. Das hier ist client,
das ist Server. Wie ist denn die Verbindung eigentlich?
Die Funktionskorpionatik kennt den Funktionsservice. Würde ich auch erstmal sagen
. Würde ich echt auch sagen. So,
und jetzt komme ich noch, jetzt habe ich sie in
eine Falle gelockt
Habe ich sie in eine Falle gelockt? Nein, das
ist nicht bösartig gemeint. Jetzt haben wir den Schnitt zwischen
Client und Server klassisch, legen wir den also so.
Hier auf dem Klienten schön das Werkzeug und es kann reagieren,
mouse over und Knöpfe werden gehighighlighted und es ist alles wunderbar.
Und es ist deswegen so wunderbar, wenn ich das mal untechnisch ausdrücken darf,
weil das findet ja alles in einem Prozessraum statt.
Der hier, der liegt also so in einem anderen Prozessraum.
Jetzt hatten Sie gerade schon gesagt, naja, gut,
dann lege ich halt die Funktionskomponente.
Irgendwann stellen Sie fest, dass hier wird ein Very Ritsch Client.
Weil das ist also das Werkzeug implementiert und implementiert,
Funktionalität und das wird so, das wird immer langsamer und sagt, hey,
wir haben noch da im Keller stehen, also steht genügend Rechenleistung rum.
Also lass uns mal was so in den Keller verlagern, sprich zum Server.
Sehr gut. Also jetzt ist die schnelle Lösung,
also die einem so einfällt, wenn man diese Architektur,
also Vorstellungen aufrechterhalten will. Die schnelle Lösung ist dann halt,
na gut, wir gehen also hier vom,
machen wir das jetzt nicht mehr hier, sondern hier.
Welches Problem kaufen wir uns damit offensichtlich ein?
Das hört man in keinen Varianten. Ist das clever?
Nee, ne? Das ist irgendwie, warum ist das
nicht clever
Das gereicht wird. Ja. Warum soll er den denn nicht kennen?
Ich meine, hey, you can't have it all, oder?
Also irgendein, was soll denn das? Welches Problem? Also ich meine,
das hier, also ich rede jetzt immer von Client und Server,
weil wenn ich das so sage, hört sich das so an,
als gäbe es einen Klienten und einen Server,
ist das im Alltag häufig der Fall?
Das hier sind eigentlich, sagen wir mal,
typischerweise mindestens zwei
Manchmal sogar drei. So. Und für so richtig
große Anwendungen kann das sogar im zweistelligen Bereich sein.
Also was man sich so an der Uni halt so vorstellen kann,
nicht wie viele Leute parallel, so.
Und das bedeutet, ich kriege, also ich komme mit meiner,
mit meiner klassischen Architekturvorstellung komme ich hier eigentlich nicht wirklich weiter.
Weil die hier, die weiß überhaupt nichts von,
so gibt es da mehrere oder gibt es,
gibt es nur einen oder so, die sagt,
also ich bin eine Funktionskomponente, ich habe einen bestimmten Zustand,
ich kann bestimmte Sachen, kann ich,
also bin ich für verantwortlich, nämlich die Funktionalität eines Werkzeugs.
Aber bitte lasst mich in Ruhe mit Mehrbenutzerbetrieb. Das ist
nicht meine Welt. So meine Welt ist der Arbeitsplatz.
Insofern ist also so die einfache Idee,
und ich kann das jetzt so, können das jetzt so sagen,
also wir haben das auch eine Zeit lang, wann war denn das so?
Mitte der 90er Jahre, haben wir das sogar versucht,
so von unserer ursprünglichen Vorstellung, nämlich hier ist also der Rich Client,
oder wie der früher hieß, Fat Client,
denen da so Schnitte uns zu überlegen,
so wie das so eigentlich liegen kann.
So und jetzt ist aber,
und das da hat sich eben als nicht besonders tragfähig erwiesen,
weil man diese Funktionskomponente einfach zu sehr anreichert.
Man muss sie überhaupt, man muss sie einreichen und wie sich herausstellt,
also zu sehr anreichern, um Dinge, die sie eigentlich nichts angehen.
Deswegen ist dieser Schnitt auch, sagen wir mal, unpraktikabel. Das,
was sich als Praktikabel herausgestellt hat, ist, Okay,
es gibt also einen Ritsch-Klein und er verdient diesen Namen.
Und jetzt seht mal zu, dass ihr den vernünftig implementiert kriegt.
Und dann hat man hier, also wenn man den Schnitt
hierhin wieder legt, dann hat man eine klassische kleinen Serverarchitektur.
Und das hier ist eine einfache Benutzt-Beziehung. Und hier kann man
all sein Wissen über, wie werden klassische Ritsch-Client-Systeme gebaut.
Das kann man hier anwenden. Das hat sich jetzt noch,
also dann im Weiteren hat es eine Entwicklung gegeben,
die sich als so erst so im Laufe der 90er Jahre,
also herauskristallisiert hat, das sind die sogenannten ULCs.
Das ULC, das steht für Ultralightweight Client. Und was die tun,
ist, die legen den Schnitt hierhin und sagen,
naja, was die tun,
ist,
also wofür steht das englische Kunstwort Vidget
Ja. Ja, sie haben möglicherweise den Witz von mir
in SE2 oder so, haben sie mal gehört.
Also ein Widget ist ein Fenster-Dingsbums. Das ist
Gadget ist eben ein Dingsbums. Und das Fenster-Dingsbums,
da wird also, der Schnitt wird genau hier gelegt,
Fenster, das ist nämlich wirklich,
also dünner kann man eine Oberfläche nicht mehr gestalten
Das ist der Fensteranteil, der läuft auf dem Klienten.
Und der Dingsbumsanteil, der läuft auf dem Server.
Und dann hat man, und um den Rest,
also wie jetzt die Verteilung, also die Benachrichtigung zwischen,
also dem Fensteranteil und dem Rest ist,
darum kümmert sich genau dieses Framework hier.
Die ULC-Maschinerie.
Das ist clever
Das ist clever. Also wenn man Ritch-Client haben will und man will aber
auf wenig Rechenleistung auf dem Klienten implementieren oder hat nur wenig Rechenleistung zur Verfügung,
dann wird man sich, also für so eine ULC-Herangehensweise.
Gibt es auch mittlerweile so die entsprechenden Produkte zu,
wird man sich für diese Architektur entscheiden.
Was also insofern charmant ist, Weil man kann also so,
hier kann man in diesem ganzen Kontext, kann man so implementieren,
als würde man sich in einem Prozessraum befinden.
Und so, dass man hier auf so,
dass man noch weiß, aha, ich sollte also die fachlichen Services,
die sollten nichts davon wissen, dass sie jemand benutzt.
Das ist insofern eine gute Idee,
als dass man die fachlichen Services in einem anderen Kontext dann möglicherweise,
also den Schnitt, jetzt mache ich hier nicht nochmal alles weg,
aber möglicherweise will man ja auch irgendwann mal den Schnitt zwischen klein und Server hier hinlegen.
Und man legt also jetzt, wenn das unsere Service-Schicht ist,
also dann wirklich nur noch die Datenbank auf den Server
Das sind so diese Variationen über einem bekannten Thema. Also das, was man sich,
denke ich, aus dieser Diskussion jetzt so,
was man da so mitnehmen kann, ist,
also die Schnitte hier sind aus architektonischen Gründen oder Abhängigkeitsgründen,
sind die nicht beliebig zu legen,
sondern also der natürliche Schnitt, in Anführungsstrichen,
ist hier.
Und wenn das aus irgendwelchen Gründen nicht geht,
also insbesondere weil hier nicht genügend Rechenleistung auf dem Klienten vorhanden ist,
dann ist eine Entwurfsalternative,
wenn man diese Architekturvorstellung hier aufrechterhalten möchte,
dann ist es
den Schnitt hier hinzulegen
Und das betrifft jetzt also erst mal so diesen Diskussionsstrang. Ich möchte mich mit einer Oberflächentechnologie wie Swing,
so als einem der prominenteren Java-Vertreter, möchte ich meine Oberflächen implementieren. Das ist eine andere Geschichte,
wenn man so etwas modernere, oberflächentechnische oder modernere Oberflächentechnologie,
womit ich nicht sagen will,
dass das andere irgendwie jetzt keine Rolle mehr spielt,
aber wenn man so eine Ajax-Implementation wie GWT,
Google Webtool Kid zur Verfügung hat, dann kann man auch anfangen,
also sich so hier in diesem Bereich auch andere Gedanken zu machen,
weil die gesamte Verteilungsfrage ja dann von einem anderen zugrunde liegenden Framework,
das dafür sorgt, dass die dass es im Browser läuft,
diese Verteilungsfragen für einen übernimmt.
Dazu werden wir Anfang Juli, aber hier auch noch einen
Gastvortrag haben, wie das dann also mit so Ajax-Implementationen,
wie da die Verteilungsfragen beantwortet werden.
Ajax, sagt jemand, Ajax, was?
Was denn? Asynchronehard WTP-Rest. Ahax. Ahas. Ja
, asynchrones JavaScript. Ja, genau, mit XML.
Das sind drei drei Fragen mit denen,
also ich sage jetzt nicht, Mann, also sagen wir mal,
mit denen ich mich nicht beschäftigen möchte, Asynchronicität, JavaScript und XML.
Das ist also, das ist das Pest-Colorer und noch irgendwas Drittes.
Damit will man sich nicht beschäftigen und man hat es total,
ich, Mann, hat es total gerne,
wenn es also einen Compiler gibt, der einen,
also schön alles in Java implementieren lässt und der also dann so die,
also Synchronicität, so die Übersetzung in JavaScript, weil es also im Browser läuft und also die XML-basierte Kommunikation abnimmt.
Das ist doch nett
So, danke, Google. GWT ist ein Beispiel,
also für so eine Ajax-Implementation,
aber das gucken wir uns dann eben nochmal genauer an.
So, wenn wir in unserer,
wenn wir uns so in unserer Welt der Rich Clients bewegen,
ist halt so und so, sagen wir mal,
so eine klassische Web-Oberfläche als zweites Frontend im Auge haben.
Das ist also der Nutzen oder auch die Schnittstelle von solchen
fachlichen Services
Ah, die kann dann also zum Beispiel, mit dem
uns ja dann mittlerweile auch schon hingänglich bekannten Proxy-Muster implementiert werden.
So, hier entwickle ich halt so,
als wäre der Desktop der Nabel der Welt und über die Integration des Proxy-Patterns in Werkzeuge,
kann ich dann ja auch den Zugang über rechne Grenzen hinaus,
so benutzt Richtung, brauche ich keine Rückkopplung, kann ich das zu einem entfernten Prozessraum hinbekommen.
Nächste Frage. Wenn Sie hier das Proxy-Pattern integrieren sollten,
Also der Service laufe jetzt mal auf tatsächlich, also auf einem Server.
Sie sind auf einem Klienten und jetzt sage ich Ihnen,
okay, Leute, wo wollen wir denn jetzt mal das Proxy integrieren?
Wo würden Sie es denn integrieren? Also,
dass die Funktionsqualität Proxy nennt. Ja, da brauchst du
dich halt um die jetzt... Ja.
Ja. Ja. Ich habe gesagt, yuhu
So, das heißt also, dieser Pfeil hier,
der kriegt jetzt also, der kriegt jetzt also die Proxy-Verbindung.
Das heißt, also in der einfachsten Implementation,
das ist in einer wirklich sehr einfachen Implementation,
würde man den fachlichen Services wie den fachlichen Service eben nicht direkt ansprechen,
sondern die Funktionskomponente wird, also dann Verteilungstransparent wird die,
die den Service kennen.
Ja. Wieso reite ich jetzt darauf rum,
dass das die einfachste Implementation wäre
Ok, die Antwort darauf ist, man kann sich das auch komplizierter vorstellen.
Jetzt sage ich mal so, als Wambler,
was habe ich Ihnen denn über Transparenz und Verteilungstransparenz bereits erzählt?
Also wir kommen jetzt aus dieser Welt,
alles lief schön auf einem Rechner.
Jetzt Schnitt und der Techniker in Ihnen sagt Proxy.
Und ich als Techniker sage Ihnen,
klappt,
können wir machen
Und jetzt schlägt der Wammler in mir durch und sagt, nee.
Mit Blick auf so die Diskussion über Arbeitsplatz und Arbeitsumgebung
halte ich das für zu kurz geworfen.
Wieso? Was sind die Bedeutungen von Transparenz?
Welche verschiedenen Bedeutungen kann das haben
Ja. Lässt sich nicht kalt und verdeckt. Ja, jetzt erläutern Sie.
Ich halte, wenn ich sehe, was genau in Detailen kommt.
Ja. Und verdeckt heiß, wenn mich nicht interessiert, wie das umgeht. Tja,
so, das ist dann in so,
also dann ist das jetzt mit dieser,
also wenn ich das jetzt mal hier, danke,
wenn ich das jetzt mal hier drauf anwende,
also es könnte eine Entwurfsentscheidung sein, dass ich dem Benutzer Verberge,
dass er auf einen fachlichen Service auf einer entfernten Maschine zugreift.
Oder, das ist der erste Teil der Möglichkeit,
ich mache genau das transparent. Da ist also so ein
fachlicher Service, sagen wir sowas wie eine Registratur.
Die ist halt nicht hier, sondern die ist da.
Wenn ich jetzt das Proxy-Muster einfach nehme, die Registratur,
gut, die ist ja klar,
dass die jetzt mal auf einen Server geht,
weil es gibt ja dann verschiedene Klienten,
die auf diesen Service zugreifen wollen
Was bedeutet das denn dann für das Thema Benutzungsmodell, Handlungssicherheit?
Wenn jetzt diese Registratur, aus welchen Gründen auch immer,
ist jetzt gerade mal nicht da. Als Wammler würde ich doch sagen,
ich möchte meinen Benutzer transparent machen, dass der Service,
der Gegenstand, auf den er zugreifen möchte, der ist gerade nicht verfügbar.
Und dann weiß der Benutzer, ich kann jetzt irgendwas machen,
aber auf die Registratur greife ich besser erst wieder zu,
wenn also die Ikone für Registratur, die brav auf meinem Arbeitsplatz ist,
die nicht mehr ausgegraut ist, sondern wieder voll drückbar.
Also braucht man das nicht nur vorstellen.
Ich haue auf diese Ikone drauf, was passiert?
Ein Auflisterwerkzeug für die Registratur geht auf.
So, das technisch können Sie sich das alles vorstellen.
Brut, bis runter geht es dann das Werkzeug,
zeigt das Inhaltsverzeichnis und so weiter.
Jetzt drückt ihr da drauf, jetzt komme ich,
jetzt verteile ich das und ihre einfache Proxy-Implementation würde jetzt sagen,
was würde sie denn sagen?
Service not available,
drei later
Please excuse, any in convenience and ask your local administrator oder irgendwas,
so von der Seite von Meldungen, die man nicht haben will,
also die ich nicht haben will, weil ich nicht weiß,
was ist denn nun eigentlich kaputt?
Was kann ich denn jetzt nun eigentlich noch machen? Das ist ja so,
und das ist eben das Problem,
also jetzt an der Stelle, oder das ist das,
was ich mindestens mal problematisieren möchte, so eine einfache Proxy-Verbindung hier,
stellt zwar dann, also eine technische Verteilungstransparenz her,
lässt den Benutzer aber fachlich etwas im Regen stehen,
in dem Fall,
wo etwas nicht da ist
Und als Wambler würde ich jetzt sagen, aber genau den Fall möchte ich verdeutlichen,
transparent machen, dass dieses Gerät auf einem anderen,
also dieser Service auf einem anderen Gerät liegt als das,
was hier lokal zur Verfügung steht. Also werden wir uns,
und das ist eigentlich so die Rede, oder das Argument,
das ich jetzt so im Weiteren noch so ein bisschen ausweizen werde,
also technisch gesehen können wir hier mit,
also wirklich einfachen Mitteln, können wir solche Verbindungen herstellen.
Die Kunst wird dann darin bestehen,
das Benutzungsmodell so transparent zu machen, dass Ausfälle,
weil das Ausfälle deutlich werden und für den Benutzer insbesondere so deutlich wird,
was geht jetzt noch und was,
also versuche ich besser jetzt erst gar nicht, bis alles wieder geht.
Ich habe jetzt angefangen, also vorhin mal gesagt,
also typischerweise ist es ja so, so zwei oder drei Klienten und ein Server.
Das ist aber auch Quatsch. Also ich greife jetzt,
wenn sie sich mal die Folien von der letzten Woche nochmal so vergegenwärtigen,
was da so an Diensten,
also zur Verfügung gestellt wird in einer typischen Service-Architektur,
Ist auch nicht, also dass der Server ein Rechner ist.
Das ist auch eine Illusion. Da liegen ja jede Menge
. Also jede Menge ist jetzt vielleicht auch übertrieben,
aber das ist eine potenziell größere Zahl als eins, die der Services bereitstellt.
Und dann wird es eben umso wichtiger zu verdeutlichen,
welche Services stehen möglicherweise nicht zur Verfügung und das auch am Arbeitsplatz,
da wo das Zeug eben verwendet werden soll, um das zu verdeutlichen.
Also, aber um nochmal so, ich habe das so,
ich frage das gerne so in Also in solchen Runden,
wo würden Sie denn das Proxy jetzt eigentlich also anschließen?
Das FK ist, also Funktionskomponent ist genau die richtige Antwort,
weil IAK scheidet ziemlich aus, weil, naja,
was hat also die Interaktion schon damit zu tun,
dass also etwas so woanders stattfindet?
Also da will ich eigentlich davon überhaupt nichts wissen.
Ich meine, das, was hier in diesem Schaubild,
was fehlt eigentlich hier in diesem Schaubild?
Welche dem Werkzeugmaterialansatz namensgebende Entwurfsmetapher fehlt hier eigentlich
Das, ja? Material. Ja, die Automaten,
ach ja, stimmt überhaupt, die Automaten.
Aber Automaten schenke ich ihnen,
weil Automaten ist also das hier mit einer ganz kleinen Interaktionskomponente.
Das sind Automaten. Also nicht, dass ich die kleinreden möchte,
die Automaten, aber die Materialien, klar, die fehlen.
Das würde man ja jetzt noch...
Jetzt muss ich doch
den Strich wegmachen
So, der fachliche Service, der greift auch auf Materialien zu.
So, und die Funktionskomponente, die auch. So,
wobei, da ist jetzt ja Obacht geboten,
das so zu malen, dass hier sind statische benutzt Beziehungen.
Also das hat nichts mit der Dynamik zu tun.
Das heißt also, die Materialien müssen dann,
also im Laufenden System greift also die Funktionskomponente nicht
Vorbei am fachlichen Service auf das Material zu,
sondern geliefert vom fachlichen Service, kennt die Funktionskomponente auch die Materialien.
So, jetzt könnte man noch die Frage stellen,
wenn sich so ein Material verändert,
Materialien haben ja Zustände, dürfen ja Zustände haben,
ist ja so eine der wesentlichen Eigenschaften von Materialien,
dass sie sich über die Zeit verändern.
Dürfen Materialien eigentlich Veränderungen ihres Zustands, einem registrierten Beobachter mitteilen.
Sollen die das können? Ja. Please eleborate. Warum
nicht? Weil sie eigentlich den Rest nicht kennen dürfen.
Warum nicht? Das ist eigentlich gar nicht ihre Aufgabe,
dass sie, da wird es mir jetzt nicht geändert haben.
Warum sollen die den Rest nicht kennen dürfen? Zwar abgesehen davon,
dass wenn die mit dem, ich meine,
das Beobachtermuster haben wir ja hier liebevoll, also argumentiert,
hier diese Funktionskomponente weiß gar nicht, ob das,
was da oben drüber liegt.
Also ob der Beobachter, ob der Beobachter,
ob das eine Interaktionskomponente ist oder nicht möglicherweise.
Sowas geht ja auch. Warum nicht? Also die kennt
ja ihre Beobachter nicht. Sie weiß ja nur,
dass also, das weiß sie auch nicht
Was sie weiß, ist, ich ändere mich. Und
falls sich jemand registriert hat, dann wird er sich das jetzt anschauen.
Oder auch nicht. Also, dürfen Materialien, sollen Materialien
ihrer Umgebung mitteilen können, dass sie sich geändert haben.
Ja? Mein Material, sind sie passend.
Sie sind aber hartnäckig. Materialien sind passiv, ja.
Ja, das könnte, das könnte ich
so gesagt haben
Und spätestens an der Stelle hier, denke ich,
also spätestens hier wird es auch einsichtig.
Das ist eine gute Idee ist, dass Materialien nicht
in eine Umgebung reinschreien dürfen. Ich habe mich geändert.
Weil spätestens hier müssten sie das ja dann,
also müsste der Beobachtungsmechanismus auch über Produzessgrenzen hinaus funktionieren.
Wo jeder Techniker sofort sagen würde,
oh ja, das ist ja eine klasse Herausforderung
Das versuchen wir mal. So, und das ist halt unsere Rede,
aber überleg doch mal, ich möchte doch gar nicht,
dass das Material irgendeine Kenntnis davon hat,
in welchen Kontexten es verwendet wird.
Sondern es wird einfach verwendet. Und das ist ja auch
genau die Richtung, in die sie jetzt argumentiert haben.
Das Material liegt also wahlweise auf diesem Schreibtisch oder es liegt auf jenem Schreibtisch.
Es wird auf jeden Fall, also das Benutzungsmodell sagt es einem, lokal verwendet.
Und dann braucht dieses Material, also aus einer reinen metaphorischen Überlegungen heraus,
braucht es niemandem Bescheid zu sagen, dass es sich geändert hat.
Das ist nicht die Aufgabe eines passiven Materials.
Das wird verändert und deswegen, und dass es verändert wird,
das muss dann möglicherweise ein anderes Werkzeug, muss das seiner Umgebung mitteilen.
Wenn ich jetzt hier mal noch eine, das ist jetzt überflüssig,
das kann man nämlich auch so darstellen,
wenn es auch hier eine benutzt Beziehung gibt,
dann ist es die Aufgabe, dann ist es die Aufgabe dieser Funktionskomponente,
also der Welt mitzuteilen, dass es dieses Material verändert hat.
Damit die darauf parallel zugreifende Funktionskomponente etwas davon mitbekommt und sich den Materialzustand möglicherweise aktualisiert.
Das heißt möglicherweise, das ist also diesen Materialzustand,
weil die hier soll ja auch immer einen aktuellen Bearbeitungszustand zeigen,
Dass das, also diese Forderung,
dass Werkzeuge immer den aktuellen Materialzustand zeigen, dass diese Forderung erfüllt wird.
Ja, ja. Und mal, wir hatten auch,
das entwickelt das, was ich jetzt versuche,
mit ihnen hier zu spielen oder zu erarbeiten.
Wir werden vielleicht noch im Laufe dieses Semesters
mal so die Wamm-Modell-Architektur so ein bisschen herauspräparieren
Und die Idee der Wamm-Modellarchitektur ist es, so das,
was alle Modellarchitekturen tun, Designspielräume verkleinern. Was zunächst mal,
also ein bisschen seltsam möglicherweise, also sich anhört,
aber das ist so die Idee von Architekturen,
dass man sagt, also was geht und was nicht geht,
was man tun soll und was man besser lässt.
Und das,
was man auf jeden Fall im Rahmen der Wamm-Modellarchitektur besser lässt,
ist, dass man Materialienkenntnis darüber gibt,
also in welchem Kontext
sie verwendet werden
Das fängt schon so bei so Kleinigkeiten an.
Wir haben ja schon so ein bisschen über Materialentwurf gesprochen.
Aber wenn man so sagt, naja, die Bücher liegen doch im Regal.
Du bist ja so der Kurzschluss, den man,
oder der puffloffische Reflex, den man haben kann,
aha, Material, Buch.
Und dann ist es so Aufbewahrungsortregal. Dass ich
das also als Zustand an Material so mit modelliere.
Und dann sagt man, das Regal steht halt in einem Raum.
Okay, der Raum befindet sich in einem Gebäude.
Das Gebäude befindet sich im Ortsteil und so
Wenn man das modelliert, hat man also so zu sagen, ständige so Kontextreferenzen.
Nur wo bin ich? Und jetzt die Herausforderung,
man möge doch mal ein Buch von einem Schreibtisch,
also das Softwaremodell eines Buches,
möge man transportieren über rohrpost, postgabe,
was wir so kennengelernt haben,
an Kooperationsmedien
auf einen anderen Schreibtisch transportieren
Jetzt wird es aber aufwendig. Weil wenn ich das Buch anfasse,
muss ich eigentlich den ganzen Rest, der also referenziell von diesem Buch aus erreichbar ist,
muss ich mittransportieren. Und dann werde ich mich wundern,
dass das Buch, also es ist sowieso ein Wunder,
dass es irgendwann auf meinem Schreibtisch gelandet ist,
aber dieses Buch auf einen anderen Schreibtisch,
also zu ziehen mit der Maus, wenn dann also die Lichter flackern,
weil so und so viele Gigabyte gerade über die Leitung transportiert werden müssen,
weil eben die referenzielle Verbindung zu der Welt nach draußen ist,
dann werde ich mich Was sage ich denn dann?
Wir brauchen mehr Rechner, wir brauchen größere Rechner.
Es ist viel einfacher, das Buch als solches zu nehmen.
Und es dann in einen Behälter namens Regal reinzustecken.
Und dann ist es halt da drin. Und der Behälter
führt ein Inhaltsverzeichnis. Also das Ding lokal zu modellieren.
Aber das sind so, ich fange jetzt an,
so einzelne Elemente, so einer Wamm-Modellarchitektur,
also hier so ein bisschen interaktiv zu entwickeln.
Es gibt viele gute Gründe, warum also Materialien passiv sind.
Und also erstens nichts von ihrem Kontext wissen und
zweitens Veränderung über ihren Zustand,
auch ihrem Kontext nicht mitteilen
Man kann sie zwar dann fragen, was los ist,
so mit den Sondierenden und prüfenden Funktionen, aber also,
dass die sich jetzt aktiv melden, nein, danke.
So, das hier ist ja jetzt, also jetzt muss
ich nochmal. Hier ist ja jetzt so die Oberflächenschicht,
das hier ist der Interaktionsservice,
der halt für verschiedene Arten der Interaktion unterschiedlich dick ist und
hier sind wir ja schon wieder dann auf der Ebene der Services und der ist auf der Serverseite.
So. Was gibt es so an Technologien? Ja,
das ist jetzt so, das ändert sich auch alle,
alle naselang, also sowas wie Ajax steht da noch gar nicht drin.
Das kann jetzt halt so unterschiedliche Ausprägungen annehmen,
so einige dieser Technologien sind auch schon so etwas angestaubt,
werden heutzutage eigentlich nicht mehr so stark eingesetzt.
Es gab also mal eine Zeit lang, da war also
diese Modellarchitektur Enterprise Java Beans, wurde sehr, sehr intensiv diskutiert und propagiert.
Das hat sich also mittlerweile ziemlich gelegt. Das ist eben auch eine Modellarchitektur,
Enterprise, Java Beans, so als sich herausgestellt hat,
dass also die Idee, Materialien, Entity Beans,
also unabhängig, also von ihrem Ort, so zu modellieren,
dass sich die als ziemlich ineffizient erwiesen hat.
Insofern ist das, sind es heutzutage auch eher wieder leichtgewichtigere
Ansätze und dazu würde ich den Wam-Ansatz eigentlich auch zählen.
Haben die sich eigentlich eher durchgesetzt? Weil so ein Material
Man könnte das ja mal mit der Welt der Technologie,
also Leute, die nicht mit einer fachlichen Modellierungsgeschichte daherkommen,
denen sage ich ein Material, ist auch nichts anderes als ein Pojo.
Pojo? Ja, eben, genau. Also das Plain
Old Java Object. Es gibt da überhaupt keine technischen,
also Verwüstungen. So ein Material modelliert einen fachlichen Zusammenhang,
einen Arbeitsgegenstand und das ist es dann.
Und mit welchen Verteilungstechnologien und mit welchen Persistenztechnologien,
das ist also verteilt bzw. persistiert wird,
Wir haben ein echtes Gottvertrauen,
dass man das Zeug sowohl verteilen als auch persistieren kann.
Aber wir brauchen das bei der Diskussion darüber,
was wir jetzt implementieren wollen und sollen, brauchen wir uns darüber keine Gedanken machen.
Wir fangen nicht in einem Projekt mit der Verteilungsfrage.
Wir fangen auch nicht an mit der Persistierungsfrage. Es ist also,
ich würde mal sagen, das ist so in den Kontexten,
in denen wir uns hier bewegen, die ich mit Ihnen diskutiere,
ist das also echt nachrangig.
Was ist was anderes, wenn man, was weiß ich,
Klimarechenmodelle macht oder so Sachen, wo ich mich nicht auskenne.
Aber so in unserem Kontext Pojos, Materialien, Arbeitsgegenständars,
Ausgangspunkt ist sicher, also eine hinreichende Idee.
So, jetzt machen wir noch ein paar Beispiele für,
wie können denn solche Services aussehen? Ach Gott,
ja, wäre schön, wenn das jetzt so einfach wäre,
so ein paar Klinken habe ich Ihnen leider noch nicht verraten.
Stellen wir uns also so diesen Kontoservice vor und der sieht ja aus,
so wie als hätte ihn ein Wammler in der Wolle
gewaschener Wammler,
hätte der
ihn entworfen
So, ich komme also, kann an den Service die Anfrage stellen, existiert so ein Konto,
das DV hier steht für Domain Value und Domain Value ist so die,
ist das englische Wort für Fachwert.
Also wir modellieren Fachwerte als modellierende Kontonummern als Fachwerte,
das haben wir ja auch schon besprochen, also das Fachwerte,
eine wirklich gute Idee ist, um die Basismaschine,
die ja nur sowas wie Integers und Strings kennt,
um die zu erweitern,
dass ich also Klassen habe,
die mit einer Wertsemantik implementiert werden,
also so ein DV-Kontonummer
Damit kann ich fragen, ob so ein Konto existiert.
Da kriege ich als Antwort dann, jo, oder ja oder nein.
Aha, sehr gut. So, jetzt sagen wir mal,
ich habe als Antwort ja bekommen und dann rufe ich diese Operation aus.
Also ich weiß ja, dass die Kontonummer das Konto existiert.
Und dann rufe ich diese Operation auf und dann kommt es zu einer Exception.
Was kann dazu, wieso, was, wie Acception?
Was kann denn da jetzt passiert sein?
Mein Abgesehen davon, dass viele Sachen passieren können
Wieso könnte es denn, obwohl ich so brav nachgefragt habe,
wieso könnte es zu einer Exception kommen?
Bitte. Verdammte Verteilung. So ein Mist. Also hier
ist mein Kontoservice. Und das ist ein Klient und hier
ist ein anderer Klient. Der hier fragt nach,
existiert das Konto, die Antwort kommt,
Der hier sagt, mean while on the ranch, lösche das Konto.
Schurkisch. Ohne böse Absicht. Und das hier,
also ich als Klient stehe auf einmal dumm da.
Was bedeutet das? Das Vertragsmodell ist also so einfach dann nun auch wieder nicht.
Also übertragbar auf diese verteilten Kontexte. Das heißt,
ich muss also immer noch so Sicherheitsoperationen drumherum machen,
weil selbst also bei bestem Willen, also kann es passieren,
dass also gerade an solchen Stellen Das ist gerade an solchen Stellen,
wo ich bestimmte Voraussetzungen mache, um eine Operation durchführen zu können.
Also das hier ist ja die, dass das hier True liefert,
ist ja die Voraussetzung dafür, dass das hier aufgerufen werden kann.
Das Vertragsmodell ist bei der Implementation von fachlichen Services nicht eins zu eins übertragbar.
Insofern muss man jeweils, weil wenn man ein Vertragsmodell hat,
das ist die wenigsten Verfügung darüber, aber bitte,
das sollte man konzeptionell, sollte man das immer mitdenken,
dann ist also, muss man mit der Möglichkeit rechnen,
obwohl man die Vorbedingungen geprüft hat, dass hier trotzdem Ausnahmen, Ausnahmebehandlungen ausgelöst werden.
Aber ansonsten ist es ja, wenn man mal vom Normalfall ausgeht,
es liest sich das ja, also so wie eine,
wie ist sich das wie eine hübsche Service-Schnittstelle oder so,
das Erste, was ich machen werde, ist,
ich lasse mir alle Kontonummern geben, dann habe ich also alle Kontonummern,
dann frage ich eine Sicherheitshalbe nach,
existiert das Konto und dann lasse ich es mir geben.
Also für den Normalfall, Gott sei Dank bietet dieser Service
noch nicht mal die Möglichkeit an, ein Konto zu löschen.
Insofern ist ihre Vermutung ziemlich aus der Luft gegriffen
Das geht gar nicht. Man kann gar kein Konto löschen.
Also kann da auch eigentlich nichts schiefgehen. Außer das,
also wirklich was schiefgegangen ist, nämlich das Konto gelöscht worden ist.
Habe ich gerade gestern erlebt. Ich rief jemanden an,
der hier arbeitet und dann sagte das Telefon,
diese Rufnummer ist nicht vergeben.
Was ist denn jetzt los? Und dann kam eine halbe Stunde später,
kam also die Mail,
die ungefähr anderthalbtausend Leute erreicht hat,
dass unser Telefonprovider hat einfach
bestimmte Verträge gekündigt
Und dann haben die den Rest des Tages damit verbracht,
das wieder hochzufahren. Das ist wieder alle erreichbar waren.
Muss wohl irgendwo ein Bit umgekippt sein.
Ja, Dinge passieren. Und das ist, ich meine,
wer von ihnen hat den Jen Summer Summerville gehört,
als der hier letztes Jahr vorgetragen hat?
Jen Summerville ist also so einer der berühmteren lebenden Softwaretechniker.
Er sagte, ja, wir haben immer sehr viel Wert darauf.
Also so bisher hat die Software technische Forschung sehr viel Wert
darauf gelegt, also die Frage zu beantworten,
wie können wir verhindern,
dass Softwaresysteme zusammenbrechen
Und es ist eine legitime Frage. Und dazu gehört dann
eben Vertragsmodell zum Beispiel auch als ein methodisch wirklich so hübsches
Element einer runden Softwaretechnik. Nun sagt er aber so,
dass die Komplexität der heute, also implementierten Anwendungen anbetrifft,
müssen wir unser Augenmerk viel mehr auf die Frage stellen,
wenn es denn zusammengebrochen ist,
wie kriegen wir das Zeug schnell wieder ans Laufen?
Und das ist eine echt andere Frage. Es ist also
so das, was er sagt, so Design for Recovery.
Wie kriege ich es hin, weil es wird irre
Irgendwo steht immer mit seinem, immer jemand mit seinem linken Fuß
auf dem falschen Stecker oder es fällt Strom aus oder sonst irgendwas.
Wie können wir das Zeug so bauen,
dass wir es ziemlich schnell wieder ans Laufen gebracht kriegen?
Das ist eine Frage, die, ja, die ist,
das ist eine Forschungsfrage. Den können wir nicht so einfach
beantworten. So, wir machen hier weiter. Ja,
diese andere Maßgabe, also Proxy hatten wir schon für den Verteilungsfall,
dass hier so eine ganz allgemeine Regel programm to in interface, nicht not to and implementation.
Also die Idee, dass ich den Konto-Service direkt verwende,
ist also auch nicht zielführend, was heißt nicht zielführend.
Diese Idee, direkt den Konto-Service zu verwenden,
also da wird von abgeraten, weil,
wie man hier sehen kann, naja, ich kann also,
wenn ich das gegen ein Interface implementiere, habe ich die Wahlfreiheit,
also wie ich den Konto-Service denn jetzt also tatsächlich instanziere.
Und das ist, also das halte ich erstmal für eine
gute Idee, also dass man gegen ein Interface implementiert.
Das hindert einen daran, dass es an der Stelle Annahmen über
die Implementation zu machen, was regelmäßig eine gute Idee ist.
Und dann können Sie, wenn Sie mal so später,
wenn Sie sich so auf Konferenzen bewegen und so Praxisberichte sich anhören,
so wie ich mir letztens einen hübschen Bericht angehört habe,
über einen sehr,
sehr erodiertes Software-System,
hat der Mann vorgetragen
Und dann sagt er, und zu allem Überfluss haben sie
auch noch vor jede Klasse ein Interface gehängt. Also das ist,
ich sag das, ich erzähle es deswegen,
weil das hier ist auch kein Allheilmittel,
an der Stelle würde ich sagen, ist das Pflicht,
das so gegen ein Interface zu implementieren, ob ich,
also hier noch jetzt, also diese Designregel anwende,
dass also die Interaktionskomponente gegen ein Interface einer FK implementiert werden muss,
das würde ich jetzt erstmal bezweifeln.
Also das muss es nicht sein
Nein. Weil die Implementation einer FK auszutauschen,
also es ist ja dann immer auch die Frage,
wie wahrscheinlich ist denn das eigentlich, in meinem Anwendungsfall jetzt so,
dass das also ausgetauscht wird, die Implementation.
Und dann gibt es ja diese andere Regel,
keine Technologie auf Vorrat implementieren,
was eigentlich das genaue Gegenteil,
also von dieser Maßgabe ist,
also sie werden schon eine Reihe von Entwurfsentscheidungen
immer wieder zu treffen haben und mit etwas Glück treffen sie
die Falsche
Müssen sie dann nachher verantworten. So, also,
was sind so die Eigenschaften fachlicher Dienstleister? Darüber habe ich
jetzt schon gesprochen, Präsentationsunabhängig. Mehrere fachliche und technische
Aspekte unterteilt sein. Das ist eigentlich auch häufig anzutreffen.
Das ist also mindestens in so einer Schnittstelle eine Unterteilung gibt zwischen,
dass hier ist also der fachliche Teil der Benutzung und dann
gibt es einen Teil, die Administration dieses Services.
Das ist also spezielle Administrationswerkzeuge oder Administrationsminister Traditionsservices auf einen Teil der Schnittstelle arbeiten können,
der für die anderen eigentlich irrelevant ist, der nicht benutzt werden kann.
Und das spricht dann auch wieder dafür,
dass man also nicht gegen den gesamten Service implementiert,
sondern dass das hier eine Schnittstelle zur Verfügung gestellt wird,
die für die normale Alltagsbenutzung genau sagt,
welche Operationen da benutzbar sein sollen.
Und dann implementiert dieser Service unter anderem eben diese Schnittstelle,
aber auch für Administrationszwecke
eine andere Schnittstelle
Darüber haben wir schon gesprochen, dass das so hierarchisch angeordnet
sein kann, dass das in Outdoor-Kritikerzyklen entwickelt werden sollten.
Also was wird eigentlich nicht in Outdoor-Kritikerzyklen entwickelt? Das ist bei Services,
ist das aber, ist das nochmal so eine etwas,
so ist das nochmal eine etwas größere Entwurfsherausforderung.
Nehmen wir mal diese klassische kleinen Serverwelt an,
haben sie sich als sowas gebaut
Was jetzt an fachlicher Funktionalität hier implementiert wird und was hier implementiert wird,
ist auch nicht, also von vornherein klar.
Also wenn sie sowas wie so ein Kontobearbeitungswerkzeug haben,
so Einzahlen auszahlen und dieses ganze Zeug,
also was also von dieser Funktionalität hier drin liegt,
ob sie das jetzt eher groß machen oder eher klein,
mit Blick auf, ich habe ja auch noch so einen Service,
meinetwegen so einen Überweisungsservice, der mir so liebevoll zur Verfügung gestellt wird.
Das ist also, immer nur eine Schnittstelle zu bedienen hat,
ist das also mitnichten selbstverständlich. Was hier implementiert wird,
was hier implementiert und wie vor allem auch,
wie also das Verhältnis zwischen Service und Material ausschaut.
Das wird in dem Moment einfacher und sie sagen,
naja gut, ich muss jetzt nicht nur so eine Ritch-Kleid-Oberfläche bedienen,
wo ich ein voll ausgestattetes Werkzeug zur Verfügung habe,
sondern das war ja so der Anfang der Diskussion.
Ich habe eben hier auch noch,
also so als zusätzlichen Klienten habe ich also noch sowas Webartiges und
da kriege ich also fast gar nichts, was da ankommt.
Also das, was ich maximal, also über den Interaktionsservice noch bekomme,
ist, dass man, also hier aus den Strings,
die da oben eingegeben worden sind,
das ist also diese Interaktionsservice schon mal versucht hat,
ein paar Fachwerte daraus zu machen.
Und der Versuch sollte nicht gescheitert sein, weil das könnte der
dann auch hier lokal, könnte der das mit der Oberfläche aushandeln.
Aber der Interaktionsservice kann halt im Glücksfall,
kann der halt so ein paar Fachwerte rüber schicken.
Und das zwingt sie dann schon, also bei dem fachlichen Service,
also sich andere Gedanken darüber zu machen,
was ich denn jetzt hier eigentlich als Schnittstelle zur Verfügung stelle.
Weil hier hat man ja so die volle Flexibilität. Und da wollte man also fast nichts,
was also an der Oberfläche, plus minus viel JavaScript,
aber so, wenn so eine Maßgabe ist,
hier wenig zu implementieren, also in der Oberfläche,
dann kommen hier halt im Regelfall nur eine Menge von fachlichen Werten an.
So, also dann Autokritikerzyklus, die können eben dafür sorgen,
dass also so die Oberfläche rein.
Nicht nur sauber, sondern rein. Ja, Lilipp.
Ja, ja, Zustandslosigkeit für Services. Das ist noch
ein anderer Grund, so warum jetzt hier ist ja Zustand drin.
Das Ding soll zustandslos sein, damit es eben von vielen
Klienten bedient werden kann. Und das ist noch ein Grund,
also warum man also die Funktionskomponente eines Werkzeugs nicht,
also nahtlos einfach auf die Serverseite tun kann,
wenn da auf einmal verschiedene Interaktionskomponenten drauf arbeiten.
Die werden sich ganz schön wundern an den verschiedenen Arbeitsplätzen,
wieso sich ihr Werkzeug auf einmal in einem anderen Zustand befindet.
Das ist gar nicht ihr Werkzeug. Also es ist überhaupt völlig sinnlos.
Also über diese Art von Verteilung nachzudenken, weiter nachzudenken.
Es sei denn, man ist ein echt schlechter Mensch.
Oder ein Programmierer, der seinen Job loswerden will,
weil er verwirrung stiftet.
Ich sehe dein Werkzeug. Toll. Ich möchte aber lieber
mein Konto sehen,
das ich jetzt gerade bearbeite
So. Nachrichten verschicken. Das ist also, manchmal ist es
dann doch sinnvoll, dass so fachliche Services Nachrichten versenden können.
Und das ist dann so ein Mechanismus, der also ähnlich
dem Beobachtermechanismus funktioniert. Wenn es denn sein soll,
solche Fälle gibt es halt, dass so ein Service,
also etwas an über seinen Zustand oder über die Möglichkeit,
ihn anzusprechen,
seiner Umgebung mitteilen,
möchte aktiv
Also dann ist das auch so, sagt die Wammm-Modellarchitektur oder nichts Gegenteiliges,
dann kann also so eine umgekehrte Benutzungsbeziehung hier so über so
eine Cuing-Mechanismus auch, ist dann auch gestattet.
Aber das ist eben so im Großen und Ganzen ist das
also für den Administrativen Teil ist das gedacht, diese Ausnahme.
So, und jetzt noch so ein paar Beispiele.
Für Services. Ja, bitte. Wir haben eben das
Beispiel Comic-Service und da konnte man ja auch ein Konto speichern.
Ja. In dem Sinne ist doch der Service-Zustand behaftet.
Auch wenn ein bisschen Speicherung nachher in Resistenzschwindigkeit in meinem Leben.
Ja, aber das ist ja genau der letzte Halbsatz.
Das ist genau die Lösung dieses Problems. Das ist,
reicht es also so schnell, wie er kann,
reicht er das also weiter, sodass also im Service nicht so bekannt ist,
also dass da ein gespeichertes Konto vorhanden ist.
Ja, das ist so die Lösung, so dieses Problem,
eigentlich würde man ja denken, es ist Teil des Services,
zu sagen, ja, du hast das Konto gespeichert.
Nein, also erreicht es gleich weiter. Und dann kann er
zustandslos weiter vor sich hin leben. So, ach ja, das haben wir schon an verschiedenen Stellen implementiert. Das,
was Sie hier sehen, ist so ein Blick auf eine Diagnose-System,
also die erste Idee war, dass mit Rich Client RMI die Patientenverwaltung,
also zu implementieren, haben wir auch gemacht und dann kam halt der Wunsch auf,
ja, wir brauchen aber auch noch Einen Web,
einen Web-Zugriff gut,
denn eben über einen Application-Server musste das in dem Fall gelöst werden.
Und ein anderer Kunde wollte das eben sein eigenes Krankenhausinformationssystem.
Also die Patientenverwaltung übernimmt. Und das kann man diese unterschiedlichen Kontexte und unterschiedlichen Anforderungen,
konnten wir halt jeweils, also ganz günstig,
ganz gut über so dieses Gedankengut des fachlichen Services implementieren.
Ein bisschen detaillierter ist jetzt dieses Beispiel, da geht es um Sandhandel.
Also die Ausgangssituation, jemand ruft an und sagt,
drei blaue T-Shirts, irgendwie sowas von der Ecke.
Also das war noch ein Callcenter, das da bedient werden muss, also kein Internethandel.
Und die haben als Oberfläche halt so was Zwingbasiertes gehabt,
die haben ein Werkzeug gehabt, das also zu verschiedenen Zwecken verwendet wurde und dieses Werkzeug konnte halt also unterschiedliche Materialien bearbeiten.
Also kenne ich diesen Kunden, wie ist dessen Bonität einzuschätzen,
wie viel von dem Artikel haben wir gerade auf Lager,
was ist denn der Auftrag,
der jetzt hier gerade aufgenommen wird, So,
diese ganzen Sachen hier, die kann man völlig unabhängig,
also von der Art und Weise,
wie das also im Werkzeug interaktiv verwendet wird,
konnten wir diese Materialien implementieren.
Und die haben sich natürlich auf,
also eine ganze Reihe von Fachwerten abgestützt und zur Verfügung gestellt,
haben wir also diese Materialien und Materialien und Fachwerte immer über Services.
So, auf die haben die Werkzeuge das Hauptwerkzeug hier mit seinen Subwerkzeugen dann letztendlich zugegriffen.
Und der Hauptservice ist halt so dieser Persistenz-Service gewesen,
der dann, also sich abgestützt hat auf,
also technische Service, die technische Services, die jeweils,
also die genauen Backends kannten.
Das werden sie auch erleben. Also das ist heutzutage eher
der Ausnahmefall, dass so selbst eine Neuentwicklung,
dass die auf der sogenannten grünen Wiese stattfindet.
Da hat jemand halt seit, in diesem Fall seit 20
Jahren hat er also eine DB2-Datenbank für Artikel.
Die ist zwar,
wie heißt das
Wer glaubt, dass Projektleiter Projekte leiten, glaubt auch,
dass Zitronenfalter Zitronenfalten. Und wer glaubt das,
also das so, obwohl es seit,
ich weiß nicht, wie viele zig Jahren,
also das ist relationale Datenbank gibt und die Welt eigentlich mittlerweile bis auf die dritte,
vierte, fünfte Normalform in Datenbanken drinstecken sollte, der täuscht sich auch.
Der Regelfall ist, wenn Sie Glück haben, zweite Normalform.
Wenn Sie weniger Glück haben,
erste Normalform
Und wenn die Leute es also nicht so viel Wert drauf legen,
es ist einfach irgendwie in der Datenbank drin.
Und den Rest, also das müssen wir mal gucken,
wie wir das auseinanderklamüsern. Das hat,
teilweise hat es sogar gute Gründe, also Effizienzgründe.
Weil also so normalisierte Datenbanken neigen dazu etwas breit zu werden,
bis man so Joints über Aufträge, Kunden gemacht hat.
Also das kann schon mal ein bisschen dauern.
Also lassen wir das. Brauchen wir nicht. Ist nicht
praxistauglich. Und so entstehen dann, also Datenbankstrukturen,
wo man sagt, Leute sich sagen, naja,
das mit den Artikeln, Das lassen wir mal darüber.
Ja, ja, ja, wir wissen schon,
das könnte man mal renovieren und zusammen mit den Aufträgen,
wenn das echt effizienter, aber die Welt ist nicht so.
Also, lasst es. Gut, lassen wir das.
Und die Kunden, die haben wir her, ja,
da hat mal einer unserer ehemaligen Entwickler, hat die Entscheidung getroffen,
dass wir die in der SQL-Datenbank halten wollen.
Der ist zwar mittlerweile nicht mehr da,
aber die Kunden sind immer noch in der SQL-Datenbank.
Also, man trifft einfach auf so eine existierende Landschaft.
Und dann kann man also mit diesem Gedanken der Service-Architektur kann man auch also versuchen,
kapseln, um nahe zu verrottete Datenbestände, also zu handhabbar zu machen.
Auch dazu kann man Services verwenden. Das heißt also,
in der neueren Literatur spricht man da auch von sogenannten Anti-Corruption-Layern.
Ja, Antikorruptionsschichten. Also man weiß,
unten drunter ist alles so verrottet und korrupt,
also korrupt im Sinne von nicht jetzt,
also dass jemand Geld haben will,
um einen Service zu erfüllen,
sondern also korrumpiert,
So ein Anti-Corruption-Layer sorgt dann dafür. Also das nach außen hin so darzustellen,
als wäre auch nach innen eigentlich die Welt in Ordnung.
Und dann kann man anfangen, eben ganz tolle Werkzeuge da drauf zu setzen.
So, was wir uns jetzt noch anschauen, ist,
was ist da? Wie sieht,
also so ein tatsächlich implementierter Artikelservice aus und Sie sehen,
wir haben uns viel Mühe gegeben, auch wenn wir wissen,
dass das also im Einzelfall schiefgehen kann.
Wir haben diesen Gedanken versucht, aufrechtzuerhalten.
Es gibt also so etwas wie das Vertragsmodell
Das ist also, ja, gibt es einen Artikel?
Man kann auch alles gleich reinstecken. Ja, das
will man ja wissen. Das, was in der,
das, was wir ihnen im Grundstudium, nee,
das ist ja gar nicht mehr Grundstudium hier,
es sind Bachelor ja auch beibringen,
ist bloß nicht Englisch und Deutsch miteinander vermittchen, ja?
Bloß nicht. Dann ist es ganz schlechter Stil.
Und in diesem Sinne bitte ich Sie auch
diese aus der Praxis entnommene Schnittstelle zu interpretieren
Das Grauenhafteste, Termish. Hassartikel. Mit Artikelnummer.
Ja, wunderbar. Was sind wir International? Ja.
So, also, at Artikel, was hat der?
Also der Artikel, der darf nicht leer sein.
Ja, der darf noch nicht drin sein.
Und nachher, guckt mal, es hat auch Nachbedingungen.
Nachher muss das Gegenteil gelten, oder? Ja,
Hassartikel, ja, ist auch gut
Das, was ich versucht habe, rauszuholen mit der Artikelnummer,
muss gleich dem sein, was ich jetzt raushole.
Ja, das ist toll. Also so macht Software Spezifikationen
doch Spaß. Und jetzt verrate ich Ihnen noch,
warum wir in diesem speziellen Fall,
also so viel Wert darauf gelegt haben,
dass wir das so doch etwas feiner runterspezifiziert haben.
Abgesehen davon, dass man das sowieso immer machen sollte.
Wir haben das nämlich im Laufe des Tages
per E-Mail nach Indien, war das, glaube ich,
Und wenn wir am nächsten Tag also gekommen sind,
dann wollten wir eine Implementation davon sehen,
weil das war der Deal mit dem indischen Zulieferer.
Also das Kunde wollte, dass ein bestimmter Teil des Auftrags von,
also Germans, outgesourcten Entwicklungsdienstleistern erledigt wird.
Ist ja klar, der Kunde denkt dann, das ist kostengünstiger.
Ich sage jetzt mal nichts weiter zu diesem Gedanken,
das kann klappen. Sagen wir es mal so.
Das spricht technisch, spricht da auch nichts dagegen
Was jetzt testen und den ganzen Overhead anbetrifft, da muss man halt
mit rechnen. Aber das hat sich in dem Projekt,
das war mehr so ein Testprojekt für den Kunden,
ob sie das in Großen auch wirklich so machen wollen.
Also mindestens war dieses Testprojekt nachher dann so erfolgreich und auch mit der Arbeitsverteilung,
dass man sagen konnte, ja,
das könnte auch im großen Projekt klappen,
weil das ist ja etwas, was so Arbeitsverteilung anbetrifft,
dieses ganze Zeug hier, das können sie ja,
wenn sie so über ihre Modellierungstechniken verfügen und da gehört eben Vertragsmodell, Zustandsübergangsdiagramme
So etwas, also das ist ja das kleine 1x1. Wenn Sie das haben,
dann kann denen hier, die das, denen,
die das implementieren, auch wirklich völlig egal sein,
wie, was hier oben sich abspielt.
Und das ist in diesem Sinne ist es,
also es gibt so diese Wamm-Modell-Architektur, also auch selbst für solche Offshoring-Maßnahmen,
ist das so eine kleine Handlungsanleitung,
so wie man wie so eine Arbeitsverteilung aussehen kann.
Weil es wäre ziemlich beknackt gewesen, Verzeihung,
also die Arbeitsverteilung zwischen, sagen wir,
diesem Frontend und diesem Frontend
zu machen
Nur um mal eine besonders dumme Idee dagegen zu halten. Ich glaube nicht,
dass jemand in der Praxis also tatsächlich auf die Idee kommen würde,
aber so das da zu trennen, ist durchaus zielführend.
Ja, und so zieht sich das jetzt durch die,
zieht sich das jetzt durch diesen Service,
also die lassen sich die Operationen,
lassen sich jeweils also gut spezifizieren durch vor- und nachbedingungen.
Und jetzt ist also dieses Praxisbeispiel, zeigt ja jetzt auch,
Also das ist wirklich mit diesem Deutsch-Englische, das ist wirklich so total grauenhaft.
Na gut, davon sehen wir jetzt mal ab.
Aber mit was für lustigen Fragestellungen man sich dann ja dann doch,
wo man so als von außen draufschauender,
wo man sich kaum Gedanken drüber machen möchte oder sich keine Gedanken drüber machen kann.
Also sie bestellen ein blaues, also sie wollen
ein blaues T-Shirt sehen und dann sagt das Ding ihnen,
ich habe ein grünes.
Weil irgendjemand, also so die Abfrage halt,
hells Ersatzartikel vor, halt in einer entsprechenden Art und Weise
implementiert hat
Und was man so für Sachen lernt. Was schätzen Sie?
Habe ich das schon mal gefragt? Wie hoch die Retoure-Quoten,
also in dieser Branche ist, so beim Internet bestellen?
Habe ich das schon? Die Retoure-Quoten. Sie setzen sich
abends an den Rechner und bestellen ein T-Shirt.
Wie viel Prozent davon, also 100 Prozent kommen bei Ihnen an,
wie viel Prozent, glauben Sie, gehen wieder zurück?
Ich höre 75. Na
So zwischen 60 und 80, 75 scheinen das zu spielen,
dieses Spiel. Das Spiel wird nämlich so gespielt,
also ich möchte ein grünes T-Shirt haben und ich glaube,
L ist meine Größe. Aber vielleicht passt mir auch noch M,
weiß man ja nicht, wie die jetzt so ausfallen,
oder? Zur Sicherheit bestelle ich mal noch ein XL.
Das Blaue ist eigentlich auch schön. Also nochmal drei.
So, dann kommen also sechs an.
Obwohl ich weiß, dass ich nur eins haben will.
Ja, finde ich noch nicht mal als inlegitim, diese Herangehensweise.
Aber das hat vielen Versandhändlern schon, also viele Probleme bereitet,
Sex rausschicken und das Rausschicken ist nicht das Problem, das Logistische.
Das Problem ist, die fünf, die zurückkommen,
wieder so verpacken, dass am nächsten Tag der Nächste genauso agieren kann.
Und wie oft kann man das machen? So,
und dann nicht, dass ich ihnen so jungen Menschen,
von denen ich annehme, dass sie mitunter noch auf Partys gehen.
So, jetzt das ans Herz legen möchte,
weil da sind die Jungs auch darauf vorbereitet.
Sie bestellen also am Montag das schicke, den schicken Anzug.
Für die Party am Freitag. Und am Samstag schicken sie
den zurück, voll verraucht, mit Lippenstiftresten und sagen,
hat nicht gepasst
Sowas gibt's auch. Aber das kriegen die mit.
Spätestens beim zweiten Mal. Nur, ja,
ich weiß gar nicht, was die dann machen,
aber ja, das, also so ein Artikelservice,
der ist da erstmal ganz harmlos, ne?
Und dann kommen so diese Services drumherum, so,
was halt so den Alltag so lustig macht.
So, liebe Leute, was haben wir?
15.037 Uhr, der Rest ist eigentlich, ja,
ja,
mehr Benutzerfähigkeit
Ja, jede Operation ist eine Transaktion.
Auch schön, schön gesagt. Das Problem hier,
das ist, das möchte ich nur nochmal erwähnt haben.
Das, was ich jetzt gerade gesagt habe,
waren ja so die Unwägbarkeiten des Fachlichen Umgangs. Das,
was natürlich auch zu berücksichtigen ist, ist,
dass in so einer Architektur, ich sage dem Ding jetzt also,
das Werkzeug sagt dem Persistenzservice, Ich speichere diesen Auftrag für diesen Kunden.
Und der Persistenzservice sagt als erstes, also jetzt reduziere ich mal den Artikelbestand.
Jetzt registriere ich diesen Auftrag, damit eine Rechnung geschrieben werden kann.
Und dem Kunden hier gebe ich noch,
will ich noch drei Persistenzpersistenzpunkte, sehr schön.
Bonuspunkte geben. Und der hier stürzt jetzt mal lustig ab.
So, das ist dann eben eine Frage so
mit dem Rollback
Wann kann ich, also wann kann der hier nach oben melden,
dass es geklappt hat? Wann ist ein Auftrag vollständig abgearbeitet?
Weil das hier oben an der Schnittstelle tut es ja so,
dieser Persistenz-Service, dieser Artikel-Service, als sei er atomar,
ist er aber gar nicht.
Im Inneren hat er noch, also ganz schöne,
ganz schön viele Quarks und da kann noch was schiefgehen.
Das ist eben so eine weitere Herausforderung beim Design dieser Schnittstellen,
also die einzelnen Operationen so zu gestalten,
dass sie also auch möglichst atomar abgearbeitet werden können.
Und mit diesen Worten bedanke ich mich für Ihre Zeit.
Bitte entschuldigen Sie die Verspätung nächste Woche wieder ohne Anzug und
dann im B201, oder?
Ja. Juhu