Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik. Hauptseminararbeit. Java-JMS für Smarthphones und mobile Geräte

Transkript

1 Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Hauptseminararbeit Java-JMS für Smarthphones und mobile Geräte vorgelegt von: Aalbrecht Alby Irawan eingereicht am: geboren am: Studiengang: Studienrichtung: Ingenieurinformatik Multimediale Informations- und Kommunikationssysteme Anfertigung im Fachgebiet: Kommunikationsnetze Fakultät für Elektrotechnik und Informationstechnik Verantwortlicher Professor: Wissenschaftlicher Betreuer: Prof. Dr. rer. nat. habil. Jochen Seitz Dipl.-Ing. Karsten Renhak

2 Kurzfassung Diese Hauptarbeit befasst sich mit Java Messaging Service. Am Anfang wird die Unterschiede zwischen 3 Java Platformen definiert. Dann wird über JMS erklärt und die Leistung verschiedener JMS-Provider verglichen.

3 Inhaltsverzeichnis i Inhaltsverzeichnis 1 Einleitung Verschiedene Java Platformen Java-VMs für Smartphones und mobile Geräte Java-JMS Übersicht Message Oriented Middleware Java Message Service Vergleich Java-JMS-Clientimplementierungen Prüfbedingungen Hardware- und Software-Konfiguration Test-Szenarien Testdauer Testergebnisse Auswertung Literaturverzeichnis 18 Abbildungsverzeichnis 19 Tabellenverzeichnis 20 Abkürzungsverzeichnis und Formelzeichen 21 Erklärung 22

4 1 Einleitung 1 1 Einleitung 1.1 Verschiedene Java Platformen Java Platform kann in 3 Bereiche aufgeteilt werden: Java 2 Standard Edition ist die Grundlage aller andere Java Platformen. Darin enthält sich die benötigte JVM und Bibliotheken, die beim normalen PC oder Workstation gebraucht wird. Java 2 Enterprise Edition ist die J2SE mit Addition von mehreren API, Container und Komponenten, die zur Entwicklung von Enterprise-Applikationen gebraucht werden. Die dient dazu, eine Leistung von Serverdienste zu ermoglichen. J2EE betriebene Server können web-basierte mobile Anwendungen (z.b. WML oder xhtml) dienen. Java 2 Micro Edition ist für mobile Geräte gedacht. Gehören dazu sind speziell angefertige VM und nur allerwichtigste oder eine leichtere Version von herkommlichen J2SE Bibliotheken Obwohl heutzutage die Smartphones oder PDA wesentlich größere Spezifikationen haben als in den vergangenen Jahren (und somit der Einsatz von J2SE ermögliche), benutzt man immer noch J2ME für moble Geräte. Laut einer Gartner Studie vom Jahr 2002 liegt die Totalentwicklungkosten von Smartphones etwa einzhentel billiger als die von Wireless Laptop und einviertel als die von Wireless PDA. Aufgrund der weltverbreiten Anwendungen gehört J2ME zu den wichtigsten mobile Platform. J2ME Um Portabilität mit Leistung und Durchführbarkeit, enthält J2ME mehrere Komponenten wie Konfiguration, Profil und optionale Pakete. Jede gültige Kombination aus Konfiguration und Profil ist auf einer bestimmten Art von Gerät gezielt. Die Konfiguration bietet die grundlegende und allgemeine Sprachfunktionalität. Das Profil hingegen

