Unterschiede der JSP-Implementierung zwischen Glassfish, Websphere, JBOSS und WebLogic

Aus Winfwiki

Wechseln zu: Navigation, Suche
Name des Autors / der Autoren: Markus Venes, Danny Ihlenfeld
Titel der Arbeit: Unterschiede der JSP-Implementierung zwischen Glassfish, Websphere, JBOSS und WebLogic
Hochschule und Studienort: Fachhochschule für Oekonomie & Management - Essen


Inhaltsverzeichnis

1 Abkürzungsverzeichnis

AbkürzungBedeutung
API Application Programming Interface
CORBACommon Object Request Broker Architecture
DBMSDatenbank Mangement System
EIS Enterprise Information Systems
EJB Enterprise Java Beans
ERP Enterprise Ressource Planning
GPL General Public Licence
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
J2EEJava 2 Platform Enterprise Edition
JCA Java EE Connector Architecture
JDBCJava-Database-Connectivity
JMS Java Message Service
JNDI Java Naming and Directory Interface
JPA Java Persistence API
JRE Java Runtime Environment
JSP Java Server Pages
JSF Java Server Faces
RMI Remote Method Invocation
RPC Remote Procedure Call
SOA Service-Oriented-Architecture
SOAP Simple Object Access Protocol
URI Unified Ressource Identifier
WAR Web Archive
WAS WebSphere Application Server

2 Abbildungsverzeichnis

AbbildungBeschriftung
Abbildung 1 Zwei-Schichten-Modell
Abbildung 2 Drei-Schichten-Modell
Abbildung 3 Überblick über die 4-Tier-Architektur und die J2EE-spezifischen Komponentenmodelle
Abbildung 4 Middleware als Mittelschicht
Abbildung 5 Aufbau eines Java Applikation Servers
Abbildung 6 The Java runtime environment
Abbildung 7 Aufgabenverteilung und Bereitstellung von Diensten
Abbildung 8 Aufbau und den Zugriff auf Messaging Systeme
Abbildung 9 Funktionsweise von Session Beans
Abbildung 10 JSP-Lebenszyklus

3 Tabellenverzeichnis

TabelleBeschriftung
Tabelle 1 Gesamtnutzen einer JSP-Implementierung

4 Einleitung

Diese Hausarbeit stellt die Problematiken bei der JSP-Implementierung bei der Verwendung verschiedener Applikationsserver dar. Dazu wird zunächst die im Hintergrund agierende Technologie erläutert. Dies beinhaltet neben der umfassenden Mehr-Tier Architektur auch die verschiedenen Arten von Middleware. Im weiteren Prozess der Ausarbeitung wird dann auf die Java Platform, Enterprise Edition (J2EE) eingegangen, welche die Grundlage der einzelnen Applikationsserver ist und die JSP-Implementierung ermöglicht. In dieser Hausarbeit werden zudem nur J2EE gestützte Produkte betrachtet und die Verwendung von möglichen .Net Produkten aussen vor gelassen. Besonderes Augenmerk wird bei der Hausarbeit immer auf die einzelnen Komponenten liegen, die die JSP-Implementierung am meisten beeinflussen. Zudem werden weitere Komponenten des J2EE kurz vorgestellt, um den Umfang der J2EE darzustellen. Weiterhin wird in dieser Hausarbeit an exemplarischen Beispielen gezeigt, bei welchen Implementierungen man besonders aufpassen muss, da ein Wechsel des Applikationsservers den Entwickler dazu zwingt, seinen Code zu verändern.
Das Ziel dieser Hausarbeit ist, die Unterschiede der JSP-Implementierung der einzelnen Produkte herauszustellen und zu bewerten. Dazu wird eine Nutzwertanalyse durchgeführt, die unter Berücksichtigung verschiedener Kriterien zeigt, auf welche Aspekte man bei der Implementierung für die einzelnen Applikationsserver besonders zu achten hat. Am Ende dieser Nutzwertanalyse wird eine Empfehlung erfolgen, ob ein Einsatz einer nicht J2EE konformen Implementierung vorteilhaft ist oder ob diese nur Mehrarbeit verursacht.

5 Grundlagen

5.1 Schichtenmodell

5.1.1 Das Zwei-Schichten-Modell

Beim Zwei-Schichten-Modell wird die Gesamtanwendung, die aus der Ausführungslogik und aus der Datenhaltung besteht, auf zwei Ebenen unterteilt. Auf der ersten Ebene befindet sich die Benutzerschnittstelle mit der Anwendungslogik und dem Datenzugriff, der mit Java mittels Java-Database-Connectivity (JDBC) durchgeführt wird. [1] Die Anwendung auf Ebene eins kommuniziert beispielsweise über das Netzwerk mit dem Datenbank-Management-System, das auch DBMS genannt wird und den Zugriff auf die Datenbank gewährt. Der Datenbank-Server ist auf Ebene zwei angesiedelt und auf diesem können je nach Anwendung unternehmenskritische Daten gelesen und gespeichert werden.

Abbildung 1: Zwei-Schichten-Modell
Abbildung 1: Zwei-Schichten-Modell[2]

Die Nachteile der beschriebenen Architektur bestehen darin, dass die Anwendungslogik nicht von der Benutzerschnittstelle getrennt ist, sondern auf einem Client ausgeführt wird. Daher verrichtet der Client den größten Teil der Arbeit und muss dabei genügend Ressourcen besitzen. Dadurch kann die Datenintegrität gestört werden, da ein Fehler in der Anwendungslogik auf dem Client die Integrität anderer Programme gefährdet.[3] Ein weiterer Nachteil der sich ergibt ist, dass wenn sich ein Teil der Software oder sich Daten ändern, diese auf dem Client entweder automatisch oder manuell aktualisiert werden müssen. Dadurch hat die Anwendung einen hohen Aktualisierungs- bzw. Wartungsaufwand. Dies hat bei datenintensiven Operationen einen hohen Datentransfer zur Folge, der leicht zu einer Überlastung des Netzwerks oder des Datenbank-Servers führen kann.

5.1.2 Das Drei-Schichten-Modell

Bei dem Drei-Schichten-Modell wird die Anwendungslogik in eine separate Ebene ausgegliedert. Es entsteht ein Appikationserver, der nun Funktionen in Form von Objekten und Methoden zur Verfügung stellt. Diese Ebene wird auch Geschäftslogik oder „Business Logic“ genannt. [4] Die Software, die auf dem Applikationsserver installiert wird, nennt man „Middleware“. Der Client erhält keinen direkten Zugriff zum Datenbestand, wie es beim Zwei-Schichten-Modell der Fall ist. Somit wird sichergestellt, dass der Client nur auf bestimmte Daten zugreifen darf. Für den Datenaustausch zwischen dem Client und dem Applikationsserver werden Middleware-Lösungen, wie zum Beispiel CORBA (Common Object Request Broker Architecture), unter dem man einen Vermittler für Objektanforderungen versteht, verwendet. Andernfalls ist der Client in der Lage über das HTTP-Protokoll mit Hilfe von Servlets mit dem Applikationsserver kommunizieren. Der Applikationsserver kommuniziert mittels des DBMS-Protokolls mit der Datenbank.

Abbildung 2: Drei-Schichten-Modell
Abbildung 2: Drei-Schichten-Modell[5]

Diese Architektur bringt bei datenintensiven Prozeduren einige Vorzüge in Punkto Schnelligkeit, da die Verbindung zum Datenbank-Server meist besser dimensioniert ist, als die Verbindung zu den Endnutzern. Somit ist eine langsame Verbindung zum Client ausreichend, über die die eigentlichen Daten über das Datenbank-Management-System ausgetauscht werden.[6] Insgesamt ist das System besser zu warten und zu erweitern, zumal die eigentliche Anwendung auf dem Applikationsserver vorliegt und entsprechende Änderungen auch dort vorgenommen werden müssen. Die Komplexität der Gesamtanwendung steigt je mehr Ebenen in die Architektur implementiert werden. Folglich wird durch den steigenden Abstraktionsgrad die Anwendungsentwicklung deutlich komplexer. Die Portabilität ist bei dieser Architektur sehr eingeschränkt, durch die Hersteller einen Applikationsserver erstellen, der nur für die eigene Plattform zugeschnitten ist. Ein Wechsel zu einem anderen Anbieter hätte zur Folge, dass die gesamte Anwendung neu implementiert werden muss, da sie nicht übernommen werden kann. Zusammenfassend kann man sagen, dass dieses Modell nicht plattform- und herstellerabhängig ist.

5.1.3 Das Vier-Schichten-Modell

Das Vier-Schichten-Modell ist der Standard für webbasierte Applikationen. Diese Architektur wurde um eine weitere Schicht erweitert. [7]

