Enterprise Software Development Software-Architekturen für Unternehmenslösungen

Transkript

1 Enterprise Software Development - Software-Architekturen für Unternehmenslösungen Eine Ausarbeitung für das Wahlpflichtfach Werkzeuge der Softwareentwicklung im Studium der Allgemeinen Informatik WS05/06 der FH Köln, Campus Gummersbach Nils Liebelt Matrikelnr Sanjay Jena Matrikelnr Sanjay Jena; Nils Liebelt 1

2 Inhaltsverzeichnis 1Einleitung Grundlagen moderner Enterprise Software Architekturen Anforderungen an Software-Architekturen Design Gesichtspunkte Verteiltes System vs. nicht verteiltes System Strategien für den Zugriff auf Daten Entity Beans Java Data Objects Weitere O/R Mapping Lösungen JDBC State Management Layering Drei-Schichten-Architektur Ausführungsort der Layer Moderne Entwurfsmuster Inversion of Control Dependency Injection Aspektorientierte Programmierung Agile J2EE Einführung J2EE Probleme mit den traditionellen J2EE Ansätzen Lightweight Frameworks Spring Framework Spring Module im Überblick IoC Container AOP Framework Abstraction Layer Weitere Integrationen...21 Sanjay Jena; Nils Liebelt 2

3 1 Einleitung Diese Ausarbeitung beschäftigt sich mit den aktuellen Technologien zur Entwicklung von Enterprise Software. Unter Enterprise oder Business Software, zu Deutsch Unternehmenssoftware, verstehen wir jede Art von Software, welche in Organisationen und Unternehmen genutzt wird. Die Entwicklung von Unternehmenssoftware ist durch zwei Kriterien geprägt: Dem Zeitdruck, unter welchem die Software erstellt werden muss, und das häufig enge Budget, unter welchem entwickelt wird. Diese beiden Kriterien, sowohl begrenzte Zeit als auch begrenzte Mittel, haben die Nutzung von Werkzeugen, welche uns gewisse Rahmen für die Anwendungen und Lösungen für häufig auftretende Probleme bieten, üblich und unerlässlich gemacht. Diese Ausarbeitung soll einen Überblick über die heutigen Standardwerkzeuge und Programmierprinzipien geben, welche sich in den letzten Jahren sehr stark dem Bedürfnis des Einsatzes im Netz angepasst haben. Im ersten Teil werden Grundsätze der Softwareentwicklung, wichtige Kriterien beim Entwurf von Anwendungssystemen sowie die am häufigst verwendeten Technologien diskutiert. Im zweiten Teil werden diese theoretischen Ansätze dann anhand von praktischen Beispielen und konkreten Technologien erläutert. Sanjay Jena; Nils Liebelt 3

4 2 Grundlagen moderner Enterprise Software Architekturen 2.1 Anforderungen an Software-Architekturen Aufgrund der Abhängigkeit von Unternehmen in Bezug auf Software, wird dieser heutzutage eine zentrale und höchst relevante Rolle zugesprochen. Heutige Systemarchitekturen müssen daher folgenden Anforderungen genügen: Robustheit Software ist wichtig für Unternehmen. Sie unterstützt die Mitarbeiter in vielen Prozessen und Abläufen und ist schon fast ausnahmslos essentieller Bestandteil einer jeden Arbeitsumgebung. Inkorrektheit oder gar Ausfall einer Unternehmenssoftware folgen in einer Störung des Arbeitsflusses und sind somit für Unternehmen nicht zu tragen. Zuverlässigkeit eines Programms und qualitativ hochwertiger Code sind daher unerlässlich. Performanz und Skalierbarkeit Von Unternehmensanwendungen erwartet man schnelle Antworten. Als stetig genutzte Software würden sich Wartezeiten schnell aufsummieren. Da die Anwendungen in der Regel einer grossen Anzahl von Mitarbeitern oder Kunden zur Verfügung stehen sollen, ist die Skalierbarkeit in Bezug auf die Anzahl der Nutzer und das Verhalten der Anwendung auf eine solche Last ein wichtiges Kriterium. Objektorientiertheit Das Rad nicht neu erfinden - Nach wie vor gilt diese Weisheit. Das Nutzen objektorientierter Entwurfsprinzipien bietet einen Benefit in komplexen Systemen. Entwurfsmuster (design patterns) bieten übersichtliche Lösungen für häufig auftretende Probleme. Ihre Nutzung senkt das Risiko von eigenen Entwurfsfehlern und spart viel Zeit. Einfachheit Komplexe und mächtige Technologien der Softwareentwicklung locken dazu, nur ihre Vorteile zu betrachten und die Nachteile zu unterschätzen. Oft werden Anwendungssysteme zu komplex entworfen, die Technologie zur Umsetzung übertrieben gewählt oder bewusst mächtigere Werkzeuge verwendet, um die Anwendung für zukünftig optionale Funktionen und Erweiterungen flexibel zu halten. Over-Engineering verursacht unnötige Kompliziertheit und Unübersichtlichkeit. Der Ansatz des Extreme Programming (XP) "the simplest thing that could possibly work" ist zwar sicherlich nicht immer der sinnvollste, mit Sicherheit jedoch der schnellste. Der Gefahr des Over-Engineerings steht die Versimplifizierung entgegen. Man sollte die Sanjay Jena; Nils Liebelt 4

