Das TAO des Konfigurationsmanagement

Kommt es zur Technik gelten in der Softwaretechnik vermutlich zwei Maxime:

Es gibt nichts Wichtigeres als die Auswahl einer stabilen technologischen Basis für die Entwicklung. Der Einsatz neuer Technologien steht dem entgegen. Gleichzeitig gilt jedoch: Es gibt nichts Wichtigeres als den Erhalt von Anpassbarkeit und Erweiterbarkeit eines Systems. Dies beinhaltet die Erneuerung oder den Austausch von eingesetzten Technologien und destabilisiert jede stabile technologische Basis.

Jeder Techniker trägt diesen Kampf in sich aus. Ständig suchen wir aufs Neue die Balance zwischen dem Wunsch nach stabiler, vorhersehbarer Softwareentwicklung und der Veränderung von Umgebung, Anforderungen und Rahmenbedingungen.


Welche Bücher sollte ein Informatiker gelesen haben?

Hiermit komme ich der Bitte nach, ein paar Buchempfehlungen zu geben, die man als praktischer Informatiker gelesen haben sollte. Es gibt tolle theoretische Bücher oder Grundlagenwerke. Es gibt Bücher, die sich eher auf Projektmanagement beziehen. Und es gibt Bücher, die sich auf das Selbstverständnis und das Handwerkszeug beziehen.

Es fällt mir schwer, meine persönliche Top 10 zusammenzustellen. Bemerkenswert ist, wie alt die wertvollen Bücher im Schnitt sind… Hier ist die Liste der nicht spezifischen Bücher, die sich eher mit zeitlosen Themen befassen:

* Code Complete
* Pragmatic Programmer
* Mythos des Mann-Monats
* Objektorientierte Softwareentwicklung Analyse und Design mit UML 2.0
* Refactoring
* Extreme Programming
* Business Components Factory
* Analysis Patterns
* Programming Pearls
* Release It

Eigentlich müsste man natürlich noch The Art of Computer Programming aufführen, allerdings kenne ich nur einen der das Buch lesen und durcharbeiten kann. Die anderen Menschen, die ich kenne, sind nicht bereit dazu, sich mit der hohen Informationsdichte und Komplexität auseinander zu setzen.

Darüber hinaus könnte man noch ein paar hervorragende Programmiersprachen-spezifische Bücher aufführen, die sicherlich einen Platz in der Top 10 einnehmen könnten. Meine Liste der tollen Management-Bücher habe ich vor gut zwei Jahren vorgestellt: Empfehlung zu Management-Büchern

Preisfrage: Welches der obigen Bücher sollte man mit ganz großer Vorsicht lesen und besser noch doppelt und dreifach darüber sinnieren?


Die Architektur des Webs ist gescheitert

Das Internet, das wir alle kennen und täglich nutzen, durchdringt nicht nur den Alltag immer stärker sondern findet durch eine Bewegung anerkannter IT-Experten immer größere Beachtung. Bis vor kurzem wurde stark bezweifelt, dass die für das Internet verwendeten Dienste und Anwendungen ausreichen könnten, um ernsthafte Geschäftsanwendungen zu realisieren. Selbstverständlich sah man lange Zeit in Amazon, Google und Co. die obligatorischen Ausnahmen, die für einige aus diesem Zweifel eine Regel machten.

Dank technisch versierter Experten wie Fielding, Tilkov oder Vinoski wird mittlerweile auch den Anhängern der klassischen Unternehmens-IT-Disziplinen klar, welche Vorzüge in dem Architektur-Stil des weltweiten Datennetzes (des World Wide Webs) stecken. Rhethorischen Fragen a la “Warum findet man mit einer Internet-Recherche mehr Informationen über einen bestehenden Vertrag mit einem Vertragspartner als in Eurer Bestandsführung?” treffen einen Nerv und decken architekturelle Schwächen gängiger Unternehmensanwendungen auf.

Dennoch: Gerade in einer Zeit, die das Zusammenbrechen technischer Barrieren verspricht, gefährdet eine aktuelle Entdeckung den Fortbestand des Internets, wie wir es kennen. Die IP-Adressen - sozusagen die Telefonnummern des Internets - sind aus.

