Autor: z_admin

Java ist eine brauchbare Programmiersprache. Der Umfang des JDK plus einen Datenbank-Treiber (JDBC) und einen Treiber für einen Asynchronen Transaktionsmonitor reicht. Es gab sicher einigen Wildwuchs, insbesondere bei J2EE und den diversen Tools, um Datenbank anzusprechen oder GUIs  zu erstellen, aber man muss es ja nicht nutzen.

Ich sehe Java mit der „Brille“ des Back-End Programmierer, der auch in „alten“ Programmiersprachen Back-End Prozesse erstellt und hierbei von den vielen Jahrzehnten Erfahrung seiner Kollegen und Vorgänger profitiert hat. Den Fehler, die ein COBOL Programmierer 1970 gemacht hat, ja machen musste, weil es die bessere Alternative noch nicht gab und den ein anderer COBOL Programmierer 1985 ausgebaut hat und mir davon stolz erzählt hat, muss ich nicht 2015 in JAVA wieder tun, in der Hoffnung, dass 2030 ein JAVA Programmierer meine Fehler beseitigt. Als Beispiel: Speichern von Daten in hierarchischen Strukturen statt in relationale Tabellen. 

Und irgendwie war mein Einstieg in die OOP nicht c++, sondern ein Buch über smalltalk, das ich vor 30 Jahren las. Damals gab es leider keine für einen Studenten bezahlbare Möglichkeit, etwas mit smalltalk auszuprobieren, aber was für eine c-Programmierer, damit auch für einen c++ Programmierer und letztlich für einen Java Programmierer ein Methoden-Aufruf ist (function call), ist für mich auch eine Nachricht (message).

Das GUI oder ein anderes Programm schickt (XML-) Messages per Asynchronen Transaktionsmonitor, der Transaktionsmonitor ruft das Programm auf, das Programm liest und schreibt mit SQL Statements auf Datenbanken, vielleicht sendet es an ein anderes Programm (XML-) Meldungen und wenn es fertig ist, schickt es einen Response an den Transaktionsmonitor, der wiederum den Aufrufer informiert.

Damit sind die Programme zustandslos, der „alte“ Zustand seht in der Datenbank, der „neue“ Zustand wird vom GUI verwaltet und am Ende steht der „neue“ Zustand in der Datenbank. 

Das vielfach implementierte Vorgehen eines zustandsbehafteten Server-Prozesses führt an einige Stellen zu Problemen, die man vermeiden sollte. Zum einen geht es um die Verwaltung des Zustands des Server-Prozesses, wer sich die Beispiele für eine Entity Bean oder Stateful Session Bean anschaut, sieht einen komplexen Lifecycle. Zum anderen erzeugt jeder Aufruf einer Server-Funktion vom GUI aus einen recht grossen Overhead, einem Aufruf mit 10 kb ist zehnmal schneller wie 10 Aufrufen á einem Byte. Wenn man keine Datenbank (also Transaktionen) und keine gesicherten Transportwege (Asynchroner Transaktionsmonitor) zur Verfügung hat (beides fehlte SUN damals im Produkt-Portfolio), also die gesamte Verwaltung der Transaktionen in Java macht, muss man den Weg von EJB gehen, aber wer arbeitet heute ohne Dankbank und Transaktionsmonitor?
 
Einige Dinge fehlen mir oder stören mich in Java.

• Null-Objekt
• „IS“ oder „ALIAS“
• Evaluate
• implements Klasse
• Klassen entsprechend der XSD Definitionen
• String mit fester Länge

OpenSource ist in aller Munde, wir alle nutzen OpenSource.
Dieses Seite wird mit einem OpenSource CMS betrieben, die Datenbank, die das CMS nutzt, ist auch OpenSource. Das Betriebssystem, das auf dem WebServer läuft, dürfte OpenSource sein.

Es gibt Office-Programme, Entwicklungsumgebung, WebServer, Datenbanken, … als OpenSource. 

OpenSource ist nicht billiger wie kommerzielle Software, die Entwickler, Tester, Handbuch-Schreiber, Supporter und die vielen anderen Menschen, die an einer Software arbeiten, wollen auch leben und ihre Familie ernähren. Wie diese Kosten gedeckt werden, ist bei verschiedenen OpenSource Projekten unterschiedlich. Und werden die Kosten nicht langfristig gedeckt, stirbt eine OpenSource Software.

Ich habe auch schon den ein oder anderen Beitrag zu OpenSource Software geleistet, manchmal privat, manchmal im Rahmen von Projekten und natürlich im Auftrag des Kunden. Und ich habe auch schon Geld gespendet.

Der Grund, warum Unternehmen OpenSource einsetzen sollten, ist die Verminderung der Abhängigkeit. 

Ihr Unternehmen setzt eine Software, zum Beispiel eine Warenwirtschaft, ein und baut um diese Software einen Workflow, nutzt Schnittstellen zu anderen Programmen. 

Nun nimmt, warum auch immer, der Hersteller, Inhaber des Copyright oder auch der Konkursverwalter des Herstellers die Software vom Markt, sprich stellt die Wartung ein. 

Sofern Ihr Unternehmen eine Dauerlizenz besitzen, kann der Hersteller Ihnen zwar nicht die Nutzung verbieten, aber Sie werden auch keine Updates mehr erhalten. 

Auch so ist das Ende der Nutzung absehbar. Bei der nächsten Version des Betriebssystems, einer gesetzlichen Änderung, … müssen Sie die Nutzung des Programms einstellen.

Also beschaffen Sie ein neues Programm. Das mag Geld kosten, aber Ihre Kosten sind weit höher. Ihr bisheriger Workflow, die Schnittstellen zu den anderen Programmen und das KnowHow Ihrer Mitarbeiter sind hinfällig. 

Hätten Sie eine OpenSource Software und das KnowHow an der Hand, zum Beispiel ein oder mehrere Mitarbeiter, die mit der Software programmieren können, können Sie die Software selber weiter warten und damit Ihre Investitionen schützen. 

Bei vielen OpenSource Projekten gibt es auch Unternehmen, die nicht nur an der Entwicklung beteiligt sind, sondern auch gegen Gebühr einen Support anbieten. Wenn dieser Dienstleister den Geschäftsbetrieb einstellt, haben Sie zumindest die Option, einen der jetzt arbeitslosen Mitarbeiter einzustellen.

Gegenüber einer kompletten Eigenentwicklung hat OpenSource den Vorteil, dass Sie die Entwicklungskosten mit anderen Unternehmen, die auch die Software nutzen, teilen. 

Gehen Sie in die Kfz-Werksstatt Ihres Vertrauens und fragen Sie den Mechaniker, was ein Zwei-Takt Diesel ist.
Die Antwort wird wahrscheinlich ähnlich ausfallen wie die Frage nach einem Mainframe an einen Computer-Techniker.

Siebzig Prozent des Welthandels werden mit Überseeschiffen transportiert, und diese haben in der Regel einen Zwei-Takt Diesel als Antrieb.
Okay, pro Jahr werden deutlich weniger dieser Maschinen produziert wie in einem grossen PKW-Motorenwerk am Tag, …
Und an einen Schiffsdiesel kommen auch nur Maschinenbauingenieure ran.

Die Hälfte der SQL DML Befehle sind unnötig?
Klingt erst einmal komisch, aber …