Die 4 Ebenen teilen sich wie folgt auf:
Abbildung 3: Überblick über die 4-Tier-Architektur und die J2EE-spezifischen Komponentenmodelle
Abbildung 3: Überblick über die 4-Tier-Architektur und die J2EE-spezifischen Komponentenmodelle [8]
  • Ebene 1 ist die Visualisierungsebene. Diese Schicht stellt die Benutzeroberfläche dar. Die Inhalte, die auf der Ebene 2 zusammengestellt werden, werden mittels Browser dargestellt. Der Browser nimmt bei dieser Schicht die Eingaben des Benutzers entgegen und leitet diese an die Ebene 2 weiter, in der die Daten weiterverarbeitet werden.
  • Ebene 2 ist die Präsentationsebene (Web-Server). Hier werden die Daten anwendungstechnisch ausgewertet, welche aus der Ebene 1 vom Browser an diese Ebene gesendet werden. Die Daten werden in dieser Schicht überprüft und weiter ausgewertet, indem die Applikationslogik auf Ebene 3 angesprochen wird. Nach einer Überprüfung der Daten werden die Informationen an den Browser zurückgesendet.
  • In der Ebene 3 ist der Applikationsserver und die dazugehörige Anwendungslogik vorzufinden und eingebettet. Die dafür benötigten Daten werden aus der Ebene 4 angefordert verarbeitet.
  • Die letzte Ebene ist Ebene 4, die Datenbankebene. Die Daten werden von dem Server zur Verfügung gestellt und abgelegt.

Das Konzept hat den Nachteil, dass mit der erneut höheren Anzahl der verwendeten Schichten auch die Komplexität der Gesamtanwendung ansteigt. Dem gegenüber steht, dass das Modell den Vorteil bietet plattform- und herstellerunabhängig zu agieren.

5.2 Applikationsserver

Der Applikationsserver ist ein komponentenbasiertes Produkt, welches erstmals im Drei-Schichten-Modell zum Einsatz kam. Der Server wird als „Middle-Tier“ bezeichnet und stellt eine separate Ebene im Schichten-Modell zwischen der Präsentationsschicht und der Datenhaltung dar, die die eigentliche Geschäftslogik bereitstellt. [9] Ein wichtiger Betrachtungswinkel ist die J2EE-Spezifikation, initiert durch die Firma Sun Microsystems, welche Softwarekomponenten und Dienste definiert, um auf dessen Basis modulare bzw. mehrschichtige Anwendungen zu entwickeln. Diese Spezifikation verlangt, dass ein J2EE-spezifizierter Application Server einen Servlet-Container, einen Enterprise Java Beans - Container und umfassende Schnittstellen zu anderen Programmen besitzt. [10] Hierbei sollen klar definierte Schnittstellen dafür sorgen, dass Softwarekomponenten unterschiedlicher Hersteller zueinander kompatibel sind. Einige bekannte Applikationsserver sind zum Beispiel die Produkte Glassfish von Sun, Websphere von IBM, JBOSS von Redhat und WebLogic von Oracle.

5.3 Middleware

5.3.1 Definition

Unter dem Begriff Middleware wird eine Software zwischen dem Betriebssystem und der Anwendung verstanden, welche umfassende Dienste anbietet, um verteilte Systeme zu entwickeln, betreiben und warten zu können. Die Middleware unterstützt die Entwicklung von verteilten Systemen, in denen Anwendungen die entfernten Ressourcen nutzen, wie die lokalen Programme. Die sogenannte Middleware bildet eine zusätzliche Schicht, die zwischen der Anwendung und dem Betriebssystem, siehe Abbildung 4, angesiedelt ist.[11] Diese kann sich auf die Verbindung im Allgemeinen beziehen, die synchron aber auch asynchron sein kann. Zudem wird dabei auf die Logging Funktionalität des Datenflusses, die Portierung und die Interaktion zwischen Anwendungskomponenten in verschiedenartigen Systemen geachtet, welche für die Sicherheit in Hinsicht auf Zugriffsberechtigungen gleichermaßen, wie auf die Datensicherheit bei Transaktionen, zuständig ist.

Abbildung 4: Middleware als Mittelschicht
Abbildung 4: Middleware als Mittelschicht[12]

5.3.2 Unterschiede Middleware

Die Middleware-Technologien sind konkrete Implementierungen, die in verschiedene Klassen eingeordnet werden können.

5.3.2.1 Kommunikationsorientierte Middleware

Die kommunikationsorientierte Middleware ist ein Middlewareprotokoll, welches entfernte Aufrufe ermöglicht. Dazu ist es notwendig Marshalling und Unmarshalling durchzuführen. Darunter ist zu verstehen, dass Daten so aufbereitet werden, dass sie in einer Nachricht an den Empfänger verschickt werden können. Dieser muss dann mit Hilfe von Unmarshalling die Nachricht so aufbereiten, dass aus ihr wieder Daten entstehen. Es gibt verschiedene Programmiermodelle, in der diese Methode Anwendung findet. So zum Beispiel die entfernten Prozeduraufrufe (RPC) und die entfernten Methodenaufrufe (RMI). Ferner ist eine weitere Aufgabe der kommunikationsorientierten Middleware die Fehlerbehandlung und Fehlerbehebung.[13]

5.3.2.2 Anwendungsorientierte Middleware

Anwendungsorientierte Middleware kann als Erweiterung der kommunikationsorientierten Middleware gesehen werden. Sie zeichnet sich dadurch aus, dass neben der Kommunikationsinfrastruktur den Anwendungen zusätzliche Dienste und eine erweiterte Laufzeitumgebung bereitgestellt wird. Es werden also zwischen dem verteilten System und der Anwendung mehrere Abstraktionsstufen gelegt. Dabei hat jede Stufe eine Aufgabe. Die oben genannte Laufzeitumgebung dient dazu ein Anwendung auf dem Betriebssystem auszuführen. Dazu wird durch die Laufzeitumgebung die Betriebssystemfunktionalität erweitert, um die Defizite dieser auszugleichen. Dadurch sind die Anwendungen betriebssystem- und hardwareunabhängig. Die Laufzeitumgebung kümmert sich unter anderem um die Ressourcenverwaltung, Nebenläufigkeit, Verbindungsverwaltung, Verfügbarkeit und der Sicherheit. [14]

5.3.2.3 Nachrichtenorientierte Middleware

Man spricht von einer nachrichtenorientierten Middleware, wenn Nachrichten verwendet werden, um die Kommunikation zwischen den betroffenen Komponenten über eine Zwischeninstanz zu realisieren. Die nachrichtenorientiere Middleware ermöglicht vielfältige Funktionen, da die Kommunikation auf einem sehr hohem Abstraktionsniveau erfolgt. Ferner kann man durch das Versenden der Nachrichten eine lose Kopplung einzelner Komponenten erreichen, wodurch die Flexibilität ebenfalls gesteigert werden kann. Ein weiterer Vorteil ergibt sich für die Entwickler, die auf die vorhandenen Funktion zurückgreifen können und sich somit auf die Geschäftslogik konzentrieren können. Leider werden von den Herstellern nachrichtenorientierter Middleware keine spezifischen Änderungen vorgenommen, so dass man diese im Zweifel stets an den Anwendungsfall anpassen muss. Weiterhin entsteht durch das Erzeugen von Nachrichten, die entsprechend addressiert werden müssen, auch noch ein zusätzlicher Overhead. Auch sind diese nicht in der Lage in Echtzeitsystemen verwendet zu werden, da sie Nachrichten in einer Warteschlange sequentiell abarbeiten und es somit zu Wartezeiten kommen kann. [15] Der aktuell wichtigste Standard für nachrichtenorientierte Middleware ist der Java Message Service (JMS). Ein bekanntes Beispiel für eine nachrichtenorientierte Middleware ist WebSphere von IBM.

6 Java Platform, Enterprise Edition

6.1 Einführung

Bei der Java Platform, Enterprise Edition (J2EE) von Sun Microsystems handelt es sich um eine Sammlung von Spezifikationen bezüglich verschiedener serverseitigen Diensten. Diese Dienste werden so definiert, dass verschiedene Programmierschnittstellen (Application Programming Interface - API) entwickelt werden. Die einzelnen Implementierungen dieser Schnittstellen werden durch die Softwarehersteller in Form von Softwarebibliotheken (Libraries) bereitgestellt. Dabei können sowohl nur einzelne Spezifikationen implementiert werden, aber auch alle J2EE-Spezifikationen. Bei letzterem spricht man dann von einem J2EE-Applikationsserver. [16]

Zu den oben genannten Diensten zählen Transaktionsmanagement, Persistenz, Sicherheit, Namens- und Verzeichnisdienste und mehr. Hierbei wird auch der Lebenszyklus von serverseitigen Komponenten und das Packen der Komponenten durch die Spezifikation definiert. Diese Dienste werden im Rahmen der J2EE Spezifikation in einem Container-Model verwendet. Dieses Container-Model händelt die Laufzeit der Dienste und ermöglicht den Zugriff auf diese. Es stellt zudem die Pflege und den Schutz der aufgespielten Komponenten und Diensten dar. So gibt es für Servlets und Java Server Pages den Web-Container und für Enterprise Java Beans (EJB) einen EJB-Container. [17]

