Vermeide Random, verwende stattdessen SecureRandom

Random ist nicht wirklich zufällig, wenn zwei aufeinanderfolgende Zufallszahlen bekannt sind, können alle weiteren erraten werden. Dumm nur, wenn ein Hacker darauf spekulieren kann …

Vertraue keiner externen Quelle, insbesondere keinen Eingaben des Anwenders

Im einfachsten Fall sprechen wir von Texteingaben, es betrifft aber RSS-Feeds, Emails usw. Nach Analyse von (öffentlichen) Sicherheitsmeldungen konnte ein schlauer Mensch ca. 60% der Fehlfunktionen auf fehlende Überprüfung der Eingabe klassifizieren - vielleicht mag ja jemand mal die Quelle nachreichen. Aus der Erfahrung von Bruce Sams heraus können die meisten Sicherheitsprobleme in Webanwendungen dem Datenfluss zugeordnet werden, genauer der ungenügenden Validierung von Eingaben und anderen externen Quellen. Das deckt sich mit meiner Erfahrung, dass die meisten Probleme in Webanwendungen durch “komische” Eingaben erzeugt werden.

Lösung: Versuche möglichst nicht, die Daten im nachhinein zu validieren, sondern bestimme genau, was zulässig ist, und was nicht. Was an der Oberfläche abgefangen werden kann, sollte da auch abgefangen werden. Vertraue der Oberfläche aber nicht bedingungslos, genau die kann in Webanwendungen manipuliert werden.

Überprüfe Deinen Code

Die offensichtlichsten Probleme im Code lassen sich auch durch statische Analyse finden. Bevor also eine umfassende Datenflussanalyse durchgeführt wird, oder zumindestens ganz wilde Eingabetests, lasse Tools wie FindBugs und JDepend auf den Code los. Ich selber mag z.B. auch Checkstyle sehr gerne.

Ergänze dies durch JUnit-Tests, und zwar mit zufälligen Eingaben, mit Überprüfung der offensichtlichen Grenzbereiche (wie z.B. gar keine Eingabe und überlange Eingabe), sowie mit allen behobenen Fehlerfällen. Wichtig: Jeder behobene Fehler sollte wirklich in einem JUnit-Test landen, sonst kommt er irgendwann einmal wieder.

Why OSGi (Open Services Gateway Initiative) ?

1. Wire components together, not only beans or such
2. Manage these components

What is OSGi?

In this case not the alliance but the specification and the API for a component framework - actually it is a SPI including the test cases. You can feel free and provide your own implementation - the interfaces are all in Java. You might have heard of Equinox as the Eclipse implementation.

What does it have in stock for you?

• Register services (which are basically interfaces)
• Bind implementations to a service
• Find a service (or more precisely the bound implementation)
• Listeners on service binding and unbinding

Component Life Cycle

1. install
2. start
3. stop
4. update
5. uninstall

You can react on any life cycle update and do what you need to do, e.g. allocate a connection pool on install, free it on uninstall, etc.

Kaum ein Vortrag, wo kein Mac OS die Folien beisteuerte, das Verhältnis war gefühlte 60% Apple und 40% Windows.

Interessant aber dass der Apple auch außerhalb der Vortragsnomaden seinen Siegeszug hält, ob in der Lobby oder sonstwo. Nur die Aussteller hatten mehrheitlich auf Windows gesetzt. Nun ja, viele spannende Themen laufen halt auch auf der Kommandozeile ab, vor allen die Skriptsprachen wie Ruby On Rails, Groovy, etc. Und der Apple hat halt neben dem richtig schönen und schnellen grafischen Desktop immer sofort ein Terminal parat.

Übrigens: Auf meinem Rechner läuft auf Kundenwunsch weiterhin Windows XP … man darf doch wohl noch träumen.

Domain Driven Design - Entwurf getrieben von den fachlichen Anforderungen

Warum?

Weil die Fachlichkeit i.d.R. die Aspekte sind, die am längesten stabil bleiben bzw. sich am wenigsten verändern um die sich letztendlich alles dreht. Beispiel: Die Kontonummer eines Kunden hat immer Bestand, egal welche Anwendung darauf zurückgreift. Aus Erfahrung wissen wir auch, dass Daten stabiler als Methoden sind, d.h. Artikel werden seit Jahren immer auf die gleiche Weise abgelegt, egal ob die Zugriffssoftware in COBOL oder Java erstellt wurde.

Was sagen die Vortragenden?

“Einige Dich auf eine Sprache!” - das ist das eigentliche Motto. Domain entspricht hierbei der Fachlichkeit bzw. dem Fachwissen, und zwar explizit nicht der technischen Sicht. Domain Driven heißt hierbei Orientierung am Anwender, also wird alles von der fachlichen Ebene getrieben, nicht von der technischen Umsetzung.

Die Modelle bzw. der Code sollte die Sprache der Fachanwender wiederspiegeln, damit die Anwender direkt mit den Entwicklern sprechen können und ein gemeinsames Verständnis der Begriffe vorhanden ist, auch im Hinblick auf spätere Änderungen und Fluktuationen.

Orientiere Dich in der technischen Umsetzung immer an der Unterstützung der fachlichen Anforderungen, und Deine Codebasis wird stabiler und einfacher sein, sowohl in der Entwicklung als auch in der Wartung, selbst wenn die Anwendung skaliert.

Tipps und Tricks

1. Mache die Domain Objects (Geschäftsobjekte) als auch die Business Logic (Geschäftslogik und -prozesse) explizit, bündele sie und denke an die entsprechende Benennung! Factories, Composites, Strategies helfen hier.
2. Domain Driven Design ist eine notwendige Voraussetzung für Model-Driven Software Development (MDSD), da sonst keine (stabile) formale Spezifikation möglich ist.
3. Domain Driven Design ist hilfreich für Extreme Programming (XP), legt aber mehr Wert auf Dokumentation und kann auch in großen Projekten von großem Nutzen sein.
4. Änderungen im Domain Model (sowie in der Domain) sind teuer, lohnen sich aber immer. Verschleppung ist noch teurer, und zwar exponential.
5. Partionierung der Domains ist ein gutes Mittel, insbesondere um die Kerndomäne herauszuschälen und die logisch Domänen zu trennen und damit beherrschbar zu machen.
6. In großen Projekten muss die Kerndomäne identifiziert werden und kurz und prägnant beschrieben werden, am besten in Form eines “Vision Statements”.

Ach so: Alle Eindrücke und Zusammenfassungen sind höchst subjektiv und nie ein Zitat … so haben die Herren und Damen es vorne garantiert nicht gesagt, so hat der Autor es verstanden und wollte es so verstehen.

Danke für die Nachsicht!