Performance-Modellgenerierung für Java- Enterprise-Edition-Anwendungen auf Basis von Messdaten einer Application-Performance- Management-Lösung

Größe: px
Ab Seite anzeigen:

Download "Performance-Modellgenerierung für Java- Enterprise-Edition-Anwendungen auf Basis von Messdaten einer Application-Performance- Management-Lösung"

Transkript

1 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master s Thesis in Informatik Performance-Modellgenerierung für Java- Enterprise-Edition-Anwendungen auf Basis von Messdaten einer Application-Performance- Management-Lösung Bernhard Alexander Koch-Kemper

2 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master s Thesis in Informatik Performance-Modellgenerierung für Java- Enterprise-Edition-Anwendungen auf Basis von Messdaten einer Application-Performance- Management-Lösung Performance Model Generation for Java Enterprise Edition Applications using Measurement Data of an Application Performance Management Solution Bearbeiter: Bernhard Alexander Koch-Kemper Aufgabensteller: Prof. Dr. Helmut Krcmar Betreuer: Felix Willnecker Abgabedatum: 12. Mai 2015

3 Erklärung Ich versichere, dass ich diese Master s Thesis selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. Garching b. München, den 12. Mai 2015 Ort, Datum Bernhard Koch-Kemper

4 Zusammenfassung Die Performance von Anwendungssystemen (ausgedrückt durch Metriken wie der Antwortzeit, dem Durchsatz oder dem Ressourcen-Verbrauch) ist ein entscheidendes Qualitätsmerkmal und beeinflusst sowohl die Akzeptanz der Endanwender als auch die für den Betrieb des Systems nötigen Hardware-, Software- oder Energiekosten. Die Durchführung und Koordination aller Aktivitäten zur Sicherstellung der Performance von Anwendungssystemen bezeichnet man als Performance Management Work (PMW). Die Werkzeuge, die hierfür zur Verfügung stehen, unterteilen sich in zwei Klassen bezüglich der Lebenszyklusphasen des Anwendungssystems: Den Systementwicklungsprozess und den IT-Betrieb. Während im Systementwicklungsprozess insbesondere Performance-Modelle weit verbreitet sind, mit denen das Anwendungssystem abstrahiert modelliert wird, um Performance-Metriken vorherzusagen, werden im IT-Betrieb sogenannte Application-Performance-Management-Lösungen oft eingesetzt. Hiermit kann das laufende Anwendungssystem vermessen werden, um Erkenntnisse über Flaschenhälse, hohe Ressourcen-Auslastungen oder mögliche Verstöße gegen Service Level Agreements zu erhalten. Da viele Performance-Modellierungsansätze mit Messdaten des laufenden Anwendungssystems angereichert werden, stellt sich die Frage nach einer Verknüpfung der beiden Werkzeugklassen. Bisherige Modellgenerierungsansätze basieren vor allem auf spezifischen Eigenentwicklungen mit denen die Daten erhoben werden. Dies hemmt die Durchführung von PMW in der Praxis, da man dort auf Standard-Lösungen setzt. Der in dieser Arbeit entwickelte Ansatz erzeugt automatisiert Performance-Modelle auf Basis von Messdaten einer Application-Performance-Management-Lösung. Stichworte: Performance-Modell, Performance-Messung, Application Performance Management, Kapazitätsplanung, Palladio Component Model, Software Performance Engineering. Abstract Performance of enterprise applications (represented by metrics like response time, throughput or resource consumption) is an important quality criterion which influences both the acceptance by end users and the cost of the software, hardware and energy. The implementation of activities and coordination to ensure that performance criteria are met is called performance management work (PMW). Tools for PMW are separated in two different classes which are defined by the life-cycle phases of the enterprise application: system development and IT operation. While in system development abstract performance models of the system are used to predict performance metrics, application performance management solutions are in widespread use for IT operations. Running applications can thereby be monitored to detect bottlenecks, high resource consumption or service level agreement breaches. Because a lot of performance models generation approaches are using monitoring data to enrich the parameters, a closer integration of both tool classes is desirable. Current performance model generation approaches often use custom monitoring solutions which constrain the PMW activities in practice as standard solutions are preferred there. This thesis develops an approach to automatically generate performance models by using monitoring data of an application performance management Solution. Keywords: Performance Model, Performance Measurement, Application Performance Management, Capacity Planning, Palladio Component Model, Software Performance Engineering. III

5 Inhaltsverzeichnis Zusammenfassung... III Inhaltsverzeichnis... IV Abbildungsverzeichnis... VI Tabellenverzeichnis... VII Abkürzungsverzeichnis... VIII 1 Einleitung Motivation von Performance Management Work Ziele der Arbeit Forschungsfragen Aufbau der Arbeit Grundlagen Allgemeine Begriffe und Definitionen Performance und Metriken Die Java-EE-Spezifikation Performance-Modelle und Werkzeuge Queueing Networks Layered Queueing Networks Queueing Petri Nets Palladio Component Model Application Performance Management und Werkzeuge Dynatrace Daten-Extraktion Übersicht verwandter Ansätze: Erstellung von Performance-Modellen auf Grundlage von Messdaten Queuing Network Models Layered Queueing Network Models Queuing Petri Net Models Palladio Component Model Weitere verwandte Ansätze Übersicht und Zusammenfassung der Ansätze Integration von Dynatrace-Messdaten ins PMWT-Framework Erweiterung des bestehenden Datenmodells Evaluation der Modellgenerierung SPECjEnterprise2010-Benchmark IV

6 4.1.1 Detailbetrachtung der Orders Domain Testumgebung Dynatrace-Overhead-Analyse CPU-Overhead Response-Time-Overhead Vergleich mit den bestehenden Ergebnissen Konstante Anzahl an CPU-Kernen und Steigerung des Workloads Erhöhung der CPU-Kerne und Steigerung des Workloads Reduktion der CPU-Kerne und konstanter Workload Zusammenfassung und Ausblick Literaturverzeichnis Anhang A DVD V

7 Abbildungsverzeichnis Abbildung 1: Schema des PMWT-Frameworks mit Dynatrace-Schnittstelle... 4 Abbildung 2: Typische Architektur eines betrieblichen Anwendungssystems... 7 Abbildung 3: Service Time, Service Demand und Respone Time... 9 Abbildung 4: Ressourcen-Profil Abbildung 5: Java-EE-Architektur Abbildung 6: Queueing Network Model Abbildung 7: Layered Queuing Network Model Abbildung 8: Queueing Petri Net Model Abbildung 9: Palladio Component Model Abbildung 10: PCM Respository Model und RDSEFF Abbildung 11: PCM System Model Abbildung 12: PCM Resource Environment Model Abbildung 13: PCM Allocation Model Abbildung 14: PCM Usage Model Abbildung 15: Dynatrace PurePath Abbildung 16: Klassendiagramm der bestehenden Softwarearchitektur Abbildung 17: Neues auf Messdaten-Aggregation basierendes PMWT-Datenmodell Abbildung 18: Klassendiagramm der neuen Softwarearchitektur Abbildung 19: Architektur des SPECjEnterprise2010-Benchmarks Abbildung 20: SPECjEnterprise2010 Orders Domain Abbildung 21: Gemessene und simulierte Ergebnisse für Szenario Abbildung 22: Gemessene und simulierte Ergebnisse für Szenario Abbildung 23: Gemessene und simulierte Ergebnisse für Szenario VI

8 Tabellenverzeichnis Tabelle 1: Zeitgewinn durch parallelen Datenexport Tabelle 2: Testumgebung der Evaluation Tabelle 3: CPU-Overhead durch Instrumentierung auf dem SUT Tabelle 4: Response-Time-Overhead durch Instrumentierung auf dem SUT Tabelle 5: Abkürzungen der Evaluationsrepräsentation Tabelle 6: Gemessene und simulierte Ergebnisse für Szenario Tabelle 7: Gemessene und simulierte Ergebnisse für Szenario Tabelle 8: Gemessene und simulierte Ergebnisse für Szenario VII

9 Abkürzungsverzeichnis API Application Programming Interface APM Application Performance Management AwS Anwendungssystem CBML Component Based Modeling Language CPU Central Processing Unit, Prozessor CSV Comma Separated Value EJB Enterprise Java Beans GUI Graphical User Interface HDD Hard Disk Drive, Festplatte HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure I/O Input/Output JDBC Java Database Connectivity JMS Java Message Service JMX Java Management Extension JPA Java Persistence API JSF JavaServer Faces JSP JavaServer Pages JVM Java Virtual Machine LQN Layered Queueing Networks MBeans Managed Beans MEM Memory, Arbeitsspeicher ms Millisekunde NET Network, Netzwerk PCM Palladio Component Model PMW Performance Management Work PMWT Performance Management Work Tools POJO Plain Old Java Objects QN Queueing Network QPN Queueing Petri Net SEFF Service Effect Specification RDSEFF Resource Demanding Service Effect Specification REST Representational State Transfer RT Response Time s Sekunde SEFF Service Effect Specification SLA Service Level Agreements SPE Software Performance Engineering SPEC Standard Performance Evaluation Corporation SQL Structured Query Language UML Unified Modeling Language VM Virtuelle Maschine XML Extensible Markup Language VIII