Abbildung 5: Aufbau eines Java Applikation Servers
Abbildung 5: Aufbau eines Java Applikation Servers[18]

6.2 Containermodell

6.2.1 Applet Container

Unter einem Applet Container versteht man eine Laufzeitumgebung, die der Ausführung von Applets dient. Ein Applet ist eine Java Klasse, die in einem Webbrowser oder anderen Anwendungen auf dem Client ausgeführt wird. Der Applet Container hat die Möglichkeit in HTML Seiten eingebettete Applets zu verarbeiten. Der Benutzer kann über dieses in HTML eingebettete Java Applet auf eine EJB auf dem Applikationsserver zugreifen.[19]

6.2.2 Application Client Container

Unter einem Application Client Container versteht man eine Laufzeitumgebung, die der Ausführung von Application Clients dient. Dabei ist ein Application Client eine Anwendung, die Zugriff auf alle clientseitigen J2EE Services hat. Der Application Client benutzt Nachrichtenschlangen, sprich die Services JMS und JDBC. Anders als normale Klassen wird dieser Application Client erst während der Laufzeit compiliert und konfiguriert. Dazu wird JNDI verwendet.[20]

6.2.3 Web / Servlet Container

Ein Web bzw. Servlet Container ist prinzipiell für das Verarbeiten und Hosten von Webseiten zuständig. Dazu beinhaltet er Unterstützung für Entwicklungsmechanismen, das Versenden von Anfragen und Dienste bezüglich der Laufzeitumgebung. Dieser Container ist verantwortlich für HTTP-Verbindung, so dass diese in Java Objekte compiliert werden können. Der jeweilige Einstiegspunkt für den Code sind die entsprechenden Methode doGet(), doPost() usw. Ferner kann man mittels einer web.xml Datei ein so genanntes Mapping durchführen, mit Hilfe der man eine URI auflösen und einer Klasse zuweisen kann. Weiterhin benötigt jeder Web-Container auch ein Wurzelverzeichnis (context path) und Unterverzeichnisse. Das bekannteste Unterverzeichnis ist das WEB-INF Verzeichnis, in dem unter anderem die web.xml hinterlegt ist. Oft wird dieses Verzeichnis noch in eine einzelne Datei, der so genannten WAR-Datei gepackt. [21]

6.2.4 EJB Container

Der EJB-Container ist die Laufzeitumgebung für Enterprise JavaBeans. Dazu muss er mindestens die später genannten Diensten implementieren. Diese werden allerdings nur genannt, da sie im späteren Verlauf noch erläutert werden. Es handelt sich bei den Diensten um die Überwachung des Lebenszyklus der EJBs, Instanzen-Pooling, Namens- und Verzeichnisdienst, Transaktionsdienst, Nachrichtendienst und der Persistenz. [22]

6.3 Laufzeitumgebung

Unter einer Laufzeitumgebung versteht man bei Java eine virtuelle Maschine, die den vom Interpreter erzeugten Byte Code umsetzt. Dies ermöglicht es, eine Anwendung plattformunabhängig zu verwenden. Somit ist es nicht notwendig seinen Quellcode für verschiedene Betriebssysteme zu entwickeln. Die Laufzeitumgebung, auch Java Runtime Environment (JRE) genannt, ist für die Verwaltung der Ressourcen zuständig. Sie steuert das Instanziieren der Objekte als auch den Garbage Collector (Löschen der Objekte) und noch weitere Funktionen.[23]

Die nachfolgende Abbildung verdeutlich schematisch die Stellung der JRE:

Abbildung 6: The Java runtime environment
Abbildung 6: The Java runtime environment[24]

6.4 Dienste

6.4.1 Kommunikationsprotokolle

Abhängig von den zur Verfügung gestellten Diensten, werden unterschiedliche Kommunikationsprotokolle unterstützt. Darunter versteht man z.B. HTTP, HTTPS oder SOAP über HTTP. Diese Protokolle dienen zur Kommunikation zwischen dem Client und den EJB-Komponenten. Ferner ist es auch möglich, dass Applikationsserver eigene Protokolle mitbringen (z.B T3-Protokoll des BEA WebLogic Servers).[25]

6.4.2 Datenbankzugriff / Persistenz

Unter Persistenz in Java versteht man die neu entwickelte Java API, die es ermöglicht relatione Datenbanken mittels einer JavaBean auf Java Objekte abzubilden und zu verwalten. Somit wird eine dauerhafte Speicherung der Daten über die Laufzeit einer Webanwendung gewährleistet. Dies ist zwar schon mit einfachen Datenbankzugriffen über JDBC und einzelnen Abfragen möglich, allerdings nicht so performant und komfortabel. Ferner ermöglicht die Java Persistence API, dass die Daten an verschiedenen Orten gespeichert werden können, so dass man nicht an eine Datenbank gebunden ist.[26]

6.4.3 Namens- und Verzeichnisdienst

Unter dem Namens- und Verzeichnisdienst versteht man unter Java (JNDI) zunächst einmal einen Satz von Schnittstellen, der beschreibt, wie auf die einzelnen Namens- und Verzeichnisdienste zugegriffen werden kann. Ein Namensdienst ist ein Dienst, der einen Namen auf ein damit assoziiertes Objekt abbildet. Ein Verzeichnisdienst hingegen ist eine Erweiterung des Namensdienstes, dahingehend, dass neben der Zuordnung von Namen zu Objekt auch Attribute zu Objekten ermöglicht. Somit genügt es im Code lediglich die Referenz anzugeben, so dass vor allem bei der Benutzung von mehreren Servern eine einfachere und flexiblere Handhabung möglich ist.[27]

Die folgende Grafik zeigt eine mögliche Verwendung von JNDI in einer 3-Tier-Architektur:

Abbildung 7: Aufgabenverteilung und Bereitstellung von Diensten
Abbildung 7: Aufgabenverteilung und Bereitstellung von Diensten[28]

6.4.4 Transaktionen

Unter Transaktionen versteht man das Ausführen verschiedener Teilaufgaben als gesamte Aufgabe. Fällt also eine der Teilaufgaben fehl, so schlägt die gesamte Aufgabe fehl und es wird ein Rollback durchgeführt und es kommt nicht zu einer Inkonsitenz der Daten. Erfolgen alle Teilaufgaben korrekt, so ist auch die gesamte Aufgabe erfolgreich und man spricht von einem commit. [29]

6.4.5 Message Service

Hierbei handelt es sich um ein allgemeines API, dem so genannten Java Message Service. Dabei implementiert jeder Hersteller gemäß der JMS-Spezifikation. Es ist erwünscht, dass Hersteller eigene Erweiterungen implementieren. Bei JMS handelt es sich um nachrichtenorienterte Kommunikation zwischen zwei unterschiedlichen Clients, wobei sich die Gesprächspartner untereinander nicht kennen. Dadurch ist eine asynchrone Kommunikation möglich.[30]

Folgende Abbildung zeigt schematisch den Aufbau und den Zugriff auf Messaging Systeme:

Abbildung 8: Aufbau und den Zugriff auf Messaging Systeme
Abbildung 8: Aufbau und den Zugriff auf Messaging Systeme[31]

6.5 Enterprise Java Beans

6.5.1 Bean-Typen

Da es sich bei Enterprise Java Beans um eine spezialisierte Form der Bean und der Java Bean handelt, werden diese allgemeineren Typen kurz erläutert.

6.5.1.1 Bean

Generell versteht man unter einer Bean in Java eine in sich geschlossene Software-Komponente. Eine Bean kann unter anderem eine Klasse implementieren, die ein Objekt kapselt und den Zugriff darauf steuert. Sie kann aber auch eine komplette ERP Lösung sein. [32]

6.5.1.2 Java Bean

Hierbei handelt es sich um eine Bean, die "Get-" und "Setter-Methoden" (besondere Namenskonvention) bereitstellt, so dass man auch während der Laufzeit die Eigenschaften eines Objektes verändern kann. Sie sorgt zudem für die Persistenz dieser Eigenschaften. [33]

6.5.2 Verwendung

Enterprise JavaBeans steht für eine serverseitige Komponentenarchitektur innerhalb der J2EE-Plattform. Sie dient der Entwicklung und Benutzung von verteilten, komponentenbasierten Geschäftsanwendungen. Daher spricht man bei EJBs häufig auch von einem Komponentenmodell. Auf Basis der EJB basierenden Komponenten wird die Geschäftslogik implementiert. Sie dienen nicht dazu Informationen, die aus der Geschäftslogik-Schicht kommen, für die Präsentation aufzubereiten. Dabei dienen sie der Kapselung der Geschäftslogik. Dies erfolgt durch den so genannten EJB-Container, der auf dem Applikationsserver vorhanden ist.[34] Ferner bezeichnet man auch die implementierten Softwarekomponenten häufig als EJB, so dass dieser Begriff vielmals synonym verwendet wird.[35]

