Message Oriented Middleware: Technische Aspekte der Umsetzung von EAI

Größe: px
Ab Seite anzeigen:

Download "Message Oriented Middleware: Technische Aspekte der Umsetzung von EAI"

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Message Oriented Middleware: Technische Aspekte der Umsetzung von EAI im Rahmen des Seminars Enterprise Architecture Management Benjamin Oberste-Berghaus Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Dipl.- Wirt.Inform. Christoph Lembeck Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Middleware und Enterprise Application Intergration Message Oriented Middleware Middleware Remote Procedure Call Object Oriented Middleware Message Oriented Middleware MOM und Enterprise Application Integration Java Message Service Grundlagen Kommunikationsmodelle Point-to-Point Publish/Subscribe Nachrichten Interfaces Erweiterte Konzepte Zuverlässigkeit Transaktionen Request Reply Message Driven Beans Grundlagen Lebenszyklus Beurteilung Zusammenfassung A WM-Ticket-Beispiel Literaturverzeichnis II

3 Kapitel 1: Middleware und Enterprise Application Intergration 1 Middleware und Enterprise Application Intergration In Unternehmen gibt es häufig eine Vielzahl von unterschiedlichen Applikationen, Plattformen und Datenbanken, die historisch nebeneinander gewachsen sind. Neben diesen Altsystemen ist die Nutzung von neueren Technologien, wie Intranet und Internet, für eine effiziente und effektive Wettbewerbsstrategie erforderlich. Middleware ermöglicht diesen unterschiedlichen Softwarekomponenten miteinander zu kommunizieren. Ziel der Enterprise Application Integration ist es die intra- und interorganisatorischen Geschäftsprozesse zu optimieren. Dafür ist die Kommunikation zwischen den Softwaresystemen, und deswegen Middleware notwendig. Innerhalb dieser Ausarbeitung wird zunächst begründet, weshalb sich gerade Message Oriented Middleware auf dem Gebiet der Enterprise Application Integration durchsetzt (Kapitel 2). Anschließend wird der Java Message Service, als eine mögliche Spezifikation für Message Oriented Middleware, näher erläutert (Kapitel 3). Abschließend werden Message Driven Beans vorgestellt, welche die asynchrone Kommunikation auf Ebene der Enterprise Java Beans unterstützen (Kapitel 4). 3

4 Kapitel 2: Message Oriented Middleware 2 Message Oriented Middleware Dieses Kapitel führt zunächst in den Begriff Middleware ein (Abschnitt 2.1) und stellt in den Abschnitten drei Typen von Middleware vor. Abschließend soll in Abschnitt 2.5.herausgearbeitet werden, warum sich gerade Message Oriented Middleware für die Enterprise Application Integration eignet. 2.1 Middleware Der Begriff Middleware ist, wie viele andere in wissenschaftlichen Diskussionen, nicht einheitlich definiert. Eine weit gefasste Definition von Linthicum dient als Grundlage dieser Ausarbeitung: Middleware is basically any type of software that facilitates communication between two or more software systems [Li99, S. 100]. Anhand dieser Definition lassen sich die wichtigsten Merkmale von Middleware identifizieren. Zunächst ist Middleware ein softwarebasiertes Konzept. Ein weiterer Bestandteil der Definition ist, dass Middleware eingesetzt wird, um Kommunikation zu ermöglichen. Auf Softwaresysteme bezogen, bedeutet Kommunikation den Austausch von Daten bzw. Informationen. Diese kann hierbei sowohl zwischen zwei, als auch zwischen mehreren Softwaresystemen stattfinden. Die Softwaresysteme zwischen denen die Kommunikation ermöglicht werden soll, weisen i.d.r. einen hohen Grad an Heterogenität auf. Die Heterogenität der Softwaresysteme kann sich auf viele Bereiche der Softwaresysteme, wie die Programmiersprache, Plattformen und Inhalt, beziehen. Das Verbergen der Heterogenität der zu Grunde liegenden Netzwerke, Hardware, Betriebssysteme und Programmiersprachen ist nach Coulouris das zentrale Ziel der Middleware [CDK01, S. 35]. Der Name Middleware resultiert aus der Tatsache, dass die von Middleware angebotenen Dienste zwischen der Betriebssystemschicht und der Applikationsschicht ausgeführt werden [JBLN01, S. 27]. Middleware wird je nach Zweck unterschiedlich klassifiziert. Eine gängige Klassifizierung unterteilt Middleware anhand der beteiligten Softwaresysteme bzw. der ausgetauschten Informationen in Remote Procedure Calls, Object Oriented Middleware, Database Oriented Middleware und Message Oriented Middleware [Li99, JBLN01, Ke02]. Da Message Oriented Middleware im Mittelpunkt dieser Ausarbeitung steht, wird eine grobe, aber für das Ziel der Ausarbeitung zweckmäßige Klassifizierung in synchrone 4

5 Kapitel 2: Message Oriented Middleware und asynchrone Middleware vorgenommen. Dadurch ist es möglich die Unterschiede zwischen den Kommunikationsparadigmen deutlich herauszustellen. Wie noch gezeigt wird, arbeiten Remote Procedure Calls und Objekt Oriented Middleware mit synchroner Kommunikationsmechanismen und Message Oriented Middleware mit einem asynchronen Mechanismus. Diese drei Typen von Middleware sollen im Folgenden näher beschrieben werden. 2.2 Remote Procedure Call Der Remote Procedure Call (RPC) ermöglicht die Kommunikation zwischen Applikationen, die auf heterogenen Plattformen laufen. RPC basiert auf prozeduralen Konzepten und unterstützt entfernte Funktionsaufrufe. RPC blendet die Details der Kommunikation, die Low-Level Netzwerkkommunikation, vor der Applikation und dem Programmierer aus. Dieser braucht sich um die Details nicht zu kümmern. Zentrales Anliegen des RPC ist es, einem lokalen Programm eine entfernte Funktion nutzbar zu machen. Für das lokale Programm ist der entfernte Funktionsaufruf genauso wie ein lokaler Aufruf [CDK01, S. 215]. Ein RPC ist für das lokale Programm also transparent. Diese Art der Transparenz erfordert, dass die aufrufende Applikation, wie bei einem lokalen Aufruf, auf die Antwort wartet und nicht weiterarbeitet; sie blockiert. Dieser Kommunikationsmechanismus, bei der ein Prozess blockiert während seine Anfrage bearbeitet wird, heißt synchrone Kommunikation. Ausführlichere Informationen über RPC können beispielsweise in [CDK01] nachgelesen werden. 2.3 Object Oriented Middleware Object Oriented Middelware (OOM) unterstützt die Kommunikation zwischen verteilten Objekten und Komponenten [JBLN01, S. 31f.]. Realisiert wird OOM meistens mit Hilfe von Object Request Broker (ORB). Sie ermöglichen lokalen Objekten oder Komponenten die Methoden entfernter Objekte oder Komponenten mittels Schnittstellen zu benutzen. Im Prinzip ist OOM eine weitere Schicht über RPC. Deswegen arbeitet auch OOM mit dem synchronen Kommunikationsmechanismus und blendet Details der Kommunikation aus. Um hinsichtlich der Programmiersprachen und der Plattformen Transparenz zu ermöglichen, sind Standards für die Schnittstellen erforderlich, an welche sich die Hersteller von ORB halten können. 5