10 1 Einleitung Dieses Kapitel dient der Einführung der in dieser Masterarbeit behandelten Thematik und motiviert diese. Es werden aus der Motivation Ziele formuliert (Abschnitt 1.2) und drei konkrete Forschungsfragen abgeleitet (Abschnitt 1.3). Der Aufbau der weiteren Kapitel und die verwendete Methodik wird in Abschnitt 1.4 dargelegt. 1.1 Motivation von Performance Management Work Bei der Planung und Entwicklung von Anwendungssystemen (AwS) spielt die Performance eine entscheidende Rolle. Sie wird durch Metriken wie der Antwortzeit, dem Durchsatz oder dem Ressourcenverbrauch beschrieben (Becker et al. 2013). Bereits kleinere Verschlechterungen der Performance (beispielsweise wenn die Antwortzeit von Webseitenaufrufen größer wird) können signifikante betriebswirtschaftliche Auswirkungen nach sich ziehen und Umsatzeinbußen für Verkaufsplattformen bedeuten (Gomez 2015). Performance beeinflusst somit sowohl die Akzeptanz bei Endanwendern als auch die Hardware-, Software- und Energie- Kosten des AwS. Die Koordination und Durchführung aller Aktivitäten, um die Performance von AwS zu gewährleisten, subsumiert man in der Literatur unter dem Begriff Performance Management Work (PMW) (Brunnert et al. 2014). Unterteilt werden kann hierbei in zwei Teilbereiche bezüglich der Lebenszyklusphasen eines AwS: - Das Software Performance Engineering (SPE) nach Smith/Williams (1997); Woodside/Franks/Petriu (2007) für den Systementwicklungsprozess und das - Application Performance Management 1 (APM) nach Menascé (2002) für den (laufenden) IT-Betrieb. Problematisch ist, dass die Systementwicklung und der IT-Betrieb teilweise gegensätzliche Ziele verfolgen. Aufgaben der Systementwicklung sind beispielsweise die Implementierung neuer Funktionalitäten, die Sicherstellung einer skalierbaren und robusten Software-Architektur sowie die effiziente Nutzung von Ressourcen (Vögele/Danciu/Kroß 2014). Der IT-Betrieb hingegen ist daran interessiert, den Zustand einer stabil laufenden Umgebung zu erhalten. Hierzu werden Hard- und Software-Änderungen (z.b. Updates) evaluiert, Störungen und Flaschenhälse des Systems analysiert und des Weiteren überwacht, dass mögliche vertraglich festgehaltene Verstöße gegen Service Level Agreements (SLA) aufgespürt oder vermieden werden (Vögele/Danciu/Kroß 2014). Obwohl also die Integration beider Aktivitäten sehr sinnvoll erscheint, da die Performance eines Anwendungssystems ein maßgebliches Qualitätsmerkmal ist, werden die Vorgehens- 1 Der Buchstabe M in APM steht in der Praxis teilweise nur für Monitoring und wird vom Begriff Management subsumiert. 1

11 und Arbeitsweisen oft nur separat betrachtet und nicht ganzheitlich integriert (Brunnert et al. 2014). Als Folge gibt es sowohl für das SPE als auch für APM eigene Klassen an Software- Werkzeugen und Modellierungssprachen. Beispielhafte Werkzeuge des SPE bauen oft auf sogenannten Performance-Modelltypen auf. Das Palladio Component Model (PCM) (Becker/Koziolek/Reussner 2009), SPE ED (Smith/Williams 1997) oder das Queueing Petrinet Modeling Environment (QPME) (Kounev/Dutz 2009) sind Beispiele solcher Werkzeuge, die den Nutzer bei der Modellierung auf Basis eines Modelltypens unterstützen. Anhand verschiedener Eingabe-Parameter wie der Softwarearchitektur, Hardwareinfrastruktur oder dem Nutzerverhalten können so Modelle generiert werden, die mittels analytischer Lösung oder Simulation eine Vorhersage bezüglich der Performance-Metriken des AwS treffen können. Im Bereich APM existieren eine Reihe von (kommerziellen) Software-Werkzeugen (Gartner 2013) wie zum Beispiel Dynatrace (Compuware 2015b), SteelCentral (Riverbed 2015), AppDynamics (AppDynamics 2015), New Relic APM (New Relict 2015) oder das aus dem Universitätsumfeld stammende Kieker (van Hoorn/Waller/Hasselbring 2012c, 2012a). Die APM-Werkzeuge unterstützen den IT-Betrieb dadurch, dass mithilfe eines detaillierten AwS-Monitorings während des Zugriffs durch Endnutzer die Messdatengrundlage geschaffen wird, um das Wissen über das Auftreten und die Ursachen von Performance-Problemen im AwS zu gewinnen (Gartner 2013). Obwohl die Performance ein gemeinsames Ziel des SPE und APM ist, sind Werkzeuge für integrierte PMW-Aktivitäten derzeit selten und bieten ein Potenzial für zukünftige Entwicklungen (Brunnert et al. 2014). Ein Ansatz findet sich in Brunnert/Vögele/Krcmar (2013), welcher unter dem Namen Performance Management Work Tools (PMWT, fortiss (2015)) weiterentwickelt wird. Eine Eigenentwicklung ermöglicht hierbei das Erheben von Messdaten einer laufenden Java-EE-Applikation. Auf Basis dieser Messdaten können dann automatisiert mit einem Generator PCM-Performance-Modell der Applikation generiert werden. Jedoch setzt die Datenerhebung nicht auf ein Standard-Werkzeug im Bereich APM auf. Aufgrund ihrer Verbreitung, des besseren Supports und der umfangreicheren Testbasis wäre eine Messdaten-Erzeugung über APM-Werkzeuge aus Unternehmenssicht mit Vorteilen verbunden gegenüber einer Eigenentwicklung. 1.2 Ziele der Arbeit Das erste Ziel der Masterarbeit ist es, die aus dem ersten Kapitel motivierte Fragestellung nach einer Verknüpfung von APM- und SPE-Werkzeugen als aktuelle Forschungslücke wissenschaftlich darzulegen. Hierfür müssen die existierenden Ansätze in der Literatur für die Performance-Modellgenerierung auf Basis von Messdaten evaluiert werden. Aktuelle Publikationen wie Brunnert et al. (2014) geben bereits Hinweise darauf, dass umfassende Modellgenerierungsansätze mit Messdaten aus Standardsoftware selten sind. Der bestehende Modellgenerator der PMWT soll deshalb um eine APM-Schnittstelle erweitert werden, um diese Lücke zu schließen. Hiermit sollen generierte Messdaten von APM-Werkzeugen verwendet werden können, um automatisiert PCM-Performance-Modelle zu erzeugen. Bei- 2

12 spielhaft für diverse APM-Lösungen soll diese Erweiterung des Modellgenerators für das konkrete Werkzeug Dynatrace technisch umgesetzt und getestet werden. Als Folge müssen anschließend die Vor- und Nachteile der APM-Erweiterung des Modellgenerators analysiert werden. Hierbei wird ein generiertes Performance-Modell mit Dynatrace- Messdaten den bestehenden Ansätzen gegenüber gestellt, um zu entscheiden, aus welcher Architektur sich ein Modell mit einer höheren Genauigkeit oder Funktionalität ergibt. Dies soll anhand einer exemplarischen Java-EE-Anwendung geschehen, wie sie im betrieblichen Kontext oft zu finden sind. 1.3 Forschungsfragen Aus den Zielen ergeben sich drei Forschungsfragen: Forschungsfrage 1: Welche automatischen und auf Messdatenbasierende Performance- Modell-Generierungsansätze existieren in Literatur und Praxis? Das Ziel bei der Beantwortung dieser Forschungsfrage ist es, themenverwandte Literatur aufzuzeigen. Die eigene Erweiterung des Modellgenerators soll somit als Forschungslücke eingeordnet werden können. Zudem soll der Literaturüberblick zeigen, in welchen Bereichen und für welche Technologien Messdatenbasierende Modell-Generierungsansätze existieren, um weitere Anwendungsmöglichkeiten aufzuzeigen. Existierende (Teil-)Ansätze, aufbauend zum Beispiel auf dem Kieker-Framework von van Hoorn/Waller/Hasselbring (2012c), sollen für eine Anforderungsanalyse der eigenen Modellgeneratorerweiterung evaluiert werden, um hohe Flexibilität und Anpassbarkeit der zu entwickelnden Schnittstellen zu gewährleisten. Dies soll insgesamt dazu dienen, die PMWT- Modellgeneration unabhängig von der Datenerhebungsmethode zu konstruieren. Automatisierte Ansätze wie der von Brunnert/Vögele/Krcmar (2013) sind besonders in der Praxis den manuellen Ansätzen vorzuziehen, da der Aufwand einer manuellen Modellierung oft einem späteren Nutzen übersteigt (Koziolek 2010). Zudem lassen sich automatisierte Ansätze einfacher vergleichen und auf andere AwS übertragen, da hierbei keine zusätzliche Benutzereingabe notwendig ist. Es entsteht somit weniger Spielraum bei der Auswertung von Performance-Ergebnissen. Insgesamt gilt es somit folglich bei der Literaturrecherche darum, auf Folgende Fragen Antworten zu finden: - Welche Messdaten wurden in welcher Granularität erhoben? - Welche Monitoring-Lösung wurde benutzt und welche Schnittstelle dabei verwendet? - Welches Performance-Metamodell wurde in welchem Umfang (möglich sind auch Teilmodelle) verwendet? - Wie hoch ist der Grad der Automatisierung bei der Modellgenerierung? Wie leicht sich das existierende Vorgehen zur Modellgenerierung aus der Literatur auf andere APM-Werkzeuge und Performance-Modelle übertragen lässt, sollte ebenfalls analysiert werden. Dies dient dazu, die Flexibilität der eigenen APM-Erweiterung einzuordnen. 3

13 Forschungsfrage 2: Welche Anpassungen an das bestehende Performance-Modell- Generierungs-Framework (PMWT) sind notwendig, um Standard-APM-Werkzeuge als Messdatenquelle zu nutzen? Das Ziel dieser Forschungsfrage ist es herauszufinden, wie der bestehende Modellgenerator basierend auf der eigenen Erhebung von Messdaten angepasst werden muss, damit auch extrahierte Messdaten aus anderen APM-Werkzeugen für die Generierung von Performance- Modelle benutzt werden können. Hierfür muss die Konzeption und Implementierung umgesetzt werden. Abbildung 1 zeigt eine solche Erweiterung schematisch. Der Generator greift für die Modellgenerierung auf Daten zu, die mittels einer Persistence- Service-Schnittstelle bereitgestellt werden. Während der erste Ansatz von Brunnert/Vögele/Krcmar (2013) die Messdaten für diese Schnittstelle über CSV-Dateien 1 aggregiert und in einer Datenbank bereitstellt, existiert auch eine Alternative, die Messdaten für die Modellgenerierung direkt als MBeans überträgt (Brunnert/Neubig/Krcmar 2014; Oracle 2015c). Extrahierte Messdaten aus Dynatrace müssen also auf die Persistence-Service- Schnittstelle transformiert werden. Die Orientierung an einem der vorhandenen Ansätze über CSV-Dateien oder MBeans muss bewertet werden. Da diese Arbeit - stellvertretend für allgemeine APM-Standardlösungen - eine Messdatenerhebung mit Dynatrace implementiert, müssen die von Dynatrace bereitgestellten Möglichkeiten einer Daten-Extraktion analysiert werden. Die von Dynatrace zur Verfügung stehenden Schnittstellen wie REST Interfaces (Fielding 2000; Compuware 2015j) müssen verglichen Abbildung 1: Schema des PMWT-Frameworks mit Dynatrace-Schnittstelle Quelle: Willnecker et al. (2015) 1 Comma-separated values 4

