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?

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.

Denn dieses Bild wurde mit Terragen gerendert.

Meiner 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.

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.

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.

Eine wirklich gelungene Werbung …

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.

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.

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…

 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	}

 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>

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

 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	}

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

 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>