6 Kapitel 2: Message Oriented Middleware Die drei wichtigsten Standards für ORB sind CORBA von OMG, JAVA RMI und RMI- IIOP von SUN sowie COM/DCOM/COM+ von Microsoft. Viele ORB Produkte sind mit den CORBA ORB Spezifikationen und den verschiedenen RMI und RMI-IIOP Implementierungen kompatibel. Insbesondere die Unterstützung von RMI-IIOP ist wichtig, da es das gleiche Kommunikationsprotokoll wie CORBA benutzt, IIOP (Internet Inter-ORB-Protocol), und dadurch RMI und CORBA zusammenarbeiten können. Verteilte Objekte sind die Grundlage von Enterprise Java Beans (EJB) und dementsprechend ist die mittels RMI bzw. RMI-IIOP durchgeführte Kommunikation zentraler Bestandteil der gesamten J2EE Plattform. Der Microsoft Standard, welcher des Öfteren den Namen gewechselt hat, unterscheidet sich in einigen Punkten deutlich von RMI und CORBA. Trotzdem ist eine Verbindung zwischen diesen Technologien möglich. Da eine detaillierte Auseinandersetzung mit den genannten ORB Standards nicht Gegenstand dieser Ausarbeitung ist, sei auf die weiterführende Literatur verwiesen: zum Thema CORBA [CDK01, Kap.17] und zum Thema RMI und RMI-IIOP siehe [MAY03, Kap.4]. 2.4 Message Oriented Middleware Wie in den Abschnitten 2.2 und 2.3 gezeigt, sind RPC und OOM klassische Vertreter auf synchroner Kommunikation basierender Middleware. Message Oriented Middleware (MOM) ermöglicht asynchrone Kommunikation mittels Nachrichten. Diese werden nicht direkt von einer Sender-Applikation zur Empfänger-Applikation gesendet, sondern gelangen über einen Vermittler an ihr Ziel. Dieser Mittler ist die MOM und deren technische Realisierung wird als Message-Server oder auch Message Broker bezeichnet [Mo02, S. 10]. Durch die Verwendung von Nachrichten und einen Vermittler ist ein hohes Maß an Interoperabilität zwischen sehr heterogenen Softwaresystemen möglich, da diese keine Details übereinander kennen müssen [JBLN01, S.28]. Außerdem sind die kommunizierenden Applikationen, wie in Abbildung 1 [JBLN01, S. 28] dargestellt, entkoppelt. Die Sender-Applikation sendet die Nachricht an den Vermittler und arbeitet sofort weiter, ohne dass sie, wie bei Verwendung von RPC oder OOM, blockiert. Der Vermittler ist für die Weiterleitung der Nachricht an die Empfänger-Applikation verantwortlich. Ist diese temporär nicht verfügbar, dann verwahrt der Message-Server die Nachricht solange, bis die Applikation empfangsbereit ist [JBLN01, S. 28]. 6

7 Kapitel 2: Message Oriented Middleware Abbildung 1: Prinzip von MOM Auch in einer anderen Hinsicht sind die Applikationen entkoppelt. Da die Kommunikation über Nachrichten stattfindet, benötigen die Applikationen keine Informationen darüber, wer die Nachrichten wann und wie bearbeitet. Genauso wie bei RPC und OOM reduziert MOM die Komplexität, da Details der Kommunikation, bezüglich des Transports und des Netzwerks, versteckt werden. Die Funktionalität von MOM wird über ein Application Programming Interface (API) zugänglich. 2.5 MOM und Enterprise Application Integration Um verschiedene Softwaresysteme eines Unternehmens miteinander zu verbinden, ist Middleware, als Motor von Enterprise Application Integration (EAI), notwendig [Li99, S. 99]. Gerade MOM ist ein wichtiger Bestandteil von EAI, da sie einige wichtige Eigenschaften besitzt [Li99, S. 110]. Diese Eigenschaften resultieren zum einen aus der Verwendung eines zentralen Vermittlers, dem Message-Server, und zum anderen aus der Verwendung des asynchronen Kommunikationsmechanismus mittels Nachrichten. Die Verwendung eines Message-Servers und die damit verbundene zentrale Architektur ermöglicht eine einfache Umsetzung nicht nur der Point-to-Point, sondern auch der Many-to-Many Kommunikation. Letztere Art der Kommunikation ist im Rahmen der EAI notwendig, da es innerhalb eines Unternehmens häufig erforderlich ist, dass viele Applikationen miteinander kommunizieren [Li99, S.113f.]. Die Applikationen treten jeweils nur direkt mit dem Message-Server in Kontakt. Dadurch ist die gesamte Architek- 7

8 Kapitel 2: Message Oriented Middleware tur flexibel, denn Änderungen sind leicht durchzuführen. Außerdem brauchen Applikationen deswegen die Details der anderen Applikationen und Plattformen nicht zu kennen [JBLN01, S.28]. Zudem stellt ein Message-Server neben der reinen Nachrichtenübermittlung i.d.r noch weitere Dienste, wie Lastverteilung und Transaktionen, bereit. Besonders die gesicherte Kommunikation mittels Transaktionen ist vor dem Hintergrund der EAI relevant [Li99, S.118f.]. Die Verwendung eines zentralen Servers kann allerdings auch einen großen Nachteil haben, weil dann die gesamte Architektur von diesem abhängig ist. Können die Applikationen nur mit dem Server eines Anbieters kommunizieren, ist die Architektur sogar von dem Server eines bestimmten Anbieters abhängig. Um diese Abhängigkeit zu vermeiden, hat die Firma SUN eine allgemeine Schnittstelle bereitgestellt, mittels der die Message-Server aller Anbieter kontaktiert werden können, den Java Message Service (JMS). Dieser wird in Kapitel 3 näher beschrieben. Durch den JMS entfällt zwar die Abhängigkeit von einem speziellen Anbieter, allerdings müssen die Applikationen in Java geschrieben sein. Durch die Verwendung von Nachrichten ist die asynchrone Kommunikation zwischen Applikationen möglich. Da die Applikationen dabei nicht blockieren, ist MOM grundsätzlich performanter als RPC oder OOM. Wie in diesem Kapitel deutlich wurde, hat MOM viele Vorteile gegenüber der klassischen Middleware RPC und OOM. MOM ist aber vor allem eine Ergänzung von RPC und OOM, insbesondere im Rahmen der EAI, und kein vollständiger Ersatz. In vielen Situationen findet die Kommunikation weiterhin über die klassische Middleware statt. 8

9 Kapitel 3: Java Message Service 3 Java Message Service Innerhalb dieses Kapitels wird der Java Message Service der Firma SUN vorgestellt. Zunächst wird im ersten Abschnitt erklärt was der Java Message Service ist. Die Abschnitte 3.2 bis 3.4 beschreiben die grundsätzliche Funktionsweise, sowie die notwendigen Bestandteile. Das letzte Kapitel erläutert weiterführende Konzepte, die insbesondere im Rahmen von EAI interessant sind. 3.1 Grundlagen Java Message Service (JMS) ist ein Messaging Standard. Eine vollständige Darstellung des Java Message Service ist in [JMS1.1] nachzulesen. JMS stellt eine Spezifikationen dar, welche Schnittstellen und Semantik definiert. Diese ermöglichen es Java Applikationen Dienste von allen JMS kompatiblen Message-Servern zu nutzen. JMS besteht aus zwei Teilen; einem Application Programming Interface (API), um Nachrichten zu schreiben und zu verschicken, und ein Service Provider Interface (SPI), welches die Seite des Servers spezifiziert [RAJ02, S.203]. Die Java Applikation kann mit einem beliebigen Message-Server kommunizieren, wenn dieser JMS kompatibel ist, also das JMS SPI umsetzt. Im Kontext von JMS werden diese Message-Server auch als JMS Provider bezeichnet. Es ist wichtig zu beachten, dass SUN derzeit keine Kompatibilitätstests durchführt. Deswegen gibt es keinen Standard, um die auf Seiten der Anbieter erklärte JMS Kompatibilität zu überprüfen [MC01, S.133]. Eine Applikation, welche die JMS Spezifikation umsetzt, ist nicht mehr an den Message-Server eines bestimmten Herstellers gekoppelt. Dieser Zusammenhand ist in Abbildung 2 verdeutlicht. Abbildung 2: Java Message Service 9

