Verteilte Systeme: State of the Art

Größe: px
Ab Seite anzeigen:

Download "Verteilte Systeme: State of the Art"

Transkript

1 Georg-August-Universität Göttingen Institut für Wirtschaftsinformatik Professor Dr. Matthias Schumann Platz der Göttinger Sieben Göttingen Telefon: Telefax: Arbeitsbericht Nr. 1/2003 Hrsg.: Matthias Schumann Thomas Diekmann / Svenja Hagenhoff Verteilte Systeme: State of the Art

2 Copyright: Institut für Wirtschaftsinformatik, Abteilung Wirtschaftsinformatik II, Georg-August-Universität Göttingen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urhebergesetzes ist ohne Zustimmung des Herausgebers unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Alle Rechte vorbehalten.

3 Inhaltsverzeichnis III Inhaltsverzeichnis Inhaltsverzeichnis...III Abbildungsverzeichnis... IV Abkürzungsverzeichnis... V 1 Problemstellung Grundbegriffe Verteilte Systeme und verteilte Anwendungen Definitionen Gegenstand und Zielsetzung der Verteilung Aspekte der Verteilung Probleme der Verteilung Middleware Konzepte Konzepte zur Funktionsverteilung Remote Procedure Call/Remote Method Invocation Message Oriented Middleware Object Request Broker Komponentenorientierte Ansätze Beurteilung der Konzepte zur Funktionsverteilung Konzepte zur Datenverteilung Verteilte Datenbanken Peer-To-Peer Filesharing Grid Computing als Konzept zur Lastverteilung Ausblick...27 Literaturverzeichnis...29

4 Abbildungsverzeichnis IV Abbildungsverzeichnis Abbildung 2-1: Abgrenzung zentralistischer von verteilten Systemen... 4 Abbildung 2-2: Deadlock... 9 Abbildung 2-3: Einordnung von Middleware Abbildung 3-1: Generierung und Verwendung von Stub und Skeleton Abbildung 3-2: vereinfachte CORBA Architektur Abbildung 3-3: Die Object Management Architecture Abbildung 3-4: Applikationsserver Abbildung 3-5: Realisierungsformen verteilter Informationssysteme Abbildung 3-6: Client-Server vs. Peer-to-Peer Architektur... 24

5 Abkürzungsverzeichnis V Abkürzungsverzeichnis API COM CORBA DBMS DCOM HTTP IDL IETF IIOP ISO J2EE LAN MOM OLE OMA OMG ORB P2P RMI RPC SQL TCP UMTS XML Application Programming Interface Component Object Model Common Object Request Broker Architecture Datenbank Management Systeme Distributed Component Object Model Hypertext Transfer Protocol Interface Definition Language Internet Engineering Task Force Internet Inter-ORB-Protocol International Standards Organisation Java 2 Enterprise Edition Local Area Network Message Oriented Middleware Object Linking and Embedding Object Management Architecture Object Management Group Object Request Broker Peer-to-Peer Remote Method Invocation Remote Procedure Call Structured Query Language Transport Control Protocol Universal Mobile Telephone System Extensible Markup Language

6 1 Problemstellung 1 1 Problemstellung Die Entwicklung verteilter Systeme begann etwa um 1980 mit dem Aufkommen von lokalen Netzwerken (Local Area Networks LANs). Die durch die lokalen Netzwerke ermöglichte Kopplung von mehreren Mikroprozessoren und die Tatsache, dass deren Preis/Leistungsverhältnis sich Laufe der Zeit im Vergleich zu Großrechnern stetig verbesserte, lies die Bedeutung von verteilten Systemen kontinuierlich ansteigen 1. Dass verteilte Systeme auch heute noch von Relevanz sind, zeigen die aktuellen Entwicklungen im Bereich des Ubiquitous Computing, die maßgeblich auf die Erkenntnisse verteilter Systeme aufbauen 2. Der Begriff des Ubiquitous Computing wurde im Jahre 1991 von Mark Weiser begründet. Er verstand unter Ubiquitous Computing a method of enhancing computer use by making many computers available throughout the physical environment, but making them effectively invisible to the user 3. Damals war Ubiquitous Computing noch eine technologische Utopie, deren Erfüllung noch in weiter Ferne lag. Verschiedene Entwicklungen zeigen aber, dass dem Ubiquitous Computing in den nächsten Jahren zumindest aus technologischer Sicht wenig im Weg steht und somit die Bedeutung und Aktualität von Ubiquitous Computing weiter steigen wird. In Tabelle 1-1 werden die wichtigsten dieser Entwicklungen aufgeführt 4 : 1 Vgl. Bengel 2002, S. 1 f. 2 Vgl. Samulowitz 2002, S Weiser 1993, S Vgl. Fleisch/Mattern/Billinger 2003, S. 5 f.

7 1 Problemstellung 2 Preisverfall Hardware Miniaturisierung Hardware Weiterentwicklung von Software Energieverbrauch Hardware Das Moore sche Gesetz vom exponentielle Wachstum der Leistung von Mikroprozessoren gilt immer noch und führt somit weiterhin zu fallenden Preisen. Hardware wird so klein, dass sie nahezu unsichtbar ist. Man spricht auch von Embedded Networked Processors. Es wird immer mehr spezielle Software für mobile Anwendungen entwickelt (z.b. Java 2 Platform, Micro Edition). Bei gleich bleibender Leistung und Funktionalität von Mikroprozessoren sinkt der Energieverbrauch. Sensorik Die Qualität der für das Ubiquitous Computing benötigten Sensoren steigt kontinuierlich. Preisverfall Kommunikation Neue Materialien Standards Prognosen zufolge verdreifacht sich die Bandbreite der Kommunikationsnetzwerke in den nächsten Jahren alle zwölf Monate. Flexible Bildschirme und intelligentes Papier werden die Entwicklung des Ubiquitous Computing maßgeblich beeinflussen. Standards mit breiter Akzeptanz wie XML begünstigen die Entwicklung von Ubiquitous Computing. Tabelle 1-1: Ubiquitous Computing begünstigende Entwicklungen Da die Aktualität des Ubiquitous Computing zukünftig, wie gezeigt wurde, gegeben ist oder sogar noch steigen wird, ist ein gewisses Grundverständnis über verteilte Systeme obligatorisch. In diesem Beitrag soll deshalb der Stand der Forschung im Bereich verteilter Systeme dargestellt werden. In Kapitel 2 werden zunächst die Grundlagen, die für das Verständnis von verteilten Systemen notwendig sind, gelegt. Dabei wird insbesondere auf die Definition von verteilten Systemen bzw. Anwendungen, auf den Gegenstand und die Zielsetzung der Verteilung, auf die Aspekte und Probleme der Verteilung und auf Middleware eingegangen. In Kapitel 3 werden Konzepte zur Funktionsverteilung, zur Datenverteilung und zur Lastverteilung in verteilten Systemen beschrieben. Neben den Grundideen dieser Konzepte werden zum Teil auch kurz Produkte angesprochen. In Kapitel 4 wird der Beitrag zusammengefasst und ein Ausblick gegeben.

8 2 Grundbegriffe 3 2 Grundbegriffe Ziel dieses Abschnittes ist es, die Grundbegriffe, die im Zusammenhang mit verteilten Systemen stehen, zu erläutern. Dazu werden zunächst verteilte Systeme und verteilte Anwendungen definiert und Aspekte (Kapitel 2.1.3) bzw. Probleme (Kapitel 2.1.4) der Verteilung dargestellt. Im Anschluss soll kurz auf Middleware eingegangen werden, die die Ausführung von verteilten unterstützen und einige der in Kapitel beschriebenen Probleme vermeiden soll. 2.1 Verteilte Systeme und verteilte Anwendungen Im Folgenden sollen verteilte Systeme und verteilte Anwendungen erläutert werden. Ausgangspunkt sind dabei die in der Literatur zu findenden Definitionen von verteilten Systemen um dann im Anschluss eine Abgrenzung zu verteilten Anwendungen zu erarbeiten. Aus dem Gegenstand der Verteilung sollen im Kapitel einige Ziele verteilter Systeme und verteilter Anwendungen abgeleitet werden. Die bei der Verteilung zu beachtenden Aspekte und die aus der Verteilung resultierenden Probleme werden in Kapitel bzw. Kapitel diskutiert Definitionen In der Literatur findet sich eine Vielzahl von variierenden Definitionen für verteilte Systeme. Gemeinsam haben alle Definitionen, dass sie versuchen eine Abgrenzung zu dem im Gegensatz stehenden zentralistischen System zu finden. Dies gelingt oftmals aber nicht, da die Grenze zwischen verteilten und zentralistischen Systemen fließend ist. Exemplarisch hierfür ist die Definition von einem verteilten System als System von miteinander verbundenen und zusammenarbeitenden Prozessoren 5, da hier auch Rechner mit mehreren Prozessoren als verteilte Systeme gelten würden. Diese sind aber eindeutig zentralistischen Systemen zuzuordnen 6. Es ergibt sich somit die Problematik die Definition möglichst allgemein gültig zu halten, aber dennoch eine klare Abgrenzung zu zentralistischen System zu wahren. Mit folgender Definition scheint ein guter Kompromiss gelungen zu sein: 5 Vgl. Tanenbaum/van Renesse 1985, S. 419 ff. 6 Vgl. Mullender 1989

