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

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

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

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

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

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

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

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

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

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

-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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

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

Technische Universität Dresden Prof. Hußmann Softwarekomponenten. 3.3 Enterprise JavaBeans-Technologie

Technische Universität Dresden Prof. Hußmann Softwarekomponenten. 3.3 Enterprise JavaBeans-Technologie Gliederung 1. Software-Komponenten: Grundlegende Begriffe 2. Systematischer Entwicklungsprozess für Komponenten-Software mit UML 3. Java-Komponenten-Technologien 3.1 JavaBeans-Technologie 3.2 Web-Komponenten

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

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Enterprise JavaBeans Basics Enterprise JavaBeans (EJB) Enterprise JavaBeans (EJB) Komponenten sind wohl definiert verteilt (MI-based) serverseitig Sie dienen

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

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

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

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

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

Variablen manipulieren per JDI

Variablen manipulieren per JDI Variablen manipulieren per JDI Zusammenfassung Jede moderne Java IDE verfügt über eine mächtige und dennoch meist einfach zu bedienende Benutzeroberfläche die das finden von Fehlern in lokalen oder entfernt

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

Enterprise Java Beans

Enterprise Java Beans Enterprise Java Beans Beispiel Minibank nur: Kunde, Konto, Überweisung personen.person Attributes Name:String Vorname:String überweisungen.überweisung Attributes Verwendungszweck:String Datum:Date betrag:integer

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

.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

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

11. Enterprise Java Beans Grundlagen der Programmierung II (Java)

11. Enterprise Java Beans Grundlagen der Programmierung II (Java) 11. Enterprise Java Beans Grundlagen der Programmierung II (Java) Prof. Dr. Bernhard Humm Hochschule Darmstadt University of Applied Sciences Sommersemester 2006 Übersicht Grundlagen der Programmierung

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

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

Mehr

WebSphere and Message Driven Beans

WebSphere and Message Driven Beans 6 xxx WebSphere and Message Driven Beans Abteilung Technische Informatik, Institut für Informatik, Universität Leipzig Abteilung Technische Informatik, Wilhelm Schickard Institut für Informatik, Universität

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

Modul Software Komponenten 10 Komponentenarchitektur

Modul Software Komponenten 10 Komponentenarchitektur Modul Software Komponenten 10 Komponentenarchitektur Teil 3 Peter Sollberger Eine erste CORBA Anwendung Inhalt Dienstag, 4. November Object Request Broker CORBA Architektur und Komponenten (Teil 1) Übung:

Mehr

Liste V Enterprise JavaBeans

Liste V Enterprise JavaBeans Liste V Enterprise JavaBeans Fachhochschule Wiesbaden, FB Design Informatik Medien Studiengang Allgemeine Informatik Vorlesung zur Vertiefungslehrveranstaltung Spezielle Methoden der Softwaretechnik SS

Mehr

Schritt 4: Hallo Enterprise Bean

Schritt 4: Hallo Enterprise Bean Prof. Dr. Th. Letschert FB MNI JEE Schritt 4: Hallo Enterprise Bean Einstieg: EJBs erzeugen und nutzen Meine erstes EJB Projekt Enterprise Beans sind eine Backend Technologie, die mit unterschiedlichen

Mehr

G s e a s m a t m ar a ch c i h tek e tur u I und IoC

G s e a s m a t m ar a ch c i h tek e tur u I und IoC Gesamtarchitektur I und IoC Schichten einer Web-Anwendung Initiiert durch J2EE und Spring: Strukturierte Sicht auf UI und Fachlogik (Domäne) Ergibt 5 Schichten: Man unterscheidet Präsentations- und Domänenmodell!

Mehr

Übungsaufgabe Transaktion als Middleware

Übungsaufgabe Transaktion als Middleware Übungsaufgabe Transaktion als Middleware und Java Persistence API Client/Server Abstraktes Komponentenmodell Entscheidende Punkte Erweiterung der Invoke-Methode Context-Verwaltung Transaktionsbehandlung

Mehr

ORACLE Business Components for Java (BC4J) Marco Grawunder

ORACLE Business Components for Java (BC4J) Marco Grawunder ORACLE Business Components for Java (BC4J) Marco Grawunder Gliederung 2 Probleme von J2EE/EJB J2EE-Pattern Lösungsansatz: BC4J Architektur einer BC4J-Anwendung Komponenten Entity Objects View Objects Application

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

CORBA. Eine kurze Einführung. Common Object Request Broker Architecture. Ying Lu