10 Kapitel 3: Java Message Service Fünf große JMS Provider sind WebSphere MQ von IBM, SonicMQ von Progress, FioranoMQ von Fiorano, Java Message Queue von Sun Microsystems und WebLogic Server von BEA. Diese sind in [MC01, Kap.9] näher beschrieben. Das Message Produkt Message Queue der Firma Microsoft unterstützt JMS nicht. JMS wurde entwickelt, um die Vorteile von asynchroner Kommunikation auch für Java Applikationen zu nutzen. An der Entwicklung von JMS waren außer SUN weitere große Unternehmen beteiligt. Das ist ein Grund, weshalb die JMS Spezifikation von vielen Server Anbietern unterstützt wird. Ein weiterer Grund für die weit verbreitete Unterstützung ist, dass JMS nur die direkt mit der Kommunikation zusammenhängenden Aspekte festlegt. Beispielsweise werden keine Vorgaben bezüglich der Lastverteilung oder von Sicherheitsaspekten gemacht [JMS1.1, S.16f.] Die Spezifikation ist dadurch leichtgewichtig und die Anbieter von JMS Providern können sich anhand zusätzlicher Merkmale untereinander differenzieren. Um JMS benutzen zu können, werden Nachrichten, administrative Objekte und JMS Clients benötigt. Bevor diese näher Erläutert werden, sollen die beiden in JMS spezifizierten Kommunikationsmodelle erklärt werden. 3.2 Kommunikationsmodelle JMS unterstützt zwei Kommunikationsmodelle, Point-to-Point und Publish/Subscribe. Die an der Kommunikation beteiligten Komponenten werden allgemein als Produzent, Konsument und Destination bezeichnet. Der Produzent ist der Erzeuger der Nachricht, der Konsument ist der Abnehmer. Eine Destination agiert als Vermittler der Nachrichten. Diese Komponenten werden in Abhängigkeit von dem zugrunde liegenden Kommunikationsmodell entweder als Sender, Receiver und Queue oder als Publisher, Abonnent und Topic bezeichnet Point-to-Point Das Point-to-Point (P-t-P) Modell realisiert Kommunikation zwischen einem Sender und einem Receiver mittels einer Queue (s. Abbildung 3). Abbildung 3: Das Point-to-Point Kommunikationsmodell 10

11 Kapitel 3: Java Message Service Dabei hat jede Nachricht genau einen Receiver. Der Kommunikationsaustausch findet zwischen genau zwei Komponenten statt. Ein oder mehrere Sender schicken eine Nachricht an die Queue. Eine Queue kann mehrere Receiver haben an die sie Nachrichten weiterleitet. Die Queue stellt sicher, dass jede Nachricht genau einmal versendet wird. JMS unterstützt für die Weiterleitung von Nachrichten durch die Queue den Pull- und den Push- Mechanismus. Beim Pull-Mechanismus ruft der Receiver Nachrichten aktiv ab, indem er bei der Queue anfragt, ob Nachrichten für ihn vorhanden sind. Leitet die Queue Nachrichten automatisch an den Receiver weiterleitet, ist der Push-Mechanismus umgesetzt. Weitere Einstellungen hinsichtlich der Bearbeitung von Nachrichten durch die Queue, beispielsweise die Lastverteilung, werden Herstellerspezifisch umgesetzt Publish/Subscribe Das Publish/Subscribe (Pub/Sub) Kommunikationsmodell ermöglicht die Kommunikation zwischen einem Publisher und einem oder mehreren Abonnenten mittels eines Topics. Dieses Modell ist die Umsetzung der Many-to-Many Kommunikation. Der Nachrichtenaustausch ist nicht auf zwei beteiligte Komponenten beschränkt. Unter einem Topic können ein oder mehrere Publisher Nachrichten veröffentlichten, also Nachrichten an das Topic senden. Diese Nachrichten eines Topics erhalten alle Abonnenten, die bei dem Topic registriert sind. Deswegen kann eine Nachricht viele Konsumenten haben. Dieser Zusammenhang ist in Abbildung 4 dargestellt. Abbildung 4: Das Publish/Subscribe Kommunikationsmodell Publisher und Abonnenten können dynamisch während der Laufzeit hinzugefügt werden, dadurch lassen sich Systeme einfach verändern und vergrößern. Das Pub/Sub Kommunikationsmodell in JMS unterstützt nur den Push-Mechanismus, also die automatische Weitergabe der Nachrichten durch das Topic an die Abonnenten. 11

12 Kapitel 3: Java Message Service 3.3 Nachrichten Der Inhalt der Kommunikation zwischen Produzent und Konsument wird mittels Nachrichten weitergegeben. Nachrichten sind zentraler Bestandteil von jeder MOM. Ihre Struktur wird im Folgenden erklärt. Wie in Abbildung 5 zu erkennen, besteht eine Nachricht aus drei Teilen: Header, Property und Body. Abbildung 5: Struktur einer Nachricht Im Header sind Metadaten enthalten, welche die Nachricht beschreiben, bspw. das Ziel der Nachricht und der Zeitpunkt, wann sie erhalten wurde. Mit dem Inhalt des Headers lassen sich die Nachrichten vom JMS Provider an das gewünschte Ziel weiterleiten. Die Properties ermöglichen es dem Entwickler neben den Standardinformationen des Headers optional weitere zusätzliche Informationen, wie applikationsspezifische und serverspezifische Eigenschaften, hinzuzufügen. Der Body enthält die eigentlichen Daten, die transportiert werden sollen. Die Art des Inhalts ist unterschiedlich und hängt vom Typ der Nachrichten ab. Die Typen von JMS werden durch das javax.jms.message Interface festgelegt und sind in Tabelle 1 aufgelistet. Tabelle 1: JMS Nachrichten Typen 12

13 Kapitel 3: Java Message Service 3.4 Interfaces Neben dem Message Interface stellt JMS noch weitere Interfaces bereit, die in jeder JMS Applikation genutzt werden. Im Einzelnen sind dies die administrativen Objekte Destination, ConnectionFactory, Connection und Session, sowie MessageProducer und MessageConsumer. Der in Abbildung 6 [JMS1.1, S. 24] dargestellte Zusammenhang zwischen den Interfaces ist für die beiden Kommunikationsmodelle P-t-P und Pub/Sub grundsätzlich gleich. Für jedes Modell gibt es jeweils eigene Subinterfaces. Connection Factory erzeugt Connection erzeugt Message Producer erzeugt Session erzeugt Message Consumer sendet an erzeugt erhält von Destination Message Destination Abbildung 6: Zusammenhang zwischen den Interfaces Ohne auf Details der einzelnen Interfaces einzugehen, lassen sich anhand dieser Abbildung bereits die notwendigen Schritte beschreiben, die zur Nutzung des JMS durchzuführen sind. Die Interfaces werden weiter unten ausführlicher beschrieben. Voraussetzung zur Durchführung der Schritte sind eine bereits vorhandene ConnectionFactory und eine Destination. Diese Komponenten werden im JMS Provider konfiguriert und sind nicht Bestandteil der Applikation. Um sie nutzen zu können, ist ein JNDI lookup notwendig. Zur Funktionsweise des JNDI siehe [MAY03, Kap.11]. Die ConnectionFactory erzeugt ein Connection Objekt. Mit dem Connection Objekt lässt sich eine Session erstellen. Das Session Objekt erzeugt einen Mes- 13