9 2 Grundbegriffe 4 Ein verteiltes System ist ein informationsverarbeitendes System, das eine Vielzahl von eigenständigen Rechnern enthält, die über ein Kommunikationsnetzwerk miteinander kooperieren, um ein angestrebtes Ziel zu erreichen 7. Durch diese Definition werden mehrere Charakteristika verteilter Systeme hervorgehoben. Die elementaren Einheiten von verteilten Systemen sind ihre Aktionen autonom ausführende Rechner, die ihre Kommunikation und die Koordination ihrer Aktionen nur über ein Kommunikationsnetzwerk mittels Nachrichten abwickeln. Der Zweck der Kooperation ist die Erreichung eines nicht weiter definierten Zieles. Eine weitere Verallgemeinerung dieser Definition wird erreicht, wenn als elementare Einheit eines verteilten Systems nicht Rechner, sondern Hardware-Komponenten definiert werden 8. Diese etwas weiter gefasste Definition umfasst beispielsweise auch Drucker in einem Netzwerk, die nicht direkt an einem Computer gebunden sind, sondern als Ressource mehreren Rechnern zur Verfügung stehen. Auf den elementaren Einheiten des verteilten Systems laufen Prozesse, die untereinander kommunizieren. Die Gesamtheit dieser kooperierenden Prozesse wird als verteilte Anwendung bezeichnet. Es ist dabei unerheblich, ob die Prozesse physisch auf mehrere Rechner verteilt sind oder nicht. Wichtig ist nur, dass die Prozesse nicht über einen gemeinsamen Speicher verfügen, also in verschiedenen Adressräumen arbeiten 9. In Abbildung werden zentralistische Anwendungen von verteilten Anwendungen und zentralistische Systeme von verteilten Systemen abgegrenzt Rechner Zentral. System Zentralistische Anwendung Rechner A Rechner B Kommunikationsnetzwerk Rechner C Rechner D Rechner X n Verteiltes System Verteilte Anwendung Legende m Prozess läuft auf Abbildung 2-1: Abgrenzung zentralistischer von verteilten Systemen 7 Bapat 1994, S Vgl. Coulouris/Dollimore/Kindberg 2002, S Vgl. Mühlhäuser/Schill 1992, S. 7 f.

10 2 Grundbegriffe Gegenstand und Zielsetzung der Verteilung Einige Ziele von verteilten Systemen und verteilten Anwendungen lassen sich aus dem Gegenstand der Verteilung direkt ableiten 10 : - Durch die Verteilung von Funktionen versucht man eine höhere Wiederverwendbarkeit von Code-Teile zu erreichen, da beispielsweise ein kommerzieller Anbieter die Ausführung eines bestimmten Algorithmus als Dienstleistung anbieten kann. Auch wird die Flexibilität und Erweiterbarkeit der Anwendung gefördert, da die Entwickler gezwungen sind die Schnittstellen genau zu definieren. Bei anderen Anwendungen, wie beispielsweise der Internettelefonie ist die Verteilung der Funktion von Natur aus gegeben. - Durch Verteilung von Daten erreicht man eine höhere Robustheit und Verfügbarkeit der Anwendung. Bei Ausfall eines Rechners kann ein anderer Rechner, der die Daten redundant hält, die Aufgaben des ausgefallenen Rechners übernehmen. Ein bekanntes Beispiel für die Verteilung von Daten stellen P2P-basierte Musiktauschbörsen wie Gnutella dar Das Ziel möglichst geringer Kosten spricht für eine gleichmäßige Verteilung der Last. Da die Kosten für Hardware im Bereich der Personal Computer in den letzen Jahren im Vergleich zu Hochleistungsrechnern stark gefallen sind, ist die Vernetzung von mehreren PCs meist kostengünstiger als die Anschaffung eines Hochleistungsrechners. Auch die Vergrößerung der Rechenleistung eines verteilten Systems kann wesentlich bedarfsadäquater vorgenommen werden, da die Rechenleistung in wesentlich kleineren Schritten erhöht werden kann als bei Großrechnern. Die Verteilung der Last geschieht zumeist nicht durch die Anwendung, sondern durch eine darunter liegende Kontrollschicht. Sie ist somit als systemorientierter Mechanismus anzusehen. Auf Konzepte, die zur Umsetzung der Funktions-, Daten- und Lastverteilung eingesetzt werden, wird in Kapitel 3.1, Kapitel 3.2 bzw. Kapitel 3.3 eingegangen. Tabelle 2-2 fasst die Vorteile von verteilten Systemen gegenüber zentralistischen Systemen zusammen. 10 Vgl. Haase 2001, S. 3 f.; Mühlhäuser/Schill 1992, S. 10 f.; Tanenbaum 1995, S. 448 ff. 11 Vgl. Schögel/van Delden 2002, S. 503 f.

11 2 Grundbegriffe 6 Robustheit Wiederverwendbarkeit Erweiterbarkeit Wirtschaftlichkeit Durch redundante Ressourcen kann das Gesamtsystem bei Ausfall einzelner Ressourcen weiterarbeiten. Code-Teile können bei verteilten Systemen leichter wieder verwendet werden. Die Erweiterungsmöglichkeiten sind bei verteilten Systemen wesentlich flexibler. Personal Computer bieten ein besseres Preis/Leistungsverhältnis als Großrechner. Tabelle 2-1: Vorteile verteilter Systeme Aspekte der Verteilung Durch die speziellen Charakteristika, die verteilte Systeme im Vergleich zu zentralistischen Systemen ausmachen, müssen bei der Entwicklung verteilter Systeme Aspekte berücksichtigt werden, die bei der Entwicklung zentralistischer Systeme gar nicht oder nur sehr wenig relevant sind 12. Einer der prägnantesten Aspekte, der bei der Entwicklung von verteilten Systemen beachtet werden muss, ist die Heterogenität der Hard- und Software. Die Heterogenität kann sich auf die für die Kommunikation benötigten Netzwerke, auf die Hardware und die Betriebssysteme der Rechner und auf die Programmiersprache der auf den Rechner laufenden Anwendungen beziehen. Heterogenität entsteht auch durch die Tatsache, dass die auf den Rechnern laufenden Anwendungen durch verschiedene Programmierer entwickelt werden, die zum Teil sehr unterschiedliche Programmierstile pflegen. Die Forderung nach Offenheit, d.h. die Möglichkeit der Erweiterung des verteilten Systems, wird durch die Heterogenität stark beeinflusst. Verteilte Systeme und die darauf ablaufenden Anwendungen brauchen, um Offenheit gewährleisten zu können, einen einheitlichen Kommunikationsmechanismus und veröffentlichte Schnittstellen. Bei verteilten Systemen, die diese Eigenschaften erfüllen, spricht man von offenen verteilten Systemen. Im Gegensatz zur Offenheit, die die Möglichkeit der Erweiterung des verteilten Systems um weitere Funktionen gewährleisten soll, zielt der Aspekt der Skalierbarkeit auf die Sicherstellung der Effektivität und Effizienz des verteilten Systems bei steigender Ressourcen- und Nutzerzahl. Wie wichtig die Skalierbarkeit von verteilten System ist, zeigt das Internet, das mit ein paar wenigen vernetzten Rechnern angefangen und mittlerweile viele Millionen Rechner und Nutzer miteinander verbindet. Auch der Aspekt der Sicherheit 12 Zu den Aspekten der Verteilung vgl. Coulouris/Dollimore/Kindberg 2002, S. 34 ff.

12 2 Grundbegriffe 7 tritt besonders im Internet-Umfeld in den Vordergrund, ist aber auch bei anderen verteilten Systemen von großer Bedeutung (siehe auch Kapitel 2.1.4). Um die Komplexität eines verteilten Systems zu verringern, versucht man die Verteilung des Systems vor dem Anwender zu verbergen. Durch diese als Transparenz bezeichnete Eigenschaft des verteilten Systems erscheint es dem Anwender als Ganzes und nicht als eine Sammlung von untereinander abhängigen Komponenten 13. Das Reference Model für Open Distributed Processing der International Standards Organization (ISO) unterscheidet dabei acht verschiedene Arten von Transparenzen 14, von denen die Zugriffs- und die Positionstransparenz, zusammengefasst auch als Netzwerktransparenz bezeichnet, für die Entwicklung von verteilten Systemen von besonderer Bedeutung sind. Durch die Netzwerktransparenz soll der Zugriff auf lokale und entfernte Ressourcen mit identischen Operationen ohne Kenntnisse über die Position der Ressourcen ermöglichen. Um dies zu ermöglichen und da bei verteilten Systemen partielle Ausfälle möglich sind, die nur sehr schwer zu beheben sind, muss dem Aspekt der Fehlerbehandlung bei der Entwicklung besondere Aufmerksamkeit zuteil werden. Leslie Lamport hebt diesen Aspekt sehr anschaulich in einer zynischen Definition von verteilten Systemen besonders hervor: Ein verteiltes System zeichnet sich dadurch aus, dass der Ausfall eines Rechners, von deren Existenz man noch nicht einmal wusste, einen in seiner eigenen Arbeit beeinträchtigt. Der Aspekt der Fehlerbehandlung wird auch durch den Aspekt der Nebenläufigkeit stark beeinflusst, da bei der Berücksichtigung von mehreren parallelen Zugriffen auf eine Ressource ganz neue Fehlerklassen entstehen (s. auch Kapitel 2.1.4) Probleme der Verteilung Verteilte Systeme bringen nicht nur Vorteile mit sich, sondern verursachen zum Teil auch Probleme, die bei der Entwicklung und dem Betrieb von verteilten Systemen zu beachten sind. In diesem Abschnitt soll deswegen auf einige dieser Probleme kurz eingegangen werden. Als ein Ziel der Verteilung wurde die höhere Robustheit des gesamten Systems beschrieben. Die höhere Robustheit des Systems wird erreicht, indem eine ausgefallene Ressource durch eine redundante Ressource substituiert wird und somit das System als Ganzes weiter arbeiten kann. Das Vorhalten von redundanten Ressourcen kann aber aus wirtschaftlicher 13 Vgl. Haase 2001, S. 5

