Implementierung einer Referenzanwendung für den JBoss Application Server unter Verwendung der Java 2 Enterprise Edition

Transkript

1 Implementierung einer Referenzanwendung für den JBoss Application Server unter Verwendung der Java 2 Enterprise Edition Mark Rambow geb. am in Potsdam Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker (FH) eingereicht an der Fachhochschule Brandenburg - Fachbereich Informatik und Medien - Betreuer Erstprüfer: Prof. Dr. Ing. Stefan Edlich (Fachhochschule Brandenburg) Zweitprüfer: Prof. Dr. Ing. Thomas Preuß (Fachhochschule Brandenburg) Brandenburg an der Havel, 22. Mai 2004

2

3 Danksagung Durch die Auswahl des Themas und die gemeinsame Bestimmung der Schwerpunkte mit meinem betreuenden Prof. Dr. Stefan Edlich, ist die vorliegende Diplomarbeit zum interessantesten Teil meines Studiums geworden. Für die Unterstützung bei der Umsetzung möchte ich mich hiermit bei meinen Betreuern Prof. Dr. Stefan Edlich und Prof. Dr. Thomas Preuß bedanken. Ebenfalls möchte ich mich an dieser Stelle bei meinen Kommilitonen Christian Koth, Jens Ziegler, Oliver Kalz, Andreas Graff und Mathias Meyer bedanken. Durch ihre konstruktive Kritik und ihr fachliches Wissen konnten einige Fragen, die im Verlauf der Arbeit auftraten, geklärt werden. Meinen Eltern möchte ich für die hervorragende Unterstützung während des gesamten Studiums danken. Mark Rambow

4

5 Inhaltsverzeichnis 1. Einleitung Thematik und Aufbau der Arbeit Motivation Aufgabenstellung Theoretische Grundlagen Einführung in plattformunabhängige Programmierung Die Java-Plattform XML als plattformunabhängiges Datenformat SQL, die Standard-Datenbank-Anfragesprache Verteilte Anwendungen Komponenten Komponentenmodelle in Java Alternative Komponentenmodelle Vergleich der Komponentenmodelle Softwareentwicklung für komponentenbasierte Systeme Komponenten-Engineering UML als Standard zur Modellierung des Entwicklungsprozesses Enterprise JavaBeans Rollenmodell bei J2EE Enterprise Bean-Provider Application Assembler Deployer

6 vi Inhaltsverzeichnis EJB-Server-Provider EJB-Container-Provider System-Administrator Architektur der Enterprise JavaBeans J2EE-Server EJB-Container Programmierrestriktionen bei EJB Enity Beans Aufbau einer Entity Bean Bean Managed Persistence Container Managed Persistence Container Managed Relations Client-Sicht Alternativen für persistente Objekte Session Beans Stateless Session Beans Stateful Session Beans Client-Sicht Message-Driven Beans Transaktionen JBoss Application Server Architektur des JBoss Java Management Extension Aufbau des JBoss-Kerns JBoss Interceptor-Architektur Deployment JBoss Classloading JBoss Deployment-Komponenten Hot-Deployment Vorgang des Deployments Clustering Cluster-Architektur des JBoss

7 Inhaltsverzeichnis vii 4.3. EJB-Container Webserver JBoss-Konfiguration JBoss-Standard-Konfigurationen JBoss-spezifische Deployment-Deskriptoren Konfiguration für HTTPS-Verbindungen JBoss Version AOP Werkzeuge für den JBoss Application Server Ant XDoclet Entwickler-Werkzeuge für die JBoss-Plattform Integrierte Entwicklungsumgebungen Vergleich zwischen J2EE-Application-Servern JOnAS Oracle 10g und Orion Application Server BEA WebLogic IBM WebSphere Fazit Referenz-Anwendung Zielsetzung Anwendungsfälle - UML Aufbau, Architektur und Entwurfsmuster Multitier-Anwendung Entwurfsmuster: MVC 2 - Web Entwurfsmuster: Session-Fassade Entwurfsmuster: DTO Data Transfer Object Entwurfsmuster: UUID Backend der Anwendung Datenmodell Web-Anwendung Aufbau und Architektur der Anwendung

8 viii Inhaltsverzeichnis Web-Benutzer-Interface Konfiguration der Anwendung Administrator-Anwendung Architektur der Administrator-Anwendung Verbindung mit JBoss WAP-Frontend Zusammenfassung und Ausblick Zukunftsprognose Einsatzmöglichkeiten der entwickelten Anwendung Notwendige Erweiterungen für einen produktiven Einsatz Die Anwendung als Beispiel zur Erstellung von J2EE Applikationen Fazit A. Anhang 135 A.1. Servlet und JavaServer Pages A.1.1. Servlets A.1.2. JavaServer Pages A.2. Deployment A.3. JBoss Management Konsole A.4. Datenmodell der Referenzanwendung A.5. Konfiguration der Web-Anwendung A.6. Inhalt der CD Abbildungsverzeichnis 149 Tabellenverzeichnis 151 Quelltextverzeichnis 153 Listings 153 Literaturverzeichnis 155 Selbstständigkeitserklärung 159

9 1. Einleitung Durch zunehmende Globalisierung und gemeinschaftliches Arbeiten bei räumlicher Trennung gewinnt die Vernetzung von Unternehmensanwendungen immer mehr an Bedeutung. Das World Wide Web ermöglicht den Zugriff auf die Daten von Unternehmen. Um dieser Entwicklung gerecht werden zu können ist es notwendig, Konzepte für eine Infrastruktur zu schaffen, welche die dabei auftretenden Probleme beherrschbar macht. Dieser Herausforderung stellen sich Unternehmen wie Sun Microsystems oder Microsoft. In dieser Arbeit soll auf die von Sun eingeführte, Java 2 Platform, Enterprise Edition (J2EE) eingegangen werden. Um deren Vorteile nutzen zu können, wird ein Application-Server verwendet, welcher die benötigten Dienste bereitstellt. In der vorliegenden Diplomarbeit soll eine Evaluation des Open-Source-Projekt JBoss Application Server durchgeführt werden, dabei wird JBoss auch kommerziellen Produkten gegenübergestellt. Ziel ist es, dem Leser sowohl ein Verständnis für das Erstellen von Anwendungssoftware auf Basis von J2EE zu vermitteln, als auch den JBoss Application Server detailliert und kritisch zu untersuchen Thematik und Aufbau der Arbeit Diese Arbeit beschäftigt sich mit der Erstellung einer Referenzimplementierung für den JBoss Application-Server. In diesem Zusammenhang wird in die Grundlagen für die Erstellung von komponentenbasierten Systemen auf J2EE-Basis eingeführt, einige best practises in Form von Entwurfsmustern (Pattern) vorgestellt und Quellcodebeispiele zur Veranschaulichung angeführt. Der zweite Schwerpunkt dieser Arbeit befasst sich mit Application-Servern, speziell mit dem JBoss. Dabei wird der JBoss genau untersucht und seine Konfiguration erläutert. Um den JBoss Application Server im Markt einordnen zu können, wird ein kurzer Vergleich mit

