Client-Server-Infrastruktur und -Architektur für Espresso

INHALTSVERZEICHNIS

Einleitung und Übersicht
Motivation
Zielsetzung

Voraussetzungen
Komponentenbasierte Softwareentwicklung
Weshalb komponentenbasierte Entwicklung?
Komponentenorientierte Plattformen
J2EE als Plattform für myEspresso.net
Sun ONE als Plattform für myEspresso.net
Sun Open Net Environment (Sun ONE)
Sun ONE bei myEspresso.net
Gründe für den Einsatz von Sun ONE

Architektur und Technologien
myEspresso.net Übersicht
Entwicklungsanforderungen
Systemübersicht
Anbindung
Verwendete Sun ONE Komponenten
Weitere Komponenten
Verwendete Technologien
Enterprise Java Beans
J2EE Connector Architecture
Java Servlets und JavaServer Pages
Java 2 Micro Edition
Web Services
Standards im Umfeld von Web Services

Design
Entwicklungsmodelle
Phasenmodelle
Rational Unified Process
Der Rational Unified Process bei myEspresso.net
Analysephase
Entwurfsphase
Implementierungs- und Übergabephase
Schichtenmodell
myEspresso.net Komponentenarchitektur
Anpassung des EJB Command Patterns
Ersetzen clientseitiger Kommandoobjekte
Kommandoobjekte auf Serverseite

Implementierung
Implementierung des EJB Command Patterns
Kommandos
Controller
Manager / Services
Web Services
Server
Client
Dienste
ProvisioningManager
CurrencyConverter
CalendarManager

J2EE Entwicklung im Team
Teamwork
Strategien für das Teamwork
Rollenverteilung
Architektur
Werkzeuge

Assembling and Deploying
Packaging
Aufbau einer Enterprise Applikation
Deskriptoren
Client Packaging
Der Build und Deploy Prozeß
Ant

Ausblick / Ergebnisse
Ergebnisse
Ausblick

Tools und Utilities
INHALTSVERZEICHNIS ix
Oracle JDeveloper
Altova XML Spy
SmartCVS
Softerra LDAP Browser
Simulatoren
Sun's Java Web Services Developer Pack

Literaturverzeichnis

Abbildungsverzeichnis

ABSTRACT

Abbildung in dieser Leseprobe nicht enthalten

Zusammenfassung:

Die Diplomarbeit beschreibt die prototypische Entwicklung einer Infrastruktur und Architektur für eine Plattform zur Anbindung mobiler Endgeräte an bestehende Infrastrukturen in Unternehmen und die Erweiterung der Funktionalität der Geräte durch internetbasierte Dienste. Dazu wurde mit myEspresso.net eine modulare und erweiterbare Architektur entwickelt, die es ermöglicht, mobile Lösungen für bestehende Anwendungen schnell und flexibel zu entwickeln. Es können sowohl neue Anwendungen erstellt, als auch bestehende Infrastrukturen integriert werden. In der Diplomarbeit werden die zur Realisierung benutzten Technologien erläutert und deren Anwendung in myEspresso.net beispielhaft demonstriert. Außerdem wird auf das Design der Architektur der Applikation, unter Berücksichtigung von Entwurfsmustern, eingegangen und die Vor- und Nachteile verschiedener Architekturen beschrieben. Zuletzt wird auch die Entwicklung von J2EE Anwendungen im Team und die Probleme, die dabei auftreten können, erörtert. Es werden Werkzeuge vorgestellt, die diese Probleme vermeiden helfen und deren Anwendung bei myEspresso.net gezeigt.¹

Danksagung

Bedanken möchte ich mich bei allen Freunden, die verhindert haben, daß ich diese Diplomarbeit in den Sand setze bei Sandra, dafür das sie es sich auf sich genommen hat, diese Diplomarbeit, für die sich sicher nur Informatiker begeistern können, Korrektur zu lesen bei unseren Betreuern Herrn Prof. Dr.-Ing. Meixner und Prof. Dr. rer. nat. Kelch, dafür, daß sie dieses Experiment eingegangen sind bei allen Mitarbeiten des Fachbereichs Informatik, die uns mit Rat und Tat unterstützt haben, insbesondere Frau Podratzky und natürlich bei Hubert, Andreas und Jürgen dafür, daß wir trotzdem immer noch miteinander reden

1 Einleitung und Übersicht

Diese Diplomarbeit beschreibt die prototypische Entwicklung einer Infrastruktur und Architektur für eine Plattform zur Anbindung mobiler Endgeräte an bestehende Infrastrukturen in Unternehmen und die Erweiterung der Funktionalität der Geräte durch internetbasierte Dienste.

Aufgrund der Größe und Komplexität teilt sich dieses Projekt in drei weitere Diplomarbeiten mit jeweils unterschiedlichen Schwerpunkten auf:

Andreas Jocham,

„Dienste- und Benutzerprofilkomponenten für Espresso, eine komponenten- orientierte Plattform zur benutzerbezogenen Anbindung von javafähigen mobilen Geräten an Informationsdienste und Geschäftsprozesse“

Hubert Schweiger,

„Die Daten-Persistenz-Schicht für Espresso, eine komponentenorientierte Plattform zur benutzerbezogenen Anbindung von javafähigen mobilen Geräten an Informationsdienste und Geschäftsprozesse“

Jürgen Kanzler,

„Entwurf und Programmierung einer Kommunikationsschnittstelle zwischen J2EE-Servern und SAP/R3 Systemen zum Datenaustausch für eine mobile Außendienstapplikation“

1.1 Motivation

Der Zugriff auf das Internet ist heute nicht mehr nur auf den PC eingeschränkt. Das Handy und der Organizer verschmelzen immer mehr zu einem Gerät und die neuen Netze garantieren von diesen einen fast gleichwertigen Zugang zum Internet, wie ihn auch der heimische PC bietet.

Der Benutzer kann 24 Stunden rund um die Uhr, 7 Tage die Woche, diese Dienste nutzen, egal wo er sich befindet und was er gerade tut.

myEspresso.net soll nun einerseits aufzeigen, welche Wege es gibt, diesen Anforderungen gerecht zu werden, andererseits aber auch die Chance bieten, sich mit den neuesten Technologien zu befassen und ein größeres Projekt von Grund auf zu planen und realisieren.

Diese Punkte waren ausschlaggebend für die Entscheidung, dieses Projekt ohne Beteiligung einer Firma zu entwickeln, da nur so die nötige Entscheidungsfreiheit in allen Fragen des Projekts gegeben war.

Durch die Entscheidung myEspresso.net im Team zu entwickeln, bot sich auch die Möglichkeit, den Ablauf eines realen Projekts in einer Firma nachzubilden, inklusive aller Probleme die daraus entstehen können.

1.2 Zielsetzung

myEspresso.net ist eine modulare und erweiterbare Architektur, die es ermöglicht, mobile Lösungen für bestehende Anwendungen schnell und flexibel zu entwickeln. Es können sowohl neue Anwendungen erstellt, als auch bestehende Infrastrukturen integriert werden.

Im Hinblick auf Anforderungen von Unternehmen wurde myEspresso.net unter folgenden Zielsetzungen entwickelt:

- Modulare Architektur, die es unnötig macht, bestehende Infrastrukturen für die mobile Anwendung zu überarbeiten.
- Skalierbar, um die Erweiterbarkeit und Anpassungsfähigkeit für zukünftige Applikationen, Geräte und auch die Anzahl der Benutzer zu garantieren. myEspresso.net ist darauf ausgelegt, mit den Anforderungen zu wachsen.
- Auf Standards basierend, um Entwicklern eine geringe Einarbeitungsphase zu bieten und eine nahtlose Integration in existierende Systeme zu ermöglichen.

Primäre Zielgruppen von myEspresso.net sind Außendienstmitarbeiter, denen der ständige Zugriff auf aktuelle Daten ihrer Firma ermöglicht wird und Privatanwender, welche die Möglichkeiten ihrer Mobiltelefone erweitern wollen.

