SYSTEM- ARCHITEKTUREN FÜR VERTEILTE ANWENDUNGEN

Transkript

1 jürgen DUNKEL andreas EBERHART stefan FISCHER carsten KLEINER arne KOSCHEL SYSTEM- ARCHITEKTUREN FÜR VERTEILTE ANWENDUNGEN CLIENT-SERVER // MULTI-TIER // SOA // EVENT-DRIVEN ARCHITECTURE // P2P // GRID // WEB 2.0

2 Inhaltsverzeichnis Teil I Einf ührung 1 1 Motivation und Überblick Softwarearchitekturen Der Begriff Softwarearchitektur Leitgedanken zur Strukturierung von Software Kriterien f ür gute Softwarearchitekturen Die Dimensionen verteilter Systeme Verteilung und Kommunikation Nebenläufigkeit Persistenz Existierende Softwarearchitekturen f ür verteilte Systeme Teil II Architekturen für verteilte Systeme 19 3 Client-Server-Architekturen Architekturkonzept Einführung Eigenschaften des Client-Server-Modells Realisierungsplattformen WWW-Clients und -Server Sockets RPC am Beispiel Java Remote Method Invocation Client und Datenbank-Server Code-Beispiele Sockets... 32

3 VI Inhaltsverzeichnis RPC mit Java RMI DB-Client und DB-Server und N-Tier-Architekturen Architekturkonzepte Dreischichtige Architekturen Mehrschichtige Architekturen Realisierungsplattformen Klassische Web1.0-Anwendungsarchitekturen Verteilte Objekte am Beispiel CORBA JEE NET Code-Beispiele Klassische Web1.0-Anwendungsarchitekturen Verteilte Objekte am Beispiel CORBA: Code JEE NET SOA Architekturkonzept Motivation Struktur von SOAs WebServices Motivation, Historie und Standardisierung SOAP WSDL UDDI WS-BPEL WS-I WS-* Fragestellungen in der Praxis Bewertung der WebService Standards Realisierungsplattformen NET Apache Axis Open Enterprise Service Bus

4 Inhaltsverzeichnis VII Oracle WS-BPEL Engine Code-Beispiele Java /Axis NET WS-BPEL Event-Driven Architecture (EDA) Architekturkonzept Ereignis-orientierte Softwarearchitektur Complex Event Processing EDA-Referenzarchitektur Vorgehen bei der Entwicklung von EDA-Anwendungen Aktueller Entwicklungsstand Realisierungsplattformen Code-Beispiele Peer-to-Peer Architekturkonzept Wasist P2P? Zentrale Architektur Napster Verteilte Architektur Gnutella Distributed Hash Tables Chord Split-Stream-Protokolle Bedeutung und Einordnung von P2P-Netzen Realisierungsplattformen JXTA Peer-to-Peer-Netze in der Praxis Grid-Architekturen Architekturkonzept Allgemeines Arten von Grids OGSA Weiterführende Literatur Realisierungsplattformen

5 VIII Inhaltsverzeichnis Konzeptionelle Realisierungen der OGSA Unabhängige Implementierungen Herstellerspezifische Implementierungen Code-Beispiele Globus Toolkit GT Amazon Web 2.0 und Web-orientierte Architekturen Architekturkonzept Keep it Simple! HochskalierbareSysteme mit REST AJAX: Neue Wege im Design von Web-basierten Benutzerschnittstellen JSON als leichtgewichtiger Ersatz f ür XML Event-basierte Programmierung mit Feeds Mashups: Daten- und Applikationsintegration im Browser Architektonische Probleme bei Mashups und AJAX Realisierungplattformen AJAX-Werkzeuge UI Libs Mashup IDEs Alternative Clients Code-Beispiele REST Client in Java JavaScript Mashup Teil III Auswahl einer konkreten Architektur Vergleichskriterien zur Architekturwahl Anforderungen aus dem Softwarelebenszyklus Analyse und Design Entwicklung und Test Betrieb Management und Umfeld Analyse der Architekturen Anforderungen der Anwendungen