14 werden, um an den PMWT-Modellgenerator anknüpfen zu können. Forschungsfrage 3: Welche Unterschiede in Genauigkeit und Funktionalität ergeben sich durch den Einsatz einer Standard-APM-Lösung gegenüber selbstentwickelten Werkzeugen zur Messdatenerhebung? Die bestehende Ansätze aus Brunnert/Vögele/Krcmar (2013) mit der eigenen Methode für die Messdatenerhebung generieren bereits Performance-Modelle mit einem Fehler von nur 1-20% in der Antwortzeit und weniger als 10% in der CPU-Auslastung bei Nutzung einer exemplarischen Java-EE-Applikation. Das Ziel dieser Forschungsfrage ist die Beantwortung, wie exakt die Performance-Modelle mithilfe der Messdaten eines Standard-APM-Werkzeugs werden. Zum einen handelt es sich hierbei in der Regel um lizenzpflichtige Industrie-Lösungen, was technisch auf sehr ausgereifte Produkte deuten könnte, die einen Zugewinn in der Genauigkeit der Performance- Modelle bringen könnten. Zum anderen muss jedoch auch bedacht werden, dass es sich im Vergleich zu der PMWT-Messdatenerhebungsmethode um sehr viel umfangreichere Werkzeuge und keine Speziallösung zur Modellgenerierung handelt, was zu schlechten Performance-Vorhersagen führen könnte. 1.4 Aufbau der Arbeit Die Masterarbeit ist in mehrere Kapitel eingeteilt. Eine Struktur basierend auf den definierten Forschungsfragen wird im Folgenden gegeben: Zu Beginn der Arbeit müssen alle relevanten Fachbegriffe definiert und erläutert werden. Hierzu gehören Definitionen bezüglich der zu untersuchenden Anwendungssysteme, der Performance-Modellierung und Metriken sowie der in dieser Arbeit verwendeten Technologien. Diese Grundlagen werden in Kapitel 2 beschrieben. Um die erste Forschungsfrage bezüglich der wissenschaftlichen Einordnung dieser Arbeit beantworten zu können, bietet sich eine Literaturrecherche angelehnt nach Webster/Watson (2002) an. Dieser Literaturüberblick der vorhandenen Ansätze ist in Abschnitt 2.4 zu finden. Hauptbestandteile einer Klassifizierung bezüglich Messdaten-basierter Performance- Modellgenerierung leiten sich direkt aus der Forschungsfrage ab (vgl. Abschnitt 1.3). Für die Beantwortung der zweiten Forschungsfrage, bei der es um die Integration der Dynatrace-Messdaten in das PMWT-Modellgenerierungsframework geht, wird zuerst geprüft, welche für die Performance-Modellierung-relevanten Daten man wie mit Dynatrace (als Fallbeispiel für APM-Werkzeuge) extrahieren kann (Abschnitt 2.3). Danach sollten die vorhandenen Schnittstellen oder Datenstrukturen im PMWT-Framework ausgewählt bzw. adaptiert werden, damit die extrahierten Messdaten aus Dynatrace verwendet werden können (Kapitel 3). Um die dritte Frage zu beantworten und die Unterschiede in Genauigkeit und Funktionalität zu vergleichen, sollte ein an Hevner et al. (2004) angelehntes Controlled Experiment durchgeführt werden. Der Test sollte zudem ein typisches betriebliches Anwendungssystem simulieren, da APM-Werkzeuge dort primär eingesetzt werden. Als Ausgangspunkt zum 5

15 Plausibilisieren der Ergebnisse mit vorhandenen Messungen wird die für die Eigenentwicklung von Brunnert/Vögele/Krcmar (2013) bereits verwendete Java-EE-Applikation SPECjEnterprise2010 verwendet. Die Evaluation der Ergebnisse findet in Kapitel 3.3 statt. Ferner wird die Arbeit in Abschnitt 5 zusammengefasst und ein Ausblick gegeben, an was zukünftig weitergeforscht werden kann. 6

16 2 Grundlagen 2.1 Allgemeine Begriffe und Definitionen Anwendungssystem und Anwendungssoftware Der Begriff Anwendungssystem (oder Informationssystem) bezeichnet ein System, welches für bestimmte Anwendungsgebiete erstellt wurde und umfasst die hierfür nötige Gesamtheit an Hard- und Software. Schwarzer/Krcmar (2010) trennen hiervon den Begriff der Anwendungssoftware, welche das eigentliche Programm beschreibt und auf der Hardware eingesetzt wird, die dem Anwendungssystem zur Verfügung steht. Anwendungssoftware wird oft auch als Anwendung, Applikation oder kurz als App bezeichnet. Eine Anwendungssoftware besteht ferner wiederum aus vielen einzelnen Operationen (in der Systementwicklung oft Methode genannt), die kleine Funktionalitäten implementieren und sich gegenseitig (verschachtelt) aufrufen können. Logisch oder programmatisch zusammenhängende Operationen können zu einer sogenannten (Geschäfts-) Transaktion zusammengefasst werden, welche die gesamte Abfolge an Operationsaufrufen (den Kontrollfluss) von einer Anfrage bis zur Antwort beschreibt. Eine oder auch mehrere Transaktionen sind hierbei immer für die Ausführung der von der Anwendungssoftware bereitgestellten Funktionalität nötig (Smith 2007b, S. 294). Anwendungssysteme im betrieblichen Kontext sind heutzutage oft verteilte webbasierte Anwendungen, die parallel von Endnutzer genutzt werden können und mittels Netzwerkverbindungen untereinander kommunizieren bzw. Daten austauschen können. Unterteilt werden hierbei in der Regel drei Schichten (Leff/Rayfield 2001): Die Präsentations-, die Geschäftslogik/Business- und die Datenhaltungsschicht (vgl. Abbildung 2). Abbildung 2: Typische Architektur eines betrieblichen Anwendungssystems Quelle: Wischer (2014) 7

17 Das Ziel der Datenhaltungsschicht ist die (langfristige) Speicherung von Daten (Persistierung). Hierfür werden in der Praxis oft Datenbanksysteme eingesetzt. Aufbauend auf der Datenhaltungsschicht arbeitet die Businessschicht, welche sich um die Anwendungslogik und die Prozessierung von Informationen kümmert. Die Präsentationsschicht hingegen beinhaltet keine Geschäftslogik aber baut auf der Businessschicht auf. Die Schicht ist ausschließlich für die (grafische) Aufbereitung der prozessierten Daten zuständig. Sie dient den Benutzern des Anwendungssystems als Schnittstelle der Interaktion. Aus Gründen der Skalierbarkeit besteht die Hardware, die für die Anwendung nötig ist, oft nicht mehr aus monolithischen sondern kleineren verteilten Serversystemen. Mithilfe sogenannter Load Balancer können zum Beispiel Benutzeraufrufe auf verschiedene Hardwarekomponenten umgeleitet werden, sodass die Last gleichmäßig verteilt wird. Komponentenbasierte Anwendungssysteme Der Grundgedanke von komponentenbasierten Anwendungssystemen ist die Unterteilung der Anwendung in logisch geschlossene Einheiten, die jeweils eine bestimmte Funktionalität implementieren. Komponenten können hierbei Schnittstellen für andere Komponenten anbieten, Abhängigkeiten zu anderen Komponenten aufweisen und voneinander unabhängig auf verschiedenen Hardwaresystemen laufen. Die Einteilung in Komponenten kann somit eine Kostenersparnis induzieren, weil weniger Programmcode neu geschrieben werden muss, da Komponenten wiederverwendet werden können (Bruegge/Dutoit 2004, S. 664). Ebenso erhöht die Einteilung in Komponenten aber auch die Flexibilität des Anwendungssystems und kann zudem den Softwareentwicklungsprozess insgesamt unterstützen: Dadurch, dass Entwickler sich auf die Erstellung einzelner Komponenten spezialisieren können, sinkt die Komplexität des Entwicklungsprozesses, da für das Zusammensetzen ebendieser Komponenten und die Spezifikation der Schnittstellen eigene Rollen (die sogenannten Software- Architekten) bestimmt werden (Koziolek 2010). Der komponentenbasierte Softwareentwicklungsprozess wird ist der Literatur oft als Component Based Software Engineering (CBSE) bezeichnet (Jifeng/Li/Liu 2005). Ressourcen Woodside/Franks/Petriu (2007) definieren Ressourcen als Systemelemente, die eine Leistung erbringen können, die von anderen Systemelementen nachgefragt wird. Die in dieser Arbeit primär betrachteten Ressourcen sind Hardware-Ressourcen. Beispiele sind die in Anwendungssystemen verbauten Einheiten wie der Prozessor (CPU), der Arbeitsspeicher (MEM), die Festplatten (HDD oder oft auch als Input/Output (I/O) abgekürzt) oder die Netzwerkanbindung (NET). Neben Hardware-Ressourcen existieren auch logische Ressourcen wie Semaphoren, wie sie beispielsweise eingesetzt werden um die Anzahl an maximalen Verbindungen auf eine Datenbank zu limitieren. Man spricht von einem Ressourcenbedarf, wenn eine Operation für ihren Aufruf eine oder mehrere Ressourcen benötigt. Beispielsweise hat der Operationsaufruf eines Sortieralgorithmus einen CPU-Bedarf um die nötigen mathematischen Vergleichsoperationen durchzuführen sowie einen Bedarf an Arbeitsspeicher, um auf die zu sortierenden Zahlen zuzugreifen. Wenn Ressourcen benutzt werden, spricht man oft davon, dass sie ausgelastet sind. Dies bezieht sich immer auf eine Zeitperiode. Wenn beispielsweise einer von vier CPU-Kernen von einer Operation benutzt wird, so beträgt die CPU-Auslastung 25% in der betrachteten Zeitper- 8