10 2 1. Einleitung den Konkurenzprodukten durchgeführt. Es soll gezeigt werden, welche Kriterien für den Einsatz eines Application-Server sprechen und was beim Einsatz zu beachten ist Motivation JBoss ist ein Open-Source Application-Servern für J2EE Anwendungen. Dadurch ist er sowohl für kosteneffizient arbeitende kleinere Unternehmen interessant, die ihn kostenlos einsetzen können als auch für große Unternehmen, die in der Verfügbarkeit des Quellcodes mehr Sicherheit für ihr Unternehmen erkennen. Durch seine große Entwicklergemeinde, die als JBoss Group gemeinsam das Projekt vorantreiben, gehört er zu den sich am schnellsten weiterentwickelnden Application-Servern. Durch den Einsatz neuester Technologien gehen vom JBoss immer wieder Impulse aus, die ihn besonders interessant für die Untersuchung machen Aufgabenstellung Die Aufgabenstellung umfasst sowohl die Erstellung einer Referenzimplementierung auf Basis des JBoss als auch die genaue Untersuchung des JBoss Application Servers. Das zu entwickelnde Programm stellt ein Beispiel für J2EE-Anwendungen dar. Sie soll nicht den Anforderungen eines Produktivsystems gerecht werden, sondern vielmehr als Studienobjekt Entwickler bei der Erstellung von J2EE-Anwendungen und dem Betrieb des JBoss Application Server unterstützen.

11 2. Theoretische Grundlagen Die Basis für komplexe Anwendungen im J2EE 1 -Bereich bildet die Programmiersprache Java 2, auf der die Enterprise Edition aufbaut. Im Rahmen dieser Diplomarbeit kann keine vollständige Einführung in die Softwareentwicklung mit Java gegeben werden. Vielmehr geht es um die Vermittlung von Konzepten, die bei der Entwicklung von J2EE-Applikationen Verwendung finden. Weitere wichtige Grundlagen stellen die Auszeichnungssprache XML 3 und die Datenbank- Anfragesprache SQL 4 dar. In welchem Zusammenhang sie mit der Entwicklung von Enterprise Systemen stehen, wird im ersten Abschnitt dieses Kapitels veranschaulicht. Der daran anschließende Abschnitt Verteilte Anwendungen geht tiefer auf die Programmierung mit der Java 2 Enterprise Edition ein. Es soll ein Überblick über die verfügbaren Komponenten der J2EE gegeben und diese mit anderen Modellen verglichen werden. Den Abschluss des Kapitels bildet der Abschnitt Softwareentwicklung für komponentenbasierte Systeme. Hier wird auf das Softwareengineering bei J2EE Anwendungen eingegangen und es werden Standards vorgestellt, die diesen Prozess unterstützen Einführung in plattformunabhängige Programmierung Unter Plattformunabhängigkeit versteht man die Unabhängigkeit einer entwickelten Software von einer spezifischen Zielplattform. In die Betrachtung müssen dabei sowohl die Hardware als auch die verwendeten Betriebssysteme einbezogen werden. Unter anderem ist dabei sicherzustellen, dass alle Datentypen den gleichen Wertebereich ausschöpfen z. B. 1 Java 2 Platform, Enterprise Edition 2 Java ist eingetragenes Markenzeichen der Sun Microsystems Cooperation 3 Extensible Markup Language 4 Structured Query Language

12 4 2. Theoretische Grundlagen ist der Integer-Wertebereich maschinenabhängig. Eine weitere Anpassung bezieht sich auf die Haltung von Daten im Hauptspeicher. Dieser kann als Big-Endian oder Little-Endian organisiert sein. Dabei bedeutet Big-Endian, dass die Bytes in einer Speicherzelle vom höchstwertigen Byte links zum niederwertigsten Byte rechts angeordnet werden. Beim Little-Endian -Format, welches hauptsächlich von Intel bevorzugt wird, steht das niederwertigste Byte links, das höchstwertige Byte rechts [Cur94]. Auch der Zugriff und Austausch von Daten muss geregelt werden. Immer häufiger kommt daher eine Datenaustauschsprache zum Einsatz, die öffentlich spezifiziert wurde - XML. Auch offen gelegte Standards bei Netzwerkprotokollen helfen hier Plattformunabhängigkeit zu erreichen. Um dieses Konzept zu verwirklichen ist es erforderlich, eine Vermittlerinstanz (Middleware) zwischen den Programmcode und die Zielplattform zu schalten. Mit einer solchen Middleware kann z. B. ein Java-Programm mit einem in COBOL 5 implementierten Programm auf einem Mainframe kommunizieren. Hierbei könnte z. B. CORBA 6 als Middleware eingesetzt werden. Ein gutes Beispiel für offene Protokolle zur Kommunikation findet man u. a. bei den WebServices. Hier wird mittels SOAP 7 und einer Servicebeschreibung in XML der Zugang zu Programmen unterschiedlicher Programmiersprachen und Systeme hergestellt. Ein weiterer Ansatz, der bei portablen Programmen unterschiedlicher Sprachen zum Einsatz kommt, ist eine Laufzeitumgebung, wie sie bei der Sprache Java oder der.net-sprachfamilie zu finden sind. Diese Sprachen nennt man interpretierte Programmiersprachen. Im Fall von Java wird kein nativer Code erzeugt, sondern Bytecode, der von der JVM 8 interpretiert wird. Das hat den Vorteil, dass man Programmcode auf jedem Rechner, für den eine JVM verfügbar ist, ohne Änderungen ausführen kann. Dieses Prinzip nennt Sun Write Once, Run Anywhere Die Java-Plattform Als Sun 1995 die Programmiersprache Java veröffentlichte, wuchs deren Verbreitung mit der gleichzeitig wachsenden Popularität des Internets. Java setzte sich zum Ziel, die unterschiedlichsten Hard- und Softwareplattformen in der Art zu vereinen, dass Java-Programme ohne Codeanpassungen überall dort lauffähig sind, wo eine JVM installiert ist. 5 Common Business Oriented Language 6 Common Object Request Broker Architecture 7 Simple Object Access Protocol 8 Java Virtual Maschine