6 Inhaltsverzeichnis IX Grad an Interaktivität Zahl der Teilnehmer Ressourcenbedarf Dynamik Robustheitsanforderungen Anwendungsgebiet Zusammenfassung der Architekturbewertung Verteilte Anwendungen: Fallbeispiele aus der Praxis Fallbeispiele Klassische Web-Anwendungsarchitekturen und Verteilte Objekte Klassische Web1.0-Anwendungsarchitekturen Tier Web- und verteilte Objekte-Anwendung mit CORBA: UIS-Föderationsarchitektur Fallbeispiele N-tier-Architekturen NET: 3-Schicht-Anwendung vita.net Java EE/J2EE: Standard-Web-Anwendungen PetStore und Duke s Bank Fallbeispiele SOA SOA und WebServices: Amazon.com SOA und ESB: Einführung in einem mittelständischen Versicherungsunternehmen SOA, CORBA und J2EE: Erfahrungen bei der Migration eines IMS-basierenden Kernbankenverfahrens in eine Serviceorientierte Architektur Fallbeispiele Peer-to-Peer Fallbeispiele Grid Huge Scale Grid: Worldwide LHC Computing Grid (WLCG) Kleine Grids: ViSoGrid Fallbeispiel Web2.0: Flickr Teil IV Ausblick und Zusammenfassung Künftige Entwicklungen SoftwareasaService Virtualisierung

7 X Inhaltsverzeichnis 12.3 Appliances Cloud Computing Semantic Web Ubiquitous Computing Ultra-Large-Scale Systems Zusammenfassung Literaturverzeichnis Stichwortverzeichnis

8 Kapitel 2 Softwarearchitekturen In diesem Kapitel werden wir uns allgemein mit dem Begriff der Softwarearchitektur für verteilte Systeme beschäftigen. Dazu klären wir im ersten Abschnitt zunächst den generellen Begriff der Softwarearchitektur.Bei genaueremhinsehen kann man feststellen, dass man zunächst einige einfache, aber wichtige Leitideen verinnerlichen sollte, bevor man an die Details der Softwareerstellung geht. Diese Grundgedanken sind Thema des zweiten Abschnitts. Sie münden in Überlegungen zu einigen überschaubaren Kriterien f ür eine gute Softwarearchitektur, die wir in einem späteren Teil des Buches noch einmal intensiv benötigen werden. Die beiden restlichen Abschnitte des Buches beschäftigen sich dann mit den Anforderungen, die die Verteiltheit einer Anwendung für die Architektur mit sich bringt. Zunächst betrachten wir die wichtigsten Aspekte, die ein verteiltes von einem nicht verteilten System unterscheidet. Schließlich geben wir einen Überblick über die bekanntesten Architekturen verteilter Systeme, die im späteren Verlauf des Buches viel ausführlicher behandelt werden. 2.1 Der Begriff Softwarearchitektur Den Begriff Architektur kennt man zunächst einmal allgemein vom Bauwesen her. Er meint im Wesentlichen den planvollen Entwurf und die Gestaltung von Bauwerken. Dies l ässt sich nun leicht auf den Begriffder Softwarearchitektur übertragen: es geht um einen systematischen Ansatz zur Entwicklung von Software. Im engeren Sinne beschreibt die Architektur einer Software den Aufbau ihrer Komponenten und deren Zusammenspiel, oder, um es mit Helmut Balzert zu formulieren [6]: Definition 2.1 Unter dem Begriff Softwarearchitektur versteht man eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie die Beschreibung ihrer Beziehungen.