6.5.3 Aufbau

Bei Enterprise JavaBeans handelt es sich ebenfalls um eine Spezifikation, deren Funktionalitäten und Schnittstellen im Rahmen von Applikationsserver und EJB-Containern implementiert werden. Dabei werden grundsätzlich 2 Typen der Enterprise JavaBeans unterschieden. Zum einen die Session Beans, die grundsätzlich für die Geschäftslogik zuständig sind und die Message-Driven Beans, die im Rahmen der Geschäftslogik für die Nachrichten zuständig sind. Es gibt ferner noch einen 3. Typ, die so genannten Entity Beans. Diese sind allerdings veraltet und werden vielmehr durch die Java Persistence API realisiert. Diese stellt den Zugriff auf die hinterlegten Daten (z.B. in einer Datenbank) sicher.[36] Im Folgenden werden diese beiden Typen näher erläutert, allerdings wird darauf verzichtet zu zeigen, wie diese in Anwendungen zu implementieren sind.

6.5.3.1 Session Beans

Wie bereits zuvor beschrieben, sind Session Beans für die reine Geschäftslogik zuständig. Man unterscheidet jedoch noch die beiden Typen "stateful" und "stateless". Die Wahl des richtigen Typs sind für die einzelnen Anwendungen von großer Bedeutung. So sind stateful Session Beans zustandsbehaftet. Das bedeutet, dass sie sich den internen Zustand über einen Methodenauruf hinweg merken können. Der aufrufende Client ist somit über Methodenaufrufe hinweg an die selbe Session Bean gebunden. Bei "stateless" Session Beans ist dies jedoch nicht der Fall, so das der Client für einen Methodenaufruf die Session Bean zugewiesen bekommt. Somit kann man nicht auf den Zustände zugreifen, die über mehrere Methoden hinweg gehen.[37]

6.5.3.2 Message-Driven Beans

Message-Driven Beans dienen zum Versand und Empfang von asynchronen Nachrichten. Dazu wird der Java Message Service verwendet, bei dem es eine Warteschlange gibt, in der Nachrichten angefügt werden können. Es dient der Kommunikation der EJBs untereinander.[38]

6.5.4 EJB-Aufrufe

Folgende Abbildung zeigt grob die Funktionsweise einer SessionBean:
Abbildung 9: Funktionsweise von Session Beans
Abbildung 9: Funktionsweise von Session Beans[39]

6.6 Wichtige API's

Im Folgenden werden fünf wichtige Programmierschnittstellen betrachtet und näher erläutert. Es handelt sich dabei um Java Server Pages (JSP), Servlets, Java Server Faces (JSF), Java EE Connector Architecture (JCA) und den Enterprise Java Beans (EJB). Da EJB bereits im Vorfeld näher erläutert wurde, wird hier lediglich nur noch einmal darauf hingewiesen, dass EJB ebenfalls eine wichtige API ist. Des Weiteren ist eine detaillierte Betrachtung der weiteren Schnittstellen nicht vorgesehen, so dass nur ein kurzer Überblick über die Schnittstellen gegeben wird.

Es handelt sich bei den eben genannten APIs um Programmierschnittstellen, vor allem für den Entwickler der Webanwendung. Eine Vielzahl weiterer wichtiger APIs werden lediglich durch Anbieter von Applikationsservern umgesetzt, so dass eine nähere Betrachtung dieser nicht im Fokus dieser Ausarbeitung liegt.

6.6.1 JSP

6.6.1.1 Verwendung

Bei JSP handelt es sich um eine Technologie zur Entwicklung von Webseiten mit dynamischen Inhalt. Neben den standardmäßigen HTML-Befehlen gibt es auch JSP-Elemente, die für das Generieren des dynamischen Inhalts zuständig sind. Dabei können diese Elemente für Datenbankverbindungen, Benutzerregistrierung etc. verwendet werden. Durch JSP ist es auch möglich auf EJB (siehe unten) zuzugreifen und diese auf der Webseite zu verwenden. Für Java Server Pages genügt es einen Web-Server zu verwenden, der einen Web-Container zur Verfügung stellt. Es ist nicht zwingend notwendig einen Applikationsserver zu verwenden. Bei JSP handelt es sich ferner um eine "View-Komponente". [40] Die folgende Abbildung zeigt den Lebenszyklus einer JSP:

Abbildung 10: JSP-Lebenszyklus
Abbildung 10: JSP-Lebenszyklus[41]
6.6.1.2 Struktur / Syntax

Tags, Direktiven, Skriptlets, Kommentare und Ausdrücke sind die Bausteine einer JSP-Seite. Im Folgenden werden kurz erläutert, welche Aufgaben Direktiven, Ausdrücke, Skriptlets und Tags übernehmen.

6.6.1.2.1 Direktiven

Direktiven haben, je nach Verwendung, große Auswirkungen auf die Gesamtstruktur einer JSP-Seite bzw. dem daraus erzeugten Servlet. Man unterscheidet 3 Formen von Direktiven, so gibt es "page", "include" und "taglib". All diese Direktiven haben auch noch unzählige Attribute, um die Struktur der generierten Seite zu steuern. Mit der "page"-Direktive ist es möglich Klassen zu importieren, Basisklassen des Serverlets anzupassen, Inhaltstypen zu setzen und noch vieles mehr. Die Stelle an der man eine "page"-Direktive setzt ist frei wählbar. Mit der "include"-Direktive kann man eine beliebige Datei in die Servlet-Klasse einfügen, sobald die JSP-Datei in ein Servlet compiliert wird. Die Datei wird an der Stelle eingefügt, an der die "include"-Direktive angegeben ist. Durch die "taglib"-Direktive ist es möglich eigene Tags zu definieren. [42]

6.6.1.2.2 Ausdrücke

Mit Hilfe von JSP-Ausdrücken ist es möglich, Werte (z.B. der Rückgabewert einer Funktion) direkt auszugeben. Man hat dabei vordefinierte Variablen, wie z.B. response, request, session, out, etc., um auf diverse Informationen zuzugreifen. Es zeigt sich bereits hier, dass Anbieter Code auf unterschiedliche Arten erzeugen. Dazu wird kurz vorgestellt, wie der Ausdruck ausgewertet und in die Ausgabe eingefügt wird. Zunächst wird aus den JSP-Ausdrücken eine print-/write Anweisung in einem Servlet. Diese stehen nun in der Methode _jspService, die von service aufgerufen wird. Bei der Implementierung der _jspService-Methode haben die unterschiedlichen Anbieter bereits die Möglichkeit Optimierungen, wie z.B. das Lesen von HTML aus einem statischen Byte-Array, umzusetzen. [43]

6.6.1.2.3 Skriptlets

Möchte man allerdings mehr als nur einen einfachen Ausdruck tätigen, so reichen Ausdrücke nicht aus und man muss JSP-Skriptlets verwenden. Hiermit ist es möglich beliebigen Code in die _jspService-Methode einzufügen. Dabei kann man auf dieselben Variablen zugreifen, wie es beim Ausdruck auch möglich ist. Allgemein gesagt, kann man einen Ausdruck auch immer als Skriptlet darstellen, allerdings nicht umgekehrt.[44]

6.6.1.2.4 Tags

Tags dienen dazu, den JSP Code dahingehend zu verändern, dass er weniger Java-Code enthält, der den Quellcode nur unnötig aufbläht und übersichtlich macht. Ferner kann man mit Hilfe von Tags den Quellcode besser verwenden. Auch gibt es bereits verschiedene Tag-Bibliotheken, die man kostenlos verwenden kann und verschiedene Funktionen bereitstellen. Zu den bekanntesten zählen die JSP Standard Tag Library (JSTL), die Struts Tag Library und die Regexp Tag-Library. Ferner kann man Tags auch selbst schreiben und in verschiedenen Projekten wiederverwenden.[45]

6.6.2 Servlets

Servlets sind Java-Programme, die auf Web- oder Applikationsservern (Middleware) ausgeführt werden. Dabei händeln sie "generic service requests" und "responds to the client's requests". Man ist dabei also nicht zwingend auf HTTP als Übertragungsprotokoll gebunden, es könnten auch andere Übertragungsprotokoll verwendet werden. Um Servlets verwenden zu können, benötigt man einen Web- oder Applikationsserver, der die Java Servlet API implementiert und somit verschiedene Dienste bereitstellt. Wird nun ein Servlet instanziiert, so wird für diese Operation lediglich ein neuer Thread eröffnet, jedoch kein Prozess. Dadurch ist die Verwendung von Servlets effizient, da diese sich auch den selben verfügbaren Speicher teilen. Dabei bleibt ein Servlet so lange im Speicher, bis der Server heruntergefahren wird oder das Servlet entladen wird. Dies wird so gehandhabt, damit nicht für jeden neuen request, der dieses Servlet verwenden würde, ein neues Servlet erstellt wird. Da in einem Servlet normaler Java-Code verwendet wird, ist es möglich mit anderen Tiers, z.B. der Datenbank, zu kommunizieren. Servlets bilden oft Blockkomponenten, so arbeiten z.B. JSP Komponenten oft mit Servlet Komponenten zusammen. Allerdings nehmen Servlets auch eine verteilende Rolle ein, um z.B. entfernten Clients Dienste anzubieten. [46]