5 1 Einleitung 2 Abbildung 1.1: Java 2 Platform [Yuan04] basiert auf Konfigurationen und unterstützt erweiterte APIs wie grafische Benutzeroberfläche, Speicherung, Sicherheit und Netzwerk-Konnektivität. Die zwei wichtigste J2ME Konfigurationen sind: Connected Limited Device Configuration CLDC ist für kleine Geräte mit limitierten Rechenleistung und Arbeitsspeicher, braucht jedoch mindestens 160 KB Arbeitsspeicher und 16/32 Bit Prozessor. CLDC hat eingeschränkte math, string und I/O Funktion. Nur ein kleine Anteil von J2SE Kernbibliotheken kann vom CLDC Virtual Machine (in diesem Fall KVM oder Kilobyte Virtual Machine) eingestützt werden. Connected Device Configuration CDC ist für leistungsfähigere Geräte mit mindestens 2 MB Arbeitsspeicher und 32 Bit Prozessor. Im Gegensatz zu CLDC, CDC verfügt über Java VM und somit kann fast alle J2SE Bibiliotheken unterstützen. Das am meisten verwendeten Profil der J2ME ist Mobile Information Device Profile (MIDP), basiert auf CLDC und somit für Handys gut geeignet. Als MIDP v1.0 veröffentlich wurde, gab es noch viele Probleme, besonders bezüglich der Sicherheit und Benützeroberfläche. MIDP v2.0 bietet allerdings eine verbesserte Benutzeroberfläche, Multimedia und Spiel Möglichkeit, gesteigerte Konnektivität und Ende-zu-Ende- Sicherheit.[Yuan04] 1.2 Java-VMs für Smartphones und mobile Geräte Anders als andere Programmiersprache, wird nicht direkt Maschinencode erzeugt beim Kompilieren, sondern sogenannten Bytecode. Dieser Bytecode ist unabhänging von

6 1 Einleitung 3 Abbildung 1.2: J2ME Komponente [Yuan04] Hardware und vergleichbar mit Mikroprozessorcode für einen Prozessor, der Anweisungen wie arithmetische Operationen, Sprünge und weiteres kennt. Der Java-Compiler von Sun und der Java-Compiler der Entwicklungsumgebung Eclipse sind selbst in Java implementiert und generieren diesen Bytecode. Damit der Programmcode des virtuellen Prozessors ausgeführt werden kann. führt nach der Übersetzungsphase die Laufzeitumgebung (auch Runtime-Interpreter genannt), die Virtual Maschine (VM), den Bytecode aus. Somit ist Java eine compilierte, aber auch interpretierte Programmiersprache von der Hardwaremethode einmal abgesehen. [Ulle09] Für bestimmte Endgeräte gibt es auch bestimmte Konfiguration, die dafür spezifischen Anforderungen erfüllen. Man teilt dabei die VM in drei verschiedene Kategorien ein: Java Virtual Machine JVM ist die leistungsfähigste Virtual Machine und findet ihren Einsatz auf Servern, Workstations und Desktop PCs bzw. Notebooks. Auf diesen Systemen stehen ausreichend Ressourcen bereit, sodass eine vollständige Implementierung der JVM Spezifikation möglich ist. JVM unterstützt J2EE, J2SE und J2ME CDC. Kilobyte Virtual Machine KVM ist für die JVM Implementierung wichtig. Wegen des kleine Speicherplatzes werden manche Datentypen wie floats und doubles nicht unterstützt. Außerdem gibt es nur die wichtigsten Klasse wie java.lang, java.io und java.util. Ein weiteres Mittel, um den Speicherbedarf zu reduzieren

7 1 Einleitung 4 ist, dass Programme statt als Classdatei auch als Java Archiv (JAR) gespeichert werden können. Dies ermöglicht eine um 30 bis 50 Prozent höhere Kompression. Card Virtual Machine CardVM setzt sich dabei aus 1kB RAM und 24kB ROM zusammen. CardVM unterstützt sogar einen 8- oder 16-bit Prozessor. Um mit diesen extremen Speichereinschränkungen umzugehen werden nur boolean, byte, short, optional int und eindimensionale Arrays unterstützt. Auch alle für die Objektorientierung von Java notwendigen Features (z.b. Vererbung, Überladung von Methoden und dynamische Objek- terstellung) wurden implementiert. Die CardVM verfügt aber nicht mehr über den Class Loader, den Security Manager, Garbage Collector (meistens jedenfalls) und kennt auch keine Strings und Threads mehr. Auf einigen professionellen Java Cards ist jedoch ein Garbage Collector implementiert, welcher die Lebenszeit einer Karte deutlich erhöht. Karten ohne Garbage Collector können unbrauchbar werden, wenn irgendwann tote Objekte den Speicher belegen und keine neuen Objekte mehr erstellt werden können.[menz04] Abbildung 1.3: Übersicht der derzeit verfügbaren Virtual Machine [Sun 03]