13 2 Grundbegriffe 8 Sicht nachteilig sein und wird deshalb zum Teil unterlassen. Eine nicht redundante Verteilung von Ressourcen führt aber dazu, dass die Robustheit des Systems entgegen der Zielvorgabe verringert wird, da der Ausfall einer einzelnen Ressource zum Ausfall des ganzen Systems führen kann 15. Eine weitere Schwachstelle bei der Robustheit von verteilten Systemen stellen die Kommunikationsnetzwerke dar, die bei der Verteilung definitionsgemäß zwingend notwendig sind. Nachrichten, die für die Kooperation notwendig sind, können verloren gehen und die Robustheit des Systems wird, soweit keine Mechanismen vorhanden sind, die den Verlust von Nachrichten verhindern oder kompensieren, reduziert. Durch Kommunikationsnetzwerke kann auch die Performanz der verteilten Systeme negativ beeinflusst werden, wenn die Kapazität des Kommunikationsnetzwerkes sich als nicht adäquat erweist. Da die Leistungsfähigkeit der Kommunikationsnetzwerke in den letzten Jahren im Vergleich zur Leistungsfähigkeit von Prozessoren überproportional gestiegen ist, scheint sich das durch Kommunikationsnetzwerke verursachte Performanzproblem von verteilten Systemen aber zunehmend abzumildern. Offen bleibt dagegen die auch durch die Kommunikationsnetzwerke verursachte Sicherheitsproblematik. Die weiträumige Verteilung von Ressourcen bietet im Vergleich zu zentralistischen Systemen wesentlich mehr Angriffsfläche. Außenstehende haben wesentlich mehr Möglichkeit den Betrieb des Systems zu stören oder zu unterbrechen. Auch die unter den Ressourcen ausgetauschten Daten können abgefangen oder manipuliert werden. Bei der Entwicklung von verteilten Systemen sind also Mechanismen zur Wahrung der Sicherheit vorzusehen. Es gibt gerade im Bereich des Internets eine große Anzahl geeigneter Mechanismen, die einem ständigen Verbesserungsprozess unterliegen. Letztendlich wird es aber nie absolute Sicherheit in verteilten Systemen geben. Die Komplexität eines verteilten Systems ist wegen der erforderlichen Koordination der Ressourcen hinsichtlich eines gemeinsamen Ziels im Vergleich zu zentralistischen Lösungen wesentlich höher. Dies wiegt besonders schwer, da die Softwareunterstützung für die Entwicklung von verteilten Systemen noch sehr rudimentär vorhanden ist und bedingt durch die oben beschriebenen Aspekte von verteilten Systemen auch zukünftig wahrscheinlich nicht an den Umfang von Softwareunterstützung für die Entwicklung zentralistischer Software heranreichen wird. Der Pessimismus bezüglich des Umfangs zukünftiger Softwareunterstützung resultiert nicht zuletzt aus den neuen Fehlerklassen die mit der Entwicklung verteilter Systeme einhergehen und dass das Vermeiden und Beheben dieser Fehler sehr aufwendig sein kann. Beispiel dafür sind durch Nebenläufigkeit verursachte Anomalien, die nur durch Einschränkung der Nebenläufigkeit verhindert werden können, was aber wiederum die Performanzvorteile durch Parallelisierung mindert. 14 Vgl. ISO 1992 und Wolff 1996, S. 2 f. 15 Sloman/Kramer 1988, S. 7

14 2 Grundbegriffe 9 Das klassische Beispiel einer Fehlerklasse, die erst durch Nebenläufigkeit entstehen kann, sind die so genannten Deadlocks in Datenbanken. Abbildung 2-2 illustriert ein Deadlock. Datensatz Y wartet auf Write-Lock hat Write-Lock Anwendung A Anwendung B hat Write-Lock wartet auf Write-Lock Datensatz X Abbildung 2-2: Deadlock Anwendung A hat ein Write-Lock auf Datensatz X, d.h. keine andere Anwendung kann Datensatz X verändern. Anwendung A wird diesen Write-Lock aber nicht abgeben, bevor sie Datensatz Y verändert hat. Sie kann aber Datensatz Y nicht ändern, bevor Anwendung B sein Write-Lock auf Datensatz Y abgegeben hat. Anwendung B wird dieses Write-Lock aber nicht abgegeben bevor sie Datensatz X geändert hat. Die beiden Anwendungen blockieren sich also gegenseitig und können ohne Eingriff von Außen nicht weiterarbeiten. Tabelle 2-2 fasst die Probleme von verteilten Systemen zusammen. Robustheit Performanz Sicherheit Komplexität fehlende Softwareunterstützung neue Fehlerklassen Der Ausfall eines Knoten kann den Ausfall des ganzen Systems bedeuten. Geringe Netzwerk-Kapazitäten mindern die Performanz von verteilten Systemen. Verteilte Systeme bieten mehr Angriffsfläche für Angriffe von Außen. Verteilte Systeme sind prinzipiell schwerer zu verstehen und zu handhaben als zentralistische Systeme. Die Entwicklung von verteilten Systemen wird nur unzureichend durch Software unterstützt. Bei verteilten Systemen treten Fehler auf, die bei zentralistischen Systemen unbekannt sind. Tabelle 2-2: Probleme verteilter Systeme

15 2 Grundbegriffe Middleware Durch Transparenzmechanismen soll dem Anwender ein verteiltes System als ein Ganzes erscheinen. Dem Entwickler von verteilten Systemen bleibt also die Aufgabe überlassen, die Heterogenität des verteilten Systems zu bewältigen und vor dem Anwender zu verbergen. Um den Entwickler diese Aufgabe zu erleichtern wird zwischen der Plattform und den verteilten Anwendungen eine Verteilungsplattform die so genannte Middleware positioniert 16. Verteiltes System Verteilte Anwendungen Middleware Betriebssystem Computer und Netzwerk-Hardware Plattform Abbildung 2-3: Einordnung von Middleware 17 Middleware verbirgt die Heterogenität, die durch unterschiedliche Netzwerke, Rechnerarchitekturen, Betriebssysteme und Programmiersprachen verursacht wird, vor dem Entwickler und schafft einheitliche Schnittstellen zu den einzelnen Komponenten verteilter Systeme. Anwendungen können über ein Application Programming Interface (API) auf die Funktionalitäten der Komponenten zugreifen. Sollen durch die Middleware mehrere Programmiersprachen unterstützt werden, muss für jede Programmiersprache eine eigene API definiert werden. Um diesen Ziel gerecht zu werden, muss Middleware diversen Anforderungen genügen 18 : - Middleware muss einfach zu handhaben sein. Dem Entwickler soll die beispielsweise die Implementation der Netzwerkkommunikation durch Sockets etc. erspart bleiben. - Middleware sollte Ortstransparenz gewährleisten. Beispielsweise sollte eine Neuverteilung von Komponenten einer verteilten Anwendung ohne Neukompilierung möglich sein. 16 Vgl. Simon (1996), S.200 f. 17 Vgl. Coulouris/Dollimore/Kindberg (2002), S Vgl. Britton (2001), S. 23 f.

16 2 Grundbegriffe 11 - Um einen stabilen Betrieb von verteilten Systemen ermöglichen zu können, muss die Auslieferung von Nachrichten ohne Verlust oder Duplizierung geschehen. - Idealerweise unterstützt Middleware verschiedene Programmiersprachen und ist somit sprachtransparent.