Ohne eine flächendeckende Umstellung auf das neue Protokoll IPv6 wird das Internet nicht mehr lang funktionieren. Der selbst ernannte IT-Experte und System-Analytiker, Max Mustermann, prognostiziert einen Zusammenbruch innerhalb der nächsten 2 hoch 128 Tage. Es bleibt also weniger Zeit als gedacht.

Darüber hinaus führt eine kürzlich entdeckte Lücke in der Spezifikation des Internets (nachzulesen unter ietf.org) in letzter Konsequenz dazu, dass jeder Nutzer eines herkömmlichen Web-Browsers sich angreifbar macht und was noch schlimmer ist, selbst unbeabsichtigt zu einem Angreifer für Internet-Angebote werden kann. Die Angriffsform ist auf Neu-Deutsch unter dem Akronym CSRF (wie sea-surf) bekannt. ZDNet sagt dazu unter Anderem:

In either case, the browser executes a malicious transaction such as a wire transfer to the cybercrook’s bank.

Frei übersetzt bedeutet dies: Man kann hier von einem immer schnelleren Verbrauch der jetzt schon kaum mehr verfügbaren IP-Adressen ausgehen. Schuld daran ist die Architektur des Webs - genannt REpresentational State Transfer - oder kurz: REST.


Wenn ich dort wäre…

… dann wäre ich wohl ein 3D-Avatar.

Seen-Landschaft, umgeben von Bergen

Denn dieses Bild wurde mit Terragen gerendert.


Informationsdichte in Texten

Da habe ich am Mittwoch auf der OOP-Konferenz Tom DeMarco gehört. Er hat allen Ernstes gesagt, dass er die Texte eines Kollegen dadurch verbessert, indem er sinnlose Füllsätze einfügt. Dessen Texte seien sonst immer so dicht mit Informationen gepackt, dass man beim Lesen zu viele davon überliest. Durch die Füllsätze bekomme das Gehirn Zeit, alle Informationen zu verdauen.

Das Prinzip der PyramideMeiner Ansicht nach sollte man auf Füllsätze verzichten und Informationen kurz und präzise darstellen. Die Form eines Textes so anzupassen, dass auch einem unaufmerksamen Leser darin enthaltene Kernpunkte auffallen, sollte meiner Meinung nach durch sinnvolle Übergänge und Erläuterungen erfolgen. Sinnlose Füllsätze haben da nichts zu suchen. Frau Minto beschreibt in ihrem Buch Das Prinzip der Pyramide, wie man seine Informationen klar strukturieren kann.


Projektrisiko: Google Driven Software-Architecture

Es ist allgemein bekannt, dass das Not-Invented-Here-Syndrom (NIH) zu einem Projektrisiko werden kann. NIH veranlasst Menschen dazu, anstatt bestehende Lösungen zu verwenden lieber alles selbst zu realisieren.

In Projekten ohne jede Restriktion gibt es allerdings ein anderes Risiko, dass ich Google Driven Software-Architecture nennen will. Im Gegensatz zu NIH stellt man sich gern auf die Schulter von Giganten. (Auch wenn viele Dinge im Internet eher den Nutzen von Teppichkanten anstatt von Giganten bringen…)

Als Google Driven Software-Architecture bezeichne ich das Bestreben, bereits existierende Problemlösungen (in Form von Werkzeugen, Plattformen, Bibliotheken oder Frameworks) für die eigenen Zwecke einzusetzen, ohne allerdings das Kosten/Nutzen-Verhältnis genügend zu bewerten.

Anstatt also zuerst in einer isolierten Umgebung zu experimentieren, um zu lernen, wie Pragmatik und Philosophie der potenziellen Teillösung wirklich sind und welche Abhängigkeiten und Konsequenzen sich durch einen Einsatz ergeben, wird es erst einmal eingesetzt. (Klingt recht willkürlich agil…)

Neben Fragen zu juristischen Konsequenzen (falls eingesetzte Teillösungen nicht richtig lizensiert sind) handelt man sich damit schneller einen Zoo von Abhängigkeiten ein, als einem lieb sein kann. Mit Google Driven Software-Architecture richtig eingesetzt kann man sich kontinuierlich mit dem Lernen neuer Probleme und dem Finden entsprechender Lösungen beschäftigen, die alle nichts mit der Erreichung des Projektziels zu tun haben.