2 Voraussetzungen

In diesem Kapitel werden die Vorüberlegungen für die Entwicklung von myEspresso.net beschrieben.

Eine der wichtigsten Entscheidungen für den weiteren Verlauf der Entwicklung, ist die Wahl einer geigneten Plattform für myEspresso.net.

Um diese Auswahl treffen zu können, werden im verfügbaren Plattformen kurz vorgestellt und die Kritierien der Bewertung beschrieben.

2.1 Komponentenbasierte Softwareentwicklung

2.1.1 Weshalb komponentenbasierte Entwicklung?

Komponenten

Komponenten sind eigenständige und wiederverwertbare Softwarebausteine mit wohldefinierten Schnittstellen, welche ihre Implementierung nach außen verbergen.

Eine weitere, etwas ausführlichere Definition lautet:

„Eine Komponente ist ein Stück Software, das klein genug ist, um es in einem Stück erzeugen und pflegen zu können, groß genug ist, um eine sinnvoll einsetzbare Funktionalität zu bieten und eine individuelle Unterstützung zu rechtfertigen, sowie mit standardisierten Schnittstellen ausgestattet ist, um mit anderen Komponenten zusammenzuarbeiten.“²

Laufzeitumgebung

Komponenten können nicht für sich alleine existieren, sondern müssen in eine Laufzeitumgebung „deployed“, das heißt eingebunden werden.

Diese Laufzeitumgebung wird als „Container“ bezeichnet und ist die Grundlage einer komponentenorientierten Architektur. Der Container stellt die Funktionalität zur Verfügung, die für die Ausführung der Komponenten benötigt wird. Beispiele hierfür sind:

- Thread- und Prozeßmanagement
- Clustering und Lastverteilung
- Ausfallsicherheit
- Namens- und Verzeichnisdienst
- Zugriffsmöglichkeiten und Pooling von Betriebssystemressourcen (z. B. Netzwerk-Sockets)

Deshalb:

Die Idee der komponentenbasierten Softwareentwicklung ist es, die Komponenten möglichst einfach und flexibel zu halten, um sie möglichst oft wiederverwenden zu können.

Die Entwicklungszeit soll durch Wiederverwendung oder durch Zukauf von fertigen, standardisierten Komponenten reduziert und somit auch die Fehlerhäufigkeit verringert werden.

Ein weiterer Vorteil ist, daß Komponenten eine genau spezifizierte Aufgabe haben und sich nicht um weitere Belange kümmern müssen. Dies wiederum ermöglicht es dem Entwickler, sich ausschließlich auf sein Spezialgebiet zu konzentrieren.

Die fertige Komponente wird dann mit anderen in einen Container „deployed“, der die Ablaufumgebung für diese zur Verfügung stellt und die verschieden Dienste wie Persistenz oder Transaktionsmanagement enthält.

Applikationen können dann im besten Fall aus vielen bestehenden Komponenten „zusammengestellt“ werden. So muß nur noch das Zusammenspiel dieser programmiert werden.

2.1.2 Komponentenorientierte Plattformen

Um die Zielsetzungen von myEspresso.net zu erreichen, ist es nötig, eine geeignete Umgebung für das Projekt zu wählen. Vorgaben wie Modularität und Skalierbarkeit verlangen hier eine stark komponentenorientierte Plattform, da nur eine solche die benötigten Dienste wie Transaktionen, Persistenz, Sicherheit, usw., für die Realisierung eines solchen Projektes bereitstellt.

Auf dem Markt haben sich im Moment folgende zwei Plattformen etabliert:

- Microsoft .NET
- Sun J2EE

Microsoft .NET³

Microsoft .NET ist ein Produkt, welches es ermöglicht, intelligente EnterpriseWeb Services zu erstellen. Es ist größtenteils eine Wiederauflage von Windows DNA (Distributed Net Application Architecture), Microsoft's vorhergehender Plattform für die Entwicklung von Enterprise Anwendungen. Windows DNA verfügt über viele bewährte Technologien wie Microsoft Transaction Server, COM+, Microsoft Message Queue und Microsoft SQL Server, welche bis heute erfolgreich in Produktionsumgebungen eingesetzt werden.

Das neue .NET Framework ersetzt diese Technologien und fügt darüber hinaus noch eine Webservice-Schicht und eine verbesserte Sprachenunterstützung hinzu.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: .NET Programmiermodell für Web Services

Die .NET-Applikation läuft in einem Container, der für Enterprise Anwendungen nötige Dienste wie Transaktionen, Sicherheit und Messaging zur Verfügung stellt.

Die Anwendungsschicht der .NET-Applikation ist aus .NET „managed components“ aufgebaut und beinhaltet die Verarbeitungslogik. Sie kann sich über ADO.NET („Active Data Objects“) mit Datenbanken verbinden und hat über den Microsoft Host Integration Server auch Zugriff auf bereits existierende Dienste. Außerdem ist es möglich, Unternehmensanwendungen über Web Services anzubinden.

Die Anwendung selbst kann ihre eigenen Dienste auch über die Web Service Schicht zur Verfügung stellen.

Für herkömmliche Clients wie Browser oder Desktop Anwendungen, werden über ASP.NET („Active Server Pages“) oder „Windows Forms“, einem Ersatz für MFC, angebunden.

Das .NET Framework

Microsoft .NET bietet Sprachunabhängigkeit und Interoperabilität zwischen verschiedenen Sprachen, was einen der elementaren Aspekte dieser Plattform darstellt. Eine einzelne Komponente kann teilweise in VB.NET, der .NET Version von Visual Basic, und in C#, Microsoft's neuer objektorientierten Programmiersprache, geschrieben werden.

Der Quellcode beider Sprachen wird in die „Microsoft Intermediate Language“ übersetzt, welche mit Java Bytecode vergleichbar ist.

Dieser Zwischencode wird dann von der „Common Language Runtime“ (CLR) interpretiert und in einen ausführbaren Code übersetzt.

Die CLR ist eine Schicht zwischen dem Quellcode und der Zielhardware. Der

Code läuft nur in der CLR. Damit ist dieses Verfahren vergleichbar mit der „Java Runtime Environment“ (JRE) .

Java 2 Enterprise Edition (J2EE)⁴

Die Java 2 Enterprise Edition (J2EE) wurde entwickelt, um Entwicklung, Deployment und Management von Multitier Enterprise Anwendungen zu ereinfachen.

J2EE ist ein Industriestandard, der durch die Initiative von Sun Microsystems entstanden ist und heute von mehr als 30 Unternehmen mit getragen wird.

Wichtig ist, daß J2EE kein Produkt, sondern ein Standard ist, der beschreibt, wie Anwendungen und Container implementiert werden müssen, um zueinander kompatibel zu sein.

Ziel von J2EE ist es, dem Kunden die Wahl aus Herstellern und Werkzeugen zu lassen, damit durch die Konkurrenz dieser, die bestmögliche Lösung entsteht.

Um diesen Standard zu schaffen, arbeitet Sun mit weiteren Anbietern von eBusiness Plattformen wie Oracle, IBM und BEA zusammen. Weiterhin wurde auch der „Java Community Process“ (JCP) ins Leben gerufen, der über neue Ideen zur Verbesserung von Java und J2EE berät und über ihre Einführung entscheidet.

Java, die Grundlage von J2EE

Die J2EE Architektur basiert auf der Programmiersprache Java. Der Vorteil von Java ist, daß ein einmal geschriebener Code auf jeder Plattform, für die eine „Java Runtime Environment“ (JRE) verfügbar ist, ohne Änderung ablauffähig ist.

J2EE ist eine Anwendung von Java, deshalb können entwickelte Komponenten in Bytecode übersetzt und von der JRE ausgeführt werden.

In der Regel werden auch die Container in Java implementiert.

Die strengen Kontrakte von J2EE ermöglichen zusammen mit den Eigenschaften von Java daher, Komponenten auf unterschiedlichen Plattformen und in unterschiedlichen Containern, ohne Änderungen des Codes, ablaufen zu lassen.

