Als PDF ausgeben
Werbung
Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Name der Autoren: Hochschule und Studienort: Titel der Arbeit: Betreuer: Mathias Schulze, Henrik Motzkus FOM Hamburg "Möglichkeiten der Server-neutralen Implementierung von Anwendungen" Prof. Dr. Uwe Kern I Inhaltsverzeichnis Inhaltsverzeichnis • 1 Einleitung ♦ 1.1 Motivation ♦ 1.2 Ziel und Vorgehensweise • 2 Grundlagen ♦ 2.1 Komponentenmodelle ◊ 2.1.1 CORBA ◊ 2.1.2 EJB ◊ 2.1.3 DCOM ♦ 2.2 Relevante Techniken ◊ 2.2.1 Webservices ◊ 2.2.2 SOAP ◊ 2.2.3 XML • 3 Plattformen ♦ 3.1 .NET Framework ◊ 3.1.1 Konzept ◊ 3.1.2 Common Language Runtime ◊ 3.1.3 Intermediate Language ◊ 3.1.4 Programmierung ⋅ 3.1.4.1 API ⋅ 3.1.4.2 ASP.NET ⋅ 3.1.4.3 ADO.NET ◊ 3.1.5 Verfügbare Laufzeitumgebungen ♦ 3.2 J2EE/Java EE ◊ 3.2.1 Konzept ⋅ 3.2.1.1 Client Tier ⋅ 3.2.1.2 Web Tier ⋅ 3.2.1.3 Business Tier ⋅ 3.2.1.4 Enterprise-Information-System Tier ⋅ 3.2.1.5 Container ◊ 3.2.2 API ⋅ 3.2.2.1 Assembling Inhaltsverzeichnis 1 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen ⋅ 3.2.2.2 Übersicht ◊ 3.2.3 Verfügbare Server ◊ 3.2.4 Java EE Compatibility & Java Verification ⋅ 3.2.4.1 Application Verification Kit for the Enterprise ⋅ 3.2.4.2 Java Powered for the Enterprise Programm • 4 Schlussbetrachtung ♦ 4.1 Ergebnisse ◊ 4.1.1 Java ◊ 4.1.2 .NET ♦ 4.2 Fazit ♦ 4.3 Ausblick • 5 Anhang II Tabellenverzeichnis Tabelle Nr. 1 2 3 4 Bezeichnung J2EE Zertifizierte Anbieter Java EE 5 Compatible Implementations Java EE Apis Java EE Versionen III Abbildungsverzeichnis Abb.-Nr. 1 2 3 4 5 6 Abbildung .NET - Schritte vom Quelltext zum Maschinencode Distributed Multitiered Applications Application Packaging Java EE Apis Application Server Platforms Based On Java EE Application Architektur IV Abkürzungsverzeichnis Inhaltsverzeichnis 2 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Abkürzung ADO ASP AWT CLI CLR COM CORBA CTS DCOM EAR EIS EJB ERP ESB FLC HTML IDL IIOP OMG Java AVK JavaEE JavaEE JNDI JSP JSR JVM J2EE RAR SOA SOAP UI XML Bedeutung ActiveX Data Objects Active Server Pages Abstract Window Toolkit Common Language Infrastructure Common Language Runtime Component Object Model Common Object Request Broker Architecture Common Type System Distributed Component Object Model Enterprise Archive Enterprise Information System Enterprise Java Bean Enterprise Resouce Planning Enterprise Service Bus Framework Class Library Hyper Text Markup Language Interface Definition Language Internet Inter ORB Protocol Object Management Group Java Application Verfication Kit Java Platform Enterprise Edition 5 Java Platform Enterprise Edition 5 Java Naming Diretory Interface Java Server Page Java Specification Request Java Virtual Machine Java 2 Platform Enterprise Edition Resource Adapter File Service Oriented Architecture Simple Object Access Protocol User Interface Extensible Markup Language 1 Einleitung 1 Einleitung 3 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen 1.1 Motivation Heutzutage nutzt jedes Unternehmen Software-Anwendungen, um seine Geschäftsprozesse zu unterstützen. Ohne Software ist Unternehmertun heutzutage nicht mehr denkbar. Unternehmen werden dadurch mit zunehmendem Maß abhängig von einer zuverlässigen und kostengünstigen IT-Infrastruktur. Als in den Neunzigern das sog. E-Business Zeitalter anbrach, haben sich die Unternehmen rasant verändert. Diese Entwicklung ist so weit vorangeschritten, dass ohne den Einsatz von IT der Zutritt zu bestimmten Märkten nicht möglich ist. Software-Anwendungen nehmen eine herausragende Rolle in den Unternehmen ein. Die Qualität dieser Software-Anwendungen bestimmt häufig in großem Maße die Qualität der Geschäftsprozesse und der Produkte des Unternehmens. Die Einführung von Software ist ein komplexer Prozess. Abhängig von der Unternehmensgröße, dem Know-how der Mitarbeiter und dem finanziellen Potential kann sich ein Unternehmen dazu entscheiden, sog. Standardsoftware zu kaufen oder selbst Individualsoftware zu entwickeln. Es ist eine Make-or-Buy Entscheidung zu fällen. Der Einsatz von Standardsoftware ist meist kostengünstiger und spart Zeit. Die Entwicklung von Individualsoftware ist meistens teurer. Sie kann die Geschäftsprozesse eines Unternehmens aber meistens besser abbilden. Daher verfolgen Unternehmen meist eine gemischte Software-Beschaffungs-Strategie. Kaum ein Unternehmen wird Software für die Email-Kommunikation selbst entwickeln. Der Trend geht zur Spezialisierung auf die Kernkompetenzen, um dadurch einen Wettbewerbsvorteil zu erlangen. Software muss bei Verfolgung einer gemischten Software-Beschaffungs-Strategie nicht ausschließlich Out-of-the-Box einsetzbar sein. In immer komplexer werdenden Geschäftsprozessen kann es durchaus denkbar sein, dass Teile der zu entwickelnden Software von einem Softwareanbieter beschafft werden und aufbauend darauf ein Customizing stattfindet oder eigene Software entwickelt wird. Anwendungsserver sind ein klassisches Beispiel dafür. Ein Anwendungsserver leistet Standardaufgaben, die nicht immer wieder selbst entwickelt werden müssen. Authentifizierung oder Transaktionsverwaltung sind Aufgaben, die meist nach dem gleichen Muster ablaufen. Das Unternehmen kann in einem Anwendungsserver seine Individualsoftware ablaufen lassen und über Schnittstellen auf die Standardfunktionen zugreifen. Der Markt für Anwendungsserver ist in den letzten Jahren stark gewachsen, so dass ein Unternehmen heute eine große Auswahl hat. Es stehen Open Source-Lösungen und kommerzielle Lösungen bereit. Die Motivation für ein Unternehmen seine Software in einem Anwendungsserver ablaufen zu lassen ist groß. Die Entwicklung von Software wird erheblich kostengünstiger, die Abhängigkeit von einem Softwareanbieter wird im Gegenzug aber größer. Der gemischten Software-Beschaffungs-Strategie nach zu urteilen ist diese Situation ideal. Sie könnte aber besser sein, wenn die Abhängigkeit von einem Standardlieferanten nicht mehr bestünde. Die Motivation seine Software so zu gestalten, dass sie in verschiedenen Anwendungsservern läuft ist demnach gegeben. Davon müssen die Ziele der Softwareanbieter unterschieden werden. Es gibt Softwareanbieter, die ein Interesse daran haben ihre Software so zu gestalten, so dass sie auf möglichst vielen unterschiedlichen Anwendungsservern lauffähig ist. Der potentielle Kundenkreis erweitert sich dadurch signifikant. Andere Anbieter beschränken die Entwicklung auf ein Betriebssystem und haben wenig bis kein Interesse an der Verbreitung auf verschiedenen Systemen. 1.2 Ziel und Vorgehensweise Ziel dieser Arbeit ist es, jene Möglichkeiten und Wege aufzuzeigen, wie eine Server-neutrale Implementierung von Anwendungen erfolgen kann. 1.1 Motivation 4 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Als Anwendungsserver bezeichnet man i. w. S. jeden Server, auf dem Serveranwendungen ausgeführt werden und der über ein Netzwerk erreichbar ist. Um eine Serveranwendung zu betreiben, kann eine sog. Plattform (Laufzeitumgebung) für die Anwendung verwendet werden. Diese Arbeit teilt die Plattformen für Serveranwendungen in zwei Bereiche auf: 1. .NET von Microsoft, 2. Java EE von Sun. Für jede Plattform existieren mehrere Anwendungsserver. Eine Server-neutrale Implementierung würde daher implizieren, dass eine Anwendung auch plattformunabhängig sein muss. Da beide Plattformen aber in keiner Weise miteinander vergleichbar sind, werden die beiden Plattformen getrennt voneinander betrachtet. Implementieren bedeutet im allgemeinen Sprachgebrauch: Die Umsetzung einer Programmarchitektur oder eines Algorithmus in tatsächlichen Programmcode. Der Anwendungsentwickler erhält von einem Softwarearchitekt Vorgaben, die er dann in Programmcode umsetzt. Server-Neutralen Implementierung bedeutet, dass bei der Programmentwicklung Regeln eingehalten werden müssen. 2 Grundlagen Im Abschnitt Grundlagen werde alle Begriffe erklärt, die grundsätzlich betrachtet werden müssen, wenn von Server-neutraler Implementierung die Rede ist. Aufbauend auf den Grundlagen, muss ein Verständnis für Techniken und Architekturen geschaffen werden, um bewerten zu können, was möglich ist und was nicht. Um die Möglichkeiten einer Server-neutralen Implementierung von Anwendungen herauszuarbeiten, müssen zwei Plattformen betrachtet werden. Sun hat mit der Plattform Java EE (vorher J2EE) einen Standard für Software und Anwendungsserver geschaffen. Microsoft hat parallel die Plattform .NET entwickelt. Die nachfolgende Betrachtung der beiden Plattformen beginnt mit dem zentralen Thema der Entkoppelung von Techniken in der Anwendungsentwicklung. Zudem soll untersucht werden, ob der Einsatz dieser Technologien in der Lage ist Anwendungen Server-neutral zu implementieren. 2.1 Komponentenmodelle In der Softwareentwicklung werden Grundfunktionalitäten bzw. zusammen gehörende Funktionalitäten in Komponenten gekapselt. Dies hat zum einen den Vorteil, dass häufig benutzte Funktionen zentral zur Verfügung stehen und das mit Hilfe dieser Komponenten eine Entkoppelung einzelner Technologien erreicht werden kann. So kann z.B. ein in Java geschriebenes Programm über Corba mit einem C++ Programm Kommunizieren. 2.1.1 CORBA Die Common Object Request Broker Architecture (CORBA) ist eine serverseitige, plattformunabhängige Spezifikation von der Object Management Group (OMG), welche nicht auf einer spezifischen Programmiersprache basiert. Ziel ist die Kommunikation von verschiedenen Applikationen über Netzwerkprotokolle. Hierfür wird das Internet Inter ORB Protocol (IIOP), ebenfalls von der OMG spezifiziert, 2 Grundlagen 5 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen eingesetzt. Die Schnittstellen bei CORBA werden mit der Interface Definition Language (IDL) erstellt. Ziel ist es einzelne Programmmodule voneinander logisch zu trennen und interoperabel zu halten[1]. 2.1.2 EJB Eine Enterprise Java Bean (EJB) ist serverseitige Anwendungslogik, die von anderer Anwendungslogik abgekapselt ist. EJBs laufen in einem EJB Container, der wiederum in einem Application Server integriert ist. Der EJB Container hat Zugriff auf systemseitige Services wie die Transaktionsteuerung oder Sicherheitsfunktionen des Applicationservers. Ein Vorteil von EJBs ist, dass Anwendungslogik unabhängig von der übrigen Anwendung entwickelt werden kann. Die Entwicklung von komplexen Anwendungen wird somit vereinfacht, indem sich Arbeitspakete schnüren lassen. Ein Nachteil dieser Art der Anwendungsentwicklung ist, dass Mehraufwand beim Definieren von Schnittstellen zu anderen Komponenten entsteht. Sind die einzelnen Komponenten fertiggestellt, müssen sie zu einer Gesamtanwendung zusammengestellt (assembling) werden.[2] 2.1.3 DCOM Das Distributed Component Object Model (DCOM) ist eine von Microsoft entwickeltes System, welches die Basis für die Implementierung von verteilten Anwendungen auf dem .NET Framework ist. Es ist eine von Microsoft entwickelte Technologie, um das proprietäre Component Object Model (COM), ebenfalls von Microsoft entwickelt, über Netzwerk kommunizieren zu lassen. COM ist ebenfalls eine von Microsoft entwickelte Technologie, um Interprozesskommunikation zu ermöglichen. Die COM Objekte bieten Schnittstellen und können als DLLs oder Executables vorliegen. Da beide Technologien Eigenentwicklungen von Microsoft sind, werden diese auch nur von Microsoft eingesetzt. Es sind auch Adapter, z.B. JCOM, verfügbar, die eine Schnittstelle zwischen Java und DCOM herstellen.[3] 2.2 Relevante Techniken 2.2.1 Webservices Ein Webservice ist ein plattformunabhängiger Dienst, mit dem Zweck anderen Diensten Informationen und Funktionen zur Verfügung zu stellen. Die Kommunikation erfolgt über ein Netzwerk unter der Verwendung von Protokollen wie HTTP oder SOAP. Die Dienste arbeiten nach dem Frage Antwort Prinzip. Es lassen sich dadurch plattform- bzw. Orts unabhängige Dienste lose miteinander koppeln und wie ein Gesamtsystem erscheinen lassen. Ein Vorteil ist, dass man schnell auf sich verändernde Gegebenheiten reagieren kann. Fallen einzelne Dienste aus, so kann das Gesamtsystem m. E. weiter betrieben werden. Eine Nachteil ist ein Verwaltungsoverhead, der notwendig ist, um die Dienste miteinander kommunizieren zu lassen.[4] 2.2.2 SOAP Simple Object Access Protocol (SOAP) ist eine auf XML basierende Definition für den Austausch von Nachrichten. Die Nachrichten können frei definiert sein (Messages) oder einem vorgegebenem Aufbau folgen (Remote Procedure Calls). Die Übertragung der SOAP Nachricht kann mit jedem beliebigen Protokoll erfolgen, in der Praxis hat sich der Transport via HTTP durch gesetzt.[5] 2.1.1 CORBA 6 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen 2.2.3 XML Die Extensible Markup Language (XML) ist eine abstrakte Beschreibungssprache für Dokumente und im allgemeinen Daten. Die Daten werden mit Hilfe von Tags beschrieben und mit Werten versehen, z.B. <tag>Wert</tag>. Hierbei findet eine hierarchische Gliederung statt, d.h. es werden Tags ineinander verschachtelt und somit Strukturen aufgebaut. 3 Plattformen Es existieren zwei konkurrierende Technologien. Zum einen die .NET Plattform von Microsoft und zum anderen die J2EE basierten Server. 3.1 .NET Framework Das .Net Framework wurde von der Firma Microsoft definiert und Entwickelt. Mit diesem Framework können Client-Server, Web-, Server und mobile Anwendungen entwickelt werden. Aktuell werden 30 Programmiersprachen unterstützt[6]. Zum .NET Framework zählen im Sprachgebrauch die Laufzeitumgebung, die API, die Entwicklungsumgebung Visual Studio .NET und das .NET Software Development Kit (SDK). 3.1.1 Konzept Die elementare Grundlage des .Net Frameworks ist die Common Language Infrastructure (CLI). Die CLI wurde im Jahr 2000 von Microsoft, Intel und Hewlett Packard entwickelt und 2001 durch die ECMA, eine private internationale Normungsorganisation (für Informations-, Kommunikationssysteme und Unterhaltungselektronik), international als ECMA 335 Standard verabschiedet[7]. Somit können Hersteller bei vorhandenem Interesse eine Implementierung einer Runtime für eine beliebige Geräteklasse umsetzen. Die Umsetzung der CLI wird in der Common Language Runtime (CLR) realisiert. Die CLR kapselt den Just in Time (JIT) Compiler , die Code-, Fehler und Speicherverwaltung. So wird u.a. der Speicher mit Hilfe eines Garbage Collectors realisiert. Außerdem ist in der CLR ein einheitliches System von Datentypen implementiert, das Common Type System (CTS). Die erstellten Anwendungen werden nicht direkt in Maschinensprache umgesetzt, sondern in eine Zwischensprache, die Microsoft Intermediate Language (MSIL), umgesetzt. Hier besteht eine Analogie zu dem Konzept von Sun mit der Java Plattform. Somit ist die Voraussetzung gegeben, dass eine .NET Runtime für ein beliebiges Zielsystem implementiert werden kann. Aktuell existieren Implementierungen von Microsoft für Windows PCs (.NET Framework), für Windows Mobile und Windows CE (.NET Compact Framework) und für embedded Systeme (.NET Micro Framework). Daneben existiert eine alternative Implementierung, das Projekt Mono von der Firma Ximian initiiert und von Novell nach dem Aufkauf der Firma fortgeführt wird. Damit kann das .NET Framework auf Unix und Mac OS X Umgebungen ausgeführt werden. Das Software Development Kit (SDK) wird nur von Microsoft zur Verfügung gestellt, als Entwicklungsumgebung wird das Microsoft Visual Studio .NET angeboten. Es können aber auch alternative Entwicklungsumgebungen für die Sprachen ASP, VBA, WSH, C++, C# genutzt werden. Es werden auch auch VisualBasic.NET, Microfocus und Delphi8 unterstützt. Java ist kein Bestandteil von .NET[8] Das .NET Framework bietet eine Vielzahl von Klassen für die objektorientierte Entwicklungen. Es können auf Basis des .Net Frameworks verschiedene Arten von Anwendungen erstellt werden, z.B. Windowskonsolen-, Webanwendungen, Services oder Webservices. 3 Plattformen 7 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Das .NET Framework besteht aus zwei Hauptbestandteilen und als Plattform wird ein Windows Betriebssystem voraus gesetzt. Die beiden Hauptbestandteile sind zum einen die Common Language Runtime (CLR) und zum anderen die .NET Framework-Klassenbibliothek (Framework Class Library (FLC)). Die CLR ist eine virtuelle Maschine welche den Bytecode des .NET Programmes ausführt. Beim Kompilieren von .NET Quelltext wird Objektcode erzeugt. Dieser Objektcode wird dann lokal über die Runtime ausgeführt. Es werden von der CLR Basisfunktionen wie Speicherverwaltung (Garbage Collection), Threadverwaltung und Exceptionhandling bereitstellt. Von diesen Verwaltungsaufgaben ist der Programmierer somit entbunden. [9] Als Produkt der Entwicklung entstehen so genannte Assemblies. Dies ist die "kleinste verteilbare Einheit in .NET"[10]. In diesem Assemblies sind Informationen über den Quellcode im Manifest und weitere referenzierte Assemblies hinterlegt. Unter den Windows Betriebssystemen liegen die Assemblies als exe Dateien bzw. unter Unix als Binaries vor. Des Weiteren können auch nicht ausführbare Assemblies erzeugt werden. Diese liegen dann als statische bzw. dynamische DLLs (Dynamic Link Library) vor. Des Weiteren findet zur Laufzeit eine Unterscheidung zwischen Managed und Unmanaged Assemblies statt. Bei Managed Code wird während der Laufzeit über Zugriffsbeschränkungen entschieden. 3.1.2 Common Language Runtime Die Common Language Runtime ist die Laufzeitumgebung für .NET Anwendungen. Durch den offenen Standard kann die .NET Common Language Runtime theoretisch auf ein beliebiges Betriebssystem aufsetzen. Aktuell liegen Implementierung für verschiedene Windows Versionen (Server, Workstation, mobile Endgeräte), FreeBSD und Linux (Projekt Mono) vor. Auf Basis der CLR können verschiedene Programmiersprachen ausgeführt werden. Die CLR stellt, ähnlich wie die Java Virtuelle Maschine, einige Dienste zur Verfügung. Als wichtigste Merkmale sind die Sicherheit, das Sandbox Prinzip und die Garbage Collection zu erwähnen. Die CLR setzt die Common Language Infrastructure (CLI) um. Die CLR von .NET dient für mehrere Programmiersprachen als Laufzeitumgebung. Dies ist ein Alleinstellungsmerkmal gegenüber der Java Runtime. Grundlage dafür ist das Common Type System (CTS), welches die Datentypen von allen Programmiersprachen in die gemeinsamen Datentypen der CLR umsetzt. Die grundlegende Voraussetzung dafür ist aber, dass für die gewünschte Programmiersprach ein Kompiler vorliegt, welcher die Erzeugung von .NET Kompilaten unterstützt. Damit die CLR die Kompilate ausführen kann müssen ein paar Randbedingungen eingehalten werden. So muss ein .NET Assemblie erzeugt werden, damit die CLR die Klassen laden und den Bytecode generieren kann. Dies ist im klassischen Sinne ein Binary, eine ausführbare Datei. Des Weiteren muss das Assemblie eine eindeutige Versionsnummer erhalten und mit dem Public Key des Herstellers signiert werden. Das eigentlich Ausführen der Assemblies wird durch den Classloader realisiert. Nachdem der die Assemblies verifiziert wurden (Verifier) führt der Classloader den Bytecode aus und dieser wird dann intern in Maschinencode übersetzt[11]. 3.1.3 Intermediate Language Wie im Kapitel zur CLR beschrieben, können Assemblies verschiedener Programmiersprachen mit der CLR ausgeführt werden. Damit dies technisch möglich ist, haben die verschiedenen Programmiersprachen eine gemeinsame Grundlage, eine Zwischensprache welche als Intermediate Language (IL) bezeichnet wird. Mit Hilfe der Programmiersprachen spezifischen Compiler wird der Quellcode in die IL Sprache übersetzt, neben den Meta Informationen in das Assemblie gepackt und kann dann mkit der CLR ausgeführt werden. Vor der Ausführung wird die IL in Maschinencode umgesetzt und kann dann auf dem Zielsystem ausgeführt werden. Wie der gesamte Prozess von dem Schreiben des Quelltextes, dem Kompilieren mit einem .NET fähigen Kompiler und der Ausführung durch die CLR erfolgt ist in Abbildung 1 zu sehen. 3.1.1 Konzept 8 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Abbildung 1 : .NET - Schritte vom Quelltext zum Maschinencode 3.1.4 Programmierung 3.1.4.1 API Der zweite Bestandteil des .NET Frameworks ist die eigentliche API (Application Programming Interface). Die FLC bietet eine Vielzahl an Klassen- und Bibliotheken. Diese decken sowohl Grundfunktionalitäten, wie auch grafische Benutzeroberflächen, .NET Remoteting bis hin zu Web Forms und XML-Webdiensten ab. Aus dieser API kann sich der Entwickler bedienen. Auf den allgemeinen Basisklassen bauen die .NET Klassen, XML und die verschiedenen Ausprägungen der Forms auf. Die zwei Module ASP.NET und ADO.NET werden in zwei getrennten Unterpunkten genauer betrachtet. [12] Der Ablauf von .NET Programmen kann auf zwei unterschiedliche Arten vonstattengehen. Zum einen überwacht durch die CLR und zum anderen nicht überwacht. Wird der ablaufend Code durch die CLR überwacht wird dieser als managed/verwalteter Code bezeichnet. Nicht überwachter Code wird als unmanaged/nicht verwalteter Code definiert. In einigen Fällen kann es sinnvoll sein, Quellcode nicht überwacht ablaufen zu lassen, z.B. wenn ein Treiber programmiert und die Windows API und nicht de FLC genutzt werden soll. 3.1.4.2 ASP.NET Active Server Pages (ASP).NET ist eine Technologie zum Erstellen von Webanwendungen auf Basis des Microsoft-.NET-Frameworks. Es ist die Nachfolge der ASP Technologie von Microsoft, welche 1996 veröffentlicht wurde. Unter der Bezeichnung ASP.Net werden eine Vielzahl von Klassen für die Entwicklung von Webanwendungen zusammengefasst. Somit stehen dem Entwickler eine Vielzahl von Klassen zur Implementierung zur Verfügung, ohne sich auf eine bestimmte Programmiersprache festlegen zu müssen. Es wird HTML und ASP.Net Quellcode in einer Datei gemischt. So erfolgt eine Bündelung verschiedener Skript- und Programmiersprachen. So können ASP.Net Webseiten mit Hilfe von C#, VB.Net, Perl, PHP ... etc. erstellt werden[13]. Ein entscheidender Vorteil von ASP.Net gegenüber anderen Sprachen für Webanwendungen ist, dass ASP.Net kompiliert wird und nicht erst zur Laufzeit interpretiert und in Maschinensprache übersetzt werden muss, wie es z.B. bei PHP der Fall ist. 3.1.4.3 ADO.NET ADO steht für ActiveX Data Objects und "ist ein Client-seitiger Cache"[14]. Es stellt aus Programmiersicht eine Abstraktionsschicht in dem .NET Framework dar, welche auf Grundlage von einer Datenquelle abstrahiert. Es wird mit einer Datenquelle gearbeitet, diese kann aber im Hintergrund auf verschiedene Datenquellen zugreifen. Dabei handelt es sich um eine verbindungslose Datenbankarchitektur[15]. Als Datenquellen werden in diesem Zusammenhang sowohl Datenbanken als auch andere Formate, z.B. XML Dateien, verstanden. Dieser Zugriff kann parallel erfolgen und das Ergebnis wird durch die ADO.NET Klassen als eine Ergebnistabelle repräsentiert. 3.1.3 Intermediate Language 9 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Die aus den Datenquellen geladenen Daten werden für jeden Client (Prozess) geholt und pro Client zwischengespeichert. Jeder Client hat seinen eigenen Zwischenspeicher. Wenn mit den Klassen von ADO.NET programmiert werden soll muss hierfür der Namespace System.Data verwendet werden. 3.1.5 Verfügbare Laufzeitumgebungen Da das .NET Framework von Microsoft selbst entwickelt wurde gibt es die breite Unterstützung im vollem Umfang nur für die Microsoft Produktpalette. So werden für den Internet Information Server, den Datenbank SQL Server und sämtliche Microsoft Server Betriebssysteme (Server 2003, 2008) .NET Runtimes angeboten. Diese umfassen das .Net Framework Windows (XP, Vista, Server), .Net Mobile und .Net Micro (embedded). Daneben hat Microsoft das Projekt ROTOR aufgesetzt, welches eine Implementierung für Win2000, FreeBSD für akademische Zwecke zur Verfügung stellt. Die kommerzielle Nutzung ist untersagt[16]. Daneben existieren mehrere freie Implementierungen. Des Weiteren ist das Projekt Mono erwähnen. Initiiert durch die Firma Ximian und dessen Gründer Muguel de Icaza entstand und weiter fortgeführt durch die Firma Novell. Des Weiteren gibt es noch das DotGNU Projekt, welches eine Implementierung für Windows, Linux und Solaris bereit stellt[16]. 3.2 J2EE/Java EE Java ist eine objektorientierte Programmiersprache, die 1996 (Release JDK 1.0) von Sun Microsystems auf den Markt gebracht wurde. 1991 wurde eine Projektgruppe namens "Green Projekt" gebildet, die sich zunächst mit den kommenden Trends der Computertechnologie auseinander setzen sollte. Mitarbeiter dieser Projektgruppe waren Mike Sheridan, Patrick Naughton und James Gosling. Die unterschiedlichen Anstrengungen eine Programmiersprache zu entwerfen, die objektorientiert, klein, plattformunabhängig und robust ist, haben zunächst zu der Programmiersprache OAK geführt, die später aus markenrechtlichen Gründen in Java umbenannt wurde.[17] "J2EE (Java EE) ist das am weitesten verbreitete Betriebssystem für Webanwendungen" [18] Java EE ist weniger ein einzelnes Produkt, sondern vielmehr eine Zusammenstellung von Technologien und Spezifikationen. Java EE ermöglicht es stabile, portable und sichere Business Anwendungen zu entwerfen. Die Technologien und Spezifikationen werden von kommerziellen Anbietern oder der OpenSource Gemeinde genutzt, um eigenen Implementationen zu entwickeln. Der Kern von Java EE ist ein modulares und komponentenbasiertes System, das über Schnittstellen miteinander verbunden ist.[18] Version 1.0 der Java 2 Platform Enterprise Edition ist im Dezember 1999 von Sun auf den Markt gebracht worden. Im Mai 2006 wurde J2EE in Java Platform, Enterprise Edition (Java EE) umbenannt und stellt Version 6 dar. "The major theme for the next version of Java EE is ease of development." [19] Mit der aktuellen Version 6 soll die Entwicklung von komplexen Enterprise Anwendungen vereinfacht und beschleunigt werden. Viele J2EE Entwickler haben den Wunsch nach vereinfachter Entwicklung an Sun herangetragen. Sun's Antwort darauf ist eine erhebliche Vereinfachung im Entwicklungsprozess, die im Java Specification Request (JSR) 175 (A Metadata Facility for the JavaTM Programming Language) beschrieben ist. Die neue Kerntechnologie ermöglicht es Entwicklern viele Spezifikationsaufgaben im Code erheblich abzukürzen. Deklarationen die vorher in vielen zusätzlichen Dateien gepflegt werden mussten, werden nun direkt im Java Code durch sog. Annotations eingefügt. Bei Deployment der Anwendung im Server werden anstelle der zusätzlichen Konfigurationsdateien die Annotations direkt aus dem Code verwendet.[19] 3.1.4.3 ADO.NET 10 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Daraus kann man ableiten, dass eine Server-neutrale Implementierung durch die letzten Optimierungen seitens Sun aufwendiger wird. Später in dieser Kapitel wird deutlicher warum der Aufwand steigt. Im Folgenden soll auf die einzelnen Komponenten der Java EE Plattform eingegangen werden. Java EE Versionen Veröffentlichungsdatum Version Ausführlicher Name Dezember 1999 1.0 Java 2 Platform Enterprise Edition, v 1.0 2000 1.2 Java 2 Platform Enterprise Edition, v 1.2 23. Mai 2000 1.2.1 Java 2 Platform Enterprise Edition, v 1.2.1 24. September 2001 1.3 Java 2 Platform Enterprise Edition, v 1.3 24. November 2003 1.4 Java 2 Platform Enterprise Edition, v 1.4 11. Mai 2006 5 Java Platform, Enterprise Edition, v 5 Tabelle 4 3.2.1 Konzept Abbildung 2:Distributed Multitiered Applications[20] Die in Abbildung 2 dargestellte Architektur ist die Basis einer verteilten mehrschichtigen Anwendung. Die Anwendungslogik ist entsprechend ihrer Funktion auf mehreren Schichten verteilt. Die unterschiedlichen Schichten können durchaus auf mehreren autarken Systemen installiert sein. In Abbildung 2 sind zwei Anwendungen (Java EE Application 1 und Java EE Application 2) dargestellt, die auf die verschiedenen Schichten aufgeteilt wurde.[21] 3.2 J2EE/Java EE 11 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen 3.2.1.1 Client Tier Komponenten die auf dem Client System laufen nennt man Client-Tier-Components. Als Komponenten bezeichnet man Software, die nicht eigenständig lauffähig ist und in die Gesamtarchitektur integriert werden müssen. Der Client kann entweder ein Web-Client oder eine eigenständige Java Application sein. Die Java EE Spezifikation legt eindeutig fest welche Komponenten als Client-Komponenten bezeichnet werden.[21] • Application Clients • Web Clients (Applets) Ein Webclient besteht aus zwei Teilen. Die Webschicht (Servlet) erzeugt Informationen, die an den Webclient übermittelt werden. Der Webclient (Browser) wertet die Informationen aus und zeigt das Ergebnis an. Es ist zu Vergleichen mit dem Request-Response Verfahren. Man nennt den Webclient auch "Thin Client", weil er ausschließlich Anfragen an die Webschicht schickt und auf eine Antwort wartet. Der Webclient führt normalerweise keine Datenbankzugriffe oder komplexe Logik aus. Informationen, die an den Webclient geschickt werden, können aber komplexe Logik in Form eines Applets enthalten. Ein Applet ist ein kleines Java Programm, das in der Java Virtual Machine (JVM) der Browsers ablaufen muss. Der Browser führt dieses kleine Java Programm in einer sog. Sandbox aus.[21] Wird komplexere Logik oder ein ausgereifteres User Interface auf dem Clientsystem benötigt, so entwickelt man meist eine eigenständige Anwendung (Fat Client). Ist die Hyper Text Markup Language (HTML) nicht mehr ausreichend, um die Anforderungen an die Anwendung abzudecken, so kann man zu diversen anderen Darstellungstoolkits wie SWING oder das Abstract Window Toolkit (AWT) greifen. Es wird eine Anwendung entwickelt, die mit der Webschicht des Servers kommuniziert. [21] 3.2.1.2 Web Tier Komponenten der Webschicht sind Java Server Pages (JSP) oder Java Servlets und generieren zur Laufzeit statische Inhalte wie HTML, die in einem Browser angezeigt werden können. Diese Komponenten laufen in dem Server ab. JSPs sind HTML Dokumente die Java Code enthalten. Servlets sind Java Klassen die HMTL Code enthalten.[22] JSPs und Servlets setzten einen Servlet-Container voraus, der meist im Java EE abläuft. Besonders zu erwähnen ist eine Technologie, die in Java EE 5 Einzug gehalten hat. Java Server Faces (JSF) ist ein Framework, das die Entwicklung von webbasierten User Interfaces (UI) erleichtert. Das Framework stellt umfangreiche Methoden zur Entwicklung eines UI bereit, die nah an die Möglichkeiten eines Fat Clients heranreichen.[23] 3.2.1.3 Business Tier Die sog. Geschäftslogik enthält gekapselte Programmlogik, die die Geschäftsprozesse abbildet. Sie wird in Enterprise Java Beans (EJBs) gekapselt. EJBs werden zur Laufzeit im Java EE Server im Bean Container verwaltet und sind über Schnittstellen ansprechbar. Der Server übernimmt alle Verwaltungstätigkeiten, wie der Instanziieren oder Zerstören von EJBs. EJBs müssen eine Fülle von Funktionen abdecken und erfordern bei der 3.2.1.1 Client Tier 12 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen späteren Portabilitätsbetrachtung eine besondere Aufmerksamkeit.[21] 3.2.1.4 Enterprise-Information-System Tier Die Datenhaltungsschicht deckt alle Anforderung an die Datenhaltung der Anwendung ab. Zum Einsatz kommen hier entweder Datenbanken oder andere Systeme die Daten persistent speichern können. Enterprise Resource Planning (ERP) Systeme wie auch Legacy Systeme können hier in die verteilte Architektur Einzug halten. Durchaus denkbar ist auch der Betrieb der Datenhaltungsschicht auf dem System, auf dem auch die Geschäftslogik läuft. Grundsätzlich sind die Systeme getrennt und kommunizieren miteinander über ein Netzwerk. [20] 3.2.1.5 Container Der Container in einem Application Server beinhaltet, jene Laufzeit-Komponenten, welche als Schnittstelle zu den niedrigeren Platform spezifischen Funktionen fungieren. Während der Entwicklung muss für eine Komponente, die bspw. auf eine Datenbank zugreift, festgelegt werden, ob eine Transaktionssteuerung verwendet werden soll und wenn ja welche. Auch kann hier festgelegt werden auf welche Ressourcen ein autorisierter Benutzer zugreifen darf.[24] Container spielen in unserer Betrachtung eine besondere Rolle, weil Portabilität nur dann gewährleistet werden kann, wenn die Arbeitsweise der Container von unterschiedlichen Application Server die gleiche ist. 3.2.2 API 3.2.2.1 Assembling 3.2.1.3 Business Tier 13 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Abbildung 3:Application Packaging[25] In Abbildung 3 ist die Verzeichnisstruktur dargestellt, nach der eine Java EE Anwendung aufgebaut sein muss. Diese Verzeichnisstruktur wird in eine JAR-Datei komprimiert verpackt und mit der Dateiendung ".EAR" (Enterprise Archive) versehen. Die Zusammenstellung der verschiedenen Komponenten in ein Enterprise Archive (EAR) bietet eine hohe Flexibilität. Einmal entwickelte Komponenten (EJBs) können so wiederverwendet werden. Das EAR-File enthält zudem auch Konfigurationsdateien im Extensible Markup Language (XML) Format, in denen das Zusammenspiel der Komponenten konfiguriert wird. Diese Konfigurationsdateien (application.xml) nennt man Deployment Descriptoren, die vom Application Server beim Start ausgewertet werden. Es gibt zwei Typen von Deployment Descriptoren. Der Java EE Deployment Descriptor enthält alle Einstellungen bezüglich der Java EE Platform. Der Laufzeit Deployment Descriptor beinhaltet alle Einstellungen für die Java EE Spezifische Implementation. Das ist z.B.: der Application Server. [26] Zudem enthält das "EAR-File" weitere Komponenten. Die Unterverzeichnisse EJB-Module, Web Module, Application Client Module, Resource Adapter Module enthalten die eigentliche Anwendungslogik. In diesen Verzeichnissen liegen die Komponenten aus der eine Anwendung besteht.[26] 3.2.2.2 Übersicht 3.2.2.1 Assembling 14 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Abbildung 4:Java EE Apis[27] In Abbildung 4 wird dargestellt, welche Standard Apis von der Java EE Platform mitgeliefert werden. Portabilität erfordert die ausschließliche Verwendung dieser Apis bei der Entwicklung einer Java EE Applikation.[26] Werden von der Java EE Anwendung zusätzliche Fremd-Apis verwendet (bspw. Fehler-Logging mit den LOG4J Klassen), so muss vor Portierung der Anwendung geprüft werden, ob diese Klassen auf der Zielplattform lauffähig sind.[26] EJBs sind Software Komponenten, die ausschließlich in einem Application Server lauffähig sind. Besonders hervorzuheben ist die Möglichkeit diese Komponenten wiederzuverwenden. Unterschieden wird zwischen: • Session Beans und • Message Driven Beans. Session Beans dienen dazu eine Benutzersession persistent zu machen. Als Beispiel ist hier der klassische Warenkorb in einem Onlineshop zu nennen.[26] Message Driven Beans dienen dazu auf Ereignisse zu horchen, um darauf zu reagieren. Tritt ein Ereignis ein, so wird die Message Driven Bean aktiv und führt die Programmlogik aus.[26] 3.2.2.2 Übersicht 15 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen 3.2.3 Verfügbare Server Abbildung 5:Application Server Platforms Based On Java EE[28] Forrester hat 2007 in einer Studie festgestellt, welche Teilnehmer sich den Markt der Java EE Application Server teilen. In Abbildung 5 ist dargestellt wie stark die Position der Anbieter ist. Diese Gegenüberstellung bezieht sich auf die Java EE Server der einzelnen Anbieter. Kriterien der Gegenüberstelllung sind: • Current Offering: Auf dem Makrt befindliche Produkte dieses Herstellers • Strategy: Preis des Produktes, Unternehmensstrategie, Produktstrategie • Market Presence: Anzahl Kundeninstallationen, Kundenservices[29] Marktführer sind Oracle und IBM, die sich deutlich von den anderen Anbietern absetzen.[30] 3.2.3 Verfügbare Server 16 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen 3.2.4 Java EE Compatibility & Java Verification [31] "Write Once, Run Anywhere" Portabilität ist einer der attraktivsten Aspekte, den die Java Platform mitbringt.[32] Das bedeutet, dass ein Java-Programm auf jeder Plattform, für die es eine Java Virtual Machine gibt, ohne Anpassung lauffähig ist.[31] Diese bedeutende Eigenschaft verspricht Sun auch für die Java Enterprise Edition, wenn die Enterprise Anwendung bestimmte Anforderungen erfüllt. Java EE Compatibility & Java Verification ist ein Paket an Maßnahmen seitens Sun, um Enterprise Anwendungen auf Plattformunabhängigkeit zu überprüfen. In diesem Kontext bedeutet Plattformunabhängigkeit nicht Portabilität über Betriebssystem-Grenzen hinweg, sondern Portabilität über alle Java EE konformen Application Server. Für Unternehmen bedeutet das einen verringerten Aufwand in der Entwicklung von Enterprise Anwendungen und Investitionsschutz. Die Unabhängigkeit von einem Plattform Lieferanten verspricht eine verbesserte Verhandlungsposition und fördert den Wettbewerb. 3.2.4.1 Application Verification Kit for the Enterprise Sun hat ein Toolkit entwickelt[31], das überprüft, ob eine Enterprise Anwendung den Anforderungen der Portabilität gewachsen ist. Das Toolkit überprüft, ob die Enterprise Anwendung die Java Enterprise Apis korrekt nutzt und, ob die Enterprise Anwendung auf allen Java Enterprise Application Server lauffähig ist.[31] Mit einer Ausnahme ist keine Anpassung an der Enterprise Anwendung notwendig. Zur Überprüfung der Portabilität wird die Sun Java System Application Server Platform Edition 9 benötigt, die einen eigenen Application Server mitbringt. Die Application Server spezifischen Deployment Descriptoren müssen daher vorher an die des Sun eigenen Application Server angepasst werden.[32] Das Tooolkit kann frei von der Website http://java.sun.com/j2ee/avk/ von Sun heruntergeladen werden und ist für die Versionen Java EE und J2EE verfügbar. Es ist auf den folgenden Platformen lauffähig.[31] • Sun Solaris 9 and 10 (SPARC), Solaris 9 and 10 (x86) • 64-bit Sun Solaris 10 (SPARC, x86) • Red Hat Enterprise Linux 3.0 Update 1 and 4.0 3.2.4 Java EE Compatibility & Java Verification 17 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen • Windows 2000, Windows 2000 Advanced Server, Windows Server 2003, Windows XP Pro Das Java EE 5 Verification Toolkit überprüft u. a die korrekte Anwendung aller neuen Java EE 5 Technologien:[31] • Enterprise JavaBeans (EJB) 3.0 • JAXB 2.0 • Java Persistence • JavaServer Faces (JSF) 1.2 • JavaServer Pages (JSP) Standard Tag Library (JSTL) 1.2 • Streaming API for XML (StAX) • Web Services Metadata • Java API for XML based Web Services 2.0 (JAX-WS 2.0) Features Mit dem Toolkit wird der Sun Java System Application Server PE 9 mitgeliefert, welcher den Java EE 5 Spezifikation entspricht. Die neue Version des Java EE 5 AVK verspricht überdies eine vereinfachte Bedienung und erweiterte Features, wie das Überprüfen einzelner Anwendungen im Server. Vorher war nur eine gesamte Überprüfung aller installierten Anwendungen gleichzeitig möglich. Desweiteren werden die Überprüfungs-Ergebnisse nun während der Laufzeit zur Verfügung gestellt. Erweiterte Kommandozeilen Tools stehen nun auch zur Verfügung. Das Application Server Migration Tool 2.0, das Bestandteil des Java EE AVK ist, hilft dabei Enterprise Anwendungen, die für andere Application Server entwickelt wurden, auf den Überprüfungsprozess vorzubereiten.[31] Das Java EE 5 AVK prüft den zu scannenden Code auf properitären Code. Es überprüft ob, die Java Archive den Java EE Spezifikationen entsprechen und konvertiert Anwendungs-Server spezifische Deployment Descriptoren.[33] Mit properietärer Code sind Funktionen gemeint, die über den Funktionsumfang von Java EE hinausgehen. Beispiel: Wird von den IBM Websphere Application Server 6 eigenen Scheduler Klassen Gebrauch gemacht, so ist der Code nicht mehr auf anderen Application Servern lauffähig. Der Scheduler Service wird ausschließlich im Websphere Application Server angeboten und setzt einen Scheduling Deamon voraus.[34] Der Scheduling Service von IBM im Websphere Application Server ist ein Scheduler, der Tasks zu einer bestimmten Uhrzeit im Server ausführt.[34] Voraussetzungen Folgende Software wird auf dem System, auf dem das Java EE AVK eingesetzt werden soll, vorausgesetzt: Java Platform Standard Edition Development Kit kurz JDK der Version 5.0 Update 6 oder höher. Ferner wird der Sun Java System Application Server Platform Edition 9 benötigt.[32] Einschränkungen Eine Java Enterprise Anwendung ist eine Komposition aus mehreren Modulen(siehe Abbildung 3). Jedes Modul enthält mindestens einen Deployment Descriptor. Zu beachten ist, dass das Java EE 5 Verification Toolkit zur 3.2.4.1 Application Verification Kit for the Enterprise 18 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Zeit keine RAR-Module (Resource Adapter) überprüfen kann.[32] Prüfumfang/Testkriterien Ein guter Programmierstil zeichnet sich dadurch aus, dass unabhängig von der eigentlichen Kernlogik auch zusätzlicher Code in die Programme fließt. So fließen Testmethoden, Debugmethoden oder Exceptionhandling in die Programme mit ein, die schwer bis gar nicht zu evaluieren sind. Um die Testfähigkeit und Flexibilität zu erhalten, hält Sun eine Testabdeckung von mindestens 80% aller Methoden in dem Programm für anstrebenswert. Die Testabdeckung kann an die jeweiligen Gegegebenheiten angepasst werden.[31] Im Folgenden sind die einzelnen Testkriterien aufgeführt.[32] • EJB Komponenten ♦ Alle statischen Tests müssen erfolgreich durchgeführt werden ♦ Mindestens 80% aller Business-Methoden müssen ohne System Exceptions ausgeführt werden • Web Komponenten ♦ Alle statischen Tests müssen erfolgreich durchgeführt werden ♦ Alle Servlets und JSPs müssen ohne Kompilierungs-Fehler und Runtime-Fehler ausgeführt werden ♦ Alle JSPs müssen die Endung .jsp haben oder müssen im entsprechenden Deployment Descriptor deklariert sein ♦ Alle Servlets müssen ein Mapping on der web.xml haben Prüfprozess An einem theoretischen Überprüfungsprozess soll skizziert werden, wie eine Enterprise Anwendung auf Portabilität überprüft wird.[32] 1. Installation des JAVA EE AVK auf dem Testsystem 2. Statische Prüfung des Anwendungscodes, mittels dem Tool Ant 1. Konfigurieren und Anpassen von Java EE AVK an die zu prüfende Anwendung 2. Ausführung des Tools Ant 3. Dynamische Prüfung des Anwendungscodes 1. Vorbereitung der Anwendung zum Betrieb im Application Server 2. Starten der Anwendung im Application Server 3. Ausführung des Anwendungsspezifischen Codes, mittels Benutzung der Anwendung 4. Ausführung des Reporting Tool 4. Auswertung der Ergebnisse Ergebnis Das Ergebnis ist ein Report, der aus zwei Teilen besteht. Zum einen wird aufgelistet welche EJB-Methoden aufgerufen wurden und ob eine Testabdeckung von 80% erreicht wurde. Zum anderen werden alle getesteten Web-Komponenten aufgelistet.[32] 3.2.4.1 Application Verification Kit for the Enterprise 19 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen 3.2.4.2 Java Powered for the Enterprise Programm Abbildung 6:Java Powered for the Enterprise Logo[35] Unternehmen, die J2EE Lösungen wie z.B.: Application Server entwickeln, können an dem "Java Powered for the Enterprise Programm" teilnehmen, um sich von Sun zertifizieren lassen. Die Zertifizierung bestätigt, dass die angebotene Lösung allen Ansprüchen an die Portabilität von Sun entspricht. Die Zertifizierung so verspricht Sun kann genutzt werden, um sich am Markt von anderen Lösungen abzuheben. Kunden können an dieser Zertifizierung erkennen, dass die angebotene Lösung den Ansprüchen an Portabilität von Sun entspricht. Ab Version Java EE 5 wird dieses Programm von Sun allerdings nicht weiter fortgesetzt. Nun ist jeder dazu berechtigt sein Produkt mit diesem Logo zu schmücken.[31] J2EE Zertifizierte Anbieter[36] Apache Software Foundation ATG Borland Corp. Caucho Technology, Inc. Fujitsu IBM JBoss Group Hewlett-Packard IONA Technologies Kingdee Middleware NEC Nokia ObjectWeb SAP Sonic Software Corporation Sybase, Inc. TongTech Co., Ltd Oracle Corporation SAS Institute, Inc. SpiritSoft TIBCO Software Inc. Trifork Technologies Tabelle 1 BEA Systems DataDirect Technologies Hitachi IronFlare Macromedia (Novell) SilverStream Pramati SeeBeyond Sun Microsystems Tmax Soft webMethods Diese Entwicklung ist folgenden Umstand geschuldet. Anbieter von großen J2EE Platformen haben ein großes Interesse daran sich nicht auschließlich durch die Zertifizierung von Sun vom Markt abzuheben. Sie müssen weitere Alleinstellungsmerkmale entwickeln. Große Anbieter wie IBM bieten neben einer J2EE Platform eine Reihe von anderern Technologien an. Ist der Kunde in der Lage viele dieser angebotenen Technologien miteinander zu kombinieren, so entsteht für den Kunden ein Mehrwert. IBM bietet zu seiner Websphere Application Server Platform auch eine Reihe kompatibler Produkte wie eine Entwicklungsumgebung http://www-01.ibm.com/software/awdtools/developer/application/ oder eine Enterprise Messaging Platform http://www-01.ibm.com/software/de/websphere/mq/ mit an. Die Kombination der J2EE Platform mit weiteren Hersteller spezifischen Technologien geht aber stark zu Lasten der Portabilität. Eine Enterprise Anwendung die im Rational Application Developer for WebSphere Software (die Entwicklungsumgebung von IBM für den Websphere Application Server) entwickelt wurde ist nur mit großem 3.2.4.2 Java Powered for the Enterprise Programm 20 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Aufwand auf einen anderen von Sun zertifizierten Application Server portierbar. "Is integrated and optimized for IBM WebSphere® Application Server and IBM WebSphere Portal Server products and includes test environments for these products."[37] 4 Schlussbetrachtung 4.1 Ergebnisse 4.1.1 Java Im Folgenden soll eine Zusammenfassung zeigen, welche Teildisziplinen in der Java-Anwendungslandschaft beleuchtet wurden. Die Architektur der gesamten Anwendungslandschaft nimmt erheblichen Einfluss auf ihre Einzel-Komponenten. Die Komponenten teilen sich ein Netzwerk, um miteinander kommunizieren zu können. Sie greifen auf eine gemeinsame Datenbasis zu oder sie sind nach einheitlichen Sicherheitsstandards entworfen. Soll eine Anwendung auf Portabilität untersucht werden, so müssen zwangsläufig alle mit ihr in Relation stehenden Komponenten betrachtet werden. Ist die Zielplattform mit einer anhängigen Komponente nicht kompatibel so entsteht Anpassungsaufwand. Ein Programm, das in Java geschrieben ist, ist generell ohne Anpassungsaufwand plattformunabhängig. Eine Java EE Anwendung besteht hingegen aus vielen Teilen, die über Schnittstellen miteinander kommunizieren. Schnittstellen müssen definiert werden und die Anwendung selbst muss beschrieben werden. Deployment Descriptoren sind Dateien, in denen diese Beschreibung generell vorgenommen wird. Deployment Descriptoren werden vom Server zur Laufzeit interpretiert. Jeder Hersteller hat diesbezüglich ein eigenes Konzept. Daher ist besonders die Anpassung der Deployment Descriptoren an den neuen Anwendungsserver zu untersuchen. Nähere Betrachtung verdient auch die Java-Anwendung selbst. Wird eine Java-EE-Anwendung ausschließlich mit den Java Standard APIs entwickelt, so ist der Teil der Anwendung der in Java geschrieben ist ohne Anpassungsaufwand portabel. Sind allerdings Fremd-APIs in die Entwicklung eingeflossen, so muss deren Portabilität überprüft werden. Das Zusammenstellen (Assembling) einer Anwendung erfolgt immer nach gleichen Vorgaben. Eine nach Java-EE-Vorgaben zusammengesetzte Anwendung sollte von jedem Server ohne Anpassung akzeptiert werden. Die größte Vereinfachung in der neuesten Java EE Version ist zweifelsohne die Auslagerung der beschreibenden Elemente aus den Deployment Descriptoren in den Java Code selbst. Der Aufwand bei der Entwicklung einer Java EE Anwendung verringert sich somit. Da die Elemente aber in den Quellcode verschoben wurden, erhöht sich der Aufwand für eine Portierung. Die notwendigen Änderungen müssten dann im Quellcode selbst vorgenommen werden. 4.1.2 .NET Analog zu Java ist auch ein .Net Programm generell und ohne Anpassungsaufwand theoretisch plattformunabhängig. Im Gegensatz zu Java kann in .NET in vielen verschiedenen Programmiersprachen wie 4 Schlussbetrachtung 21 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen Smalltalk, C#, C++, ... programmiert werden. Dem theoretischen Ansatz, dass auf allen momentanen verfügbaren Systemen ein .NET Programm laufen kann, steht die fehlende Implementierung von CLRs auf nicht Microsoft Systemen entgegen. 4.2 Fazit Betrachtet man nur die in Java geschriebene Enterprise Anwendung, so ist es Sun nicht gelungen Portabilität gänzlich ohne Anpassungs- oder Validierungsaufwand zu gewährleisten. Microsoft hat durch die Standardisierung von .NET die Grundlage gelegt, damit in .NET entwickelte Anwendungen portabel sind. Durch die fehlenden Implementierungen der Runtimes auf nicht Microsoft Systemen ist die Portabilität aktuell faktisch nicht gegeben. Es wurde in dieser Studienarbeit erkannt, dass die grundsätzliche Portierung einer Java Enterprise Anwendung möglich ist. Bei der Portierung entsteht Anpassungsaufwand und somit Kosten. Eine Portierung von .NET Anwendungen ist auf Grund fehlender Runtimes nicht möglich. Aus Sicht von Softwareanbietern ist somit Java EE als Programmiersprache vorzuziehen, wenn die Applikation auf unterschiedlichen Plattformen laufen soll. Betrachtet man darüber hinaus auch die Architektur, in der eine Anwendung eingebunden sein kann, so stellt sich die Frage, in wie weit Server-neutrale Portabilität überhaupt sinnvoll ist. So können z.B. mit Hilfe der Serviceorientierten Architektur (SOA) die Stärken einzelner Komponenten Plattform- und Programmiersprachen unabhängig zu einer Applikation zusammen gefasst werden. Dies geschieht durch die lose Koppelung der einzelnen Module über den Enterprise Service Bus. 4.3 Ausblick Beide Plattformen werden permanent weiter entwickelt und auch eine Vielzahl von Softwareanbietern entwickeln Applikationen für diese Plattformen. Das Interesse von Microsoft an der Verfügbarkeit von CLRs auf allen nicht Microsoft Systemen ist begrenzt, da eine enge Verzahnung von den Microsoft Server und Client Betriebssystemen und dem .NET Framework vorliegt. Da hat Sun mit Java klare Vorteile, da für alle Betriebssysteme CLRs vorliegen. Dort ist aber der Nachteil, dass nur eine Programmiersprache verwendet werden kann. V Fußnoten 1. ? Vgl. o. V. (2009l) 2. ? Entnommen aus o. V. (2009h), S. 633 f. 3. ? Vgl. o. V. (2009m) 4. ? Vgl. Stark, Thomas (2005), S. 425 ff. 5. ? Vgl. Merker, Erwin (2004), S. 319 6. ? Vgl. o. V. (2009n) 7. ? Vgl. Roden, Golo (2008), S. 2 8. ? Vgl. Karadagi, Allan (2007), S. 24 9. ? Vgl. Gläßer, Lothar (2003), S. 134ff 10. ? Vgl. Sosnecki, Anita (2003), S. 24 11. ? Vgl. Thai, Thuan und Lam, Hoang Q. (2003), S. 21 4.1.2 .NET 22 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen 12. ? Vgl. o. V. (2007) 13. ? Vgl. Wenz, Christian, Kordwig, Andreas und Trennhaus, Christian (2004), S. 21 14. ? Vgl. Wagner, Johann und Schwarzenbacher, Kurt (2004), S. 93 15. ? Vgl. Liberty, Jesse (2007), S. 369 16. ? 16,0 16,1 Vgl. Candar, Kaan (2007), S. 17 17. ? Vgl. Ullenboom, Christian (2009), Kap. 1.2 18. ? 18,0 18,1 Vgl. Stark, Thomas (2005), S. 15 19. ? 19,0 19,1 Vgl. o. V. (2009f) 20. ? 20,0 20,1 Entnommen aus o. V. (2009h), S.43 21. ? 21,0 21,1 21,2 21,3 21,4 Vgl. o. V. (2009h), S.42 ff. 22. ? Vgl. Brüssau, Kai (2009), S. 26 23. ? Vgl. Brüssau, Kai (2009a), S. 3 24. ? Vgl. o. V. (2009h), S.49 ff. 25. ? Entnommen aus o. V. (2009h), S.53 26. ? 26,0 26,1 26,2 26,3 26,4 26,5 Vgl. o. V. (2009h), S.53 ff. 27. ? Entnommen aus o. V. (2009h), S.57 28. ? Entnommen aus Rymer, John R. (2007), S. 21 29. ? Vgl. Rymer, John R. (2007), S. 5 f. 30. ? Vgl. Rymer, John R. (2007), S. 19 31. ? 31,0 31,1 31,2 31,3 31,4 31,5 31,6 31,7 31,8 Vgl. o. V. (2009b) 32. ? 32,0 32,1 32,2 32,3 32,4 32,5 32,6 Vgl. o. V. (2009c) 33. ? Vgl. o. V. (2009e) 34. ? 34,0 34,1 Vgl. o. V. (2009j) 35. ? Entnommen aus o. V. (2009i) 36. ? Vgl. o. V. (2009a) 37. ? Vgl. o. V. (2009k) 5 Anhang Literatur und Quellenverzeichnis Brüssau, Kai (2009) Brüssau, Kai (2009a) Candar, Kaan (2007) Gläßer, Lothar (2003) Karadagi, Allan (2007) Liberty, Jesse (2007) Merker, Erwin (2004) o. V. (2009a) 5 Anhang Script Mehrschichtenarchitektur zur Vorlesung: Objektorientierte Programmiertechnik (HH), Hamburg https://campus.bildungscentrum.de/nfcampus/get/22939196/Kapitel%2010.pdf (24.10.09, 12:49) Script Java Server Faces zur Vorlesung: Objektorientierte Programmiertechnik (HH), Hamburg 2009, https://campus.bildungscentrum.de/nfcampus/get/23855122/Kapitel%2011.pdf (24.10.09, 12:50) Mono.net goes Linux, Franzis (November 2007) IT-Lösungen im E-Business. Technische Grundlagen: Die Technischen Grundlagen - Einfach, Praxisna Corporate Publishing, 1. Auflage (Juli 2003) Service-orientierte Architekturen: Proof-of-Concept eines Web Service zur Integration verteilter Anwe Programmieren mit C#, O'Reilly, 2. korrigierter Nachdruck 2007 Grundkurs Java-technologien, 2004, Vieweg+Teubner, 1. Auflage (2004) Sun (Hrsg.), J2EE: Authorized Licensees of the J2EE Platform, http://java.sun.com/j2ee/licensees.html 23 Möglichkeiten_der_Server-neutralen_Implementierung_von_Anwendungen o. V. (2009b) o. V. (2009c) o. V. (2009d) o. V. (2009e) o. V. (2009f) Sun (Hrsg.), J2EE: Java Verification, http://java.sun.com/j2ee/verified/index.jsp (04.10.2009, 11:11) Sun (Hrsg.), Java AVK User Guide, http://java.sun.com/j2ee/avk/5.0/usersguide.html (04.10.2009, 11: Sun (Hrsg.), Java EE 5 Compatible Implementations, http://java.sun.com/javaee/overview/compatibilit Sun (Hrsg.), Java EE AVK Release Notes, http://java.sun.com/j2ee/avk/5.0/release.html (04.10.2009, 1 Sun (Hrsg.), JSR 244: JavaTM Platform, Enterprise Edition 5 (Java EE 5) Specification, http://www.jc 12:09) o. V. (2009g) nicht Sun (Hrsg.), Java EE Technologies at a Glance, http://java.sun.com/javaee/technologies/ (04.10.2009, 1 verwendet Sun (Hrsg.), Java EE 5 Tutorial: For Sun Java System Application Server 9.1, Santa Clara 2008, o. V. (2009h) http://java.sun.com/javaee/5/docs/tutorial/doc/JavaEETutorial.pdf (04.10.2009, 13:20) o. V. (2009i) Sun (Hrsg.), The Java Powered for the Enterprise Program, http://java.sun.com/j2ee/verified/program.h IBM (Hrsg.), Websphere Application Server Scheduling Service, http://publib.boulder.ibm.com/infocenter/wsdoc400/v6r0/index.jsp?topic=/com.ibm.websphere.iseries. o. V. (2009j) (04.10.2009, 11:17) IBM (Hrsg.), Rational Application Developer for WebSphere Software, http://www-01.ibm.com/softw o. V. (2009k) (04.10.2009, 11:16) o. V. (2007) MSDN Microsoft, http://msdn.microsoft.com/de-de/library/zw4w595w%28lightweight%29.aspx, (abg o. V. (2009l) What is CORBA? What does it do?, http://www.omg.org/gettingstarted/corbafaq.htm#WhatIsIt, (abger o. V. (2009m) What is COM?, http://www.microsoft.com/com/default.mspx, (abgerufen am 18.10.2009, 20:10 Uhr) Microsoft .NET Language Support and Interoperability and Learning, o. V. (2009n) http://www.microsoft.com/germany/net/Microsoft%20.NET%20Language%20Support%20and%20Int (abgerufen am 15.11, 13:21 Uhr) Roden, Golo Auf der Fährte von C#, Springer, Berlin, 1. Auflage (April 2008) (2008) Rymer, John R. Forrester (Hrsg.), The Forrester Wave?: Application Server Platforms Q3 2007, Cambridge 2007, (2007) https://sites.google.com/a/motzkus.info/fallstudie/dateien/MarktsituationApplicationServer.pdf (24.10. Sosnecki, Anita Seminar Softwaretechnologie WS 2003, Universität Bonn (2003) Stark, Thomas J2EE: Einstieg für Anspruchvolle, 1. Auflage, Addison Wesley, München 2005 (2005) Thai, Thuan und Lam, Hoang Q. .NET Framework Essentials, Oreilly, 3. Auflage (August 2003) (2003) Ullenboom, Java ist auch eine Insel (2009), Galileo Press GmbH, Bonn 2009, Christian (2009) http://download.galileo-press.de/openbook/javainsel8/galileocomputing_javainsel8.zip (04.10.2009, 11 Wagner, Johann und Föderative Unternehmensprozesse: Technologien, Standards und Perspektiven, Publicis Corporate Pub Schwarzenbacher, Kurt (2004) Wenz, Christian, Kordwig, Andreas Jetzt lerne ich ASP.NET, Markt und Technik, 1. Auflage (2004) und Trennhaus, Christian (2004) 5 Anhang 24