6.6.3 JSF

Bei den Java Server Faces handelt es sich um eine Spezifikation, die es dem Entwickler ermöglichen soll, möglichst einfach leistungsfähige Webanwendungen zu verfassen. Dies erfolgt unter anderem durch die Verwendung von Tags innerhalb von Java Server Pages. Die Tags stehen dabei für einzelne Funktionen, die dem Entwickler zur Verfügung gestellt werden. Ferner kann man auch sagen, dass es sich bei der JSF-Spezifikation um vorgefertigen Komponenten für Webseiten handelt und sie auf der Basis von JSP entstanden sind. [47]

6.6.4 JCA

Java EE Connector Architecture definiert eine Schnittstelle zwischen Java EE Container Systemen (EJB und Web/Servlet) und Enterprise Information Systems (EIS). Unter EIS versteht man z.B. relationale Datenbanken, nachrichtenorientierte Middleware oder aber auch ERP-Systeme. Dazu werden einige APIs definiert, wie z.B. JDBC, JMS, JNDI und JavaMail. Auch wenn diese APIs herstellerneutral spezifiziert sind, ist ihre Implementierung für die einzelnen EJBs meist proprietär und für eigene Systeme optimiert. So könnte es passieren, dass ein Hersteller nur Oracle DB über JDBC anbinden kann, hingegen ein anderer Hersteller nur DB2 [48]

7 Applikationsserver

7.1 Open-Source-Server

7.1.1 Glassfish

Der Applikationsserver „Glassfish“ ist ein Open-Source Projekt der Firma Sun Microsystems und startete im Juni 2005, welches die Entwicklung des Servers innerhalb der Firma und der Internetgemeinde betreut. Das Projekt ist unter der Open-Source Lizenz GPL lizensiert. Das Sun GlassFish-Portfolio bietet interessante Funktionen und eine flexible Preisgestaltung in Form von Abonnements für Unternehmen aller Größen. Seit Dezember 2009 steht Glassfish in der Version 3 zur Verfügung, die als Referenzimplementierung der neuen Java EE 6 Spezifikation gilt. Weiterführende Informationen sind auf dem Link ersichtlich: [1]

7.1.2 JBOSS

Der JBOSS Applikationsserver wurde zum ersten Mal im Jahr 1999 im Internet angeboten und stand als freier Download zur Verfügung. Um eine entsprechende Unterstützung in Form von Entwicklern und Experten für das Produkt anbieten zu können, wurde die JBOSS Group im Jahr 2001 gegründet. Seit 2004 existiert die JBOSS Inc. deren Entwickler die Inhaber des Unternehmens sind und diese durch die Venture Capital-Geber Matrix Partners, Accel Partners und Intel unterstützt werden. Das Credo des Unternehmens besteht darin, eine Middleware für die Kunden anzubieten, die durch Open-Source Lizenzen geringe Gesamtbetriebskosten garantieren. Das Geld erwirtschaftet das Unternehmen, indem Support-Abonnements vertrieben werden, die für die nötige technische Unterstützung sorgen. [49]Grundvoraussetzung für die Installation des JBoss Applikationsservers ist eine vorhandene Installation der Java Runtime Environment 1.4. [50] Um EJB3-Techniken anzuwenden, sollte jedoch Java in der Version 1.5 auf dem Server vorliegen und installiert sein.

7.2 Kommerzielle Server

7.2.1 Websphere

Das Software-Unternehmen IBM bietet einen Applikationsserver mit dem Markennamen „WebSphere“ an. Häufig wird der Server auch als WebSphere Application Server (WAS) bezeichnet. Bei diesem Produkt handelt es sich um ein kostenpflichtiges Software-Produkt aus der Produktfamilie von IBM, welches auf dem J2EE-Standard aufsetzt. Durch den modularen Aufbau können einzelne Komponenten relativ einfach miteinander kombiniert werden.[51] Die aktuelle Version der Software ist 7.0. Weitere Informationen gibt es im angehängten Link: [2]

7.2.2 Weblogic

Die Software Weblogic wurde von dem Unternehmen BEA Systems entwickelt, die im Jahre 2008 durch Oracle übernommen wurden. [52] Die Software wird nicht kostenlos zum Download angeboten, sondern wird kommerziell vertrieben. Der WebLogic Server basiert, wie die drei anderen Server auch auf der Java 2 Platform Enterprise Edition (J2EE). Dieser Applikationsserver ermöglicht den Aufbau von sogenannten serviceorientierten Architekturen (SOA). Der Vorteil darin liegt an einem hohen Maß an Skalierbarkeit, da mit Hilfe der Architektur, Komponenten von anderen übernommen werden können und Informationen wiederverwendet werden können. Die aktuellste Version der Middleware ist 11g. Weitere Informationen gibt es auf dem nachfolgenden Link: [3]

8 Implementierungen

Bei J2EE wird immer wieder die API von dessen Implementierung getrennt. So handelt es sich bei der API nur um einen Satz von abstrakten Klassen und Interfaces. Diese werden dann von den einzelnen Herstellern auf verschiedene Arten implementiert. So kann man zwar immer die gleichen Klassen und Interfaces benutzen, die Ausführung erfolgt aber gemäß der Implementierung des Herstellers, so dass dort große Unterschiede auftauchen können. Dies ermöglicht aber auch die Modularität der Anwendung.[53]

Im Folgenden wird an Hand von verschiedenen Implementierungen der abstrakten Klassen und Interfaces gezeigt, an welchen Stellen besondere Vorsicht bei der Entwicklung der Webanwendung gegeben werden muss. Dies erfolgt vor dem Hintergrund der vier Implementierungen der Applikationsserver JBOSS, Glassfish, Websphere und WebLogic.

8.1 Proprietäre APIs

Vereinzelt werden auch einzelne Schnittstellen, auf die auch Java Server Pages zugreifen und diese verwenden, für eine bestimmte Anwendung implementiert. Diese werden für einzelne Anwendungen speziell optimiert, so dass ein besserer Zugriff und eine bessere Benutzbarkeit möglich wird.

8.1.1 Glassfish

Da es sich bei Glassfish um die Referenzimplementierung von Sun für einen J2EE spezifischen Applikationsserver handelt, sind hierbei keine proprietären APIs vorhanden, da sich ausschließlich auf den J2EE Standard bezogen wird.

8.1.2 JBOSS

Ähnlich wie bei Glassfish sind alle Funktionen J2EE konform. Allerdings kann man durch spezielle JBOSS Frameworks wie z.B. JBOSS Seam auch weitere Funktionen hinzufügen. Diese können jedoch auch mit den anderen Applikationsservern verwendet werden.

8.1.3 WebSphere

WebSphere stellt eine proprietäre API für Servlets zur Verfügung, die die J2EE konforme Servlet-API um weitere Funktionen erweitert. Dabei handelt es sich um Erweiterungen, die das Verwenden von Sitzungen, Erzeugen von personalisierten Webseiten, bessere Fehlermeldungen sowie den Datenbankzugriff vereinfachen.

8.1.4 WebLogic

WebLogic besitzt verschiedene APIs, die unter anderem eine Reihe von High-Level Datenbanken Objekten, mit deren Hilfe man Verbindungen zu Datenbanken auf einem abstrakteren Level als bei JDBC aufbauen kann. Dadurch können Datenbankdaten in einem High-Level angesehen und modifiziert werden. Somit ist es möglich, dass man kein Wissen über die DBMS Tabellenstruktur und deren Datentypen haben muss, um mit den Datenbanken zu arbeiten.

Ferner implementiert WebLogic eine proprietäre Version des RMI. Seit Version 7 allerdings wird darauf hingewiesen, nur noch die J2EE konforme Implementierung zu verwenden.

8.2 JNDI

Die Methode "lookup()", welche fester Bestandteil des Namens- und Verzeichnisdienstes ist, wird zwar immer gleich aufgerufen und verwendet, jedoch ist es zuvor notwendig eine InitialContextFactory anzugeben. Diese ist jedoch bei den einzelnen Applikationsservern verschieden. Dazu werden die Eingaben in einer HashMap eingefügt.

8.2.1 Glassfish