Bei kommerziellen Anwendungen müssen Datenänderungen nachvollziehbar sein, einige Daten dürfen nicht mehr geändert werden, andere sollten nie mehr geändert werden, nur bei einer Gruppe von Daten könnte es die Notwendigkeit von Updates geben.

Die Datentype, Satzarten, die in Datenbanken gespeichert werden, lassen sich in vier Gruppen zusammenfassen:
– Fremdschlüssel
– Journale
– Stammdaten
– Salden

Stammdaten sind zum Bespiel: Kunden-Stamm, Artikel-Stamm, Konten-Stamm. Wertpapier-Stammdaten, …

Journale sind die Bewegungsdaten, Bestandsveränderungen, Aufträge, Ein- und Auszahlungen, Umbuchungen, …

Salden sind die aktuellen Bestände, die sich aus den Journalen ergeben. Zu einem Konto gibt es in eine Datenbanktabelle die Stammdaten, in einer anderen den Saldo. In der Salden-Tabelle sind zwei Felder vorhanden, die „Konto-Nummer“, zu der es Stammdaten gibt sowie einen Betrag (Währung, Stück, …). 

Um Manipulationen oder technische Probleme aufdecken zu können, kann es noch drei Felder geben, das Datum der aktuellen Buchung, die Anzahl der Buchungen in der Periode und der Buchungsnummer, die zu diesem Saldo geführt hat.

Bei Stammdaten und Journalen gibt es Feld-Inhalte, die einem Wertebereich zugeordnet sind, zum Beispiel die Konto-Art (Bilanz / GuV), der Anredeschlüssel, …, der Wertebereich ist in jeweils einer Fremdschlüssel-Tabelle hinterlegt. 

Jetzt zu den technischen Aspekten.

Fremdschlüssel-Werte 

Zum Beispiel die Ausprägungen für „Männlich/Weiblich“, Anredeschlüssel, Konto-Typ, Mehrwertsteuer-Schlüssel, Kunden-Systematik, …, enthalten, dürfen erst gelöscht werden, wenn der letzte Datensatz, der auf einen dieser Schlüssel verweist, aus der Datenbank verschwunden ist. 

Änderungen sind denkbar, aber nur bezüglich des Gültigkeitszeitraums. 
Als Anfang 2007 der neue Mehrwertsteuersatz von 19% gültig wurde, muss vorher dieser Schlüssel mit der Gültigkeit 01.01.2007 bis 31.12.9999 eingefügt werden. Bei dem bis dahin gültigen Mehrwertsteuersatz 16% musste die Gültigkeit von bisher 01.04.1998 bis 31.12.9999 auf dem 31.12.2006 begrenzt werden, hier ist also ein Update auf das Feld „gültig-bis“ notwendig.

Wann kann ein Schlüssel gelöscht werden? Eigentlich nie, Männer und Frauen wird es geben, solange die Menschheit existiert, nur bei zum Beispiel dem Mehrwertsteuer-Schlüssel wäre eine Löschung denkbar.

Nehmen wir den Mehrwertsteuer-Schlüssel. Er wird in jeder Auftragspositionen zu finden sein. Damit könnte er entfallen, wenn die letzte Auftragsposition mit diesem Mehrwertsteuersatz gelöscht wurde. Die gesetzliche Aufbewahrungsfrist beträgt 10 Jahren, also am 01.01.2017 könnten die letzten Rechnungen … 
Falsch! Wenn die Lieferung noch 2006 erfolgte, die Rechnung aber erst 2007 geschrieben wurde, konnte noch der alten Mehrwertsteuersatz verwendet werden. Bei Gutschriften wird auch die Mehrwertsteuer des ursprünglichen Geschäfts genutzt, damit könnte auch Jahre später noch 16% Mehrwertsteuer bei einer Gutschrift genutzt werden.

Für eine Kundenhistorie können die Daten auch deutlich länger gespeichert werden. Wenn heute ein Kunde anruft und ein Ersatzteil für einen 1980 gekaufte Maschine benötigt, ist es doch sinnvoll, heute noch die Daten von damals vorliegen zu haben. Die Umsatzsteuer (damals 13%) braucht man sicher nicht mehr, aber die Artikelnummer bzw. die Artikelbeschreibung ist wichtig. 

Also, bei den Tabellen gibt es nie ein Delete. Der Aufwand, alle Daten zu prüfen, ob der Schlüssel doch noch genutzt wird, oder vielleicht sogar den bisherigen Schlüssel durch einen Dummy-Eintrag zu ersetzen, rechtfertig nicht die Einsparung von wenige Bytes in der Datenbank. 
Bei einigen Typen mit Gültigkeitszeitraum kann dieser per Update begrenzt werden.

Und diese Fremdschlüssel-Tabellen werden nicht über ein Dialog-Programm gepflegt. In alle Umgebungen (Entwicklung, Test, Schulung, Produktion, …) müssen ja die gleichen Ausprägungen vorliegen, die Tabellen müssen identisch sein, also schreibt ein Administrator ein Script (auf dem Mainframe einen „SPUFI“), der dann nach Freigabe ausgeführt wird.

Journale 

Also Bewegungsdaten in einer Buchhaltung, dürfen nie geändert werden. 
Mit Buchhaltung ist nicht nur die Finanzbuchhaltung im engeren Sinn gemeint, sondern z.B. auch Barauszahlungen an einem Geldautomaten, Einträge in ein Fahrtenbuch, Material-Entnahmescheine, …

Falls eine Änderung notwendig ist, ist eine Storno-Buchung, also eine Generalumkehr, zu erfassen. Ein Update oder Delete ist hier gesetzlich verboten!

Es gibt gesetzliche Aufbewahrungsfristen, bei vielen Daten beträgt sie 6 oder auch 10 Jahre, Buchungen aus 2004 konnten also Anfang 2015 gelöscht werden. Solche Löschungen passieren in besonderen Reorganisation nach erfolgten Jahresabschluss. Dabei wird meist kein „DELETE FROM tabelle WHERE datum …“ genutzt, sondern die Datenbank wird entladen, die noch notwendigen Sätze kopiert und diese dann in eine neue Tabelle geladen. 

Aber bei bestimmten Journalen ist eine längere Aufbewahrungsfrist sinnvoll. Als Beispiel kann der Fall des Sparbuch dienen, das nach 38 Jahren ohne jede Buchung vom Erben gefunden und bei der Bank vorgelegt wurde. Die Bank meinte, sie haben vor über 30 Jahren das Sparbuch für ungültig erklärt, habe aber nur noch Unterlagen über eine Sammelbuchung auf einem Mikrofilm. Da die Bank nicht nachweisen konnte, dass das Geld damals wegen des Verschwinden des Sparbuches auf ein anderes Sparbuch übertragen wurde, durfte sie entsprechend eines Gerichtsurteils das „Guthaben“ zuzüglich Zinsen auszahlen. 

Salden

Der eine Datentyp, bei dem ein Update sinnvoll sein könnte. 
Bei jedem Insert in ein Journal ändern sich zumindest zwei Salden.
Wieso „zumindest zwei“? Was passiert bei „Kunden zahlt mit Skonto“? Hier ändern sich vier Salden (Bank, Forderungen, Skonto-Aufwand und Umsatzsteuer).