18 iode. Da Auslastungen zwischen sehr kleinen Zeitintervallen stark schwanken können, werden sie in der Regel immer für größere Zeitintervalle (z.b. mindestens 1s-Intervalle) angegeben Performance und Metriken Service Time, Service Demand, Response Time und Durchsatz Wenn durch den Aufruf einer Operation Ressourcen allokiert werden müssen, können diese bereits durch die (parallele) Ausführung von anderen Operationen belegt sein. Solange bis die Ressource freigegeben wird, muss die Ausführung der Operation dann Pausieren. Abbildung 3 veranschaulicht einen solchen Operationsaufruf. Direkt beim Start der Operation ist die CPU-Ressource belegt und die Ausführung muss deshalb für vier Zeiteinheiten warten (Queueing Time). Danach kann die CPU-Ressource allokiert werden. Diese folgende Zeitperiode wird als sogenannte Service-Zeit (Service Time) bezeichnet. Nach der ersten Allokation der CPU nutzt die Operation einen HDD-Aufruf, was ebenfalls wieder erst in einer Wartezeit resultiert. Später nach der zweiten Service Time auf der CPU-Ressource ist die Operation abgeschlossen. Die Länge des Intervalls von Start bis Ende bezeichnet man als sogenannte Antwortzeit oder Response Time (RT) der Operation. Differenziert werden kann zudem noch zwischen der Service Time und dem Service Demand (kurz: Demand) einer Operation. Die verschiedenen Service Times einer Operation werden hierbei je Ressource als Service Demand summiert. In Abbildung 3 bezeichnet man also die Summe der beiden CPU-Service- Start Ende CPU HDD Wartezeit Service Time Abbildung 3: Service Time, Service Demand und Respone Time Quelle: Angelehnt an Menasce/Dowdy/Almeida (2004) Times als CPU-Service-Demand (CPU-Demand) der Operation. Der HDD-Service-Demand entspricht der HDD-Service-Time. Für Transaktionen werden gerne Response Times angegeben, da dies oft die Zeit widerspiegelt, die ein Benutzer auf die Beantwortung seiner Systemanfrage warten muss. Da die Benutzeranfrage oft über die Netzwerk beim System ankommen, muss zwischen einer Serverund einer Clientseitigen Response Time unterschieden werden. Während die Clientseitige Response Time die ganze Zeit beinhaltet, die vom Abschicken der Nutzeranfrage bis zu dem Ankommen der Antwort bei dem Nutzer vergeht, misst die Serverseitige Response Time nur 9

19 die Zeit vom Eintreffen der Nutzeranfrage am Anwendungssystem bis zum Abschicken der Antwort durch das System. Es wird also nicht mitberechnet, wie lange die Übermittlung der Anfragen und Antworten über das Netzwerk dauert. Jedoch hat das Netzwerk einen sehr großen Einfluss auf die Clientseitige Response Time, welche um ein Vielfaches höher sein kann als die Serverseitige Response Time. Da diese Arbeit sich später auf die Nutzung der CPUund nicht der Netzwerk-Ressourcen fokussiert, ist im Folgenden immer die Serverseitige Response Time gemeint. Bezüglich Response Time muss außerdem der sogenannte Hockey-Stick-Effekt (Grinshpan 2012, S. 53) beachtet werden. Bei Erhöhung der gleichzeitig zu bearbeitenden Operationen steigt die Response Time hierbei in der Regel bis zu einer Ressourcen-Auslastung von 70-80% relativ linear, danach aber exponentiell an, was grafisch im Koordinatensystem einem Hockey-Schläger ähnelt. Dies ist oft zurückzuführen auf Programmcode der nicht ausreichend für die parallele Prozessierung optimiert wurde oder bei dem aufgrund eingeschränkter Ressourcen (z.b. CPU oder MEM) ein Flaschenhals entsteht, da bei einer Auslastung von 70-80% die Wahrscheinlichkeit auf viele gleichzeitige parallele Operationsausführung in der Regel sehr hoch ist. Die Rate, mit der Anfragen an das System fertig bearbeitet werden, bezeichnet man als Durchsatz (Throughput). Der Durchsatz wird hierbei in Operationen pro Zeitintervall gemessen (Menasce/Dowdy/Almeida 2004, S ). Es ist darauf zu achten, dass das Zeitintervall (z.b. eine Sekunde oder 10min) genauso wie die zu messenden Operationen wohldefiniert sind und z.b. nicht der Durchsatz basierend auf unterschiedlichen Zeiteinheiten verglichen wird. Auch möglich ist, dass die Durchsatzberechnung auf Basis von Transaktionen anstatt Operationen (vgl. Abschnitt 2.1) stattfindet. Manchmal kann der Ressource Demand (D) einer Ressource je Operation (wie der CPU- Demand) nicht direkt mithilfe eines Werkzeuges ermittelt werden. Wenn sowohl der Durchsatz (X) der Operation als auch die Gesamt-Auslastung des Systems für diese Ressource (U) zur Verfügung stehen, kann der Ressourcen-Bedarf approximativ mithilfe des Service Demand Laws (Menasce/Dowdy/Almeida 2004) ermittelt werden: D = U X. Performance Die Performance eines Anwendungssystems (oder von einzelnen Transaktionen des Systems) wird in der Regel durch Metriken wie die Response Time, des Durchsatzes und der Ressourcen-Auslastung beschrieben (Becker et al. 2013). Die Performance ist somit abhängig von verschiedenen Variablen wie der Anzahl der Benutzer bzw. der Frequenz an Nutzeranfragen an das System, dem spezifischen Nutzungsverhalten der Benutzer und dem Ressourcenbedarf der für die Nutzung des Systems verwendeten Anwendungssoftware (Cortellessa/Di Marco/Inverardi 2011). Zudem ist die Performance ein wichtiges Qualitätsmerkmal des Anwendungssystems, welches über den betrieblichen Erfolg mitentscheidend sein kann (Gomez 2015). 10

20 Um die Performance bereits im Systementwicklungsprozess und nicht erst nach Erstellung des fertigen Systems zu berücksichtigen, schlägt Smith (2007a) das Software Performance Engineering (SPE) vor. Hierbei wird der Entwicklungsprozess in mehrere Zyklen unterteilt für den zugehörige Performance-Ziele definiert werden. Mithilfe von Modellen wird für jeden Zyklus überprüft, ob die Ziele mit den entwickelten Lösungen (z.b. ein entwickelter Algorithmus) erreicht werden. Erst dann wird mit einem neuen Zyklus begonnen. Woodside/Franks/Petriu (2007) benennen die vor allem in der Industrie verwendete und auf Messdaten basierende Berücksichtigung von Performance im Entwicklungsprozess. Hierbei werden erst sehr spät im Prozess verschiedene Lasttests durchgeführt, die bereits auf fertig entwickelten (Teil-)Komponenten ausgeführt werden. Durch die Erstellung von Lastprofilen (Operation Profiles) wird hierbei versucht, das System mit künstlichen Stimuli (ähnlich wie im erwarteten Produktiveinsatz) auszuführen, um mögliche Performance-Probleme erkennen zu können. Als Folge plädieren die Autoren für eine Erweiterung des Software Performance Engineerings und eine Konvergenz beider Ansätze, sodass die im SPE verwendeten Modelle beispielsweise mit Parametern aus den Lasttests angereichert werden. Ressourcen-Profil Den Ressourcenverbrauch und die Performance eines Anwendungssystems kann man nur bestimmen, wenn sowohl die Hard- als auch die Software zusammen betrachtet wird. Insbesondere die Hardwareumgebung ist jedoch oft sehr variabel, da beispielsweise verschiedene Kunden die Anwendungssoftware auch unterschiedliche Server betreiben, auf denen das System betrieben wird. Ressourcen-Profile sind Modelle, die für eine bestimmte Anwendungssoftware erstellt werden und Aussagen über Ressourcen- und Energieverbrauch sowie Performance-Metriken treffen können (Brunnert/Wischer/Krcmar 2014). Sie sind bezüglich des Inputs parametrisierbar, um den verschiedenen Hardwareumgebungen, Nutzerzahlen und dem unterschiedlichen Nutzerverhalten eines Anwendungssystems Rechnung zu tragen (vgl. Abbildung 4). - Nutzerzahl - Nutzerverhalten - Hardwareumgebung - Response Time - Durchsatz - Ressourcen-Auslastung - Energieverbrauch Abbildung 4: Ressourcen-Profil Quelle: Angelehnt an Brunnert/Wischer/Krcmar (2014) Im betrieblichen Kontext kann ein Ressourcen-Profil beispielsweise vom Software-Hersteller für eine Anwendungssoftware erstellt werden. Potenzielle Kunden können das Ressourcen- Profil anfordern und durch individuelle Parametrisierung der Input-Parameter herausfinden, wie zufriedenstellend die Anwendungssoftware bezüglich der Output-Parameter betrieben werden kann. So kann ein Ressourcen-Profil zudem auch bei der Kapazitätsplanung des Unternehmens helfen, da zum Beispiel schon vor dem Kauf des Systems eine Aussage über eine Erweiterung oder Reduzierung der Hardware getroffen werden kann. 11

21 2.1.2 Die Java-EE-Spezifikation Da viele der in dieser Arbeit besprochenen Anwendungssysteme auf der Java-EE-Plattform aufbauen, werden die wichtigsten Merkmale im Folgenden kurz zusammengefasst. Die Java Enterprise Edition (Java EE 1 ) (Oracle 2013) dient als Middleware, um komplexe, verteilte Anwendungssysteme zu entwickeln. Es wird hierbei die aus dem CBSE bekannte Unterteilung eines Systems in Komponenten sowie eine Trennung der Präsentations-, die Geschäftslogik/Business- und der Datenhaltungsschicht unterstützt (vgl. Abschnitt 2.1). Die Komponenten werden hierbei entweder in einem Applikationsserver (Application Server) oder clientseitig ausgeführt. Im Folgenden wird die Einteilung des Container-Modells genauer beschreiben (vgl. Abbildung 5). Applet Container Applets sind (grafische) Komponenten, die typischerweise im Webbrowser ausgeführt werden. Möglich ist aber auch eine Nutzung in anderen Anwendungen, wenn diese das Applet Programmiermodell nutzen oder die Nutzerinteraktion mit dem Java-EE-System auf Basis von HTTP-Webseiten (Oracle 2013, S. 8) stattfindet. Die Nutzung des Systems auf Basis von HTTP-Webseiten ist der in dieser Arbeit ausschließlich behandelte Anwendungsfall. In beiden Fällen werden Anfragen an den Web Container und nicht an den EJB Container oder die Datenbank direkt gesendet. Application Client Container Der Application Client Container läuft ebenfalls clientseitig. Hiermit werden lokale Applikationen bezeichnet, die mit dem Web-, dem EJB-Container und der Datenbank kommunizieren können (Oracle 2013). Da sich diese Masterarbeit auf Anwendungssysteme konzentriert, die Serverseitig auf Basis von Webseiten benutzt werden, wird auf den Application Client Container nicht näher eingegangen. 1 Java EE wurde früher als J2EE abgekürzt. 12