17 3 Konzepte 12 3 Konzepte In den folgenden Abschnitten sollen verschiedene Konzepte beschrieben werden, die die Entwicklung von verteilten Systemen und Anwendungen erleichtern bzw. erst ermöglichen. Die Konzepte werden analog zu dem in Kapitel beschriebenen Gegenstand der Verteilung in Konzepte zur Funktionsverteilung (Kapitel 3.1), Konzepte zur Datenverteilung (Kapitel 3.2) und Grid Computing als Konzept zur Lastverteilung (Kapitel 3.3) untergliedert. 3.1 Konzepte zur Funktionsverteilung Durch die Verteilung von Funktionen kann die Wiederverwendbarkeit von Code-Teilen erreicht werden. Zum Beispiel kann ein kommerzieller Anbieter eine bestimmte Funktionalität einmalig implementieren und verschiedenen Nachfragern als Dienstleistung anbieten. Bei anderen Anwendungen ist die Verteilung von Funktionen von Natur aus gegeben. Beispielsweise ist es bei einer Anwendung für die Wetterprognose wesentlich sinnvoller die Messdaten automatisch vor Ort von Messstationen erfassen zu lassen, als sie zentral zu erfassen. Als Konzepte zur Funktionsverteilung werden im Folgenden Remote Procedure Calls, Message Oriented Middleware, Object Request Brokers und komponentorientierte Ansätze erläutert. Zu jedem Konzept wird ein kurzer Überblick über verfügbare Produkte gegeben, die jeweiligen Konzepte umsetzen. Im Anschluss wird eine kurze Bewertung der beschrieben Konzepte gemacht Remote Procedure Call/Remote Method Invocation Grundidee Der Remote Procedure Call (RPC) ist ein Mechanismus, der das Aufrufen von auf entfernten Computern befindlichen Prozeduren erlaubt. RPC wurde in den 1980er von SUN Microsystems entwickelt und von dem Internet-Gremium IETF (Internet Engineering Task Force) standardisiert 19. RPC ist ein relativ beliebter Mechanismus bei der Entwicklung von verteilten Systemen, da der Aufruf einer entfernten Prozedur mit RPC stark einem Aufruf einer lokalen Prozedur in konventionellen höheren Programmiersprachen ähnelt 20. Mit der Einführung des objektorientierten Programmierparadigmas wurde der RPC-Mechanismus an 19 Vgl. o.v Vgl. Simon 1996, S. 65

18 3 Konzepte 13 die neuen Gegebenheiten angepasst und firmiert nun unter dem Namen Remote Method Invocation (RMI). RMI ermöglicht Objekten die Methoden anderer Objekte prozessübergreifend aufzurufen und stellt somit eine Erweiterung des lokalen Methodenaufrufs dar 21. Da die Unterschiede zwischen RPC und RMI nur minimal sind, wird im Folgenden nur auf RMI eingegangen. Nahezu alle aufgeführten Eigenschaften von RMI können auch auf RPC übertragen werden. Grundsätzlich hat der Aufruf einer entfernten Methode über RMI folgenden Ablauf 22 : das aufrufende Objekt übergibt der entfernten Methode die Eingabeparameter die aufgerufene Methode bearbeitet die Anfrage, während das aufrufende Objekt wartet die aufgerufene Methode schickt die Ergebniswerte an das aufrufende Objekt zurück Neben dem hier beschriebenen synchronen Methodenaufruf, ist grundsätzlich auch ein asynchroner Aufruf möglich, bei dem das aufrufende Objekt nicht auf die Antwort wartet, sondern direkt nach dem Aufruf der entfernten Methode mit dem Programmablauf fortfährt. Das Ergebnis muss dem aufrufenden Objekt dann durch einen geeigneten Mechanismus, beispielsweise durch Auslösen einer Ausnahme, bereitgestellt werden 23. Bei der Entwicklung des RMI-Mechanismus, wurde versucht die Übertragung der Übergabeparameter und der Rückgabewerte vor dem Anwendungsentwickler zu verbergen und somit ein höheres Abstraktionsniveau erreicht, was zu einer einfachen Handhabung führt. Für den Anwendungsentwickler gestaltet sich der Aufruf einer entfernten Methode als ortstransparent und unterscheidet sich somit nicht oder nur kaum von dem Aufruf einer lokalen Methode 24. Die Kommunikation zwischen dem aufrufenden Prozess und der entfernten Prozedur übernimmt eine RPC-Middleware. Üblicherweise wird für das Erstellen und Verwenden von RPCs folgender Vorgehen gewählt 25 : 1. Der Entwickler der entfernten Prozedur implementiert diese und spezifiziert die Schnittstelle (Name, Anzahl und Typen der Übergabeparameter, Typ des Rückgabewerts) zu seiner Prozedur in einer Datei. 21 Vgl. Coulouris/Dollimore/Kindberg 2002, S. 203 f. 22 Vgl. Haase 2001, S Vgl. Haase S.8 24 Hansen/Neumann 2001, S. 167 f. 25 Vgl. Simon 1996, S. 65 f.

19 3 Konzepte Aus der Schnittstellenspezifikation generiert die RPC-Middleware einen Stub für die Clientseite und ein Skeleton für die Serverseite. Der Name des Stubs entspricht exakt dem Namen der entfernten Prozedur. Der Stub muss auf einen nicht weiter spezifizierten Weg auf die Clientseite gelangen. 3. Um eine entfernte Methode aufzurufen, wendet sich die aufrufende Applikation an den gleichnamigen Stub, der lokal auf derselben Maschine läuft. Die Übergabeparameter werden von dem Stub in ein plattformunabhängiges Format konvertiert, was auch als Marshalling bezeichnet wird, und an den Server geschickt. 4. Der Skeleton wandelt die Übergabeparameter in ein für seine Host-Maschine lesbares Format und ruft die eigentliche Prozedur auf. 5. Nach der Beendigung der Prozedur werden die Rückgabewerte von dem Skeleton nach demselben Schema wieder zum Stub zurückgeschickt 6. Der Stub gibt das Ergebnis an die aufrufende Anwendung weiter Abbildung 3-1 stellt den Ablauf grafisch dar 26. Prozedur- Spezifikation 1 RPC Middleware Client Stub Netzwerk Skeleton 6 5 Server 4 Abbildung 3-1: Generierung und Verwendung von Stub und Skeleton Produkte Tabelle 3-1 gibt einen Überblick über RPC/RMI Produkte 27. Die ersten drei Produkte sind reine RPC Produkte. Java RMI ist streng genommen kein RPC Produkt, wurde aber wegen seiner starken Ähnlichkeit zu RPC in der Tabelle mit aufgeführt. 26 Vgl. Haase 2001, S.9 27 Vgl. Ließmann 2000, S. 60

20 3 Konzepte 15 Name Anbieter Weitere Informationen RPC Microsoft ONC+/RPC SUN DCE-RPC Standard RPC Java RMI SUN Tabelle 3-1: RPC/RMI Produkte Message Oriented Middleware Grundidee Bei der Message Oriented Middleware (MOM) kommunizieren Prozesse über den Austausch von Nachrichten miteinander. Die Nachrichtenübertragung findet für den Entwickler transparent statt, d.h. er weiß, welche Nachrichten in welchem Format übertragen werden. Dies unterscheidet MOM von RPCs, bei denen das Nachrichten-Layout durch das Marshalling verschattet wird. Dadurch ist MOM hinsichtlich des Nachrichten-Inhalts weniger beschränkt, da neben den Prozeduraufruf und den Parameter noch weitere Inhalte übermittelt werden können. Das führt aber auch dazu, dass sowohl der sendende als auch der empfangende Prozess das Format der Nachricht kennen müssen. Neben der direkten Kommunikation der Prozesse durch Nachrichten bietet MOM auch eine indirekte Kommunikation über Warteschlangen. Dabei wird die Nachricht nicht direkt an den Prozess adressiert, sondern an einen Warteschlangen-Manager (queue manager) der mit dem Prozess assoziiert wird. Der Warteschlangen-Manager agiert als eine Mailbox für den Prozess, der die Nachrichten empfängt und so lange in einer Warteschlange einreiht bis der adressierte Prozess empfangsbereit ist. Er ermöglicht somit eine asynchrone Kommunikation der Prozesse, da der sendende Prozess nicht auf den empfangenden Prozess warten muss und somit nicht blockiert wird. So können auch Netzwerk-Ausfälle kompensiert werden, indem die Nachrichten während des Netzwerkausfalls in der Warteschlange verbleiben und erst danach versendet werden. Das sorgt für einen gewissen Grad von Fehlertransparenz, da der Entwickler von einer garantierten Auslieferung der Nachricht ausgehen kann und sich nicht um Fehlerbehandlungen bei temporären Netzwerkausfällen kümmern muss Vgl. Simon 1996, S. 60 ff.

21 3 Konzepte 16 Produkte Tabelle 3-2 gibt einen Überblick über MOM-Produkte 29. Teilweise reichen die Funktionalitäten der aufgeführten Produkte über die oben beschriebenen hinaus und umfassen ein Transaktionsmanagement. Das Transaktionsmanagement stellt sicher, dass Nachrichten die während einer Transaktion in die Warteschlange eingereiht werden, bei Abbruch der Transaktion nicht übertragen und gelöscht werden und dass alle zur Transaktion gehörigen Schritte, die bereits ausgeführt wurden, rückgängig gemacht werden 30. Name Anbieter Weitere Informationen BEA MessageQ BEA Systems WebSphere MQ family IBM MSMQ Application Link Enabling (ALE) TIBCO Rendezvous Microsoft SAP TIBCO ve_enterprise/rv/default.jsp Tabelle 3-2: MOM Produkte Object Request Broker Grundidee Object Request Broker (ORB) stellen eine Infrastruktur für die Kommunikation verteilter Objekte bereit. Die treibende Kraft bei der Entwicklung von ORB ist die Object Management Group (OMG), ein Konsortium aus etwa 800 Firmen, das 1989 mit dem Ziel gegründet wurde eine universelle verteilte Plattform für objektorientierte Programmierung zu schaffen. Die Bemühungen der OMG mündeten in der Object Management Architecture (OMA) und der Common Object Request Broker Architecture (CORBA) 31, die ständig weiter entwickelt werden. Die Mitglieder des Konsortiums reichen dazu laufend Vorschläge für die Erweiterung und Nachbesserung der bestehende Spezifikationen ein, die die OMG publiziert und nach einer Diskussion durch die Mitglieder ggf. in die Spezifikation aufnimmt. Die Tätigkeit der 29 Vgl. Britton 2001, S. 34 f. 30 Vgl. Wijegunaratne/Fernandez 1998, S Neben OMA und CORBA entwickelt die OMG noch weitere, z.t. sehr bekannte Spezifikation wie die Unified Modelling Language (UML) und die Model Driven Architecture (MDA).