Was macht die Datenbank bei einem Update, sie muss ja in der Lage sein, bei einem Rollback, also dem Verwerfen der Transaktion, den alten Zustand wieder herzustellen? Sie fügt einen neuen Datensatz in die Tabelle ein und setzt das interne Löschkennzeichen für den Datensatz mit dem alten Saldo.

Wichtig ist, den Saldo-Datensatz möglichst kurz zu halten, also nicht die Stammdaten des Kontos dort mit unterzubringen. Die Datenbank muss ja den kompletten Satz kopieren (die meisten Datenbanken arbeiten auch beim Rollback satzweise). Pro Buchung zumindest 2 Salden-Änderungen notwendig, und pro Änderung für die Datenbank intern ein Kopiervorgang, und dann sind 2000 Bytes inklusive Stammdaten doch deutlich mehr wie 40 Bytes ohne Stammdaten.

Der Saldo eines Kontos lässt sich auch aus dem Start-Bestand (Tagesanfangsbestand, zugleich der Tagesendbestand des Vortages) und den Bewegungen, die ja im Journal verzeichnet sind, wieder herstellen. Es könnte also sinnvoll sein, die Salden im Hauptspeicher zu halten und zeitverzögert zu schreiben. 

Falls der genaue Bestand / Saldo eines Kontos zu jeden Zeitpunkt in der Vergangenheit ermittelbar sein oder aus anderen Gründen (gleitender Durchschnitt nach HGB) gestaffelt werden muss, muss bei einem rückwirkenden Storno auf den zu dem Zeitpunkt des Stornos aktuellen Saldo aufgesetzt werden. In der Praxis kenne ich das Vorgehen, sich die Salden vom Monats- und Quartals-Anfang zu merken, um nicht immer am Jahresanfang aufsetzen zu müssen. Wenn am 21. Mai ein Storno für den 15. April gebucht wird, wird mit dem Quartal-Anfangs-Saldo (1. April) begonnen und alle Buchungen an dem 1. April, inklusive des Stornos am 21. April, erneut gestaffelt. 
Falls statt des Updates auf die Salden-Tabelle immer ein Insert mit dem Buchungszeitpunkt (Buchungsdatum) durchgeführt wird, können alle Salden nach dem Zeitpunkt des Stornos gelöscht werden, der dann jüngste Saldo ist ja der Saldo zum Zeitpunkt des Stornos, und beginnend mit dem Storno werden alle Buchungen neu gestaffelt und die neuen Salden mit dem Zeitpunkt der Buchung eingefügt.

Stammdaten

Also zum Beispiel die Adressen von Kunden. Hier gelten auch die gesetzlichen Aufbewahrungsfristen, und die Änderungen müssen nachvollziehbar sein. 

Zieht ein Kunden um, teil uns also seine Adressänderung mit, ist die Gültigkeit der bisherigen Adresse zu begrenzen und die neue Adresse einzufügen.
Wurde eine Adresse 2015 ungültig, kann sie Anfang 2026 aus der Datenbank gelöscht werden. 

Wir benötigen also zusätzlich zum fachlichen Schlüssel (Kundennummer plus Art der Adresse) oder zum technischen Schlüssel (hier bietet sich eine eindeutige Satz-ID, also eine 64 Bit Zahl, an), etwas, was die notwendigen Datensätze im Zeitablauf eindeutig macht. Optimal ist hier der Timestamp, an dem der Datensatz in die Datenbank aufgenommen wurde, also das Feld „geändert-am“ / „eingefügt-am“.

Falls wir das „ersetzt-am“, also den Zeitpunkt der fachlichen Änderung, die diesen Satz ersetzt, in eine eigene Tabelle, bestehend aus technischen Schlüssel (ID + „geändert-am“) sowie „ersetzt-am“, auslagern, reicht ein Insert auf diese Tabelle. Die Abfragen laufen dann über einen View, der die Datensätze, deren Schlüssel auch in der „Ersetzt-Tabelle“ enthalten ist, ausblendet.

Nette Kunden informieren schon im Vorfeld eines Umzuges über die neue Adresse.
Was ist fachlich zu tun?
Der bisherige Datensatz muss zum Umzugsdatum abgegrenzt und ein neuer Datensatz eingefügt werden. Dabei sollte aber die Information, wer wann diesen Datensatz zuletzt geändert hat, nicht verloren gehen.

Wie ist die technische Umsetzung?
Ermittlung des aktuellen Timestamps und merken in einer Variable.
Insert in die „Ersetzt-Tabelle“ mit dem technischen Schlüssel des bisherigen Satzes und „ersetzt-am“ mit dem gemerkten Timestamp. Bekommen wir hier einen SQL-Fehler „Doppelter Schlüssel“ hat zwischenzeitlich ein anderer Anwender den Datensatz geändert, damit haben wir also sehr einfach ein Optimistisches Sperren implementiert.
Insert in die Adressen-Tabelle des bisherigen Satzes, nur ist „geändert-am“ der gemerkte Timestamp und „gültig-bis“ das Umzugsdatum.
Addieren von 1 (also einer Nano-Sekunde) zum gemerkten Timestamp.
Insert der neuen Adresse, „geändert-am“ mit dem Timestamp plus 1, wegen der Eindeutigkeit im Zeitablauf, „gültig-ab“ mit dem Umzugsdatum und „gültig-bis“ dem 31.12.9999 füllen.
Fertig!

Drei Insert Statements, optimistisches Sperren sauber implementiert, alle Änderungen nachvollziehbar, besser geht es nicht, und das ohne Update oder Delete.

Nun wird der Fall komplexer, aber bei Bausparkassen, Gebäudeversicherungen und ähnlichem sicher Tagesgeschäft: 
Der Kunde baut ein neues Haus und will Anfang 2015 einziehen, die bisherige Wohnung wurde zu Ende Januar 2015 gekündigt. Am 10. November 2015 teilte der Kunde die Adressänderung für den 15.01.2015 mit.
Also läuft der oben beschriebene Prozess ab. Wir haben anschliessend drei Datensätze
„Mietwohnung“, „gültig-bis“ 31.12.9999, „ersetzt-am“ 10.11.2014
„Mietwohnung“, „gültig-bis“ 15.01.2015, „geändert-am“ 10.11.2014, nicht ersetzt
„Haus“, „gültig-ab“ 15.01.2015, „geändert-am“ 10.11.2014 plus 1 Nano-Sekunde, nicht ersetzt

Kurz vor Weihnachten (22.12.2014) teilt der Kunde mit, dass sich der Bezug des Hauses um 2 Monate (16.03.2015) verzögert, er die Mietwohnung nun am 30.01.2015 räumt und dafür zwischenzeitlich bei seinen Eltern unterkommt.

Was ist zu tun?
Ändern des „gültig-bis“ der „Mietwohnung“ auf den 30.01.2015.
Ändern des „gültig-ab“ des „Haus“ auf dem 16.03.2015.
Einfügen eines Satzes „Eltern“ mit „gültig-ab“ 30.01.2015 und „gültig-bis“ 16.03.2015.