22 Web Container Die Hauptkomponenten des Web Containers sind JavaServer Pages (JSPs) und Servlets (vgl. Abbildung 5). Während JSPs rein für die grafische Repräsentation von Informationen zuständig sind, also die Aufgabe der Präsentationsschicht, sind Servlets auch für die Weiterleitung von Anfragen und Antworten zuständig. Durch Nutzung von Servlet-Filtern kann beim Eintreffen einer Anfrage und bei der zugehörigen Antwort weitere eigene Programmlogik in den Ablauf der Transaktion integriert werden (Oracle 2013, S. 53). Die Messung der Response Time einer Transaktion kann somit beispielsweise mit der Differenz der Zeitstempel von Antwort und Anfrage berechnet werden. Der Web Container läuft Serverseitig und kann mit dem EJB Container kommunizieren. Abbildung 5: Java-EE-Architektur Quelle: Oracle (2013, S. 6) 13

23 EJB Container Die Serverseitigen EJB Container sind für die Geschäftslogik zuständig, welche in Form von Enterprise Java Beans (EJB) implementiert wird. Ähnlich wie mit den Servlet-Filtern können mit sogenannten EJB Interceptors Performance-Messdaten ermittelt werden, indem weitere Programmlogik beim Aufruf von EJB-Operationen integriert wird. EJBs nutzen Informationen aus der Datenhaltungsschicht, welche wie in Abbildung 5 üblicherweise in Form einer Datenbank dargestellt umgesetzt wurde. Hierfür können EJBs zur Persistierung die sogenannte Java Persistence API (JPA, Oracle (2015k)) nutzen. Java Persistence API (JPA) Die Java Persistence API (JPA) ist nicht Java-EE-spezifisch und kann auch außerhalb von Java-EE-Umgebungen genutzt werden. Da JPA aber im Rahmen der eigenen Implementierung in dieser Arbeit verwendet wird folgt eine kurze Beschreibung. Der Nutzen der JPA-Schnittstelle liegt in der Abbildung von Java-Objekten auf eine relationale Datenbank, was man als Object Relational Mapping (Oracle 2015p) bezeichnet. Die Schnittstelle wird hierbei von einem Persistence Provider implementiert. Der Java-EE- Applikationsserver Glassfish (Glassfish 2015) basiert beispielsweise auf der JPA- Implementierung des EclipseLink-Providers (Eclipse 2015) und kann somit JPA- Funktionalität direkt anbieten. Durch Annotationen der zugehörigen Java-Klassen, oft als Plain Old Java Objects (POJOs) bezeichnet, werden die Objekte dieser Klassen für die Persistierung gekennzeichnet. Mittels Konfigurationsdateien, in denen unter anderem auch die Datenbankverbindung definiert wird, können die Objekte so zur Laufzeit in die Datenbank persistiert werden, ohne, dass der Entwickler sich explizit über das Datenbankschema oder die SQL-Abfragen Gedanken machen muss. Ferner können nicht nur einzelne Objekte, sondern auch komplexe Objektstrukturen komfortabel persistiert werden. JPA legt hier weitere Annotationen fest, mit denen Attribute (bzw. Verweise auf andere Java-Klassen) gekennzeichnet werden. Schlussendlich ist auch ein Laden/Wiederherstellen der persistierten Objekte ebenso einfach möglich, sodass die persistierten Objekte in der Datenbank wieder in Java-Laufzeitobjekte überführt werden. 2.2 Performance-Modelle und Werkzeuge Im Software Performance Engineering (vgl. Abschnitt 2.1.1) werden Performance-Modelle dafür verwendet, um im Systementwicklungsprozess Aussagen über Performance-Ziele treffen zu können. Hierbei wird das zu untersuchende Anwendungssystem abstrahiert in Form eines Performance-Modells repräsentiert. Dieses Modell besitzt Möglichkeiten der Parametrisierung um spezifische variable Einflussfaktoren, die Auswirkungen auf die Performance des Systems haben, zu spezifizieren. Je nach Art des Modells können dies beispielsweise die Hardwareumgebung, der Ressourcen-Verbrauch von Operationen oder das Nutzerverhalten sein. Somit ist ein Performance-Modell insbesondere als Mitttel geeignet, das Ressourcen- Profil eines Anwendungssystems abzubilden (Brunnert/Wischer/Krcmar 2014). Um mithilfe des parametrisierten Performance-Modells Aussagen über Performance-Metriken und Ressourcen-Auslastungen des Anwendungssystems zu gewinnen, kann dieses simuliert oder mathematisch gelöst werden. Während die mathematische Lösung in der Regel deutlich 14

24 schneller Ergebnisse erzeugt als eine Simulation, lassen sich komplexe Modellierungen hiermit oft nicht lösen. Performance-Modelle werden heutzutage in der Regel mit Werkzeugen erstellt, die bei der Modellierung unterstützen und bauen auf dem Prinzip der Meta-Modellierung auf. Die Modellierung basiert oft auf den klassischen Modellierungsnotationen (Cortellessa/Di Marco/Inverardi 2011, S ) wie beispielsweise - Markov Processes, - Queuing Networks, - Layered Queuing Networks, - Stochastic Petri Nets oder - Process Algebras. Dies ermöglicht es den Werkzeugen, bereits erforschtes Wissen über die mathematische Analyse oder die Simulation anzuwenden. Zudem können die Werkzeuge die Notation erweitern und so die Modellierung besser unterstützen. Meta-Modelle, die nicht auf einer der klassischen Modellierungsnotation aufbauen (wie zum Beispiel das Palladio Component Model) existieren ebenfalls. Neuere Entwicklungsansätze wie das CBSE können hiermit besser als mit den klassischen Modellierungstypen abgebildet werden. Im Folgenden werden Queueing Networks (Abschnitt 2.2.1), Layered Queuing Networks (Abschnitt 2.2.2), Queueing Petri Nets (Abschnitt 2.2.3) und das Palladio Component Model (Abschnitt 2.2.4) vorgestellt. Dies dient als Grundlage dazu, die eigene APM-Erweiterung des PMWT-Frameworks sowie die in der Literatur existierenden Ansätze später besser beschreiben zu können Queueing Networks Wenn Operationen eines Anwendungssystems ausgeführt werden (zum Beispiel durch die Nutzerinteraktion mit einer Web-Applikation), wird dafür eine bestimmte Menge an Hardware-Ressourcen (oft CPU oder HDD) benötigt. Da diese Ressourcen nicht unbegrenzt zur Verfügung stehen, muss beim Prozessieren der Operation oft auf Ressourcen gewartet werden. Queueing Networks (QN) bilden diesen grundlegenden Sachverhalt mithilfe sogenannter Queued Center ab (Cortellessa/Di Marco/Inverardi 2011, S ). Ein Queued Center (vgl. Abbildung 6) besteht aus dem sogenannten Ressourcen-Server (als Kreis modelliert) und einer davor geschalteten Warteschlange. Der Server stellt hierbei die Ressource (z.b. CPU) dar, die durch Aufträge (Jobs) belegt werden kann. Da in der Regel mehrere Aufträge gleichzeitig Zugriff auf eine Ressource haben wollen, werden sie in einer Warteschlage vor dem Server eingereiht. Unmittelbar nachdem ein Auftrag vom Server bearbeitet wurde, wird mittels Scheduling-Strategien wie First Come First Served oder Last Come First Served der nächste Auftrag aus der Warteschlage bestimmt, der den Ressourcen- Server belegt. Wenn ein Auftrag von einem Center abgearbeitet wurde, traversiert er im gerichteten Graphen weiter. Mittels Verzweigungen und annotierten Wahrscheinlichkeiten (p, (1-p)) kann Nichtde- 15

25 terminismus modelliert werden. Des Weiteren kann mit Delay Nodes eine Wartezeit definiert werden, bevor Aufträge weitergeleitet werden (beispielsweise um die Latenz einer Netzwerkverbindung zu modellieren). Die Erzeugung von Aufträgen im QN kann auf zwei Arten erfolgen: In Form eines offenen oder geschlossenem QN. In offenen Queueing Networks existieren ein Source- und ein Sink- Node. Während im Source Node neue Auftrtäge erzeugt werden, gelten Aufträge beim Eintreffen am Sink Node als abgearbeitet. In geschlossenen Queueing Networks existieren stattdessen Terminal Nodes. Beim Eintreffen eines Auftrages an einem Terminal Node verweilt der Auftrag für eine gewisse Zeitspanne lang (dies spiegelt die Think Time eines Benutzers wieder) bevor er als abgearbeitet gilt und ein neuer Auftrag an genau diesem Terminal Node erzeugt wird. p Queued Center Queued Center 1-p Source Node Sink Node Neben der Modellierung der Elemente muss das QN auch parametrisiert werden, um Aussagen über Performance-Metriken treffen zu können. Hierbei sind verschiedene Möglichkeiten denkbar (Cortellessa/Di Marco/Inverardi 2011, S ). Für die Queue Center ist beispielsweise neben einer maximalen Warteschlangen-Länge die Service Time wichtig, die die Länge der Belegung durch einen Auftrag angibt. Für die Delay Nodes muss ebenso eine Wartezeit definiert werden. Zudem sollten alle Parameter abhängig von definierten Auftrags-Klassen sein, um beispielsweise zu modellieren, dass verschiedene Aufträge verschiedene Service Time eines Queue Centers belegen Layered Queueing Networks Delay Node Abbildung 6: Queueing Network Model Quelle: Neubig (2014) Bei traditionellen Queueing Networks aus Abschnitt werden Anwendungssysteme typischerweise durch eine Menge verbundener Queued Center, verschiedener Auftrags-Klassen und einer Workload-Beschreibung modelliert. Dies macht es schwer, die heute verbreiteten komponentenbasierten AwS zu modellieren (Cortellessa/Di Marco/Inverardi 2011, S ). Layered Queueing Networks (LQN) (Franks et al. 1995; Rolia/Sevcik 1995) stellen eine Erweiterung der Queueing Networks dar, die durch die Einführung von Schichten (Layers) dem komponentenbasierten Paradigma Rechnung trägt und zudem eine flexiblere Zuordnung von diesen Komponenten auf Hardware-Ressourcen erlaubt. 16