22 3 Konzepte 17 OMG beschränkt sich ausschließlich auf die Erarbeitung von Spezifikation. Sie stellt also keine eigenen Produkte her, sondern beschreibt nur, wie solche Produkte auszusehen haben 32. Konkrete Implementierungen der Spezifikation werden in Kapitel 0 angesprochen. Die beiden oben genannten Spezifikation OMA und CORBA verhalten sich komplementär zueinander. CORBA ermöglicht die objektorientierte Interoperabilität und legt so die konzeptionelle (aber nicht hierarchische) Grundlage für die OMA 33. Zentrales Element von CORBA ist der ORB, der die Kommunikation von Objekten in verteilten heterogenen Umgebungen ermöglicht. Die Objekte sind durch eine Schnittstellen, die mit der Interface Definition Language (IDL) der OMG beschrieben wird, von dem ORB separiert. Die Schnittstellenbeschreibung ist unabhängig von der Implementierung des Objektes. Erst der IDL-Compiler setzt die Definition mit Hilfe der in der CORBA-Spezifikationen vorgeschriebenen Abbildungen in verschiedene Programmiersprachen wie Java und C++ in eine Zielsprache um 34. Bei einem einfachen Objektaufruf richtet das Client-Objekt die Anfrage an den Broker und übergibt die in der IDL-Schnittstelle geforderten Parameter. Durch die Zwischenschaltung des ORB erreicht man ortstransparenz, da das aufrufende Objekt den konkreten Ort des aufgerufenen Objekts nicht wissen muss. Auch die wird die Anwendung durch den ORB von Spezifika wie Hardwareplattform, dem Betriebssystem und dem Netzwerkprotokoll abgeschottet 35. Abbildung 3-2 illustriert die CORBA-Architektur an einem einfachen Objektaufruf. Objekt 1 (Client) Objekt 2 Objekt 3 (Server) Objekt n IDL 1 IDL 2 IDL 3 IDL n Aufruf Object Request Broker Abbildung 3-2: vereinfachte CORBA Architektur Die bei dem Objektaufruf genutzten Objektreferenzen sind aber nicht zwangsläufig global gültig, sie beschränken sich vielmehr auf einen bestimmten ORB. Damit ORBs 32 Vgl. Steckermeier 2001, S Vgl. Siegel 1999, S. 120 f. 34 Vgl. Steckermeier 2001, S. 31 f. 35 Vgl. Bengel 2002, S. 164 f.

23 3 Konzepte 18 (verschiedener Hersteller) untereinander kommunizieren und somit eine systemübergreifende Zusammenarbeit von Objekten möglich ist, hat die OMG ein Interoperabilitäts-Framework definiert, welches an die Besonderheiten des jeweiligen Transportmechanismus angepasst werden muss. Speziell für den Einsatz von dem in Verbindung mit anderen Internettechnologien sehr verbreiteten Transport Control Protocol (TCP) als Transportmechanismus beschreibt die CORBA-Spezifikation das Internet Inter- ORB-Protokoll (IIOP) 36. Mit IIOP können Objekte Broker-übergreifend eindeutig referenziert werden 37. Die OMA baut konzeptionell auf der CORBA-Spezifikation bildet die Grundlage für unternehmensweite Anwendungen. Die OMA umfasst neben den Applikationsobjekten CORBAservices und CORBAfacilities. CORBAservices umfassen Dienste, die über den reinen Methodenaufruf hinausgehen und gleichzeitig generisch genug sind, um in einer Vielzahl von Anwendungen verwendet zu werden (z.b. Naming, Security, Transaction). Die CORBAfacilities richten sich dagegen an industrie-spezifische Anwendungsgebiete wie etwa Telekommunikationsanwendungen oder Biotechnologieanwendungen 38. Abbildung 3-3 stellt die OMA dar. Anwendungs- Objekte CORBAfacilities Gesundheit Telekommunikation E-Commerce Versicherung etc. Object Request Broker Naming Security Transaction CORBAservices Abbildung 3-3: Die Object Management Architecture 39 Produkte Tabelle 3-3 zeigt eine Auswahl von Produkten, die die CORBA-Spezifikation umsetzen. J2EE wird in der Tabelle bewusst nicht aufgeführt, da es zwar auf CORBA-Spezifikationen 36 Vgl. Puder/Römer 2001, S Vgl. Griffel 1998, S Vgl. Siegel, S. 120 f. 39 Vgl. Siegel, S. 121

24 3 Konzepte 19 aufbaut, aber auch zu den komponentenorientierten Ansätzen zählt. Auf J2EE wird in Kapitel eingegangen. Name Anbieter Weitere Informationen ObjectBroker BEA VisiBroker Borland Orbix Iona Tabelle 3-3: CORBA-Produkte Komponentenorientierte Ansätze Grundidee Unter einer Komponente wird ein Stück Software verstanden, das klein genug ist, um es in einem Stück erzeugen und pflegen zu können, groß genug ist, um eine sinnvoll einsetzbare Funktionalität zu bieten und eine individuelle Unterstützung zu rechtfertigen sowie mit standardisierten Schnittstellen ausgestattet ist, um mit anderen Komponenten zusammenzuarbeiten 40. Diese Definition von Komponenten ähnelt sehr der Definition eines Objektes in der Objektorientierung differiert aber in einigen wichtigen Aspekten. Der grundlegendste Unterschied zwischen Objekten und Komponenten liegt in der gewählten Granularität. Objekte haben in der Regel nur einen sehr geringen Funktionsumfang und müssen deswegen auf Funktionalitäten anderer Objekte zurückgreifen. Dadurch entstehen zwischen den Objekten Abhängigkeiten, die wiederum die Pflege der Objekte erschweren. Bei dem Entwurf von Komponenten achtet man dagegen darauf, dass die Funktionalität der Komponenten möglichst abgeschlossen ist und somit die Abhängigkeiten zwischen den Komponenten minimiert werden. Solange die Schnittstellen zu anderen Komponenten unverändert bleiben, können die Komponenten erheblichen Anpassungen unterworfen werden und können sogar komplett ausgetauscht werden 41. Dies setzt aber die in der Definition geforderte Standardisierung der Schnittstellen voraus, was bei der Objektorientierung nur rudimentär vorhanden ist. Die Schnittstellen werden in der Objektorientierung zwar klar spezifiziert, können mit Objekten anderer Programmiersprachen in der Regel aber nicht kommunizieren Definition von Jed Harris, zitiert in Orfali/Harkey/Edwards Vgl. Stiemerling 2002, S Vgl. Griffel 1998, S. 31 ff.

25 3 Konzepte 20 Fasst man die eben gemachten Aussagen zu Objekten und Komponenten zusammen, kommt man zu dem Schluss, dass es sich bei diesen nicht um verschiedene sondern um komplementäre Konzepte handelt. Komponenten fassen Objekte zusammen und erreichen somit einen höheren Abstraktionsgrad 43, was manchmal zu der Aussage führt, dass Komponenten gleich Objekte plus Irgendwas sind ( Komponenten = Objekte + Irgendwas ). Durch Komponenten kommt man dem Ziel der ingenieurmäßigen Montage von Anwendungssystemen einen großen Schritt näher. Man setzt Komponenten verschiedener Hersteller dabei zu einen kundenindividuellen Anwendungssystem zusammen und verbindet so die Vorteile von Individualsoftware und Standardsoftware. Der Nutzen von plug und play Komponenten reicht von einer besseren Beherrschung der Komplexität integrierter Anwendungssysteme über eine Erhöhung der Flexibilität bis hin zur Senkung der Markteintrittsbarrieren 44. Technisch wird die Komposition der Komponenten in Applikationsservern realisiert. Applikationsserver bieten den Komponenten mit den so genannten Containern eine Laufzeitumgebung und stellen verschiedene Dienste zur Verfügung 45. Beispielsweise besitzen Applikationsserver Dienste, die es Komponenten ermöglichen ortstransparent auf Komponenten zuzugreifen die außerhalb des eigenen Containers laufen. In der Regel greifen sie dabei auf bewährte Technologien zurück, wie zum Beispiel die der in Kapitel beschriebenen ORBs. Applikationsserver sind also keine neue Technik, sondern fassen vielmehr bewährte Technologien unter einem Dach zusammen 46. Abbildung 3-4 stellt das Prinzip des Applikationsserver dar. Komponenten- Anbieter 1 Komponenten- Anbieter 2 Komponenten- Anbieter n Browser Web Container Komponente 1 Komponente 2 Komponente n Container Client Anwendung (GUI) Dienst A Dienst XY Dienst B (z.b. Connection Pooling) Applikationsserver Abbildung 3-4: Applikationsserver 43 Vgl. Bengel 2002, S Vgl. Turowski 2001, S Vgl. Singh/Stearns/Johnson 2002, S. 25 f. 46 Vgl. Ließmann 2000, S. 62