Wir haben anschliessend folgende 5 Datensätze
„Mietwohnung“, „gültig-bis“ 31.12.9999, „ersetzt-am“ 10.11.2014
„Mietwohnung“, „gültig-bis“ 15.01.2015, „geändert-am“ 10.11.2014, „ersetzt-am“ 22.12.2014
„Mietwohnung“, „gültig-bis“ 30.01.2015, „geändert-am“ 22.12.2014, nicht ersetzt
„Eltern“, „gültig-ab“ 31.01.2015, „gültig-bis“ 15.03.2015, „geändert-am“ 22.12.2014 plus 1 Nano-Sekunde
„Haus“, „gültig-ab“ 15.01.2015, „geändert-am“ 10.11.2014 plus 1 Nano-Sekunde, „ersetzt-am“ 22.12.2014 plus 2 Nano-Sekunden
„Haus“, „gültig-ab“ 16.03.2015, „geändert-am“ 22.12.2014 plus 2 Nano-Sekunden,. Nicht ersetzt.

Die ersetzten Datensätze können, müssen aber nicht, im Rahmen von Reorganisationen in einer Historien-Tabelle ausgelagert werden. Gehen wir von dem Falls aus, dass die Auslagerung nicht stattfindet, so bleiben die Daten bis Ende der Aufbewahrungsfrist in der Datenbank.

Gehen wir weiter davon aus, dass das Haus termingerecht bezogen werden konnte und der Kunde dort bis ans Ende aller Tage lebt, so ist der weitere Verlauf:

Anfang 2025 können die Sätze 
„Mietwohnung“, „gültig-bis“ 31.12.9999, „ersetzt-am“ 10.11.2014
„Mietwohnung“, „gültig-bis“ 15.01.2015, „geändert-am“ 10.11.2014, „ersetzt-am“ 22.12.2014
„Haus“, „gültig-ab“ 15.01.2015, „geändert-am“ 10.11.2014 plus 1 Nano-Sekunde, „ersetzt-am“ 22.12.2014 plus 2 Nano-Sekunden
da 2014 ersetzt, gelöscht werden.

Anfang 2026 können die Sätze 
„Mietwohnung“, „gültig-bis“ 30.01.2015, „geändert-am“ 22.12.2014, nicht ersetzt
„Eltern“, „gültig-ab“ 30.01.2015, „gültig-bis“ 16.03.2015, „geändert-am“ 22.12.2014 plus 1 Nano-Sekunde, nicht ersetzt
da 2015 ungültig geworden, gelöscht werden.

Bei der fachlichen und der technischen Gültigkeit („gültig-von“ – „gültig-bis“, „geändert-am“ – „ersetzt-am“) darf es keine Überschneidungen geben. In einem Projekt war das „ersetzt-am“ bzw. das „gültig-bis“ als „gültig-bis-einschliesslich“ definiert, was zu etwas Arbeit führte, da vom „gültig-ab“ des ersetzenden Datensatzes immer eine Nano-Sekunde abzuziehen war. Besser ist eine Definition „gültig-bis-ausschliesslich“. Dann ist der Timestamp, ab dem der neue Datensatz gültig bis identisch mit dem Zeitraum, ab dem der alte Datensatz ungültig ist.
In der SQL Where-Bedingung also
„gueltig_von <= Such-Termin and gueltig_bis > Such-Termin“
stattfindet
„gueltig_von <= Such-Termin and gueltig_bis >= Such-Termin“

Ich hatte vor einigen Jahren schon eine Docker Installation unter MacOS. Zuerst noch die Lösung mit Virtual Box, entspricht der heutigen „Docker Toolbox“, Docker braucht ja ein Linux als Basis und kein BSD Unix. Nach einemUpdate hatte ich dann eine „moderne“ Docker Installation ohne die Virtual Box als Basis. Der Plattenplatz auf dem MacBook wurde aber irgendwann knapp, deshalb flog Docker von dem Rechner.

Vor einigen Wochen habe ich mir einem Windows Notebook gekauft, I7 CPU, 128 GB SSD und 1 TB Festplatte. Es ging mir um die Frage „Kann ich auf Windows umsteigen, wenn es mein Lieblings-Betriebssystem nur noch mit einem Spiegel als Monitor gibt?“

Das meiste war schnell eingerichtet, ich hatte in der Vergangenheit darauf geachtet, dass meine „Arbeits-Anwendungen“ auch unter Windows und Linux verfügbar sind. Wirklich fehlt mir nur Time Maschine, die Suchfunktion und vor allem die „Intelligenten Order“ im MacOS Mail Programm.

Wichtig, unter Windows auch den „Windows Linux Service Ubuntu“ (siehe Microsoft Store) installieren, dann kann man aus „CMD.EXE“ mit „bash“ in den Linux-Mode umschalten.

Ich hatte noch den „OpenSSH Server“ in Windows installiert.

Jetzt wird es sprachlich kompliziert, es gibt Microsoft Windows und etwa genauso alt „X-Window“, eine grafische Oberfläche für Unix. Sie besteht aus einem „X-Server“, in den Achtzigern ein Terminal, also einen „Kasten mit Bildschirm“, heute in der Regel einer Software. Der X-Server heisst Server, auch wenn er die Schnittstelle für den Benutzer ist, weil er für das Programm der „Server“ für Ein- und Ausgabe ist. X-Server und Programm unterhalten sich per TCP/IP, es ist also egal, ob sie auf der gleichen Maschine laufen, oder über Kontinente getrennt sind.

Ein X-Server gehört nach meiner Meinung aus zu einer Unix Umgebung.

Hier habe ich XLauch auf dem Windows Rechner installiert und zum Ausprobieren mit „apt-get install kate“ den KDE Editor zum Ausprobieren. 

Von meinem MacBook aus dem Terminal kann ich mit „ssh benutzer@windows-rechner“ auf den den Linux Teil des Windows Rechners zugreifen. Nächster Test, auf dem MacBook den X-Server starten, xterm (Terminal unter X-Window) läuft, mit „ssh -X benutzer@windows-rechner“ wechseln, läuft. Nun ein grafisches Linux-Programm (kate, x-eyes, …) starten. Nun sollte auf dem MacBook ein neues Fenster aufgehen und das Programm zu sehen sein. Ein Fenster öffnete sich, aber auf dem Windows Rechner. Verschiedene Versuch mit der DISPLAY-Variable, kein Erfolg. Nach längerem Suchen fand ich die Lösung, Microsoft hat es (noch?) nicht in sein OpenSSH eingebaut, Schade.

Die Gegenrichtung, also ein X-Window auf dem Windows Rechner für eine graphische Unix-Anwendung auf dem MacBook geht (wie gewohnt) ohne Probleme.

Nach dem alles lief, habe ich mich an die Installation von Docker gemacht.

Der Rechner wurde mit „Windows 10 Home“ geliefert, damit funktioniert die normale Dcker Desktop Installation nicht. Also die Docker Toolbox genommen und installiert. Ich habe Virtual Box mit mehreren Virtuellen Maschinen am Laufen, also habe ich das Kreuzchen für „Installieren von Virtual Box“ herausgenommen. Damit lief dann Docker nicht.

Also noch einmal versucht, jetzt mit „Installieren von Virtual Box“. Danach liefen meine anderen Virtuellen Maschinen nicht mehr. Also das Installationspaket für Virtual Box von Oracle noch einmal installiert, es lief alles. Meine Virtuellen Maschinen wie gewohnt, aber der Docker nicht genauso so, wie ich es mir vorgestellt hatte. Insbesondere die Verwendung des Laufwerks „C:“ wollte ich nicht, dort habe ich ja nur wenig Platz.