Mein Plädoyer lautet daher genau zu prüfen, welche Konsequenzen sich aus dem Einsatz von vermeintlichen Lösungen ergeben und dies für den eigenen Kontext zu bewerten. Der Verzicht auf den Einsatz von vermeintlichen Lösungen ist manchmal sinnvoll.


Der Von-Neumann-Flaschenhals und das Test-Orakel

Ist es nicht bemerkenswert, wie sich manche Dinge materialisieren, obwohl sie nur eigentlich nur konzeptionell existieren? - Zwei kleine Beispiele sollen dies veranschaulichen …

Obwohl die Von-Neumann-Rechnerarchitektur aus Steuerwerk, Rechenwerk, Hauptspeicher für Programm-Code und Daten sowie einem Bus und I/O-Einheit besteht, kursierte vor Jahren an meiner Hochschule das Gerücht, dass es eine weitere Kernkomponente zu dieser Architektur gibt: den Von-Neumann-Flaschenhals.

Der Von-Neumann-Flaschenhals muss ein fieses kleines Bauteil der Rechnerarchitekturen gewesen sein, der einen wesentlichen Teil des Optimierungspotenzials der Rechnerarchitektur zentralisierte.

In ähnlicher Weise materialisierte sich ein weiteres (eher konzeptionelles) Element: Bei einigen Studenten der FH-Do hat sich herumgesprochen, dass es eine generische Software-Komponente gibt: das Test-Orakel.

Dieser idealer Weise zu kaufende Baustein einer jeden automatisierten Software-Testumgebung löst alle Probleme des täglichen Lebens. Wir haben schon in dem Film Matrix gesehen, dass Orakel nicht nur dazu geeignet sind, die aktuelle Funktionsweise eines Software-Teils zu erkennen, sondern auch wage Andeutungen über dessen Potenzial anzubieten.

Diesen eher komischen Anekdoten kann man etwas Ernstes entnehmen: Hören-Sagen tradiert auch heute Wissen und Erfahrung. Die meisten lassen sich allerdings viel zu häufig in relevanten Teilen von unqualifizierten Informationen leiten. Wie viele bezeichnen sich als Experten für ein beliebiges X und kennen nicht einmal jemanden, der die Spezifikation von X gelesen hat.


Kinder, nehmt Euch in Acht!

Es scheint Euch an den Kragen zu gehen, Ihr kleinen, süßen Racker. Fight for Kisses kündet vom Zweikampf der Generationen um die Gunst unserer Frauen und Mütter. Herr der Ringe, Rocky, Matrix, Mortal Kombat und Karate Tiger treffen Ödipus…

Eine wirklich gelungene Werbung …


Mit Geronimo herumgespielt (Teil 1)

Da ist gerade Ruby on Rails Version 2.0 freigegeben und ich schreibe etwas über Java EE, obwohl ich mich schon darauf freue, die Rails-Unterstützung des iPhones auszuprobieren….

Ich habe in den vergangenen Jahren Erfahrungen mit verschiedenen Applikationsservern gesammelt. Um zu sehen, was der aktuelle Apache Geronimo kann, habe ich mal ein wenig damit herum gespielt.

Meine Experimente unterteile ich in drei Teile:

  1. Ein Durchstich (erledigt)
  2. Verwendung in der Entwicklung / Hot deployment und Entwicklung mit Exploded-Verzeichnissen (erledigt)
  3. Austesten der Persistenz-Engine

Eigentlich sollte sich noch ein vierter Teil anschließen: Last- und Dauerlasttests. Allerdings würde dieser Nutzungsszenarien und implementierte (Fach- bzw. Prozess-)Logik erfordern, um ein für meine typischen Szenarien aussagekräftiges Ergebnis zu liefern, da ich unterstelle, dass Geronimo grundsätzlich skalierbar und stabil ist.

Der Durchstich

Ich habe mit einem minimalen Durchstich begonnen. Dazu habe ich eine Reihe von Projekten in meiner Entwicklungsumgebung angelegt. Die Abhängigkeiten sind so in in der folgenden Abbildung dargestellt.


Die Projektstruktur

Abbildung 1. Die Projektstruktur.

Weiter habe ich dann ein paar Klassen geschrieben, die für einen kleinen Durchstich nötig waren. Die nächste Abbildung zeigt die beteiligten Klassen.


Die Projektstruktur

