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

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

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

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

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

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

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

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

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

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

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

Ü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

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

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

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

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

anaptecs JEAF Plattform JEAF Developer Guide

anaptecs JEAF Plattform JEAF Developer Guide anaptecs JEAF Plattform JEAF Developer Guide : JEAF Framework Die technische Grundlage für Applikationen auf Basis der JEAF Plattform bildet das JEAF Framework. Dabei handelt es sich um ein leichtgewichtiges

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

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

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

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

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

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

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

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

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

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

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

Security Technologien in Java EE 6

Security Technologien in Java EE 6 Security Technologien in Java EE 6 Java Forum Stuttgart 2010 Sebastian Glandien Acando GmbH sebastian.glandien@acando.de Agenda I. Einleitung II. Java Authentication SPI for Containers (JSR-196) I. Message

Mehr

Einführung in AOP. Rico Schiekel - 012816 rschiekel@web.de. Agenda. Kernproblem der Objekt Orientierung

Einführung in AOP. Rico Schiekel - 012816 rschiekel@web.de. Agenda. Kernproblem der Objekt Orientierung Einführung in AOP Informatikseminar Rico Schiekel - 012816 rschiekel@web.de Fachhochschule Ravensburg Weingarten Hochschule für Technik und Sozialwesen Einführung in AOP Agenda Kernproblem der Objekt Orientierung

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

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

Oracle Weblogic Administration Grundlagen

Oracle Weblogic Administration Grundlagen Oracle Weblogic Administration Grundlagen Seminarunterlage Version: 1.07 Version 1.07 vom 14. September 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

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

Android Kurs Online Kurs Entwicklung auf Android-Handys

Android Kurs Online Kurs Entwicklung auf Android-Handys Android Kurs Online Kurs Entwicklung auf Android-Handys Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses Modul Eins - Programmierung J2ee 1) Grundlegende Java - Programmierung : Grundlegende

Mehr

-Testen verteilter Anwendungen