Damit back to the roots. Ich installierte auf Virtual Box einen „Ubuntu Server“ mit Long Time Support und packte das Image zu den anderen Virtuellen Maschinen auf das Laufwerk „D:“. 

Natürlich OpenVPN Server nicht vergessen.

Aber Docker erst später installieren, die Pakete der Distribution sind manchmal recht alt. 

Sah gut aus, nur war die Virtuelle Maschine nicht in meinem Netzwerk erreichbar.

Also eine „Netzwerkbrücke“ bei der Installation in Virtual Box als Netzwerk Adapter 3 angegeben und neu installiert (geht schneller wie in den Netzwerkeinstellungen von Linux die Einstellungen zu ändern, der Server hat ja kein GUI), und schon war die Maschine auch in meiner Fritz!Box zu sehen. Die Netzwerkbrücke hat als „Hardware“ den Ethernet Controller des Notebooks (ist ja auch 1 GBit), wenn das Kabel eingesteckt ist, schaltet der Notebook das WLAN ab. Also das Kabel gezogen und einen weiteren Adapter mit dem WLAN Controller eingerichtet. Nun war die Virtuelle Maschine unter einer anderen IP Adresse auf der Fritz!Box zu sehen, aber beide unter dem Netzwerk Namen, die ich der Ubuntu Server gegeben hatte. Unschön, aber damit kann ich leben.

Mit „apt-get update“ und „apt-get upgrade“ für die aktuellen Version gesorgt, daran sollte man auch bei einer frisch Virtuellen Maschine denken.

Jetzt noch die wichtige Software installiert.

Ich bin „ein Kinder der Achtziger“, mag also den Norton Commander. Unter Linux gibt es einen Nachbau Midnight Commander, kurz „mc“, mit „apt-get install mc“ installiert und ausprobiert, super.

Falls man doch einen Web-Browser auf der Maschine braucht (weil nur localhost Anfrage erlaubt sind) mit „apt-get install firefox“ dem Browser installiert.

Um ihn nutzen zu können, braucht man auf Windows einen X-Server, zum Beispiel XLaunch.

Ich hatte ihn schon installiert, also auf Windows „cmd.exe“ gestartet, mit „bash“ (vorher natürlich den Ubuntu Linux Service unter Windows installieren), „xterm &“ um ein X-Window Terminal zu starten, mit „ssh X benutzer@ubuntu-server“ auf den Ubuntu-Server wechseln, „firefox &“ dem Browser starten, läuft.

Die HTML Verwaltungsoberfläche webmin hatte mir vor Jahren auf meinem PowerBook (ja, mit Power-PC CPU) gute Dienste geleistet. 

Problem, auf der Download Adresse gab es eine ältere Version. Nach der Installation von Host (Windows Rechner) webmin mit „https://192.168.#.#:10000“ aufgerufen. Der Chrome Browser beschwerte sich wegen der fehlenden Zertifikate bei https, aber nach drei Klicks sah ich das Login von webmin. Einloggen mit den Benutzer der Virtuellen Maschine und das Update auf die aktuelle Version durchführen.

Nun Docker und Docker-Composer installiert.

Getestet mit „docker-compose –version“, passt.

Docker ist nett, aber manchmal ist ein GUI schöner. Also „Portianer“ installiert. Mit „https://192.168.#.#:9000“ aufgerufen, läuft.

Den Text hatte ich im Sommer 2019 geschrieben. Mittlerweile habe ich auf dem Windows Rechner „Win10 Pro“ installiert, im MacBook ist eine größere SSD.

Das ist ein Thema, mit dem man sich viele Feinde machen kann.
Wer im Land X aufgewachsen ist, für den ist seine Muttersprache X eine einfach zu erlernende Sprache, und er wird sicher kaum verstehen, warum jemand mit dem Erlernen seiner Muttersprache Probleme hat und warum jemand so etwas komplexes wie die Sprache Y lernen und anwenden will.

Es gibt verschiedene Klassifizierung für Programmiersprachen.
Lassen wir mal das „X ist die Beste und Y ist …“ weg, dann sehe ich folgende Einteilungen:

Bei der Nutzung gibt es
– Script-Sprachen, zum Beispiel Perl, Python, Apple-Script, REXX und viele andere mehr.
Es sind Interpreter-Sprachen mit mächtigen Zeichenketten-Manipulations-Funktionen und dienen als „Klebstoff“ zwischen Anwendungs- und Systemprogrammen.

– Spezial Script-Sprachen, zum Beispiel php (für den Apache WebServer) oder PL/SQL (für Oracle Datenbanken). Sie entsprechen den Script-Sprachen, nur laufen sie in sehr speziellen Umgebungen.

Ob Javascript eine Spezial Script-Sprache ist, oder doch zu den normalen Script-Sprachen gehört? Entstanden ist Javascript für Interaktionen im Web-Browser, sie wird jedoch mittlerweile in einigen weiteren Bereichen, z.B. dem Report-Generator BIRT, verwendet, deshalb trifft die Aussage „sehr spezielle Umgebung“ nicht mehr zu.

Welche Scriptsprache in einem Projekt genutzt wird, ist abhängig von der Umgebung. Sind mehrere Anwendungen in einem Unix System zu verbinden, dürfte PHP nicht die erste Wahl sein.

– Die „normalen“ Programmiersprachen, C, C++, Basic, Pascal, Java, Cobol, Lisp, Fortran, C#…

Lisp (Autocad und vor allem Emacs) und Basic (viele Microsoft Produkte) könnten auch bei den Spezial Script-Sprachen aufgeführt werden, aber sie sind als eigenständige Programmiersprachen entstanden.

Bei der Art der Ausführung gibt es einen Unterschied, Interpreter- und Compiler-Sprachen.

Der Unterschied ist nicht, ob nativer Maschinencode erzeugt wird, sondern ob eine Syntax-Prüfung und vielleicht einige Optimierungen vor der Ausführung stattfinden. Muss einmalig nach der Programmerstellung ein Compiler aufgerufen werden und merkt dieser, falls ein Variablenname falsch geschrieben wurde, ist es eine Compiler-Sprache. Viele Compiler-Sprachen erzeugen eine Zwischencode, der von einer Laufzeitumgebung interpretiert wird, oder was als „nativ“ erscheint, läuft in einer virtuellen Maschine und wird dort interpretiert. Einige Interpreter-Sprachen erzeugen zur Laufzeit nativen Maschinen-Code, um zum Beispiel Schleifen schneller abarbeiten zu können.

Es gibt Prozedurale, Funktionale, Objekt-Orientierte Programmiersprachen, es gibt Sprachen für Künstliche Intelligenz, …

Im kommerziellen Umfeld sind aber meist Prozedurale Sprachen (Fortran, Cobol, C, REXX, …), Objekt-Orientierte Sprachen (Smalltalk, …) und Prozedurale Sprachen mit Objekt-Orientierten Erweiterungen (C++, Java., Python, …) zu finden. 