8 2 Java-JMS 5 2 Java-JMS 2.1 Übersicht Mobile Nachrichtenvermittlungapplikationen haben sich extrem erfolgreich durchgesetzt, person-to-person Kommunikation zu unterstützen. Allerdings ist Nachrichtenvermittlung viel mehr als nur zwischen-menschliche Kommunikation. Die breite Nutzung von nachrichtenorientierte Middleware (engl. message oriented middleware MOM), wie z.b. Java Messaging Service (JMS), hat Nachrichtenvermittlung zu einer der wichtigsten modernen Enterprise-Anwendungen Message Oriented Middleware Message Oriented Middleware (MOM) ist eine Software- oder Hardware-Infrastruktur für das Senden und Empfangen von Nachrichten zwischen verteilten Systemen. MOM erlaubt, dass Programm-Module über heterogene Plattformen verteilt werden und reduziert die Komplexität der Entwicklung von Anwendungen, die mehrere Betriebssysteme und Netzwerk-Protokolle umfassen. Die Middleware schafft eine verteilte Kommunikationsschicht, dass der Anwendungs-Entwickler von den Details der verschiedenen Betriebssystem-und Netzwerk-Schnittstellen isoliert. APIs, die über verschiedene Plattformen und Netzwerke auszuweiten werden typischerweise durch MOM vorgesehen. MOM bietet eine Client / Server-Architektur und unterstützt in der Regel asynchrone Aufrufe zwischen Client und Server-Anwendungen. MOM reduziert die Beteiligung von Entwicklern mit der Komplexität der Master-Slave-Charakter der Client / Server- Mechanismus. MOM sollte die folgenden Eigenschaften haben: mehrere Client-Protokolle bedienen können Point-to-Point oder Publish-Subscribe Modelle Nachrichten speichern und weiterleiten

9 2 Java-JMS 6 Nachrichtenübermittlung bestätigen Schnittstelen für J2ME bieten Die fehlende Normung für die Verwendung von MOM kann allerdings Probleme verursachen. Alle großen Hersteller haben ihre eigenen Implementierungen mit jeweils ihrem eigenen API und Management-Tools. Die J2EE Programmierumgebung liefert zwar Standard-API namens Java Message Service (JMS), die von den meisten MOM Anbietern umgesetzt wird, aber JMS definiert nicht das Format der Nachrichten die ausgetauscht werden. Deshalb kann essein, dass JMS-Systeme nicht immer miteinander kompatibel sind Java Message Service JMS definiert eine API für den Zugriff auf die Dienste eines Messaging-Anbieter. Es definiert eine Standard-Schnittstelle für Java-Programme um Nachrichten zu erstellen, senden, empfangen und lesen. JMS ist eng mit der J2EE-Plattform gekoppelt. Die J2EE-Plattform besteht aus einer Reihe von Diensten, APIs und Protokolle, die die Entwicklung einer mehrstufigen Architektur unterstützen. Die Einbeziehung von JMS in J2EE bedeutet nicht, dass JMS nur mit J2EE basierten Anwendungen verwendet werden. Die Dienstleistungen des Messaging-Anbieter sind zugänglich für jede Java- Anwendung. [Yusu04] JMS definiert zwei Messaging-Domänen, Point-to-Point und Publish-Subscribe, zur Unterstützung der beiden üblichen Muster von Nachrichtenvermittlung. Eine Reihe von Schnittstellen sind für jede Domäne definiert, erben ihre Attribute und das Verhalten von einer Basis von Schnittstellen (Tabelle 2.1). Eine Anwendung wählt in der Regel eine Gruppe von Schnittstellen (Point-to-Point oder Publish-Subscribe), mit der sie arbeiten möchte. Common (Parent) Point-to-Point Publish-Subscribe ConnectionFactory QuueueConnectionFactory TopicConnectionFactory Connection QueueConnection TopicConnection Destination Queue Topic Session QueueSession TopicSession MessageProducer QueueSender TopicPublisher MessageConsumer QueueReceiver TopicSubscriber QueueBrowser Tabelle 2.1: Messaging Domäne Schnitstelle [Yusu04]