Abbildung 2. Die Projektstruktur.

Die Entitäten werden zwar nur von der Management-Komponente bearbeitet allerdings als Transferobjekte auch an die Web-Schicht übergeben. In den folgenden Abschnitten stelle ich auszugsweise die Implementierungen vor. Dabei habe ich mich auf den Fall Partner anlegen beschränkt. Die Ausgabe der Antwortseiten mittels einfachen JSPs habe ich ausgelassen…

Folgende Auszüge von Java-Klassen erwarten Sie:

sowie die erforderlichen Konfigurationen:

Die Web-Schicht

Dank Java EE und insbesondere der Servlet-API 2.5 kann man EJBs in Servlets injizieren lassen. Einerseits spart man sich den Lookup und andererseits sind Home-Interfaces obsolet.
Die Zeilen 3 und 4 in Listing 1 deklarieren ein Attribut, dass annotiert ist und die Client-Sicht (das Local-Interface) der gewünschten EJB injiziert bekommt. Zwar kann man auf die EJB nun direkt über das Attribut zugreifen, allerdings empfehle ich hier immer den Zugriff über einen Getter, da man auch nachträglich ohne viel Aufwand Anpassungen machen kann, wenn man beispielsweise das Servlet doch in einem Kontainer deployen muss, der nur Servlet-API 2.4 unterstützt und daher das Einweben von EJBs nicht funktioniert. Aus Darstellungsgründen habe ich den Getter hier weggelassen…

 1	public class PartnerServlet extends HttpServlet {
 2
 3	    @EJB( beanName = "ejb/PartnerService")
 4	    PartnerServiceLocal partnerService;
 5
 6	    protected void doGet(HttpServletRequest request,
 7	           HttpServletResponse response)
 8	           throws ServletException, IOException
 9	    {
10	        // ...
11	    }
12
13	    protected void doPost(HttpServletRequest request,
14	            HttpServletResponse response)
15	            throws ServletException, IOException
16	    {
17	        // ...
18
19	        partnerService.partnerAnlegen(
20	            createPartnerFor(
21	            request.getParameterMap()));
22	        response.sendRedirect( "/partner/" );
23	    }
24
25	    private Partner createPartnerFor(Map values) {
26	        //...
27	    }
28	}

Listing 1. PartnerServlet (mit eingewebter EJB)

 1	<?xml version="1.0" encoding="UTF-8"?>
 2	<web-app xmlns="http://java.sun.com/xml/ns/javaee"
 3	    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 4	    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
 5	    http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
 6	    version="2.5">
 7
 8	  <servlet>
 9	    <servlet-name>partner</servlet-name>
10	    <servlet-class>
11	      de.ghadir.partner.web.PartnerServlet
12	    </servlet-class>
13	  </servlet>
14
15	  <servlet-mapping>
16	    <servlet-name>partner</servlet-name>
17	    <url-pattern>/</url-pattern>
18	  </servlet-mapping>
19
20	  <ejb-local-ref>
21	    <ejb-ref-name>ejb/PartnerService</ejb-ref-name>
22	    <ejb-link>ejb/PartnerService</ejb-link>
23	  </ejb-local-ref>
24	</web-app>

Listing 2. web.xml konfiguriert das PartnerServlet und die lokale Referenz auf PartnerService

PartnerManagement - die Session-Komponente

Die PartnerManagement-Komponente realisiert alle Anwendungsfälle im Zusammenhang mit der Entität Partner. Über eine Menge von Session-Beans können Bearbeitungs-Prozesse realisiert werden und verschiedenen Clients zur Verfügung gestellt werden. In dem Durchstich sind vorerst die einfachen Lebenszyklus-Methoden für zwei Entitäten realisiert. In Listing 3 und Listing 4 wird stellvertretend der Fall Partner anlegen dargestellt.

1	@Local
2	public interface PartnerServiceLocal {
3
4	    void partnerAnlegen( Partner p );
5
6		// ...
7	}

Listing 3. Lokale Client-Sicht von PartnerService

 1	@Stateless( name="ejb/PartnerService")
 2	public class PartnerServiceBean
 3	        implements PartnerServiceLocal
 4	{
 5
 6	    @PersistenceContext( name = "partnerPU" )
 7	    EntityManager em;
 8
 9	    public void partnerAnlegen( Partner p ) {
10	        em.persist( p );
11	    }
12
13		// ...
14	}