Bei Variablen gibt es verschiedene Datentypen, zum Beispiel Ganzzahl, Datumswerte, Zeichenketten, Strukturen und Objekte. Bei einige Sprachen wird bei einer Zuweisung in Variablen der Datentypen streng geprüft, bei anderen weniger stark, es gibt, insbesondere bei Script-Sprachen auch solche, bei denen alles eine Zeichenkette ist.

Wichtig ist die Art der Speicherverwaltung.
Interpreter-Sprachen haben immer eine automatische Speicherverwaltung, Befehle zum Allokieren und Freigeben von Speicherbereichen findet man hier nicht.
Bei den Compiler-Sprachen gibt es auch solche mit einer automatischen Speicherverwaltung (Java, Basic), bei anderen muss der Programmierer selber Speicher anfordern und wieder freigeben (C, Pascal) und schliesslich gibt es Programmiersprachen, bei denen die Speicherbelegung beim Übersetzen, also wenn der Compiler arbeitet, festgelegt wird (Cobol).

Hat der Programmierer die Speicherverwaltung selber in der Hand, kann er hoch optimierte Programme schreiben, aber auch schlimme Fehler (Buffer Overflow, Memory Leak) einbauen.
Bei der automatischen Speicherverwaltung kann dieses nicht passiert, aber irgendwann muss das Programm seinen Speicher aufräumen, und es kann eine Verzögerung im Programmablauf geben.
Bei Sprachen ohne Speicherverwaltung kann das alles nicht passieren, aber wenn für ein Array oder eine Zeichenkette nicht ausreichend Speicher eingeplant war, bricht das Programm ab.

Für die Systemprogrammierung und bei ausreichenden Tests bietet Programmiersprachen mit „manueller“ Speicherverwaltung grosse Vorteile, deshalb werden Betriebssysteme in C oder C++ geschrieben.
Bei der Anwendungsentwicklung, wo auch kurz vor der Auslieferung ein Bugfix eingebaut werden muss, oder wo um auf eine Marktanforderung eine schnelle Anpassung der Anwendung erfordert, ist aber die Gefahr, durch einen Buffer Overflow oder ein Memory Leak die Sicherheit der Anwendung zu gefährden, zu gross.

Für Anwendungsentwicklung sollte deshalb die Entscheidung zwischen COBOL und einer Sprache mit automatischer Speicherverwaltung, also Java, Basic oder C# fallen.
Steht der Durchsatz, also grossen Datenvolumen in einem Batch-Lauf oder sehr viele Anwender in Online-Betrieb, im Vordergrund, spielt COBOL seine Vorteile aus. Geht es um einen geringeren Aufwand bei der Entwicklung, sind Java, Basis oder C# klar im Vorteil.

Pattern übersetzen die meisten Informatiker mit Entwurfsmuster.

Ähnlich wie sie „side effects“ mit „Seiteneffekte“ übersetzen, für die meisten Menschen bedeutet der englische Begriff „side effects“ aber „Nebenwirkungen“. Schauen Sie mal auf eine englischsprachig Arzneimittelpackung, statt wegen „Wegen Risiken und Nebenwirkungen …“ steht dort …

Ein Pattern ist für die meisten Menschen eher ein Schnittmuster oder auch Schnittbogen, also etwas aus der Bekleidungsherstellung.

Betrachten wir das Thema aus dem Blickwinkel eines Schneiders: Eine Hose ist etwas „mit drei Löchern, ein grosses oben, zwei kleine, getrennte unten, besteht aus 5 Stücken plus einige Anbauteile“, oder eben der Zuschnitt für eine konkrete Hose. Wer versucht, eine Levis 501 zu kopieren, bekommt zurecht Probleme.

Die Hobby-Näherin kauft eine Zeitschrift mit Schnittbogen.
Der Mass-Schneider nimmt Mass und zeichnet mit Kreide die Umrisse auf den Stoff.
Der Schneider in der Industrie oder dem Zeitschriftenverlag erstellt einen Schnittbogen per CAD, dieser wird gedruckt oder steuert in einem fernöstlichen Land eine Zuschnitt-Maschine.

Die Anzahl der Pattern ist überschaubar, bei Bekleidung gibt es Hose, Rock, Hemd / Bluse, Jacke, … 

In der Informatik sind es vielleicht ein bis zwei Dutzend Pattern. Die ersten Autoren, die Bücher über Pattern schrieben, hatten die freie Auswahl, wer in den letzten 15 Jahren etwas schreiben wollte, und um zu verkaufen etwas Neues schreiben musste, erfand neue Pattern, zum Bespiel den „Hosenrock“, für einen Schneider „etwas mit drei Löchern, oben gross, unten relativ grosse Löcher,   die zusammengenäht sind, besteht aus 5 Stücken plus einigen Anbauteilen“, also eigentlich eine Hose, aber jetzt der neuste und beste Pattern aller Zeiten.

Ein Schneider und auch ein Informatiker lernen in der Ausbildung und den ersten Berufsjahren verschiedene Pattern kennen und benutzen sie später intuitiv situationsabhängig.

Den Schnittbogen „mit Namen“ braucht die Hobby-Näherin, oder der Informatiker ohne Erfahrung, und komischerweise kenne diese auch den Namen. Der Schneidermeister und auch der erfahrene Entwickler kennen diese Namen eher weniger

ORM bedeutet Object-Relational-Mapping.
Also geht es darum, Strukturen, die nach dem objektorientierten Paradigma erstellt wurden, in Relationale Strukturen zu mappen, oder sagen wir besser zu pressen.

Daten, und damit Datenstrukturen, leben sehr lang!
Vertragsdaten bis zu 30 Jahre nach Vertragende und es gibt Verträge, die 100 oder mehr Jahre bestehen können. 
Konstruktionsunterlagen, vor 50 Jahren ja noch meist auf Papier, heute in Datenstrukturen, müssen so lange lesbar sein, wie das Gerät im Einsatz und damit gewartet werden muss. Der US-Bomber B52 von Anfang der 1950ziger Jahre soll bis 2050 fliegen, ein Tunnel, der heute gebaut wird, wird hoffentlich über 200 Jahre halten. 

Der Objektorientierte Ansatz in der Informatik lässt sich zwar bis in die 1960ziger Jahre zurückverfolgen, aber eine kommerzielle Bedeutung hat er erst seit Anfang der 1990ziger Jahre. Es gibt einige andere Paradigmen in der Informatik, regelmäßig kommen neue Paradigmen hinzu, und ob in 20, 50 oder 100 Jahren der OO Ansatz immer noch als „das Beste“ gilt?

Das Relationale Modell ist sehr simpel, im Sinn von „genial simpel“. Es lässt sich gut auf Strukturen, die bei den verschiedenen Paradigmen genutzt werden, abbilden. Es lässt sich auch gut verstehen, aus den Strukturen der Tabellen, deren Indizes, deren Relationen kann der geübte Entwickler den Sinn einer Anwendung erkennen.

Objektmodelle sind meist komplexer, denn sie sollen schnell aus der komplexen Realität hergeleitet werden. Ein OO-Entwickler, der die entsprechende Programmiersprache beherrscht, kann auch den Sinn einer Anwendung erkennen, aber versteht ein Java-Programmierer ein Modell in Smalltalk? 