9 8 2 Softwarearchitekturen Softwarewirddemnach nicht als monolithisches Paket angesehen, sondern als ein System, das aus Teilkomponenten bzw. en besteht. Diese e erbringen gemeinsam die Funktionalität, die das Problem löst, für das die Software entwickelt wurde. Dazu müssen die e zusammenarbeiten. Wir werden gleich sehen, dass diese Zusammenarbeit im Falle eines verteilten Systems anders aussieht als bei einem zentralisierten System. Jedenfalls muss eine konkrete Softwarearchitektur die Fragen beantworten, wie ein System in Teilkomponenten aufgeteilt wirdund wie diese Komponenten interagieren. 2.2 Leitgedanken zur Strukturierung von Software Unabhängig von der konkret verwendeten Softwarearchitektur gibt es einige wenige Prinzipien, die man immer anwenden sollte, die also praktisch zu den Grundfesten des SoftwareEngineering gehören. Diese beiden Prinzipien sind die starke Kohärenz und die lose Kopplung. Die Idee der starken Kohärenz verdeutlicht Abbildung 2.1. Ein gegebenes Problem wird zunächst genau analysiert, um einer späteren Implementierung zugänglich gemacht zu werden. Die Analyse ergibt normalerweise eine Aufteilung des gesamten Problemraums in klar abgrenzbare Teilprobleme. Das nun zu entwicklende Lösungssystem ist ebenfalls in e aufgeteilt. Die starke Kohärenz verlangt, dass jedes sich mit einem klar abgegrenzten Teilproblem beschäftigt. Das in der Grafik durchgestrichene sollte in einer L ösung nicht auftauchen, da es sich mit unterschiedlichen Teilproblemen beschäftigt. Teilproblem Teilproblem Problem Abbildung2.1: Leitgedanke der starken Kohärenz

10 2.3 Kriterien f ür gute Softwarearchitekturen 9 (a) Starke Kopplung (b) Lose Kopplung Abbildung 2.2: Leitgedanke der losen Kopplung Starke Kohärenz ist kein Selbstzweck. Zunächst soll sie die Einfachheit und Verständlichkeit des Systems, im Prinzip also die Wirklichkeitsnähe fördern. Es wird aber auch in hohem Maße eine Redundanzfreiheit erreicht, da sich nicht mehrere Systeme mit demselben Teilproblem beschäftigen und jeweils eigene Lösungen erarbeiten müssen. Schließlich wird auch die Teambildung und damit die Effizienz der Erstellungsprozesse f ür eine bestimmte L ösung deutlich verbessert. Abbildung 2.2 visualisiert den Gedanken der losen Kopplung. In Abbildungsteil (a) ist ein System dargestellt, das stark gekoppelt ist: jedes ist mit fast jedem anderen verbunden, nutzt also Funktionalität von dort. Die Änderung einer Schnittstelle eines s hat dann zur Folge, dass alle anderene ebenfalls angepasst werden m üssen. Die in Abbildungsteil (b) dargestellte lose Kopplung versucht hingegen, die Zahl der Beziehungen zwischen en zu minimieren, indem stattdessen Verbünde von en gebildet werden, die dann jeweils nur über eine einzige Schnittstelle, die noch dazu aus möglichst wenigen Schnittstellenfunktionen besteht, verbunden sind. Auf diese Weise wird der Änderungsaufwand minimiert. Insgesamt ist die lose Kopplung in verteilten Systemen zu bevorzugen. Diese Prinzipien sollten also beim Softwareentwurf immer eingehalten werden; sie sind ein Qualitätsmerkmal. Es gibt jedoch weiterefaktoren, die die G üte einer Softwarearchitektur beeinflussen. Darauf geht der folgende Abschnitt ein. 2.3 Kriterien für gute Softwarearchitekturen Eine Softwarearchitektur ist kein Selbstzweck sie muss vielmehr das einzusetzende System bei dieser Lösung unterstützen. Dies kann erreicht werden, indem die Architektur die Anforderungen an Funktionaliät, Dienstgüte und Lebenszy-