10 2 Java-JMS 7 Point-to-Point Hier schickt der Sender die Nachricht zu einer bestimmten Warteschlange und der Empfänger bekommt die Nachricht von derselben Warteschlange. Hier kennt der Sender das Ziel der Nachricht. Mehrere Sender und Empfänger können in eine Warteschlange angekoppelt sein, aber jede Nachricht wird nur einmal verbraucht. Sobald eine Nachricht an einem Empfänger übermittelt wird, ist sie von der Warteschlagen entfernt. Der Sender muss nicht gerade aktiv sein als die Nachricht empfängt wird und der Empfänger muss auch nicht gerade aktiv sein als die Nachricht gesendet wird. Point-to-Point ist in der Regel angenommen, wenn eine Applikation mit einer einzelnen Applikation oder eine kleine Anzahl von bekannten Applikationen komuniziert. Falls der Sender mehrere Empfänger erreichen will, muss er auch mehrere male die Nachricht senden. In den meisten Szenarien gibt es jedoch nur eine einzelne Empfänger. Abbildung 2.1: Point-to-Point Modell [Yuan04] Publish-Subscribe Hier ist das Ziel eine Topics. Das Thema definiert eine Katogerie oder eine Gegenstand, damit die Nachrichten in Verbindung gebracht werden können und die Empfänger soll vorher ihre Interesse an einem bestimmten Thema abonnieren. Gesendete Nachrichten zu einem Thema werden dupliziert und an alle Abbonenten dieses Thema weitergeleitet. Wenn ein Teilnehmer vorübergehend nicht verfügbar ist, wird der Server die Nachricht halten und versucht später noch einmal. Ein Sender kann ein neues Thema starten oder Nachricht senden zu einem schon vorhandenen Thema.

11 2 Java-JMS 8 Publish-Subscribe wird normalerweise verwendet, wenn Daten an mehrere Subscriber kommen sollen, die dynamisch ändern können. Die Verwendung ist auch sehr eng mit Event-gesteuerte Szenarien verbundet. In diesem Modell kennt außerdem weder Publisher noch Subscriber über einander. Es kann auch passieren, dass niemand die Nachricht erhält, falls ein Thema null Subscriber hat. Die Subscriber muss ständig aktiv bleiben, um Nachrichten zu empfängen. Verpasste Nachricht kommt nicht wieder, außer der Publisher eine dauerhafte (engl. durable) Abonnement eingeführt hat. In diesem Fall wird veröffentliche Nachrichten, die während eine Abbonenten abwesend ist, umverteilt wenn die Abbonenten wieder aktiv ist. Abbildung 2.2: Publish-Subscribe [Yuan04] JMS definiert eine Reihe von Schnittstellen für Nachrichten. Diese Schnitstelle entspricht die Grundformen von Daten, die gesendet oder empfängt werden. Die definierten Nachrichtentypen sind: BytesMessage: speichert Daten als eine Folge von Bytes, unterstützt die grundlegendsten Darstellung von Daten und kann somit verschiedene Payloads enthalten. TextMessage: speichert Daten als String. StreamMessage: speichert Dateng als eine Folge von Feldern. Z.B. JohnDoe33, wird als Folge von 2 strings (John, Doe) und 1 integer (33) definiert.