Listing 4. Bean-Implementierung von PartnerService

Entitätskomponente Partner

 1	@Entity
 2	public class Partner {
 3
 4	    @Id
 5	    @GeneratedValue
 6	    private long id;
 7
 8	    // ... Attribute etc. ...
 9
10		// ...
11	}

Listing 5. JPA-Entität Partner

 1  <?xml version="1.0" encoding="UTF-8"?>
 2  <persistence
 3      xmlns="http://java.sun.com/xml/ns/persistence">
 4    <persistence-unit name="partnerPU">
 5      <description> ... </description>
 6      <provider>
 7        org.apache.openjpa.persistence.PersistenceProviderImpl
 8      </provider>
 9      <class>de.ghadir.partner.entities.Partner</class>
10  	    <properties>
11        <property name="openjpa.ConnectionURL"
12          value="jdbc:derby:PartnerDB" />
13        <property name="openjpa.ConnectionDriverName"
14          value="org.apache.derby.jdbc.EmbeddedDriver" />
15        <property name="ConnectionUserName" value="app" />
16        <property name="openjpa.jdbc.SynchronizeMappings"
17          value="false" />
18      </properties>
19    </persistence-unit>
20  </persistence>

Listing 6. persistence.xml

Hot-Deployment / Exploded

Leider kann ich noch keine Aussage darüber treffen, wie Apache Geronimo mit großen Enterprise Anwendungen zurecht kommt. Aber für meine Experimente funktionierte das Hot-Deployment sehr gut.

Anpassung an Komponente Hot-Deployment
Entitätskomponente Partner als Teil der anderen Komponenten
EJB-JAR PartnerManagement funktioniert
WebApp PartnerWeb funktioniert

Tabelle 1. Hot-Deployment und Exploded-Modus

Fazit

Die Entwicklung mit dem Geronimo Server funktioniert sehr gut. Der Entwicklungszyklus ist dank des Hot-Deployment kurz. Die Unterstützung der aktuellen Java EE Standards erleichtert die Entwicklung ungemein. Ich freue mich schon, die Persistenz-Engine in Bezug auf Beziehungen (einschließlich verschiedener Lade- und Speicherstrategien), Query-Hints, Aggregationen und Co. auszuprobieren.


Präsentieren - Fakten oder Ideen vermitteln?

Zu dem Beitrag Die zehn Teilbereiche der Software-Technik habe ich einige wertvolle Kommentare erhalten.

Buch Made to Stick

Bei dem letzten Punkt möchte ich anknüpfen.
Die Grundidee von SUCCESs ist einfach: Ideen müssen so aufbereitet werden, dass sie merkwürdig sind (den Ausdruck habe ich von Gedächtnistrainer Oliver Geisselhart):

  • Simple (einfach)
  • Unexpected (unerwartet)
  • Concrete (konkret)
  • Credible (glaubwürdig)
  • Emotional
  • Stories (Geschichten [enthalten])

Foliensatz zur Gettysburg-Rede Abraham Lincoln hat in seiner Gettysburg Rede (Englisch) der gefallen Soldaten gedacht. Es heißt, die Rede war eine der größten der amerikanischen Geschichte. Peter Norvig hat die Fakten dieser Rede genommen und zeigt wie sie mit Hilfe von Powerpoint hätte aufgewertet werden können, wenn man im 19. Jahrhundert nur Powerpoint zur Verfügung gehabt hätte.

Vermutlich nehmen die Amerikaner in ihrer Schulzeit die Gettysburg Rede durch, wenn sie den Sezessionskrieg behandeln. Vermutlich hat die Präsentation deshalb auch großen Anklang in der Presse gefunden.

Ein fahler Beigeschmack bleibt aber schon: Viel zu viele von uns tendieren dazu, Ihre Präsentation eher am Stil der obigen Powerpoint-Präsentation auszurichten als an den großen Reden der Weltgeschichte. Um wieviel erfolgreicher könnten wir also sein, wenn unsere Zielgruppe aus lebenden, fühlenden und denkenden Menschen bestünde anstatt aus gleichgültigen, rein sachlich orientierten Organismen vom Planeten Vulkan? - Wir präsentieren doch sowieso meistens vor den Ersteren.