11 10 2Softwarearchitekturen kluseigenschaften zu erfüllen hilft. Anders formuliert, behindert eine schlechte Softwarearchitektur das System bei der Erfüllung dieser Anforderungen. Dies heißt aber auch, dass man eine gegebene Architekturform nicht per se als gut oder schlecht bezeichnen kann, sondern nur als gut oder schlecht geeignet für ein bestimmtes gegebenes Anwendungsproblem mit seinen Nebenbedingungen wir besprechen dies noch ausführlich in Kapitel 10. Das Problem selbst hat demnach massiven Einfluss auf die gewählte Architektur. Sokann es etwa bei einer Datenbankanwendung sinnvoll sein, das System auf geringen Speicherbedarf zu optimieren, da es sich bei den eingesetzten Endgeräten um Handys handelt. Genauso kann es aber sein, dass man stattdessen schnelle Zugriffszeiten braucht, weil man auf bestimmte Ereignisse sehr schnell reagieren können muss. Beide Anforderungen bilden in vielen Fällen sich widersprechende Ziele, die sich oftmals auch in unterschiedlichen Architekturen widerspiegeln. Neben diesen noch nicht sehr operativen Zielen und den beiden Leitgedanken der starken Kohärenz und losen Kopplung kann man weitere Kriterien für die Güte einer gegebenen Softwarearchitektur und für die Entscheidung für oder gegen sie angeben. Ein Aspekt wurde schon bei der losen Kopplung kurz angesprochen: es ist wichtig, die Schnittstellen zu anderen Systemteilen m öglichst schmal zuhalten und gleichzeitig m öglichst abstrakt. Man sollte also nicht zu viele Funktionen an einer Schnittstelle bereit halten, da dies f ür den Programmierer erstens schwer überschaubar ist und zweitens meist zu einem hohen Änderungsaufwand führt. Hohe Abstraktion bedeutet, dass die Schnittstelle nicht zu stark die Implementierung widerspiegeln darf. So ist es z.b. immer gut, wenn die Implementierung einer bestimmten Anwendungslogik keine Voraussetzungen bzgl. der Darstellung mit sich bringt. Vielmehr sollte sie rein diejenigen Datenstrukturen verwenden, die allein zur Lösung des Anwendungsproblems nötig sind, aber nicht für das Layout. Durch eine hohe Abstraktion wird dann ein weiteres wichtiges Kriterium gefördert, nämlich das der Wiederverwendbarkeit. Je besser eine Architektur die Möglichkeit unterstützt, bestimmte Komponenten in anderen Anwendungen einzubauen, desto besser. Wir werden später sehen, dass dieses Kriterium in den modernen Architekturen stark an Bedeutung gewonnen hat. Aber auch die Wartbarkeit und die Erweiterbarkeit sind wichtige Ziele, die durch lose Kopplung und Abstraktion unterstützt werden. Es ist ja nicht so, dass ein einmal erstelltes System bis ans Ende seiner Tage unverändert weiterläuft, sondern es wird immer wieder modifziert werden; Komponenten werden ausgetauscht, neue Funktionalitäten eingebaut, etc. Hat man dann auf eine starke Kopplung mit zu konkreten (im Sinne des Gegensatzes zu abstrakten) Schnittstellen gesetzt, dann hat man sich ein erhebliches Problem eingehandelt. Unabhängig von der Wahl der Architektur ist es jedenfalls von großer Bedeutung, diese Wahl begründet zu treffen, indem man die genannten Kriterien gegeneinander abwägt. Ein häufig angewandtes Kriterium, das aber sehr selten hilfreich ist, lautet: Das ist eine neue Technik, die jetzt alle verwenden, die m üssen wir auch