12 2 Java-JMS 9 MapMessage: speichert Daten als eine Reihe von Schlüssel-Wert-Paar. Der Schlüssel ist ein String und der Wert ist beliebig. Z.B. Alter:27, Alter ist hier der Schlüssel und 27 ist der integer Wert. ObjectMessage: speichert eine Java-Object. JMS-Nachricht besteht aus drei grundlegenden Teilen zusammengesetzt Header: Enthält Attribute (Felder), mit der die Nachricht identifiziert und weitergeleitet werden kann. Die Attribute werden mit JMS vorangestellt. Beispiele sind JMSMessageID, die eindeutig die Nachricht identifiziert. JMSDestination, die das Ziel zu dem die Nachricht gesendet wird enthält. JMSDeliverymode, die eine Meldung definiert als persistent oder nonpersistent. Properties: Enthält Nachrichtenzusatzinformationen als Attribute in Form von Schlüssel-Wert-Paar. Ein möglicher Verwendungszweck dieser Attribute ist Filterung der Nachrichten bei den Empfängern. Body: Enthält die eigentliche Nachricht. Wie bereits erwähnt, der Typ der JMS- Nachrichten ist vorher definiert. 2.2 Vergleich Java-JMS-Clientimplementierungen Um JMS zu nutzen, wird ein JMS-Provider (MOM) benötigt, der die Topics, Queues und Sessions verwaltet. Die untenstehende Tabelle 2.2 führt ein paar JMS-Provider auf, die sowohl kommerzielle als auch freie Software sind. Name Firma Lizenz Für J2ME geeignet ActiveMQ Apache Open Source Nein FioranoMQ Fiorano kommerziell Nein ibus//mobile Softwired kommerziell Ja JBoss Redhat Open Source Nein SonicMQ Progress Software kommerziell Nein Sun MQ Sun Microsystems Open Source Nein Tibco EMS TIBCO kommerziell Nein WebSphere IBM kommerziell Ja Tabelle 2.2: JMS-Provider Es ist ganz schwer zu feststellen, welche JMS-Provider die Beste ist. Fiorano hat einen Bericht veröffentlich, in dem verschiedene JMS-Provider getestet und verglichen

13 2 Java-JMS 10 werden. Natürlich wird FioranoMQ als die Beste dargestellt, trotzdem bekommt man grobe Überblick, welche Resultät rauskommen wird wenn die einzelne JMS-Provider eingesetzt ist. Ein Beispiel von einem anderen unabhängigen Bericht [techa] kann man finden auf Prüfbedingungen Alle Tests wurden unter folgenden Bedingungen durchgeführt. Jeder Client läuft auf einem separaten JMS-Verbindung. Alle Prüfergebnisse werden aufgezeichnet, nachdem der Client-Verbindungen hergestellt wurden und Publishers-Subscribers und andere Objekte geschaffen wurden. Alle Test wurden mehrfach ausgeführt wurden, um die Wiederholbarkeit zu gewährleisten. Leistung war unter maximaler Belastung gemessen. So viele Nachrichten wie möglich wurde erzeugt unter Verwendung der Standardeinstellung des Servers damit diese maximale Belastung erreicht. Während der Tests waren keine anderen Anwendungen laufen. Alle Server wurden in der Standardmodus getestet Hardware- und Software-Konfiguration Server System: GNU/Linux el5xen 4 CPU Intel(R) Xeon(R) CPU 3,00 GHz 64 bit 8 GB RAM Client System: Microsoft Windows Server 2003 R2 4 CPU Intel(R) Xeon(R) Cpu 3,00 GHz 64 Bit 8 GB RAM