13 2. Theoretische Grundlagen 5 Die ersten Java-Programme waren Applets, die in Browsern ausgeführt und von einem Server bei Bedarf geladen wurden. Der Vorteil dieser Programme war, dass eine Oberfläche für dynamische Interaktion von Webseiten mit deren Benutzern geschaffen wurde. Oftmals wurden mit Applets jedoch auch einfach nur Webseiten, z. B. durch animierte Logos, aufgewertet. Die Benutzer dieser Programme können sicher sein, dass diese keinen Schaden verursachen. Java-Applets laufen in der sogenannten Sandbox ab. Das heißt, dass sie nicht auf Systemressourcen zugreifen können. Aufgrund der Applet-Technologie wird Java oft als die Sprache des Internets bezeichnet. Doch die Java-Plattform kann weitaus mehr und entwickelt sich in rasantem Tempo weiter. Durch die Auslegung Javas als objektorientierte Programmiersprache mit einer Vielzahl von APIs 9, z. B. für Netzwerkprogrammierung und Sicherheit, wurde Java unter anderem auch für Serverprogrammierung interessant. Der eigentliche Durchbruch auf diesem Gebiet gelang Sun mit der Spezifikation von J2EE mit den Teilspezifikationen der Servlets und JavaServer Pages (vgl. A.1) sowie der Enterprise JavaBeans (EJB), die in Kapitel 3 beschrieben werden. Die Plattformunabhängigkeit half dabei der Marktdurchdringung, so dass Java eine der am häufigsten verwendeten Programmiersprachen ist. Tools Application Programming Interface Applets JavaBeans TM EJBs JSPs Servlets EJB Container Messaging Transactions Mail TM Java 2 SDK, Standard Edition CORBA RMI Database Naming/Directory Connectors Java Virtual Maschine Hardware Platform Abb. 2.1: Java und J2EE Quelle: [SM97] 9 Application Programming Interface

14 6 2. Theoretische Grundlagen Plattformunabhängigkeit - Portabilität Erreicht wurde die Plattformunabhängigkeit Javas durch einen Zwischenschritt bei der Übersetzung des Quelltextes in einen lauffähigen Code. Statt eines Compilers, der Programme in Maschinensprache übersetzt und so lauffähig macht, übersetzt der Java Compiler das Programm in einen maschinenunabhängigen Bytecode. Dieser kann dann in einer virtuellen Maschine ausgeführt werden. Sun bzw. deren Tochterunternehmen JavaSoft sorgen dafür, dass für die meisten Hard- und Softwareplattformen eine solche JVM verfügbar ist. Dieses Konzept orientierte sich am aktuellen Bedarf. In einer heterogenen Landschaft wie dem Internet gab es nun die Möglichkeit, Software nicht mehr für eine bestimmte Plattform zu entwickeln, sondern für einen definierten Benutzerkreis. Doch nicht nur reine Java-Programme und Applets sind portabel, auch andere Komponenten die in Java entwickelt wurden, so z. B. die Enterprise JavaBeans der J2EE-Spezifikation. Diese sind ohne Javacode-Anpassungen zwischen den Application-Servern unterschiedlicher Hersteller austauschbar. Geringfügige Anpassungen, die bei solch komplexen Softwaresystemen notwendig sind, werden mittels XML-Dateien konfiguriert. Diese sind ebenfalls durch ihre Repräsentation als reiner Text auf jeder Plattform bearbeitbar. Solche Anpassungen sind einfach und weniger fehlerträchtig, als die Portierung eines in C++ geschriebenen Softwaresystems von Windows auf z. B. Linux. Die Portabilität aller Bestandteile der Java-Plattform lässt Entwickler aus einer Vielzahl möglicher Implementierungsvarianten auswählen, wodurch besser skalierbare und individueller zugeschnittene Softwaresysteme entstehen können. Die Entwicklung der Plattformunabhängigkeit geht jedoch weiter und betrifft nicht nur die Java Softwareentwicklung. Durch die Einführung von WebServices ist mittlerweile die Interoperabilität zwischen sehr unterschiedlichen Rechner-Architekturen möglich, selbst wenn der WebService von einem Programm einer anderen Programmiersprache zur Verfügung gestellt wird. Konzepte der Sprache Die Eigenschaften Javas, wie Dynamik, Robustheit und Sicherheit, ließen aus der vermeintlichen Internetsprache schnell eine universell einsetzbare Programmiersprache werden.

15 2. Theoretische Grundlagen 7 Die Objektorientierung veränderte die Art der Softwareentwicklung. Das Modellieren von komplexen Objekten entspricht viel eher der Art, wie Menschen ihre Umgebung wahrnehmen. Dieses Programmierparadigma kann als Grundlage für das neue Konzept der komponentenorientierten Softwareentwicklung angesehen werden. Hierbei wird noch weiter generalisiert ohne die Möglichkeit zu verlieren, detailgenaue Abbildungen der Wirklichkeit zu schaffen. Als völlig neu entwickelte Sprache konnte sich Java auch von einigen in anderen Sprachen existierenden Konzepten lösen, die sowohl in der Entwicklung als auch im Betrieb eines Programms zu Fehlern führen können. Konzepte, die nicht in Java aufgenommen wurden, sind unter anderen die aus der Sprache C und C++ bekannte Zeigerarithmetik, die Mehrfachvererbung oder auch die goto-anweisung, um nur einige wichtige zu nennen [Krü02]. Das Weglassen dieser Eigenschaften hatte jedoch außer einer Umgewöhnung für Umsteiger aus anderen Sprachen mehr Vor- als Nachteile. Java ist um einige Syntaxelemente ärmer als z.b. C++ und deshalb leichter zu erlernen, zum anderen ist die Sprache dadurch stabiler. Alle Speicherzugriffe werden von der JVM durchgeführt. Hierbei tritt auch der Garbage Collector als eine wichtige Eigenschaft von Java auf. Wo C-Programmierer noch selbst dafür sorgen mussten Speicher freizugeben, läuft in Java in gewissen Zeitabständen der Garbage Collector als Prozess. Dieser sucht nach nicht referenzierten Java-Objekten. Wenn ein solches Objekt gefunden wurde, wird der belegte Speicherplatz wieder freigegeben bzw. die finalize-methode aufgerufen. Ein Absturz eines Javaprogramms, das Auftreten eines Nullpointers oder eine andere Ausnahme wird durch die Ausnahmebehandlung 10 der JVM verarbeitet und, wenn nötig, die fehlerhafte Anwendung kontrolliert beendet. Die Ausnahmebehandlung trägt jedoch nicht nur durch das Abfangen von Fehlern zur Stabilität bei. Durch diesen Mechanismus ist es auch leichter, Fehler im Programmcode während der Entwicklung zu finden und so entsprechend auszuschließen. Dies führt dazu, dass die Programme fehlerfreier und fehlertoleranter sind. Das Sicherheitskonzept von Java ist dafür zuständig, dass Programme und Daten nicht kompromittiert oder von Unbefugten gelesen werden können. Zugriffe auf Daten und Ressour- 10 Exceptionhandling

