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

Größe: px
Ab Seite anzeigen:

Download "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

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

Mehr

Application Frameworks

Application Frameworks Seminar Software Engineering 1 Grundlagen Agenda Spring Framework Dependency Injection Aspektorientierte Programmierung Datenbankanbindung Modell View Controller Sicherheit Spring vs. Java EE Zusammenfassung

Mehr

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de s & Servlet Integration Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Motivation Das Interface Stateful und Stateless s Programmierung einer Stateful

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

Analyse und praktischer Vergleich von neuen Access- Layer-Technologien in modernen Webanwendungen unter Java. Oliver Kalz

Analyse und praktischer Vergleich von neuen Access- Layer-Technologien in modernen Webanwendungen unter Java. Oliver Kalz Analyse und praktischer Vergleich von neuen Access- Layer-Technologien in modernen Webanwendungen unter Java Oliver Kalz Agenda Grundlagen Objektpersistenz Objektrelationales Mapping Performance Fazit

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Oliver Paulus, oliver@code-project.org. 7. Februar 2006. Spring Framework Einführung. Oliver Paulus, oliver@codeproject.org. Was ist Spring?

Oliver Paulus, oliver@code-project.org. 7. Februar 2006. Spring Framework Einführung. Oliver Paulus, oliver@codeproject.org. Was ist Spring? oliver@code-project.org 7. Februar 2006 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2 3 4 5 6 7 8 9 Inhalt 1 2

Mehr

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen

FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen FWP Aktuelle Technologien zur Entwicklung verteilter Java- Anwendungen Sommersemester 2013 Michael Theis, Lehrbeauftragter Java EE Spezifikation definiert ein Programmiermodell für Applikationen die Eigenschaften

Mehr

Rechnernetze Projekt SS 2015