5 fachlichen Anforderungen nicht zu naiv betrachten und das problem einfacher darstellen als es ist. Erweiterbarkeit Die Auswahl von Anwendungssystemen werden in der Regel durch die langfristige Unternehmensstrategie des Unternehmens beeinflusst. J2EE Anwendungen bleiben folglich für viele Jahre Bestandteil der Anwendungssystemslandschaft eines Unternehmens und werden immer wieder an neue business need, also unternehmerische Bedürfnisse, angepasst. Die Pflege von Anwendungen ist der weitaus teuerste Teil des Software Lebenszyklus. Daher ist schon beim Design von J2EE Systemen die Wartbarkeit im Auge zu behalten, welches einen sauberen Systementwurf voraussetzt. Testbarkeit Testen ist ein essentieller Bestandteil des Software Lebenszyklus und der Qualitätssicherung. Schon beim Systementwurf sollte daher darauf geachtet werden, dass Komponenten unabhängig und isoliert getestet werden können. Wiederverwendbarkeit Codewiederholung sollte vermieden werden. Dies wird in der Regel durch Praktizieren guter OO Entwurfsprinzipien erreicht. 2.2 Design Gesichtspunkte Vor dem Entwurf eines Softwaresystems, sollten einige Eigenschaften der Anwendung identifiziert werden, da sie direkten Einfluss auf die Architektur nehmen. Container-Architekturen und Frameworks helfen uns, diese effizient umzusetzen. Diese wachsen aus ihren Problemstellungen heraus, nicht anders herum. In folgenden Fragestellungen und Standard Problemstellungen sollen Application Frameworks helfen Verteiltes System vs. nicht verteiltes System Führende Plattformen, wie zum Beispiel J2EE (Java 2 Enterprise Edition) bieten eine hervorragende Unterstützung in der Implementierung verteilter Systeme. Komponenten von verteilten Systemen können auf verschiedene JVMs (Java Virtual Machine) aufgeteilt werden, sowohl auf einem als auch auf mehreren physischen Servern. Die hervorragende Unterstützung bei der Implementierung von verteilten Systemen durch J2EE führte jedoch in der Vergangenheit zu der fälschlichen und fraglichen Annahme, dass J2EE- Architekturen zwangsweise immer verteilt seien. Verteilte Systeme in J2EE basieren auf EJBs Sanjay Jena; Nils Liebelt 5

6 (Enterprise Java Beans) mit Remote Interfaces. Zwar handelt es sich um eine sehr mächtige Technologie, welche viele Möglichkeiten bietet, jedoch ist sie ebenso komplex und kompliziert. Die Notwendigkeit, eine Anwendung generell als verteiltes System zu realisieren, ist daher fraglich. Unabhängig von der Implementierung bieten verteilte Architekturen folgende Vorteile: Unterstützung einer heterogenen Client-Landschaft, welche auf eine gemeinsame Zwischenschicht (middle tier) mit Business Objects zugreifen. Dies trifft jedoch nicht auf Webanwendungen zu, da der Web-Container eine Zwischenschicht bereit stellt. Die Fähigkeit, jede beliebige Komponente auf jedem beliebigen physischen Server zu deployen. Dies ist nur bei einer Lastverteilung sinnvoll, falls einige Business Objects sehr rechenaufwändig sind. Dem gegenüber steht jedoch die erheblich schlechtere Performanz von verteilten Systemen. Im Gegenzug stellen uns verteile Systeme vor klare Nachteile: Performanz entfernte Anfragen sind erheblich langsamer als lokale Anfragen. Komplexität - verteilte Systeme sind schwierig zu konzipieren, zu entwickeln, zu deployen, zu testen und zu warten. Die Systemarchitektur verteilter Systeme ist in der Regel nicht einwandfrei mit den Prinzipien objektorientierter Programmierung in Einklang zu bringen. Unter diesen Gesichtspunkten sollte sich bei dem Entwurf der Systemarchitektur die Frage gestellt werden, ob eine verteilte Anwendung nötig ist, oder unter welchen Umständen sie zu einem absehbaren Zeitpunkt notwendig sein wird Strategien für den Zugriff auf Daten Geschäftsanwendungen arbeiten in der Regel mit einem großen Datenbestand, z.b. Stammdaten, Auftragsdaten, etc. Die Wahl des Datenzugriffs ist daher eine zwingende und wichtige Entscheidungen, welche die Performanz des Systems direkt beeinflusst. Eine übliche und die wohl am weitesten verbreitete Speicherform ist die Nutzung relationaler Datenbanken. Hierbei ist objektrelationales Mapping (O/R Mapping) die beste Lösung. Unabhängig von der Strategie sollte das Ziel jedoch sein, die Business Logik von der Ebene des Datenzugriffs durch eine weitere Abstraktionsebene zu entkoppeln Entity Beans Entity Beans sind eine fest an die EJB-Architektur gekoppelte Komponente. Sie modellieren die Sanjay Jena; Nils Liebelt 6