16 8 2. Theoretische Grundlagen cen werden nur autorisierten Personen gestattet. Dieses Sicherheitskonzept wird zusätzlich durch die Java Cryptographic API unterstützt, die die Verschlüsselung jeglicher Daten ermöglicht. Der Java Security Manager sorgt für die Verwaltung von Zugriffsrechten. Dabei kann er eingesetzt werden, um z. B. den Zugriff auf das Netzwerk oder auf bestimmte Dateien zu verhindern. Der Security Manager arbeitet mit einer Positivliste: alles was nicht erlaubt ist, ist verboten. Um den Security Manager einzusetzen, muss das Programm jedoch mit der entsprechenden Option gestartet werden [Ull03]. Applets benutzen grundsätzlich den Security Manager, der vom Browser beim Start der JVM aktiviert wird. Da Java durch die Möglichkeit, Programmteile bei Bedarf nachzuladen, sehr oft in verteilten Systemen eingesetzt wird, gibt es auch einen Mechanismus, um Programm-Pakete zu signieren. Die Dateien, die dabei meist übertragen werden, sind JARs 11. Dies hilft dem Empfänger zu überprüfen, wessen Programmteil er empfängt, und gibt ihm die Sicherheit, dass auf dem Weg durch das Netzwerk der Bytecode nicht manipuliert wurde XML als plattformunabhängiges Datenformat Die Extensible Markup Language (XML) entstand aus der Standard Generalized Markup Language (SGML), einem ISO-Standard 12. Nachdem SGML nicht die gewünschte Akzeptanz fand, begann das W3C (World Wide Web Consortium) unter Mitwirkung der Industrie einen neuen Standard zu entwickeln. XML wurde sehr schnell in der Industrie angenommen und fand eine enorm schnelle Verbreitung. Zum Ziel gesetzt hatte sich das W3C, einen Sprach-Standard zu etablieren, der es ermöglicht, Daten zu strukturieren und über das Internet auszutauschen. Ursprünglich war XML dazu gedacht, elektronische Publikationen zu unterstützen und so das Design von der Darstellung zu lösen (nach [Qui04]). Durch den allgemeinen Charakter von XML lassen sich fast beliebige Daten darstellen und auch andere Auszeichnungssprachen wie HTML 13 oder auch SVG 14 damit beschreiben. Es wird jedoch noch lange dauern bis sich reine oder generierte HTML-Seiten vollständig durch XML- 11 Java Archives 12 International Organisation for Standardization 13 Hypertext Markup Language 14 Scalable Vector Graphics

17 2. Theoretische Grundlagen 9 Seiten ersetzen lassen, die mit Hilfe von XSLT 15 zum gewünschten Dokument umgeformt werden. In XML verfasste Dokumente unterliegen den Richtlinien der XML-Spezifikation [Qui04]. Zum einen müssen XML-Dokumente wohlgeformt sein, das heißt, dass jedes geöffnete Tag 16 auch durch einen / oder ein schließendes Tag terminiert werden. Tags können ineinander verschachtelt werden, wenn deren Reihenfolge dabei konsistent bleibt. Eine restriktivere Einschränkung stellt die Gültigkeit eines XML-Dokuments dar. Ein XML-Dokument ist genau dann gültig, wenn es eine DTD 17 referenziert und der darin beschriebenen Grammatik entspricht. Der folgende XML Codeabschnitt zeigt ein Beispiel der Datei jboss-web.xml eines speziellen Deployment-Deskriptors des JBoss Servers (vgl. Kapitel 3). Dieses Dokument ist wohlgeformt, da öffnende Tags in korrekter Weise geschlossen werden. In der ersten Zeile wird für das Dokument der Zeichensatz angegeben, hier UTF Danach wurde, mit der Angabe der DTD, der Document-Type festgelegt, der unter der angegebenen URL 19 zu finden ist. Listing 2.1: jboss-web.xml 1 <?xml version="1.0" encoding="utf-8"?> 2 <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Application 2.3V2// EN" " 3 4 <jboss-web> 5 <security-domain>java:/jaas/myjbosssec</security-domain> 6 </jboss-web> Bei J2EE-Anwendungen werden seit EJB 2.0 XML-Dateien zur Konfiguration eingesetzt. In früheren EJB-Versionen wurden zu diesem Zweck noch serialisierte Java-Objekte benutzt. Durch die einfachere Verarbeitung von XML lassen sich so leichter Anpassungen an den EJBs vornehmen. Auch der JBoss-Server wird mit XML-Dateien konfiguriert. Alle 15 extensible Stylesheet Language Transformation, Eine Sprache zur Formatierung von XML Dokumenten 16 engl. Markierung 17 Document Type Definition 18 Unicode Transformation Format, 8-bit kodierte Form 19 Uniform Resource Locator

18 10 2. Theoretische Grundlagen Einstellungen, die die angebotenen Dienste betreffen, werden in einer der Konfigurationsdateien vorgeschrieben. Auf diese Dateien wird in Kapitel 4.5 genauer eingegangen SQL, die Standard-Datenbank-Anfragesprache Die Structured Query Language (SQL) ist die Standard-Anfragesprache für relationale Datenbanksysteme. Sie vereinigt in sich die verschiedenen Sprachen, die bei einem RDBMS 20 benötigt werden [HS00]: Data Definition Language (DDL) Data Manipulation Language (DML) View Definition Language (VDL) Storage Definition Language (SDL) Die Grundlagen der Sprache wurden bereits 1974 und 1976 von IBM durch die Entwicklung der Sprachen SEQUEL 21 und SEQUEL2 gelegt. SQL entstand in den folgenden Jahren durch Datenbankhersteller wie Oracle. Im Jahr 1986 wurde SQL dann zum ANSI 22 -Standard. Durch die International Standard Organisation (ISO) wurde 1989 SQL-89 und 1992 SQL-92 standardisiert. Mit SQL-99 wurde SQL dann zu einer objektrelationalen Datenbanksprache. Relationale Datenbanksysteme beherrschen zur Zeit den Markt, obwohl objektrelationale und objektorientierte Datenbanksysteme eine Zeit lang immer mehr Marktanteile beanspruchten. Der Trend zur objektorientierten Datenbank wurde durch den Einsatz der sogenannten Objektrelationalen Mapper gebremst (vgl. Kapitel 3.3.3). Durch die lange Tradition des Relationen-Modells ist die damit verbundene SQL jedoch nicht aus der Datenbankwelt wegzudenken. Die Verwendung von SQL in objektorientierten Systemen führt jedoch zum Impedance Mismatch, dem Bruch zwischen der Programmier- und Datenzugriffssprache. In den heutigen Zugriffsschichten für Datenbanksysteme aus objektorientierten Welten werden meist SQL-Statements generiert, um den Impedance Mismatch vor dem Nutzer zu verbergen. Um den Übergang zu objektorientierten Datenbanken zu erleichtern bietet z.b. die 20 Relational Database Management System 21 Structured English Query Language 22 American National Standard Institute

