Technische Universität Ilmenau Fakultät für Elektrotechnik und ...

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: 01. 07. 2011 

geboren am: 

Studiengang: Ingenieurinformatik 

Studienrichtung: Multimediale Informations- und 

Kommunikationssysteme 

Anfertigung im Fachgebiet: Kommunikationsnetze 

Fakultät für Elektrotechnik und Informationstechnik 

Verantwortlicher Professor: Prof. Dr. rer. nat. habil. Jochen Seitz 

Wissenschaftlicher Betreuer: Dipl.-Ing. Karsten Renhak

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.

Inhaltsverzeichnis i 

Inhaltsverzeichnis 

1 Einleitung 1 

1.1 Verschiedene Java Platformen . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Java-VMs für Smartphones und mobile Geräte . . . . . . . . . . . . . . 2 

2 Java-JMS 5 

2.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

2.1.1 Message Oriented Middleware . . . . . . . . . . . . . . . . . . . 5 

2.1.2 Java Message Service . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.2 Vergleich Java-JMS-Clientimplementierungen . . . . . . . . . . . . . . 9 

2.2.1 Prüfbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.2.2 Hardware- und Software-Konfiguration . . . . . . . . . . . . . . 10 

2.2.3 Test-Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.2.4 Testdauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.2.5 Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.2.6 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

Literaturverzeichnis 18 

Abbildungsverzeichnis 19 

Tabellenverzeichnis 20 

Abkürzungsverzeichnis und Formelzeichen 21 

Erklärung 22 

Hauptseminararbeit Aalbrecht Alby Irawan


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 ent- 

hält sich die benötigte JVM und Bibliotheken, die beim normalen PC oder Work- 

station 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 ange- 

fertige 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 Kompo- 

nenten wie Konfiguration, Profil und optionale Pakete. Jede gültige Kombination aus 

Konfiguration und Profil ist auf einer bestimmten Art von Gerät gezielt. Die Konfigura- 

tion bietet die grundlegende und allgemeine Sprachfunktionalität. Das Profil hingegen 



Abbildung 1.1: Java 2 Platform [Yuan04] 

basiert auf Konfigurationen und unterstützt erweiterte APIs wie grafische Benutzero- 

berflä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 limitier- 

ten Rechenleistung und Arbeitsspeicher, braucht jedoch mindestens 160 KB Ar- 

beitsspeicher 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 mindes- 

tens 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 Pro- 

file (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 



Abbildung 1.2: J2ME Komponente [Yuan04] 

Hardware und vergleichbar mit Mikroprozessorcode für einen Prozessor, der Anweisun- 

gen 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 spezifi- 

schen 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 ih- 

ren Einsatz auf Servern, Workstations und Desktop PCs bzw. Notebooks. Auf 

diesen Systemen stehen ausreichend Ressourcen bereit, sodass eine vollständi- 

ge 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 



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 zu- 

sammen. CardVM unterstützt sogar einen 8- oder 16-bit Prozessor. Um mit die- 

sen 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 Mana- 

ger, 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. Kar- 

ten 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] 


2 Java-JMS 5 

2 Java-JMS 

2.1 Übersicht 

Mobile Nachrichtenvermittlungapplikationen haben sich extrem erfolgreich durchge- 

setzt, person-to-person Kommunikation zu unterstützen. Allerdings ist Nachrichtenver- 

mittlung 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 wichtigs- 

ten modernen Enterprise-Anwendungen. 

2.1.1 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 re- 

duziert die Komplexität der Entwicklung von Anwendungen, die mehrere Betriebssys- 

teme und Netzwerk-Protokolle umfassen. Die Middleware schafft eine verteilte Kom- 

munikationsschicht, dass der Anwendungs-Entwickler von den Details der verschiede- 

nen Betriebssystem-und Netzwerk-Schnittstellen isoliert. APIs, die über verschiedene 

Plattformen und Netzwerke auszuweiten werden typischerweise durch MOM vorgese- 

hen. 

MOM bietet eine Client / Server-Architektur und unterstützt in der Regel asynchro- 

ne 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 


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. 

2.1.2 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] 