7 dauerhaft persistenten Daten des Systems, wie zum Beispiel Benutzerinformationen, Informationsstrukturen (z.b. Adressen) oder Vorgangsinformationen (z.b. Rechnungen). Die Persistenz wird entweder vom Programmierer selbst umgesetzt oder vom EJB-Container realisiert. Entity beans bieten eine saubere Lösung zur Isolierung des Datenzugriffs. Sie binden uns nicht an einen bestimmten Typen von Datenbank, jedoch an die EJB Container. Folglich sind sie eine sehr aufgeblähte Lösung mit einem großen overhead Java Data Objects Java Data Objects (JDO) ist eine aktuelle Spezifikation, entwickelt durch den Java Community Prozess, und nicht Teil der J2EE Spezifikation. Sie beschreibt einen herstellerunabhängigen Mechanismus für die persistente Speicherung von Java Objekten auf relationale oder objektorientierte Datenbanken, Dateien und andere transaktionale Datenspeicher. Die Spezifikation beschreibt eine einheitliche Schnittstelle für den Zugriff auf persistente Daten, lässt aber die Art und Weise der physikalischen Speicherung offen. Somit muss sich der Programmierer nicht mehr mit der Infrastruktur des Speichermediums auseinander setzen, und können sich auf die reine Applikationslogik konzentrieren. JDO bietet ein leichtgewichtigeres Modell als die Entity Beans, während es gleichzeitig die meisten positiven Seiten der Entity Beans erhält Weitere O/R Mapping Lösungen Objektrelationes Mapping (O/R-Mapping) ist das Abbilden von Objekten (bzw. Objektinformationen) auf relationale Strukturen wie zum Beispiel relationale Datenbanken, also in Tabellen und Spalten. Führende Produkte des objektrelationalen Mappings sind Oracle TopLink oder das Open Source Projekt Hibernate. Sie sind ausgereifter als JDO, können an beliebigen Stellen von J2EE Anwendungen eingesetzt werden und bieten leistungsstarkes, anspruchsvolles und effektives O/R- Mapping JDBC JDBC (Java Database Connectivity) ist Teil der Java API und bietet eine einheitliche Schnittstelle zu relationalen Datenbanken. Zu den Aufgaben von JDBC gehören der Aufbau und die Verwaltung von Datenbankverbindungen, die Weiterleitung von SQL-Anfragen an die Datenbank, die Umwandlung der Ergebnisse in eine für Java nutzbare Form und die anschließende Bereitstellung an das Programm. Im Vergleich mit anderen Werkzeugen ist JDBC low-level und seine Programmierung sehr mühsam. Nach wie vor bietet es jedoch sehr gute Performanz. Sanjay Jena; Nils Liebelt 7

8 2.2.3 State Management Ein weiterer wichtiger Punkt beim Entwurf der Systemarchitektur ist die Entscheidung, ob und wie ein serverseitiger Status verwaltet werden soll. Ein serverseitiger Status stellt kein Problem dar, wenn die Anwendung auf einem einzigen physischen Server läuft. Der Status bleibt dort bis Ende der Sitzung erhalten. Anders jedoch bei Lastverteilung auf verschiedene physische Server. Hier ergibt sich das Problem, dass der Status auf alle Server repliziert werden muss. Andernfalls laufen wir Gefahr, dass sich der Client an einen bestimmten Server bindet, da der Status auf den anderen Servern nicht vertreten ist (server affinity). Anwendungssysteme, welche keinen serverseitigen Status benötigen, sind somit einfacher zu skalieren und in Umgebungen mit mehreren physischen Servern zu installieren. Ist der serverseitige Status nicht umgehbar, so sollte man ihn so klein wie möglich halten. 2.3 Layering Unter Layering versteht man die Trennung des Anwendungssystems in unterschiedliche Schichten (Layer). Es ist eine der üblichsten Techniken in der Softwareentwicklung um die Komplexität von Systemen zu reduzieren und übersichtlicher zu gestalten. Zerlegen wir ein System in mehrere Schichten (vgl. Abbildung 1), so ist die innerste Schicht unabhängig von allen anderen. Die zweite Schicht baut auf der innersten auf und nutzt ihre Funktionalitäten, die dritte Schicht baut wiederum auf der zweiten auf und so weiter. Ein System in verschiedene Schichten zu unterteilen, bringt wichtige Vorteile mich sich: Jede einzelne Schicht kann als abgekapselter Teil betrachtet werden, ohne viel Wissen über andere Schichten zu besitzen. Es kann beispielsweise ein FTP Client auf Basis von TCP geschrieben werden, ohne Detailwissen über die Funktionsweise von Ethernet zu besitzen. Einzelne Schichten können durch alternative Implementierungen ausgetauscht werden, solange sie die selben Funktionalitäten bieten, welche in der Regel in einer Schnittstelle definiert werden. Ein FTP Service kann ohne Änderung über jede Art der Datenübertragung Ethernet, PPP etc. genutzt werden. Abbildung 1: Layering - Das Anwendungssytem wird in verschiedene Schichten unterteilt, welche jeweils aufeinander aufbauen Die Abhängigkeiten zwischen Schichten kann minimiert werden. Sanjay Jena; Nils Liebelt 8

9 Schichten bieten eine gute Grundlage für Standardisierungen. Eine einmal erstelle Schicht kann als Grundlage für weitere darüberliegende Schichten verwendet werden. TCP/IP wird als Grundlage für FTP, telnet, SSH und HTTP verwendet. Im Gegenzug birgt Layering auch Nachteile: Schichtenarchitekturen kapseln viele, jedoch nicht alle Problemdomänen gut. Einige Anforderungserweiterungen ziehen oft eine Reihe von Änderunge in vielen Schichten mit sich. Als klassiches Beispiel dient eine Webapplikation, in welcher ein eine Eingabemaske um ein weiteres Feld erweitert werden soll. Die Änderungen müssen nicht nur im User Interface, sondern ebenfalls in der Business Logik und eventuell sogar in der Datenbank, in Form einer neuen Spalte in einer Tabelle, durchgeführt werden. Zusätzliche Schichten können die Performanz beeinträchtigen. In jeder Schicht müssen die Daten an das in der Schnittstelle definierte Format transformiert werden, was die Effizienz eines Vorgangs oft sehr beeinträchtigt Drei-Schichten-Architektur Die am häufigsten aufgegriffene Schichtenarchitektur ist die Unterteilung in drei Layer: Presentation, Domain und Data Source (vgl. Abbildung 2). Presentation-Layer Die Präsentations Logik ist für die Interaktion mit dem Benutzer der Software verantwortlich. Dies kann in Form einer simplen Kommandozeilenabfrage, eines textbasiertes Menüs oder durch ein grafisches Rich-Client User Interface (UI), wie z.b. ein Swing/Rich-Client unter Windows, als Gegenbeispiel zu einem HTML-Browsers. Sanjay Jena; Nils Liebelt 9