26 LQNs bestehen aus Processors (als Kreis modelliert) und Tasks (als Parallelogramme modelliert), welche aus ein oder mehreren Entries bestehen. Während Processors die Hardware- Ressourcen modellieren, bilden Tasks die logischen Elemente wie Software-Komponenten oder Datenbanken ab. Die Anordnung ist hierbei hierarchisch in Ebenen, sodass höher angeordnete Elemente nur auf darunterliegende zugreifen dürfen. An unterster Ebene befinden sich folglich immer die für das AwS modellierten Hardware-Ressourcen (Cortellessa/Di Marco/Inverardi 2011, S. 46). In Abbildung 7 ist dies beispielsweise eine einzelne CPU. In LQNs besitzen sowohl die Processors als auch die Tasks die aus QNs bekannten vorgeschalteten Warteschlagen mit einer spezifizierten Länge und Scheduling-Strategie. Client [Z = 10s] Client [m=500] Entry 1 [s=4, s=2] Act. 1 [s=1] & Act. 2 [s=1] Act. 3 [s=1] [2, 1] [2.5, 0] & Act. 1 [s=0] Act. 4 [s=2] Entry 2 Entry 3 Entry 4 [s=2, s=1] [s=1, s=2] [s=2, s=2] Entry 5 [s=3] CPU [m=4] Abbildung 7: Layered Queuing Network Model Quelle: Neubig (2014); Cortellessa/Di Marco/Inverardi (2011, S. 46, 48) Die Multiplizität m spezifiziert sowohl für Processors als auch für Tasks die Anzahl an gleichzeitig zur Verfügung stehenden Slots. Für Processors ist das zum Beispiel die Anzahl der CPU-Kerne während man für Tasks so einen Thread-Pool realisieren kann. Entries modellieren die Operationen in den Tasks. Hat ein Task mehrere Entries werden diese der Reihe nach abgearbeitet. Ebenso kann ein Entry selbst aus mehreren Phasen bestehen, was durch eine Liste ( [ ] ) an Service Times s modelliert wird. In Abbildung 7 besteht Entry 1 beispielswelche aus zwei Phasen, von denen die erste Phase 4 und die zweite 2 Service Times des Processors CPU verbraucht (Neubig 2014, S. 17). Durch die Annotation an den gerichteten Kanten der Entries wird der Zugriff auf andere logische Elemente je Phase eines Entries modelliert. Entry 1 greift im Beispiel in seiner ersten Phase 2 mal auf Entry 2 und 2,5 mal auf Entry 3 zu während Entry 1 in seiner zweiten Phase nur 1 mal auf Entry 2 zugreift. 17

27 Neben der bereits bei Entries erwähnten Abarbeitung in Phasen, steht mit Aktivitätsgraphen noch ein Element zur Verfügung, welches i.d.r. für komplexe Kontrollflüsse basierend auf Nebenläufigkeit verwendet wird (Cortellessa/Di Marco/Inverardi 2011, S. 48). Task 4 in Abbildung 7 wurde hierzu als Aktivitätsgraph modelliert. Mit + und & werden hierbei Forks bzw. Joins modelliert, also Elemente der Verzweigung und der Synchronisation. Reference Tasks sind in LQNs die Tasks, die auf der obersten Schicht modelliert werden und so keine Anfragen von anderen Elementen entgegen nehmen. Reference Tasks werden benutzt, um Nutzerverhalten zu modellieren. Hierzu wird anstatt einer Service Time s eine Think Time Z definiert. Die von diesem Reference Task benutzte Hardware-Ressource (der Processor) dient der Modellierung des Nutzer-Pools (vgl. den Task mit Namen Client in Abbildung 7) Queueing Petri Nets Queueing Petri Nets (QPN) wurden von Bause (1993) eingeführt und kombinieren die aus Abschnitt beschriebenen QNs mit den aus der Informatik vielseitig verwendeten Petri- Netzen (Murata 1989). Kounev/Dutz (2009) beschreiben QPNs als sinnvolle Erweiterung von QNs, da sie die von Petri-Netzen bekannten Eigenschaften von gleichzeitiger Ressourcen- Allokation, Nebenläufigkeit und Elemente zur Synchronisation besitzen, was sie für die Modellierung moderner AwS interessant macht. Die aus der Petri-Netz-Theorie bekannten (mathematischen) Grundlagen eignen sich ferner auch zur qualitativen Beurteilung des AwS/Modells (z.b. ein Auffinden von Deadlocks) und bilden eine sinnvolle Vorstufe vor der Berechnung der quantitativen Performance-Metriken. Ebenso heben die Autoren die einfache grafische Repräsentation hervor. Datenbank Nutzer CPU DB-CPU DB-I/O Legende Queue Depository Place Token Transition DB Connection Pool Abbildung 8: Queueing Petri Net Model Quelle: Angelehnt an Kounev/Dutz (2009) Ein gewöhnliches Petri-Netz besteht aus Stellen (Places), Transitionen (Transitions), Marken (Tokens) und gerichten Kanten, die ausschließlich Stellen und Transitionen verbinden. Die im Petri-Netz in den Stellen verteilten Marken spiegeln einen Zustand des Systems wieder. Die- 18

28 ser Zustand kann durch das Schalten von Transitionen verändert werden. Beim Schalten werden Marken auf den Stellen entfernt, die auf die Transition zeigen und es werden neue Marken an Stellen erzeugt, auf die die Transition selbst zeigt. Mit Multiplizitäten an den Kanten kann zusätzlich noch definiert werden, wie viele Marken von den Stellen hinzugefügt oder entfernt werden sollen. Zudem kann es im Petri-Netz verschiedene Klassen an Marken geben, für die jeweils eigene Multiplizitäten definiert werden können. Neu bei QPNs ist, dass Stellen eine zusätzliche Warteschlange (Queue) enthalten. Wenn eine Marke auf einer Stelle eintrifft, landet sie zuerst in der Warteschlange. Mittels einer Scheduling-Strategie werden die Elemente aus der Queue ausgewählt, die als nächstes prozessiert werden sollen. Für die Prozessierung ist für jede Klasse an Marken ist eine Zeitspanne in der Stelle selbst definiert. Nach Ablauf dieser Zeitspanne wird die Marke ins Depository der Stelle gelegt und ist erst dann für das Schalten einer neuen Transition verfügbar. Das in Abbildung 8 definierte QPN modelliert drei Benutzer, die auf eine CPU und ein Datenbanksystem zugreifen. Einer der Nutzer befindet sich hierbei noch ein einem Warteprozess (vgl. die Think Time aus Abschnitt 2.2.2). Nutzeranfragen belegen zuerst CPU-Ressourcen und danach Datenbank-Ressourcen, wenn mindestens einer der beiden Plätze des Connection Pools frei ist Palladio Component Model Abbildung 9: Palladio Component Model Angelehnt an: Becker/Koziolek/Reussner (2009); Wischer (2014) Das Palladio Component Model (PCM) ist ein von Becker/Koziolek/Reussner (2009) vorgestelltes Performance-Metamodell, welches explizit für die in Abschnitt 2.1 vorgestellte Systementwicklungsmethode des Component-Based Software Engineerings entworfen wurde. Einer der großen Vorteile von CBSE, die Aufteilung der Entwicklung von komplexen Software-Komponenten in kleinere Basiskomponenten, wird auch von PCM aufgegriffen. Hierzu 19

29 werden fünf Teilmodelle definiert, die sich untereinander referenzieren (Palladio 2015). Zum Erstellen der Teilmodelle (vgl. Abbildung 9) definieren Becker/Koziolek/Reussner (2009) verschiedene Rollen, die sich um die Erstellung der Teilartefakte kümmern: - Component Developer spezifizieren und implementieren die Software- Komponenten und sind deshalb für die Erstellung des Repository Models zuständig. - Software Architects erstellen aus den einzelnen Software-Komponenten das Gesamtsystem. Dies wird im System Model repräsentiert. - System Deployers kümmern sich um die Bereitstellung der für den Betrieb des Systems notwendigen Ressourcen und die Allokation der Komponenten auf diese. Im Ressource Environment Model und im Allocation Model wird dies abgebildet. - Business Domain Experts sind vertraut mit dem Nutzungsverhalten des Systems und definieren dieses im Usage Model. Im Folgenden werden die fünf Teilmodelle näher beschrieben: Die für die Anwendung definierten Komponenten und deren Abhängigkeiten werden im Repository Model spezifiziert. Komponenten können Schnittstellen (Interfaces) nach außen anbieten und zudem auch auf Schnittstellen, die von anderer Komponenten angeboten werden, zugreifen. In Abbildung 10 sind links zwei Komponenten ( ComponentA und ComponentB ) abgebildet. ComponentA stellt das Interface IComponentA zur Verfügung und greift zudem auch auf das von ComponentB bereitgestellte Interface IComponentB zu. Dies wird durch Pfeile mit den Annotationen Provides und Requires modelliert. Abbildung 10: PCM Respository Model und RDSEFF Quelle: Angelehnt an Brunnert/Vögele/Krcmar (2013) Interfaces definieren jeweils eine Menge an Operationen, die von den Komponenten, die das Interface zusammen bereitstellen, implementiert werden soll. Diese Implementierung wird in den Service Effect Specifications (SEFF) modelliert. Eine speziell für die Modellierung von Performance- und Zuverlässigkeits-Vorhersage definierte SEFF ist die Resource Demanding Service Effect Specification (RDSEFF) (Reussner et al. 2007, S. 49). Eine solche RDSEFF ist für die erste Operation von ComponentA in Abbildung 10 auf der rechten Seite genauer dargestellt. Die grafische Notation der RDSEFFs orientiert sich an den aus der Unified Modeling 20