Geht es um einen zeitlich überschaubare Anwendung, zum Beispiel die Verwaltung eines Preisausschreibens, kennt der Entwickler Java, hat aber keine Ahnung von Datenbanken, steht die Time-To-Market im Vordergrund, ist der ORM Ansatz sicher gut, auch wenn es für solche Dinge sicher noch bessere Programmiermodell gibt, zum Beispiel „Ruby On Rails“.

Bei dem ORM Ansatz wird zuerst das Objekt-Modell erstellt und sicher auch im Lauf der Zeit weiterentwickelt. Hieraus werden dann regelmässig die Relationale Strukturen und die Zugriffsmodule generiert. Am Ende steht dann ein Relationales Modell, das nicht nur die Komplexität des Objekt-Modells, sondern auch dessen Entwicklungshistorie enthält.

Wenn dann, nach vielen Jahren, in denen die Anwendung stabil und ohne Wartungsaufwand lief, also kein spezielles Know-How für diese Anwendung mehr verfügbar ist, eine grössere Anpassung, vielleicht in einer neuen Programmiersprache in dem dann „besten“ Programmier-Paradigma, notwendig wird, versteht der Entwickler nur „Bahnhof“.

Dabei interessieren ihn wie auch die Anwender oder das Management nicht das alte Programm, interessant sind nur die Dateninhalt und wie sie weiter abgefragt und gepflegt werden können. 

Auch wenn es etwas mehr Arbeit ist, scheint es mir sinnvoll, zuerst ein für die Anwendung angemessenes Datenbank Design zu entwickeln, dieses dann mit Verstand und nicht mittels Automatik in ein Objekt-Modell zu transferieren und die Zugriffsschicht zu schreiben.

Damit sind wir bei ROM, aber die Abkürzung ist schon besetzt.

OLTP bedeutet „Online Transaction Processing“, also das Bearbeiten von Daten innerhalb von Transaktionen im Dialog. 

Damit gehören alle Dialog-Anwendungen, auf die mehrere Benutzer zugreifen können und die Datenbestände ändern, zu den OLTP Anwendungen. 

OLTP setzt eine entsprechende Middleware, den Transaktions-Monitor, voraus.
Hier sind zu nennen IBM IMS DC (z/OS), IBM CICS (primär z/OS), FSC UTM (BS2000), EJB und viele andere mehr. 

Eine Middleware Komponente stellt für die Ablage der Daten im Rahmen eines Transaktions Kontexts sicher, bei IBM IMS kann dieses die integrierte hierarchische Datenbank (oder DB2) sein, bei CICS oder UTM ist es meist die Datenbank (DB2 bzw. SESAM) des Herstellers und bei EJB kann (konnte?) es alles, inkl. dem Filesystem, sein. 

Exkurs Datenbanken:
Datenbanken, insbesondere mit der „Abfragesprache“ SQL, werden häufig als Tool gesehen, mit dem Datenbestände abgefragt werden können. Die Hauptaufgabe einer Datenbank ist jedoch das Speichern von Daten nach dem ACID Prinzip (Atomicity, Consistency, Isolation, Durability). 

Ermöglicht ein Transaktions-Monitor als Persistenz-Medium auch Nicht-ACID Medien, also zum Beispiel Flatfiles, egal ob einfach strukturiert oder als XML, im Filesystem, muss der Transaktions-Monitor ein ACID Verhalten selber sicherstellen, was zu einem massiven Aufblähen der Systemanforderungen und vor allem des Codierungsaufwands führt. 

Eine weitere Komponente, die ein Transaktions-Monitor benötigt, ist ein „Terminal“, also die Schnittstelle zum Benutzer, der die OLTP Anwendung nutzen. Neben den früher verwendeten IBM 3270 Terminal (ISPF) oder FSC 9750 (TransData) sind heute primär Microsoft Windows, die verschiedenen Java APIs (AWT, Swing, SWT) sowie HTML. 

Heute werden die OLTP Anwendungen meist auf mehreren Computer ausgeführt. Es sind neben dem Client der Präsentation-Server, Anwendungs-Server (EJB Container) sowie der Datenbank-Server. Häufig findet man noch mehrere Instanzen der Anwendungs-Server, die entweder identische Funktionalität besitzen oder auf bestimmte Bereiche spezialisiert sind. Um diese Rechner in einem Transaktions-Kontext miteinander zu verbinden, wird eine Message-Orientierte Middleware benötigt. Als Standard in der Java-Welt gilt JMS, konkrete kommerzielle Produkte sind zum Beispiel IBM MQ-Series, das die Grundlage für IBM WebSphere bildet und daher als IBM WebSphere MQ vermarktet wird oder Bea WebLogic, also eigentliche jeder EJB-Container. 

Von aussen betrachtet ist eine WebSphere oder eine WebLogic Installation vergleichbare mit einer IMS-DB/DC Installationen, es ist eine Lösung, die von der Bildschirm-Maske über die Transaktions-Logik bis zur Persitenz alles abdeckt. 

Ein weiterer am Markt weit verbreiteter Transaktions-Monitor, auch wenn man ihn als solchen kaum wahrnimmt, ist SAP R/3. Hier stehen die Business-Prozesse im Vordergrund, um sie sicher abbilden zu können, ist jedoch eine starke Middleware notwendig. 

Das „wer schreibt wann“ auf die Datenbank ist eine wichtige Unterscheidung zwischen den Möglichkeiten, ein OLTP System zu implementieren. Hier gibt es grundsätzlich zwei Möglichkeiten: 

Der Task, der die Benutzereingaben entgegen nimmt, schreibt auch auf die Datenbank.
Der Task, der die Benutzereingaben entgegen nimmt, übergibt sie (nach einer Vorprüfung) an einen asynchronen Bucher-Task.

Der asynchrone Bucher erhöht den Aufwand bei der Implementierung, so dass im klassischen Mainframe-Umfeld bei kleineren Installationen gerne hierauf verzichtet wird. EJB kennt auch keinen Bucher-Task, da nach der Definition Business-Objekte als Java-Objekte zwischen den einzelnen Komponenten ausgetauscht werden und bei Bedarf persistent abgelegt werden. 

Der Asynchrone Bucher sorgt aber für eine wesentlich bessere Skalierbarkeit der Anwendung. 

Da nur dieser eine Task, der sequentiell die fertiggestellten Benutzer-Interaktionen bearbeitet, auf die Datenbank schreiben darf, wird die Datenbank nicht mit der Verwaltung von Satzsperren überlastet. 

Die Datenbank ist die limitierende technische Komponente eines jeden OLTP Systems. Anwendungs- und Präsentation-Server können in beliebiger Anzahl parallel laufen, ein Datensatz bleibt jedoch ein Datensatz und muss deshalb in einer bestimmten Tabelle in einer bestimmten Datenbank vorhanden sein.
Durch die Entlastung der Datenbank erhöht man somit die mögliche Anzahl der Transaktionen pro Sekunde beziehungsweise die Anzahl der Online-Benutzer für eine (preiswerte) Hardware-Plattform. 

Dafür muss jedoch der Anwendungsentwickler für die Satzsperren auf logischer Ebene sorgen. Die Sperren können in einer Tabelle verwalten werden, es kann jedoch auch der „Update-Timestamp“ als Kennzeichen, ob ein Datensatz geändert wurde, verwendet werden.