Bei der Verwendung von Glassfish ist es nicht notwendig die Eigenschaft für die InitialContextFactory in einer HashMap aufzurufen. Der initialContext kann auch ohne Angabe aufgerufen werden: 

Context initialContext = new InitialContext();

8.2.2 JBOSS

Die WebSphere InitialContextFactory ist wie folgt einzurichten: 

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
Context initialContext = new InitialContext(env);

8.2.3 WebSphere

Die WebSphere InitialContextFactory ist wie folgt einzurichten: 

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
Context initialContext = new InitialContext(env);

8.2.4 WebLogic

Die WebLogic InitialContextFactory ist wie folgt einzurichten: 

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.TengahInitialContextFactory");
Context initialContext = new InitialContext(env);

8.3 Custom Taglibs

Bei der Entwicklung von JSP Seiten ist es möglich Taglibs zu verwenden, um den Quellcode so um Java-spezifischen Code zu erleichtern. Somit wird der Quellcode der JSP-Seiten nicht so umfangreich und wird leichter zu verstehen. Allerdings gibt es Probleme mit der Unterstützung der einzelnen Taglibs. Vorab unterstützt jeder hier erwähnte Applikationsserver die JSTL. Aber es gibt auch serverspezifische Erweiterungen bzw. Open-Source Erweiterungen, die nicht von allen Servern unterstützt werden. Diese werden häufig im Zusammenhang mit JSF verwendet, welches JSP-Seiten vollständig mit der Hilfe von Taglibs erzeugt.

8.3.1 Glassfish

Glassfish bringt keine Custom Tags mit sich. Es wird hier stets die JSTL verwendet, dennoch ist es möglich eigene Custom Tags zu implementieren und zu verwenden.

8.3.2 JBOSS

JBOSS bringt keine eigenen Custom Tags mit, sondern bezieht sich allein auf die in J2EE spezifizierte JSTL. Die formals im Apache Jakarta Projekt entstandene Custom Tag Library wurde mit in JSTL übernommen und wird deshalb auch nicht mehr weiterentwickelt. Es ist ferner möglich eigene Custom Tags zu implementieren.

8.3.3 WebSphere

WebSphere hat seine Datenbankanbindung und die Verabeitung der Daten mit Hilfe von einer eigenen, auf JSTL basierenden Taglib (tsx), optimiert. Diese ermöglicht dem Benutzer mit ähnlicher Syntax, z.B. tsx:dbconnect statt sql:dbconnect sich mit der Datenbank zu verbinden. Der Tag-Bezeihchner tsx kann nicht frei gewählt werden, sql hingegen schon. Eine Datenbankanbindung könnte also wie folgt aussehen[54]: 

<tsx:dbconnect id="Verbindungs-ID"
    userid="Datenbankbenutzer" passwd="Benutzerkennwort"
    url="jdbc:Subprotokoll:Datenbank"
    driver="Name_des_Datenbanktreibers"
    jndiname="JNDI_Kontext/logischer_Name">
</tsx:dbconnect>

8.3.4 WebLogic

WebLogic hingegen verwendet die JSTL Taglibs für einen solchen Aufbau der Datenbankverbindung. Oracle weißt aber darauf hin, dass man ohnehin die Datenbankverbindung nicht in der jsp-seite aufbauen sollte, sondern dies über einen Ressourcen-Pool machen soll, auf den man dann zugreift. WebLogic stellt ebenfalls eigene Tags bereits, jedoch für das Caching, Processing und Repeating. So bietet das Cache-Tag die Möglichkeit Daten, die sich im "body-Tag" befinden zwischenzuspeichern. Dieses Tag ist sehr umfangreich, so dass nur exemplarisch ein Beispiel gezeigt wird[55]: 

<wl:cache timeout="15m" async="true"> 
 <!--get the new headlines from the database every 15 minutes and display them--> 
 <!--do not let anyone see the pause while they are retrieved--> 
 </wl:cache>

Das Process-Tag ermöglicht dem Anwender die Flusskontrolle innerhalb einer JSP-Datei mittels Abfrageparameter zu steuern. Ein Beispiel ist: 

    <wl:process notname="update">
    <wl:process notname="delete">
    <!--Only show this if there is no update or delete parameter-->
    <form action="<%= request.getRequestURI() %>">
      <input type="text" name="name"/>
      <input type="submit" name="update" value="Update"/>
      <input type="submit" name="delete" value="Delete"/>
    </form>
    </wl:process>
    </wl:process>

    <wl:process name="update">
    <!-- do the update -->
    </wl:process>


    <wl:process name="delete">
    <!--do the delete-->
    </wl:process>

    <wl:process name="lastBookRead" value="A Man in Full">
    <!--this section of code will be executed if lastBookRead exists and the value of lastBookRead is "A Man in Full"-->
    </wl:process>


Das Repeat-Tag ermöglicht mehrere Typen von Mengen, inklusive Aufzählungen, Vektoren, ResultSets, Iterationen usw. zu durchlaufen. Auch kann man damit ganz übliche Schleifen erzeugen. Folgendes Beispiel zeigt die Verwendung[56]: 

<wl:repeat id="name" set="<%= new String[] { "sam", "fred", "ed" } %>"> 
  <%= name %> 
 </wl:repeat> 
 
 <% Vector v = new Vector();%> 
 <!--add to the vector--> 
 
 <wl:repeat id="item" set="<%= v.elements() %>"> 
 <!--print each element--> 
 </wl:repeat>

9 Nutzwertanalyse

Die Nutzwertanalyse wird auch als Scoring- oder Punktebewertungsmodell bezeichnet und ist ein Teilbereich der Wirtschaftlichkeitsanalyse bei der Planung eines Projekts. Um die Softwareprodukte und deren JSP-Implementierung fachgerecht bewerten zu können wird die Nutzwertanalyse zur Entscheidungsfindung eingesetzt. Die Analyse wird vielfach in Projekten angewandt, in denen mehrere Handlungsalternativen zur Verfügung stehen, die sich aber aufgrund von subjektiv bewertbarer Eigenschaften schlecht vergleichen lassen. Hierbei stellt die Nutzwertanalyse die Grundlage von wichtigen Anforderungskriterien dar und hilft bei der Analyse und Bewertung von verschiedenen Softwarealternativen. Mit diesem Verfahren lassen sich nicht nur die Rangfolgen des Produktes ermitteln, sondern auch die verschiedenen Stärken und Schwächen eines Produkts herauskristallisieren. [57] Die Ablaufreihenfolge zur Erstellung einer Nutzwertanalyse lässt sich im folgenden Abschnitt entnehmen:

  • Zielkriterienbestimmung
  • Zielkriterienbeschreibung
  • Zielkriteriengewichtung
  • Nutzwertermittlung

9.1 Zielkriterienbestimmung

Grundsätzlich kann man sagen, dass die Hersteller die J2EE Spezifikationen in den Punkten Sicherheit, Transaktionsmanagement, Namens- und Verzeichnisdienste, Persistenzdienste (langfristige Speicherung von Daten) und dem Management der Komponenten über den gesamten Lebenszyklus einhalten. Dennoch haben die Unternehmen ihre Applikationsserver mit einem weiten Spektrum an zusätzlichen Entwicklungstools oder Funktionen ausgestattet. Ein Beispiel ist Oracle Weblogic, welches eine hervorragende Implementierung zur Oracle-Datenbank besitzt, woraus sich ein Performancevorteil ergibt. Zusätzlich werden dem Anwender einige praktische Funktionen und Optimierungen an die Hand gegeben, welche den Wechsel zu einem anderen Anbieter in diesem Sektor sehr schwierig machen. Mögliche Kriterien bei der Anschaffung eines Applikationsservers können z.B. die Funktionalität, die Anpassbarkeit oder die Benutzerfreundlichkeit in Form des Administrationsaufwands sein. In unserer Ausarbeitung konzentrieren wir unsere Nutzwertanalyse auf die Unterschiede der JSP-Implementierung. Der Kriterienkatalog umfasst die APIs, die Verwendung von JNDI und die Custom Tags, die bei jedem der Applikationsserver unterschiedlich implementiert sind.

9.2 Zielkriterienbeschreibung