12 2.4 Die Dimensionen verteilter Systeme 11 mal nehmen. Durch eine klare Dokumentation der Entscheidung kann man hier leicht Fehlentscheidungen vermeiden, da sich dann oft herausstellt, dass etwas älterelösungen besser sind, weil sie einfach besser zum System passen. In diesem Abschnitt sollte klar geworden sein, dass die Auswahl einer konkreten Softwarearchitektur für ein System eine komplexe und sehr stark anwendungsabhängige Angelegenheit ist. Trotzdem wollen wir das Problem der Architekturwahl in diesem Buch angehen, indem wir generell die verschiedenen Architekturen vorstellen und später versuchen, Anwendungstypen zu identifizieren, die aufgrund ihrer Eigenschaften besonders gut für bestimmte Architekturen geeignet sind. Uns interessieren in diesem Buch allerdings nicht beliebige Softwarearchitekturen, sondern diejenigen für verteilte Systeme. Neben den oben bereits genannten Anforderungen allgemeiner Softwaresysteme treten nun diejenigen, die sich aus der verteilten Ausführung eines Programmes ergeben. Was macht nun aber ein verteiltes System gegenüber einem nicht-verteilten aus? Dies soll im folgenden Abschnitt geklärt werden. 2.4 Die Dimensionen verteilter Systeme Dazu muss zunächst definiert werden, was ein verteiltes System ist. Praktisch in jedem Lehrbuch zu verteilten Systemen findet sich eine eigene Definition. Eine der bekanntesten Beschreibungen stammt von Tanenbaum und van Steen [88], die ein verteiltes System vor allem aus Nutzersicht definieren: Definition 2.2 Ein verteiltes System ist eine Ansammlung unabhängiger Computer,die den Benutzern wie ein einzelnes kohärentes System erscheinen. Diese Definition ist sehr allgemein gehalten, macht aber schon eine wichtige Aussage über die Rechner, die das System bilden (unabhängig, aber sonst beliebig), und über das Verhalten gegenüber dem Benutzer der Benutzer nimmt ein verteiltes System gerade nicht als aus Komponenten bestehend wahr, sondern als ein einziges kohärentes System. Die Kernaufgabe der Software in einem verteilten System besteht darin, diese Eigenschaft zu erfüllen. Die Softwarearchitektur muss sie darin unterstützen. Damit die Softwaredieser Aufgabe gewachsen ist, muss sie verschiedene Teilaufgaben erfüllen. Sicherlich lässt sich hier darüber streiten, welche Bedeutung jede einzelne dieser Aufgaben hat und ob beispielsweise die Güte, mit der sie bewältigt wird, eine wichtige Rolle spielt. Unstrittig ist jedoch, dass es drei Dimensionen eines verteilten Systems gibt, die jede Softwareabdecken muss: Verteilung und Kommunikation Nebenläufigkeit Persistenz

13 Stichwortverzeichnis.NET,63, 106, 116, 242.NET Framework, 63.NET Remoting, 68 21/2-Tier-Architektur,49 Abstraktion, 10 Abstraktionsvermögen, 232 Adminstrationsaufwand, 217 ADO.NET,66, 70, 83 Adobe Flash, 205 AJAX, 187, 189, 234, 273 Alexa, 166 Amazon, 166, 178 Amazon S3, 181 Analyse, 214, 215 Anwendungsentwickler,213 Anwendungslogik, 10 Anwendungsproblem, 10 Anwendungsschicht, 43 AOP,95 Apache, 50 Apache Axis, 104 Appliance, 268 Applikationslogik, 225 Applikationsserver,45, 225 Architekt, 218 Aris, 225 ASP.NET,66 ASPs, 50 Ausfallsicherheit, 223 Axis, 113 B2B, 224 B2C-Anwendung, 237 Basic Profile, 102 Bauwesen, 7 BCI, 253 Beratung, 218 Best Practice, 216, 231 Betrieb, 214 Binding, 70 BitTorrent, 159 Blog, 186 Blueprints, 222 Bluetooth, 3 Business Process Modelling Notation, 52 C, 37, 175 C++, 64 C#, 64, 84 Callback, 13, 202 CEP,124 CERN, 257 CGI, 50 Chord, 151 CIL, 64 Client-Server,4 Client-Server-Anwendung, 219 Client-Server-Architektur,15, 190 Client-Server-Modell, 21 Cloud Computing, 270 CLR, 64 Cluster,164 COBOL, 253