Betrachtet man die IT Umgebungen bei grossen Unternehmen, findet man primär drei Programmier Sprachen.
Sicher gibt es noch einige weitere Programmiersprachen im Portofolio, weil entsprechende Anwendungen existieren und auch weiterentwickelt werden, bei Neuentwicklungen werden aber in der Regel COBOL, Java (oder in reinen Microsoft Umgebungen c#) und C (also c++ oder manchmal auch Objective-C) gewählt.

Die Sprachen unterscheiden sich in vielerlei Hinsicht.
COBOL wurde Anfang der 1960er Jahre, also zu Zeiten der Lochkarten, entwickelt. Die Anwendungsentwickler, die es vorher wohl noch nicht gab, sollte ein Werkzeug an die Hand gegeben werden um den Bruch zwischen der Person, die die Fachlichkeit versteht und der Person, die den Computer versteht, zu vermeiden.
C wurde Anfang der 1970er Jahre für die Implementation eines Betriebssystems (Unix) entwickelt.
Java sollte die aufkommende Beherrschung von Microsoft im Bereich der Anwendungsentwicklung verhindern und wurde von Herstellern von Unix Rechnern (SUN) entwickelt und von Herstellern von Mainframes (IBM) stark unterstützt.
c# war, nachdem Microsoft die Java Welt nicht spalten konnte, der Gegenentwurf zu Java.

Bei der Speicherverwaltung gibt es grosse Unterschiede. 

Der Speicher für die zur Laufzeit benötigten Variablen wird bei COBOL durch den Compiler, also schon sehr früh, festgelegt.
Dieses Vorgehen hat den Vorteil, dass eigentlich keine Speicherverwaltung benötigt wird, hier also nichts schiefgehen kann, es gibt also keine Speicher-Lecks, die ein System, das 24×7 laufen muss, zum Absturz bringen wird.
Und dieses ist auch der grosse Nachteil. Schon beim Programmieren muss festgelegt werden, welche Anzahl an Variablen (speziell in einem Array) benötigt wird, und die Erfahrung zeigt, dass irgendwann die Anzahl der benötigten Array-Elemente die Anzahl der definierten Array-Elemente übersteigt (ausser der Entwickler hat beim Design die notwendigen Vorkehrungen getroffen).

Bei Java gibt es eine automatische Speicherverwaltung. Wird zu Laufzeit ein Array-Element (in einer ArrayList oder einem Vector) zusätzlich benötigt, stellt Java den Speicherplatz zur Verfügung. Und wird der Speicherplatz nicht mehr benötigt, räumt Java den Speicher wieder auf. Diese Automatik funktioniert sehr gut, kostet aber Ressourcen, insbesondere Laufzeit, was bei grossen Servern zum Problem werden kann. Da das Aufräumen in einem eigenen Thread („Faden“ der Programmausführung) läuft, der nur Rechenzeit erhält, wenn der Computer meint, die notwendige Zeit zu haben, kann sich bei einem stark ausgelasteten Server ein grosser „Haufen“ an nicht aufgeräumten Speicher ansammeln, was auch zu Problemen führen kann.

In C, c++, Objective-C verwaltet der Programmierer den Speicher selbst. Er kann bei Bedarf Speicher anfordern und muss ihn, wenn der Speicher nicht mehr benötigt wird, freigeben. Wird der Speicher nicht freigegeben, entsteht ein Speicher-Leck. Nun sind Programm meist nicht so trivial „Speicher anfordern, etwas tun, Speicher freigeben“, so dass hier ein besonderes Augenmerk notwendig ist. Bei eher technischen Programmen, Betriebssystemen, einer Textverarbeitung ist dieses möglich und die notwendigen Test sind planbar. Was ist aber in einem ERP System bei der Erweiterung der Stücklisten-Verwaltung (welche Teile werden benötigt, um einen PKW zu bauen? Motor, … Welche Teile werden benötigt um einen Motor zu bauen? …)? Hier kann eine kleine Erweiterung (5 Zeilen), für die eine Stunde Arbeitszeit eingeplant ist, durch ein Speicher-Leck in einer aufgerufenen Funktion das gesamte ERP System zum Absturz bringen.

Was für den Speicher gilt, gilt entsprechend auch für andere Ressourcen, die von Programmen benötigt werden.

Da C für die Entwicklung von Betriebssystemen geschaffen wurde, gibt es dem Programmierer Möglichkeiten an die Hand, die der erfahrene Entwickler bewusst und mit der notwendigen Umsicht nutzt. Der unerfahrene Entwickler, oder auch der Entwickler unter Zeitdruck, können diese Möglichkeiten nutzen mit dem Ergebnis „es läuft ja“. Die Probleme treten dann später zu Tage.

C sollte also in der Anwendungsentwicklung nur in besonderen Fällen genutzt werden, oder um bestimmte Funktionen für andere Programmiersprachen zur Verfügung zu stellen.

Bleiben also Java und COBOL. Bei „Time-to-Market“ ist Java deutlich besser, sonders bei der Entwicklung von Benutzer-Oberflächen. Komplexe fachliche Zusammenhänge lassen sich in Java deutlich besser beschreiben. Es gibt also keinen Grund auf COBOL zu setzen? 

Geht es um einen 24×7 Betrieb (der ja meist einen ausfallsicheren Computer, also eine Mainframe erfordert) und um einen hohen Durchsatz, rechnet sich der Einsatz von COBOL. 

Es können auch beide Methoden kombiniert werden, zum Beispiel das GUI und der Work-Flow in Java, aber die Speicherung der Daten inklusive der Valdierung vor dem Speichern in COBOL. Aber dieses erfordert an der Schnittstelle einen Entwickler, der in beiden Welten zu hause ist.

Weiter oben schrieb ich von den unterschiedlichen Design zwischen einer Java und einer COBOL Anwendung. Die Phase der Analyse kann (und sollte) in OOA geschehen. Beim Design (OOD) muss dann abgebogen werden. 

Als Beispiel soll in Vorbereitung auf ein Kundengespräch die Kontaktdaten mit der Telefonnummer, unter der der Kunden zu dem gewünschten Zeitpunkt erreichbar ist, ausgedruckt werden. OOA sagt, man braucht die Daten des Kunden, diese sind aufbereitet zu drucken. 

OOD für Java bedeutet „Kunde = x.getKundenDaten(KundenNummer)“ und „Kunde.printKundenNameMitTelefon( Datum, Uhrzeit)“. 

Für COBOL bräuchten wir die Information, wieviele Telefonnummern kann ein Kunde haben, um ein passendes Array zu definieren. Die Erfahrung zeigt, dass es immer einen Kunden geben wird, der eine Telefonnummer mehr hat, oder wir definieren, ein Kunden kann 1000 Telefonnummern haben, was auch nicht sinnvoll ist. Also nutzt uns das Objekt „Kunde“ mit einer unbekannten Anzahl an Telefonnummern nichts. Deshalb wenden wir das EVA-Prinzip (Eingabe, Verarbeiten, Ausgabe) an, lesen also nicht alles ein und verarbeiten das komplette Objekt, sondern lesen einzelne Datensätze, verarbeiten diese und geben sie aus. „holenKundenName(KundenNummer)“, „holenTelefonnummer(KundenNummer, Datum, Uhrzeit)“ und „druckeDaten()“.