10 Data-Source-Layer Die Data Source Logik übernimmt die Kommunikation mit anderen Systemen, welche für die Applikation tätig werden. Dies können wiederum andere Applikationen oder Benachrichtigungssysteme sein. In der Regel handelt es sich jedoch um persistente Daten wie Dateien oder Datenbanken. Domain/Business-Layer Die Domain Logik, auch Business Logik genannt, ist verantwortlich für den verbleibenden Teil. Diese umfassen Berechnungen und Verarbeitungen von Ein- und Ausgabe-Daten, Plausibilitätsprüfungen und generell jeder Art von Verarbeitung, welche auf das Problem bezogen ist Abbildung 2: Beispiel einer Anfrage in einer Bei der Betrachtung der einzelnen Schichten Drei-Schichten-Architektur (Quelle: [WIKI]) und die Beziehung unter ihnen, ist es sinnvoll auf die Asymmetrie ihrer Beziehungen zu achten: Welche Schicht bietet einen Service an, und welche Schicht nimmt den Service einer anderen Schicht in Anspruch. In der Drei-Schichten- Architektur arbeitet die Data Source Schicht unabhängig von den beiden anderen und bietet Funktionalitäten an, welche von der Domain Schicht in Anspruch genommen werden. Diese wiederum bedient die Präsentationsschicht mit Funktionalitäten. Beim Entwurf eines Softwaresystems sollte immer eine Trennung in Schichten vorgenommen werden. Ist die Applikation in ihrere Komplexität sehr gering, so sollte diese Trennung zumindest auf Ebene der Nutzung von unterschiedlichen Subroutinen bzw. Methoden statt finden. Diese Trennung kann dann später einfacher verstärkt werden, sobald das System komplexer wird. Bei der Trennung sollte niemals das Prinzip außer Acht gelassen werden, dass innere Schichten nicht von höherliegenden Schichten abhängen dürfen. Im Drei-Schichten-Modell bedeutet dies konkret, dass Domain und Data Source niemals von der Presentation Layer abhängig sein dürfen Ausführungsort der Layer Wir zerlegen ein System in verschiedene Teile, um die Abhängigkeiten zwischen ihnen Teilen zu reduzieren. Dies ist sinnvoll, unabhängig vom Ort an welchem die jeweiligen Schichten ausgeführt werden. Für die meisten Applikationen ist die wichtigste Entscheidung, ob sie auf der Client oder der Server Sanjay Jena; Nils Liebelt 10

11 Machine ausgeführt werden. Die komplette Verarbeitung auf den Server zu legen ist in der Regel die einfachste Lösung. Als Frontend bieten sich HTML gestützte Web-Browser an. Führen wir die Verarbeitung auf dem Server aus, so bietet dies einen großen Vorteil bei der Aktualisierung der Anwendung oder einiger seiner Teile. Da die Orte, auf welchem die Programmteile aktuell gehalten werden müssen, begrenzt ist, erspart dies viel Arbeit in Bezug auf Synchronisation mit dem Server und der Kompatibilität mit anderer Desktop Software. Im Gegensatz hierzu steht die Alternative, die Verarbeitung mehr auf den Client zu verlagern; die Data Source Layer liegt dabei jedoch weiterhin auf dem Server. Für diese Alternative sprechen die geringeren Antwortzeiten, welche erreicht werden, wenn nicht für jede Operation mehrere Schichten auf Seiten des Servers durchlaufen müssen. Für die Verarbeitung auf Clientseite spricht auch, wenn man davon ausgehen kann, dass nicht immer Verbindung zum Server besteht. Operationen, welche in einem solchen Zustand ausgeführt werden, können in der Regel nicht ausgeführt werden, da sich die Programmlogik auf dem Server befindet. Antwortzeiten können durch Browser Scripting oder herunter ladbare Applets verbessert werden. Hierdurch werden jedoch ebenfalls die Browser-Kompatibilität eingeschränkt und häufig andere Probleme verursacht. Rich-Clients sollten also vermieden werden, solange Antwortzeiten und stetige Verbindung zum Server kein Problem darstellen. Die Aufteilung der Domain Logik sowohl auf Client als auch auf den Server, ist die schlechteste Alternative, da die Lokalität eines jeden Teils der Logik nicht transparent ist. Umso konsequenter ausschließlich pures HTML auf Clientseite verwendet wird, desto einfacher ist der Entwicklungsprozess. 2.4 Moderne Entwurfsmuster Entwurfsmuster unterstützen uns in der Lösung und Implementierung von häufig auftretenden Problemen. Neben den bekannten Entwurfsmustern, welche in der heutigen Entwicklung komplexer Systeme unerlässlich sind, tauchten in den vergangenen Jahren noch einige neue Entwurfsmuster auf, wie z.b. Inversion of Control, welche insbesondere im Kontext der Enterprise Software schnell an Bedeutung gewonnen haben und Gegenstand aktueller Application Frameworks, wie z.b. Spring, sind Inversion of Control Inversion of Control (IoC) ist eine typische Eigenschaft einer Containerarchitektur. Es beschreibt die Verlagerung der Kontrolle eines Prozedur-Aufrufs weg vom Programm hinein in das Containers. Ein anschauliches Beispiel bietet der Ablauf von Konsolenanwendungen. Eingaben werden sequentiell vom Benutzer eingefordert, die Kontrolle liegt im Programm. Grafische Benutzerschnittstellen bieten heute alle Eingabefelder zur selben Zeit in einer Maske an. Statt Sanjay Jena; Nils Liebelt 11