14 Kapitel 3: Java Message Service sageproducer, wenn eine Nachricht versendet werden soll, bzw. einen Message- Consumer, wenn eine Nachricht empfangen werden soll. Im ersten Fall wird auch Objekt vom Typ Message von der Session erstellt. Diese wird dann durch den MessageProducer versendet. Im Anhang ist ein kompletter Beispielcode aufgeführt, an dem die Zusammenhänge verdeutlicht werden. Eine Destination ist das Ziel einer Nachricht. Spezielle Destinations sind im Kontext von JMS die Queue oder das Topic, je nach dem zugrunde liegenden Kommunikationsmodell. Normalerweise werden diese im JMS Provider konfiguriert und können nicht direkt in der Applikation instanziiert werden. Eine Ausnahme bilden temporaryqueue und temporarytopic, die in Abschnitt beschrieben werden. Das Interface ist javax.jms.destination. Die Subinterfaces sind Queue für die P-t-P Kommunikation und Topic für das Pub/Sub Modell. Objekte vom Typ Connection werden in JMS ausschließlich mittels ConnectionFactories erzeugt. ConnectionFactories sind nur für die Erstellung von Connections zuständig. Auch die ConnectionFactory muss, wie die Destination, über einen JNDI lookup aufgerufen werden. Das Interface ist javax.jms.connectionfactory. Für die Kommunikationsmodelle P-t-P bzw. Pub/Sub sind die Subinterfaces Queue- ConnectionFactory und TopicConnectionFactory vorhanden. Ab der JMS Version 1.1 ist allerdings eine Unterscheidung nicht mehr notwendig [MAY03, S. 237]; es kann für beide Modelle das Interface ConnectionFactory benutzt werden. Nur aus Gründen der Abwärtskompatibilität mit älteren Versionen, sind die Subinterfaces noch vorhanden. JMS Connections repräsentieren eine Verbindung zwischen einem Client und einem JMS Provider, über welche Nachrichten gesendet werden [MC01, S. 142]. Connections steuern die Low-Level Kommunikation über das Netzwerk. Das Connection Interface ist javax.jms.connection. Entsprechend der ConnectionFactory hat auch Connection Subinterfaces, QueueConnection und TopicConnection, welche ebenfalls lediglich wegen der Abwärtskompatibilität vorhanden sind. Ein Objekt vom Typ Session arbeitet wie eine Fabrik für Objekte des Typs Message, MessageProducer und MessageConsumer [MC01, S. 27]. Nachrichten werden nicht direkt über Connections versendet, sondern durch ein Session Objekt erzeugt. Um ein Objekt vom Typ Session zu erstellen ist ein Connection Objekt 14

15 Kapitel 3: Java Message Service notwendig. Da ein Session Objekt eine Connection nutzt, stellt sie die Verbindung zwischen einem Client und dem JMS Provider her. Für die Kommunikation zwischen zwei Clients sind folglich mindestens zwei Sessions, vom MessageProducer zur Destination und von der Destination zum MessageConsumer, erforderlich. Das Interface ist javax.jms.session. Die Subinterfaces QueueSession und TopicSession werden auch nur für ältere Versionen benötigt. Nachdem die notwendigen administrativen Objekte (Destination, Connection- Factory, Connection und Session) erzeugt sind, können Nachrichten versendet und empfangen werden. Außer Nachrichten, deren Struktur in Abschnitt 3.3 beschrieben ist, erzeugt eine Session auch MessageProducer und MessageConsumer. Um Nachrichten versenden zu können, ist ein Objekt vom Typ MessageProducer notwendig. Das Interface für diesen ist javax.jms.message-producer und hat zwei Subinterfaces: QueueSender und TopicPublisher. Zur Erzeugung eines MessageProducers ist ein Session Objekt erforderlich. Mit dem Interface javax.jms.message-consumer lässt sich ein Objekt vom Typ MessageConsumer erzeugen. Auch dieses stellt zwei Subinterfaces bereit, Queue- Receiver und TopicReceiver. Wie in Abschnitt erwähnt, unterstützt JMS zur Weiterleitung von Nachrichten durch den JMS Provider den Pull und den Push- Mechanismus. Diese Mechanismen werden durch den MessageConsumer entweder mit der Methode receive() oder dem Interface MessageListener() umgesetzt [Mo02, S.36]. Wird der Pull-Mechanismus realisiert, holt sich der Konsument die Nachrichten vom JMS Provider ab. Dafür wendet der Client die receive() Methode an. Durch den Aufruf der Methode liefert der Server die nächste Nachricht. Ist momentan keine Nachricht vorhanden, blockiert der Konsument so lange, bis eine neue kommt. Um diese Blockade zu begrenzen, kann als Argument ein Zeitintervall in Millisekunden angegeben werden. Die Methode hat dann die Form receive(long timeout). Der Konsument blockiert nur in dem vorgegebenen Intervall. Durch Anwendung der Methode receivenowait() wird die Blockierung des Konsumenten verhindert. Alternativ kann der Push-Mechanismus realisiert werden. Der Konsument lässt sich Nachrichten zustellen, sobald sie verfügbar sind. Dazu muss ein Objekt erzeugt werden, welches das MessageListener()Interface implementiert. Dieses Interface enthält 15

16 Kapitel 3: Java Message Service nur die Methode onmessage(). Die Methode definiert was gemacht werden soll, wenn eine Nachricht eintrifft. Sie enthält ein Argument vom Typ Message. Ein MessageListener Objekt verhält sich wie ein asynchroner event handler für Nachrichten. Durch den Aufruf der Methode setmessagelistener()wird ein Message- Listener bei einem spezifischen QueueReceiver oder TopicSubscriber registriert. Wird eine Nachricht überbracht, ruft der Client automatisch die onmessage() Methode auf. Wie in Kapitel 4 noch gezeigt wird, sind Message Driven Beans eine spezielle Form des Typs MessageListener. 3.5 Erweiterte Konzepte Nachdem die bisherigen Abschnitte die Grundlagen zur Nutzung des JMS gelegt haben, soll nun auf einige erweiterte Konzepte eingegangen werden. Hierbei wurden Konzepte ausgewählt, die Sicherheitsaspekte adressieren und dementsprechend insbesondere im Rahmen der EAI relevant sind. Dazu zählen Aspekte der Zuverlässigkeit, Transaktionen und der Request/Reply Mechanismus Zuverlässigkeit Die Zuverlässigkeit der Nachrichtenübertragung kann auf den drei Ebenen Nachrichtenproduzent, JMS Provider und Nachrichtenkonsument beeinflusst werden. Auf Ebene des Produzenten kann der Übertragungsmodus, auf Ebene des JMS Providers das Quittierungsverhalten und auf Ebene des Konsumenten der Subskriptionstyp festgelegt werden. Diese drei Möglichkeiten zur Beeinflussung der Zuverlässigkeit sind Gegenstand dieses Abschnitts. Bei der Wahl des gewünschten Zuverlässigkeitsgrads ist zu berücksichtigen, dass höhere Zuverlässigkeit immer schlechtere Performanz nach sich zieht. Auf Ebene des Nachrichtenproduzenten kann Übertragungsmodus festgelegt werden, der sich auf die Art der Nachrichtenspeicherung durch den Server bezieht [MC01, S.85]. In Abhängigkeit, ob eher Zuverlässigkeit oder Performanz gewünscht ist, unterstützt JMS die Übertragungsmodi nicht-persistent oder persistent. Wenn die Performanz wichtiger und der Verlust einer Nachricht als nicht kritisch zu bewerten ist, kann der Modus nicht-persistent gewählt werden. Da die Nachricht vom Server nicht auf einen stabilen Speicher abgelegt werden muss, entsteht weniger Overhead. Allerdings kann die Nachricht bei einem Serverabsturz verloren gehen. Ist die zuverlässige Nachrichtenübermittlung unerlässlich, muss der Modus persistent gewählt werden. 16