Rechnernetze Projekt SS 2015 30/03/15 Seite 1 Aspektorientierte Programmierung logische Aspekte (Concerns) im Programm separieren Crosscutting Concerns (Ziel: generische Funktionalitäten über mehrere Klassen hinweg zu verwenden -

Mehr

ORACLE Business Components for Java (BC4J) Marco Grawunder

ORACLE Business Components for Java (BC4J) Marco Grawunder ORACLE Business Components for Java (BC4J) Marco Grawunder Gliederung 2 Probleme von J2EE/EJB J2EE-Pattern Lösungsansatz: BC4J Architektur einer BC4J-Anwendung Komponenten Entity Objects View Objects Application

Mehr

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Eclipse Equinox als Basis für Smart Client Anwendungen Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Übersicht Definition / Architektur Smart Client Smart Client mit RCP / Equinox Gesamtfazit

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

Enterprise JavaBeans Überblick

Enterprise JavaBeans Überblick Enterprise JavaBeans Überblick 1. Überblick Java EE 5 und Komponententechnologien 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.

Mehr

G s e a s m a t m ar a ch c i h tek e tur u I und IoC

G s e a s m a t m ar a ch c i h tek e tur u I und IoC Gesamtarchitektur I und IoC Schichten einer Web-Anwendung Initiiert durch J2EE und Spring: Strukturierte Sicht auf UI und Fachlogik (Domäne) Ergibt 5 Schichten: Man unterscheidet Präsentations- und Domänenmodell!

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Herzlich Willkommen! eine praxisnahe Übersicht. Mit Java ins Web - mb@bebox.franken.de. 26.11.2000 (c) Michael Behrendt -

Herzlich Willkommen! eine praxisnahe Übersicht. Mit Java ins Web - mb@bebox.franken.de. 26.11.2000 (c) Michael Behrendt - Herzlich Willkommen! Mit Java ins Web - eine praxisnahe Übersicht 1 Wer bin ich? Michael Behrendt, 21, Nürnberg kurzer Lebenslauf: 1991 Erster Rechner: Commodore C128 1995 Ausbildung zum Datenverarbeitungskaufmann

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Java EE Projektseminar

Java EE Projektseminar Java EE Projektseminar Daniel Alberts & Sonja Subicin Sprachliche Informationsverarbeitung Universität zu Köln Sommersemester 2010 Sitzung Organisatorisches zum Seminar Java EE Projektplanung Defi nition

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Inhaltsverzeichnis. Zusammenfassung Wydler

Inhaltsverzeichnis. Zusammenfassung Wydler Inhaltsverzeichnis 1 Multitier Anwendungen... 2 2 J2EE Komponenten... 2 2.1 J2EE Design Patterns for Performance... 2 2.1.1 Design Patterns... 2 2.1.2 Session Façade... 2 2.1.3 Data Transfer Object (Value

Mehr

UI-Architekturen mit JSF

UI-Architekturen mit JSF www.jsf-academy.com UI-Architekturen mit JSF - JSF ist mehr als nur Syntax - Copyright 2011, Andy Bosch, www.jsf-academy.com Slide 1 Agenda Warum reden wir überhaupt über UI-Architektur? Technologien und

Mehr

Aspektorientierte Middleware Florian Wagner

Aspektorientierte Middleware Florian Wagner Anwendungen der Aspektorientierung (5) Übersicht Middleware? Middleware-Concerns Java 2 Enterprise Edition AO Implementierung AOP & JBoss 2 mid dle ware (mĭd'l-wâr') n. Software that serves as an intermediary

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

Java Frameworks im Vergleich - ADF vs. Grails vs. Spring

Java Frameworks im Vergleich - ADF vs. Grails vs. Spring Java Frameworks im Vergleich - ADF vs. Grails vs. Spring Frank Szilinski esentri software GmbH Karlsruhe Schlüsselworte: ADF, Java, JEE, JSF, Grails, Spring, Open Source, Rapid Application Development

Mehr

EJB Beispiel. JEE Vorlesung 10. Ralf Gitzel ralf_gitzel@hotmail.de

EJB Beispiel. JEE Vorlesung 10. Ralf Gitzel ralf_gitzel@hotmail.de EJB Beispiel JEE Vorlesung 10 Ralf Gitzel ralf_gitzel@hotmail.de 1 Stundenkonzept Gemeinsame Übung Stoff der letzten Stunde wird gemeinsam in einem Beispiel umgesetzt Details werden nochmals erklärt bzw.

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013 GTUG Java Arbeitskreis Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung September 2013 Jürgen Depping CommitWork GmbH Seite 1 Info@CommitWork.de www.commitwork.de Agenda Was ist OmnivoBase?

Mehr

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1

Grid-Systeme. Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit. 07.06.2002 Grid Systeme 1 Grid-Systeme Betrachtung verschiedener Softwareplattformen zur Realisierung von Grids und Vorstellung des Globus Toolkit 07.06.2002 Grid Systeme 1 Gliederung Vorstellung verschiedener Plattformen Globus

Mehr

Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen

Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen Tom Krauß Agenda Begriffsdefinition Verfahren Praktische Beispiele Vergleich und Bewertung Begriffsklärung

Mehr

Java Beans (22.02.2001)

Java Beans (22.02.2001) Component Based Software Development Java Beans (22.02.2001) Stefan Jäger Robert Kalcklösch Veranstalter: M. Bittner W. Koch Inhalt Einführung in Java Die Java Beans Einsatz und Entwicklung von Beans Enterprise

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Übungsaufgabe Transaktion als Middleware

Übungsaufgabe Transaktion als Middleware Übungsaufgabe Transaktion als Middleware und Java Persistence API Client/Server Abstraktes Komponentenmodell Entscheidende Punkte Erweiterung der Invoke-Methode Context-Verwaltung Transaktionsbehandlung

Mehr

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher

Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM. Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher Schlussbewertung FB VI SOFTWAREPROJEKT II WS 09/10 TEAM Alexander Kalden Dominik Eckelmann Marcel Pierry Julian Heise Besha Taher 729631 745097 736477 745011 741297 Inhalt Schlussbewertung... 3 Bewertung

Mehr

OWASP Stammtisch München Sep 2014 XSS und andere Sicherheitslücken aus der Perspektive des Programmcodes

OWASP Stammtisch München Sep 2014 XSS und andere Sicherheitslücken aus der Perspektive des Programmcodes OWASP Stammtisch München Sep 2014 XSS und andere Sicherheitslücken aus der Perspektive des Programmcodes 1 XSS: Cross-Site Scripting 1.) Es gelangen Daten in den Web-Browser, die Steuerungsinformationen

Mehr

Jakarta Turbine Ein Open Source Framework fÿr Webanwendungen. KNF Kongre 2001 Henning P. Schmiedehausen

Jakarta Turbine Ein Open Source Framework fÿr Webanwendungen. KNF Kongre 2001 Henning P. Schmiedehausen <henning@apache.org> Jakarta Turbine Ein Open Source Framework fÿr Webanwendungen Henning P. Schmiedehausen Turbine - ein berblick Open Source unter Apache License 100% pure Java, Java 2 (JDK 1.2+) Servlet-basiertes

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

Der SBB Online-Ticketshop Mit SOA zum Erfolg

Der SBB Online-Ticketshop Mit SOA zum Erfolg Der SBB Online-Ticketshop Mit SOA zum Erfolg BAT 03 Stefan Meichtry, Stefan Becker Bern, den 17.03.2006 SBB Informatik 1 Das Ziel SBB Informatik 2 Agenda Problemraum Lösungsraum Analyse Wir sind hier Synthese

Mehr

Komponentenbasierte Softwareentwicklung mit PHP. Oliver Schlicht - bitexpert

Komponentenbasierte Softwareentwicklung mit PHP. Oliver Schlicht - bitexpert Komponentenbasierte Softwareentwicklung mit PHP Oliver Schlicht - bitexpert Überblick 1. Was ist eine Komponente? 2. Entwicklung eines Beispieldesigns 3. Dependency Injection 4. DI Container Garden 5.

Mehr

JavaEE Grundlagen. Theis Michael - Senior Developer UniCredit Global Information Services S.C.p.A

JavaEE Grundlagen. Theis Michael - Senior Developer UniCredit Global Information Services S.C.p.A JavaEE Grundlagen FWP Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen Theis Michael - Senior Developer UniCredit Global Information Services S.C.p.A Sommersemester 2012 2 Die Java EE

Mehr

Geschäftskomponenten mit EJB 3.1

Geschäftskomponenten mit EJB 3.1 Geschäftskomponenten mit EJB 3.1 Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen Kurt Fastner Sommersemester 2012 Inhalt Was ist EJB Die verschiedenen EJB-Typen/Komponenten Applikationsserver,

Mehr

WebSphere Application Server Installation

WebSphere Application Server Installation WebSphere Application Server Installation und Administration Seminarunterlage Version: 3.04 Copyright Version 3.04 vom 16. Mai 2013 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte

Mehr

Aspektorientierte Programmierung (aspect-oriented programming, AOP)

Aspektorientierte Programmierung (aspect-oriented programming, AOP) Aspektorientierte Programmierung (aspect-oriented programming, AOP) Abstract Die aspektorientierte Programmierung ist ein neues Programmierparadigma, das die Probleme und Nachteile, die aus der prozeduralen

Mehr

Java Message Service im J2EE-Kontext

Java Message Service im J2EE-Kontext Java Message Service im J2EE-Kontext Im Folgenden soll kurz das Konzept der nachrichtenorientierten Kommunikation mit Hilfe von Messaging Services vorgestellt, und im Anschluss deren Einsatzmöglichkeiten

Mehr

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH Erfahrungen und Erkenntnisse Klaus Richarz, HBT GmbH Java Enterprise Edition 5.0 JBoss Seam Konsequenzen für Realisierung Qualitätssicherung Build & Deployment Fazit & Empfehlungen JBoss Seam in Projekten,

Mehr

Was ist Software-Architektur?

Was ist Software-Architektur? Was ist Software-Architektur? Stephan Schulze Martin Knobloch 28.04.2004 Seminar: Software-Architektur Humboldt Universität zu Berlin sschulze knobloch@informatik.hu-berlin.de Gliederung Begriffsbestimmung

Mehr

5. Programmierschnittstellen für XML

5. Programmierschnittstellen für XML 5. Programmierschnittstellen für Grundlagen Dr. E. Schön FH Erfurt Sommersemester 2015 Seite 135 Programmierschnittstelle Notwendigkeit: Zugriff auf -Daten durch Applikationen wiederverwendbare Schnittstellen

Mehr

Contexts and Dependency Injection. W3L AG info@w3l.de

Contexts and Dependency Injection. W3L AG info@w3l.de 1 Contexts and Dependency Injection W3L AG info@w3l.de 2015 2 Inhaltsverzeichnis Teil 1: Motivation Teil 2: Inversion of Control Teil 3: Contexts and Dependency Injection Teil 4: Beispiel zurück 3 Motivation

Mehr

Next generation open source BPM JBoss jbpm 4. Java Forum Stuttgart 02.07.2009 bernd.ruecker@camunda.com

Next generation open source BPM JBoss jbpm 4. Java Forum Stuttgart 02.07.2009 bernd.ruecker@camunda.com Next generation open source BPM JBoss jbpm 4 Java Forum Stuttgart 02.07.2009 bernd.ruecker@camunda.com Bernd Rücker / bernd.ruecker@camunda.com / 2 Guten Morgen Berater, Trainer, Coach Softwareentwickler

Mehr

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany Enterprise JavaBeans Einführung Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Inhalt Allgemeines Motivation Rollen Aufbau einer EJB Arten von Beans Enterprise JavaBeans

Mehr

Bridging the Gap between the Enterprise and You. Who s the JBoss now?

Bridging the Gap between the Enterprise and You. Who s the JBoss now? or Who s the JBoss now? Patrick Hof (patrick.hof@redteam-pentesting.de) Jens Liebchen (jens.liebchen@redteam-pentesting.de) RedTeam Pentesting GmbH http://www.redteam-pentesting.de 16. DFN-Cert Workshop

Mehr

Existierende Systeme I Bibliotheken & Frameworks

Existierende Systeme I Bibliotheken & Frameworks Projektgruppe: Generierung von Webanwendungen aus visuellen Spezifikationen Existierende Systeme I Bibliotheken & Frameworks Von Christian Schneider Paderborn, den 18.06.2004 Übersicht Motivation Dynamische

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Whitepaper Walkyre Enterprise Resource Manangement

Whitepaper Walkyre Enterprise Resource Manangement Whitepaper Walkyre Enterprise Resource Management Seite 1 Whitepaper Walkyre Enterprise Resource Manangement Stand 15.11.2004 Inhalt 1. Hinweis... 2 2. Grundsätzliches zur Funktionalität... 3 3. Der Walkyre-Client...

Mehr

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des

Mehr

JDO Java Data Objects

JDO Java Data Objects JDO Java Data Objects Ralf Degner, Chief Consultant Ralf.Degner@poet.de Agenda POET Motivation Geschichte Einführung Architekturen FastObjects POET Gegründet 1993 Zwei Produktlinien esupplier Solutions:

Mehr

Architecture Blueprints

Architecture Blueprints Architecture Blueprints Daniel Liebhart, Peter Welkenbach, Perry Pakull, Mischa Kölliker, Michael Könings, Markus Heinisch, Guido Schmutz Ein Leitfaden zur Konstruktion von Softwaresystemen mit Java Spring,.NET,

Mehr

Anwendung eines Enterprise Java Beans

Anwendung eines Enterprise Java Beans Anwendung eines Enterprise Java Beans EJB Server EJB Container Remote Interface Home Interface EJB Object Der EJB Container kümmert sich um die Kommunikation des Beans mit anderen Komponenten, wobei er

Mehr

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg COMMON OBJECT REQUEST BROKER ARCHITECTURE Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg Gliederung Motivation Was ist CORBA? Object Management Architecture (OMA ) Interface Definition Language

Mehr

Microsoft.NET und SunONE

Microsoft.NET und SunONE Microsoft.NET und SunONE, Plattformen und Application Service Providing Agenda Einordnung.NET und SunONE Kurzvorstellung Gegenüberstellung Zusammenfassung ASP (Application( Service Providing) ) und Ausblick

Mehr

Warum EJB Technologie (1)?

Warum EJB Technologie (1)? Datenbanken und Informationssysteme 2 SS 2004 Prof. Dr. Stefan Böttcher Universität Paderborn Datenbanken und Informationssysteme 2 - Prof. Dr. Stefan Böttcher - SS 2004 Folie EJB - 1 Warum EJB Technologie

Mehr

Java Beans Enterprise Java Beans. Eine kurze Einführung in die Welt der Bohnen

Java Beans Enterprise Java Beans. Eine kurze Einführung in die Welt der Bohnen Java Beans Enterprise Java Beans Eine kurze Einführung in die Welt der Bohnen Java Beans Einführung Stefan Sauer Was ist ein Java Bean? Beans sind Komponenten. Einmal schreiben Überall wiederverwerten

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Überblick 1.Einfürung in die Multi-Tier Architektur 2.Ausgangspunkt und Probleme 3.Rundgang durch die Architektur 4.Architektur

Mehr

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.

J2EEKurs. J2EE eine Plattform für betriebliche Anwendungen. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10. J2EE eine Plattform für betriebliche Anwendungen Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Plattform Betriebliche Anwendung J2EE Kontrahenten J2EE im Überblick Was ist

Mehr

OSGi. The Next Generation Java Service Platform. SOA - The Java Way or My classpath is killing me. Michael Greifeneder

OSGi. The Next Generation Java Service Platform. SOA - The Java Way or My classpath is killing me. Michael Greifeneder Michael Greifeneder OSGi The Next Generation Java Service Platform SOA - The Java Way or My classpath is killing me Bilder von Peter Kriens W-JAX Keynote 2007 und Neil Bartletts Getting Started with OSGi

Mehr

Design Patterns 2. Model-View-Controller in der Praxis

Design Patterns 2. Model-View-Controller in der Praxis Design Patterns 2 Model-View-Controller in der Praxis Design Patterns Oft Schablonen für eine Klassenstruktur... aber nicht immer! Dahinterliegende Konzepte wichtiger als wörtliche Umsetzung Pattern werden

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

Der lokale und verteilte Fall

Der lokale und verteilte Fall Lokale Beans Der lokale und verteilte Fall RemoteClient Lokaler Client (JSP) RemoteSession/Entity-Bean Lokale Session/Entity-Bean 2 Lokale Beans Die bisher vorgestellten EJBswaren immer in der Lage auf

Mehr

5. Programmierschnittstellen für XML

5. Programmierschnittstellen für XML 5. Programmierschnittstellen für für Medientechnologen Dr. E. Schön Wintersemester 2015/16 Seite 146 Notwendigkeit: Programmierschnittstelle Zugriff auf -Daten durch Applikationen wiederverwendbare Schnittstellen

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Der Java Server beinhaltet Container für EJB, Servlet und JSP, darüber hinaus unterstützt er diejee 1.3 Version.

Der Java Server beinhaltet Container für EJB, Servlet und JSP, darüber hinaus unterstützt er diejee 1.3 Version. hehuvlfkw Oracle 9iApplication Server (9iAS) fasst in einem einzigen integrierten Produkt alle Middleware-Funktionen zusammen, die bisher nur mit mehreren Produkten unterschiedlicher Anbieter erreicht

Mehr

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de FH LU JEE Vorlesung SS 2010 Ralf Gitzel ralf_gitzel@hotmail.de 1 Einführung + Organisatorisches Ralf Gitzel ralf_gitzel@hotmail.de 2 Dozent Dr. Ralf Gitzel Promotion an der Universität Mannheim in Wirtschaftsinformatik

Mehr

Integration von Web Services in J EE Anwendungen mit XFire. 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire

Integration von Web Services in J EE Anwendungen mit XFire. 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire Integration von Web Services in J EE Anwendungen mit XFire 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire univativ : = Umsetzung durch Studenten und Young Professionals.

Mehr

OO Programmiersprache vs relationales Model. DBIS/Dr. Karsten Tolle

OO Programmiersprache vs relationales Model. DBIS/Dr. Karsten Tolle OO Programmiersprache vs relationales Model Vorgehen bisher Erstellen eines ER-Diagramms Übersetzen in das relationale Datenmodell Zugriff auf das relationale Datenmodell aus z.b. Java ER rel. Modell OO

Mehr

Applikationsentwicklung Architekturübungen

Applikationsentwicklung Architekturübungen Applikationsentwicklung Architekturübungen Aufgabe : Systeme und Subsysteme Gegeben ist das umfangreiche Softwaresystem eines modernen Passagierflugzeuges von der Steuerung und Navigation bis zum Bordunterhaltungssysstem

Mehr

Web-Programmierung (WPR)

Web-Programmierung (WPR) Web-Programmierung (WPR) Vorlesung XII. Vergleich Server-Plattformen mailto:wpr@gruner.org 1 Technologien Perl/CGI Einsatzgebiete: Kleine Websites, semiprofessioneller Bereich Pro's: Plattform/Serverneutralität

Mehr

OERA OpenEdge Reference Architecture. Mike Fechner PUG Infotag 19. Mai 05 Frankfurt

OERA OpenEdge Reference Architecture. Mike Fechner PUG Infotag 19. Mai 05 Frankfurt OERA OpenEdge Reference Architecture Mike Fechner PUG Infotag 19. Mai 05 Frankfurt Überblick OERA Separated presentation and integration layers Common business logic with advanced models Data access abstracted

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Programmierung von Client/Server- Anwendungen

Programmierung von Client/Server- Anwendungen Programmierung von Client/Server- Anwendungen Komponenten des Web-Containers (Java EE) SoSe2015 Prof. Dr. Andreas Schmietendorf 1 Übersicht zur Vorlesung Entwicklung der Java Enterprise Edition Servlets,

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Rich Internet Applications, Flex & Mate. (Ja, das ist Grafische Benutzeroberflächen!) 18.03.2010 Jakob Külzer jakob.kuelzer@gmail.

Rich Internet Applications, Flex & Mate. (Ja, das ist Grafische Benutzeroberflächen!) 18.03.2010 Jakob Külzer jakob.kuelzer@gmail. Rich Internet Applications, Flex & Mate (Ja, das ist Grafische Benutzeroberflächen!) 18.03.2010 Jakob Külzer jakob.kuelzer@gmail.com Überblick Mein Thema im Überblick 1. Definitionen 2. Rich Internet Applications

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

Bekannte Lösungen für bekannte Probleme benutzen. Entwurf auf höherer Abstraktionsebene als bei Programmiersprachen

Bekannte Lösungen für bekannte Probleme benutzen. Entwurf auf höherer Abstraktionsebene als bei Programmiersprachen Michael Saecker Bekannte Lösungen für bekannte Probleme benutzen Entwurf auf höherer Abstraktionsebene als bei Programmiersprachen Gemeinsames Vokabular für Designer 2 http://www.clickpix.de/sommer/architektur.jpg

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

Internetanbindung von Datenbanken

Internetanbindung von Datenbanken Internetanbindung von Datenbanken Oracle Application Server Oracle Application Server - 1 Gliederung Einführung Oracle Application Server (OAS) Praxis- und Diplomarbeitenverwaltung LiveHTML Kritik Becker,

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Model View Controller Pattern

Model View Controller Pattern Christian Vogt HAW Hamburg 19. Dezember 2011 Inhaltsverzeichnis 1 Prolog Einleitung Entwurfsmuster andere Muster 2 Model-View-Controller Hintergrund Konzept Umsetzung 3 Beispiele Überblick Beispiel in

Mehr

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013

Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Fujitsu BeanConnect TM V3.0 Software 0 FUJITSU LIMITED 2013 Die Herausforderung: Hostanbindung Viele Unternehmen besitzen Mainframe- und Legacy-Anwendungen, so genannte Enterprise Information Systems (EIS),

Mehr

Enterprise JavaBeans

Enterprise JavaBeans Enterprise JavaBeans Sebastian Pipping 18. Dezember 2006 This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. Teil I J2EE J2EE Was ist J2EE? Was ist J2EE?

Mehr

CARL HANSER VERLAG. Erika Horn, Thomas Reinke. Softwarearchitektur und Softwarebauelemente Eine Einführung für Softwarearchitekten 3-446-21300-7

CARL HANSER VERLAG. Erika Horn, Thomas Reinke. Softwarearchitektur und Softwarebauelemente Eine Einführung für Softwarearchitekten 3-446-21300-7 CARL HANSER VERLAG Erika Horn, Thomas Reinke Softwarearchitektur und Softwarebauelemente Eine Einführung für Softwarearchitekten 3-446-21300-7 www.hanser.de Inhalt Vorwort...IX 1 Einleitung... 1 1.1 Software

Mehr

Advanced Software Engineering WS0910 Kapitel4. Dr. Dominik Haneberg

Advanced Software Engineering WS0910 Kapitel4. Dr. Dominik Haneberg Advanced Software Engineering WS0910 Kapitel4 Dr. Dominik Haneberg ASPEKT-ORIENTIERTE ENTWICKLUNG 08.02.2010 Advanced Software Engineering 2 Einführung Aspektorientierte Programmierung (AOP) ist ein Programmierparadigma,

Mehr