19 2. Theoretische Grundlagen 11 postrelationale Datenbank Caché die Möglichkeit, auch mit SQL Daten zu manipulieren, zu definieren oder Anfragen zu stellen. Im J2EE-Umfeld wird häufig eine relationale Datenbank für die Persistenz der Daten eingesetzt. Auch hier werden SQL-Statements erzeugt. Bei der Container Managed Persistence (CMP) wird dem Programmierer mit EJB-QL (vgl. Kapitel 3.3.2) eine auf der SQL-Syntax basierende Anfragesprache zur Verfügung gestellt, mit der Objekte aus Datensätzen des RDBMS erzeugt werden können. Die Bedeutung von SQL lässt sich an diesen Beispielen gut erkennen. Selbst völlig neue Ansätze zur Speicherung von Daten greifen auf SQL zu oder bieten eine Anfragesprache, die sich an SQL orientiert Verteilte Anwendungen In einem heterogenen Umfeld mit ständig wachsendem Bedarf an Rechenleistung, Speichergrösse und immer kürzeren Antwortzeiten wird das Konzept des Grossrechners zunehmend durch verteilte Systeme ersetzt. Diese Systeme haben einige entscheidende Vorteile [TS03]: Benutzertransparenz: Ein verteiltes System fühlt sich für den Benutzer an, wie ein einzelner leistungsfähiger Computer. Kosten: Rechenleistung im PC-Bereich wird immer günstiger. Durch den Zusammenschluss vieler günstiger Systeme ist die Rechenleistung eines Grossrechners zu einem wesentlich geringeren Preis zu verwirklichen. Erweiterbarkeit: Bei Leistungsengpässen und schwindenden Reserven von Speicherplatz oder anderen Betriebsmitteln können neue Systeme an das verteilte System angeschlossen werden, um die Leistung weiter zu steigern. Spezialisierung: Komponenten einer Software können so verteilt werden, das sie auf dem Rechner im verteilten System ablaufen, der ihnen die bestmögliche Leistung gewährleistet. Ausfallsicherheit: Bei einem verteilten System soll der Ausfall einer Komponente nicht das gesamte System beeinträchtigen.

20 12 2. Theoretische Grundlagen Die im folgenden aufgeführten Nachteile hingegen lassen sich durch sorgfältige Planung relativieren. Verteilte Systeme sind abhängig vom Verbindungsnetzwerk. Wenn die Netzwerkkomponenten unzuverlässig arbeiten, wird das Gesamtsystem beeinträchtigt. Die fortschreitende Entwicklung in der Netzwerktechnik verringert jedoch dieses Problem immer weiter. Eine weitere Aufgabe ist es, ein solches System gegen Angriffe von außen zu schützen. Es werden mehr Punkte zur Kompromittierung angeboten; die Chance, ein Sicherheitsloch zu finden, steigt. Bei verteilten Systemen, die in einem Intranet genutzt werden, um eine hohe Rechenleistung zu erbringen ist dieses Problem geringer, als beim verteilten Rechnen z. B. im Internet. Hier lassen sich aber durch virtuelle private Netzwerke (VPN) die Risiken von ungewolltem Mitlesen und Verändern des Datenverkehrs minimieren. Der Einsatz von Firewalls und Intrusion Detection Systemen (IDS) schützt vor Einbrüchen in die Systeme und gehört mittlerweile zum Standard in Firmen- und oft auch in Heimnetzwerken. Ein weiteres Problem liegt in der Komplexität der Verwaltung eines solchen Systems. Die Software, die die Vorteile von verteilten Systemen nutzen soll, ist wesentlich komplizierter zu entwickeln, als die für monolithische Systeme. Es gibt jedoch Rahmenwerke (Frameworks), die den Entwickler hierbei unterstützen. Im Bereich der Application-Server bieten die Serverhersteller oftmals schon die Möglichkeit zur Verteilung der Last auf mehrere Application-Server. Das so genannte Clustering bietet hierbei die Vorteile von verteilten Systemen ohne grösseren Aufwand. Software die für J2EE entwickelt wird, ist ohne große Änderungen auch in einem Cluster einsetzbar. Auf das Verteilen von Komponenten und Last wird im folgenden Abschnitt eingegangen. In Kapitel wird am Beispiel des JBoss die Konfiguration eines Clusters erläutert Komponenten Jeder Teil einer Software wurde schon einmal implementiert, aber noch nicht von jedem. [Quelle: unbekannt] Die objektorientierte Software-Entwicklung ist erprobt und hat ihre Stärken und Schwächen offenbart. Es wurde nach Lösungsansätzen gesucht, um die Wiederverwendbarkeit von Programmteilen zu erhöhen. Dabei hat sich auch gezeigt, dass Klassen und Objekte zu feingranular sind, um den Softwareentwicklungszyklus weiter zu beschleunigen. Oftmals werden in unterschiedlichen Softwaresystemen ähnliche Programmteile benötigt, wie z. B.

21 2. Theoretische Grundlagen 13 ein Datenbankzugang oder eine Benutzerverwaltung. Solch ein Programmteil besteht in der Regel jedoch aus mehreren Klassen. In Java werden solche Teilsysteme zu Paketen, den so genannten Packages zusammengefasst. Um diese Programmteile einfach wiederverwenden zu können, ist es notwendig, aus solchen Paketen Komponenten zu erzeugen. Der Begriff Komponente kann wie folgt definiert werden: Ein Halbfabrikat bzw. eine Komponente (componentware) ist also ein abgeschlossener, binärer Software-Baustein, der eine anwendungsorientierte, semantisch zusammengehörende Funktionalität besitzt, die nach außen über Schnittstellen zur Verfügung gestellt wird. [Bal00] Eine Komponente kann also aus einer Vielzahl von Klassen bestehen, deren Funktionalität über eine Schnittstelle bereitgestellt wird. Dadurch ist es auch möglich, dass viele Komponenten miteinander interagieren können. Da Komponenten mit dem Ziel der Wiederverwendung entwickelt werden, ist es notwendig, dass alle Funktionen und Schnittstellen der Komponente ausreichend beschrieben und getestet werden. Eine Komponente sollte klein genug sein, um sie leicht warten und herstellen und in einer Vielzahl von Systemen integrieren zu können. Sie soll aber einen Funktionsumfang bieten, der gross genug ist, um einen Vorteil durch ihre Integration zu erhalten. (vgl. [SDD02] und [DP02]). Der Einsatz einer fertigen Komponente orientiert sich am so genannten Blackbox Prinzip. Das bedeutet, dass für den Einsatz und die Integration der Komponente nicht der Quelltext bzw. die Implementierungsdetails offen liegen müssen, sondern dass anhand der Schnittstellen und Funktionsbeschreibung eine Integration erfolgt. Durch das Komponenten-Paradigma lassen sich grössere Softwaresysteme effizienter zusammenstellen und entwickeln. Bei Software-Entwicklern, welche an verschiedenen Standorten arbeiten, ist eine solche Architektur notwendig. So kann jeder einen Teil der Software entwickeln, welcher der Schnittstellen- und Funktionsbeschreibung entspricht. Komponenten steigern die Qualität einer Software. Durch gut getestete Komponenten treten weniger Fehler auf und die Komplexität bei der Fehlersuche wird verringert. Wenn eine Komponente fehlerhaft ist, kann diese überprüft und berichtigt werden. Auch ist es wesentlich einfacher, neue Technologien in Komponenten-Software zu integrieren. Wenn

