Architecture Blueprints

Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Architecture Blueprints Ein Leitfaden zur Konstruktion von Softwaresystemen mit Java Spring, .NET, ADF, Forms und SOA ISBN-10: 3-446-41201-8 ISBN-13: 978-3-446-41201-9 Vorwort Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41201-9 sowie im Buchhandel Vorwort Zur zweiten Auflage Die zweite Auflage der Architecture Blueprints ist eine aktualisierte Überarbeitung der Ersten, die erst vor kurzem – im Herbst 2006 – erschienen ist. Die Überarbeitung hat sich aufgrund der großen Nachfrage ergeben, was uns sehr gefreut hat und wir danken allen Lesern und Leserinnen dafür. Wir haben die Gelegenheit genutzt, um neue Erfahrungen einfließen zu lassen und eine Reihe von Techniken und Technolo- gien mit einzubeziehen, die inzwischen reif für die Praxis sind. Mit Marcel Lattmann hat ein erfahrener Architekt das Autorenteam bereichert. Die vorliegende Ausgabe ist vollständig überarbeitet worden. Die Architekturstan- dards für die Technologien Java Spring, Microsoft .NET, Oracle ADF, Oracle Forms und SOA wurden verfeinert und sind – wie wir hoffen – noch klarer und verständli- cher dargestellt worden. Das einführende Kapitel „Grundlegende Architekturkonzepte“ wurde von Mischa Kölliker zur besseren Lesbarkeit gestrafft und umgestellt und in die Bereiche Domain Layer, Persistence Layer und Presentation Layer aufgeteilt. Es beschreibt Pattern, Kon- zepte und Designkriterien, die in der Praxis für Enterprise Architekturen relevant sind. Der Review wurde von Guido Schmutz und Peter Welkenbach durchgeführt. „Spring Framework Architecture Blueprint“ wurde von Guido Schmutz und Peter Welkenbach ergänzt, die inzwischen zu diesem Thema ein eigenes Buch mit den Titel „Spring 2.0 im Einsatz“ geschrieben haben. Die wichtigste Ergänzung befasst sich mit dem Enterprise Middletier und seiner Realisierung. Mischa Kölliker hat den Review übernommen. Das Kapitel „Microsoft .NET Architecture Blueprint“ wurde von Marcel Lattmann und Michael Könings komplett überarbeitet, um die neuen Technologien .NET 3.0 und AJAX und deren Einsatz in der Praxis darzustellen und einen Ausblick auf die techno- logische Entwicklung (LINQ und die nächste .NET Version), die in naher Zukunft re- XI Vorwort levant sein könnte, zu präsentieren. Das Kapitel wurde von Christoph Pletz, Meinrad Weiss und Markus Heinisch reviewed. Das Kapitel „Oracle ADF Architecture Blueprint“ wurde von Markus Heinisch mit Beispielen angereichert und mit einer Beschreibung von JHeadstart, einer Technolo- gie zur produktiven Generierung von einfachen Anwendungen, ergänzt. Perry Pakull war für den Review zuständig. „Oracle Forms Architecture Blueprint“ hat Perry Pakull mit einem zusätzlichen Ab- schnitt zu Thema Oracle Forms Konzepte erweitert. Außerdem hat er die Einsatzbe- reiche, die Architektur und die verschiedenen Ausprägungen des Forms Clients ver- feinert. Der Review wurde von Michael Könings und Daniel Liebhart durchgeführt. Das Kapitel „SOA Blueprint“ wurde von Daniel Liebhart aufgrund der Tatsache, dass sowohl die Hersteller also auch viele Unternehmen sehr viel Neues realisiert haben, überarbeitet und erweitert. Neu sind die Bestandteile der einzelnen Ebenen einer SOA und der Abschnitt SOA und BPM. Außerdem wurde der SOA Blueprint verfei- nert und die SOA Modelle der großen Hersteller skizziert. Das Review hat Markus Heinisch ausgeführt. An dieser Stelle danken die Autoren allen Personen, die in irgendeiner Weise einen Beitrag zur Überarbeitung dieses Buches geleistet haben. Neben den Reviewern wa- ren das unter anderem Urban Lankes für die Initiative zur kompletten Überarbeitung, Patrick Spieler für die AJAX Vorlage, Urs Meier für die Weiterentwicklung der Grund- lagen zum Microsoft .NET Architecture Blueprint, Anton Rasch für den Input zum Layering und Dirk Nachbar für den Input zum Sizing im Oracle Forms Architecture Blueprint, Michael Beer für die Reflektionen zum Einführungskapitel und dem SOA- Expertenrat und seinen Bloggern für die vielen Ideen und Inputs zum SOA Blueprint und schließlich unseren Kollegen, Kolleginnen, Freunden, Freundinnen, Angehörigen sowie dem Korrektor und den Verlagsmitarbeiterinnen für ihre Geduld. Basel, Bern, Frankfurt, München, Stuttgart und Zürich im April 2007 Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull und Peter Welkenbach XII Vorwort Vorwort der ersten Auflage Architecture Blueprints sind Anleitungen und Orientierungshilfen für den Bau von Individualsoftware. Dieses Buch definiert Architekturstandards für die Technologien Java Spring, Microsoft .NET, Oracle ADF, Oracle Forms und SOA. Wir haben dieses Buch geschrieben, weil es einem Bedürfnis entspricht, die Lücke zwischen den Vorstellungen der großen Hersteller und den theoretischen Ansätzen der reinen Lehre zu füllen. Wir leisten damit einen Beitrag, um die Qualität und Pro- duktivität der Individualentwicklung zu erhöhen. Das Buch soll helfen, Softwaresys- teme effizienter, qualitativ hoch stehend und kostengünstig zu erstellen, betreiben und beurteilen. Das Buch ist für IT-Professionals die Software entwickeln, für Architekten die Ge- samtsysteme gestalten, für Manager und Projektleiter die den Einsatz verschiedener Technologien beurteilen und für Systemadministratoren die Anwendungen betrei- ben. Jede Technologie ist in einem einzelnen Kapitel beschrieben. Jedes dieser Kapitel kann für sich alleine gelesen werden. Der Leser und die Leserin finden in jedem Ka- pitel einen Architecture Blueprint, dessen Bestandteile (Building Blocks) erklärt wer- den. Zusätzlich haben wir unsere Erfahrungen beim Einsatz der jeweiligen Technolo- gie reflektiert, als „Do’s“ und „Dont’s“ zusammengestellt und auf die Besonderheiten hingewiesen. Das einführende Kapitel „Grundlegende Architekturkonzepte“ wurde von Guido Schmutz, Mischa Kölliker und Peter Welkenbach verfasst. Es beschreibt die konzep- tionelle Basis der Architekturen, die in den nachfolgenden Kapiteln ausgeführt wer- den. Das Kapitel „Spring Framework Architecture Blueprint“ wurde ebenfalls von Guido Schmutz, Mischa Kölliker und Peter Welkenbach verfasst. Sie stellen den Architek- turstandard für das Java Spring Framework vor. Dieses Kapitel ist ausführlich gehal- ten, da die Vielfalt der möglichen Frameworks und Komponenten im Bereich „Enter- prise Applications“ mit Java einer genauen Betrachtung, Bewertung und Gewichtung bedürfen. „Microsoft .NET Architecture Blueprint“ wurde von Michael Könings geschrieben. Es fasst das von Urs Meier, Christoph Pletz, Marcel Lattmann und Željko Savić entwi- ckelte „Enterprise Application Programming“ Framework zusammen und beschreibt, wie leistungsfähige betriebliche Anwendungen auf Basis der .NET Plattform gestaltet werden. „Oracle ADF Architecture Blueprint“ wurde von Markus Heinisch geschrieben. Er fasst die Einsatzgebiete, die Stärken und die Schwächen von Oracle ADF als Enterprise Framework zusammen. Besonders vertieft werden die Business Components, deren Layering und Anwendungsregeln. XIII Vorwort „Oracle Forms Architecture Blueprint“ hat Perry Pakull verfasst. Er zeigt auf, wie die traditionelle 4 GL Technologie Oracle Forms als produktives Werkzeug für die Reali- sierung moderner Multi-Tier Anwendungen eingesetzt werden kann. Unabhängig vom Hersteller Oracle werden Upgradeszenarien, Sizingregeln und Layeringprinzi- pien erläutert und vertieft. „SOA Blueprint“ wurde von Daniel Liebhart geschrieben. Der SOA Blueprint zeigt ein herstellerunabhängiges, pragmatisches Architekturmodell auf. Die möglichen Ska- leneffekte für ein Unternehmen, der Einfluss auf eine IT Organisation und die Stärken von SOA, in Bezug auf die Weiterverwendung bestehender Systeme, werden ausge- führt. Sämtliche Kapitel wurden im Teamwork von allen Autoren gemeinsam konzeptionell entwickelt, intensiv diskutiert, teilweise verworfen, komplett überarbeitet und mehr- fach reviewed. An dieser Stelle danken die Autoren allen Personen, die in irgendeiner Weise einen Beitrag zum Entstehen dieses Buches geleistet haben. Der Firma Trivadis AG dafür, dass dieses Buch überhaupt möglich war. Anton Rasch und Dirk Jablonski für den Review des Kapitels „Grundlegende Architekturkonzepte“ und des Kapitels „Spring Framework Architecture Blueprint“. Marcel Lattmann und Željko Savić für den Re- view des Kapitels Microsoft .NET Architecture Blueprint“ und im speziellen Željko Savić für die Mithilfe bei der Überarbeitung dieses Kapitels und Urs Meier für den reichhaltigen Input. Yves Caloz und Ulrich Vogel für den Review des Kapitels „Orac- le ADF Architecture Blueprint“. Walter Müller und Stefan Jüssen für den Review des Kapitels „Oracle Forms Architecture Blueprint“ und im speziellen Gudrun Pabst für das Migrationsszenario.

Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Architecture Blueprints Ein Leitfaden zur Konstruktion von Softwaresystemen mit Java Spring, .NET, ADF, Forms und SOA ISBN-10: 3-446-41201-8 ISBN-13: 978-3-446-41201-9 Inhaltsverzeichnis Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41201-9 sowie im Buchhandel Inhalt Vorwort zur zweiten Auflage ............................................................................................... XI Vorwort der ersten Auflage ................................................................................................XIII Die Autoren.........................................................................................................................XV 1 Grundlegende Architekturkonzepte ........................................................................... 1 1.1 Enterprise Application Architecture Patterns ................................................................ 1 1.2 Application und Domain Layer ................................................................................... 2 1.2.1 Transaction Script........................................................................................... 3 1.2.2 Domain Model............................................................................................... 4 1.2.3 Table Module................................................................................................. 6 1.2.4 Service Layer.................................................................................................. 9 1.3 Persistence Layer ...................................................................................................... 14 1.3.1 Foreign Key Mapping ................................................................................... 14 1.3.2 Association Table Mapping........................................................................... 15 1.3.3 Single Table Inheritance ............................................................................... 16 1.3.4 Class Table Inheritance................................................................................. 17 1.3.5 Concrete Table Inheritance........................................................................... 18 1.3.6 Lazy Load..................................................................................................... 19 1.3.7 Query Object ............................................................................................... 20 1.3.8 Optimistic Offline Lock ................................................................................ 20 1.3.9 Pessimistic Offline Lock................................................................................ 21 1.4 Presentation Layer..................................................................................................... 22 1.4.1 Forms und Controls ...................................................................................... 22 1.4.2 Model View Controller (MVC) ...................................................................... 24 1.4.3 Model View Presenter (MVP)........................................................................ 26 1.4.4 Presentation Model (auch Application Model)............................................... 27 1.4.5 Page Controller ............................................................................................ 29 1.4.6 Front Controller............................................................................................ 30 1.5 Domain Driven Design............................................................................................. 30 1.5.1 Isoliere die Domäne ..................................................................................... 32 1.5.2 Beschreibe das Modell durch Software ......................................................... 34 V Inhalt 1.5.3 Organisation der Business-Logik ................................................................... 45 1.6 Zusammenfassung .................................................................................................... 47 1.6.1 Transaction Script......................................................................................... 47 1.6.2 Domain Model............................................................................................. 48 1.6.3 Table Module............................................................................................... 49 1.6.4 Wann welches Pattern wählen? .................................................................... 50 1.6.5 Fazit............................................................................................................. 52 2 Spring Framework Architecture Blueprint................................................................ 53 2.1 Einleitung ................................................................................................................. 54 2.1.1 Lightweight-Container .................................................................................. 54 2.1.2 Die Geschichte von Spring........................................................................... 55 2.1.3 Was ist Spring ?............................................................................................ 55 2.1.4 Injecting Dependencies................................................................................ 56 2.1.5 Architekturvorteile mit Spring....................................................................... 56 2.1.6 Ziele des Spring Frameworks........................................................................ 57 2.2 Architektur ............................................................................................................... 58 2.2.1 Die Bestandteile von Spring ......................................................................... 59 2.2.2 Der Spring Container und Dependency Injection.......................................... 60 2.2.3 Arbeiten mit dem ApplicationContext........................................................... 61 2.3 Building Blocks ........................................................................................................ 62 2.3.1 Integration Layer .......................................................................................... 62 2.3.2 Domain Layer als Transaction Script/Table Module....................................... 64 2.3.3 Domain Layer als Rich Domain Model ......................................................... 67 2.3.4 Application Layer ......................................................................................... 70 2.3.5 Presentation Layer – Web............................................................................. 79 2.3.6 Presentation Layer – Rich Client ................................................................... 91 2.3.7 DTO (Data Transfer Objects) ........................................................................ 97 2.3.8 Enterprise Application Security ..................................................................... 99 2.3.9 Konfiguration ............................................................................................. 101 2.4 Spring und das Enterprise Middletier....................................................................... 102 2.4.1 Was ist Mule ?............................................................................................ 103 2.4.2 Mule-Architektur ........................................................................................ 105 2.4.3 Mule Building Blocks ................................................................................. 106 2.4.4 Mule und Spring ........................................................................................ 121 2.5 Quality ................................................................................................................... 122 2.5.1 Java Coding Standards ................................................................................ 123 2.5.2 Code Review.............................................................................................. 124 2.5.3 Standard für Projekt: Verzeichnislayout ...................................................... 124 2.6 Deployment ........................................................................................................... 124 2.6.1 Nur ein Web Container .............................................................................. 124 2.6.2 Präsentation auf separatem Server............................................................... 125 2.6.3 „Full-blown“ Application Server ................................................................. 126 2.6.4 Rich Client .................................................................................................

Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Architecture Blueprints Ein Leitfaden zur Konstruktion von Softwaresystemen mit Java Spring, .NET, ADF, Forms und SOA ISBN-10: 3-446-41201-8 ISBN-13: 978-3-446-41201-9 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41201-9 sowie im Buchhandel 1 1 Grundlegende Architekturkonzepte In diesem Kapitel stellen wir einige theoretische Grundlagen guten Software-Entwurfs aus heutiger Sicht vor. Diese Konzepte lassen sich mit allen modernen Plattformen und Frameworks ähnlich gut umsetzen (wenn auch nicht immer in vollem Umfang) und können als State of the Art des modernen Applikationsdesigns gelten. Design- Guidelines werden mit Design Patterns beschrieben. Dies ist kein Buch für Anfänger. Wir gehen daher davon aus, dass dem Leser die grundlegenden Design-Patterns und -Prinzipien bekannt sind und auch eine Layered Architecture kein Fremdwort ist. Deshalb wollen wir Sie als Leser nicht mit einer bloßen Auflistung von Patterns langweilen, sondern die wichtigsten Enterprise-Archi- tektur-Patterns in ihrem natürlichen Umfeld beschreiben. Für einige der hier nicht beschriebenen, aber trotzdem wichtigen Pattern und Prinzipien verweisen wir auf die gängige Literatur zum Thema (Fowler, 2003), (Gamma et al., 1995), (Eilebrecht et al., 2007). Nach der Lektüre dieses grundlegenden Kapitels sollten dem Leser die wesentlichen Architektur- und Design-Konzepte bekannt sein und ihm beim Lesen der weiteren Kapitel zum besseren Verständnis dienen. 1.1 Enterprise Application Architecture Patterns Ein Design Pattern ist ein existierendes Software-Konstrukt und gleichzeitig eine Re- gel, die beschreibt wie und wann dieses zu erstellen ist. Die Beschreibung dieser Kombination umfasst einen Namen und Erörterungen der Problemstellung und der Lösung. Design Patterns gehen ursprünglich auf den Architekten – nein: kein Software-Ar- chitekt, sondern ein richtiger Häuserbauer – Christopher Alexander zurück, der in seinem Buch „The Timeless Way of Building“ bauliche Maßnahmen, die sich wie- derholten, in Form von Patterns beschrieb. Im Folgenden ein Beispiel einer solchen Pattern-Beschreibung: 1 1 Grundlegende Architekturkonzepte Pattern Name: “An architectural pattern example – Window Place.” Problemkontext: “Everybody loves window seats, bay windows, and big windows with low sills and comfortable chairs drawn up to them. … A room which does not have a place like this seldom allows you to feel comfortable or perfectly at ease. … If the room contains no window which is a ‘place’, a person in the room will be torn between two forces: He wants to sit down and be comfortable. He is drawn toward the light. Obviously, if the comfortable places – those places in the room where you most want to sit – are away from the windows, there is no way of overcoming this conflict. …”. Lösungskontext: “Therefore: In every room where you spend any length of time during the day, make at least one window into a ‘ window place’.” Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides (Gamma et al., 1995) haben dieses Konzept dann Mitte der Neunziger auf die Softwareentwicklung übertragen. Ihr Buch „Design Patterns – Elements of Reusable Object-Oriented De- sign“ gilt als Basis für alle weiteren Beschreibungen von Design Patterns in der Soft- wareentwicklung. Seitdem haben viele Autoren weitere Design Patterns für unter- schiedliche Kontexte (z.B. Strukturpatterns, Refactoring-Patterns) und Programmier- sprachen publiziert. Die Hauptaufgabe von Design Patterns besteht in der Weitergabe und der Wieder- verwendung von Erfahrung. Design Patterns beschreiben Best Practices und Lösun- gen von erfahrenen Designern. Unterschiedliche Technologien und Programmier- sprachen erlauben unterschiedliche Realisierungen einzelner Design Patterns. Viele moderne Frameworks realisieren Design Patterns im Hintergrund und gestatten auch unerfahrenen Programmieren, Anwendungen nach modernen Design-Richtlinien zu erstellen. In der Regel kann jedes Pattern einer bestimmten Schicht (Layer) zugeordnet werden, z.B. dem User-Interface Layer oder dem Domain Layer. Das Pattern bietet dann eine Lösung eines typischen Problems in diesem Layer. Im Folgenden stellen wir einige zen- trale Design Patterns im Kontext des jeweiligen Layers kurz vor. Für tiefergehende Erörterungen sei auf die Original-Literatur verwiesen bzw. auf Literatur, die die ein- zelnen Patterns im Kontext konkreter Programmiersprachen darstellt (z.B. C#, Java). 1.2 Application und Domain Layer Die zentralen Teile der meisten Enterprise-Applikationen sind der Application und der Domain Layer. Hier sind die Business-Logik und die Verknüpfung von Domain- Modulen zu Services angesiedelt. Für die Organisation der Domänenlogik sieht Fowler (Fowler, 2003) drei verschiede- ne Patterns vor: Transaction Script, Domain Model und Table Module. 2 1.2 Application und Domain Layer Fowler beschreibt eine zusätzliche Möglichkeit, die Domänenlogik aufzutrennen, indem er einen Service Layer über ein darunterliegendes Domain Model oder Table Module legt. Diese wichtigen Pattern werden in den folgenden Abschnitten ausführ- lich behandelt. 1.2.1 Transaction Script Transaction Script Das Transaction Script organisiert und unterteilt die Geschäftslogik in einzelne Prozedu- ren, sodass jede Prozedur eine einzelne Anfrage vom Presentation Layer abdeckt. Viele einfache Geschäftsapplikationen können als eine Serie von Einzeltransaktionen angesehen werden. Dies gilt in hohem Maß für klassische Client/Server-Applikatio- nen. Jede Interaktion zwischen Client und Server enthält ein begrenztes Maß an (nicht all- zu komplexer) Geschäftslogik. In den meisten Fällen handelt es sich hierbei um simple Validierungen und Kalkulationen und betrifft nur wenige Entitäts-Typen (Ach- tung: nicht „Einzelobjekte“!) pro Interaktion. Transaction Script kapselt diese Logik pro Interaktion in einzelne Operationen und kommuniziert direkt oder nur über einen schlanken Adapter mit einer relationalen Datenbank. Jede Transaktion hat ihr eigenes Transaction Script. In vielen Fällen ent- spricht ein Transaction Script einer Datenbank-Transaktion. Es gibt zwei Möglichkei- ten, die Transaction-Script-Logik zu modularisieren: Ein Transaction Script pro Operation einer Klasse Ein Transaction Script pro Klasse (Command Pattern) Beide haben Vor- und Nachteile. Beim generischen Command Pattern trägt jede Operation den gleichen Namen (z.B. execute() ); der Klassenname sollte die Se- mantik der Transaktion beschreiben. Beim anderen Ansatz beschreibt der Operati- onsname hingegen die Semantik, womit sich Intention Revealing Interfaces realisie- ren lassen. Das Command Pattern in Kombination mit Memento ist wichtig für Kom- pensationen (Compensating Transaction), wie sie vor allem in einer SOA vorkom- men. Service Ein Service fasst semantisch nahestehende Transaction Scripts als einzelne Service- Methoden zusammen. Diese einzelnen Transaction Scripts delegieren dann an einen Command und Memento realisierenden Helfer Service, der auch für Kompensationen zuständig ist. Im Allgemeinen wird dies ein interner Teil des Application Service selbst sein, um die Einfachheit in diesem Ansatz zu wahren. Ein Applikations-Service realisiert in diesem Blueprint das Transaction Script Pattern. Mehr zur Anwendung dieses Patterns folgt in Abschnitt 1.5.3. 3 1 Grundlegende Architekturkonzepte View User Interface Application Service Client Tier remoting Middle Tier Application DTO Application Assembler Service DAO Factory Validator Domain Infrastructure Persistence Abbildung 1.1 Transaction Script Architecture 1.2.2 Domain Model Domain Model Domain Model beschreibt ein Objektmodell der Problemdomäne, welches Verhalten und Daten umfasst. Das Modell setzt sich aus einem Netzwerk feingranularer Klassen zusammen. Jede einzelne dieser Klassen repräsentiert ein wichtiges Objekt der Geschäftsdomäne. Hierbei kann es sich um etwas so Großes wie einen Konzern oder aber um eine ein- zelne Zeile einer Rechnung handeln.