17 Kapitel 3: Java Message Service Die Nachricht wird von dem JMS Provider so abgespeichert, dass sie auch bei einem Serverabsturz nicht verloren geht. Persistent ist der default Wert. Das von JMS bereitgestellte DeliveryMode Interface sieht folgendermaßen aus: public interface DeliveryMode { static final int NON_PERSISTENT = 1; static final int PERSISTENT = 2; Informationen über die Art des Übertragungsmodus sind im Header der Nachricht hinterlegt. Ist eine Nachricht bei dem JMS Provider angekommen, dann obliegt es seiner Verantwortung die Nachricht an den oder die Konsumenten weiterzuleiten. Erst wenn die Nachricht nachweislich das gewünschte Ziel erreicht hat, löscht der Server die Nachricht. Der Nachweis erfolgt in Form einer Rückmeldung bzw. Quittierung vom Konsument. Solange eine Nachricht nicht quittiert wurde, versucht der Server sie erneut zu versenden, bis er die Rückmeldung erhält. Dieses Verhalten des Servers ist bei der Wahl des Modus zu beachten. Im JMS sind die drei in Tabelle 2 beschriebenen Rückmeldungsmodi möglich. Modus Session.AUTO_ACKNOWLEDGE Session.CLIENT_ACKNOWLEDGE Session.DUPS_OK_ACKNOWLEDGE Beschreibung Sobald die Session des Konsumenten eine Nachricht erhält, quittiert sie den Empfang automatisch. Dieser Modus garantiert das eine Nachricht once-and-only-once ein Ziel erreicht und wird normalerweise angewendet. Nicht die Session, sondern der Client quittiert den Empfang einer Nachricht. Er braucht nicht sofort jede einzeln zu quittieren, sondern kann dies für mehrere auf einmal machen. Bei diesem Modus erfolgt die Quittierung mittels der Session nicht automatisch., sondern es bleibt der Session überlassen, wann sie dies macht. Tabelle 2: Die drei Rückmeldungsmodi Der Modus wird bei der Erstellung einer Session als zweites Argument angegeben und ist vom Typ int. Das Mapping zwischen den int Werten und den Modi ist Serverspezifisch. Im Beispiel sieht das folgendermaßen aus: 17

18 Kapitel 3: Java Message Service session = connection.createsession(false, Session.AUTO_ACKNOWLEDGE); Bei der Wahl des Rückmeldungsmodus ist zu beachten, dass jede Nachricht, die ein JMS Provider an einen Konsument versendet, quittiert werden muss. Ist der Empfang einer Nachricht noch nicht quittiert, verschickt der JMS Provider sie erneut. Die Modi Session.CLIENT_ACKNOWLEDGE und Session.DUPS_OK_ACKNOWLEDGE ermöglichen eine bessere Performanz, da mehrer Nachrichten zusammen quittiert werden können. Allerdings müssen die Konsumenten bei diesen Modi den wiederholten Empfang der gleichen Nachricht verarbeiten können [Mo02, S.34]. Das JMS Publish/Subscribe Kommunikationsmodell unterstützt zwei mögliche Subskriptionstypen, nicht-dauerhaft und dauerhaft. Nicht-dauerhaft bedeutet, dass ein Client eine Nachricht nur erhält, wenn der Abonnent zum Zeitpunkt der Veröffentlichung aktiv ist. Ist er nicht aktiv, erhält der Client die Nachricht nicht. Abonnenten dieser Art werden mit der Methode Session.createSubsriber() erzeugt. Durch die Methode Session.createDurableSubsriber()lässt sich ein dauerhafter Abonnent erzeugen, der alle unter einem Topic veröffentlichten Nachrichten bekommt, auch wenn er nicht immer aktiv ist. Der JMS Provider stellt die Nachricht an den Abonnenten zu, sobald dieser wieder welche empfangen kann. Dieser Mechanismus ist auch unter dem Namen store-and-forward bekannt [MAY03, S.236]. Da sichergestellt ist, dass der Abonnent alle Nachrichten erhält, ist das Pub/Sub Modell durch diesen Mechanismus genauso zuverlässig, wie das P-t-P Modell. Zwischen den Ebenen bestehen Zusammenhänge, die bei der Implementierung berücksichtigt werden müssen. Wenn beispielsweise eine Nachricht an einen dauerhaften A- bonnenten geschickt und der Modus nicht-persistent benutzt wird, kann die Nachricht verloren gehen. Das ist möglich, wenn der Abonnent nicht aktiv ist und der Server abstürzt. Deswegen sollte für Nachrichten die an dauerhafte Abonnenten gesendet werden immer der Modus persistent gewählt werden Transaktionen Durch Verwendung von Transaktionen kann sichergestellt werden, dass zusammenhängende Nachrichten entweder alle zusammen oder gar nicht versendet werden [MC01, 18

19 Kapitel 3: Java Message Service S.95ff.]. Das Transaktionskonzept bietet erweiterte, auf mehrere Nachrichten bezogene Zuverlässigkeit. Das Transaktionsverhalten wird bei der Erzeugung einer Session festgelegt. Es ist vom Typ boolean. Sollen mehrere Nachrichten atomar versendet bzw. empfangen werden, ist der Wert true als Argument einzutragen. Sind Transaktionen nicht erwünscht, wird false als Argument angegeben. Eine Transaktion wird innerhalb einer Session ausgeführt. Da Produzent und Konsument unterschiedliche Sessions benutzen, bezieht sich eine Transaktion entweder auf das Versenden oder den Empfang von Nachrichten. Es ist möglich eine Nachricht, die über eine transaktionale Session versendet wurde, innerhalb einer nicht-transaktionalen Session zu empfangen et vice versa [DP02, S.265]. Ein Produzent benutzt eine Transaktion, um zuverlässig mehrere Nachrichten zusammen zu versenden. Die Transaktion startet automatisch, wenn eine Session mit Transaktionsverhalten erstellt wird. Nachrichten, die der Produzent innerhalb einer Transaktion erzeugt, werden erst als ein Paket an die Queue oder das Topic gesendet, wenn der Produzent session.commit()aufruft. Danach startet innerhalb der Session automatisch die nächste Transaktion. Da es keine Methode zum manuellen Aufruf einer Transaktion gibt, sind deswegen verschachtelte Transaktionen nicht möglich. Der Aufruf von session.rollback() bewirkt, dass alle Nachrichten nach dem letzten Aufruf von commit()verworfen werden. Die Nutzung von Transaktionen durch den Produzent wird an einem Beispiel dargestellt: session = connection.createsession(true, Session.Auto_ACKNOWLEDGE); MessageProducer producer = session.createproducer(); /** Sende einige Nachrichten durch den Produzenten */ if(erfolgreich) session.commit(); else session.rollback(); Auf Seite des Konsumenten läuft die Transaktion ähnlich ab. Durch den session.commit()aufruf quittiert der Konsument die empfangenen Nachrichten. Erst nach Aufruf dieser Methode löscht der JMS Provider die Nachricht. Wenn sessi- 19

20 Kapitel 3: Java Message Service on.rollback() vom Konsument aufgerufen wird, versendet der JMS Provider alle Nachrichten seit dem letzten session.commit() erneut. Da bei einer Transaktion der Empfang der Nachrichten erst durch den Aufruf der commit() Methode quittiert werden kann, sind die anderen Rückmeldungsmodi, die in Abschnitt beschrieben wurden, für Transaktionen nicht relevant Request Reply Grundsätzlich entspringt die Idee der asynchronen Kommunikation aus der Entkopplung von dem Produzent und dem Konsumenten einer Nachricht. Nachdem der Produzent die Nachricht an den JMS Provider versendet hat, arbeitet er weiter, ohne auf ein Ergebnis bzw. eine Antwort zu warten. Er hat auch keine Informationen darüber, wer seine Nachricht wann bearbeitet. Der Konsument bekommt die Nachricht vom JMS Provider und hat seinerseits keine Informationen über den Produzenten. Für manche Prozesse benötigt der Produzent aber eine Antwort auf eine spezielle Nachricht, um weiterarbeiten zu können. Der von JMS spezifizierte Request/Reply Mechanismus gewährleistet dieses Verhalten [DP02, S. 269ff.;Mo02, Kap.6]. Dieser Mechanismus ermöglicht synchrone Kommunikation. Von zentraler Bedeutung für die Umsetzung, ist die Erzeugung einer temporären Destination, an die der Konsument die Antwort senden kann. Temporärere Destinations gibt es in der Form TemporaryQueue und TemporarayTopic. Durch die beiden Methoden QueueSession.createTemporaryQueue und TopicSession.createTemporaryTopic werden sie dynamisch erstellt. Sie existieren nur solange, wie die Connection besteht, innerhalb der sie erzeugt wurden. Nur die Konsumenten, die von der gleichen Connection wie die temporäre Destination erzeugt wurden, können die Antworten verarbeiten. Wenn eine temporäre Destination erzeugt wurde und im Header Feld JMSReplyTo der Nachricht an den Konsumenten übergeben wird, kann dieser eine Antwort an die angegebene Destination zurücksenden. 20

Kapitel 8: Nachrichtenbasierte Kommunikation mit JMS. Middleware in Java vieweg 2005 Steffen Heinzl, Markus Mathes

Kapitel 8: Nachrichtenbasierte Kommunikation mit JMS. Middleware in Java vieweg 2005 Steffen Heinzl, Markus Mathes Kapitel 8: Nachrichtenbasierte Kommunikation mit JMS Middleware und nachrichtenorientierte Middleware Eine Software heißt Middleware genau dann, wenn sie die Entwicklung und den Betrieb eines verteilten

Mehr

Enterprise Application Integration. 8. Nachrichten-orientierte Middleware

Enterprise Application Integration. 8. Nachrichten-orientierte Middleware Enterprise Application Integration 8. Nachrichten-orientierte Middleware Kommunikation zwischen IS in Unternehmen eng Remote Procedure Calls/ Remote Method Invocation, z.b. bei: CORBA EJB DCOM+ Web Services

Mehr

Message Oriented Middleware (MOM) Java Message Service (JMS)

Message Oriented Middleware (MOM) Java Message Service (JMS) Message Oriented Middleware (MOM) Java Message Service (JMS) Vorlesung: Applikationsserver Prof. Dr. Ch. Reich rch@fh furtwangen.de http://www.informatik.fh furtwangen.de/~reich Message Oriented Middleware

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Enterprise Softwarearchitekturen in Java

Enterprise Softwarearchitekturen in Java Enterprise Softwarearchitekturen in Java Dauer: 5 Tage 1. Tag: Vorbereitungstag...2 Der erste Tag richtet sich an alle, die bislang wenig Praxiserfahrung mit der Programmiersprache Java haben. Die Teilnehmer

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

Mehr

JMS JAVA MESSAGE SERVICES. Entwicklung von Webanwendungen SS 07

JMS JAVA MESSAGE SERVICES. Entwicklung von Webanwendungen SS 07 JMS JAVA MESSAGE SERVICES Entwicklung von Webanwendungen SS 07 Marc Seeger Stephan Helten [ms155] [sh094] Agenda Teil 1: Marc Seeger [ms155] Einführung: Was ist Messaging Message Oriented Middleware [MOM]

Mehr

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg COMMON OBJECT REQUEST BROKER ARCHITECTURE Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg Gliederung Motivation Was ist CORBA? Object Management Architecture (OMA ) Interface Definition Language

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

Anwendung eines Enterprise Java Beans

Anwendung eines Enterprise Java Beans Anwendung eines Enterprise Java Beans EJB Server EJB Container Remote Interface Home Interface EJB Object Der EJB Container kümmert sich um die Kommunikation des Beans mit anderen Komponenten, wobei er

Mehr

JMS Java Message Service

JMS Java Message Service JMS Java Message Service TK3 - WS03/04 Dipl.-Ing. Erwin Aitenbichler Abt. Telekooperation TU Darmstadt 1 JMS: Java Message Service Messaging Lose gekoppelte verteilte Kommunikation RMI: Eng gekoppelt Sender

Mehr

Vorlesung Internetprogrammierung

Vorlesung Internetprogrammierung Vorlesung Internetprogrammierung Message-Driven Beans Peter Thiemann Universität Freiburg Vorlesung Internetprogrammierung, SS2006 Inhalt 1 Java Message Service 2 Beispiel 3 Arten von Nachrichten 4 Eine

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

10.4 JMS - Java Message Service

10.4 JMS - Java Message Service 10.4 JMS - Java Message Service ist Schnittstelle zu MOM-Implementierungen verschiedener Anbieter (z.b. IBM MQSeries) ist sehr liberal bezüglich der Semantik dieser Implementierungen unterstützt sowohl

Mehr

Enterprise Java Beans (EJB)

Enterprise Java Beans (EJB) silbergrau Consulting & Software GmbH Enterprise Java Beans (EJB) Fachhochschule Hagenberg WS 2002 / 2003 Silbergrau Consulting & Software GmbH Dr. Andreas Erlach Inhaltsübersicht Application Server J2EE

Mehr

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de

Session Beans & Servlet Integration. Ralf Gitzel ralf_gitzel@hotmail.de s & Servlet Integration Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Motivation Das Interface Stateful und Stateless s Programmierung einer Stateful

Mehr

3 Programmiermodelle für parallele und verteilte Systeme

3 Programmiermodelle für parallele und verteilte Systeme 3 Programmiermodelle für parallele und verteilte Systeme Das vorherrschende Programmiermodell für parallele und verteilte Systeme ist das Client Server Modell. Das Client Server Modell ist unabhängig von

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

Oracle Advanced Queuing AQ

Oracle Advanced Queuing AQ Oracle Advanced Queuing AQ 13.09.2012 Referenten: Claus Cullmann Andreas Steinel Inhalt Motivation Message Systeme Eigenschaften, Beispiele Oracle AQ Terminologie AQ Beispiel pure SQL Beispiel Java-Anwendung

Mehr

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA Hauptseminar Management von Softwaresystemen Techniken der System-Integration EAI, Middleware, SOA, CORBA Betreuerin: Referent: Ulrike Hammerschall Alexey Krivoborodov Agenda Motivation Arten der Verteilung

Mehr

Warum EJB Technologie (1)?

Warum EJB Technologie (1)? Datenbanken und Informationssysteme 2 SS 2004 Prof. Dr. Stefan Böttcher Universität Paderborn Datenbanken und Informationssysteme 2 - Prof. Dr. Stefan Böttcher - SS 2004 Folie EJB - 1 Warum EJB Technologie

Mehr

Seminarhausarbeit Java Message Service

Seminarhausarbeit Java Message Service Fachbereich Angewandte Informatik an der Fachhochschule Bonn Rhein Sieg Seminar: Verteilte und Paralle Systeme I Seminarhausarbeit Java Message Service 10. Juni 2002 Themensteller: Prof. Dr. Rudolf Berrendorf

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP)

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP) Enterprise Applikation Integration und Service-orientierte Architekturen 09 Simple Object Access Protocol (SOAP) Anwendungsintegration ein Beispiel Messages Warenwirtschaftssystem Auktionssystem thats