12 jedoch innerhalb einer Schleife auf Eingaben zu warten, wird mit Ereignissen gearbeitet, welche durch Eingaben in den Eingabefeldern ausgelöst werden. Die Kontrolle wurde also weg vom Programm zum Framework, in diesem Fall dem Event-Handler, übertragen Dependency Injection Im Zuge des vermehrten Aufkommens leichtgewichtiger Container spielte vor allem Inversion of Control eine zentrale Rolle. Dependency Injection ist ein Entwurfsmuster, welches beschreibt, wie die Inversion of Control umzusetzen ist. Eine häufige Vorgehensweise in der Programmierung ist die Instanzierung von anderen Objekten innerhalb von Member-Methoden. Dies macht das Objekt zum einen schwerer und komplexer, und schafft zum anderen mehr Abhängigkeiten. Die erhöhte Komplexität erschwert das Verständnis und vor allem die Möglichkeiten des Testens. Eine andere Möglichkeit ist, den Member-Methoden solche Abhängigkeiten beim Aufruf mitzugeben. Diese spezielle Form der Inversion of Control wird Dependency Injection genannt. Abhängigkeiten werden dem Objekt hierbei "injiziert" (vgl. Abbildung 3). Dependency Injection schafft Transparenz bezüglich der Abhängigkeiten und erleichtert das Testen der Objektmethoden. Abbildung 3: Inversion of Control (IoC) - X s direkte Abhängigkeit von Y wird durch die Abhängigkeit von einem Interface I ersetzt, welches Y implementiert Im Gegensatz hierzu steht das Entwurfsprinzip, zu lange Parameterlisten bei Methodenaufrufen zu vermeiden. Die Entscheidung, welche Abhängigkeiten injiziert werden, und welche in der Verantwortung des Objektes bleiben, ist also hierbei entscheidend und erfordert gewisse Erfahrung. Das Entwurfsmuster Inversion of Control kann eine grosse Hilfe bei der Erzeugung unabhängiger leicht konfigurierbarer Architekturen sein. Ein Framework zur übersichtlichen Realisierung von Dependency Injection ist Spring, welches den Programmierer dabei unterstützt, die Kontrolle über die Abhängigkeiten aus den Objekten in die Konfigurationsmechanismen des Frameworks zu schieben. 2.5 Aspektorientierte Programmierung Aspect-oriented Programming (AOP) beschreibt eine andere Sicht auf die Struktur von Quellcode. Vergleicht man diesen Ansatz mit dem älteren Paradigma der Objektorientierung oder der prozeduralen Programmierung, so zielt auch AOP darauf ab, die Aufteilung und Kapselung der inhaltlichen Belange ("concerns") in einzelne Entitäten zu verfeinern. Sanjay Jena; Nils Liebelt 12

13 In der objektorientierten Programmierung kapseln Attribute und Methoden einer Klasse einen bestimmten inhaltlichen Belang. Betrachtet man jetzt eine Vielzahl von solchen Klassen, so kann aber es sein dass diese einen Teil des Belanges wiederholt kapseln. Charakteristisch ist das wiederholte Auftreten, daher werden diese Aspekte auch häufig als "Crosscutting concerns" beschrieben. Als bekanntes Beispiel aus dem Enterprise Kontext wird häufig der Aspekt des Loggings als "Cross Cutting Concern" aufgegriffen. Logging ist in fast jedem Teil einer Anwendung notwendig und geht dabei häufig nach ähnlichen Mustern vor. So könnte man sich leicht vorstellen, dass man z.b. die Argumente der Methoden aus seiner Problemdomäne loggen möchte. Ziel der AOP ist es nun, dies nicht wiederholt in den einzelnen Methoden zu realisieren, sondern den Aspekt des Loggings an einer zentralen Stellen zu implementieren. Dieses Beispiel zeigt eine direkte Möglichkeit der praktischen Anwendung. Wie weitreichend das Konzept jedoch ist möchten wir an einem weiteren Beispiel zeigen: "Fundamentals of Object-Oriented Design in UML" von Meilir Page-Jones gibt ein kleines Beispiel, welches die Schwierigkeiten des traditionellen OO-Designs verdeutlicht und eine elegante Lösung durch Aspektorientierung nahelegt. Die Klasse Person besitzt ein Attribut numofdogsowned und eine öffentliche Zugriffsmethode getnumofdogsowned(). Unter Betrachtung der möglichen Wiederverwendbarkeit der Klasse Person ensteht eine interessante Fragestellung, da Person und Dog eindeutige Konzepte repräsentieren und DogOwnership kein essentieller Bestandteil von Person ist. Wie kann man die Klasse Person jedoch in einer Anwendung ohne Dogs wiederverwenden. Meilir Page-Jones beschreibt in Ihrem Buch hierzu vier objektorientierte Lösungsmöglichkeiten, die alle Vor und Nachteile bieten: Das überflüssige Feld wird einfach mit übernommen jedoch nicht benutzt. Es bleibt redundant erhalten Durch Verwendung einer PersonDogOwnership Assoziations-Klasse. Mehrfach-Vererbung oder Verwendung von Mixings (also dem einbinden von Modulen in eine Klasse statt Mehrfachvererbung). Über eine Aggregation Alternativ ist seit Anfang letzten Jahres auch eine einfache Lösung dieses auch als Mixed-Role Cohesion bekanntem Problems über Aspektorientierung bekannt. Die Modellierung des Aspekts DogOwnership macht es möglich diesen losgelöst von der Person auch für z.b. eine Organization wiederzuverwenden. Umgekehrt gibt es keine direkte Abhängigkeit von Person auf DogOwnership. Eine Darstellung unter Verwendung der Java Erweiterung AspectJ zeigt diese beschriebene Modellierung exemplarisch: Sanjay Jena; Nils Liebelt 13