J2EE und Web Services

J2EE wurde als Architektur zur Entwicklung von serverseitigen, in Java imple-mentieren Anwendungen konzipiert. Es kann benutzt werden, um Internetauftritte, Softwarekomponenten oder ganze Applikationen damit zu entwickeln. Aufbauend auf bestehenden APIs wurde es vor Kurzem um die Fähigkeit, auf XML basierende Web Services zu verarbeiten, erweitert.

J2EE Programmiermodell für Web Services

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: J2EE Programmiermodell für Web Services

J2EE Applikationen werden in einem Container verarbeitet, welcher für Enterprise Anwendungen nötige Dienste wie Transaktionen, Sicherheit und Persistenz zur Verfügung stellt.

Die Businesschicht beherbergt die Geschäftslogik und die Datenhaltung. In großen J2EE Anwendungen besteht diese üblicherweise aus kooperierenden Komponenten, sogenannten „Enterprise Java Beans“ (EJB). Der Zugriff auf Datenbanken oder Legacy Systeme erfolgt über die „Java Database Connectivity“ (JDBC) oder SQL/J bzw. die „Java Connector Architecture“ (JCA). Zusätzlich können andere Anwendungen auch über Web Services mit Hilfe der „Java APIs for XML“ (JAX APIs) angebunden werden.

Auf die Dienste der J2EE Anwendung kann sowohl über Web Services als auch über das „Internet Inter ORB Protocol“ (IIOP) zugegriffen werden. Für webbasierte Clients steht mit „Servlets“ und „Java Server Pages“ (JSP) eine eigene Präsentationsschicht zur Verfügung. (Genaueres zu Enterprise Java Beans und der Datenhaltung in [Schweiger03]).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Vergleich .NET und J2EE

Wie Tabelle 1 zeigt, gibt es sehr viele Ähnlichkeiten zwischen beiden Technologien. Im folgenden werden jedoch noch die Unterschiede erläutert. Time-To-Market Eigenschaften

„Time-To-Market“ gibt an, welche Möglichkeiten das Produkt dem Entwickler bietet, um schnell auf neue Entwicklungen des Marktes zu reagieren. Heutzutage entscheiden schon wenige Monate über das Gelingen oder Scheitern einer Idee, denn die Gefahr, daß ein anderes Unternehmen schneller sein könnte, ist groß.

J2EE und .NET setzen hier auf unterschiedliche Wege, welche beide Vor- und Nachteile haben. Für eine genauere Erläuterung dieser sei auf [J2EE2001] verwiesen.

Single-Vendor Solution

Generell ist es einfacher, eine Lösung einzusetzen, die aus einer Hand stammt. Obwohl J2EE für sich eine vom Hersteller unabhängige Kompatibilität in Anspruch nimmt, trifft das in der Realität nicht immer zu. Zu oft behindern noch herstellerspezifische Eigenheiten die Portabilität einer Anwendung. (Siehe hierzu auch [ServerSide03a] und [ServerSide03b]).

Dagegen ermöglicht J2EE es, aus verschiedenen Produkten verschiedener Hersteller zu wählen, sowohl im Bereich des Application Servers als auch im Bereich der eingesetzten Werkzeuge.

.NET verfügt über eine komplette Lösung von einem einzelnen Hersteller:

Microsoft. .NET fehlen zwar einige Highnd Features, welche J2EE besitzt, aber trotzdem bietet es vergleichbare Möglichkeiten wie J2EE. Außerdem hat es mit .NET-Studio eine vollständig integrierte Entwicklungsumgebung.

Ein anderer Ansatz, um eine Single-Vendor Lösung zu beurteilen, ist es, be- stehende Systeme in Unternehmen mit einzubeziehen. Die meisten dieser Legacy Systeme sind von Herstellern wie IBM oder BEA, deren J2EE Plattformen sich nahtlos an diese anbinden lassen. Deshalb könnte man hier im Gegensatz zu .NET eher eine J2EE Lösung des entsprechenden Herstellers als eine Single-Vendor Solution bezeichnen.

Unterstützung existierender Systeme

In den meisten Unternehmen existiert bereits Code, der in vielen verschiedenen Programmiersprachen entwickelt wurde. Außerdem benutzen sie eine Reihe von Legacy-Systemen wie SAP R/3 oder Siebel.

Notwendigerweise müssen diese Investitionen der Unternehmen in neue

Anwendungen mit integriert werden, da die Unternehmen in der Regel kein Budget und keine Zeit für eine Neuentwicklung ihrer Systeme haben.

J2EE bietet eine Reihe von Möglichkeiten, die Anforderung der Integration von Legacy-Systemen zu erfüllen:

- Java Message Service (JMS)
- Web Services
- Schnittstellen für CORBA
- Java Native Interface (JNI)
- Java Connector Architecture (JCA)

.NET bietet für die Integration von Legacy Systemen eigene Serverprodukte:

- Microsoft Host Integration Server 2000
- Microsoft COM Transaction Integrator (COM TI)
- Microsoft Message Queu (MSMQ)
- Microsoft BizTalk Server 2000

Der große Vorteil von J2EE liegt hier eindeutig in der Java Connector Architecture, die einen großen Markt von Adaptern für verschiedene Systeme schaffen wird. .NET bietet diese Möglichkeit nicht und unterstützt im Moment nur einige ausgewählte Systeme.

Ausgereiftheit der Plattform

Wichtig für die Wahl einer geeigneten Plattform ist auch deren Ausgereiftheit. Es gibt bereits viele J2EE-Anwendungen, die seit Jahren laufen und auch in geschäftskritischen Bereichen keine Probleme verursachen. Trotzdem gibt es noch einige Risiken beim Einsatz von J2EE:

- Die automatische Persistenz ist noch nicht völlig ausgereift
- Die Java Connector Architecture ist völlig neu
- Die Integration der Web Services ist völlig neu

.NET basiert, obwohl neu entwickelt, in Teilen immer noch auf Windows DNA, welches ebenso wie J2EE bereits seine Fähigkeit, geschäftskritische Anwendungen zu betreiben, unter Beweis gestellt hat. Aber auch hier gibt es

Punkte, auf die geachtet werden sollte:

- Ein großer Teil der .NET-Plattform wurde komplett neuentwickelt
- Die Programmiersprache C# ist völlig neu
- Die Web Service-Unterstützung ist völlig neu

Offensichtlich ist J2EE aufgrund der Dauer seiner Anwendung die ausgereiftere Plattform, obwohl der Einsatz der neuen APIs ebenfalls risikoreich sein kann. Im Gegensatz zu .NET ist bei J2EE die Plattform keine komplette Neuentwicklung und es wurde auch keine neue Programmiersprache eingeführt. Diese beiden Punkte bilden ein enormes Risiko im Vergleich zu J2EE.

Sprachunterstützung

J2EE basiert auf Java und deshalb müssen alle Komponenten, die in eine J2EE Umgebung deployed werden, auch in Java geschrieben werden. Eine Anbindung an andere Sprachen läßt sich nur über die bereits vorher genannten Wege wie CORBA, JNI, usw. umsetzen. Es ist nicht möglich, verschiedene Sprachen zur Erstellung einer Komponente zu mischen, obwohl der Bytecode sprachneutral ist und es so theoretisch machbar wäre.

.NET unterstützt dagegen die Entwicklung in jeder Sprache, die von Microsoft's Werkzeugen unterstützt wird. Mit Ausnahme von Java können fast alle gängigen Programmiersprachen werden. Außerdem wurde für .NET eine eigene Program-miersprache C# neuentwickelt, die im Wesentlichen vergleichbar mit Java ist. Diese Sprachunabhängigkeit ermöglicht es, einzelne Komponente in einer ganzen Reihe von Sprachen zu schreiben. Damit verfügt .NET über einen klaren Vorteil gegenüber J2EE , unabhängig davon, ob dieser wirklich sinnvoll ist (siehe dazu: [J2EE2001]).