26 3 Konzepte 21 Produkte Den ersten komponentenorientierten Ansatz präsentierte Microsoft 1993 mit dem Component Object Model (COM) einer Weiterentwicklung des Object Linking and Embedding (OLE). COM definiert wie Komponenten untereinander auf binärer Ebene untereinander kommunizieren. COM unterstützt allerdings nur die Kommunikation von Komponenten, die auf dem gleichen Computer laufen, entfernte Komponenten können nicht angesprochen werden. Erst die Erweiterung zum Distributed Component Object Model (DCOM) ermöglicht die Entwicklung von verteilten komponentenorientierten Architekturen 47. Mit der Java 2 Enterprise Edition (J2EE) definiert SUN einen Standard zur Implementation, Konfiguration und Verteilung von unternehmensweiten Standards. J2EE ist im eigentlichen Sinne aber kein Produkt, sondern definiert nur ein Rahmenwerk zur Erstellung unternehmensweiter Anwendung basierend auf dem Komponentenmodell und der Programmiersprache Java. Mit J2EE soll die Komplexität die mit der Entwicklung verteilter Anwendungen einhergeht maßgeblich reduziert und somit die Produktivität der Entwicklung werden 48. Name Anbieter Weitere Informationen DCOM Microsoft J2EE Sun Tabelle 3-4: Komponentenorientierte Produkte Beurteilung der Konzepte zur Funktionsverteilung In den vorangegangenen Abschnitten wurden Technologien beschrieben, die die Entwicklung von verteilten Systemen und Anwendungen erleichtern bzw. erst ermöglichen sollen. Mit RPC-Mechanismen ist es möglich nahezu vollständig ortstransparente Anwendungen zu entwickeln. Nachteilig bei dieser Technologie ist die Beschränkung auf einfache Methodenaufrufe und damit die fehlende Unterstützung der Objektorientierung. Erst mit JavaRMI wurde diese Beschränkung aufgehoben, allerdings auf Kosten der Programmiersprachenunabhängigkeit. Mit ORBs wurde auch die Programmiersprachenunabhängigkeit erreicht. ORBs erlauben die ortstransparente Verteilung von Objekten auf verschiedene Netzwerkknoten, haben aber den Nachteil, dass die Objekte starr gekoppelt 47 Vgl. Szyperski 1998, S. 3 f. 48 Vgl. Singh/Stearns/Johnson 2002, S. 1 ff.

27 3 Konzepte 22 sind. Auch hat sich gezeigt, dass die Wunschvorstellung von wieder verwendbarer Software sich mit der reinen Objektorientierung noch nicht erfüllt hat. Dies führte zu der Entwicklung von komponentenorientierten Ansätzen, die eine vereinfachte Nutzung und Distribution von Softwarekomponenten gegenüber den Klassen- und Funktionsbibliotheken versprechen 49. Es hat sich aber gezeigt, dass durch den Einsatz von Komponenten die Komplexität der Entwicklung stark ansteigt. Nur durch den konsequenten Einsatz architektonischer Ansätze kann die Komplexität von komponentenorientierter Anwendungen reduziert werden 50. Die Anwendung von Architekturen bei der Dekomposition eines Softwaresystems in Komponenten beinhaltet aber auch immer einen kreativen, nicht-formalisierbaren Kern in sich und bedarf deshalb immer eine gewisse Erfahrung bei dem Architekten. Nur dann kann sich der Architekt bis zu einem gewissen Grad auf seine Intuitionen verlassen 51. Die fehlende Formalisierbarkeit der Dekompositionsprozesses führt zu einem Mangel an Entwicklungsmethoden und Werkzeugen zur Unterstützung der Entwicklung, was als wesentlicher Grund für die bisher nicht erfüllten Erwartungen an die Komponententechnologie identifiziert wurde Konzepte zur Datenverteilung Durch die Datenverteilung soll vor allem die Verfügbarkeit und Robustheit einer Anwendung erhöht werden. Als Beispiele für die Konzepte für die Verteilung von Daten werden im Folgenden verteilte Datenbanken und Peer-to-Peer Filesharing beschrieben Verteilte Datenbanken In den 1960er und 1970er Jahren kamen die ersten Datenbankmanagementsysteme (DBMS) auf den Markt, die eine Reduzierung der Komplexität der Anwendungsentwicklung und einen erhöhten Grad an Datenunabhängigkeit im Vergleich zur Speicherung von Daten in Dateien versprachen. Die Datenbanken wurden in der Regel in zentralen Rechenzentren betrieben, damit die teuren Hardware-Ressourcen effizient genutzt werden konnten. Da der Bedarf an Speicherplatz aber in vielen Fällen schnell an die Grenzen des (damals) machbaren stieß, wurden logisch zusammenhängende Datenbestände auf verschiedene physische Datenbanken verteilt. Neben dieser Fragmentierung, wurden die Datenbestände aber auch repliziert und auf verschiedene Rechner verteilt um beispielsweise eine 49 Vgl. Malischewski 1995, S 65 f. 50 Vgl. Ruh/Maginnis/Brown 2001, S Vgl. Stiemerling 2002, S. 436

28 3 Konzepte 23 Lastverteilung zu erreichen. Die Verteilung bereitet aber gerade im Bereich der Konsistenz der Daten erhebliche Probleme. Dies führte zur Entwicklung von verteilten DBMS, die zur Aufgabe haben, auf verteilte Datenbestände zuzugreifen und diese dem Anwender bzw. dem Anwendungsprogramm als eine einheitliche Datenbank zu repräsentieren 53. Abbildung 3-5 illustriert den Unterschied zwischen einer konventionellen Realisation der Verteilung von Datenbanken in einem Informationssystem und der Realisation mittels eines verteilten DBMS. Bei einer konventionellen Realisation findet die benötigte Kommunikation zwischen den Anwendungen auf Anwendungsebene statt. Betrachtet man etwa einen Auftragsdurchlauf in der industriellen Fertigung, würde beispielsweise das Produktionssystem die Daten eines fertig bearbeiteten Auftrags direkt an das Vertriebssystem übergeben. Bei der Realisation mittels eines verteilten DBMS entfällt diese Kommunikation, da die beiden Systeme auf die gleiche logische Datenbasis zugreifen. Das Vertriebsystem merkt automatisch, wann der Auftrag in der Produktion fertig gestellt ist. Anwendung A Kommunikation Anwendung B Anwendung A Anwendung B DBMS A DBMS B verteiltes DBMS DB A DB B DB A Kommunikation DB B konventionell realisiert Mittels eines verteilten DBMS realisiert Abbildung 3-5: Realisierungsformen verteilter Informationssysteme 54 Im idealtypischen Fall kann ein verteiltes Datenbankmanagementsystem Datenbestände verwalten, die auf beliebig vielen Rechnern mit möglicherweise verschiedenen Betriebssystemen verteilt sind und in beliebigen Datenbanksystemen mit verschiedenen Kommunikationsprotokollen gespeichert sind 55. Als Middleware für den Zugriff auf verteilte Datenbanken hat sich zwar die Structured Query Language (SQL) als Standard durchgesetzt, doch leider ist man immer noch weit davon entfernt transparent auf 52 Vgl. Holten 2003, S Vgl. Dadam 1996, S. 1 ff. 54 Vgl. Dadam 1996, S Vgl. Lamersdorf 1994, S. 20

29 3 Konzepte 24 Datenbanken verschiedener Hersteller zugreifen zu können, da es eine große Vielfalt an SQL Dialekten gibt Peer-To-Peer Filesharing Insbesondere Filesharing-Musiktauschbörsen wie Napster haben das Peer-To-Peer (P2P) Paradigma in das Bewusstsein der Öffentlichkeit gerückt und werden oft als Synonym für das P2P-Pradigma verwendet. Die folgende einfache Definition von P2P ist aber wesentlicher nüchterner und klarer als die heiße Diskussion um Napster und ähnliche Ansätze vermuten lässt 57 : P2P ist eine Netzwerk-Architektur, in der jeder Computer die gleichen Fähigkeiten und Verantwortlichkeiten besitzt. Alle Computer in einem P2P-Netzwerk, sie werden auch als Knoten bezeichnet, sind im idealtypischen Falle funktional gleich und leisten sowohl Server- als auch Clientdienste. Die Kommunikation zwischen den Knoten erfolgt direkt, ohne eine zentrale koordinierende Instanz 58. Abbildung 3-6 verdeutlicht die Unterschiede zwischen dem P2P-Paradigma und dem Client-Server-Paradigma. C C/S C C C/S C/S Legende C S C C/S S C/S C S Client Server C/S Client und Server C C C/S C/S C Client-Server Architektur C/S Peer-to-Peer Architektur Abbildung 3-6: Client-Server vs. Peer-to-Peer Architektur 59 In einer Client-Server Architektur kommunizieren die Client-Knoten nur indirekt über den Server miteinander. Es ist zwar möglich, dass ein Server Dienste eines anderen Servers in 56 Vgl. Tresch 1996, S. 250 f. 57 Vgl. Miller 2001, S Vgl. Barkai 2001, S. 4 f.