14 /** * Keine Abhängigkeiten auf DogOwnership in irgendeiner Form */ public class Person { } private String lastname; private Address address;... public String getlastname() { return lastname; }... public aspect DogOwnership { } /** * Bei dieser Deklaration handelt es sich um ein inter-type interface, * das sich s.u. dynamisch an die Person mit DogOwnerShip binden lässt */ public interface IDogOwner {}; /** * Cross cutting member - Klassenvariable über mehrere Klasse definiert, die die * Anzahl der Dogs speichert */ private int IDogOwner.numDogsOwned; /** * JavaBean getter */ public int IDogOwner.getNumDogsOwned() { return numdogsowned; } /** * Der PersonOwnsDog Aspekt verwebt Person mit IDogOwner */ public aspect PersonOwnsDog { declare parents : Person implements DogOwnership.IDogOwner; } Nach der Kompilierung durch den AspectJ Compiler lässt sich die Person mit dem jetzt verwobenen Aspekt DogOwnership nutzen. Person person = new Person(); person.getnumdogsowned(); Dieses Beispiel zeigt die weitreichenden Möglichkeiten Aspektorientierten Programmierung. Inwiefern und auf welche Art und Weise sich dieses Paradigma im Enterprise-Anwendungen etabliert ist momentan noch unklar. Dabei konkurieren auf Proxy und auf Bytecode-Manipulation basierende Implementationen miteinander. Aspektorientierte Programmierung findet heute vor allem in deklarativen Transaktionen, deklarativer Security, Exception Handling und Caching ihren Einsatz. Inwiefern der Einfluss der aspektorientierten Programmierung in den nächstne Jahren wachsen wird, ist zum jetzigen Zeitpunkt unklar. Sanjay Jena; Nils Liebelt 14

15 3 Agile J2EE Im folgenden werfen wir einen pragmatischen Blick auf heutige Möglichkeiten und Technologien zur Entwicklung von Enterprise Software. Der kolossale Einfluss von SUNs J2EE Spezifikation legt es nahe, diese Technologie genauer zu untersuchen. Kriterium dabei sollen die identifizierten Anforderungen an Enterprise Software aus dem ersten Teil sein. Daneben wollen wir aber auch neue Konzepte und Paradigmen (wie IoC und AOP) in diesem Nutzungskontext prüfen. 3.1 Einführung J2EE J2EE ist die Abkürzung für Java 2 Platform, Enterprise Edition. Eine Spezifikation für eine Platform von Anwendungskomponenten. Die aktuelle Version der J2EE-Spezifikation ist die Version 5.0. In der Spezifikation werden Softwarekomponenten definiert, die unterschiedliche wiederkehrende Aufgabe und Probleme aus dem Enterprise Kontext lösen. Die Spezifikation dient dazu, einen allgemein akzeptierten Rahmen zur Verfügung zu stellen, welchen Hersteller auf Basis modularer Komponenten implementieren können. Die so erzeugten Komponenten sind interoperabel, wenn sie sich an die Spezifikation halten. J2EE Komponenten im Kontext dieser Ausarbeitung sind insbesondere: Kurzform Name EJB Enterprise Java Beans Bedeutung beinhalten die Geschäftslogik einer Enterprise Anwendung oder gestatten Zugriff auf persistente Daten. Die Anwendungs-Objekte laufen in einem EJB-Container. Der Container bietet Transaktionen und verteilte Objekte. Es gibt drei unterschiedliche Typen von EJBs: Session-Beans, sowohl statusbehaftet als auch ohne internen Status, welche die Geschäftslogik implementieren und meistens vom Client aus zugreifbar sind Message-Driven-Beans (MDB), für die Verarbeitung von JMS (Java Messaging Service) Nachrichten Entity-Beans für die Abbildung von persistenten Datenobjekten Servlet Java Servlet API Die Java-Servlet-API ist eine allgemeine Erweiterung für Server, deren Protokoll auf Anfragen und Antworten basiert. Primär werden Servlets im Zusammenhang mit dem Hypertext Transfer Protocol (HTTP) verwendet. Ein Web-Container wie z.b. Tomcat implementiert die Servlet-API und stellt unter anderem aus der API spezifizierte Objekte für Request und Response zur Verfügung Sanjay Jena; Nils Liebelt 15