14 288 Stichwortverzeichnis COM, 67 Common Intermediate Language, 64 Common Language Runtime, 64 Compensation, 101 Complex Event Processing, 124 Complex-Event-Processing, 226 Component Object Model, 67 Composite Desktop Applications, 242 Content Management-System, 186 Contract, 70 CORBA, 51, 75, 89, 93, 190, 222, 240, 247, 252 CORBA 3.0, 55 CORBA-Anwendung, 75 CORBA-Client, 77 CORBA-Objekte, 54 CORBA-Objektreferenz, 54 CORBAservices, 54 CRM, 266 Cross Domain-Problematik, 233 CSS, 191 Cursor,31 CVS, 269 Cyberspace, 3 Daten-Grid, 165 Datenbank-Client, 37 Datenbank-Server,37 Datenbankanwendung, 10 Datenbanksystem, 30 Datenstruktur,10 DB2, 187, 204 DCOM, 28, 51, 68, 93, 190 DCOM-CORBA-Krieg, 93 Deployment, 63, 216, 220, 225, 230 Design, 214, 215 Desktop, 235 Dienstgüte, 9 Dienstqualität, 169 Dienstverzeichnis, 90, 224 Distributed Common Object Model, 51 Distributed Component Object Model, 68 Distributed Hash Tables, 149 DNS, 23 Dojo, 203 DOM, 93, 195, 200 Dreischichtenarchitektur,45 DRMAA, 178 Duke s Bank, 246 DWR, 202 Dynamik, 236 dynamisches SQL, 30 EC2, 179, 265 ECA, 241 Eclipse, 220 EDA, 17, 92, 119, 227, 241 edonkey,159 EJB 3.0, 59 Elastic Compute Cloud, 179 Embedded SQL, 30, 37 Endpunkt, 70 Enterprise JavaBeans, 59, 80, 235 Entwicklungsprozess, 216 Entwicklungsumgebung, 220 Entwicklungszyklus, 215 Ereignis-Orientierung, 122 Ereignismuster,226 Ereignisregel, 226 ESB, 110, 247 Esper,137 Ethernet, 15 Event Driven Architecture, siehe EDA event patterns, 124 Event Processing Engine, 128 Event Processing Language, 136, 226 Event Processing Networks, 131 Event-basierte Programmierung, 196 Event-Driven Architecture, 241 FastTrack, 149, 159 Fat Client, 199 Feed, 196 Fehlertoleranz, 222 Filesharing-System, 228 Finger Tables, 153 Firewall, 187 Flickr,261

15 Stichwortverzeichnis 289 GAD, 252 General Inter ORB Protocol, 54 Geschäftsprozess, 101, 225, 233 GGF,166 GIOP,54 Global Grid Forum, 166 Globus Toolkit, 168, 174, 230 Gnutella, 146 Gnutella2, 159 Google, 270 Google App Engine, 270 Google Geocoder,189 Google Maps, 198 GRAM, 179 Green Pages, 100 Grid, 161, 230, 257 Grid Computing, 162 Grid-Projekt, 259 Grid-Software, 230 GridFTP,176, 180 Großrechner,252 Groupware-Anwendung, 228 gsoap,104 GWSDL, 171 Handy,3,10 HTML, 191 HTML-Datei, 16 HTTP,22, 25, 233 HTTP-GET,26 Hype, 218, 223, 231 IBM, 270 IBM IMS/DC, 253 IDL, 53, 76 ignorable whitespace, 93 IIOP,54 IIS, 50, 106 Implementierung, 10, 214 Implementierungsmodell, 216 Instant Messaging, 228 Integrationstest, 220 Interaktivität, 235 Interface Definition Language, 53, 98 Internet Inter ORB Protocol, 54 Intranet, 223 J2EE, 112, 245, 247, 252 Java, 175 Java EE, 245 Java Enterprise, 245 Java Persistence API, 61, 82 Java RMI, 28, 35 Java-Servlet, 50, 57, 72 JavaScript, 191, 199, 200, 272 JavaServer Faces, 58, 79 JavaServer Pages, 57, 78 JDBC, 22, 31, 72 JEE, 55 JMS, 109 JSON, 195 JSP,192 JXTA, 156, 228 Kademlia, 159 Kapselung, 91 Kazaa, 149 Klassifikation, 214 kohärentes System, 11 Kommunikation, 11 Komposition, 91 Kontrollfluss, 226 Koordinationsbedarf, 13 L ösungssystem, 8 LAMP,269 LAMP-Stack, 240 Language Integrated Query,71 Lastbalancierung, 222 Laufzeiteigenschaft, 217 LDAP,95 Lebenszyklus, 10, 219 Lernkurve, 216 LINQ, 71 Lizenzkosten, 221 Lizenzmodell, 218 Logik, 215 Logistikbranche, 4 lose Kopplung, 8, 91