14 2 Java-JMS 11 Network Setting: Server und Client waren in demselben Netzwerk Netzwerkgeschwindigkeit 1 GBPS Software-Konfiguration: Java 2 Runtime Environment, Standard Edition (build b02) FioranoMQ v SonicMQ v 7.6 Tibco EMS v ActiveMQ v JBoss SunMQ 4.3 IBM WebSphere Test-Szenarien Die Tests wurden für die meist verwendeten Messaging-Modelle mit Topics (Publish- Subscribe) durchgeführt: Non-persistent Publisher und Non-durable Subscriber Diese Modell ist in der Regel verwendet, wenn der Austauschvolume von Nachrichten hoch ist und minimale Latenz gefördert wird. Persistent Publisher und Durable Subscriber Diese Modell wird eingesetzt, wenn viele Redundanz gebraucht wird und es versichert werden muss, dass mindestens eine Nachricht unabhängig von Server- und Client-Status kommt. Die folgenden Tests wurden durchgeführt, basierend auf typischen Kunden Use-Cases: Topic Skalierbarkeit Tests: Es wird die Leistungsmerkmale des JMS-Servers beobachtet mit unterschiedlicher Anzahl von Publisher-/Subscriber-Client in einem festen Anzahl von Topic. Die Ergebnisse veranschaulichen die Skalierbarkeit von JMS-Server als mehrere Clients eingesetzt (alle arbeiten mit dem gleichen JMS- Topic).

15 2 Java-JMS 12 Server Skalierbarkeit Tests: Es wird die Leistungsmerkmale des JMS-Servers beobachtet mit unterschiedlicher Anzahl von Topics in einem festen Anzahl von Publisher-/Subscriber-Client. Die Ergebnisse veranschaulichen die Skalierbarkeit von JMS-Server als mehrere Clients eingesetzt (jeder arbeitet mit ungleichen JMS-Topics). Persistent Publisher, mehrere durable Subscriber: Diese Tests beachten Leistungsmerkmale des JMS-Servers, wenn ein persistent Publisher Nachrichten zu mehreren durable Subscriber sendet. Non-persistent Publisher, mehrere non-durable Subscriber: Diese Tests beachten Leistungsmerkmale des JMS-Servers, wenn ein non-persisten Publisher Nachrichten zu mehreren non-durable Subscriber sendet. Es gibt einen feinen Unterschied zwischen durable JMS-Nachricht und persistent JMS-Nachricht. Eine durable JMS-Nachricht gilt nur für Publish-Subscribe und eine persistent JMS-Nachricht gilt sowohl für Point-to-Point und Publish-Subscribe. Durable : JMS-Server hält eine Nachricht, wenn der Teilnehmer ist vorübergehend nicht aktiv. So ist die Haltbarkeit von dem Topic-Subscriber und dem JMS-Server definiert. Damit dies geschehen, müssen sich Subscriber mit seinem eindeutigen Client ID registrieren. Persistent : JMS-Server speichert jede Nachricht in einem sekundären Speicher. Die gespeicherte Nachricht wird erst entfernt, wenn Subscriber die Nachricht erfolgreich empfängt hat. Dies wird von dem Publisher und JMS-Server definiert Testdauer Alle Test-Szenarien wurden für insgesamt acht Minuten durchgeführt. Jede Test umfasste acht, sechzig-sekunden-intervallen. Die ersten beiden und letzten Intervalle wurdn als Ramp-up und Ramp-down vorgesehen. Ramp-up Intervalle sind Zeiten, in denen die Systeme ihre Nachrichten-Handling- Kapazitäten aufsteuern in Reaktion auf die neu eingeführten Client. Ramp-down Intervalle sind Zeiten, in denen die Systeme ihre Nachrichten-Handling- Kapazitäten herabsetzen in Reaktion auf die Reduzierung der Client. Die Restlichen fünf Intervalle sind die Messzeiten, während der Steady-State-Leistung erreicht wurde. Steady-State ist der Zustand, in dem sich Nachrichtenrate geringfügig verändert.

16 2 Java-JMS Testergebnisse Abbildung 2.3: Topic Skalierbarkeit [techb] Abbildung 2.4: Topic Skalierbarkeit [techb]