Die API stellt technische Schnittstellen, beispielsweise zur Datenbank des Applikationsservers, dar, über die Daten stabil und effizient ausgetauscht werden können. Diese Programmierschnittstelle ist unter anderem eine Grundlage für die Custom Tags. Über diese Schnittstelle lassen sich z.B. Produktdatenbanken und ERP-Systeme direkt an den Applikationsserver anbinden sowie herstellerspezifische Softwarelösungen anfertigen.
Das zweite Kriterium JNDI stellt Mechanismen für Applikationsserver bereit, die den transparenten Gebrauch von Namens- und Verzeichnisdiensten zulassen. Diese spielen in der JSP-Implementierung eine eher untergeordnete Rolle. Dennoch sind die Namensdienste für das Backend interessant, da sie leicht zu verändern und bekannt sind.
Die JSP-Technologie bietet einen Mechanismus für das Verändern von dynamischen Funktionen in Custom Tags, den sogenannten Erweiterungen der JSP-Sprache. Custom Tags werden in der Regel in Form einer Tag-Bibliothek definiert und enthalten die Objekte, welche die Tags implementieren. Die Tags können zwar von anderen Applikationksservern übernommen werden, jedoch benötigen diese eventuell noch weitere Implementierungen. Zudem können fehlende Tags zu mangelnder Funktionalität bzw. zu Darstellungsproblemen am Client führen, falls diese nicht hinreichend getestet wurden. Zudem sind die Fehler nicht trivial im Quelltext ersichtlich. Die Auswirkungen lassen sich meist erst im Echtbetrieb des Systems ausfindig machen.

9.3 Zielkriteriengewichtung

Die einzelnen Zielkriterien sind bei der Beurteilung der Wahlmöglichkeiten oftmals anders priorisiert. [58] Mittels der Vergabe einer Gewichtung kann so eine Reihenfolge der Präferenzen angefertigt werden. Hierbei bekommen entscheidende Kriterien eine höhere Gewichtung und weniger bedeutsame Merkmale eine niedrigere. Die Ordnung dabei hängt jedoch von der persönlichen Einschätzung der Entscheidungsträger ab. [59] Die Gewichtung der Kriterien wurde subjektiv durchgeführt. Hierbei wurde festgelegt, wie die verschiedenen Kriterien gewichtet werden sollen. Die Gewichtung von Custom Tags wurde auf 60 Prozent beurteilt. Mit weiteren 20 Prozent werden die APIs gewichtet. Mit den restlichen 20 Prozent wird das Kriterium JNDI bewertet. Damit sich alle Werte gut miteinander vergleichen lassen, wird bei der Nutzwertanalyse die Kardinalskala 0-10 angewandt.

9.4 Nutzwertermittlung

Kriterien / Produkt Gewichtung Glassfish Websphere JBOSS WebLogic
APIs
20 %
5
9
5
7
JNDI
20 %
8
6
6
6
Custom Tags
60 %
5
7
5
9
Summe
100 %
56
72
52
78

Tabelle 1: Gesamtnutzen einer JSP-Implementierung

Die Nutzwertanalyse zeigt, dass alle Produkte die Funktionalitätsansprüche erfüllen. Hingegen gibt es für die Produkte Glassfish und JBOSS Punktabzug in der Vielfalt der zur Verfügung gestellten APIs, da diese nur die Spezifikation erfüllen und darüber hinaus keine charakteristischen Merkmale bieten. Das Produkt WebLogic punktet damit, dass es eine High-Level API für Datenbank mitbringt, die es ermöglicht auch ohne Kenntnisse der DBMS-Tabellenstrukturen damit zu arbeiten. Das Produkt WebSphere überzeugt durch eine umfassende Auswahl an APIs, womit man verschiedene Geschäftssysteme miteinander verbinden kann. Zudem bietet das Produkt neben dem erleichterten Datenbankzugriffs einige Vorteile, da eine erweiterte Servlet API mitgeliefert wird, welche einfachere Wiederverwendbarkeit erlaubt.
Die Glassfish-Lösung besticht durch eine konsequente Umsetzung des J2EE-Standards, da bei JNDI nicht einmal eine Angabe zum Initial Context Factory benötigt wird und sich die mögliche Änderungen in Grenzen halten. Die anderen Produkte erhalten sechs Punkte, weil sie jeweils ihre eigene Factory mitbringen und man sich somit darüber informieren muss, welche implementiert werden muss. Allerdings sind diese Factories etwas überarbeitet und erfüllen voll die Anforderungen.
Die Produkte Weblogic und Websphere bestechen vor allem durch die mitgebrachten Custom Tags, so ermöglichen sie zum einen den einfacheren Datenbankenzugriff und ermöglichen somit eine bessere Verwaltung und Nutzung der Ressourcen. Zum anderen bietet z.B. WebLogic die Möglichkeit mittels des Repeat-Tags verschiedene Datenstrukturen zu durchlaufen und auszugeben. Weiterhin haben sowohl WebSphere als auch WebLogic die Möglichkeit das Caching für bestimmte Bereiche einer Webseite zu aktivieren, um ausgewählte Aktionen auf der Webseite zu beschleunigen. Ein weiterer positiver Gesichtspunkt ist auch, dass die Produkte WebSphere und WebLogic eine leichtere Wiederverwendbarkeit und eine gute Trennung von Präsentations- und Logikschicht bieten. Der Gewinner der Nutzwertanalyse ist die Softwarelösung WebLogic der Firma Oracle mit 78 Punkten, die den höchsten Wert im Vegleich erzielt.

10 Fazit

Nach dem Vergleich der verschiedenen Applikationserver ist zu erkennen, dass das Produkt WebLogic den höchsten Funktionsumfang im Bereich der JSP-Implementierung aufweist. Die Analyse der Applikationsserver zeigt, dass die Software WebLogic besonders gute Ansätze und Funktionalitäten im Bereich der JSP-Implementierungen bietet. Abschließend ist der Einsatz von WebLogic in Unternehmen, die einen hohen Wert auf Custom Tags und die damit verbundenen Vorteile legen zu empfehlen. Es zeigte sich hierbei auch, dass beide Open Source Produkte sich sehr nah an der J2EE-Spezifikation bewegen und keinen erweiterten Funktionsumfang von sich aus mitbringen. Einzig die kommerziellen Lösungen konnten dahingegend punkten und setzen sich somit von den Open Source Lösungen ab.
Aber es gehört nicht nur die JSP-Implementierungen zu einem Applikationsserver. Da es sich bei JSP lediglich um eine View Komponente handelt, ist dies nur ein kleiner Teil des Applikationsservers. Streng genommen reicht für JSP-Seiten auch einzig der Web-Container. Der Applikationsserver zeigt seinen vollen Nutzen erst durch die Verwendungen von Enterprise Java Beans und damit verbunden der Geschäftslogik und dem Zugriff zur Datenbank. Dort kann sich ein Applikationsserver viel umfangreicher von anderen absetzen, beispielsweise durch eine erhöhte Sicherheit bei der Übertragung von Geschäftsdaten.

So ist es auch wichtig einen Applikationsserver weniger auf Grund der JSP-Implementierung auszuwählen, da die Unternehmen oft eigene Anforderungen oder Ansprüche an Server mitbringen, um eigene Geschäftsprozesse abzubilden. Häufige Anforderungen sind kurze Antwortzeiten, hohe Sicherheit und einfache Erweiterbarkeit und Verwaltung.

Weiterhin wird die kommende Entwicklung von Web-Anwendungen interessant sein, da sich derzeit abzeichnet, dass man Weg von der JSP-Implementierung und hin zur JSF-Implementierung geht. Diese ist durch die starke und fast ausschließliche Fokussierung auf Tags bereits in die JSP-Implementierung eingegangen.