2 Java-JMS 7 

Point-to-Point Hier schickt der Sender die Nachricht zu einer bestimmten Warte- 

schlange und der Empfänger bekommt die Nachricht von derselben Warteschlan- 

ge. 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 ein- 

mal 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 ko- 

muniziert. Falls der Sender mehrere Empfänger erreichen will, muss er auch meh- 

rere 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 The- 

ma abonnieren. Gesendete Nachrichten zu einem Thema werden dupliziert und 

an alle Abbonenten dieses Thema weitergeleitet. Wenn ein Teilnehmer vorüber- 

gehend 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. 


2 Java-JMS 8 

Publish-Subscribe wird normalerweise verwendet, wenn Daten an mehrere Sub- 

scriber 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 Sub- 

scriber muss ständig aktiv bleiben, um Nachrichten zu empfängen. Verpasste 

Nachricht kommt nicht wieder, außer der Publisher eine dauerhafte (engl. dura- 

ble) 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 ent- 

spricht die Grundformen von Daten, die gesendet oder empfängt werden. Die definier- 

ten Nachrichtentypen sind: 

• BytesMessage: speichert Daten als eine Folge von Bytes, unterstützt die grundle- 

gendsten 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. 


2 Java-JMS 9 

• MapMessage: speichert Daten als eine Reihe von Schlüssel-Wert-Paar. Der Schlüs- 

sel 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 wei- 

tergeleitet 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 Fil- 

terung 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 


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 http://www.capitalware.biz/dl/docs/krissoft_jms_performance.pdf 

2.2.1 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 her- 

gestellt wurden und Publishers-Subscribers und andere Objekte geschaffen wur- 

den. 

• Alle Test wurden mehrfach ausgeführt wurden, um die Wiederholbarkeit zu ge- 

wä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. 

2.2.2 Hardware- und Software-Konfiguration 

Server System: 

• GNU/Linux 2.6.18-92.el5xen 

• 4 CPU Intel(R) Xeon(R) CPU 5160 @ 3,00 GHz 

• 64 bit 8 GB RAM 

Client System: 

• Microsoft Windows Server 2003 R2 

• 4 CPU Intel(R) Xeon(R) Cpu 5160 @ 3,00 GHz 

• 64 Bit 8 GB RAM 


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 1.5.0 18-b02) 

• FioranoMQ v 9.1.1 

• SonicMQ v 7.6 

• Tibco EMS v 4.4.0 

• ActiveMQ v 5.3.0 

• JBoss 1.4.4 

• SunMQ 4.3 

• IBM WebSphere 7.0 

2.2.3 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 Re- 

gel verwendet, wenn der Austauschvolume von Nachrichten hoch ist und mini- 

male Latenz gefördert wird. 

Persistent Publisher und Durable Subscriber Diese Modell wird eingesetzt, wenn vie- 

le 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 be- 

obachtet 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). 


2 Java-JMS 12 

• Server Skalierbarkeit Tests: Es wird die Leistungsmerkmale des JMS-Servers be- 

obachtet 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 Leis- 

tungsmerkmale 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 Nachrich- 

ten 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 erfolg- 

reich empfängt hat. Dies wird von dem Publisher und JMS-Server definiert. 

2.2.4 Testdauer 

Alle Test-Szenarien wurden für insgesamt acht Minuten durchgeführt. Jede Test um- 

fasste 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. 


2 Java-JMS 13 

2.2.5 Testergebnisse 

Abbildung 2.3: Topic Skalierbarkeit [techb] 

Abbildung 2.4: Topic Skalierbarkeit [techb] 


2 Java-JMS 14 

Abbildung 2.5: Server Skalierbarkeit [techb] 

Abbildung 2.6: Server Skalierbarkeit [techb] 


2 Java-JMS 15 

Abbildung 2.7: Persistent Publisher, Durable Subscriber [techb] 

Abbildung 2.8: Persistent Publisher, Durable Subscriber [techb] 


2 Java-JMS 16 

Abbildung 2.9: Non Persistent Publisher, Non Durable Subscriber [techb] 