-Testen verteilter Anwendungen -Testen verteilter Anwendungen Seminar Simulation und Bildanalyse mit Java im SS04 Konstantin Tjo, Urs Pricking Testen verteilter Anwendungen 1 Übersicht Einführung in verteilte Anwendungen RMI (Remote

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

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

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

11. Enterprise Java Beans Grundlagen der Programmierung II (Java)

11. Enterprise Java Beans Grundlagen der Programmierung II (Java) 11. Enterprise Java Beans Grundlagen der Programmierung II (Java) Prof. Dr. Bernhard Humm Hochschule Darmstadt University of Applied Sciences Sommersemester 2006 Übersicht Grundlagen der Programmierung

Mehr

Kommunikation ist alles

Kommunikation ist alles Kommunikation in verteilten Systemen mit Kommunikation ist alles >> alexander ziegler In einem verteilten System müssen die Anwendungsbestandteile miteinander interagieren nur so funktioniert ein großes

Mehr

Application Server und Continuous Integration

Application Server und Continuous Integration Application Server und Continuous Integration Outline 2 Einleitung Application Server Java EE Enterprise Applikationen vs. Web Applikationen Web Application Life Cycle Servlets JavaServer Pages verschiedene

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

Dieser Artikel bietet eine Einführung in die Konzepte der Lightweight Container und beschreibt das grundlegende Konzept, das Inversion of Control.

Dieser Artikel bietet eine Einführung in die Konzepte der Lightweight Container und beschreibt das grundlegende Konzept, das Inversion of Control. Betrifft: Abnehmen leicht gemacht - Lightweight Container auf dem Vormarsch Autor: Guido Schmutz Art der Info: Whitepaper (Juni 2005) Quelle: Aus unserem TechnoCircle und TTC (Trivadis Technology Center)

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Das Spring Framework eine Einführung

Das Spring Framework eine Einführung Das Spring Framework eine Einführung Sebastian Schelter Softwareengineering Freie Universität Berlin Arnimallee 14 14195 Berlin sebastian@alombra.de Abstract: Eine Einführung in die grundlegenden Konzepte

Mehr

Business Applika-onen schnell entwickeln JVx Framework - Live!

Business Applika-onen schnell entwickeln JVx Framework - Live! Business Applika-onen schnell entwickeln JVx Framework - Live! - Enterprise Applica-on Framework h&p://www.sibvisions.com/jvx JVx ermöglicht in kürzester Zeit mit wenig Source Code hoch performante professionelle

Mehr

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen IN-Q-My Title Company (Name) / 1 Agenda Firmenübersicht ebusiness Evolution InQMy Application Server Architektur Zusammenfassung

Mehr

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung

Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Gegenseitige Beeinflussungen von Testautomatisierung, Testmanagement und Entwicklung Jan Düttmann Archimedon Software + Consulting GmbH & Co. KG Marienstraße 66 32427 Minden Stephan Kleuker Hochschule

Mehr

SpringSource Enterprise & Application Platform: Wo geht die Reise hin?

SpringSource Enterprise & Application Platform: Wo geht die Reise hin? SpringSource Enterprise & Application Platform: Wo geht die Reise hin? Eberhard Wolff Regional Director & Principal Consultant SpringSource Copyright 2007 SpringSource. Copying, publishing or distributing

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

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

Eclipse Smart Client Beyond Eclipse RCP. Christian Campo, compeople, 24.April 2007

Eclipse Smart Client Beyond Eclipse RCP. Christian Campo, compeople, 24.April 2007 Eclipse Smart Client Beyond Eclipse RCP Christian Campo, compeople, 24.April 2007 1 Übersicht Definition / Architektur Smart Client Smart Client mit RCP Gesamtfazit 2 Fat - Thin - Smart Fat Client lokale

Mehr

Clustering von Application Servern am Beispiel von JBoss 3.2

Clustering von Application Servern am Beispiel von JBoss 3.2 Clustering von Application Servern am Beispiel von JBoss 3.2 Cluster Workshop iternum GmbH Alexanderstraße 7 60489 Frankfurt/Main www.iternum.com Agenda Clustertechnik allgemein Was ist Clustering? Gründe

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht.

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht. Technisches Design Inhalt Design Übersicht Menü und DispatcherServlet DWR Servlet Viewer Servlets Controllers Managers Sicherheit Anwendung Architektur Component Diagram Deployment Diagram Komponente Sequence

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

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

Webinar: Einführung in ICEfaces

Webinar: Einführung in ICEfaces Webinar: Einführung in ICEfaces präsentiert von VOIP-Audio ist standardmässig aktiviert Alternatives Einwählen: +41 (0) 415 0008 65 ICESOFT TECHNOLOGIES INC ICESOFT Donnerstag, TECHNOLOGIES 26. März 2009

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

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

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

JSP und Servlet Programmierung

JSP und Servlet Programmierung Seminarunterlage Version: 5.02 Copyright Version 5.02 vom 1. März 2013 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

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

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

EJB3.0 Unit-Testing Reloaded

EJB3.0 Unit-Testing Reloaded EJB3.0 Unit-Testing Reloaded Werner Eberling werner.eberling@mathema.de www.mathema.de Werner Eberling, MATHEMA Software GmbH - EJB3.0 - Unit-Testing Reloaded (G4 - Folie 1) Java Forum Stuttgart 2007 Automatisiertes

Mehr

Komponentenbasierte Softwareentwicklung

Komponentenbasierte Softwareentwicklung Seminar WS04 Komponentenbasierte Softwareentwicklung Karl Pauls Software-Komponente A software component is a unit of composition with contractually specified interfaces and explicit context dependencies

Mehr

jetzt lerne ich J2EE Der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition THOMAS STARK

jetzt lerne ich J2EE Der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition THOMAS STARK jetzt lerne ich J2EE Der einfache Einstieg in die Programmierung mit der Java 2 Enterprise Edition THOMAS STARK Inhaltsverzeichnis jetzt lerne ich Vorwort 17 1 Einleitung 19 1.1 Zentrale Konzepte 20 1.1.1

Mehr

Architektur iterativ auf Basis von OSGi entwickeln

Architektur iterativ auf Basis von OSGi entwickeln Architektur iterativ auf Basis von OSGi entwickeln Ein Vortrag von Sven Jeppsson (syngenio AG) und Karsten Panier (Signal Iduna Gruppe) 1 Inhalt Motivation Architektur Architektur Evolution OSGi Refactoring

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

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

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Lightweight Java in der Automatisierungstechnik

Lightweight Java in der Automatisierungstechnik Lightweight Java in der Automatisierungstechnik Erfahrungen aus dem Anlagenbau Dr. Markus Eiglsperger eig@zuehlke.com Business Driver im Anlagenbau Kosten Modularisierung Vernetzung Agilität Paradigmenwechsel

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 FrOSCon 2009 22./23.

Mehr

Von SAP R/3 zu mysap ERP und NetWeaver

Von SAP R/3 zu mysap ERP und NetWeaver Von SAP R/3 zu mysap ERP und NetWeaver Bremerhaven 06.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. Motivation für SAP NetWeaver 2. SAP R/3 mysap ERP und SAP Business Suite 3. Application Platform T4T

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

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Middleware Versuch einer Einleitung Host dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Mainframe enthält vollständige Anwendung Typ. COBOL, C Mainframe contd.! Nachteile! Mainframe ist teuer

Mehr

Mufid Sulaiman mufidsulaiman@web.de

Mufid Sulaiman mufidsulaiman@web.de Mufid Sulaiman mufidsulaiman@web.de Überblick Frameworks Applikationsentwicklung mit Frameworks Komponentenbasierte Frameworks Einführung in Enterprise JavaBean Einführung in SanFrancisco Vergleich Enterprise

Mehr

Integrating Architecture

Integrating Architecture Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Vorstellung und Einführung Ein beliebiger Zeitpunkt in einem beliebigen Unternehmen

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

Administration und Konfiguration für JBOSS

Administration und Konfiguration für JBOSS Administration und Konfiguration für JBOSS Seminarunterlage Version: 2.03 Version 2.03 vom 7. Mai 2012 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

JSP Grundlagen. JEE Vorlesung Teil 5. Ralf Gitzel ralf_gitzel@hotmail.de

JSP Grundlagen. JEE Vorlesung Teil 5. Ralf Gitzel ralf_gitzel@hotmail.de JSP Grundlagen JEE Vorlesung Teil 5 Ralf Gitzel ralf_gitzel@hotmail.de 1 Übersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht JSP Konzept Model-View-Controller mit JSPs JSP Expression Language EL Literale

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

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Objektorientierte Softwareentwicklung SoSe 15

Objektorientierte Softwareentwicklung SoSe 15 Objektorientierte Softwareentwicklung SoSe 15 Heinz Faßbender Raum E148 Tel. 0241/6009 51913 Email: fassbender@fh-aachen.de www.fassbender.fh-aachen.de FH AACHEN UNIVERSITY OF APPLIED SCIENCES FACHBEREICH

Mehr

Software-Architektur Design Patterns

Software-Architektur Design Patterns Design Patterns Prof. Dr. Oliver Braun Fakultät für Informatik und Mathematik Hochschule München SS 2015 Standardwerk Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides: Design Patterns:

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Aspektorientierte Modellierung

Aspektorientierte Modellierung Aspektorientierte Modellierung Softwaretechnik-Seminar 2002 Thema: Evolutionäre Software Referent: Alexander Winter Gliederung Einführung und Motivation Was ist Aspektorientierte Modellierung? Vorstellung

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

Schritt 4: Hallo Enterprise Bean

Schritt 4: Hallo Enterprise Bean Prof. Dr. Th. Letschert FB MNI JEE Schritt 4: Hallo Enterprise Bean Einstieg: EJBs erzeugen und nutzen Meine erstes EJB Projekt Enterprise Beans sind eine Backend Technologie, die mit unterschiedlichen

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Enterprise Java Beans (EJB)

Enterprise Java Beans (EJB) silbergrau Consulting & Software GmbH Enterprise Java Beans (EJB) Fachhochschule Hagenberg WS 2002 / 2003 Silbergrau Consulting & Software GmbH Dr. Andreas Erlach Inhaltsübersicht Application Server J2EE

Mehr

WebObjects. Dirk Schober Senior Software Trainer AppleServices EMEA. Was ist eigentlich ein Application Server?

WebObjects. Dirk Schober Senior Software Trainer AppleServices EMEA. Was ist eigentlich ein Application Server? Objects Dirk Schober Senior Software Trainer leservices EMEA Fragen über Fragen Was ist eigentlich ein lication? Welche lication gibt es sonst noch? Was kostet sowas? Wer setzt denn eine solche Technologie

Mehr

CORBA. Eine kurze Einführung. Common Object Request Broker Architecture. Ying Lu

CORBA. Eine kurze Einführung. Common Object Request Broker Architecture. Ying Lu CORBA Common Object Request Broker Architecture Eine kurze Einführung Ying Lu Verlauf der Präsentation Was ist CORBA CORBA-Architektur Ein Beispiel CORBA im Einsatz CORBA im Vergleich Was ist CORBA Begriffe

Mehr