11 Fußnoten

  1. ↑ Vgl. Langner, Torsten; Reiberg, Daniel (2006), Seite 4f.
  2. ↑ Saake, Gunter; Sattler, Kai-Uwe (2000), Seite 379ff
  3. ↑ Vgl. Saake, Gunter; Kai-Uwe Sattler (2000), Seite 379ff
  4. ↑ Vgl. Langner, Torsten; Reiberg, Daniel (2006), Seite 5f.
  5. ↑ Saake, Gunter; Sattler, Kai-Uwe (2000), Seite 379ff
  6. ↑ Vgl. Saake, Gunter; Sattler, Kai-Uwe (2000), Seite 379ff
  7. ↑ Vgl. Langner, Torsten; Reiberg, Daniel (2006), Seite 6f.
  8. ↑ Langner, Torsten; Reiberg, Daniel (2006), Seite 6
  9. ↑ Vgl. Mattern, Thomas (2001), Seite 3f.
  10. ↑ Vgl. Mattern, Thomas (2001), Seite 4f.
  11. ↑ Vgl. Uni Tübingen, Seite 4.
  12. ↑ Hochschule für Technik, Wirtschaft und Kultur Leipzig, http://www.imn.htwk-leipzig.de/~weicker/upload//Main/middleware.png
  13. ↑ Vgl. Hammerschall, Ulrike (2005), Seite 33ff.
  14. ↑ Vgl. Hammerschall, Ulrike (2005), Seite 46.
  15. ↑ Vgl. Heinzl, Steffen; Mathes, Markus (2005), Seite 212f.
  16. ↑ Vgl. Heldt, Stefan; Wirdemann, Ralf (2003), Seite 65f.
  17. ↑ Vgl. Mountjoy, Jon; Chugh, Avinash (2004), Seite 4
  18. ↑ Stark, Thomas (2007), Seite 299
  19. ↑ Vgl. Ebel, Nadin (2005), Seite 386
  20. ↑ Vgl. Ebenda
  21. ↑ Vgl. Kumar, Pankaj (2004), Seite 255f
  22. ↑ Vgl. Stark, Thomas (2007), Seite 301f.
  23. ↑ Vgl. Niemeyer, Patrick; Knudsen, Jonathan (2002), Seite 5
  24. ↑ Ebenda
  25. ↑ Heldt, Stefan; Wirdemann, Ralf (2003), Seite 71
  26. ↑ Vgl. Stark, Thomas (2007), Seite 365ff.
  27. ↑ Vgl. Ebenda, Seite 256ff.
  28. ↑ Stark, Thomas (2007), Seite 256
  29. ↑ Vgl. Ebenda, Seite 301
  30. ↑ Vgl. Ebenda, Seite 322f.
  31. ↑ Stark, Thomas (2007), Seite 322
  32. ↑ Vgl. Stark, Thomas (2007), Seite 302
  33. ↑ Vgl. Ebenda, Seite 302f.
  34. ↑ Vgl. Heldt, Stefan; Wirdemann, Ralf (2003), Seite 46
  35. ↑ Vgl. Ebenda, Seite 48
  36. ↑ Vgl. Heffelfinger, David R. (2007), Seite 291
  37. ↑ Vgl. Heinisch, Cornelia; Goll, Joachim (2007), Seite 1113f.
  38. ↑ Vgl. Heffelfinger, David R. (2007), Seite 301
  39. ↑ Stark, Thomas (2007), Seite 308
  40. ↑ Vgl. Bergsten, Hans (2003), Seite 3f.
  41. ↑ Robert J. Brunner (2003), Seite 9
  42. ↑ Vgl. Hall, Marty; Brown, Larry (2003), Seite 353
  43. ↑ Vgl. Ebenda, Seite 325f.
  44. ↑ Vgl. Ebenda, Seite 332
  45. ↑ Vgl. Stark, Thomas (2009), Seite 163f.
  46. ↑ Vgl. Qian, Kai; Allen, Richard (2006), Seite 120ff.
  47. ↑ Vgl. Stark, Thomas (2007), Seite 253f.
  48. ↑ Vgl. Burke, Bill; Monson-Haefel, Richard (2006), Seite 38
  49. ↑ Vgl. Fleury, Stark, Richards(2006), Seite 15f.
  50. ↑ Vgl. Fleury, Stark, Richards(2006), Seite 24
  51. ↑ Vgl. Schäffer, Steffan (2002), Seite 44ff
  52. ↑ Vgl. http://www.manager-magazin.de/it/artikel/0,2828,528979,00.html
  53. ↑ Vgl. Stark, Thomas (2009), Seite 22
  54. ↑ http://publib.boulder.ibm.com/infocenter/wasinfo/v5r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/cweb_taglibs.html
  55. ↑ http://download-llnw.oracle.com/docs/cd/E13222_01/wls/docs81/jsp/customtags.html#57021
  56. ↑ http://download-llnw.oracle.com/docs/cd/E13222_01/wls/docs81/jsp/customtags.html#57059
  57. ↑ Vgl. Adam, Dietrich(1996) Seite 413
  58. ↑ Vgl. Heinrich, Lehner (2005), Seite 383
  59. ↑ Vgl. Vahs, Dietmar (2003), Seite 461

12 Literaturverzeichnis

Adam, Dietrich (1996) Adam, Dietrich (1996): "Planung und Entscheidung – Modelle – Ziele – Methoden, Mit Fallstudien und Lösungen", 4. Auflage, Wiesbaden
Bergsten, Hans (2003) Bergsten, Hans (2003): "JavaServer pages", 3. Auflage, O'Reilly Media, USA-Sebastopol - Kalifornien
Brunner, Robert (2003) Brunner, Robert (2003): "A Practical Guide for Programmers.: Practical Guide for Programmers (Practical Guides)", Morgan Kaufmann, USA-San Francisco - Kalifornien
Burke, Bill; Monson-Haefel, Richard (2006) Burke, Bill; Monson-Haefel, Richard (2006): "Enterprise JavaBeans 3.0", O'Reilly Media, USA-Sebastopol - Kalifornien
Ebel, Nadin (2005) Ebel, Nadin (2005): "WebSphere/Domino Workplace Administration", Addison-Wesley, München
Fleury, Marc; Stark, Scott; Richards, Norman (2006) Fleury, Marc; Stark, Scott; Richards, Norman (2006): "JBOSS 4.0 - Das offizielle Handbuch", Addison-Wesley Verlag, München
Hall, Marty; Brown, Larry (2003) Hall, Marty; Brown, Larry (2003): "Core Servlets and JavaServer Pages: Volume 1: Core Technologies", 2. Auflage, Prentice Hall, aus Sun Core Series, USA-Santa Clara - Kalifornien
Hammerschall, Ulrike (2005) Hammerschall, Ulrike (2005): "Verteilte Systeme und Anwendungen", Pearson Studium, München
Heffelfinger, David R. (2007) Heffelfinger, David R. (2007): "Java EE 5 Development using GlassFish Application Server", Packt Publishing, UK-Birmingham
Heinisch, Cornelia; Goll, Joachim (2007) Heinisch, Cornelia; Goll, Joachim (2007): "Java als erste Programmiersprache - Vom Einsteiger zum Profi", 5. Auflage, Vieweg+Teubner Verlag, Wiesbaden
Heinrich, Lutz J., Lehner, Franz (2005) Heinrich, Lutz J., Lehner, Franz (2005): "Informationsmanagemen"t, 8. Auflage, München, Wien
Heinzl, Steffen; Mathes, Markus (2005) Heinzl, Steffen; Mathes, Markus (2005): "Middleware in Java", Vieweg+Teubner Verlag, Wiesbaden
Heldt, Stefan; Wirdemann, Ralf (2003) Heldt, Stefan; Wirdemann, Ralf (2003): "Enterprise JavaBeans komplett, Grundlagen, Überblick und Einsatz von EJB 2.1", Oldenbourg-Verlag, München
Hochschule für Technik, Wirtschaft und Kultur Leipzig Hochschule für Technik, Wirtschaft und Kultur Leipzig - Middleware als Mittelschicht, http://www.imn.htwk-leipzig.de/~weicker/upload//Main/middleware.png (30.12.2009, 10:08)
Kumar, Pankaj (2004) Kumar, Pankaj (2004): "J2EE security for servlets, EJBs and Web services", Prentice Hall, aus HP-Professional Series, USA - New Jersey
Langner, Torsten; Reiberg, Daniel (2006) Langner, Torsten; Reiberg, Daniel (2006): "J2EE und JBoss. Verteilte Enterprise Applikationen auf Basis von J2EE, JBoss & Eclipse. Grundlagen und Profiwissen", Carl Hanser Verlag, München
Mattern, Thomas (2001) Mattern, Thomas (2001): "Applikationsserver – flexible Softwareinfrastruktur für verteilte Anwendungen"
Mountjoy, Jon; Chugh, Avinash (2004) Mountjoy, Jon; Chugh, Avinash (2004): "WebLogic: the definitve guide", O'Reilly Media, USA-Sebastopol - Kalifornien
Niemeyer, Patrick; Knudsen, Jonathan (2002) Niemeyer, Patrick; Knudsen, Jonathan (2002): "Learning Perl", 2. Auflage, O'Reilly Media, USA-Sebastopol - Kalifornien
Saake, Gunter; Sattler, Kai-Uwe (2000) Saake, Gunter; Sattler, Kai-Uwe (2000): "Datenbanken & Java. JDBC, SQLJ und ODMG", Mai 2000
Schäffer, Steffan (2002) Schäffer, Steffan (2002): "Enterprise Java mit IBM WebSphere: J2EE-applikationen effizient entwickeln", München 2002
Stark, Thomas (2007) Stark, Thomas (2007): "J2EE Master Class. Einstieg für Anspruchsvolle", Pearson Studium, München
Stark, Thomas (2009) Stark, Thomas (2009): "Java EE 5: Einstieg für Anspruchsvolle", Addison-Wesley, München
Qian, Kai; Allen, Richard (2006) Qian, Kai; Allen, Richard (2006): "Java Web Developement Illuminated", Jones and Bartlett Publishers, USA
Uni Tübingen Uni Tübingen - Middleware, http://www-ti.informatik.uni-tuebingen.de/os390/foils/tx01.pdf (30.12.2009, 10:02)
Vahs, Dietmar (2003) Vahs, Dietmar (2003): "Organisation – Einführung in die Organisationstheorie und Organisationspraxis", 4. Auflage, Stuttgart
Von „http://winfwiki.wi-fom.de/index.php/Unterschiede_der_JSP-Implementierung_zwischen_Glassfish%2C_Websphere%2C_JBOSS_und_WebLogic“
Persönliche Werkzeuge