22 14 2. Theoretische Grundlagen eine Komponente ein Refactoring 23 durchläuft, kann festgestellt werden, ob sie die neuesten Entwurfsmuster verwendet. Ist dies nicht der Fall, kann sie aufgrund ihrer geringeren Größe leichter auf den aktuellsten Stand der Softwaretechnik gebracht werden. Komponenten in Geschäftsanwendungen In verteilten Softwaresystemen gibt es eine Reihe von immer wieder auftretenden Anforderungen, die durch den Einsatz von Komponentenmodellen erfüllt werden können. In heutigen Unternehmensanwendungen steht meist eine Datenbank zur Verfügung, die Geschäftsdaten (Entitäten) enthält. Programme oder Programmteile arbeiten auf der Basis dieser Daten. Oftmals sind sowohl die Daten, als auch die Geschäftsprozesse über ein Netzwerk miteinander verbunden. Die Änderungen an den Geschäftsdaten werden mit Hilfe von Transaktionen (vgl. 3.6) gesichert und die Daten der Anwendung werden dem Nutzer ansprechend visualisiert. Man spricht hierbei von mehrschichtigen Systemen. Moderne Anwendungen werden immer vielschichtiger. Die ehemaligen 2-Schichtsysteme (Client-Server-Systeme) werden durch 3- bis n-schichtsysteme ersetzt. Server Client Browser/GUI Logik zur Darstellung der Daten Kommunikation z.b. RMI oder HTTP Client Kommunikation Geschäftslogik Datenzugriff Kommunikation über vereinbartes Protokoll Datenbank Abb. 2.2: Beispiel einer Mehrschicht-Architektur Dabei gibt es meistens eine Präsentations-, eine so genannte Geschäftslogik- und eine Datenhaltungs-Schicht. Die drei Hauptschichten sind oft auch physikalisch voneinander abgegrenzt. Das Schichtenmodell durchzieht jedoch auch die Anwendungen innerhalb der 23 Das Untersuchen, Verbessern und ggf. Neuimplementieren von Quelltexten, ohne dessenderen Semantik zu verändern.

23 2. Theoretische Grundlagen 15 physikalischen Schichten. Bei speziellen Anforderungen kann die Anzahl der Schichten um weitere ergänzt werden. Intern sind sie oft stark gekoppelt; zu ihren korrespondierenden Schichten besteht eine schwächere Bindung. So ist der Austausch einer Schicht durch eine andere mit entsprechenden Schnittstellen möglich. Das Komponenten-Paradigma entfaltet hier sein Potential. So ist es durch eine Analyse möglich, Komponenten in bestehenden oder neu zu entwickelnden Anwendungen zu finden. Komponenten können sowohl die einzelnen Schichten der Anwendung darstellen als auch bestimmte funktionale Aspekte, wie z. B. Logging, Netzwerkverbindungen oder Sicherheit. Bei diesen funktionalen Anforderungen ist eine weitere Abstraktion, durch die aspektorientierte Programmierung möglich, die in Kapitel vorgestellt wird. Die heutigen Geschäftsanwendungen verwenden zumeist einen Application-Server, der die technischen Anforderungen eines Softwaresystems umsetzt, während die funktionalen Teile des Systems von Entwicklern individuell erstellt werden. Man spricht dabei von einer Trennung der Zuständigkeiten ( separation of concerns ). Die Application-Server bieten eine Ablaufumgebung (auch Container genannt) für die funktionalen Bestandteile des Softwaresystems. Sie bieten Dienste an, die in allen Geschäftsanwendungen gleichermaßen auftreten. So z. B. Transaktionen, Sicherheitsrichtlinien, Zugriff auf Datenquellen (EIS 24 ) und Laufzeitverwaltung der installierten Anwendungen Komponentenmodelle in Java Da Komponenten und Objekte viele Gemeinsamkeiten haben, definiert Java mehrere Komponentenmodelle. Der erste Ansatz zu Komponenten ist bei den Applets zu finden. Diese kann man als GUI 25 -Komponenten in Webseiten betrachten. Applets sind keine Programme und sind nicht eigenständig ausführbar. Ein Applet wird immer in einer Ablaufumgebung, also einem Container, ausgeführt. Dieser Container kann sowohl ein Webbrowser als auch ein Applet-Viewer sein. Der Container überwacht unter anderem die Rechte des Applets (Sandbox-Prinzip) und dessen Lebenszyklus. Die Darstellung eines Applets ist immer eine vom Applet implementierte GUI. Applets werden von java.applet.applet abgeleitet. Komponenten sind wiederverwendbare Softwarebausteine (vgl ), die über Schnittstel- 24 Enterprise Information System 25 Graphical User Interface

24 16 2. Theoretische Grundlagen len Funktionen bereitstellen. Applets können aus einer Reihe von Klassen bestehen, die selbst Funktionseinheiten innerhalb des Applet-Programms darstellen. Applets können also selbst ebenfalls aus Komponenten bestehen. Dabei kann man die visuelle Komponente des Applets von seinen funktionalen Komponenten trennen. Applets können also aus Komponenten zusammengesetzt sein und Teil anderer komponentenbasierter Systeme werden. Die Portabilität ist durch die Sprache Java gewährleistet. Es ist leicht, Komponenten eines Applets in anderen Programmen wiederzuverwenden. Ein ganzes Applet ist jedoch nur komplett als Komponente einer anderen Webseite wiederverwendbar. Ebenso ist die Anzahl der Schnittstellen die ein Applet hat sehr begrenzt. Es kann mit JavaScript 26 und dem Benutzer interagieren sowie auf Programm-Ereignisse und Lebenszyklusmethoden reagieren. JavaBeans Das erste echte Komponentenmodell, das auch als solches entwickelt wurde, ist die JavaBeans-Spezifikation. Sun hat sich damit zum Ziel gesetzt, das Erstellen von Softwarebausteinen (Komponenten) für Firmen zu ermöglichen, die diese Komponenten vertreiben können, (vgl. [SM97]). Bei der Entwicklung des GUI-Frameworks Swing und AWT 27 wurden von Sun selbst Java- Beans eingesetzt. Eine kurze Definition von Sun für JavaBeans lautet: A Java Bean is a reusable software component that can be manipulated visually in a builder tool. [SM97] Dies zeigt nur ein kleines Spektrum der Möglichkeiten, die man mit JavaBeans hat. Um diese Definition zu erfüllen ist es notwendig, dass andere Programme JavaBeans untersuchen können. Zu diesem Zweck dient die Java Reflection-API 28. Mit den Reflection- Methoden ist es möglich, Objekte und Klassen zur Laufzeit zu untersuchen. Da alle Objekte von Object abgeleitet sind, steht ihnen die Methode getclass() zur Verfügung. Das Class-Objekt liefert Informationen zum Typ, den Konstruktoren, Methoden und Feldern ei- 26 in Webseiten eingebettete, von Netscape entwickelte Skript-Sprache um dynamische Inhalte zu erzeugen oder zu modifizieren 27 Abstract Windowing Toolkit, API zur Erstellung grafischer Benutzeroberflächen 28 java.lang.reflect