Mehr

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany

J2EEKurs. Enterprise JavaBeans Einführung. Peter Thiemann. Sommercampus J2EEKurs, Freiburg, Germany, 10.-14.10.2005. Universität Freiburg, Germany Enterprise JavaBeans Einführung Universität Freiburg, Germany Sommercampus, Freiburg, Germany, 10.-14.10.2005 Inhalt Allgemeines Motivation Rollen Aufbau einer EJB Arten von Beans Enterprise JavaBeans

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen 6.3Publish/Subscribe-Techniken

Mehr

Java Beans Enterprise Java Beans. Eine kurze Einführung in die Welt der Bohnen

Java Beans Enterprise Java Beans. Eine kurze Einführung in die Welt der Bohnen Java Beans Enterprise Java Beans Eine kurze Einführung in die Welt der Bohnen Java Beans Einführung Stefan Sauer Was ist ein Java Bean? Beans sind Komponenten. Einmal schreiben Überall wiederverwerten

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) G 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten G 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen G 6.3Publish/Subscribe-Techniken

Mehr

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013 WebSphere MQ Teil 3 Trigger el0100 Copyright W. G. Spruth,

Mehr

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 11 Dr. H. Ehler, S. Wagner 23. Januar 2004 Übungen zu Softwaretechnik Aufgabe 16 Qualitätseigenschaften Broker-Pattern Beurteilen Sie das in Aufgabe 15 benutzte

Mehr

E.1 Object Request Brokers

E.1 Object Request Brokers E Überblick über die 4. Übung E Überblick über die 4. Übung 1 Komponenten eines ORBs Lösungsskizze Aufgabe 2 RPC und ORB Aufrufsemantiken Hinweise Aufgabe 3 Kommunikationsschicht: tauscht Daten zwischen