30 Language (UML) bekannten Aktivitätsdiagrammen (OMG 2015c) und beginnt mit einer BranchAction. Diese ist in Abbildung 10 in zwei Partitionen eingeteilt, an die jeweils eine Wahrscheinlichkeit (Probability) annotiert ist. Beim Aufruf von operationa wird infolgedessen in 30% der Fälle in der linken und mit 70% Wahrscheinlichkeit in der rechten Partition gestartet. Für den in der Operation dann entstehenden Ressourcenverbrauch und mögliche Abbildung 11: PCM System Model Quelle: Juratoni (2014) Kontrollflüsse stehen weitere Elemente zur Verfügung. Mit internalactions können Service Times modelliert werden. Dies sind im Beispiel 0,315 CPU-Einheiten. Schleifen werden durch LoopAction modelliert. IntPMF definiert hierfür eine Ganzzahl- Wahrscheinlichkeitsverteilung, mit der stochastisch spezifiziert wird, wie oft eine Schleife iteriert wird. Mit ExternalCallActions kann ferner ein Aufruf einer Operation modelliert werden, die von einer anderen Komponente über ein Interface zur Verfügung gestellt wird. Im System Model (vgl. Abbildung 11: PCM System ModelAbbildung 11) wird ein Anwendungssystem aus den im Repository Model definierten Komponenten und Interfaces zusammengestellt. Es wird hier definiert, welche Interfaces von außen (für das Usage Model) verfügbar sind. Abbildung 12: PCM Resource Environment Model Quelle: Wischer (2014) Das Resource Environment Model modelliert die vorhandenen Hardware-Ressourcen. In Abbildung 12 wurden zwei Server (Hardware Container) modelliert, die durch ein Netzwerk 21

31 verbunden sind. Als Scheduling-Strategie ( Scheduling ) wird im Beispiel Processor Sharing 1 verwendet. Mit Number of Replicas kann beispielsweise die Anzahl der CPU-Kerne modelliert werden. Durch eine Processing Rate (Anzahl der Instruktionen pro Zeiteinheit) von 1000 lässt sich die Service Time von 0,315 CPU-Einheiten aus Abbildung 10 besonders einfach als 1000 * 0,315 = 315 Millisekunden interpretieren. Im Allocation Model werden den Komponenten aus dem Repository Model den Hardware- Ressourcen aus dem Resource Environment Model zugeordnet. In Abbildung 13 wurden die beiden Komponenten auf je einen eigenen Hardware Container ( Server1, Server2 ) zugeordnet. Abbildung 13: PCM Allocation Model Quelle: Wischer (2014) Das Usage Model spezifiziert die Benutzerinteraktionen mit dem System. Auf oberster Ebene wird hierbei zwischen einem offenen und einem geschlossenem Workload unterschieden. Beim geschlossenen Workload wird eine Population und eine durchschnittliche Think Time dieser Benutzer definiert. Die Population gibt hierbei die konstante Gesamtzahl der Benutzer an, die mit dem System interagieren. Jeder Nutzer wartet nach Abschluss der Interaktion dann im Durchschnitt so lange wie durch den Think-Time-Wert definiert wurde bevor die Interaktion wieder von vorne anfängt. Beim offenen Workload wird hingegen die sogenannte Arrival Rate definiert. Diese Zufallsvariable gibt die durchschnittliche Ankunft neuer Benutzer am System an. Im Vergleich zum geschlossenen Workload handelt es sich bei dieser Modellierung um eine unendliche Sequenz anstatt einer fixen Population. Wenn ein Nutzer die Interaktion mit dem System beendet hat, gilt seine Interaktion mit dem System jedoch als beendet. Die eigentliche Interaktion der Nutzer mit dem System wird in einer Modellierungssprache ähnlich der UML-Aktivitätsdiagramme (OMG 2015c) definiert. SystemCallAction - Elemente definieren hierbei Aufrufe des Nutzers am System. Mit Branch -Elementen kann der Kontrollfluss dieser Aufrufe stochastisch verzweigen. Mit Loop -Elementen können Wiederholungen definiert werden. 1 Processor Sharing ist eine Round-Robin-Scheduling-Strategie (Brause 2004, S. 32) mit infinitesimal-kleinen Zeitperioden (Spinner et al. 2014). 22

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

Abbildung von Ressourcen-Profilen für Unternehmens- anwendungen durch Performance-Modelle

Abbildung von Ressourcen-Profilen für Unternehmens- anwendungen durch Performance-Modelle FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Master s Thesis in Finanz- & Informationsmanagement Abbildung von Ressourcen-Profilen für Unternehmens- anwendungen durch Performance-Modelle

Mehr

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

Evaluierung der Ressourcenabschätzung einer beispielhaften Unternehmensanwendung auf Basis eines automatisch generierten Performance-Modells

Evaluierung der Ressourcenabschätzung einer beispielhaften Unternehmensanwendung auf Basis eines automatisch generierten Performance-Modells FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Informatik Evaluierung der Ressourcenabschätzung einer beispielhaften Unternehmensanwendung auf Basis eines automatisch generierten

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

Stabilisierung von J2EE-Anwendungen durch APM

Stabilisierung von J2EE-Anwendungen durch APM Stabilisierung von J2EE-Anwendungen durch APM juergen.moors@de.quest.com Agenda Was ist Application Performance Management? Anwendungen Wo liegt das Problem? APM Best Practices APM Was ist APM? Was ist

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

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Entwurf eines generischen Prozessleitstandes für Change Request Systeme Development of a Generic

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

Simulation von Computer- und Kommunikationssystemen

Simulation von Computer- und Kommunikationssystemen Computer und Kommunikationssysteme Nachbildung der Verarbeitung in Rechnern und Kommunikation in Netzwerken Belegung und Auslastung von Systemressourcen Analyse von Systemverhalten Systemleistung in der

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

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

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

Inhaltsverzeichnis Einführung...1 Performance und Entwicklungsprozess...13

Inhaltsverzeichnis Einführung...1 Performance und Entwicklungsprozess...13 Inhaltsverzeichnis 1 Einführung...1 1.2 Ein Performancemeeting...1 1.3 Das fachliche und technische Umfeld...4 1.4 Performanceaspekte...5 1.5 Neue Herausforderungen...8 1.6 Performance als interdisziplinäre

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

Performance Monitoring Warum macht es Sinn?

Performance Monitoring Warum macht es Sinn? Performance Monitoring Warum macht es Sinn? achermann consulting ag Nicola Lardieri Network Engineer Luzern, 25.5.2011 Inhalt Definition Monitoring Warum Performance Monitoring? Performance Monitoring

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant

<Insert Picture Here> Oracle Business Process Analysis Suite. Gert Schüßler Principal Sales Consultant Oracle Business Process Analysis Suite Gert Schüßler Principal Sales Consultant 1 Geschäftsprozesse Zerlegung am Beispiel Kreditvergabe Antrag aufnehmen Antrag erfassen Schufa Kunden

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

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

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y Cloud Computing Betriebssicherheit von Cloud Umgebungen Urs Zumstein Leiter Performance Care Team Urs.Zumstein@DevoTeam.ch 079 639 42 58 Agenda Definition von Cloud Services Anforderungen an die Betriebssicherheit

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

FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN. Bachelorarbeit in Wirtschaftsinformatik

FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN. Bachelorarbeit in Wirtschaftsinformatik FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Wirtschaftsinformatik Konzeption und Entwicklung einer Java EE- Anwendung zum Datenaustausch zwischen einer Performance-Simulationsumgebung

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

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

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

Performance Analyses with inspectit

Performance Analyses with inspectit Performance Analyses with inspectit 23.03.2012 Über uns Beratungsschwerpunkte Performanceanalyse und -optimierung, Application Monitoring, Lastund Performancetests Architekturberatung Java-basierte Anwendungsentwicklung

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

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

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

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

FH LU JEE Vorlesung SS 2014. Ralf Gitzel ralf_gitzel@hotmail.de FH LU JEE Vorlesung SS 2014 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

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

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

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

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 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

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

Module für eine Java-Administrationsschulung

Module für eine Java-Administrationsschulung Module für eine Java-Administrationsschulung Schulungsmodule 1 Java Administration allgemein...2 1.1 Java und die Virtual Machine...2 1.2 Java EE Bestandteile...2 1.3 Java Management Extensions...2 1.4

Mehr

A Platform for Complex Event Processing

A Platform for Complex Event Processing A Platform for Complex Event Processing Einführung Business Process Technology Prof. Dr. Mathias Weske Matthias Kunze Nico Herzberg Business Process Technology Seit 2001 Untersuchung realer Probleme des

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

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

Warum Anwendungen nicht skalieren Wie man Performance- und Skalierbarkeitsprobleme findet und eliminiert

Warum Anwendungen nicht skalieren Wie man Performance- und Skalierbarkeitsprobleme findet und eliminiert Warum Anwendungen nicht skalieren Wie man Performance- und Skalierbarkeitsprobleme findet und eliminiert Alois Reitbauer, dynatrace Software Mirko Novakovic, codecentric GmbH Agenda Skalierbarkeit Das

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

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

ITIL Capacity Management für den Oracle DBA

ITIL Capacity Management für den Oracle DBA ITIL Capacity Management für den Oracle DBA Peter Stalder Peter.stalder@trivadis.com TrivadisOPEN 21. Okt. 2008 Basel Baden Bern Lausanne Zurich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg Munich Stuttgart

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Test nichtfunktionaler Anforderungen in der Praxis am Beispiel einer netzzentrierten Anwendung. Test nichtfunktionaler Anforderungen Agenda

Test nichtfunktionaler Anforderungen in der Praxis am Beispiel einer netzzentrierten Anwendung. Test nichtfunktionaler Anforderungen Agenda Test nichtfunktionaler in der Praxis am Beispiel einer netzzentrierten Anwendung Februar 2011 Test nichtfunktionaler Agenda 1. 2. 3. 4. 5. 6. TAV Tagung Februar 2011 Julia Remmert Public Wincor Nixdorf

Mehr

Effiziente Anwendungs-Entwicklung mittels Business Software Framework BISON Solution

Effiziente Anwendungs-Entwicklung mittels Business Software Framework BISON Solution Effiziente Anwendungs-Entwicklung mittels Business Software Framework BISON Solution Thomas Seiler Product Manager Technology BISON Schweiz AG Agenda Vergleich - Business Software Framework zu.net Framework

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

Dienstbeschreibung und modellierung