25 2. Theoretische Grundlagen 17 ner Klasse. Die Attribute einer JavaBean unterliegen wohl definierten Namens-Konventionen. So müssen die Attribute die Sichtbarkeit private definieren. Damit sind sie nicht direkt von einer anderen Klasse zugänglich. Um die Attribute einer JavaBean dennoch ändern zu können, bekommen alle Attribute, die änderbar sein sollen, ein get/set-methoden-paar, das als public definiert ist. Auf diese öffentlich zugänglichen Methoden können andere Klassen und Programme über die Reflection-API zugreifen. Dieser Vorgang wird Introspection genannt. Die grafischen Programme zum Editieren einer JavaBean benutzen genau diese Möglichkeit. Attribute die diese Anforderungen erfüllen, werden bei den JavaBeans properties genannt. Um sicherzustellen, dass alle JavaBean-Instanzen bei ihrer Erzeugung die gleichen Eigenschaften haben, besitzen sie nur einen parameterlosen Konstruktor 29. Um die Beans anzupassen werden die Properties bearbeitet. Dieser Vorgang wird als Customizing bezeichnet. JavaBeans erzeugen z. B. für jede Property ein PropertyChangeEvent bei Änderungen dieser Attribute. JavaBeans können auch eigene Events definieren, bei GUI-Komponenten sind das die AWT- oder Swing-Events. Wie in Kapitel bereits beschrieben, müssen Komponenten Interfaces besitzen, die nach außen deren Fähigkeiten anzeigen. Bei den JavaBeans sind das BeanInfo und PropertyEditor. Diese Interfaces werden explizit von grafischen Editoren genutzt (z. B. Bean Development Kit von Sun), um die Beans zu bearbeiten. Die Spezifikation der JavaBeans verlangt auch, dass sie dauerhaft abgespeichert werden können. Dazu wird wie bei anderen Java-Klassen das Interface Serializable implementiert, wodurch die JavaBean in binärer Form dauerhaft speicherbar ist. Es besteht ebenso die Möglichkeit Beans über XML-Encoder/Decoder persistent zu machen. Wie bereits erwähnt, werden JavaBeans als GUI-Komponenten eingesetzt, z. B. als JButton oder auch als Menu- Item. Doch außer diesen sichtbaren Komponenten werden auch unsichtbare JavaBeans benutzt. Letztere werden z. B. in Webanwendungen verwendet um die Programmlogik zu halten oder das Datenmodell einer Seite zu kapseln. In der Beschreibung der in dieser Diplomarbeit erstellten Anwendung im Kapitel 5.5 wird genauer auf die Verwendung von JavaBeans eingegangen. 29 Durch den Aufruf des Konstruktors wird bei eine Instanz einer Klasse erzeugt

26 18 2. Theoretische Grundlagen Enterprise JavaBeans An dieser Stelle wird nur kurz auf die Enterprise JavaBeans-Technologie eingegangen. Ein umfassender Überblick wird in Kapitel 3 gegeben. Die Enterprise JavaBeans sind eine serverseitige Komponententechnologie der J2EE. Um EJB nutzen zu können, ist ein Application-Server notwendig, der die Ablaufumgebung bereitstellt und den Lebenszyklus der EJB überwacht. Dieser stellt eine Vielzahl von Diensten bereit, die bei Geschäftsanwendungen notwendig sind. Diese Dienste können implizit genutzt werden und müssen nicht vom Programmierer der Komponente entwickelt werden. Zu diesen Diensten zählen z. B. die Persistenz von Entity Beans. Dieser Dienst ermöglicht die Speicherung von Geschäfts-Entitäten in einem Enterprise Information System, z. B. einer relationalen Datenbank. Dies entlastet den Entwickler und sorgt für fehlertolerantere Anwendungen, da weniger funktionaler Quelltext benötigt wird. Die Enterprise JavaBeans sind konsequent auf verteilte Systeme ausgerichtet. Sie ermöglichen über Namensdienste das Auffinden von Komponenten und Datenquellen. Dadurch ist der Einsatz von EJBs in Clustern möglich. Ein Cluster bietet verschiedene Vorteile, die in Kapitel aufgezeigt werden Alternative Komponentenmodelle Die alternativen Komponentenmodelle die hier beschrieben werden sollen, sind als Konkurrenz zu den in dieser Arbeit verwendeten Java-Komponentenmodellen zu sehen. Es soll nur ein kurzer Überblick gegeben werden, um die Java-Komponentenmodelle besser einordnen zu können und vergleichbar zu machen. Der anschließende Vergleich der Komponentenmodelle ergänzt diesen Abschnitt. COM, COM+ und DCOM Das von Microsoft entwickelte Component Object Model (COM) ist bereits im Jahr 1993 entstanden. Als eines der ersten Modelle für komponentenbasierte Software und durch den Marketingdruck von Microsoft wurde es zu einer führenden Komponententechnologie. COM basiert auf Object Linking and Embedding (OLE) von Microsoft, das eine Komponentenumgebung bietet, die jedoch noch nicht auf verteilte Komponenten eingeht. In den

27 2. Theoretische Grundlagen 19 folgenden Jahren und Betriebssystem-Versionen von Windows wurde COM vollständig integriert und bietet die Dienste, die Applikationsentwickler in Windows benötigen. Bereits damals wurden Konzepte wie Objektorientierung und Unabhängigkeit von Programmiersprachen umgesetzt. COM definiert einen Binärstandard für die erzeugten DLL-Dateien, die mit Programmiersprachen wie C++, Delphi und sogar Java erzeugt und benutzt werden können (vgl. [Sch01]). Jedoch gab es mit COM und dem später folgenden COM+, das seit Windows 2000 eine Reihe weiterer Dienste bereitstellt, auch zahlreiche Probleme. COM fehlte die Möglichkeit Komponenten über ein Netzwerk zu verteilen. Diese Aufgabe übernahm das Distributed Component Object Model (DCOM), welches die entsprechenden Dienste zur Verfügung stellte. Eine fehlende Versionskontrolle und das systemweite Registrieren der Komponenten führten zum Begriff der DLL-Hölle. Damit meint man, dass durch die Verwendung von DLLs über deren Namen geschieht, wodurch es möglich ist, dass mehrere Hersteller von Komponenten eine DLL mit gleichem Namen zur Verfügung stellten. Ebenso war es für Applikationen schwer herauszufinden, ob die Komponente die geforderte ist und in der richtigen Version vorliegt. Einer der größten Nachteile, der sich nach der Einführung und dem Erfolg von Java noch weiter verstärkte, war die Bindung an die Windows-Plattform. Das Portieren von Windows- Anwendungen, die als COM implementiert wurden, war gar nicht oder nur mit enormen Aufwand auf andere Systeme möglich..net Microsoft nahm sich der Problematik an und schuf.net 30. Es wurde, basierend auf der COM und COM+ Architektur, eine Neuimplementierung vorgenommen und deren beste Eigenschaften übernommen. Auch die Konzepte, die Java so erfolgreich machen, wurden herangezogen. Als Konkurrenz zu Java und J2EE hat Microsoft mit.net ein Framework entwickelt, das nicht wie Java/J2EE plattformunabhängig, sondern programmiersprachenunabhängig ist. Dadurch kann die Windowsplattform weiteren Ansprüchen gerecht werden. Microsoft entwickelte eine Common Language Runtime (CLR) und die Microsoft Intermediate Language (MSIL). Die CLR ist die Ablaufumgebung für alle.net-fähigen Spra- 30 gesprochen: DOT NET