17 2 Java-JMS 14 Abbildung 2.5: Server Skalierbarkeit [techb] Abbildung 2.6: Server Skalierbarkeit [techb]

18 2 Java-JMS 15 Abbildung 2.7: Persistent Publisher, Durable Subscriber [techb] Abbildung 2.8: Persistent Publisher, Durable Subscriber [techb]

19 2 Java-JMS 16 Abbildung 2.9: Non Persistent Publisher, Non Durable Subscriber [techb] Abbildung 2.10: Non Persistent Publisher, Non Durable Subscriber [techb]

20 2 Java-JMS Auswertung Die Testszenarien stellen Bedingungen für realen Anwendungen, wo eine einzelne Message Broker viele Publisher und Subscriber unterstützen soll. Verschiedene Konfigurationen von JMS-Broker oder Änderungen an Test-Defitionen können zu andere Durchsatzleistungen herbeiführen. FioranoMQ und SonicMQ liefern relativ hohe Durchsatzrate und kommen als Sieger von dem oben genannten Test. Aber mehr Ingenieur benutzen ActiveMQ oder JBoss für ihre Systeme. Es liegt einfach daran, dass die beiden Programme kostenlos erwerbbar sein. Wenn die Server und die Clients als eine Gesamtpaket betrachtet sein soll, um die Interoperabilität zwischen J2EE und J2ME zu gewährleisten, wird in vielen Bücher IBus Mobile oder IBM WebSphere empfohlen. Alternative Variante ist JORAM (Java Open Reliable Asynchronous Messaging), da JORAM eine Open-Source-Software ist.

21 Literaturverzeichnis 18 Literaturverzeichnis [Menz04] Stefan Menz. Die Java Virtual Machine. Technischer Bericht, Uni Ulm, [Sun 03] Sun Microsystems, Inc., cdc-whitepaper.pdf. CDC WhitePaper, [techa] Java Performance Comparison. Technischer Bericht, Krissoft Solutions. [techb] Java Performance Comparison. Technischer Bericht, Fiorano Software Technologies Pte Ltd, java-message-service/jms-performance-comparison.php. [Ulle09] Christian Ullenboom. Java ist auch eine Insel. Galileo Press Seiten, 8. Auflage, [Yuan04] Michael Juntao Yuan. Enterprise J2ME. Prentice Hall. 452 Seiten, 4. Auflage, [Yusu04] Kareem Yusuf. Enterprise Messaging Using JMS and IBM Websphere. Pearson Education. 329 Seiten, 1. Auflage, 2004.

22 Abbildungsverzeichnis 19 Abbildungsverzeichnis 1.1 Java 2 Platform [Yuan04] J2ME Komponente [Yuan04] Übersicht der derzeit verfügbaren Virtual Machine [Sun 03] Point-to-Point Modell [Yuan04] Publish-Subscribe [Yuan04] Topic Skalierbarkeit [techb] Topic Skalierbarkeit [techb] Server Skalierbarkeit [techb] Server Skalierbarkeit [techb] Persistent Publisher, Durable Subscriber [techb] Persistent Publisher, Durable Subscriber [techb] Non Persistent Publisher, Non Durable Subscriber [techb] Non Persistent Publisher, Non Durable Subscriber [techb]

23 Tabellenverzeichnis 20 Tabellenverzeichnis 2.1 Messaging Domäne Schnitstelle [Yusu04] JMS-Provider

24 Abkürzungsverzeichnis und Formelzeichen 21 Abkürzungsverzeichnis und Formelzeichen CDC CLDC JMS JVM KVM MIDP Connected Device Configuration Connected Limited Device Configuration Java Messaging Service Java Virtual Machine Kilobyte Virtual Machine Mobile Information Device Profile

25 Erklärung 22 Erklärung Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der angegebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer oder anderer Prüfungen noch nicht vorgelegt worden. Ilmenau, den Aalbrecht Alby Irawan