Migration existierender Anwendungen

Besitzen Unternehmen bereits existierende Anwendungen, die auf J2EE oder Windows DNA basieren, so stellt sich die Frage nach der Portierbarkeit auf eine neue Plattform.

Da neue Fähigkeiten und APIs in J2EE immer nur eine Erweiterung der bereits bestehenden sind (z. B. JCA oder Web Services), sollte die Migration keine größeren Probleme ergeben.

.NET unterstützt zwar noch Anwendungen, die auf älternen Technologien wie COM+ aufbauen, aber nur als sogenannten „unmanaged code“, der nicht die vollen Fähigkeiten des .NET-Frameworks besitzt. Deshalb muß zwangsläufig älterer Code angepasst oder schlimmstenfalls neu geschrieben werden.

Portabilität

Einer der wichtigsten Unterschiede zwischen J2EE und .NET ist die Plattformunabhängigkeit von J2EE, welches auf einer großen Spanne von Hardware und Betriebssystemen eingesetzt werden kann und wird. J2EE ist für jede Plattform erhältlich, für die eine JRE existiert.

Ein zweiter Punkt und wichtigerer Aspekt bei J2EE ist jedoch, daß J2EE ein Standard ist und die einzelnen Hersteller eigene Produkte nach diesem entwickeln. Die Gefahr liegt nun darin, daß diese Produkte sich nicht strikt an den Standard halten oder diesen um eigene Eigenschaften erweitern. Um dies zu verhindern, entwickelte Sun einen Kompatibilitätstest, anhand dem Hersteller ihre Produkte zertifizieren können, was die Portabilität von Anwendungen garantiert.

.NET akzeptiert als Betriebssystem nur Windows und ist auch eng mit diesem verzahnt. Somit kann es nur auf Hardware eingesetzt werden, die auch von Windows unterstützt wird. Es ist sehr unwahrscheinlich, daß Microsoft eine Portierung des .NET Frameworks auf andere Plattformen plant.

Unterstützung von Web Services

Im Gegensatz zu Sun hat Microsoft bereits sehr früh die Bedeutung von Web Services erkannt und konsequent seine .NET-Plattform darauf aufgebaut. Dies ermöglicht eine schnelle Entwicklung von neuen Web Services und die Anbindung von bestehendem Code, unterstützt durch die von Microsoft Produkten bekannten Assistenten.

In J2EE wird die Intergration von Web Services durch die neu hinzugekommene „Java API for XML Parsing“ (JAXP) und weitere, auf dieser aufbauenden APIs, realisiert.

In J2EE sind Web Services nicht so tief integriert wie in .NET, sondern nur eine weitere API, die bei der Erstellung von Komponenten verwendet werden kann. Dadurch ist die Verwendung von Web Services noch nicht so komfortabel wie dies in .NET der Fall ist.

Entwicklungswerkzeuge

Sowohl in .NET als auch in J2EE ist es kaum noch möglich Projekte, ohne die entsprechende Unterstützung durch Entwicklungswerkzeuge zu realisieren.

Neben den vielen erhältlichen Programmierumgebungen wie IBM's VisualAge oder Borland's JBuilder, bietet Sun mit dem Sun ONE Studio eine eigene Entwicklungsumgebung an. Dieses aus Forte für Java und NetBeans hervorgegangene Werkzeug orientiert sich jedoch stark an dem eigenen Sun ONE ApplicationServer 7 sowie einigen weiteren etablierten Applikationsservern.

Microsoft bietet passend zu .NET ein VisualStudio.NET, das alle Sprachen der .NET Plattform inklusive des neuen C# unterstützt.

Für .NET ist die Auswahl an Entwicklungswerkzeugen bei weitem nicht so vielfältig wie für J2EE, jedoch sind die Werkzeuge bei J2EE sehr stark an die jeweiligen Applikationsserver der Hersteller gebunden, was einen Austausch dieser erschwert.

Anschaffungskosten

Genauso groß wie das Angebot an Applikationsservern, welche auf J2EE basieren, ist auch der Preisspielraum dieser Angebote. Dieser Umstand ermöglicht es Unternehmen, aus dieser Spanne ein geeignetes Produkt, das ihrem Budget und Bedarf an Beratung nahe kommt, zu wählen.

J2EE unterstützt sowohl UNIX/Linux als auch Windows als Betriebssystem, wobei Windows die in der Regel günstigere Alternative ist.

.NET ist bislang nur für Windows verfügbar und es gibt keine Anzeichen dafür, daß sich dies in nächster Zeit ändern sollte. Zusammen mit Microsoft's aggressiver Preispolitik sorgt dies für günstige Lösungen.

Wichtig ist jedoch festzuhalten, daß die Anschaffungskosten der einem Projekt zugrunde liegenden Plattform im Gegensatz zu den Gesamtkosten des Projekts nur einen geringen Teil ausmachen und deshalb nicht den ausschlaggebenden Grund für die Entscheidung zwischen .NET und J2EE ausmachen sollten.

Performance

Eine Anwendung wird als performant bezeichnet, wenn sie unter einer bestimmten Nutzerlast eine akzeptable Antwortzeit bietet. Was genau aber unter „akzeptabel“ zu verstehen ist, hängt von der einzelnen Anwendung ab.

Das größte Problem bei Enterprise Anwendungen, die stark datenorientiert sind, bilden Datenbankzugriffe.

J2EE bietet hierfür einige Strategien zur Vermeidung dieses Problems und auch die verschiedenen Hersteller von J2EE Architekturen bieten spezifische Lösungen dieses Problems, welche vom Programmierer allerdings ein tieferes Verständnis derselben verlangen. Dafür bieten sie allerdings auch eine größere Kontrolle über das System.

.NET bietet keine Unterstützung für diese Strategien auf der Programmierebene, was hingegen allerdings den Vorteil bringt, daß Entwickler dadurch auch keine Fehler in das System einbringen können.

Skalierbarkeit

Eine Plattform wird als skalierbar bezeichnet, wenn eine Erweiterung der Hardware direkt einer Erhöhung der Zahl der gleichzeitig unterstützten Benutzer bewirkt.

Skalierbarkeit ist einer der wichtigsten Aspekte für geschäftskritische Software, da nur selten vorausgesagt werden kann, wie sich neue Geschäftsziele auf die Anzahl der Benutzerzugriffe auswirken wird.

Das zugrunde liegende Betriebssystem spielt in diesem Zusammenhang nur eine untergeordnete Rolle, so daß hier weder J2EE noch .NET einen klaren Vorteil haben. Beide erlauben es, zusätzliche Anwendungsserver hinzuzufügen, um durch Lastverteilung die Antwortzeiten zu erhöhen.

Der einzige Unterschied zwischen beiden besteht nur in der Tatsache, daß .NET eine höhere Anzahl an Anwendungsservern benötigt, um dieselbe Antwortzeit wie J2EE zu garantieren, da es nur Windows unterstützt und dieses die Anzahl der Prozessoren pro Anwendungsserver einschränkt.

2.2 J2EE als Plattform für myEspresso.net

Ausschlaggebend für den Einsatz von J2EE als Plattform für myEspresso.net ist vor allem die größere Marktdurchdringung dieser Architektur.

J2EE hat in vielen Einsatzszenarien und Projekten seine Eignung für geschäftskritische Anwendungen bewiesen, was für .NET, während der Entscheidungsphase nur als Beta-Release erhältlich war, nicht gilt.

J2EE ist nur ein Teil der Java Plattform, die von Sun für die Softwareentwicklung angeboten wird. Neben J2EE, das für die Entwicklung von serverseitigen Unternehmensanwendungen gedacht ist, existieren noch die „Java 2 Standard Edition“ (J2SE) und die „Java 2 Micro Edition“ (J2ME), wobei jede dieser eine Teilmenge der nächstgrößeren ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Java Plattform