Dienstbeschreibung und modellierung KIVS 2003 in Leipzig AG Lehrunterstützung Fakultät für Informatik Universität Karlsruhe (TH) Dienstbeschreibung und modellierung für ein SLA-fähiges Service-Management C. Mayerl, S. Abeck, M. Becker, A.

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

Wanna be faster? Performance kann man managen! Application Performance Management, TIC Konferenz 2014

Wanna be faster? Performance kann man managen! Application Performance Management, TIC Konferenz 2014 Wanna be faster? Performance kann man managen! Application Performance Management, TIC Konferenz 2014 Streng vertraulich, Vertraulich, Intern Autor / Thema der Präsentation 26.11.2014 1 Performance? Who

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

Model Driven Development einige wichtige Grundprinzipien

Model Driven Development einige wichtige Grundprinzipien Model Driven Development einige wichtige Grundprinzipien Johannes Scheier j@scheier software.ch Copyright by Scheier Software Engineering Seite 1 Inhalt Was ist Model Driven Development (MDD)? Was verspricht

Mehr

Oracle GridControl Tuning Pack. best Open Systems Day April 2010. Unterföhring. Marco Kühn best Systeme GmbH marco.kuehn@best.de

Oracle GridControl Tuning Pack. best Open Systems Day April 2010. Unterföhring. Marco Kühn best Systeme GmbH marco.kuehn@best.de Oracle GridControl Tuning Pack best Open Systems Day April 2010 Unterföhring Marco Kühn best Systeme GmbH marco.kuehn@best.de Agenda GridControl Overview Tuning Pack 4/26/10 Seite 2 Overview Grid Control

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

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

SaaS-Referenzarchitektur. iico-2013-berlin

SaaS-Referenzarchitektur. iico-2013-berlin SaaS-Referenzarchitektur iico-2013-berlin Referent Ertan Özdil Founder / CEO / Shareholder weclapp die Anforderungen 1.000.000 registrierte User 3.000 gleichzeitig aktive user Höchste Performance Hohe

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

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen WEITER BLICKEN. MEHR ERKENNEN. BESSER ENTSCHEIDEN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN VERSION 1.0 OPTIMIERUNG VON ABFRAGEN IN MS SQL

Mehr

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit

Vorteile von Java und Konvergenz Service Creation mit JAIN Network Management mit JMX Fazit Hochschule für Technik und Architektur Chur Dr. Bruno Studer Studienleiter NDS Telecom, FH-Dozent bruno.studer@fh-htachur.ch 1 GSM: 079/610 51 75 Agenda Vorteile von Java und Konvergenz Service Creation

Mehr

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP 8.4 Überblick und Vergleich weiterer ERP-Systeme G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP Kapitel 8: ERP-Einführung 32 Architektur von Oracle Applications 11 G Logische

Mehr

OPNET s Application Response Expert (ARX)

OPNET s Application Response Expert (ARX) OPNET s Application Response Expert (ARX) Root Cause Analyse und End2End Monitoring für Web Anwendungen Summary Werden im IT Betrieb Probleme durch die Anwender gemeldet, müssen schnell Informationen aus

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

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

Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung

Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung Peter Stalder DOAG November 2009 Basel Baden Bern Lausanne Zurich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg Munich Stuttgart Vienna

Mehr

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain

Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP. Ralf Ackermann Daimler AG, ITM MBC Powertrain Ansätze zur Synchronisation von Enterprise Architecture Management, Prozessmanagement und SAP Ralf Ackermann Daimler AG, ITM MBC Powertrain Agenda Ausgangslage EAM Tool-Landschaft bei Daimler planningit

Mehr

Towards Automated Analysis of Business Processes for Financial Audits

Towards Automated Analysis of Business Processes for Financial Audits Towards Automated Analysis of Business Processes for Financial Audits Michael Werner Universität Hamburg michael.werner@wiso.uni hamburg.de Max Brauer Allee 60 22765 Hamburg StB Prof. Dr. Nick Gehrke Nordakademie

Mehr

MICHAEL RÜGER. Abschluss Diplom Fach Informatik. Geburtsjahr 1985 Profil-Stand April 2015

MICHAEL RÜGER. Abschluss Diplom Fach Informatik. Geburtsjahr 1985 Profil-Stand April 2015 MICHAEL RÜGER Abschluss Diplom Fach Informatik Geburtsjahr 1985 Profil-Stand April 2015 Triona Information und Technologie GmbH Wilhelm-Theodor-Römheld-Str. 14 55130 Mainz Fon +49 (0) 61 31 9 21-122 Fax

Mehr

Tivoli Monitoring for Databases (ITM) Resource Model Tivoli Enterprise Console (TEC) Zusammenfassung. IBM Tivoli. Marcel Brückner

Tivoli Monitoring for Databases (ITM) Resource Model Tivoli Enterprise Console (TEC) Zusammenfassung. IBM Tivoli. Marcel Brückner 1 Tivoli Monitoring for Databases (ITM) Grundidee Umsetzung 2 3 Aufbau Kombination mit ITM Rule Sets 4 Grundidee Umsetzung 1 Tivoli Monitoring for Databases (ITM) Grundidee Umsetzung 2 3 Aufbau Kombination

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

Entwicklung einer mobilen webbasierten Anwendung mit Oracle9i Lite Web-to-Go

Entwicklung einer mobilen webbasierten Anwendung mit Oracle9i Lite Web-to-Go Thema Autor Entwicklung einer mobilen webbasierten Anwendung mit Oracle9i Lite Web-to-Go Christian Antognini (christian.antognini@trivadis.com) Art der Information Produktübersicht (Mai 2002) Quelle Trivadis

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

JBoss AS 7. Installation, Konfiguration und Betrieb. Alexander Pacnik Karlsruhe, 13.12.2013

JBoss AS 7. Installation, Konfiguration und Betrieb. Alexander Pacnik Karlsruhe, 13.12.2013 JBoss AS 7 Installation, Konfiguration und Betrieb Alexander Pacnik Karlsruhe, 13.12.2013 Jboss 7 AS... worum es in diesem Vortrag geht. Einführung Installation Konfiguration Management Deployment Betrieb

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 8 10. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Enterprise Edition Teil 4 Schnittstellen el0100 copyright W. G. Spruth, wgs 04-10

Mehr

Von ODBC zu OLE DB. Neue Möglichkeiten der Datenintegration. Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig

Von ODBC zu OLE DB. Neue Möglichkeiten der Datenintegration. Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig Von ODBC zu OLE DB Neue Möglichkeiten der Datenintegration Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig Von ODBC zu OLE DB Begriffsbestimmung ODBC, OLE DB, COM, ADO... Unterschiede zwischen

Mehr

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining Das Knowledge Grid Eine Architektur für verteiltes Data Mining 1 Gliederung 1. Motivation 2. KDD und PDKD Systeme 3. Knowledge Grid Services 4. TeraGrid Projekt 5. Das Semantic Web 2 Motivation Rapide

Mehr

1 YAWL Yet Another Workflow Language

1 YAWL Yet Another Workflow Language 1 YAWL Yet Another Workflow Language Das YAWL Workflow-Management-System wurde von Wil van der Aalst und seinem Team an der Eindhoven University of Technology entwickelt. Das System ist in seiner jetzigen

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

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

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10

Prototypvortrag. Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning. Projektseminar WS 2009/10 Prototypvortrag Exploiting Cloud and Infrastructure as a Service (IaaS) Solutions for Online Game Service Provisioning Projektseminar WS 2009/10 Eugen Fot, Sebastian Kenter, Michael Surmann AG Parallele

Mehr

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

Jan Hendrik Bartels Seminar: Leistungsanalyse unter Linux

Jan Hendrik Bartels Seminar: Leistungsanalyse unter Linux Jan Hendrik Bartels Seminar: Leistungsanalyse unter Linux Jan H. Bartels XXX XXX XXX XXX XXX Einführung Leistungskennzahlen & Komponenten Methoden der Leistungsanalyse Zusammenfassung XXX XXX 23.06.2011

Mehr

Caching. Hintergründe, Patterns &" Best Practices" für Business Anwendungen

Caching. Hintergründe, Patterns & Best Practices für Business Anwendungen Caching Hintergründe, Patterns &" Best Practices" für Business Anwendungen Michael Plöd" Senacor Technologies AG @bitboss Business-Anwendung!= Twitter / Facebook & co. " / kæʃ /" bezeichnet in der EDV

Mehr

Hochschule für Angewandte Wissenschaften München Fakultät Informatik und Mathematik

Hochschule für Angewandte Wissenschaften München Fakultät Informatik und Mathematik Hochschule für Angewandte Wissenschaften München Fakultät Informatik und Mathematik Verteilte Systeme (Masterstudiengänge) Wintersemester 2014/2015 München, September 2014 Prof. Dr. Peter Mandl Inhalt

Mehr

Datenhaltung für Android. Model First

Datenhaltung für Android. Model First Datenhaltung für Android Model First Frederik Götz, Johannes Tysiak 26.05.2011 Unser Ziel! 26.05.2011 Datenhaltung in Android - Model First» Frederik Götz, Johannes Tysiak 2 Agenda Android Quickstart Datenhaltung

Mehr

Design von skalierbaren Websystemen und Test auf ihre Leistungsbeschränkungen Basiert auf der Veröffentlichung Design and testing of scalable Web-based systems with performance constraints von Mauro Andrelini,

Mehr

Mobile Backend in der

Mobile Backend in der Mobile Backend in der Cloud Azure Mobile Services / Websites / Active Directory / Kontext Auth Back-Office Mobile Users Push Data Website DevOps Social Networks Logic Others TFS online Windows Azure Mobile

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

Application Performance Management. Auch eine Frage des Netzwerkes?

Application Performance Management. Auch eine Frage des Netzwerkes? Application Performance Management Auch eine Frage des Netzwerkes? Agenda Architektur von Webanwendungen Lange Applikationsantwortzeiten Application Performance Management (APM) Netzwerkbasiertes APM Serverbasiertes

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

OMNITRACKER Betriebssupport Überblick

OMNITRACKER Betriebssupport Überblick OMNITRACKER Betriebssupport Überblick Detailierte Informationen verfügbar durch Anfrage bei 29.06.2010-1- 1 Inhalt 1. OMNITRACKER Betriebssupport im Überblick 2. Die Leistungsmerkmale im Überblick 3. Die

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

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