16 Kurzform Name JSP Bedeutung Java Server Pages JSP-Dateien sind Textdokumente, die zum einen aus statischem Text und zum anderen aus dynamischen Textelementen - den JSP- Elementen - bestehen. Die JSP-Seiten werden transparent vom Web-Container in ein Servlet umgewandelt und stellen eine spezielle View-Technologie für J2EE Webanwendungen dar JMX JNDI Java Management Extensions Java Naming and Directory Interface Eine Java Technolgie, die Werkzeuge für die Verwaltung und Überwachung von Anwendungen und Systemobjekten zur Laufzeit ermöglicht API für einen Objektorientierten Directory Service. Gibt die Möglichkeit, Objekte in Namensräumen zu suchen und zu entdecken. Über das zusätzlich spezifizierte Service Provider Interface (SPI) ist eine Kopplung an weit verbreitete Naming und Directory Services, wie z.b. LDAP, DNS, RMI oder CORBA Naming Service möglich. 3.2 Probleme mit den traditionellen J2EE Ansätzen Zwar haben sich verschiedene J2EE Implementationen seit 1999/2000 weit verbreitet, doch gibt es beim praktischen Einsatz auch heute viele Kompliziertheiten, welche die Produktivität der Entwickler bremsen. Verallgemeinert lässt sich festhalten, dass einfache J2EE Applikationen oftmals übermäßig komplex sind, also einen gewissen Ballast an nicht problembezogenen, technischen Schwierigkeiten aufweisen. Deren Ursachen lassen sich in verschiedene Gruppen aufteilen: Übermäßiger Anteil an Blei-Code ("plumb code, glue code") Damit sind Code-Blöcke gemeint die immer wiederkehren aber eigentlich nichts bewirken. Dazu gehören vor allem JNDI lookups und Transfer objects. Mit letzterem meinen wir dass kopieren von Objektattributen z.b. von Web-Tier in die EJB-Domäne Viele J2EE Applikationen benutzen ein verteiltes Objektmodel, obwohl dies eigentlich unpassend ist Die Folge davon ist exzessive Code Wiederholung z.b. durch EJB Local Remote Interface Jetzt kann man natürlich versuchen dem mit code generierende Werkzeugen entgegen zuwirken. Doch gerade wenn Fehler auftreten wird es jetzt besonders schwierig. Daneben ist es auch konzeptual falsch einfach verteiltes Model bei einer nicht verteilten Anforderungen. EJB Komponenten Model unnötig komplex Ursprünglich gedacht dem Entwickler bei der formalen Abbildung des Gesschäftsprozess in Code zu helfen. In der Praxis nicht geglückt. Sanjay Jena; Nils Liebelt 16

17 EJB zu viel benutzt; nicht flexibel EJB ist designed für verteilte, transaktionale Anwendungen. In der Praxis sind fast alle nicht trivialen Anwendungen transaktional jedoch eher wenige verteilt. Im EJB Programmiermodell bekommt man entweder beides oder kein von beidem. "J2EE design patterns" [SUN2] keine Pattern im Sinne von OO-Entwurfsmustern Die auch als Blueprints bekannten "Muster" sind eher als eine aus der Technologie herausgewachsene Sammlung für "J2EE best practises" anzusehen. Diese Pattern müssten auf Ihre Bedeutung im klassischen Sinne von Entwurfsmustern geprüft werden. Oftmals erzeugt eine API schwierige Situationen, die dann mit einem solchen Pattern behoben werden. Eine von dem Framework gelöste, technologie-unabhängige Betrachtung der selben Fragestellung offenbart oft einfachere praktischere Lösungen! Abbildung 4: Übersicht über J2EE Design Pattern Schwierige Testbarkeit Sanjay Jena; Nils Liebelt 17

18 Viele J2EE Module sind ungeeignet für das Komponentenweise testen außerhalb des Application Containers. Um möglichst viel Fehler Szenarios abzudecken sind diese Test allerdings essentiell. Darüber hinaus halten Tests außerhalb des Containers den Entwicklungsprozess vital. Keine lange unproduktiven Wartezeiten auf das deployment der Applikation. 3.3 Lightweight Frameworks Die diskutierten Probleme mit nativen J2EE Ansätzen beziehen sich dabei nicht nur auf Aspekte der J2EE Technologie sondern allgemein auf Frameworks, die in dieser Zeit entwickelt wurden. So stammt aus dieser frühen Phase z.b. auch das Apache Avalon Projekt [APACHE1]. Ein Java Apache Server Framework, mit dem Konfiguration und Management (IoC Pioniere) für die Applikation in Form von Komponenten ermöglicht wurde. Das Avalon Framework fand nie große Anerkennung in der JAVA Welt. Hauptgründe waren die vielen Abhängigkeiten auf die Avalon API, sowie die steile Lernkurve, die keinen leichten Einstieg in die Materie erlaubte. Das Apache Projekt ist mittlerweile geschlossen. Diese Misstände machten es zunehmenden notwendig, neue leichtgewichtigere Frameworks zu entwickeln. Ursprünglich zielten die ersten Lightweight Frameworks darauf ab J2EE Services leichter handhaben zu können. Dabei sollten jedoch im Unterschied zu Heavyweight Containern möglichst wenig Abhängigkeiten entstehen. Das Framework an sich sollte unsichtbar werden. Darüber hinaus sollte den Entwicklern ermöglicht werden, primär mit POJOs zu arbeiten anstatt mit speziellen Vererbungshierarchien wie EJB. Die Verwendung von Lightweight Frameworks hat dabei folgende Absichten: Keine hohen Projektanlaufzeiten Keine großen binären Abhängigkeiten Verwendbarkeit unabhängig von der Umgebung Leicht zu testen Hauptaufgaben des Frameworks sind dabei: Reduzierung der Komplexität des Programmcodes der Problemdomäne Reduzierung der Komplexität in der Verwendung des Frameworks Grundlegend lässt sich die Lightweight -Idee mit dem Anraten des Extreme Programming "the simplest thing that could possibly work" vergleichen. Lightweight Frameworks sind aus den Erfahrungen mit den Umgang von J2EE gewachsen. Es ist jedoch wichtig zu erwähnen das die Verwendung eines Lightweight Containers auf verschiedene Umgebungen anwendbar ist und sich dieses Konzept nicht zwingend auf J2EE Technologie Sanjay Jena; Nils Liebelt 18