16 290 Stichwortverzeichnis Mainframe, 221 Managed Applications, 64 Management, 218 Mashup, 198, 233 Mediation, 110 Mehrschichtige Architekturen, 46 Mehrstufiges Client-Server-Modell, 24 Message Queue, 94, 109 Message Queueing, 69 Metadaten, 103 Microsoft, 93, 270 Microsoft Message Queue, 91 Microsoft Visual Studio, 85 Middleware, 12, 14 Model Driven Architecture, 52, 221 Model View Controller,190 Modellierung, 215, 222, 230 Modul, 214 Modultest, 214 Mono, 72 MSMQ, 69 Multiprozessorrechner,12 MySQL, 269 N-Schichten-Architektur,4 N-Tier-Anwendung, 236 N-Tier-Anwendungsarchitektur,221 N-Tier-Architektur,16, 48 N-tier-Architektur,241 Nachricht, 12 Nahverkehrsnetz, 3 Napster,145 NCS, 28 Nebenläufigkeit, 11, 13 Netzwerklast, 218 Non-Managed Applications, 65 NTP,23 OASIS, 93 Object Management Architecture, 52 Object Management Group, 51 Object Request Broker,53 ODBC, 31 OGSA, 166 OGSA Platform Services, 166, 169 OGSI, 166, 171 OLE-Datenbank, 85 OMA, 52 OMG, 51, 221 On Demand Script, 200 Ontologie, 272 Open Grid Forum, 178 Open Grid Services Architecture, 166 Open Grid Services Infrastructure, 166, 169 Open Source, 218, 223, 234 Oracle, 92 ORB, 53, 55, 77 Overlay-Netzwerk, 143 P2P,228, 235 Parallelbetrieb, 13 Parallelrechner,164 Pattern, 216 Peer-to-Peer,141 Peer-to-Peer-Architektur,4 Persistenz, 11, 14 Persistenzschicht, 44 Personal Digital Assistant, 3 PetStore, 245 PHP,74, 240, 269 Plattenplatz, 236 Plattform, 217, 224 PostgreSQL, 37 Präsentationsschicht, 43 Programmiermodell, 227 Projektgruppe, 214 Prototyp, 215 Prozess, 12, 13, 224 Publish-Subscribe, 92 Push-Dienst, 196 Python, 175 QEDWiki, 204 Qualitätskontrolle, 224 Qualitätsmerkmal, 9 Ray Ozzie, 200 RDF,271 Realisierungsplattform, 5