Mehr

Seminarvortrag Serviceorientierte Softwarearchitekturen

Seminarvortrag Serviceorientierte Softwarearchitekturen Seminarvortrag Serviceorientierte Softwarearchitekturen vorhandene Altsysteme Gliederung Einführung Grundlegende Modelle Grundlegende Komponenten Architekturen 2 Einführung Altanwendung und Altsysteme?

Mehr

-Testen verteilter Anwendungen

-Testen verteilter Anwendungen -Testen verteilter Anwendungen Seminar Simulation und Bildanalyse mit Java im SS04 Konstantin Tjo, Urs Pricking Testen verteilter Anwendungen 1 Übersicht Einführung in verteilte Anwendungen RMI (Remote

Mehr

Standardsoftware II. Klassifikation Schnittstellen

Standardsoftware II. Klassifikation Schnittstellen Standardsoftware II Schnittstellen zu ERP-Systemen Schnittstellen-1 Klassifikation Schnittstellen datenorientierte funktionale objektorientierte Schnittstellen-2 Was zeichnet eine Schnittstelle aus? Merkmale

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

Client/Server-Programmierung

Client/Server-Programmierung Client/Server-Programmierung WS 2014/2015 Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 15. Oktober 2015 Betriebssysteme / verteilte

Mehr

Client/Server-Programmierung

Client/Server-Programmierung Client/Server-Programmierung WS 2014/2015 Betriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 15. Oktober 2015 Betriebssysteme / verteilte

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Java RMI Remote Method Invocation

Java RMI Remote Method Invocation Java RMI Remote Method Invocation Ziel: Aufruf von Instanzmethoden entfernter Objekte basierend auf Java. Paket: java.rmi und Unterpakete Topologie: RMI Registry RMI Server RMI Client Der Server registriert

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013

Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung. September 2013 GTUG Java Arbeitskreis Erste Erfahrungen mit NSASJ anhand der OmnivoBase Portierung September 2013 Jürgen Depping CommitWork GmbH Seite 1 Info@CommitWork.de www.commitwork.de Agenda Was ist OmnivoBase?

Mehr

.NET-Networking 2 Windows Communication Foundation

.NET-Networking 2 Windows Communication Foundation .NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile

Mehr

Anleitung. Ein einfaches RMI-Beispiel. (ab Java 5.0) c Y. Pfeifer. (Juni 2014)

Anleitung. Ein einfaches RMI-Beispiel. (ab Java 5.0) c Y. Pfeifer. (Juni 2014) Anleitung Ein einfaches RMI-Beispiel (ab Java.0) c Y. Pfeifer (Juni 014) 1 Ein einfaches RMI-Beispiel Vorgehensweise: 1. Java Projekt anlegen. Zwei Packages server & client erstellen Auf der Server-Seite

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

WebSphere Application Server Installation

WebSphere Application Server Installation WebSphere Application Server Installation und Administration Seminarunterlage Version: 3.04 Copyright Version 3.04 vom 16. Mai 2013 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte

Mehr

Enterprise Service Bus

Enterprise Service Bus Enterprise Service Bus Christopher Weiß 25.01.2010 Gliederung 1 Motivation und Einordung Integrationsformen 2 Definition und Eigenschaften Definitionen Eigenschaften 3 Aufbau und Konzepte Aufbau Produkte

Mehr

Web-Services Implementierung mit Java

Web-Services Implementierung mit Java Web-Services Implementierung mit Java J. Heinzelreiter WS 2004/05 Java-APIs für Web-Services (1) Anwendungs-Code JAXR JAXM JAX-RPC SAAJ SOAP/SwA JWSDL WSDL XML/XML-Schema Web-Services/Java - 2 Java-APIs

Mehr

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1 Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 31.03.2003 J.M.Joller 1 Inhalt Architekturen Main Stream.NET J2EE und Applikations-Server Sicht der Anbieter Java J2EE J2EE versus.net Web

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

Business Process Management und Enterprise Service Bus

Business Process Management und Enterprise Service Bus Business Process Management und Enterprise Service Bus Gegner oder doch eine gute Ergänzung? Author: Date: Markus Demolsky Soreco International 08. November 2010 Vortragender Warum über Integration nachdenken?

Mehr

EJB jar.xml und Name Service (JNDI)

EJB jar.xml und Name Service (JNDI) EJB jar.xml und Name Service (JNDI) Applikationsserver Prof. Dr. Ch. Reich rch@fh furtwangen.de http://www.informatik.fh furtwangen.de/~reich/appserver/index.html Beschreibung der Beans mit Deployment

Mehr

VS3 Slide 1. Verteilte Systeme. Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel

VS3 Slide 1. Verteilte Systeme. Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel VS3 Slide 1 Verteilte Systeme Vorlesung 3 vom 22.04.2004 Dr. Sebastian Iwanowski FH Wedel Inhaltsverzeichnis für die Vorlesung Zur Motivation: 4 Beispiele aus der Praxis Allgemeine Anforderungen an Verteilte

Mehr

Integration von Web Services in J EE Anwendungen mit XFire. 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire

Integration von Web Services in J EE Anwendungen mit XFire. 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire Integration von Web Services in J EE Anwendungen mit XFire 1/26 André Janus - Integration von Web Services in J EE Anwendungen mit XFire univativ : = Umsetzung durch Studenten und Young Professionals.

Mehr

EJB Beispiel. JEE Vorlesung 10. Ralf Gitzel ralf_gitzel@hotmail.de

EJB Beispiel. JEE Vorlesung 10. Ralf Gitzel ralf_gitzel@hotmail.de EJB Beispiel JEE Vorlesung 10 Ralf Gitzel ralf_gitzel@hotmail.de 1 Stundenkonzept Gemeinsame Übung Stoff der letzten Stunde wird gemeinsam in einem Beispiel umgesetzt Details werden nochmals erklärt bzw.

Mehr

Enterprise JavaBeans

Enterprise JavaBeans Enterprise JavaBeans Sebastian Pipping 18. Dezember 2006 This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. Teil I J2EE J2EE Was ist J2EE? Was ist J2EE?

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e Servlet Debugging

i n g e n i e u r b ü r o f ü r s o f t w a r e t e c h n o l o g i e w w w. v o e l t e r. d e Servlet Debugging Servlet Debugging Markus Völter, voelter@acm.org, www.voelter.de Bei der Arbeit mit Servlets kommt man recht schnell an den Punkt, an dem man Servlets vernünftig testen oder debuggen will. Mit Hilfe des

Mehr

Enterprise JavaBeans Überblick: 17. Enterprise Information System Schicht

Enterprise JavaBeans Überblick: 17. Enterprise Information System Schicht Enterprise JavaBeans Überblick 1. Überblick Komponententechnologien 2. Einführung 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen

UNIVERSITÄT LEIPZIG. Mainframe Internet Integration SS2013. Java Enterprise Edition Teil 4. Schnittstellen UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Enterprise Edition Teil 4 Schnittstellen el0100 copyright W. G. Spruth, wgs 04-10

Mehr

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2011 CS104 Programmieren II / CS108 Programmier-Projekt Java-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

Oracle Enterprise Scheduler (ESS) Unleashed Carsten Wiesbaum esentri AG Ettlingen Schlüsselworte Einleitung Oracle Enterprise Scheduler (ESS)

Oracle Enterprise Scheduler (ESS) Unleashed Carsten Wiesbaum esentri AG Ettlingen Schlüsselworte Einleitung Oracle Enterprise Scheduler (ESS) Oracle Enterprise Scheduler (ESS) Unleashed Carsten Wiesbaum esentri AG Ettlingen Schlüsselworte Automatisierung, Betrieb, Middleware Einleitung Der Oracle Fusion Middleware Stack beinhaltet eine leistungsstarke

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

Mehr

Auszug aus JAX-WS Folien

Auszug aus JAX-WS Folien Auszug aus JAXWS Folien Dieses Dokument ist ein Auszug aus unserem Skript zur Java Web Services Schulung. Es dient lediglich als Beispiel für unsere Kursunterlagen. Thomas Bayer Hauptstraße 33 75050 Gemmingen

Mehr

Musterlösung Übungsblatt 2 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 2 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 2 Netzprogrammierung WS 05/06 Aufgabe 1 Bitte schreiben Sie ein RMI Objekt, das eine Person repräsentiert. Es soll die folgende Schnittstelle implementieren: public interface Person

Mehr

Enterprise Application Integration

Enterprise Application Integration 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Wolfgang Keller Enterprise Application Integration Erfahrungen aus

Mehr

ObjectBridge Java Edition

ObjectBridge Java Edition ObjectBridge Java Edition Als Bestandteil von SCORE Integration Suite stellt ObjectBridge Java Edition eine Verbindung von einem objektorientierten Java-Client zu einer fast beliebigen Server-Komponente

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

Java TV. Seminar Medientechnik. Kristin Doppler 23.06.2003. Übersicht. Einleitung Umgebungen Java TV API - Kategorien. Service- und Selektions-APIs

Java TV. Seminar Medientechnik. Kristin Doppler 23.06.2003. Übersicht. Einleitung Umgebungen Java TV API - Kategorien. Service- und Selektions-APIs Java TV Seminar Medientechnik 23.06.2003 Übersicht Einleitung Umgebungen Java TV API - Kategorien Service- und Selektions-APIs Definitionen Packages Service Selection API Application Lifecycle APIs (Xlets)

Mehr

Mufid Sulaiman mufidsulaiman@web.de

Mufid Sulaiman mufidsulaiman@web.de Mufid Sulaiman mufidsulaiman@web.de Überblick Frameworks Applikationsentwicklung mit Frameworks Komponentenbasierte Frameworks Einführung in Enterprise JavaBean Einführung in SanFrancisco Vergleich Enterprise

Mehr

Der lokale und verteilte Fall

Der lokale und verteilte Fall Lokale Beans Der lokale und verteilte Fall RemoteClient Lokaler Client (JSP) RemoteSession/Entity-Bean Lokale Session/Entity-Bean 2 Lokale Beans Die bisher vorgestellten EJBswaren immer in der Lage auf

Mehr

Remote Method Invocation

Remote Method Invocation Remote Method Invocation spezielle Technik aus dem Java-Umfeld Ausführung der Methoden auf einem entfernten Rechner Analogon zum RPC (Remote Procedure Call) Zweck: Objekte in verschiedenen Java-VM s Aufruf

Mehr

Client/Server-Programmierung WS2007/08. EJB/JSP: Schritt-für-Schritt Anleitung

Client/Server-Programmierung WS2007/08. EJB/JSP: Schritt-für-Schritt Anleitung Client/Server-Programmierung WS2007/08 EJB/JSP: Schritt-für-Schritt Anleitung Version 1.1, 26.09.07 Eingesetzte Software: - Apache Tomcat 5.5.9 bzw. 5.5.12 (http://tomcat.apache.org/download-55.cgi#5.5.12)

Mehr

Seminararbeit Embedded Systems - Discovery Mechanismus für sdds. Kevin Sapper

Seminararbeit Embedded Systems - Discovery Mechanismus für sdds. Kevin Sapper Seminararbeit Embedded Systems - Discovery Mechanismus für sdds Kevin Sapper Seminararbeit Embedded Systems - Discovery Mechanismus für sdds Kevin Sapper Table of Contents... v 1. Einführung... 1 2. Grundlagen...

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

COPPER Best Practices

COPPER Best Practices COPPER Best Practices Version 1.0.1 Wann sollte man überhaupt COPPER verwenden? Allgemein genau dann, wenn man von der COPPER Notation oder den COPPER-Features profitieren kann. Ein wesentliches Feature

Mehr

Systemprogrammierung. Projekt: Java RMI. Wintersemester 2006 / 2007

Systemprogrammierung. Projekt: Java RMI. Wintersemester 2006 / 2007 Systemprogrammierung Projekt: Java RMI Wintersemester 2006 / 2007 Systemprogrammierung 1. Einleitung 2. Einführung in RPC 3. RMI 4. Code Beispiele 5. Live Vorstellung 6. Ausblick 7. Fazit 2 1. Einleitung

Mehr

Abbildung 3-1: Clients und Server C+S

Abbildung 3-1: Clients und Server C+S Abbildung 3-1: Clients und Server C+S Abbildung 3-2: Interaktions-koordinations-arten Abbildung 3-3: Zuverlässige Nachrichtenübertragung a) durch individuell quittierte Nachrichten b) durch Quittierung