Abbildung 2.10: Non Persistent Publisher, Non Durable Subscriber [techb] 


2 Java-JMS 17 

2.2.6 Auswertung 

Die Testszenarien stellen Bedingungen für realen Anwendungen, wo eine einzelne Mes- 

sage Broker viele Publisher und Subscriber unterstützen soll. Verschiedene Konfigura- 

tionen von JMS-Broker oder Änderungen an Test-Defitionen können zu andere Durch- 

satzleistungen herbeiführen. 

FioranoMQ und SonicMQ liefern relativ hohe Durchsatzrate und kommen als “Sie- 

ger” 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. 


Literaturverzeichnis 18 

Literaturverzeichnis 

[Menz04] Stefan Menz. Die Java Virtual Machine. Technischer Bericht, Uni Ulm, 

2004. 

[Sun 03] Sun Microsystems, Inc., http://java.sun.com/products/cdc/wp/ 

cdc-whitepaper.pdf. CDC WhitePaper, 2003. 

[techa] Java Performance Comparison. Technischer Bericht, Krissoft Solutions. 

[techb] Java Performance Comparison. Technischer Bericht, Fiorano Soft- 

ware Technologies Pte Ltd, http://www.fiorano.com/whitepapers/ 

java-message-service/JMS-performance-comparison.php. 

[Ulle09] Christian Ullenboom. Java ist auch eine Insel. Galileo Press. 1475 Seiten, 

8. Auflage, 2009. 

[Yuan04] Michael Juntao Yuan. Enterprise J2ME. Prentice Hall. 452 Seiten, 4. Auf- 

lage, 2004. 

[Yusu04] Kareem Yusuf. Enterprise Messaging Using JMS and IBM Websphere. Pear- 

son Education. 329 Seiten, 1. Auflage, 2004. 


Abbildungsverzeichnis 19 

Abbildungsverzeichnis 

1.1 Java 2 Platform [Yuan04] . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

1.2 J2ME Komponente [Yuan04] . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.3 Übersicht der derzeit verfügbaren Virtual Machine [Sun 03] . . . . . . . 4 

2.1 Point-to-Point Modell [Yuan04] . . . . . . . . . . . . . . . . . . . . . . 7 

2.2 Publish-Subscribe [Yuan04] . . . . . . . . . . . . . . . . . . . . . . . . 8 

2.3 Topic Skalierbarkeit [techb] . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.4 Topic Skalierbarkeit [techb] . . . . . . . . . . . . . . . . . . . . . . . . . 13 

2.5 Server Skalierbarkeit [techb] . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.6 Server Skalierbarkeit [techb] . . . . . . . . . . . . . . . . . . . . . . . . 14 

2.7 Persistent Publisher, Durable Subscriber [techb] . . . . . . . . . . . . . 15 

2.8 Persistent Publisher, Durable Subscriber [techb] . . . . . . . . . . . . . 15 

2.9 Non Persistent Publisher, Non Durable Subscriber [techb] . . . . . . . . 16 

2.10 Non Persistent Publisher, Non Durable Subscriber [techb] . . . . . . . . 16 


Tabellenverzeichnis 20 

Tabellenverzeichnis 

2.1 Messaging Domäne Schnitstelle [Yusu04] . . . . . . . . . . . . . . . . . 6 

2.2 JMS-Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 


Abkürzungsverzeichnis und Formelzeichen 21 

Abkürzungsverzeichnis und 

Formelzeichen 

CDC . . . . . . . . . . . . . . . Connected Device Configuration 

CLDC . . . . . . . . . . . . . . Connected Limited Device Configuration 

JMS . . . . . . . . . . . . . . . Java Messaging Service 

JVM . . . . . . . . . . . . . . . Java Virtual Machine 

KVM . . . . . . . . . . . . . . Kilobyte Virtual Machine 

MIDP . . . . . . . . . . . . . . Mobile Information Device Profile 


Erklärung 22 

Erklärung 

Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der ange- 

gebenen Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffent- 

lichten 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 01. 07. 2011 Aalbrecht Alby Irawan

Technische Universität Ilmenau Fakultät für Elektrotechnik und ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?