28 20 2. Theoretische Grundlagen chen und verwaltet deren Speicherzugriffe, Threads, Laufzeitausnahmen, Sicherheit bzw. Rechte und das Typsystem. Die CLR vereinheitlicht für alle Sprachen die Datentypen. Mit der Entwicklung der Sprache C# 31 erreichte Microsoft eine große Kompatibilität zu C- Code, der teilweise direkt in C# verwendet werden kann. Ebenfalls gibt es die Möglichkeit der Wiederverwendung von COM und COM+ Komponenten. Bei C++ ist es sogar möglich, unmanaged code im.net Framework ablaufen zu lassen, also Code, der weiterhin selbst das Speichermanagement und Zeigerarithmetik verwenden darf. Doch Microsoft wollte es auch Umsteigern anderer Sprachen leicht machen, ihre Programme für die.net Plattform zu entwickeln. Dazu wurden Sprachen wie J#, VisualBasic.NET und sogar COBOL.NET und Haskell.NET entwickelt. Auch die Kombination verschiedener Sprachen innerhalb eines Assembly ist möglich. Ein Assembly ist eine Komponente in dem Sinn, dass es Schnittstellen und Metainformationen besitzt und ist eher mit JavaBeans als mit Enterprise JavaBeans zu vergleichen. Sie können zwar auch serverseitig eingesetzt werden (ASP.NET Assembly), sind jedoch kein serverseitiges Komponentenmodell. Die MSIL ist der kleinste gemeinsame Nenner aller.net-sprachen. Da.NET programmiersprachenunabhängig ist (die Sprachen müssen der Common Language Specification CLS entsprechen), müssen alle Sprachen erst in MSIL übersetzt werden. Danach werden sie vom.net Just in Time Compiler in Maschinencode oder Assembler übersetzt. Das heißt, dass die Programme direkt auf dem Prozessor ausgeführt und nicht interpretiert werden. Microsoft hat.net von Anfang an auf WebServices und XML ausgerichtet. So ist XML ein integraler Bestandteil des.net Frameworks und wird in jeder Sprache unterstützt. WebServices sind für Microsoft ein wichtiger Bestandteil in.net und dafür gedacht, mit unterschiedlichen Komponenten, verteilt im Netz, von jedem Endgerät aus, zu kommunizieren. Als Transportprotokoll wird der Standard SOAP genutzt. Damit hat Microsoft die Möglichkeit geschaffen DCOM abzulösen. DCOM kommuniziert nicht via HTTP (Port 80) und ist daher unflexibel in komplexeren Netzwerktopologien (scheitert z. B. an den meisten Firewalls). Um Marktanteile, die Java in den letzten Jahren im Bereich der Enterprise Systeme gewonnen hat, zurückzugewinnen, wurde ASP.NET entwickelt. ASP.NET ist eine Weiterentwicklung der Active Server Pages, die vom Internet Information Server IIS bekannt sind. Hier werden die Assemblies genau wie andere Programme in MSIL übersetzt und in eine 31 C Sharp

29 2. Theoretische Grundlagen 21 DLL überführt, die mit Hilfe der CLR ausgeführt werden kann. Die ASP Assemblies erzeugen als Ausgabe HTML, können aber durch ihre Zugehörigkeit zur.net Familie auch Komponenten anderer.net-sprachen direkt benutzen (nach [Poh03]). Microsoft liefert für die Entwicklung mit.net die Entwicklungsumgebung Visual Studio.NET. Prinzipiell ist das.net Framework plattformunabhängig angelegt, jedoch liefert Microsoft nur Implementierungen für die eigene Windows Produktfamilie. Mit dem MONO Projekt 32 gibt es lauffähige Ansätze für die Portierung auf andere Plattformen wie Linux und Mac-OS. Jedoch sind diese bei weitem noch nicht so leistungsfähig wie.net für Windows. Das liegt unter anderem daran, dass.net keine klare Trennung zwischen dem.net Framework und dem Betriebssystem geschaffen hat. Einige Dienste wie Transaktionsüberwachung werden vom Betriebssystem zur Verfügung gestellt. Auch ist.net bisher nur in Teilen bei der ISO und ECMA 33 standardisiert (nach [Gra03]) Vergleich der Komponentenmodelle Der Vergleich der Komponentenmodelle von Java/J2EE und Microsoft.NET erfolgt auf der Ebene der Geschäftsanwendungen. Bei unternehmensweiten Anwendungen hat J2EE derzeit einen großen Vorsprung vor Microsoft.NET. Dieser Vorsprung ist zum einen dadurch zu erklären, dass J2EE früher entwickelt wurde, zum anderen schafft es eine andere technologische Basis. Die Plattformunabhängigkeit bietet vielen Unternehmen größeren Entscheidungsspielraum bei der Auswahl von Betriebssystemen und Hardwareplattformen. Dies kann die.net Plattform nicht bieten. Microsoft.NET ist zugeschnitten auf die Microsoft Produktpalette, deren Betriebssysteme und die dazu passende Hardware. Ein verteiltes Komponentenmodell wurde mit.net nicht neu eingeführt, sondern es wurde auf das COM+/DCOM Modell zurückgegriffen. Microsoft bedient eine andere Zielgruppe mit ihrer Plattform: Entwickler die seit jeher Microsoft-Produkte einsetzen und die eine Bindung an den Konzern nicht scheuen. Meist haben diese Firmen eine Vielzahl von Entwicklungen in COM und Webanwendungen mit ASP. Diese sind leicht in das neue.net zu integrieren. Angesprochen werden sollen außerdem Programmierer der unterschiedlichsten Sprachen, die in.net eine gemeinsame European Computer Manufacturers Association