Die Java 2 Standard Edition ist eine Sammlung von APIs, Werkzeugen und Compilern, die eine möglichst einfache und effiziente Entwicklung von Anwendungen ermöglichen soll. Weiterhin ist eine „Java Virtual Machine“ (JVM) Teil der J2SE, die jedoch für jede Ausführungsumgebung (Betriebssystem, Hardware) eigens angepasst werden kann und so die Plattformunabhängigkeit der Sprache Java garantiert.

Die Java 2 Micro Edition ist die Plattform für Embedded Devices wie Set-Top-Boxen, Mobiltelefone, PDAs und ähnliche Geräte, die nur über geringe Leistungsfähigkeit und und eingeschränkte Ressourcen verfügen.

Die Aufteilung der Java Plattform auf diese drei Versionen erlaubt es, diese sehr flexibel an die Anforderungen der genutzten Hardware bzw. der Umgebung anzu-passen. Möglich wird dies durch eine Einschränkung / Erweiterung der verschie-denen APIs oder durch gezielten Austausch dieser durch andere, besser angepass-te.

Sun unterstützt somit das gesamte Spektrum der Anwendungsentwicklung, angefangen von mobilen Endgeräten oder Webanwendungen über normale Desktop Anwendungen bis hin zu den Unternehmensanwendungen.

Für Entwickler bedeutet das, daß sie ohne einen Wechsel in der Programmiersprache in allen diesen Bereichen arbeiten können und auch das Zusammenspiel der unterschiedlichen Anwendungen gewährleistet ist.

Dies ist auch einer der wichtigsten Gründe für die Wahl von J2EE als Plattform für myEspresso.net.

Für die mobilen Endgeräte kommt dementsprechend auch nur J2ME als Plattform in Frage, was allerdings auch ganz praktisch dadurch begründet ist, daß für das konkurrierende Produkt WindowsCE.NET, noch keine Geräte erhältlich sind, welche den Anforderungen von myEspresso.net entsprechen.

Weitere Gründe für die Wahl von J2EE sind unter anderem die, wie oben schon beschrieben, bessere Integration in bestehende Legacy Anwendungen wie SAP über die Java Connector Architecture und das breitere Angebot an Werkzeugen der verschiedenen Hersteller.

2.3 Sun ONE als Plattform für myEspresso.net

Wie vorher schon beschrieben, handelt es ich bei J2EE nur um eine Sammlung von Spezifikationen und nicht um ein konkretes Produkt.

Viele Hersteller haben eigene Applikationsserver anhand der J2EE Spezifikation entwickelt. Die Auswahl reicht von High-End Lösungen wie z. B. WebSphere von IBM, WebLogic von Bea oder kostenlosen Produkten wie JBoss. Ein Vergleich verschiedener Applikationsserver ist auf „theserverside.com“ ([Matrix03]) zu finden.

Leider hat diese Vielfalt an Produkten den Nachteil, daß diese teilweise inkompa-tibel untereinander sind, da die Hersteller, um sich am Markt behaupten zu können, eigene Erweiterungen in Bereichen vornehmen, die durch J2EE nicht ge-nau spezifiziert sind. Um diesem Problem vorzubeugen, bietet Sun neben der Spezifikation auch eine Referenzimplementierung und eine Test Suite an, anhand derer Anwendungen für J2EE zertifizierbar sind. Für die Auswahl eines Applika-tionsserver empfiehlt es sich deshalb, auf diese Zertifizierung zu achten.

myEspresso.net setzt auf dem von Sun propagierten „Sun Open Net Environment“ (Sun ONE) auf. Dieses besteht nicht nur aus einem Applikations-server, sondern aus einer ganzen Reihe von Werkzeugen, Spezifikationen und Richtlinien, welche die Entwicklung von Unternehmensanwendungen unterstützen und vereinfachen sollen.

2.3.1 Sun Open Net Environment (Sun ONE)

Sun Open Net Environment ist Sun's Vision einer neuen Art von Softwareentwicklung:

„Sun Open Net Environment (Sun ONE) is Sun's standards-based software vision, architecture, platform, and expertise for building and deploying Services on Demand. It provides a highly scalable and robust foundation for traditional software applications as well as current Web-based applications, while laying the foundation for the next-generation distributed computing models such as Web services.“⁶

Sun ONE basiert auf J2EE und soll einen einfachen Weg bieten, um bestehende Enterpris Anwendungen in voll integrierte Lösungen zu verwandeln. Entwickler profitieren vor allem von der großen Anzahl bereits vorhandener Dienste und den zugehörigen Technologien, die eine schnelle und kostengünstige Entwicklung von Applikationen ermöglichen.

Prägend für Sun ONE ist der Begriff „Services on Demand“, der „anytime computing, anywhere, to anyone, using any device“, also die völlige Unabhängigkeit von Ort, Zeit und Gerät, ausdrücken soll.

Grundstein der „Services on Demand“ ist die durchgängige Anwendung der Programmiersprache Java auf allen Ebenen der Entwicklung, angefangen von der Enterprise-Schicht in Firmen über Standalone-Clients und Web-Applikationen bis hin zu mobilen Geräten.

Dies garantiert, daß es keinen Bruch der Paradigmen auf den unterschiedlichen Plattformen gibt und somit bestehendes KnowHow weiterverwendet werden kann.

Vision

Unternehmen verwenden verschiedenste Systeme, Anwendungen und Services, um sich wirtschaftlichen Herausforderungen zu stellen und Geschäfte zu betreiben. Die Möglichkeiten des Internet wurden dabei längst erkannt und Strategien für seinen nutzbringenden Einsatz und für internetbasierten Geschäftsverkehr entwickelt und implementiert.

Das neue Zeitalter der Informationstechnologie ist gekennzeichnet durch ein servicebasiertes Modell, bei dem nicht mehr monolithische Anwendungen, „Fat Clients“ oder komplexe Client/Server Anwendungen im Vordergrund stehen. Benötigt werden webbasierte Dienste, auf die Anwender zu jeder Zeit, von jedem Ort und von jedem Gerät aus zugreifen können.

Der Benutzer erwartet künftig weit mehr von solchen Diensten, z. B. daß diese sich an Umgebungssituationen seines Standorts orientieren. Oder daß er seine „Dienstleistung“ entsprechend an die Identität, Rolle und Präferenzen des Benutzers anpasst.

Um diesen Herausforderungen begegnen zu können, benötigen Unternehmen eine Infrastruktur, die ihre heutige IT Umgebung mit lokalen Anwendungen, Client/Server-Umgebungen und Webanwendungen einschließlich der Integration von Backend- und Legacy Systemen unterstützt. Zugleich muss diese Infrastruktur aber auch eine Plattform für künftige webbasierte Dienste sein.

Vision und Ziel von Sun Microsystems ist, Informationen, Daten und Applikationen für alle Anwender jederzeit, überall und auf jedem Endgerät bereitzustellen.⁷

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Sun ONE – Architektur (aus: [Su03b])

Die Sun ONE Architektur ermöglicht Unternehmen einen auf ihre geschäftlichen Anforderungen abgestimmten Einsatz von Services on Demand. Mit Hilfe des DART Modells können sie nicht nur die unternehmenseigenen Informationsbestände analysieren, sondern auch definieren, welche Architektur benötigt wird, um diese Bestände in Form von Diensten produktiv einzusetzen.

DART steht für Daten, Applikationen, Reports und Transaktionen. Diese DARTS stellen das Informationskapital eines Unternehmens dar und können über eine Softwareplattform für die jeweiligen Geschäftsanforderungen und -ziele des Unternehmens genutzt werden.

Diese Architektur ist