19 konzentriert. 3.4 Spring Framework Das Spring-Framework ist eins der wenigen erfolgreichen Softwareprojekte, die grundlegend aus den Ideen eines Buchs entstanden sind. In Expert One-on-One J2EE Design and Development [JOHNSON1] legt Rod Johnson den Grundstein für den Beginn der Spring Entwicklung. Zusammen mit dem Buch veröffentlichte Johnson auch 30,000 Zeilen Code. Das sogenannte Interface 21 Framework umfasste pragmatische Lösungen zu vielen im Buch diskutierten Problemen. Die positive Reaktion auf die Veröffentlichungen regte die Weiterentwicklung an. Im Februar 2003 ist das Framework dann erstmals unter dem Namen Spring und der Apache 2.0 Lizenz publiziert worden. Neben Johnson hat Juergen Hoeller als co-lead des Projekts große Teile der Implementation und des Designs beigetragen. Beide sind Mitgründer der 2004 gegründeten Firma Interface 21. Kerngeschäft der Firma ist Spring und dessen Consulting, Training und Support. Dabei ist dieses wirtschaftliche Model hinter dem Open-Source-Projekt gerade für die Akquise von großen Firmen interessant, da so zum einen die kontinuierliche Weiterentwicklung sichergestellt wird, aber auch eine nötige Unterstützung bzw. Betreuung von Projekten in den Firmen gewährleistet werden kann Spring Module im Überblick Das Springframework teilt sich in mehrere Module, die im folgendem Teil näher erläutert werden. Grundlegend sind dabei zwei Kategorien zu differenzieren: IoC Container und AOP Framework, das im wesentlichen für die Konfiguration der Objekte zuständig ist Eine Reihe an Services, die auf die Objekte anwendbar sind. Die Verwendung in Form einer Klassenbibliothek IoC Container Im Zentrum einer typischen Spring Anwendung steht der Application Context. Hinter diesem Interface verbirgt sich Spring's IoC Funktionalität. Der Application Context ermöglicht es Anwendungs-Objekte und Framework durch Verwendung von Dependency Injection zu konfigurieren und miteinander zu verdrahten. Dabei kümmert sich der Container um das life cycle management der Objekte. Die so konfigurierten Anwendungs-Objekte aus dem Application Context haben für gewöhnlich keine direkten Abhängigkeiten auf den Container, falls diese jedoch benötigt werden, kann z.b. über die Implementierung ApplicationContextAware ein Callback auf den Container ermöglicht werden. Sanjay Jena; Nils Liebelt 19

20 Die Verwendung des Application Contextes macht es einfach, einzelne Komponenten über Interfaces und abstrakte Superklassen zu koppeln. Für gewöhnlich wird der Application Context über einen XML-Dialekt beschrieben. Es gibt allerdings auch Code-Implementationen sowie eine Möglichkeit der Beschreibung über Property- Files. Im folgenden nun ein Beispiel, welches eine Vorstellung über die konkrete Verwendung des Frameworks greifbar machen soll. Im folgenden geht es um die Instanzierung und Abhängigkeit zwischen zwei Objekten eines simplen Computerspiels. Es existiert ein Puzzle Domain Objekt sowie ein dazugehöriges PuzzlePane welches das Model graphisch darstellt. <bean id="puzzle" class="de.fhkoeln.fb10.ala.puzzle.domain.puzzleimpl"> <constructor-arg type="int"> <value>3</value> </constructor-arg> <property name="puzzleobserver"> <list> <ref bean="puzzlepane"/> </list> </property> </bean> <bean id="puzzlepane" class="de.fhkoeln.fb10.ala.puzzle.ui.puzzlepane" init-method="initialize"> <property name="puzzlestate"> <ref bean="puzzle"/> </property> <property name="spacing" value="4"/> <property name="padding" value="28"/> <property name="title" value="puzzle Panel"/> <property name="movementtime" value="300"/> </bean> Bei Erzeugung eines Application Context durch z.b. ApplicationContext ctx = new ClassPathXmlApplicationContext( path/to/siehe/oben/context.xml ); wird der Spring IoC-Container die zwei über das Id-Attribute eindeutig identifizierten Beans puzzle sowie puzzlepane instanzieren. Danach werden in diese Objekte Attribute und Abhängigkeiten injiziert. Dabei sind grundlegend zwei Arten der Dependency Injection zu Unterscheiden: Getter/Setter Injection per JavaBean-Konvention definierte Methoden werden entsprechend des Property-Tags per Reflection aufgerufen Constructor Injection die Objekte werden direkt mittels übergebener Konstruktor Argumente instanziert. Als nächster Schritt im bean life cycle werden dann die unter init-method definerten Methoden der Objekte aufgerufen. Sanjay Jena; Nils Liebelt 20