Mehr

Der IBM Websphere Portalserver

Der IBM Websphere Portalserver Der IBM Websphere Portalserver Ergebnisse aus dem Universitäts-Praxis-Projekt 2001/2002 Vortrag von Il-Hyun Kim und Horst Rechner am 19. Juli 2002 Weiterer Teilnehmer am UPP: Clemens Oertel Betreuer: Dipl.-Phys.

Mehr

Mobile und Verteilte Datenbanken

Mobile und Verteilte Datenbanken Mobile und Verteilte Datenbanken Java RMI Vorlesung Wintersemester 2013/2014 groppe@ifis.uni-luebeck.de Institut für Informationssysteme Universität zu Lübeck Kommunikations-Middleware Bietet höhere Kommunikations-Dienste

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung Kapitel 6 Vererbung Vererbung 1 Ziele Das Vererbungsprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen

Mehr

Vgl. Oestereich Kap 2.7 Seiten 134-147

Vgl. Oestereich Kap 2.7 Seiten 134-147 Vgl. Oestereich Kap 2.7 Seiten 134-147 1 Sequenzdiagramme beschreiben die Kommunikation/Interaktion zwischen den Objekten (bzw. verschiedenen Rollen) eines Szenarios. Es wird beschrieben, welche Objekte

Mehr

Handbuch für die Erweiterbarkeit

Handbuch für die Erweiterbarkeit Handbuch für die Erweiterbarkeit Inhalt Pakete für die Erweiterbarkeit... 2 Actions... 2 Items... 2 Itemset... 2 Die UseCaseNewAction... 3 Eigene Shapes... 4 Der Shape Container... 5 User Objects... 6

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Spring Dynamic Modules for OSGi Service Platforms

Spring Dynamic Modules for OSGi Service Platforms Gerd Wütherich freiberuflicher Softwarearchitekt Spring Dynamic Modules for OSGi Service Platforms Server Anwendungen mit Spring und Eclipse Equinox Agenda OSGi Technologie: OSGi Technologie im Überblick

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2012 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Musterlösung Klausur SS 2004

Musterlösung Klausur SS 2004 Musterlösung Klausur SS 2004 Fachrichtung: Informatik Lehrveranstaltung: Verteilte Systeme Dozent: Prof. G. Bengel Tag: 15.6.04 Bearbeitungszeit: 90 Minuten Name:... Matr.Nr.:... Punkte:... Note:... Hilfsmittel:

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Objektorientierte Programmierung 1 Geschichte Dahl, Nygaard: Simula 67 (Algol 60 + Objektorientierung) Kay et al.: Smalltalk (erste rein-objektorientierte Sprache) Object Pascal, Objective C, C++ (wiederum

Mehr

Java Messaging Service JMS

Java Messaging Service JMS In diesem Kapitel: Einführung in JMS Die JMS Spezifikation Einführung Architektur Das JMS Messaging Modell JMS Common Facilities JMS Point-to-Point Modell JMS Publish / Subscribe Modell Einfache Beispiele

Mehr

Workshop Java Webentwicklung Einführung in Hibernate. Ulrich Stärk

Workshop Java Webentwicklung Einführung in Hibernate. Ulrich Stärk Workshop Java Webentwicklung Einführung in Hibernate Ulrich Stärk Ablauf Montag bis Donnerstag 09:00 Uhr s.t. Beginn, bis ca. 17:00 Uhr 1 Stunde Mittagspause Donnerstag Experiment Aufzeichnung der Programmiertätigkeit

Mehr