- hochgradig skalierbar und kann der Servicenachfrage (24 x 365 Verfügbarkeit) auch dann gerecht werden, wenn der Verkehr exponentiell wächst und neue Dienste eingesetzt werden. Weil jede Innovation einer Website auch höhere Anforderungen an die Architektur stellt, erweist sich die Skalierbarkeit als komplexe Interaktion zwischen dem Verkehrsaufkommen, der Anzahl angebotener Dienste und der potentiellen Interaktionen durch die Besuche.
- darauf ausgerichtet, maßgebliche Standardisierungsinitiativen wie etwa SOAP, J2EE, UDDI, LDAP und ebXML zu unterstützen. Sie bietet damit ideale Voraussetzungen für Entwickler, die von der Services on Demand Vision profitieren möchten.
- integrierbar, denn sie basiert auf offenen Standards und Technologien.
Diese sichern die Interoperabilität heterogener Plattformen, Systeme sowie Umgebungen und verhindern, dass sich der Kunde an einen einzigen Anbieter binden muss.⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Sun ONE – Plattform (aus: [Su03b])

Die Sun ONE Plattform erleichtert Kunden die produktive Nutzung ihrer Informa-tionsbestände in Form von Diensten und beschleunigt die Bereitstellung von On-line-Diensten.

Die Sun ONE Plattform ist die konkrete Implementierung der Sun ONE Architektur mit Technologien und Produkten von Sun Microsystems. Dabei wurden die bisherigen Markennamen iPlanet, Forte und Chili!Soft unter dem Sun ONE Branding zusammengefasst.

Diese Produkte bilden gemeinsam die Sun ONE Plattform. Zwei ihrer wichtigsten Vorteile klingen zum Verwechseln ähnlich, sind aber unterschiedlich:

- Integriert: Die Sun ONE Produkte der Plattform wurden im Hinblick auf Geschwindigkeit und Effizienz für den gemeinsamen Einsatz mit anderen Sun ONE Technologien der Plattform optimiert. So kann man zum Beispiel durch die Kombination des Sun ONE Directory mit dem Sun ONE Portal die Benutzerauthentifizierung und Personalisierung beschleunigen, da sich die Stärken beider Produkte gegenseitig ergänzen.

- Integrierbar: Weil die Sun ONE Plattform auf offenen Standards basiert, können bisherige Systeme nach wie vor einsetzt werden und in Zukunft neue Add-Ons ergänzen. Wenn beispielsweise Apache als Applikationsserver eingesetzt wird und mit der Skalierbarkeit oder anderen Eigenschaften keine Probleme auftreten, kann er auch während der Implementierung neuer Sun ONE Bestandteile weiterhin genutzt werden.

Expertise

Neben Architektur, Plattform und Richtlinien für die Implementierung bietet Sun Consulting Services an, bei denen Experten den Unternehmen bei Konzeption, Implementierung und Management zur Seite stehen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Sun ONE - DART Modell (aus: [Su03c])

Die Architektur muss in der Lage sein, Daten so zu präsentieren und zu sammeln, daß sie von jeder angestrebten Ziel-Communities sinnvoll genutzt werden können.

Solche personalisierten Inhalte werden über Portale bereitgestellt. Die Steuerung des Benutzerzugriffs auf die Informationen erfolgt durch Verzeichnisse, die über alle Benutzerdaten verfügen: Sie wissen, wer wer ist, welche Berechtigungen der Einzelne besitzt und mit welchem Bereich eines Unternehmens er zu tun hat.

Applikationen:

Moderne Applikationen sind meist Java-basiert und sind auf einem J2EE Applikationsserver ablauffähig. Der Server verbindet vorhandene Datenbanken und Applikationen, so daß auch auf Legacy Komponenten zugegriffen werden kann. Der Applikationsserver bietet unverzichtbare Voraussetzungen für eine 24 x 7 Verfügbarkeit angesichts einer exponentiellen Zunahme des Webverkehrs und der Realisierung neuer Dienste.

Reports:

Es ist absolut wichtig, die Nutzung und den Stellenwert der angebotenen Dienste zu überwachen. Über einen schnellen Webserver-Zugriff liefert Sun ONE Reports für diese Überwachung.

Transaktionen:

Transaktionen stellen sicher, daß Communities die verfügbaren Informationsbestände sinnvoll einsetzen können. Zum Beispiel für den Kauf, den Verkauf, die Abrechnung und den Handel mit Produkten und Dienstleistungen, für die Kommunikation sowohl innerhalb der Community als auch nach draußen und für die Steigerung der Effizienz bei täglich anfallenden Routineaufgaben.⁹

2.3.2 Sun ONE bei myEspresso.net

Wie in Abbildung 5 erkennbar, ist die zentrale Komponente der Sun ONE Plattform der Applikationsserver. Dieser dient als Container für Unternehmensanwendungen und bietet Dienste und Schnittstellen zu weiteren Servern, welche die Anwendung unterstützen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Service Stack einer Anwendung (aus: [SUNArchGuide2002])

Wie die meisten Anwendungen dieser Art, kann man auch bei myEspresso.net eine grobe Unterteilung anhand der Zuständigkeiten vornehmen. Bei Sun ONE wird diese Unterteilung als „Service Stack“ (siehe Abbildung 7) bezeichnet. Dieser beschreibt jedoch nicht nur die Anwendung, sondern auch alle weiteren daran beteiligten Komponenten wie vorhandene Server und das Betriebssystem.

Plattform:

Die unterste Ebene von myEspresso.net bildet das Betriebssystem Solaris 9 auf einer SunBlade 100 Workstation. Zusätzlich dazu existiert noch ein Datenbankserver mit Oracle 9i, der ebenfalls unter Solaris 9 läuft. Diese Konfiguration kann jedoch durch jede andere ersetzt werden, für die eine Java Runtime Environment existiert (z. B. Windows oder Linux auf x86). Auch die Datenbank kann gegen eine andere ausgetauscht werden.

Identity and Policy:

Diese Schicht dient der Rechte- und Benutzerverwaltung für myEspresso.net. Hier kommt der Sun ONE Directory Server 5.1 zum Einsatz, der über das „Lightweight Directory Access Protocol“ (LDAP) angebunden wird. Auch hier kann jeder andere Directory Server, der auf LDAP basiert (wie z. B. Novel eDirectory oder OpenLDAP) verwendet werden.

Service Creation, Assembly and Deployment:

Die oberste Schicht des Service Stacks bildet die Schnittstelle für Entwicklung und Installation von Anwendungen für die Sun ONE Plattform und besitzt somit keine Bedeutung für den Betrieb dieser Anwendungen.

Die Sun ONE Plattform bietet hier das Sun ONE Studio als komplett integrierte Entwicklungsumgebung an. Jedoch kamen bei der Entwicklung von myEspresso.net einige andere Werkzeuge zum Einsatz:

- In Design- und Analysephase TogetherJ von TogetherSoft
- Als Entwicklungsumgebung Oracle Jdeveloper
- Für Kompilation und Deployment eine eigene, auf ANT basierende

Lösung

Im Zentrum des Service Stacks befinden sich nun drei Schichten, die dem Programmierer als Präsentationslogik, Geschäftslogik und Datenhaltungslogik bekannt sind.

Service Delivery:

Die Service Delivery Schicht entspricht der Präsentationsschicht einer Anwendung. Bei J2EE-Applikationen ist diese Schicht sehr stark von der eigentlichen Geschäftslogik getrennt, was sogar soweit geht, daß nicht einmal der Applikationsserver die Aufgabe der Darstellung übernehmen muss. Die Sun ONE Plattform stellt für die Realisierung dieser Schicht den Sun ONE Portal Server zur Verfügung. Mit ihm kann der Entwickler bei der Erstellung der Benutzerschnittstelle auf einige Dienste zurückgreifen:

- Darstellung personalisierten Inhalts, abhängig von Gerät und Umgebung
- Zusammenführung von Inhalt und Diensten
- Synchronisation
- Sichere Kommunikation zwischen Client und Server
- Auslieferung von Anwendungen über das Java Web Client Modell
- Framework für die schnelle Entwicklung von Webanwendungen

myEspresso.net verzichtet im Moment noch auf die Verwendung eines Portal Server, in einer späteren Ausbaustufe können sich aber durchaus Gründe für den Einsatz eines solchen ergeben.

Service Container:

Der Service Container besteht aus einem Applikationsserver auf Basis der J2EE-Spezifikation wie vorher beschrieben. Er stellt die Laufzeitumgebung für die Geschäftslogik bereit. Bei myEspresso.net kommt hier der Sun ONE Application 7 zum Einsatz.

Service Integration:

In dieser Schicht wird die Anbindung der Unternehmensanwendungen an bestehende Legacy Systeme wie Datenbanken oder ERP Systeme realisiert. Hierzu werden Technologien wie JDBC, JCA und Web Services verwendet. Umfangreiche und komplexe Anbindungen können durch den Sun ONE Integration Server realisiert werden, der jedoch in myEspresso.net nicht genutzt wird.

2.3.3 Gründe für den Einsatz von Sun ONE

Die Entscheidung für Sun ONE als Plattform für myEspresso.net beruhte zum einem auf den vorhandenen Gegebenheiten wie Hardware und Betriebssystem, zum anderen aber auch auf technischen und praktischen Gründen.

Die verfügbare Hardware für das Projekt bestand aus einer SunBlade 100 Workstation, die im Lauf der Arbeit an myEspresso.net mit Speicher und Festplattenplatz aufgerüstet werden konnte. Auf dieser Workstation wurde eine komplette Sun ONE Umgebung installiert, angefangen von Solaris 9 als Betriebssystem und einem Java 2 SDK 1.4.0, welches später noch auf das SDK 1.4.1 aktualisiert wurde.

Solaris 9 enthält im Installationsumfang bereits den Sun ONE Application Server 7 und den Sun ONE Directory Server 5.1. Diese kamen aber nicht zum Einsatz, da die Firma Sun für Entwickler ein Softwarepaket zur Verfügung stellt, welches eine Auswahl des jeweils aktuellen Produktspektrums inklusive Entwicklerlizenzen enthält.

Somit war es möglich, einen kommerziellen Applikationsserver zu verwenden, der im Gegensatz zu anderen Produkten wie IBM WebSphere oder Bea WebLogic auch eine einfachere Installation und Administration bietet.

Außerdem ist der Sun ONE Application Server in der Version 7 nicht nur eine Überarbeitung der vorhergehenden Versionen (letzte Version IPlanet Application Server 6.5), sondern eine komplette Neuentwicklung, die sich sehr stark an der J2EE Spezifikation und Referenzimplementierung orientiert. Er beinhaltet auch die neue EJB 2.1 Spezifikation und die Unterstützung für XML Verarbeitung und Web Services.

Wie für alle Produkte von Sun ONE existiert für den Directory Server und den Application Server eine sehr gute Dokumentation, angefangen von der Installation, weiter über Integration anderer Systeme und der Administration. Dies stellt auch einen der wichtigsten Gründe für die Wahl von Sun ONE als Plattform für myEspresso.net dar.

3 Architektur und Technologien

Dieses Kapitel beschreibt die grundlegende Struktur von myEspresso.net und die für die Entwicklung eingesetzten Technologien.

³.1 myEspresso.net Übersicht

myEspresso.net ist als ein typisches Beispiel einer E-Commerce Anwendung geplant worden, um daran die Anforderungen und Probleme bei Design und Entwicklung einer solchen zu erkennen. Außerdem sollten aktuelle Technologien eingesetzt werden, um deren Nutzen und Anwendung zu erproben.

myEspresso.net bietet verschiedene Dienste, die vor allem auf mobile Nutzer aus-gerichtet sind. Neben diesen Diensten erfordert myEspresso.net auch eine Benutzerverwaltung, die Abrechnung der Dienstnutzung sowie Protokollierung von auftretenden Fehlern. Hierfür wurde eine webbasierte Bedienoberfläche ge-schaffen, die neben der Administration dem Kunden auch eine Einsicht in seine Abrechnungen ermöglicht.

Außerdem ist myEspresso.net für eine einfache Integration von Schnittstellen zu anderen Systemen entworfen worden, um den Einsatz in Unternehmen zu ermöglichen.

3.1.1 Entwicklungsanforderungen

Für die Entwicklung von Enterprise Anwendungen ist es erforderlich, einige Ziele zu definieren (vgl.: [Pet03]):

- Code- und Design-Wiederverwendung

Wiederverwendung von Codefragmenten reduziert die Entwicklungskos-ten und erhöht die Qualität der Software. Design-Wiederverwendung ga-rantiert die Nutzung von optimalen und bewährten Verfahren in der Soft-wareentwicklung. Erleichtert wird die Einhaltung dieser Vorgabe vor allem durch den komponentenorientierten Aufbau von myEspresso.net.

- Zerlegung der Aufgaben in wohldefinierte Teile

Jedes Modul hat eine klar definierte Aufgabe in der Anwendung. Daraus resultiert ein klares Design, das Wartung und Erweiterung der Anwendung vereinfacht. Zudem verkürzt sich die Einarbeitungszeit für neue Entwickler.

- Aufteilung der Entwicklung nach Fähigkeiten der Programmierer

Entwickler werden für Module der Anwendung eingesetzt, die ihren Fä-higkeiten entsprechen. So kann sich jedes Projektmitglied bei myEspresso.net auf seinen Teilbereich konzentrieren und sich dort einarbeiten.

- Modularität

Durch die Definition exakter Schnittstellen der einzelnen Module kann die zeitliche Abhängigkeit der Entwicklung reduziert werden. Die Entwickler können so unabhängig von einander arbeiten und testen. Verstärkt wird dieser Effekt noch durch die Architektur und den Nach-richtenfluß in myEspresso.net (siehe Kapitel 5: Analyse und Design)

- Erweiterbarkeit

Die Anwendung muss fähig sein, mit Wachstum und neuen An-

forderungen des Unternehmens Schritt zu halten, d. h. leicht erweiterbar sein. Auch hier unterstützen Komponentenorientierung und Architektur myEspresso.net.

- Sicherheit

Da es sich bei myEspresso.net um eine geschäftskritische Applikation handelt, ist entscheidend für die Sicherheit der Daten von Nutzern und Unternehmen Sorge zu tragen. Hier wird die Anwendung durch die Dienste, welche die Applikationsserver bieten, unterstützt.

- Reduktion des Netzverkehrs

Da gerade dieser Punkt die Performanz einer Anwendung stark be- einflusst, sollte die Menge der Daten, die über eine Netzwerkverbindung transportiert wird, möglichst gering gehalten werden. Erschwerend kommt für myEspresso.net hinzu, daß es sich bei den Clients um mobile Geräte handelt. Diesem Punkt wird durch Design und der Verwendung von Web Services bei myEspresso.net Rechnung getragen.

- Multiple Benutzeroberflächen

Die Präsentationsschicht der Daten sollte sich bestmöglich an die Gegebenheiten der Anwendung und des Clients anpassen. Das macht es notwendig, daß neue Benutzerschnittstellen einfach integrierbar sind. Gerade bei myEspresso.net mit seiner Ausrichtung auf mobile Endgeräte ist dieser Punkt sehr wichtig, da nur so auf neue Entwicklungen in diesem Bereich reagiert werden kann.

- Konsistente Datenhaltung

Auch hier kann sich die Anwendung zumindest zum Teil auf die Fähigkeiten des Applikationsserver verlassen. myEspresso.net erfüllt diese Anforderungen durch die Trennung von Präsentation, Verarbeitung und Datenhaltung. Dies geschieht durch Aufteilung in spezialisierte Module, verschiedene Schichten und die Verwendung von bewährten Design-Patterns.

3.1.2 Systemübersicht

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: myEspresso.net - Systemübersicht

myEspresso.net ist nicht nur ein akademisches Projekt, welches den Einsatz von neuen Technologien erproben soll, sondern hat den durchaus ernst gemeinten Hintergrund einer Nutzung in Unternehmen oder im Einsatz bei Privatkunden.