30 3 Konzepte 25 Anspruch nimmt, ein Client Knoten stellt in der Regel aber keine Dienste zur Verfügung. In einer P2P Architektur kommunizieren die Knoten direkt miteinander. Sie können dabei sowohl als Server als auch als Client fungieren. Unter dem Begriff P2P lassen sich die vier Anwendungsbereiche Instant Messaging, File- Sharing, Grid Computing und Collaboration/P2P-Groupware subsumieren 60, wobei Filesharing als Beispiel für die Verteilung von Daten im Folgenden erläutert werden soll. Wie der Begriff schon vermuten lässt, werden beim Filesharing Daten in Form von Dateien von den Benutzern des P2P Netzwerks gemeinsam genutzt. Jeder Knoten stellt Dateien zum Download bereit, die von jedem anderen Knoten herunter geladen werden können. Dateien, die durch einen Knoten von einem anderen Netzwerkknoten herunter geladen wurden, werden sofort wieder zum Download angeboten. Bei jedem Download findet folglich eine Replikation der angebotenen Dateien statt und die Redundanz der Dateien steigt an. Die Redundanz der Dateien führt dazu, dass die Chance, dass irgend ein Knoten eine bestimmte Datei zum Download bereitstellt ständig ansteigt, obwohl die Wahrscheinlichkeit dass ein bestimmter Knoten eine bestimmte Datei zum Download bereitstellt sehr gering ist 61. Auch wenn die Chance der Verfügbarkeit einer bestimmten Datei in einem P2P Netzwerk groß ist, muss sie bei Bedarf immer noch gefunden werden, da es in einem idealtypischen P2P Netzwerk keine zentrale Instanz gibt, die die verfügbaren Dateien indiziert. Suchanfragen funktionieren deshalb vereinfacht dargestellt nach dem Schneeballprinzip : Eine Suchanfrage wird an eine bestimmte Anzahl von Knoten übergeben. Verfügen die angesprochenen Knoten nicht über die gewünschte Datei, leiten diese die Suchanfrage wiederum an verschiedene Knoten weiter, bis die gewünschte Datei gefunden oder eine maximale Suchtiefe erreicht wird 62. Dieses Verfahren ist verständlicherweise nicht so performant wie Suchmaschinen, die auf einen zentralen Index zurückgreifen. Man nutzt deshalb z. T. Hybridformen von P2P Netzwerken wie Napster, die die Vorteile eines zentralen Index mit den Vorteilen von P2P Netzwerken verbinden: Als Suchmaschine halten diese Hybridformen einen zentralen Index vor, der alle Dateien enthält, die die zurzeit verfügbaren Benutzer zum Download bereitstellen. Alle populären Dateien, also Dateien die oft herunter geladen werden, liegen redundant bei den Benutzern vor. Hiermit erhöht sich die Chance, dass eine Datei verfügbar ist, obwohl die Chance, dass ein (bestimmter) Benutzer online ist gering ist (in Abbildung 3-6 wird diese Hybridform durch den gestrichelten Server in der Mitte des P2P Netzwerks verdeutlicht) Vgl. Barkai 2001, S Vgl. Schoder/Fischbach 2002, S. 587 f. 61 Vgl. Bricklin 2001, S Vgl. Schoder/Fischbach 2002, S. 587 f. 63 Vgl. Shirky 2001, S. 28 f.

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

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

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

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

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

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

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

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

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

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

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

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

-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

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

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

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

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

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

Verteilte Systeme - 1. Übung

Verteilte Systeme - 1. Übung Verteilte Systeme - 1. Übung Dr. Jens Brandt Sommersemester 2011 1. Rechnerverbünde Kommunikationsverbund: Beispiele: E-Mail (SMTP, POP/IMAP), Instant Messaging (XMPP, IRC, ICQ,...), Newsgroups (NNTP)

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

Verteilte Systemarchitekturen

Verteilte Systemarchitekturen Verteilte Systemarchitekturen Proseminar im WS 09/10 Prof. Sergei Gorlatch, Philipp Kegel, Alexander Ploß Parallele und verteilte Systeme, Westfälische Wilhelms-Universität Münster 17. Juli 2009 Inhalte

Mehr

Hello World from CORBA

Hello World from CORBA Hello World from CORBA ein erster Überblick Aufruf einer Objekt-Methode Client gettemperature() Thermometer Objekt- Implementation Thermometer th = new Thermometer(); double t = th.gettemperature(); th

Mehr

Grundlagen und Implementation. Jan Kraft

Grundlagen und Implementation. Jan Kraft Grundlagen und Implementation Jan Kraft Gliederung 1 die OMG 2 Was ist CORBA? 3 Funktionsweise 3.1 die Interface Definition Language 3.2 Objekt Adapter 3.3 weitere Komponenten des ORB 3.4 InterORB Protokolle

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

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

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 2 05.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Das

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

Klausur Verteilte Systeme Was versteht man unter verteilte Systeme

Klausur Verteilte Systeme Was versteht man unter verteilte Systeme Was versteht man unter verteilte Systeme Ein Verteiltes System ist ein System in dem Hardware- und Softwarekomponenten, die sich auf miteinander vernetzten Computern befinden miteinander kommunizieren

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

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

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

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

Verteilte Systeme. Verteilte Objektorientierte Systeme II. Prof. Dr. Oliver Haase

Verteilte Systeme. Verteilte Objektorientierte Systeme II. Prof. Dr. Oliver Haase Verteilte Systeme Verteilte Objektorientierte Systeme II Prof. Dr. Oliver Haase 1 Überblick Verteilte Objektorientierte Systeme 1 RPC verteilte objektorientierte Architekturen Java RMI Verteilte Objektorientierte

Mehr

Komponentenmodelle II

Komponentenmodelle II Komponentenmodelle II DCOM / CORBA Detlef Streitferdt Technische Universität Ilmenau DCOM Architektur Client Proxy Stub Component CoCreateInstance Security Provider DCE RPC Protocol Stack Security Provider

Mehr

Inhaltsverzeichnis. Vorwort 13. Kapitel 1 Einleitung 17. Kapitel 2 Architekturen 51. Kapitel 3 Prozesse 91

Inhaltsverzeichnis. Vorwort 13. Kapitel 1 Einleitung 17. Kapitel 2 Architekturen 51. Kapitel 3 Prozesse 91 Inhaltsverzeichnis Vorwort 13 Kapitel 1 Einleitung 17 1.1 Definition eines verteilten Systems................................ 19 1.2 Ziele........................................................ 20 1.2.1

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Verteilte Systeme CS5001

Verteilte Systeme CS5001 CS5001 Th. Letschert TH Mittelhessen Gießen University of Applied Sciences Einführung Administratives Unterlagen Verwendbar: Master of Science (Informatik) Wahlpflichtfach (Theorie-Pool) Unterlagen Folien:

Mehr

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08

PIWIN II. Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II. Vorlesung 2 SWS SS 08 PIWIN II Kap. 3: Verteilte Systeme & Rechnernetze 1 PIWIN II Praktische Informatik für Wirtschaftsmathematiker, Ingenieure und Naturwissenschaftler II Vorlesung 2 SWS SS 08 Fakultät für Informatik Technische

Mehr

Workflow-Management für CORBA-basierte Anwendungen

Workflow-Management für CORBA-basierte Anwendungen Wolfgang Schulze 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Workflow-Management für CORBA-basierte Anwendungen

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

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

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

Web Services: Inhalt

Web Services: Inhalt Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich

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

Middleware, Verteilte Plattform (auch Verteilungsplattform*) bietet Verteilungsabstraktion für verteilte Anwendungsprogramme,

Middleware, Verteilte Plattform (auch Verteilungsplattform*) bietet Verteilungsabstraktion für verteilte Anwendungsprogramme, 9 Middleware vs9 1 Middleware, Verteilte Plattform (auch Verteilungsplattform*) bietet Verteilungsabstraktion für verteilte Anwendungsprogramme, bietet Standarddienste (Transaktionen, Sicherheit,...),

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

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

explizite, orthogonale Interaktion Verteilte Anwendungen und Middleware uniforme / nicht-uniforme Interaktion implizite, nicht-orthogonale Interaktion

explizite, orthogonale Interaktion Verteilte Anwendungen und Middleware uniforme / nicht-uniforme Interaktion implizite, nicht-orthogonale Interaktion Verteilte Anwendungen und Klassifikation von Interaktionsformen explizit implizit orthogonal nicht-orthogonal uniform nicht-uniform transparent nicht-transparent explizite, orthogonale Interaktion weit

Mehr

Von ODBC zu OLE DB. Neue Möglichkeiten der Datenintegration. Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig

Von ODBC zu OLE DB. Neue Möglichkeiten der Datenintegration. Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig Von ODBC zu OLE DB Neue Möglichkeiten der Datenintegration Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig Von ODBC zu OLE DB Begriffsbestimmung ODBC, OLE DB, COM, ADO... Unterschiede zwischen

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

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

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

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

18 Entwicklung verteilter Systeme

18 Entwicklung verteilter Systeme 18 Entwicklung verteilter Systeme 18.0 Einführung Lernziele Verteilte Systeme 18.1 Charakteristika verteilter Systeme Entwurfsfragen Kommunikationsmodelle Middleware 18.2 Client-Server-Systeme Prozesse

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

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Definition Informationssystem

Definition Informationssystem Definition Informationssystem Informationssysteme (IS) sind soziotechnische Systeme, die menschliche und maschinelle Komponenten umfassen. Sie unterstützen die Sammlung, Verarbeitung, Bereitstellung, Kommunikation

Mehr

Client/Server-Programmierung

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

Mehr

DCOM und.net. B. Sc. Tobias Buchloh. Seminar Software-Entwurf Fachgebiet Software Engineering, Institut für Angewandte Informatik Universität Hannover

DCOM und.net. B. Sc. Tobias Buchloh. Seminar Software-Entwurf Fachgebiet Software Engineering, Institut für Angewandte Informatik Universität Hannover DCOM und.net B. Sc. Tobias Buchloh Seminar Software-Entwurf Fachgebiet Software Engineering, Institut für Angewandte Informatik Universität Hannover 2004-12-21 Gliederung Motivation Einordnung (D)COM.NET

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

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

8.4 Das Andrew File System 393 8.5 Ausblicke 404 8.6 Zusammenfassung 410 Übungen 411

8.4 Das Andrew File System 393 8.5 Ausblicke 404 8.6 Zusammenfassung 410 Übungen 411 Inhaltsverzeichnis Vorwort 11 Aufgabenbereiche und Leserschaft 11 Aufbau dieses Buches 12 Literatur 12 Änderungen in dieser Auflage 13 Danksagungen 14 Web-Site 14 Kapitel 1 Charakteristische Eigenschaften

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Der Einsatz von CORBA in verteilten EDA-Tools

Der Einsatz von CORBA in verteilten EDA-Tools Der Einsatz von CORBA in verteilten EDA-Tools Frank Grützmacher Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Fachgebiet Mikroelektronische Schaltungen und Systeme

Mehr

Corba. Common Object Request Broker Architecture. Von: Oliver Spiegel SoSem 2004. Seminar: Komponentenorientierte Softwareentwicklung

Corba. Common Object Request Broker Architecture. Von: Oliver Spiegel SoSem 2004. Seminar: Komponentenorientierte Softwareentwicklung Corba Common Object Request Broker Architecture Von: Oliver Spiegel SoSem 2004 Überblick Client/Server Technik Integration von bestehenden Softwaresystemen und Anwendungen Java-Unterstützung, um mobile,

Mehr

Client/Server-Systeme

Client/Server-Systeme Client/Server-Systeme Prof. Dr.-Ing. Wilhelm G. Spruth SS 2005 Teil 16 RMI, DCOM, Webservices cs 1100 ww6 sch 05-97 Remote Method Invocation (RMI) JVM JVM Client Server Stub Java Remote Skeleton Method

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

Überblick. Netzprogrammierung 2. Remote Procedure Calls. Remote Procedure Call RPC

Überblick. Netzprogrammierung 2. Remote Procedure Calls. Remote Procedure Call RPC Überblick 1. Remote rocedure Call 2. Komponenten beim RC 3. Fehler programmierung 2. Remote rocedure Calls rof. Dr.-Ing. Robert Tolksdorf Freie Universität Berlin Institut für Informatik basierte Informationssysteme

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

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

Application Server- gestern, heute, morgen?

Application Server- gestern, heute, morgen? Erschienen: Java Spektrum September / Oktober 2002 Autor: Ulrike Hammerschall Application Server- gestern, heute, morgen? Application Server sind heute in aller Munde. Wer in der IT Branche etwas auf sich

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

SAP NetWeaver Gateway. Connectivity@SNAP 2013

SAP NetWeaver Gateway. Connectivity@SNAP 2013 SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

Workflow Management: Workflow (1)

Workflow Management: Workflow (1) Workflow Management: Workflow (1) Abgrenzung: Geschäftsprozeß Vorgang (Aktivität) Arbeitsablauf (Workflow) Arbeitsschritt (Work Item) Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut

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

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

Middleware im Vergleich

Middleware im Vergleich 1 Middleware im Vergleich Prof. Dr. Alexander Schill Technische Universität Dresden Lehrstuhl Rechnernetze http://www.rn.inf.tu-dresden.de schill@rn.inf.tu-dresden.de - Einführung und Beispiel - Java-Technologien

Mehr

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203 Mehr als alter Wein in neuen Schläuchen 199 1 Problematik eines uneinheitlichen Verständnisses der SOA... 201 2 SOA als unternehmensweites Architekturkonzept........... 203 3 Struktur einer SOA..................................

Mehr

ICENI: Eine JXTA-basierte Service-Oriented. Architecture. Im Rahmen des Seminars Services Computing und Service-Oriented Architectures

ICENI: Eine JXTA-basierte Service-Oriented. Architecture. Im Rahmen des Seminars Services Computing und Service-Oriented Architectures ICENI: Eine JXTA-basierte Service-Oriented Architecture Im Rahmen des Seminars Services Computing und Service-Oriented Architectures Lisa Richter mail@lisa-richter.de 05-07-18 AGENDA 1 ICENI The Imperial

Mehr

Theorie und Praxis einer JSON-RPC-basierten Web-API

Theorie und Praxis einer JSON-RPC-basierten Web-API Theorie und Praxis einer JSON-RPC-basierten Web-API Christian Krause Christian.Krause@raritan.com Raritan Deutschland GmbH Chemnitzer LinuxTage 2015 Gliederung 1 2 Remote Procedure Call Interface Definition

Mehr

AKWi: SOA SOA-Technologiebenchmark Java RMI vs. Microsoft WCF

AKWi: SOA SOA-Technologiebenchmark Java RMI vs. Microsoft WCF AKWi: SOA SOA-Technologiebenchmark Java RMI vs. Microsoft WCF Mathias Slawik, SS 2009 Agenda Technologien Java RMI (Remote Method Invocation) Microsoft WCF (Windows Communication Foundation) Benchmark

Mehr

Verteilte Echtzeit-Systeme

Verteilte Echtzeit-Systeme Seminar im SS06 Verteilte Echtzeit-Systeme Prof. Sergei Gorlatch Dipl.-Inf. Jens Müller jmueller@uni-muenster.de Einsteinstr. 62, Raum 705, Tel. 83-32746 Westfälische Wilhelms-Universität Münster Fachbereich

Mehr

Java Enterprise Architekturen Willkommen in der Realität

Java Enterprise Architekturen Willkommen in der Realität Java Enterprise Architekturen Willkommen in der Realität Ralf Degner (Ralf.Degner@tk-online.de), Dr. Frank Griffel (Dr.Frank.Griffel@tk-online.de) Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen

Mehr

Literatur. Verteilte Systeme Hochschule Regensburg Vorlesung 1, 21.03.2012 Universitätsstraße 31, 93053 Regensburg. 1. VS: Einführung und Motivation

Literatur. Verteilte Systeme Hochschule Regensburg Vorlesung 1, 21.03.2012 Universitätsstraße 31, 93053 Regensburg. 1. VS: Einführung und Motivation Literatur Hochschule Regensburg Vorlesung 1, 21.03.2012 Universitätsstraße 31, 93053 Regensburg Prof. Dr. Jan Dünnweber Als Haupttext in allen Übungsstunden und Vorlesungen wird das Buch von Tanenbaum

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

Corba. Systemprogrammierung WS 08 / 09. 21.01.09 Roginer - Fontana - Heinisch 1

Corba. Systemprogrammierung WS 08 / 09. 21.01.09 Roginer - Fontana - Heinisch 1 Corba Systemprogrammierung WS 08 / 09 21.01.09 Roginer - Fontana - Heinisch 1 Gliederung Definition Historie RPC Eigenschaften Architektur IDL-Beispiel Anwendungen OMA Services Facilities Client-Server

Mehr

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP 8.4 Überblick und Vergleich weiterer ERP-Systeme G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP Kapitel 8: ERP-Einführung 32 Architektur von Oracle Applications 11 G Logische

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery

Mehr

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank

Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Message Broker (MB) Alexandru Arion, Benjamin Schöllhorn, Ingo Reese, Jürgen Gebhard, Stefan Patsch, Stephan Frank Programmierung verteilter Systeme Lab Institut für Informatik Universität Augsburg Universitätsstraße

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

Makologa Touré Damian Gawenda

Makologa Touré Damian Gawenda Vortrag von Makologa Touré Damian Gawenda im ITT am 08. August 2006 07.08.06 Makologa Touré Damian Gawenda 1 Übersicht Was ist ein WMS? Web-Technologien Wie installiere ich einen Web-Map-Server? 07.08.06

Mehr