17 Stichwortverzeichnis 291 Rechen-Grid, 165 Rechenleistung, 230 Rechenzeit, 236 Rechneradministration, 217 Redundanzfreiheit, 9 Regelsystem, 227 Remote ProcedureCall, 12 Request-Response-Modell, 22 Ressource, 13, 15 Ressourcen-Grid, 165 REST,105, 187, 188, 204, 233 Result Set, 31 RFID, 274 RMI, 28, 35, 190 RMI-Registry,29 RMI-Transportschicht, 29 Robustheit, 236 Rollback, 95 Routing, 110 RPC, 28, 188 RSS, 187, 197 S3, 180 SaaS, 265 Salesforce.com, 198 Schadenplattform, 248 Schichtenarchitektur,41 Schnittstelle, 9, 12, 91 Seeder,154 Semantic Web, 271 Semantik Wiki, 273 Server Proxy,201 Server-Virtualisierung, 265 Service Bus, 90, 110 Service Level Agreement, 224 Service Level Management, 169 Service Oriented Architecture, siehe SOA Service-Orientierung, 13, 121 Servlet, 50 Servlet-Engine, 50, 73 Session, 190 Session-Handling, 226 SGML, 92 Silverlight, 205 Single-Point-Of-Failure, 229 Skalierbarkeit, 218, 229, 235 Skeleton, 29 SOA, 16, 89, 105, 187, 199, 223, 236, 247, 252 SOA-Beispiel, 247 SOA-Einführung, 248 SOAP,94, 189 SOAP Body,94, 98 SOAP Handler,107 SOAP Header,94, 107 Sockets, 27, 32 Softwarearchitektur,4,7 Softwareentwickler,218 Softwarefehler,3 Softwarelebenszyklus, 213 Speicherbedarf, 10, 230 Spiralmodell, 215 Split-Stream-Protokoll, 153, 228 SQL, 72 SQLJ, 30 Stabilization Protocol, 153 starke Kohärenz, 8 statisches SQL, 30, 37 Storage Area Network, 267 Stub, 29 SVG, 205 SVN, 269 Swing, 190 Synchronisation, 13 Systemanalytiker,230 Systemarchitektur,4 Systemdesigner,4 Tag, 186 Taxonomie, 186 TCP/IP,27 Teilnehmerzahl, 235, 8 Test, 214 Thread, 13 TimBerners-Lee, 271 Token Ring, 15

18 292 Stichwortverzeichnis Tomcat, 50 Torrent, 154 Tracker Host, 154 Transaktion, 101, 222 Transaktionsmonitor,95 Ubiquitous Computing, 273 UDDI, 100 Ultra-Large-Scale System, 274 Umfeld, 218 UML, 215, 219, 221, 226 UMTS, 3 Unified Modeling Language, 52 VBA, 105 Verschlüsselung, 90, 226 Versionierung von Diensten, 103 Versionsproblematik, 225 verteiltes System, 11 Verteilung, 11 verwaltete Anwendungen, 64 VHV Gruppe, 248 Virtual Machine Monitor,267 ViSoGrid, 259 Visual Basic, 64, 190 Visual Studio, 220 vita.net,242 VMware, 267, 269 Vorgehensmodell, 226 W3C, 92 WAR-Archiv,72 Wartezeit, 13 Wasserfallmodell, 215 WCF,66, 69 Web1.0, 49, 185, 239 Web2.0, 16, 105, 185, 233, 261 Web3.0, 16 Weborientierte Architektur,185 WebService, 68, 89, 167, 171, 236, 247 Web Services Resource Framework, 169, 172 Web-Anwendung, 16 Web-Browser,50 Wegwerfartikel, 3 Wettbewerbsfaktor,4 White Pages, 100 Widgets, 203 Wiederverwendbarkeit, 10 Wiki, 186 Wikipedia, 185, 198, 269 Windows Communication Foundation, 66, 69 Windows Form, 87 Windows Presentation Foundation, 66 Windows Server,100 Windows Workflow Foundation, 66 WLAN, 3 WLCG, 257 WOA, 187 Workflow,224 Workflow Engine, 225 World Wide Web, 16 Worldwide LHC Computing Grid, 257 WPF,66 WS-BaseFaults, 173 WS-BPEL, 100, 112, 116, 225 WS-I, 93, 225 WS-Resource, 172 WS-Resource Lifetime, 173 WS-ResourceProperties, 172 WS-RF,169, 172 WS-ServiceGroup, 173 WSDL, 94, 98, 224 WSDL 2.0, 99 WSSE, 107 WWF,66 XEN, 267 XML Namespace, 96 XML Query,101 XML Schema, 92 XMLHttpRequest, 202 XPath, 101, 116, 195, 206 XSLT, 111, 195 Yahoo, 270 Yellow Pages, 100 Zertifikatsverwaltung, 225 Zigbee, 3 Zustandsautomat, 226 Zweischichtenarchitektur,44