Deshalb stellte sich das Problem, für den mobilen Bereich nutzbare Anwendungen zu finden. Dies ist insbesondere deshalb wichtig, da in den letzten Jahren beobachtet werden konnte, wie schwierig es ist, eine „Killerapplikation“ für mobile Geräte zu entwickeln. Obwohl viele Firmen in diesem Bereich Anwendungen vorgestellt haben, ist die einzig, die ein Erfolg wurde, der „Short-Message-Service“ (SMS), eher unbeabsichtigt entstanden. Weitere Entwicklungen wie das „Wireless-Application-Protocol“ (WAP) und „iMode“, beides Versuche, das Internet auch für den Mobilfunk zu erschließen, schlugen mehr oder weniger fehl.

Neben den technischen Gegebenheiten wie Benutzeroberfläche und nur eingeschränkter Übertragungsleistung, lag der Grund für das Fehlschlagen wohl auch im Sinn oder Unsinn der angebotenen Dienste.

Um sinnvolle Dienste zu finden, ist es wichtig, Benutzergruppen zu definieren, für die die Unterstützung durch ein mobiles Gerät eine Erleichterung oder einen Mehrwert im täglichen Leben bringt.

Für myEspresso.net haben sich zwei große Benutzergruppen herauskristallisiert:

- Zur ersten Gruppe gehören Privatanwender, die die Möglichkeit nutzen, die Fähigkeiten ihres Mobiltelefons um verschiedene Dienste zu erweitern. Beispiele für diese Dienste sind ein Übersetzerservice, Währungsumrechnung oder Zugriff auf aktuelle Nachrichten. Diese Dienste könnten dann zum Beispiel von Mobilfunkprovidern oder auch von unabhängigen Unternehmen angeboten werden.
- Die zweite Gruppe sind Außendienstmitarbeiter, denen myEspresso.net einen direkten Zugriff auf Daten und Dienste des Unternehmens erlaubt. Beispiele für Dienste reichen von trivialen Anwendungen wie dem Buchen der Arbeitszeit oder dem Führen von Fahrtenbüchern bis zum Zugriff auf interne Messagedienste und Terminkalendern oder komplexen Unternehmensdaten.

Um die Anforderungen dieser beiden Nutzergruppen in einem Prototypen

abdecken zu können, werden von myEspresso.net eine Reihe von exemplarischen Diensten angeboten:

Privatanwender

- Währungsumrechnung
- Übersetzerservice

Außendienstmitarbeiter

- Fahrtenbuch
- Terminverwaltung
- Auftragsbearbeitung

Neben der Bereitstellung dieser Dienste für den Benutzer sind noch weitere administrative Dienste für den Betrieb von myEspresso.net nötig:

- Abbrechnung
- Logging
- Benutzerverwaltung
- Diensteverwaltung
- Administration

Jeder Dienst wird duch einen sogenannten Manager realisiert. Diese Manager sind die Grundbausteine von myEspresso.net und realisieren die Funktionalität durch ihr Zusammenspiel untereinander sowie durch die Anbindung an externe Ressourcen.

Diese Stukturierung macht es möglich, die Funktionalität von myEspresso.net beliebig zu erweitern. Soll ein neuer Dienst eingeführt werden, muß dazu nur der entsprechende Manager entwickelt werden.

Dadurch könnte myEspresso.net individuell an die Bedürfnisse eines Kunden angepasst werden und auch optimal in bestehende Systeme integriert werde.

Folgende Manager kommen bei myEspresso.net in der jetzigen Ausbaustufe zum Einsatz:

- UserManager

Verwaltung der Benutzerdaten und -rechte

- ServiceManager

Verwaltung der Dienste

- PortfolioManager

Verwaltung des Diensteportfolios der Benutzer

- LoggingManager

Logging der Dienstaufrufe durch die Benutzer

- BillingManager

Erstellung der Abrechnungen

- CalendarManager

Terminverwaltung für Benutzer

- Fieldmanager

Zugriff auf Firmendaten durch Außendienstmitarbeiter

- Fahrtenbuch

Fahrtenbuch für Außendienstmitarbeiter

- CurrencyConverter

Währungsumrechnung

- ErrorManager

Logging von Fehlern

- AdminModul

Webbasierte Administration

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: myEspresso.net – Beispiele für Manager

Die für den Anwender nutzbare Funktionalität wird nicht von myEspresso.net selbst angeboten. Vielmehr vermittelt myEspresso.net als zentrale Instanz Anfragen an bestehende Systeme weiter und ermöglicht so den Einsatz von mobilen Endgeräten für den Zugriff auf bestehende Firmendaten oder Dienste. Um die Fähigkeiten von myEspresso.net aufzuzeigen, werden beispielhaft einige Manager implementiert, deren Anwendung im realen Einsatz in Unternehmen oder bei Privatanwendern auch von Interesse sein könnten.

3.2.1 Verwendete Sun ONE Komponenten

Sun ONE Application Server 7

Wie bereits anfangs erläutert, ist myEspresso.net eine komponentenorientierte Anwendung und benötigt deshalb einen Applikationsserver als Laufzeitumgebung. Die Gründe für die Wahl von Sun ONE Application Server 7 wurden im vorigen Kapitel bereits erläutert. Natürlich muß nicht zwingend dieser Server gewählt werden, da myEspresso.net auch auf allen anderen J2EE Applikationsservern lauffähig ist.

Der Applikationsserver bietet mit seinem EJB-Container die Umgebung für den aus EJBs bestehenden Teil von myEspresso.net an. Der mit integrierte Webserver bildet die Grundlage für das Administrationsmodul, das für die Verwaltung verwendet wird.

Sun ONE Directory Server 5.2

Auch die Verwaltung der Benutzerdaten orientiert sich bei myEspresso.net an einem realen Einsatz in Unternehmen. Dort werden schon seit Jahren sogenannte Verzeichnisdienste eingesetzt, auf die mit Hilfe des „Light-Weight-Directory-Access-Protocol“ (LDAP) zugegriffen wird.

Als Verzeichnisserver wir der Sun ONE DirectoryServer 5.2 eingesetzt, da er mit in der Produktpalette von Sun ONE enthalten ist und auch die größte Verbreitung im Markt besitzt.

Natürlich kann auch hier wegen der eingesetzten Standards jeder andere LDAPkompatible Verzeichnisdienst eingesetzt werden.

Zusätzlich zu den Benutzerdaten werden auch die Daten der einzelnen Dienste in LDAP abgelegt.

Der Einsatz eines Verzeichnisdienstes soll zudem zeigen, daß es ohne weiteres möglich ist, myEspresso.net an bereits existierende Benutzerverwaltungen in Unternehmen anzubinden.

Sun ONE Calendar Server 5.1

Viele Unternehmen setzen eine sogenannte „Groupware“ ein. Diese soll die Kommunikation der Mitarbeiter vereinfachen (siehe: [UsabillityFirst03]). Die einfachste Form von Groupware ist neben Email ein zentraler Kalender, in dem Termine vereinbart und abgeglichen werden.

Auch hier bietet die Sun ONE Plattform eine entsprechende Lösung, den Sun ONE Calendar Server 5.1.

Als Beispiel für die Anbindung von Groupware an myEspresso.net wird eine Schnittstelle zu dem Calendar Server geschaffen, die es auch mobilen Benutzern erlaubt, ihre Termine mit dem Firmenkalender abzustimmen. 2 Aus: [Gf98]3 Aus: [J2EE2001]

[...]

---

¹ Obwohl es vielleicht etwas übertrieben ist, für eine Diplomarbeit eine Danksagung zu schreiben, möchte ich es hier dennoch tun, weil ich einigen Leuten einfach für ihre Unterstützung danken muß (Außerdem, wann hat man sonst schon nocheinmal die Gelegenheit, eine Danksagung zu schreiben?).

² Aus: [Gf98]

³ Aus: [J2EE2001]

⁴ Aus: [J2EE2001]

⁵ Aus: [J2EE2001]

⁶ Aus: [Su02]

⁷ Übersetzt aus: [Su03a]

⁸ Übersetzt aus: [Su03b]

⁹ Übersetzt aus: [Su03c]