CORBA. Eine kurze Einführung. Common Object Request Broker Architecture. Ying Lu CORBA Common Object Request Broker Architecture Eine kurze Einführung Ying Lu Verlauf der Präsentation Was ist CORBA CORBA-Architektur Ein Beispiel CORBA im Einsatz CORBA im Vergleich Was ist CORBA Begriffe

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Ein einfacher Server. .NET Remoting. Klassentypen

Ein einfacher Server. .NET Remoting. Klassentypen Einführung - eine Klienten-Applikation kann mit einer Komponente interagieren die hinter einer Grenze liegt - Remoting ermöglicht eine Kommunikation von Komponenten Kontext-, Applikationsdomänen- (leichtgewichtiger

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

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Middleware Versuch einer Einleitung Host dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Mainframe enthält vollständige Anwendung Typ. COBOL, C Mainframe contd.! Nachteile! Mainframe ist teuer

Mehr

Entwurfsmuster (Design Pattern) ETIS SS05

Entwurfsmuster (Design Pattern) ETIS SS05 Entwurfsmuster (Design Pattern) ETIS SS05 Gliederung Motivation Pattern allgemein Proxy-Pattern Zusammenfassung 2 Motivation I Wie gut sind eure Programme strukturiert? Wartbarkeit? - Verständlichkeit

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

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

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007

OSEK / COM. Inhaltsverzeichnis. Abbildungsverzeichnis. Florian Hohnsbehn. PG AutoLab Seminarwochenende 21.-23. Oktober 2007 OSEK / COM Florian Hohnsbehn PG AutoLab Seminarwochenende 21.-23. Oktober 2007 Inhaltsverzeichnis Abbildungsverzeichnis 1 1 Einführung 1.1 Was ist OSEK COM? OSEK COM ist eine vom OSEK-VDX-Konsortium entwickelte

Mehr

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

Mehr

XMPP: Extensible Messaging and Presence Protocol

XMPP: Extensible Messaging and Presence Protocol XMPP: Extensible Messaging and Presence Protocol (aka Jabber) 5. Dezember 2005 Einleitung Was ist XMPP? Architektur Allgemeines Kommunikation via XMPP: Streams, Stanzas Beispielanwendung

Mehr

Lightweight Java in der Automatisierungstechnik

Lightweight Java in der Automatisierungstechnik Lightweight Java in der Automatisierungstechnik Erfahrungen aus dem Anlagenbau Dr. Markus Eiglsperger eig@zuehlke.com Business Driver im Anlagenbau Kosten Modularisierung Vernetzung Agilität Paradigmenwechsel

Mehr

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum

ANDROID. Analyse der Android Plattform. Andre Rein, Johannes Florian Tietje. 28. Oktober 2010. FH-Gieÿen-Friedberg Android Praktikum Analyse der Android Plattform Andre Rein, Johannes Florian Tietje FH-Gieÿen-Friedberg Android Praktikum 28. Oktober 2010 Topics 1 Übersicht Android Plattform Application Framework Activities und Services

Mehr

Programmierung von Client/Server- Anwendungen

Programmierung von Client/Server- Anwendungen Programmierung von Client/Server- Anwendungen Komponenten des Web-Containers (Java EE) SoSe2015 Prof. Dr. Andreas Schmietendorf 1 Übersicht zur Vorlesung Entwicklung der Java Enterprise Edition Servlets,

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

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

Lösung Verteilte Systeme WS 2011/12 Teil 1

Lösung Verteilte Systeme WS 2011/12 Teil 1 Seite 1 von 5 Lösung Verteilte Systeme WS 2011/12 Teil 1 2.02.2012 1. Aufgabe (5) Sie fahren in Ihrem Privatfahrzeug auf einer Autobahn und hinter Ihnen fährt ein Polizeifahrzeug. 1.1 Nennen Sie ein Szenario,

Mehr

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000

Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 Prüfungszeuch im Fach Objektorientierte Programmierung WS 2000 A. Beschreibung der Projektarbeit. Welche Aufgabe haben Sie im Rahmen der Projektarbeit gelöst? 2. Mit welchen Tools bzw. Programmen (Anwendung,

Mehr

Java Web Services mit Apache Axis2 Entwickler

Java Web Services mit Apache Axis2 Entwickler Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum

Mehr

Kommunikation ist alles

Kommunikation ist alles Kommunikation in verteilten Systemen mit Kommunikation ist alles >> alexander ziegler In einem verteilten System müssen die Anwendungsbestandteile miteinander interagieren nur so funktioniert ein großes

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Remote Method Invocation Teil 1

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Remote Method Invocation Teil 1 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Remote Method Invocation Teil 1 Object Request Broker el0100 copyright Abt. Technische

Mehr

Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007

Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007 Klausur zur Vorlesung Verteilte Systeme im SS 2007 Prof. Dr. Odej Kao 24. Juli 2007 Name: Vorname: Matrikelnummer: Studiengang: E-Mail: Schreiben Sie zunächst sofort Ihren Namen und Matrikelnummer auf

Mehr

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen IN-Q-My Title Company (Name) / 1 Agenda Firmenübersicht ebusiness Evolution InQMy Application Server Architektur Zusammenfassung

Mehr

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {...

Verhindert, dass eine Methode überschrieben wird. public final int holekontostand() {...} public final class Girokonto extends Konto {... PIWIN I Kap. 8 Objektorientierte Programmierung - Vererbung 31 Schlüsselwort: final Verhindert, dass eine Methode überschrieben wird public final int holekontostand() {... Erben von einer Klasse verbieten:

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

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Connection Architecture Teil 3

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Connection Architecture Teil 3 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Connection Architecture Teil 3 CICS Transaction Gateway el0100 copyright W. G. Spruth,

Mehr

Auszug aus Axis2 Schulung

Auszug aus Axis2 Schulung Auszug aus Axis2 Schulung Dieses Dokument ist ein Auszug aus unserem Skript zur Axis2- Schulung. Es dient lediglich als Beispiel für unsere Kursunterlagen. Thomas Bayer Hauptstraße 33 75050 Gemmingen Mehr

Mehr

C# im Vergleich zu Java

C# im Vergleich zu Java C# im Vergleich zu Java Serhad Ilgün Seminar Universität Dortmund SS 03 Gliederung Entstehung von C# und Java Überblick von C# und Java Unterschiede und Gemeinsamkeiten Zusammenfassung und Ausblick Entstehung

Mehr

EJB3.0 Unit-Testing Reloaded

EJB3.0 Unit-Testing Reloaded EJB3.0 Unit-Testing Reloaded Werner Eberling werner.eberling@mathema.de www.mathema.de Werner Eberling, MATHEMA Software GmbH - EJB3.0 - Unit-Testing Reloaded (G4 - Folie 1) Java Forum Stuttgart 2007 Automatisiertes

Mehr

IP routing und traceroute

IP routing und traceroute IP routing und traceroute Seminar Internet-Protokolle Dezember 2002 Falko Klaaßen fklaasse@techfak.uni-bielefeld.de 1 Übersicht zum Vortrag Was ist ein internet? Was sind Router? IP routing Subnet Routing

Mehr

EAI. Integration. EAI Version 0.9 1

EAI. Integration. EAI Version 0.9 1 EAI Enterprise Application Integration EAI Version 0.9 1 Heterogene Informationssysteme KIS DRG Grouper Stand-alone Anwendung (Windows) PACS Client-Server Anwendung (Java, LINUX, Caché) QM-System Client-Server

Mehr

Oracle Weblogic Administration Grundlagen

Oracle Weblogic Administration Grundlagen Oracle Weblogic Administration Grundlagen Seminarunterlage Version: 1.07 Version 1.07 vom 14. September 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Java Einführung Methoden in Klassen

Java Einführung Methoden in Klassen Java Einführung Methoden in Klassen Lehrziel der Einheit Methoden Signatur (=Deklaration) einer Methode Zugriff/Sichtbarkeit Rückgabewerte Parameter Aufruf von Methoden (Nachrichten) Information Hiding

Mehr

Steffen Heinzl Markus Mathes. Middleware in Java

Steffen Heinzl Markus Mathes. Middleware in Java Steffen Heinzl Markus Mathes Middleware in Java Leitfaden zum Entwurf verteilter Anwendungen - Implementierung von verteilten Systemen über JMS - Verteilte Objekte über RMI und CORBA Mit 50 Abbildungen

Mehr

CORBA. Beispiel einer Middleware-Plattform. Christian Fass WS 2013/14 Software Engineering: Basistechnologien

CORBA. Beispiel einer Middleware-Plattform. Christian Fass WS 2013/14 Software Engineering: Basistechnologien CORBA Beispiel einer Middleware-Plattform Christian Fass WS 2013/14 Software Engineering: Basistechnologien Allgemeines Common Object Request Broker Architecture Middleware: Vermittelt zwischen Obekten/Prozessen

Mehr