Das Leistungspotential von DPWS für Service-orientiertes Ubiquitäres Computing

Transkript

1 HUMBOLDT-UNIVERSITÄT ZU BERLIN Mathematisch-Naturwissenschaftliche Fakultät II Institut für Informatik Das Leistungspotential von DPWS für Service-orientiertes Ubiquitäres Computing Diplomarbeit Zur Erlangung des Grades eines Diplom-Informatikers im Studiengang Informatik Betreuer: eingereicht von Robert Hilbrich geboren am 14. Juli 1981 in Löbau Marko Fabiunke, Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik Erstgutachter: Prof. Dr. rer. nat. habil. Bernd-Holger Schlingloff Humboldt-Universität zu Berlin Zweitgutachter: PD Dr. rer. nat. habil. Katinka Wolter Humboldt-Universität zu Berlin Berlin, den

2 ii

3 Kurzfassung Mit der zunehmenden Durchdringung des Alltags mit intelligenten Computersystemen liegt ein großes Potential für Innovationen in der engeren Integration der bereits bestehenden Anwendungen auf diesen Geräten. Neben den hohen technischen Anforderungen der dafür erforderlichen Vernetzung, ist auch die Entwicklung der notwendigen Software mit komplexen Herausforderungen konfrontiert. Die Realisierung von ubiquitären Anwendungen erfordert Flexibilität, Dynamik und Interoperabilität auf einer technischen Plattform, die durch eingeschränkte Ressourcen gekennzeichnet ist. In dieser Diplomarbeit wird die Realisierung der ubiquitären Anwendungen durch Web Services auf eingebetteten Geräten mit dem Devices Profile for Web Services (DPWS) untersucht. Nach einer vergleichenden Analyse der Anforderungen einer ubiquitären Software mit den Fähigkeiten des Devices Profile for Web Services, wird empirisch ermittelt, welcher Grad an Dynamik, Flexibilität und Performance mit diesem Ansatz bereits heute erreicht werden kann. Grundlage für diese Analyse ist die Messung von Latenzen für Interaktionen zwischen Web Services auf eingebetteten Geräten. Die Ergebnisse zeigen, dass noch nicht alle Anforderungen einer ubiquitären Software durch DPWS erfüllt werden können. Trotzdem besitzt DPWS durch seine Stärken bei der interoperablen Interaktion zwischen heterogenen Geräten und der dynamischen Bestimmung von Standortinformationen zur Laufzeit ein großes Innovationspotential in verschiedenen Anwendungsbereichen. Allerdings schlägt sich die erreichte Dynamik und die lose Kopplung auch in längeren Latenzen nieder, so dass Web Services ihren Einsatz als Middleware nicht allein durch ihre Performance begründen können. Abstract With more and more intelligent devices pervading everyday life, an increasing potential for innovations lies in the integration of the already existing applications on these devices. Although the ubiquitous connectivity bears a variety of technical difficulties in itself, the development of the necessary software layer is confronted with even higher challenges as the implementation of ubiquitous applications requires flexibility, mobility and interoperability on a technical platform with limited resources. This diploma thesis studies the realization of ubiquitous applications through Web Services on embedded devices by using the Devices Profile for Web Services (DPWS). Following a detailed survey of the requirements of ubiquitous applications and the distinct features of DPWS, a detailed description of the experiments conducted to analyse the runtime behaviour of this approach is given. It is based on the measurement of latencies in the interaction between Web Services on resource-constrained devices. The results show that DPWS can not satisfy all of the requirements of ubiquitous applications. Nevertheless, the strong points of DPWS, such as the interoperable interaction between heterogeneous devices and the dynamic localisation of service providers, justify its potential for innovative applications. Still, the loose coupling and the flexibility between software components have a noticeable impact on the latencies. Thus, DPWS will not be able to justify its use as a middleware solely based on its performance. iii

4 iv

5 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis vii ix 1 Einführung Thema Problemstellung Zielsetzung und Aufbau der Arbeit Softwareentwicklung für eingebettete Systeme Was sind eingebettete Systeme? Klassische Softwarearchitektur einfacher, eingebetteter Systeme Softwarearchitektur für verteilte, eingebettete Systeme Fazit Service-orientierte Architekturen für verteilte Systeme Geschäftsprozesse und Service-orientierte Architekturen Service-orientierte Architekturen als Middlewarekonzept Embedded SOA SOA, quo vadis? Fazit Umsetzung Service-orientierter Architekturen mit Web Services Einführung in die Technologie der Web Services Die grundlegenden Konzepte von Web Services Das maschinenlesbare Textformat XML Beschreibung von Services mit WSDL Austausch von Nachrichten mit SOAP Ein zentrales Serviceverzeichnis mit UDDI Kritikpunkte von Web Services Dynamische Anwendungen auf der Basis von dynamischer Integration Web Services auf eingebetteten Geräten Einführung und Anwendungsbereiche von DPWS DPWS Terminologien: Hosting Services und Hosted Services Der Aufbau des Devices Profile for Web Services Wird der Zielkonflikt durch DPWS gelöst? Fazit v

6 5 Moderne technologische Visionen auf der Basis von Embedded SOA Die Vision vom Ubiquitären Computing Einführung und Herkunft des Begriffs Ubiquitäres Computing DPWS als Middleware für Ubiquitäres Computing Ablauf der Interaktionen zwischen DPWS-Geräten in Szenarien des Ubiquitären Computings Weiterentwicklungen der Vision des Ubiquitären Computings Pervasive Computing Ambient Intelligence Organic Computing Fazit Die durchgeführten Experimente Die verwendeten DPWS-Implementierungen Microsoft R.NET Micro Framework WS4D-gSOAP Die verwendeten eingebetteten Geräte HiCO.ARM Tahoe.NET Micro Framework Development Platform FOX Board LX Laptop Latitude D620 und Lenovo Thinkpad T Erkenntnisziele der Experimente Vorstellung der Messmethode Abschätzung der Messgenauigkeit Darstellung der Ergebnisse Betriebsbereitschaft eines Service-Konsumenten Aufruf eines Services mit unterschiedlich stark strukturierten Parametern Anteil der DPWS-Funktionalität an der Gesamtlatenz Overhead durch die Nutzung von XML zur Übertragung der Rohdaten Auswirkungen einer veränderten MTU auf die Gesamtlatenz Stärken und Schwächen der untersuchten DPWS-Implementierungen Diskussion der Ergebnisse und Ausblick Das Leistungspotential des Devices Profile for Web Services Ausblick Zusammenfassung 97 Abkürzungsverzeichnis 103 Literaturverzeichnis 105 vi

7 Abbildungsverzeichnis 2.1 Eingebettete Systeme und Mehrzweck-Computersysteme Kontron nanoetxexpress-sp - ein eingebettetes System? Softwarearchitektur für einfache, eingebettete Systeme Softwarearchitektur für verteilte, eingebettete Systeme Middleware-Architektur für verteilte Systeme Logischer Aufbau einer Service-orientierten Architektur Die Abfolge der Interaktionen zwischen Services Beispiel für eine unternehmensübergreifende SOA Web Services als Schnittstelle zu Anwendungen Interaktionen zwischen Web Services Abbildung der Daten eines Hauses in XML Validierung von XML Dokumenten SOAP-Nachrichtenformat in abstrakter und konkreter Form Hierarchie der dynamischen Web Service Integration Integration von DPWS Geräten in die Netzwerkumgebung Discovery von Hosting und Hosted Services im Beispiel Der DPWS-Protokollstapel und die enthaltenen Protokolle Kanonischer Ablauf einer realisierbaren Interaktion Aufbau des Microsoft R.NET Micro Frameworks Der Aufbau der WS4D-gSOAP Implementierung Aufbau der Stoppuhr zur Messung der Verzögerungszeiten Reale und gemessene Laufzeiten Genauigkeit der Stoppuhr bzgl. Größtfehler und Standardabweichung Schritte zur Herstellung der Betriebsbereitschaft Absolute Zeiten für die Schritte zur Herstellung der Betriebsbereitschaft SOAP-Nachrichten mit stark- und gering-strukturierten Parametern Service-Aufrufe mit steigender Anzahl an Integer-Parametern Service Aufrufe mit steigender Länge des String-Parameters Vergleich der Service-Aufrufe mit unterschiedlichen Parametern Anteil der DPWS-Funktionalität an der Gesamtlatenz Latenzen für einen DPWS-Service-Aufruf (Integer-Parameter) Latenzen für einen DPWS-Service-Aufruf (String-Parameter) Übertragung der Rohdaten im Vergleich zu einem DPWS-Service-Aufruf Auswirkungen einer verringerten MTU auf die Latenzen vii

8 viii

9 Tabellenverzeichnis 6.1 Leistungsdaten des HiCO.ARM9 Boards Leistungsdaten der Tahoe.NET Micro Framework Development Platform Leistungsdaten des FOX Board LX Leistungsdaten der Laptops Analyse der Messgenauigkeit der Stoppuhr ix

10 x

11 Kapitel 1 Einführung 1.1 Thema Die tradierte Form der Computernutzung steht vor einem durchgreifenden Wandel, der den Anwender und dessen Bedürfnis nach einer einfachen und intuitiven Nutzung der verfügbaren Technologien in den Mittelpunkt stellt. Dieser Paradigmenwechsel macht eine enge Integration von Computersystemen und Alltagsgegenständen erforderlich, damit ihre Benutzung intuitiv im Hintergrund erfolgen kann und sich damit der bewussten Wahrnehmung durch den Anwender entzieht. Computersysteme werden in der Folge dieses Wandels in der Umgebung allgegenwärtig und dabei gleichzeitig auch zunehmend unauffälliger. Dieser Wandel wird als Ubiquitäres Computing 1 bezeichnet und motiviert die Forschung in verschiedenen Bereichen der Informations- und Kommunikationstechnik seit fast 20 Jahren. Charakteristisch für diesen Trend ist der Fokus auf der Erweiterung bestehender, physikalischer Gegenstände durch ubiquitäre Anwendungen, die eine engere Integration und Kollaboration mit anderen Gegenständen in der Umgebung erlauben. Damit werden neue Formen kontextsensitiver Anwendungen möglich, die den Benutzer durch ein tieferes Verständnis von dessen Umgebungssituation und einem darauf abgestimmten Verhalten besser unterstützen können und damit ihren Gebrauchswert für den Anwender steigern. Als Folge der Fortschritte in den Bereichen der Mikrosystemtechnik, Mikroelektronik und Netzwerktechnik in den letzten Jahren rückte die Vision des Ubiquitären Computings näher an den Bereich des Machbaren heran. So sind mittlerweile Computersysteme verfügbar, die in Hinblick auf ihre Ressourcen, ihre physikalischen Ausmaße und ihre integrierten Kommunikationstechnologien den Anforderungen des Ubiquitären Computings entsprechen. Obwohl es auch im Bereich der Software für diese verteilten Systeme in den letzten Jahren Fortschritte gab, ist die Realisierung der ubiquitären Anwendungen noch immer mit vielen Herausforderungen verbunden und Gegenstand der aktuellen Forschung. 1 Rechnerallgegenwart oder allgegenwärtiges Rechnen 1

12 Kapitel 1 Einführung 1.2 Problemstellung Typische Szenarien aus der Vision des Ubiquitären Computings sind gekennzeichnet durch Interaktionen und Kollaborationen zwischen hochgradig spezialisierten, heterogenen Computersystemen, die durch die Flexibilität in ihrer Software eine weitgehende Mobilität von Geräten und Anwendern erlauben. In Hinblick auf das Ziel einer Steigerung des Gebrauchwertes für den Nutzer, sind die ubiquitären Applikationen auch nicht mehr nur auf die Ressourcen ihres physischen Trägers beschränkt. Stattdessen kann ihre Funktionalität automatisch erweitert werden, indem - für den Anwender vollkommen transparent - benachbarte Ressourcen eingebunden werden. Strukturell ist dieser Ansatz mit einem Ökosystem vergleichbar, in dem sich kleine, funktionale Einheiten dynamisch und zielgerichtet kombinieren, so dass die Funktionalität der so entstehenden Cluster über die Fähigkeiten der einzelnen Komponenten hinaus geht. Die Entwicklung von Software für die Geräte des Ubiquitären Computings ist daher mit sehr komplexen Anforderungen konfrontiert. Es stellt sich die Frage, wie Software strukturiert werden kann, so dass sie sowohl den speziellen Anforderungen der Szenarien gerecht wird und gleichzeitig auch die dabei entstehende Komplexität für den Entwickler beherrschbar gestaltet. Weiter verschärft wird diese Problematik durch die besonderen Eigenschaften der Geräte des Ubiquitären Computings. Um den Anforderungen nach geringen Ausmaßen, einem geringem Energieverbrauch und geringen Herstellungskosten für eine ubiquitäre Durchdringung gerecht zu werden, sind diese speziellen Geräte durch eingeschränkte Ressourcen gekennzeichnet. Vor dem Hintergrund der konfligierenden Ziele minimaler Betriebs- und Herstellungskosten sowie maximaler Ressourcen für eine komplexe Softwareschicht stellt sich die Frage, welches Komplexitätsniveau in der Software auf heute verfügbaren und in die Umgebung integrierbaren Computersystemen mit limitierten Ressourcen realisiert werden kann. 1.3 Zielsetzung und Aufbau der Arbeit Mit dem Devices Profile for Web Services (DPWS) wurde ein neuer Standard veröffentlicht, der die Implementierung von Web Services auf eingebetteten Geräten und ihre Interaktionen in dynamischen Umgebungen spezifiziert. Dieser Standard stellt einen Kompromiss für den oben beschriebenen Zielkonflikt dar, indem er die Realisierung von komplexer Funktionalität auf eingeschränkten Ressourcen ermöglichen soll. Das Ziel dieser Arbeit ist es, das Leistungspotential dieser Spezifikation in Hinblick auf die Entwicklung von ubiquitären Anwendungen zu evaluieren. Dazu müssen die folgenden Aspekte detailliert untersucht werden: Wie können ubiquitäre Anwendungen mit dem Devices Profile for Web Services auf Geräten mit eingeschränkten Ressourcen implementiert werden? Welche Aspekte einer ubiquitären Anwendung sind mit diesem Ansatz nicht realisierbar? 2

13 1.3 Zielsetzung und Aufbau der Arbeit Wie läßt sich das Laufzeitverhalten dieses Ansatzes auf den speziellen Computersystemen mit hinreichender Genauigkeit messen, ohne dabei das Verhalten durch den Messvorgang signifikant zu beeinflussen? Welche Performance läßt sich mit diesem Ansatz auf aktuellen Computersystemen mit eingeschränkten Ressourcen erreichen? Wie müssen Szenarien beschaffen sein, in denen sich das Potential dieses Ansatzes bereits heute sinnvoll nutzen läßt? Dazu werden im Kapitel 2 zunächst die besonderen Eigenschaften der spezialisierten Computersysteme und das Vorgehen zur Entwicklung von komplexer Software für diese Systeme vorgestellt. Das Ziel dieses Kapitels ist die Einführung des Begriffs Middleware als abstraktes Strukturschema bei der Entwicklung umfangreicher, verteilter Anwendungen. Mit dem Paradigma der Service-orientierten Architekturen wird anschließend in Kapitel 3 ein besonderes Middlewarekonzept für verteilte Systeme - und im Speziellen auch für verteilte, eingebettete Systeme - vorgestellt. Die Erwartungen hinsichtlich der zukünftigen Entwicklung und Durchsetzungskraft dieses Paradigmas sind kontrovers und werden daher ebenfalls in diesem Kapitel diskutiert. Das Kapitel 4 baut auf diesen Erkenntnissen auf und stellt mit den Web Services die defacto Standard-Implementierung Service-orientierter Architekturen vor. Im Anschluss an eine Analyse der charakteristischen Vor- und Nachteile dieser Technologie, wird das Devices Profile for Web Services als reduzierte Form der umfangreichen Web Services Spezifikationen eingeführt. Diese besondere Teilmenge der Web Services bildet den zentralen Untersuchungsgegenstand in dieser Arbeit, so dass dessen Eigenschaften und Anwendungsmöglichkeiten in diesem Kapitel ebenfalls detailliert beschrieben werden. Mit dem Kapitel 4 ist die Vorstellung der relevanten, technischen Grundlagen abgeschlossen. Das Kapitel 5 untersucht die besonderen Anforderungen des Ubiquitären Computings und vergleicht diese mit den Fähigkeiten des bereits eingeführten Devices Profile for Web Services. Das Ergebnis dieser Analyse ist die Vorstellung einer mit Hilfe des Devices Profile for Web Services realisierbaren Interaktion, die den speziellen Anforderungen des Ubiquitären Computings gerecht wird. Sie bildet die Grundlage für die Experimente zur Ermittlung des Leistungspotentials DPWS-basierter Anwendungen auf Geräten mit eingeschränkten Ressourcen. Aufgrund der umfangreichen Terminologie und der komplexen Thematik wird den Kapiteln 2, 3, 4 und 5 jeweils ein Strukturschema vorangestellt, dass das Verständnis für den Leser erleichtern soll, indem die wichtigen inhaltlichen Bezüge zwischen den einzelnen Themen noch einmal graphisch aufgearbeitet werden. Zusätzlich besitzen diese Kapitel jeweils auch ein kurzes Fazit, das die wesentlichen inhaltlichen Aspekte des jeweiligen Kapitels in Hinblick auf das Thema der Arbeit noch einmal zusammenfasst. Die Erkenntnisziele und die damit verbundenen Experimente zur Ermittlung des Laufzeitverhaltens DPWS-basierter Anwendungen auf Geräten mit eingeschränkten Ressourcen werden im anschließenden Kapitel 6 beschrieben. Neben der Vorstellung der 3

14 Kapitel 1 Einführung verwendeten Geräte und der eingesetzten DPWS-Implementierungen wird hier auch auf den Aufbau zur Messung der Latenzen und auf die dabei erreichte Messgenauigkeit eingegangen. Das Kapitel 7 nimmt die im vorhergehenden Kapitel vorgestellten Erkenntnisziele als Grundlage für die Darstellung der Ergebnisse aus den Messungen. Eine weiterführende Auswertung der Ergebnisse in Hinblick auf das Leistungspotential des Devices Profile for Web Services erfolgt im Anschluss in Kapitel 8. Dabei wird auch auf die Eigenschaften, der mit diesem Ansatz bereits heute realisierbaren Szenarien, eingegangen. Nach einem Überblick über die Ansätze für eine weiterführende Forschung bildet die Zusammenfassung in Kapitel 9 den Abschluss dieser Arbeit. 4

15 Kapitel 2 Softwareentwicklung für eingebettete Systeme Dieses Kapitel widmet sich der Fragestellung, wie komplexe Software für eingebettete Systeme mit eingeschränkten Ressourcen entwickelt werden kann, so dass dabei sowohl die Flexibilität als auch die Effizienz des Gesamtsystems erhalten bleiben. Dazu werden zunächst die besonderen Eigenschaften eingebetteter Systeme zusammen mit den sich daraus ergebenden Anforderungen für die Softwareentwicklung herausgearbeitet. Anschließend wird die Middleware als besondere Schicht innerhalb eines Schichtenmodells eingeführt, die den Aspekt der Verteilung einer Anwendung auf verschiedene Geräte kapselt. Die Auswirkungen der Beschränkungen eingebetteter Systeme auf die Gestaltung eines Schichtenmodells - insbesondere auf die Middleware - sind der Ausgangspunkt für die Formulierung eines zentralen Zielkonfliktes. Softwarearchitektur für verteilte Systeme Hohe Komplexität ist konfrontiert mit Paradigmen Implementierungsstandards erfordert Abstraktion & Flexibilität teilweise realisiert mit Middleware beschränken beschränken eingebettete Systeme Visionen 5

16 Kapitel 2 Softwareentwicklung für eingebettete Systeme 2.1 Was sind eingebettete Systeme? Ein eingebettetes System bezeichnet ein spezielles Computersystem, dessen besondere Eigenschaften für den weiteren Verlauf der Arbeit von zentraler Bedeutung sind. Als Einführung wird zunächst auf die Begriffsdefinition von Scholz zurückgegriffen. Eingebettete Systeme sind Computersysteme, die aus Hardware und Software bestehen und die in komplexe technische Umgebungen eingebettet sind. Solche Umgebungen können maschinelle Systeme wie etwa Kraftfahrzeuge, Flugzeuge, Fernsehgeräte, Waschmaschinen, Küchengeräte, Mobilfunktelefone u.a. sein, die der Interaktion eines menschlichen Benutzers bedürfen oder vollautomatisch agieren. (Scholz, 2007, S. V) In der Vergangenheit waren eingebettete Systeme und Mehrzweck-Computersysteme das Ergebnis einer Systementwicklung mit grundlegend verschiedenen Zielsetzungen und Prioritäten (siehe Abbildung 2.1). Eine klare Zuordnung eines vorliegenden Computersystems zur Gruppe der eingebetteten Systeme oder Mehrzweck-Computersystemen war damit auf der Grundlage von dessen Eigenschaften möglich. Neben dem hohen Grad der Spezialisierung unterschied sich ein eingebettetes System in Hinblick auf die verfügbaren Ressourcen und die damit verbundenen Betriebs- und Herstellungskosten deutlich von einem Mehrzweck-Computersystem. Durch die eingeschränkten Ressourcen waren eingebettete Systeme auch durch eine geringe Komplexität in der Software gekennzeichnet. hoch Herstell- und Betriebskosten gering hoch verfügbare Ressourcen gering hoch Komplexität der Software gering Mehrzweck-Computersystem gering Spezialisierung hoch eingebettetes System Abbildung 2.1: Eingebettete Systeme und Mehrzweck-Computersysteme als Ergebnis unterschiedlicher Zielsetzungen beim Systementwurf Als Folge der Fortschritte in der Mikrosystemtechnik und Mikroelektronik gehen die Begriffe eingebettetes System und Mehrzweck-Computersystem mittlerweile zunehmend ineinander über, wodurch eine klare Systematisierung der Begriffe erschwert wird. Es sind Computersysteme erhältlich (siehe Abbildung 2.2), die zwar aufgrund ihrer physischen Ausmaße, ihrer Herstellungskosten und ihrer Leistungsaufnahme zu den eingebetteten Systemen gezählt werden können, sich aber hinsichtlich der verfügbaren 6

17 2.1 Was sind eingebettete Systeme? Ressourcen und der einsetzbaren Software nicht von aktuellen Mehrzweck-Computersystemen unterscheiden. Abbildung 2.2: Kontron nanoetxexpress-sp - ein eingebettetes System? Größe 55 mm 84 mm, Leistungsaufnahme 4.5 W, Intel R Atom TM Prozessor mit 1.6 GHz, 1024 MB DDR2 SDRAM Arbeitsspeicher, Gigabit-Ethernet, Serial ATA, USB 2.0,... (Quelle: Kontron AG, In dieser Arbeit wird ein eingebettetes System daher aufgrund der Intention seiner Entwicklung und nicht basierend auf den Eigenschaften des Resultats definiert. Ein eingebettetes System zeichnet sich damit durch eine ex-ante Beschränkung des Systemzwecks aus, mit der bereits zum Zeitpunkt der Entwicklung die verfügbaren Ressourcen optimal bemessen werden können. Im Gegensatz zu Mehrzweck-Computersystemen, bei denen die Ressourcen entsprechend einem vorher unbekannten, aber möglichst universellen Einsatz dimensioniert sind, verfügen eingebettete Systeme meist nur über die minimal notwendigen Ressourcen, die zur Erfüllung ihrer Aufgabe notwendig sind. Bedingt durch die Spezialisierung eines eingebetteten Systems und der damit verbundenen Einschränkung der Ressourcen ist auch die Leistung und Flexibilität der darauf eingesetzten Software limitiert. Eine der größten Herausforderungen und zugleich wesentliches Merkmal der Softwareentwicklung für bereits existierende eingebettete Systeme liegt daher in den eingeschränkten Ressourcen. Diese limitieren die Komplexität der Software, die auf diesen Systemen eingesetzt werden kann, so dass oft anstelle von dynamischer Logik zur Laufzeit eines Systems statischen Entscheidungen zur Entwicklungszeit der Vorzug gegeben wird. Dies ist eine Konsequenz aus der Tatsache, dass je mehr Entscheidungen bereits zur Entwicklungszeit getroffen werden können und je mehr explizites Wissen bereits zu diesem Zeitpunkt in den Softwareentwurf einfließt, umso weniger Unsicherheit zur Laufzeit besteht. Damit müssen auch weniger Entscheidungen mit Hilfe komplexer Logik auf einer Plattform mit eingeschränkten Ressourcen getroffen werden. In der Vergangenheit zeichnete sich die Software auf eingebetteten Systemen daher durch einen hohen Grad an Determinismus und ein geringes Komplexitätsniveau aus. 7

18 Kapitel 2 Softwareentwicklung für eingebettete Systeme Diese Eigenschaften beschränkten gleichzeitig auch die Einsatzmöglichkeiten eingebetteter Systeme auf Bereiche, in denen die Anforderungen eine derartige Umsetzung erlauben. Häufig wurden eingebettete Systeme daher im Bereich der Regelungstechnik und Steuerungselektronik eingesetzt. Während die Bezeichnung eingebettetes System sowohl die Hardware als auch die Software umfasst, bezieht sich der Begriff eingebettetes Gerät in dieser Arbeit nur auf die Hardware, also beispielsweise auf die Systemplatine mit den entsprechenden Komponenten, wie Prozessor, Arbeitsspeicher, Sensorik und Netzwerkanschluß. Die Anzahl an eingebetteten Geräten, aus denen ein eingebettetes System aufgebaut ist, kann zu einer weiteren Klassifizierung eingebetteter Systeme herangezogen werden. Besteht ein eingebettetes System (ES) aus genau einem eingebetteten Gerät, so wird es in dieser Arbeit auch als einfaches, eingebettetes System (EES) bezeichnet. Die Bezeichnung einfach annotiert die Tatsache, dass die Aufgabe für ein EES ein hinreichend geringes Maß an Komplexität besitzt, so dass eine Realisierung mit nur einem Gerät möglich ist. Überschreitet die Komplexität des Systemzwecks allerdings ein bestimmtes Level, so ist die Realisierung nicht mehr mit nur einem einfachen, eingebetteten System möglich. Es muss stattdessen ein verteiltes, eingebettetes System (VES) konzipiert werden. Tanenbaum und van Steen liefern eine gute Definition für ein verteiltes System, die gleichzeitig auch auf den Spezialfall eines verteilten, eingebetteten Systems anwendbar ist. Ein verteiltes System ist eine Menge voneinander unabhängiger Computer, die dem Benutzer wie ein einzelnes, kohärentes System erscheinen. (Tanenbaum und van Steen, 2007, S. 18) Eine wesentliche Besonderheit eines verteilten Systems liegt damit in der Unsichtbarkeit der Heterogenität der beteiligten Computer und deren Kommunikationsstruktur für den Nutzer. Gleichzeitig ist auch die Interaktion zwischen dem Nutzer und der Anwendung eines verteilten Systems vollkommen unabhängig vom konkreten Ort, an dem sie stattfindet. Ein System, das über diese Eigenschaften verfügt und damit in der Lage ist, die Tatsache zu verbergen, dass Ressourcen physisch über mehrere Computersysteme verteilt sind, wird auch als transparent bezeichnet (Tanenbaum und van Steen, 2007, S. 21ff). Bei einem verteilten, eingebetteten System wird der Funktionszweck demnach nicht nur durch die beteiligten Geräte selbst, sondern erst durch deren Vernetzung und Kollaboration realisiert. Das Attribut verteilt verdeutlicht die Tatsache, dass die Geräte zusammenarbeiten, um das gewünschte Systemverhalten zu erreichen. Im Vergleich zu verteilten Systemen besitzen verteilte, eingebettete Systeme lediglich die zusätzliche Einschränkung, dass anstelle beliebiger voneinander unabhängiger Computer (Tanenbaum und van Steen, 2007, S. 18) nur eingebettete Geräte zum Einsatz kommen. Auch die Softwareentwicklung muss auf die Unterschiede zwischen einfachen und verteilten, eingebetteten Systemen eingehen und dabei den Entwickler bestmöglich unterstützen, um eine hohe Softwarequalität zu gewährleisten. Dazu wird im nächsten 8

19 2.2 Klassische Softwarearchitektur einfacher, eingebetteter Systeme Abschnitt zunächst das prinzipielle Vorgehen bei der Entwicklung für ein EES vorgestellt. Auf dieser Grundlage werden im Anschluss die Besonderheiten im Umgang mit verteilten, eingebetteten Systemen herausgearbeitet. 2.2 Klassische Softwarearchitektur einfacher, eingebetteter Systeme Der naive Ansatz, Software für einfache, eingebettete Systeme zu strukturieren, liegt im Entwurf eines monolithischen Blocks, der die gesamte Logik zur Umsetzung des Systemzwecks enthält. Obwohl diese Architekturform eine sehr performante Umsetzung ermöglicht, konnte sie sich trotzdem nicht durchsetzen und wurde von einer Schichtenarchitektur abgelöst. Die Schichtenarchitektur setzt neben der Effizienz auch eine hohe Priorität auf die Wiederverwendbarkeit und leichte Wartbarkeit der einzelnen Softwarekomponenten. Gleichzeitig soll mit diesem Ansatz auch der Umgang mit der Hardware für den Softwareentwickler vereinfacht werden, so dass sich dieser möglichst nur auf die hochsprachliche Beschreibung von Algorithmen beschränken kann, anstatt konkrete Maschinenbefehle verinnerlichen zu müssen. In Untersuchungen konnte gezeigt werden, dass Programmierer, die Hochsprachen verwenden, im Vergleich zu jenen, die Maschinensprachen einsetzen, um den Faktor 5-15 produktiver sind und gleichzeitig auch noch eine höhere Softwarequalität erreichen (Brooks (1987) und McConnell (2004), S. 63). Eine Schichtenarchitektur wird erreicht, indem der monolithische Block in einzelne Schichten gespalten wird, die jeweils einem Abstraktionsniveau entsprechen. In Abbildung 2.3 ist dieses Strukturschema dargestellt. Jede Schicht stellt dabei bestimmte Funktionen zur Nutzung durch andere Schichten mit einem höheren Abstraktionsniveau bereit. Welche konkreten Funktionen mit welchen Parametern zur Nutzung angeboten werden, wird durch eine horizontale Schnittstelle spezifiziert. Da die einzigen Abhängigkeiten zwischen verschiedenen Schichten klar und explizit durch Schnittstellen definiert sind, läßt sich die Implementierung einer Schicht leicht modifizieren oder austauschen. Die einzige Anforderung besteht in der Erfüllung der vorher definierten Schnittstelle, denn die Umsetzung selbst ist für andere Schichten nicht sichtbar. Mit dieser Methodik lassen sich die Schichten einer Software so gestalten, dass die spezifischen Mechanismen zur Interaktion mit der Hardware in höheren Schichten schrittweise hinter generischen Schnittstellen verborgen werden. Für den Systementwickler ergeben sich daraus verschiedene Vorteile. Zunächst wird die Entwicklung der Applikation in den höheren Schichten einfacher, da auf Funktionen tiefer liegender Schichten zurückgegriffen werden kann. Die Spezifizierung der Abläufe zur Umsetzung des Systemzwecks kann damit auf einem höheren Abstraktionsniveau erfolgen, so dass damit die Anfälligkeit für Programmierfehler sinkt. Die Bindung von Schichten an Schnittstellen steigert auch die Wiederverwendbarkeit von Quellcode, 9

20 Kapitel 2 Softwareentwicklung für eingebettete Systeme Software horizontale Schnittstelle A Schicht 1 hoch (aufgabenspezifisch) horizontale Schnittstelle B Schicht 2 Abstraktionsniveau Schicht 3 gering (hardwarespezifisch) Abbildung 2.3: Softwarearchitektur für einfache, eingebettete Systeme denn damit kann die Logik höherer Schichten ohne Änderung auch auf anderen Computersystemen mit den gleichen Schnittstellen tieferer Schichten zum Einsatz kommen. Abstraktion hat allerdings auch ihren Preis, denn jede zusätzliche Abstraktionsebene verringert die Effizienz. Die Verwaltung der Schnittstellen führt zu einem Mehraufwand (engl. Overhead), der die Performance spürbar reduzieren kann. Während dieser Architektur-Overhead bei aktuellen, leistungsfähigen Mehrzweck-Computersystemen zunehmend gegenüber den Vorteilen der Abstraktion beim Entwicklungsprozess akzeptiert wird, ist die Softwarearchitektur für eingebettete Systeme immer als Kompromiss zwischen Modularität und Effizienz zu sehen. 2.3 Softwarearchitektur für verteilte, eingebettete Systeme Das klassische Vorgehen bei der Entwicklung von Software für verteilte, eingebettete Systeme besteht in der Erweiterung der bereits eingeführten Schichtenarchitektur. In in Abbildung 2.4 auf Seite 11 ist eine erweiterte Architektur für verteilte, eingebettete Systeme dargestellt. Zusätzlich zu den bereits eingeführten horizontalen Schnittstellen, werden nun vertikale Schnittstellen ergänzt, die die Kommunikation zwischen den Schichten auf verschiedenen Geräten definieren. Diese vertikalen Schnittstellen sind das Ergebnis der Spezifikation von Kommunikationsprotokollen zwischen gleichen Schichten auf unterschiedlichen Geräten. In diesen Kommunikationsprotokollen ist der Austausch von Daten und Verwaltungsinformationen festgehalten. Mit diesem Ansatz wird mit jeder neuen Schicht neben einer horizontalen Schnittstelle auch noch eine vertikale Schnittstelle ergänzt, so dass der Umfang und die Komplexität der Software ansteigen. Um dennoch die avisierten Ziele eines verteilten 10

21 2.3 Softwarearchitektur für verteilte, eingebettete Systeme Software-Instanz 1 Software-Instanz 2 horizontale Schnittstelle A horizontale Schnittstelle B vertikale Schnittstelle 1 Schicht 1 Schicht 1 vertikale Schnittstelle 2 Schicht 2 Schicht 2 vertikale Schnittstelle 3 Schicht 3 Schicht 3 horizontale Schnittstelle A horizontale Schnittstelle B Abbildung 2.4: Softwarearchitektur für verteilte, eingebettete Systeme Systems (Transparenz der Heterogenität der Geräte und Kommunikationsstrukturen sowie Transparenz der Verteilung von Ressourcen) zu erreichen und gleichzeitig die Komplexität der Anwendungsentwicklung zu reduzieren, wird eine weitere Abstraktionsebene - die Middleware - eingeführt. Sie enthält die Mechanismen zur Verwaltung der Kommunikation zwischen den Geräten und kapselt gleichzeitig auch die Funktionen zur Interaktion mit der Hardware. Die Middleware verdankt ihren Namen der mittigen Anordnung zwischen der Schicht, die das Betriebssystem beinhaltet, und der Schicht, die die Logik der verteilten Anwendung enthält (siehe Tanenbaum und van Steen, 2007, S. 18). Da erst unterhalb der Middleware die eigentliche Kommunikation bzw. die Verteilung der Anwendung realisiert wird, ist auch die Bezeichnung Verteilungsplattform gebräuchlich (Puder und Römer, 2002, S. 23). In Abbildung 2.5 auf Seite 12 ist diese klassische Form der Software-Architektur für verteilte Systeme als Übersicht dargestellt. Durch die Nutzung einer Middleware wird die Entwicklung einer verteilten Anwendung wesentlich vereinfacht, da die Verwaltung der Verteilungsaspekte größtenteils von der Middleware übernommen wird und nicht im direkten Verantwortungsbereich des Programmierers der Anwendungslogik liegt. Aus dessen Sicht wird das Komplexitätsniveau einer Anwendung für ein VES fast auf das Niveau eines EES reduziert. Wie bereits im vorigen Abschnitt erläutert wurde, ist die Einführung weiterer Schichten mit erhöhtem Overhead verbunden, der sich negativ auf die Performance des Gesamtsystems auswirken kann. Insbesondere bei verteilten, eingebetteten Systemen mit eingeschränkten Ressourcen entsteht hier ein Zielkonflikt, denn gerade bei Geräten mit geringen Ressourcen ist der Einfluss durch den Architektur-Overhead der zusätzlichen Abstraktionsebenen signifikanter. Die Entwicklung von Software für ein verteiltes, eingebettetes System erfordert daher immer einen Kompromiss zwischen der Effizienz des Gesamtsystems und der Vereinfachung des Entwicklungsprozesses. Meist 11

22 Kapitel 2 Softwareentwicklung für eingebettete Systeme Verteilte Anwendung Verteilte Anwendung Abstraktion von Netzwerk und Hardware Middleware Middleware Betriebssystem Betriebssystem Abbildung 2.5: Middleware-Architektur für verteilte Systeme wird dieser Kompromiss auf der Grundlage einer Kostenanalyse geschlossen. Aus betriebswirtschaftlicher Sicht stellt sich damit die Frage, wie das konkrete Verhältnis der Personalkosten der Entwickler zu den Herstellungs- und Betriebskosten der eingebetteten Geräte beschaffen ist. Je einfacher die Entwicklung eines VES ist, umso weniger Spezialisten werden für die Programmierung benötigt. Allerdings erhöht ein einfacherer Entwicklungsprozess auch die Kosten für schnellere Prozessoren bzw. mehr Arbeitsspeicher, um die verringerte Performance auszugleichen. Im Zuge sinkender Herstellungskosten für Hardware und gleichzeitig steigender Personalkosten für IT-Fachkräfte, ist zu erwarten, dass dieser Kompromiss zunehmend zugunsten eines vereinfachten Entwicklungsprozesses entschieden wird. Es ist daher eine notwendige und zugleich aktuelle Aufgabe der Forschung, effiziente Middleware- Technologien zu entwickeln, die den besonderen Einschränkungen eingebetteter Systeme Rechnung trägt. 2.4 Fazit Ein eingebettetes System ist ein spezielles Computersystem, das sehr eng in seine Umgebung integriert ist und zur Erfüllung einer vorgegebenen Aufgabe mit den dafür minimal notwendigen Ressourcen ausgestattet ist. Überschreitet die Aufgabe ein bestimmtes Komplexitätsniveau, kann sie nur durch die Kollaboration mehrerer Geräte realisiert werden. Erstrecken sich die Ressourcen eines eingebetteten Systems über mehrere eingebettete Geräte, so wird das Gesamtsystem als verteiltes System - genauer gesagt als verteiltes, eingebettetes System - bezeichnet. Um sowohl die Entwicklung als auch die Wartung und Wiederverwendbarkeit von Softwarekomponenten zu vereinfachen, wird eine Schichtenarchitektur zur Strukturie- 12

23 2.4 Fazit rung verwendet. Jede Schicht repräsentiert dabei ein bestimmtes Abstraktionsniveau. Die eigentliche Funktionalität einer Schicht wird über explizite Schnittstellen anderen Schichten zugänglich gemacht, wobei die konkrete Implementation vor der nutzenden Schicht verborgen bleibt. Die Schichtenarchitektur beim Softwareentwurf für ein verteiltes System besitzt eine Middleware. Dies ist eine besondere Schicht, die die Aufgabe hat, den Verteilungsaspekt und die Heterogenität der Geräte für höhere Schichten zu verdecken. Die Trennung in Schichten, insbesondere die Einführung einer Middleware, vereinfacht die Entwicklung verteilter Anwendungen. Allerdings ist sie mit dem inhärenten Nachteil des Architektur-Overheads verbunden. Gerade bei verteilten, eingebetteten Systemen mit eingeschränkten Ressourcen ist die Auflösung dieses Zielkonfliktes zwischen Systemeffizienz und Entwicklungsaufwand anhand einer Kostenanalyse ein notwendiger Bestandteil der Systementwicklung. 13

24 Kapitel 2 Softwareentwicklung für eingebettete Systeme 14

25 Kapitel 3 Service-orientierte Architekturen für verteilte Systeme Dieses Kapitel widmet sich der Frage, an welchem grundlegenden Paradigma sich die Gestaltung einer Middleware orientieren kann, um eine geeignete Abstraktion der Realität zu schaffen und gleichzeitig die Entwicklung verteilter Anwendungen zu erleichtern. Dazu werden in diesem Kapitel Service-orientierte Architekturen als Design-Paradigma eingeführt. Sie stammen aus dem Bereich des Geschäftsprozessmanagements und erleichtern die Modellierung von IT-Systemen, die die Geschäftsprozesse eines Unternehmens unterstützen. Unter der Bezeichnung Embedded SOA wird in diesem Kapitel auch eine alternative Nutzung Service-orientierter Architekturen vorgestellt. Sie besteht in der Verwendung dieser Konzeption zur Gestaltung einer Middleware für verteilte, eingebettete Systeme. Softwarearchitektur für verteilte Systeme Modellierung von Geschäftsprozessen ist konfrontiert mit Paradigmen ist Anwendung für Implementierungsstandards Hohe Komplexität erfordert konzipieren eine Service-orientierte Architekturen (SOA) ist eine spezielle Abstraktion & Flexibilität teilweise realisiert mit ist Konzept einer Middleware für Embedded SOA Middleware beschränken beschränken eingebettete Systeme Visionen 15

26 Kapitel 3 Service-orientierte Architekturen für verteilte Systeme 3.1 Geschäftsprozesse und Service-orientierte Architekturen Die grundlegenden Abläufe in einem Unternehmen, die unmittelbar oder auch nur mittelbar mit der Geschäftstätigkeit verbunden sind, werden als Geschäftsprozesse bezeichnet. Deren bestmögliche Unterstützung durch IT-Systeme ist Gegenstand des Geschäftsprozessmanagements und ein wichtiger Forschungsschwerpunkt der Wirtschaftsinformatik. Die bestmögliche Unterstützung ist durch den Ansatz gekennzeichnet, dass die Geschäftsabläufe die Anforderungen und den Aufbau der IT-Systeme definieren und nicht umgekehrt. Dieser Ansatz zur Strukturierung der IT-Systeme eines Unternehmens entlang zugrunde liegender Prozesse mit jeweils einzelnen, abgegrenzten Teilschritten, führte auch im Bereich der Softwareentwicklung zu einem neuen Modellierungskonzept. Charakteristisch für diesen neuen Ansatz ist die Verwendung einer besonderen Abstraktionsebene, die die Geschäftsprozesse eines Unternehmens abbildet und dabei bewusst auf die Zuordnung zu konkreten Computersystemen und Technologien verzichtet. Vordergründiges Ziel dieses Modellierungskonzeptes ist die Trennung von Strategie und Mechanismus (Tanenbaum und van Steen, 2007, S. 25ff.), ein Ansatz, der - nicht nur aus Kostensicht - eine Systemkomposition aus kleinen, austauschbaren Komponenten (ebda.) nahe legt. Wird der Ablauf eines Geschäftsprozesses in mehrere Einzelschritte zerlegt, die jeweils mit Hilfe von IT-Systemen automatisiert werden, entstehen einzelne Services, die eine genau festgelegte Funktionalität realisieren. Die Zusammensetzung passender Services in der richtigen Reihenfolge ergibt einen von IT-Systemen unterstützten Geschäftsprozess 1. Damit rücken Services und ihre Konkatenationen in den Fokus des Modellierungsansatzes und begründen die Bezeichnung Service-orientierte Architektur (SOA). Bei der Modellierung eines Geschäftsprozesses entsprechend einer Service-orientierten Architektur können die folgenden Modellierungskomponenten verwendet werden (siehe Josuttis (2007), S. 9ff; Dostal et al. (2005), S. 12ff): Service (auch: Dienst) Ein Service ist ein in sich vollständiges Software-Modul, das einen oder mehrere Schritte eines Geschäftsprozesses umsetzt. Services besitzen einen nicht öffentlichen Teil, der die Funktionalität implementiert und eine öffentliche Schnittstelle zu diesen Funktionen. Enterprise Service Bus Ein Enterprise Service Bus realisiert die Verbindung zwischen Services auf verschiedenen Systemen und Plattformen. Serviceverzeichnis und Servicebeschreibungen Ein Serviceverzeichnis und Servicebeschreibungen ermöglichen es einem Service- 1 Exakter ist hier der Begriff Workflow, denn er bezeichnet nur die Teilmenge der Geschäftsprozesse, deren Ablauf auch durch IT-Systeme automatisiert werden kann. 16

27 3.1 Geschäftsprozesse und Service-orientierte Architekturen Nutzer, einen bestimmten Service über den Enterprise Service Bus zu lokalisieren und an Informationen über dessen öffentliche Schnittstelle zu gelangen. Abbildung 3.1 zeigt, wie mit den zwei grundlegenden Komponenten Service und Enterprise Service Bus IT-Systeme zur Abbildung verschiedener Geschäftsprozesse strukturiert werden können. Weiterhin zeigt die Abbildung, dass als Konsequenz des Ansatzes kleiner, austauschbarer Komponenten (Tanenbaum und van Steen, 2007, S. 25ff.) ein Service auch in unterschiedlichen Geschäftsprozessen wiederverwendet werden kann 2. Enterprise Service Bus öffentliche Schnittstelle öffentliche Schnittstelle öffentliche Schnittstelle öffentliche Schnittstelle öffentliche Schnittstelle Service A Service B Service C Service D Service E Geschäftsprozess 1: A, B, D Geschäftsprozess 2: B, C, E, A Abbildung 3.1: Schematischer Aufbau einer Service-orientierten Architektur zur Realisierung von zwei Geschäftsprozessen Das Verständnis für die Nutzung eines Serviceverzeichnisses und für die Verwendung von Servicebeschreibungen ergibt sich erst aus der näheren Betrachtung der Interaktionen zwischen Services. Während Abbildung 3.1 eine strukturelle Sicht auf die Realisierung eines vollständigen Geschäftsprozesses enthält, stellt Abbildung 3.2 die Kommunikationsabläufe zwischen zwei Services dar. Dabei wird zwischen zwei unterschiedlichen Rollen unterschieden, die ein Service annehmen kann: dem Anbieter von Funktionalität und dem Nutzer dieser Funktionalität. Jeder Service kann in Abhängigkeit von seiner aktuellen Position im Geschäftsprozess beide Rollen einnehmen. Daher ist auch der Begriff eines Peers üblich. Durch die Fokussierung auf die Konkatenation von Services als Ausdruck einer Strategie anstelle eines konkreten Mechanismus, wird im Vergleich zu anderen Architekturkonzepten ein höheres Abstraktionsniveau erreicht. Konkrete Technologien und Implementationen rücken bei SOA in den Hintergrund, während die Verfügbarkeit der Funktionalitäten von Diensten (Schill und Springer, 2007, S. 20) dominiert. Die neue Abstraktionsebene ermöglicht eine weitgehende Technologieunabhängigkeit, so dass die Gefahr der Abhängigkeit eines Unternehmens von bestimmten Herstellern und deren Produkten (Vendor Lock-In) reduziert wird. Nach der Vorstellung der grundlegenden Komponenten Service-orientierter Architekturen fehlt zur Vervollständigung des Überblicks noch die Beschreibung der Methoden, mit denen einzelne Services zu einem vollständigen Geschäftsprozess verkettet werden 2 Im Beispiel wird Service A und B von beiden Geschäftsprozessen genutzt, so dass die einmal implementierte Funktionalität in verschiedenen Prozessen wiederverwendet werden kann. 17

28 Kapitel 3 Service-orientierte Architekturen für verteilte Systeme Verzeichnis aller Services (optional) (1) Service publizieren (2) Service suchen (3) Verweis auf Service erhalten öffentliche Schnittstelle Service A (Anbieter) (4) Abfrage der Service-Beschreibung (5) Nutzung des Dienstes öffentliche Schnittstelle Service B (Nutzer) Abbildung 3.2: Die Abfolge der Interaktionen zwischen Services (nach Dostal et al., 2005, S. 12) können. Die Komposition von Services wird in SOA durch zwei Mechanismen ermöglicht: Orchestrierung und Choreographie. Durch Orchestrierung werden Services zu einem komplexen Service aggregiert. Die dabei verwendeten Services sind im komplexen Service vollständig gekapselt und nach außen nicht sichtbar. Der neue, komplexe Service erbringt dann eine erweiterte Funktionalität durch die Kombination der enthaltenen Dienste (Schill und Springer (2007), S. 20; Josuttis (2007), S. 298). Im Gegensatz zur Orchestrierung werden die einzelnen Services bei der Choreographie zu einem Ablauf zusammengesetzt. Choreographie setzt dabei auf die Definition von Regeln und Richtlinien für die Zusammenarbeit der Services, um die Bildung eines Geschäftsprozess zu gewährleisten (siehe Schill und Springer (2007), S. 21; Josuttis (2007), S. 294). Services werden damit zu den grobgranularen Bausteine[n] von Softwaresystemen (Schill und Springer, 2007, S. 20), die sowohl für die Realisierung von geschäftlichen Abläufen innerhalb eines Unternehmens, aber auch zwischen Unternehmen verwendet werden können. Dies kann für Unternehmen zu erheblichen Produktivitätssteigerungen und Kosteneinsparungen führen, ist aber auch mit neuen Herausforderungen, insbesondere durch die erhöhte Transparenz und die verteilte Datenhaltung, verbunden. In Abbildung 3.3 ist als abschließendes Beispiel eine unternehmensübergreifende Komposition von Services dargestellt. Dabei wird deutlich, dass der komponierte Service Kundenbestellung abwickeln ein Resultat der Aggregation verschiedener bestehender Services, wie zum Beispiel Auftragsannahme oder Rechnungswesen, ist. Bestehende Funktionalität (zum Beispiel Rechnungswesen ) könnte auch in anderen Service- Kompositionen (zum Beispiel für einen neuen komponierten Service Stornierung eines Kunden bearbeiten ) wiederverwendet werden. Der Aspekt der unternehmensübergreifenden Komposition wird in diesem Beispiel anhand der Services Rechnungswesen und Lagerverwaltung deutlich. Die dargestellte 18

29 3.2 Service-orientierte Architekturen als Middlewarekonzept Service-orientierte Architektur ist nicht auf das Unternehmen X begrenzt, sondern umfasst auch die Services der Bank Y und des Lieferservice Z. Unternehmen X öffentliche Schnittstelle Servicekomposition entsprechend dem zugrunde liegenden Geschäftsprozess: "Kundenbestellung abwickeln" öffentliche Schnittstelle öffentliche Schnittstelle öffentliche Schnittstelle öffentliche Schnittstelle Service Service Service Service "Auftragsannahme" "Kundenverwaltung" "Rechnungswesen" "Lagerverwaltung" öffentliche Schnittstelle Service "Bezahlungsabwicklung" öffentliche Schnittstelle Service "Auftragsannahme" Bank Y Lieferservice Z Abbildung 3.3: Beispiel für eine unternehmensübergreifende Service-orientierte Architektur (nach Schill und Springer, 2007, S. 22) 3.2 Service-orientierte Architekturen als Middlewarekonzept Obwohl das Konzept Service-orientierter Architekturen ursprünglich nur für die Modellierung von IT-unterstützten Geschäftsprozessen entwickelt wurde, hat sich dessen Anwendungsbereich auch auf die Softwareentwicklung ausgedehnt. Gerade die Abstraktion von konkreten Systemen zu generischen Services ermöglicht die Reduzierung der Komplexität von Kommunikationsabläufen und eignet sich damit für die Modellierung verteilter Systeme. Eine verteilte Anwendung lässt sich als Menge von Services modellieren, wobei die Kommunikationsinfrastruktur eines verteilten Systems durch einen Enterprise Service Bus repräsentiert werden kann. Da SOA ein prinzipielles Vorgehen beschreibt, das unabhängig von einer konkreten Anwendung oder einem Anwendungsgebiet ist, kann es auch als Konzept zur Gestaltung einer Middleware für verteilte Systeme verwendet werden 3. Zwei Aspekte Service-ori- 3 Geprägt wurde die begriffliche Nähe zwischen Service-orientierten Architekturen und Middleware-Konzepten bereits 1994 durch Alexander Pasik. Er suchte einen Namen für ein neues Konzept einer Middleware, das er in seinen Vorlesungen vermittelte. Durch die Namensgebung sollte die Prozessorientierung als wesentlicher Unterschied zur gängigen Client-Server-Architektur herausgestellt werden. 19

30 Kapitel 3 Service-orientierte Architekturen für verteilte Systeme entierter Architekturen sind dabei von besonderer Bedeutung: die explizit definierten Schnittstellen und die Abstraktion von den spezifischen Eigenschaften der Hardware. Ihre Relevanz wird durch zwei unterschiedliche Sichten deutlich: die Sicht auf das Gesamtsystem und die Sicht auf die Gestaltung einzelner Services im Gesamtsystem. Sicht auf einzelne Services In Hinblick auf die Entwicklung eines konkreten Services ermöglichen die beiden oben genannten Aspekte eine lose Kopplung zu anderen Services. Dies bedeutet, dass die softwareseitigen Abhängigkeiten zwischen Services des Gesamtsystems gering sind. Die Implementation eines Services kann damit - bei semantischer und syntaktischer Erfüllung der Schnittstelle - nahezu beliebig modifiziert werden, ohne dass diese Änderungen Auswirkungen auf die Nutzung durch andere Services haben. Die Schnittstelle kommt damit einer vertraglichen Regelung der Zusammenarbeit gleich. Die lose Kopplung in Verbindung mit der Abstraktion von spezifischen Eigenschaften der Geräte erübrigt auch die Frage nach dem physischen Träger eines Services oder nach dessen Programmiersprache, denn die konkreten Geräte und Mechanismen treten bei SOA in den Hintergrund. Wichtig ist allein die öffentliche, explizite Beschreibung der Schnittstelle zur Funktionalität. Damit wird eine neue Form der Dynamik im Bereich der Software möglich. Beispielsweise könnten Services bei Fehlern oder Ausfällen nahtlos auf andere Träger migriert werden, ohne dass dies Änderungen in der Ebene der Services bei den Konsumenten notwendig macht. Die benötigten Funktionen können damit auch erst zur Laufzeit in der Umgebung lokalisiert und anschließend genutzt werden. SOA ermöglicht damit die Nutzung von dynamischen Bindungen zur Laufzeit, so dass Anwendungen viel stärker kontextsensitiv agieren können. Sicht auf das Gesamtsystem In der Systemsicht tragen beide Aspekte zu einer wesentlichen Steigerung der Interoperabilität zwischen den beteiligten Geräten bei, denn die Abstraktion zu Services verbirgt die Heterogenität der Geräte weitgehend. Der einzige öffentliche Zugriffspunkt für andere Geräte besteht in der explizit definierten Schnittstelle eines Services, die den Zugang zu den spezifischen Eigenschaften der zugrunde liegenden Geräte unterbindet. Die Interaktionen zwischen Geräten eines verteilten Systems werden damit im Idealfall einzig durch ihre Schnittstellen und die damit verbundenen Kommunikationsprotokolle bestimmt. Dieser Idealfall wird auch als offenes, verteiltes System bezeichnet: Ein offenes verteiltes System ist ein System, das... [Ressourcen] den Standardregeln entsprechend anbietet, die die Syntax und die Semantik dieser Dienste beschreiben. (Tanenbaum und van Steen, 2007, S. 24) 20

31 3.3 Embedded SOA Während Offenheit und Interoperabilität zwar abstrakt bereits den Einsatz von SOA als Middlewarekonzept motivieren, so ist auch der konkrete Einsatz Service-orientierter Architekturen für die Modellierung verteilter Systeme vorteilhaft. In Abbildung 3.3 auf Seite 19 wurde bereits eine unternehmensübergreifende SOA präsentiert. Überträgt man dieses Konzept auf die Entwicklung eines verteilten Systems, so entsteht eine herstellerübergreifende Service-orientierte Architektur. Gerade in Hinblick auf die immer stärker ansteigende Komplexität verteilter Systeme und die gleichzeitig zunehmende Beteiligung verschiedener Parteien am Entwicklungsprozess, wird das Potential der Serviceorientierung deutlich. Es kann davon ausgegangen werden, dass die Struktur eines verteilten Systems zukünftig nicht mehr durch eine klare Systemgrenze sowie durch die Konzeption und Koordinierung eines Herstellers geprägt ist, sondern vielmehr durch Offenheit, Dynamik, und durch die Partizipation verschiedener Hersteller und Nutzer. Gerade für diesen Trend zur Realisierung eines Ökosystems verteilter Systeme sind Service-orientierte Architekturen ein wichtiger Ausgangspunkt. Dies spiegelt sich auch in der folgenden Aussage von A. Ziegler, dem Leiter der Framework Entwicklung bei der compeople AG 4, wider: In einem verteilten System müssen die verteilten Anwendungsbestandteile miteinander interagieren - nur so funktioniert ein großes Ökosystem. Es wird daher ein Mechanismus benötigt, der eine Prozess-übergreifende verteilte Kommunikation ermöglicht. (Ziegler, 2007, Absatz 1) 3.3 Embedded SOA Embedded SOA ist ein spezielles Anwendungsgebiet Service-orientierter Architekturen. Es bezeichnet den Versuch, SOA auch im Bereich der Softwareentwicklung für verteilte, eingebettete Systeme einzusetzen. Damit werden eingebettete Geräte mit eingeschränkten Ressourcen zu den physischen Trägern von Services. Dabei wird das abstrakte Konzept des Enterprise Service Bus auf konkreten Kommunikationstechnologien aus dem Netzwerkbereich abgebildet. Services bleiben damit nicht länger nur ein virtuelles Design-Paradigma ohne physische Entität. Sie sind stattdessen über ihre eingebetteten Geräte als Träger auch physisch in ihrer Umgebung präsent. Embedded SOA beschreibt damit Mechanismen, die zur Realisierung der Kommunikation zwischen autonomen Geräten beitragen (= Maschine-zu-Maschine Kommunikation) und stellt einen besonderen Kompromiss für das bereits in Kapitel 2.3, Softwarearchitektur für verteilte, eingebettete Systeme, beschriebene Dilemma dar. Einerseits soll Embedded SOA durch die Einführung einer weiteren Abstraktionsebene die Entwicklung komplexer und dynamischer Anwendungen ermöglichen, die weitgehend unabhängig von ihrem Träger sind und gleichzeitig auch die Entwicklung in Hochsprachen erlauben. Andererseits bezieht sich Embedded SOA explizit auf eingebettete 4 Die compeople AG ist ein führender IT-Dienstleister, der sich auf die Entwicklung verteilter Anwendungen auf der Basis einer herstellerunabhängigen, generischen Softwareplattform (OSGi) spezialisiert hat. 21

32 Kapitel 3 Service-orientierte Architekturen für verteilte Systeme Geräte mit eingeschränkten Ressourcen, die den Einsatz hochkomplexer Softwaresysteme mit vielen Abstraktionsebenen limitieren. Der Fokus von Embedded SOA liegt damit auf der Herausforderung, ein hohes Maß an Abstraktion und Dynamik auf einer Plattform mit eingeschränkten Ressourcen zu realisieren. Einsatzgebiete für verteilte Anwendungen auf Basis von Embedded SOA sehen Barisic et al. im Industriebereich sowie bei der Haus- und Heimautomatisierung (siehe Barisic et al., 2007, S. 1ff). Während im Privatbereich die Homogenisierung der verschiedenen Geräte ein großes Potential für neue, innovative Formen der Nutzung und Vernetzung besitzt, ist es im Industriebereich die nahtlose Integration von Fertigungsanlagen in bestehende Geschäftsprozesse des Unternehmens, die das Interesse an Embedded SOA begründet. Durch Embedded SOA kann auch die Reichweite etablierter Optimierungsverfahren für Geschäftsprozesse, zum Beispiel mittels Business Process Reengineering, auf Fertigungsanlagen und Fertigungsprozesse ausgedehnt werden, um agil und effizient auf neue Anforderungen reagieren zu können. Neben den beschriebenen Anwendungsgebieten profitiert auch der Entwicklungsprozess von Software für eingebettete Systeme von der höheren Abstraktion der Serviceorientierung (siehe Kapitel 2.3, Softwarearchitektur für verteilte, eingebettete Systeme ). So kann der Entwicklungsaufwand durch die Nutzung bereits existierender Werkzeuge, wie zum Beispiel automatischer Code-Generatoren einer bestehenden SOA Infrastruktur, weiter verringert werden. Obwohl der Einsatz Service-orientierter Architekturen - gerade auf eingebetteten Systemen - viele Vorteile bringt, muss aufgrund der bisher geringen Marktpenetration verteilter Anwendungen auf Basis von Embedded SOA davon ausgegangen werden, dass diese Vorteile die verringerte Effizienz noch nicht kompensieren konnten. Es bleibt daher weiterhin eine wichtige Aufgabe des Forschungsbereiches Embedded SOA, Service-orientierte Middleware-Technologien zu entwickeln, die neben der Orientierung am SOA-Paradigma, auch noch stärker die Beschränkungen eingebetteter Systeme und die Performance des Gesamtsystems in die Konzeption integrieren. 3.4 SOA, quo vadis? In Ermangelung aktueller Studien über den bisherigen Erfolg Service-orientierter Architekturen bei der prozessorientierten (Um-) Gestaltung von Enterprise-IT-Systemen, werden Veröffentlichungen in der Blogosphäre 5 verwendet, um einen groben Indikator für die aktuelle Stimmung und die Erwartungen für die zukünftigen Entwicklungen in diesem Bereich zu erhalten. So wird aus den Aussagen von Senior-Level Beratern des IT-Beratungsunternehmens Burton Group, sowie aus Pressemitteilungen der Nachrichtenagentur InfoWorld deutlich, dass die Versprechen von besseren und günstigeren IT-Systemen durch eine Modellierung nach dem SOA-Paradigma bisher selten eingelöst werden konnten (Manes, 5 Die Blogosphäre bezeichnet das soziale Netzwerk der verschiedenen Weblogs (Blogs), die zu bestimmten Themen von Privatpersonen und Mitarbeitern von Firmen geführt werden. 22

33 3.5 Fazit 2009, Absatz 2). Gleichzeitig sei auch die Quote fehlgeschlagener oder stark verzögerter SOA-Projekte vergleichsweise hoch (ebda.). Krill gibt dazu die Aussage der IBM Vizepräsidentin für die SOA und WebSphere Strategie Sandy Carter wider, in der sie bestätigt, dass die Ausgaben für neue SOA-basierte IT-Systeme von den Firmen reduziert werden (Krill, 2009). Zum gleichen Thema zitiert Krill auch den HP SOA Product Marketing Manager Kelly Emo, der bekräftigt, dass die Finanzierung von SOA-Technologien ohne unmittelbaren Business-Nutzen in 2009 schwieriger sein werde als im Vorjahreszeitraum (ebda.). Als wesentliche Ursache für dieses Ergebnis wird die Begriffsunschärfe Service-orientierter Architekturen gesehen. Sie soll dazu geführt haben, dass der Begriff zur Steigerung der Vermarktung neuer SOA-basierter Anwendungen zu stark aufgeladen (Krill, 2009) wurde, um die Erwartungen erfüllen zu können. Vor dem Hintergrund der aktuellen Wirtschaftskrise und den damit vermutlich weiter sinkenden Ausgaben für neue SOA-Projekte, wird auch bereits vom Tod Service-orientierter Architekturen (Keene, 2009) gesprochen. Vereinzelt wird sogar von der Verwendung des Terms SOA abgeraten, da das negative Image Service-orientierter Architekturen die Vermarktung der darauf aufbauenden Anwendung negativ beeinflussen könne. Im Gegensatz zur sinkenden Durchsetzungsfähigkeit Service-orientierter Architekturen bei der Modellierung von Geschäftsprozessen in großen Unternehmen, werden die Entwicklungschancen der technologischen Erben von SOA, wie beispielsweise Web Services, Cloud Computing oder Software as a Service, positiv eingeschätzt (Foody (2009); Spies (2009); Manes (2009)). Serviceorientierung wird nun vor allem als konkrete Service-basierte Technologie und nicht als komplexes Architekturkonzept aufgenommen und auf dieser Grundlage erfolgreich vermarktet. Deutlich wird dies durch Aussagen wie SOA is Dead; Long Live Services (Manes, 2009). Die Frage nach der Zukunft von Embedded SOA wird in der SOA-spezifischen Blogosphäre nicht weitergehend thematisiert. Da Embedded SOA aber ebenfalls in die Kategorie der als erfolgreich proklamierten SOA-Erben (wie Web Services, Cloud Computing, Software as a Service, Plattform as a Service,... ) fällt, kann davon ausgegangen werden, dass dessen Bedeutung in der Zukunft ebenfalls weiter steigen wird. Für diese Perspektive spricht auch die Tatsache, dass das Konzept Embedded SOA im Gegensatz zu SOA nicht unmittelbar mit dem großen Aufwand der Umgestaltung von Geschäftsprozessen verbunden ist, sondern als konkrete Technologie verständlich und nachvollziehbar vermarktet werden kann. Diese konkrete Anwendbarkeit spiegelt sich auch in den greifbaren Anwendungsgebieten (Industriebereich, sowie Haus- und Heimautomatisierung) wider und unterstreicht damit noch einmal die Notwendigkeit für eine weiterführende, anwendungsorientierte Forschung in diesem Bereich. 3.5 Fazit Geschäftsprozesse bezeichnen die grundlegenden Abläufe eines Unternehmens zur Realisierung von dessen Geschäftstätigkeit. Sie bilden auch die Grundlage des Architekturparadigmas Service-orientierter Architekturen, das ursprünglich für die Modellie- 23

34 Kapitel 3 Service-orientierte Architekturen für verteilte Systeme rung und Strukturierung von IT-Systemen entwickelt wurde. Der grundlegende Ansatz Service-orientierter Architekturen besteht in der Trennung von Strategie und Mechanismus. Dieser Ansatz führt zu einer Systemkomposition aus kleinen, austauschbaren Komponenten und soll den Unternehmen eine weitgehende Unabhängigkeit von konkreten Technologien ermöglichen. SOA wird häufig in der Erwartung eingesetzt, die Kosten der IT-Systeme zu reduzieren und gleichzeitig agil auf geänderte Rahmenbedingungen reagieren zu können. Die wesentlichen Bestandteile einer Service-orientierten Architektur sind Services mit einem öffentlichen Teil - der Schnittstelle - und einem nicht-öffentlichen Teil, der die Implementierung der Funktionalität enthält. Ein weiterer Bestandteil einer Serviceorientierten Architektur ist der Enterprise Service Bus. Er repräsentiert die Vernetzung von Services. Optional können auch Servicebeschreibungen innerhalb eines zentralen Serviceverzeichnisses in eine Service-orientierte Architektur integriert werden. Außerhalb des Kontextes der Geschäftsprozessmodellierung wird SOA aufgrund seiner Eigenschaften auch als konkretes Technologiekonzept zur Gestaltung einer Middleware für verteilte Systeme eingesetzt. Dabei wird durch die expliziten Schnittstellen der Services und durch die Abstraktion von den konkreten Eigenschaften der Geräte zu generischen Funktionen eine lose Kopplung und eine verbesserte Interoperabilität der Softwarekomponenten eines verteilten Systems erreicht. Dies erlaubt die Gestaltung offener, verteilter Systeme. Embedded SOA führt diesen Middleware-Ansatz weiter und bindet Services an eingebettete Geräte als physische Träger, so dass Interaktionen zwischen Services auch als Abstraktion der Kommunikationsabläufe zwischen Maschinen dargestellt werden können. Embedded SOA repräsentiert damit ein offenes, verteiltes System zur Abbildung der Maschine-zu-Maschine Kommunikation von Geräten mit eingeschränkten Ressourcen. Charakteristisch für dieses verteilte, eingebettete System ist die hohe Dynamik zur Laufzeit und die lose Kopplung zwischen den Softwarekomponenten. Der bereits in Kapitel 2.3, Softwarearchitektur für verteilte, eingebettete Systeme, angedeutete Zielkonflikt zwischen dem Streben nach einer hohen Abstraktion bei gleichzeitiger Beschränkung der verfügbaren Ressourcen wird bei Embedded SOA besonders deutlich. Ein sinnvoller Kompromiss für dieses Dilemma kann zu neuen und innovativen Anwendungen im Industriebereich sowie bei der Haus- und Heimautomatisierung führen. Trotz der hohen Herausforderungen wird Embedded SOA bereits heute ein großes Innovationspotential zugesprochen. Dieses Potential und der angedeutete, inhärente Zielkonflikt begründen sowohl die Relevanz, als auch die Motivation für eine weiterführende Forschung in diesem Bereich. 24

35 Kapitel 4 Umsetzung Service-orientierter Architekturen mit Web Services Nach der Vorstellung des Architekturparadigmas der Service-orientierten Architekturen zur Modellierung verteilter Systeme, geht dieses Kapitel der Frage nach, wie dieses Paradigma in Form einer Middleware eines verteilten Systems effizient implementiert werden kann. Dazu werden zunächst Web Services als de-facto Standard-Implementierung von Service-orientierten Architekturen vorgestellt. Im Anschluss wird das Devices Profile for Web Services als Teilmenge der umfangreichen Web Service Architektur eingeführt. Dieses Profil verspricht eine effiziente Implementierung einer Middleware für ein verteiltes, eingebettetes System. Das Devices Profile for Web Services ist auch der zentrale Untersuchungsgegenstand der vorliegenden Arbeit. Dessen Aufbau und Funktionsweise bildet die Grundlage für die im Rahmen dieser Arbeit durchgeführten Experimente. Softwarearchitektur für verteilte Systeme Modellierung von Geschäftsprozessen ist konfrontiert mit Paradigmen ist Anwendung für Implementierungsstandards Hohe Komplexität erfordert konzipieren eine Service-orientierte Architekturen (SOA) ist eine spezielle implementieren Web Services Ist Teilmenge von Abstraktion & Flexibilität teilweise realisiert mit ist Konzept einer Middleware für Embedded SOA implementiert Devices Profile for Web Services Middleware beschränken beschränken eingebettete Systeme Visionen 25

36 Kapitel 4 Umsetzung Service-orientierter Architekturen mit Web Services 4.1 Einführung in die Technologie der Web Services Web Services ist die Bezeichnung für eine Middleware-Technologie zur Umsetzung verteilter Anwendung, die sich am Paradigma Service-orientierter Architekturen orientieren. Vergleichbar mit der begrifflichen Unschärfe des Terms Service-orientierter Architekturen, gibt es auch für Web Services viele Definitionen mit einem unterschiedlichen Fokus. Eine sehr allgemeine Definition ist die folgende: Ein Web Service ist eine über ein Netzwerk zugängliche Schnittstelle zu Anwendungsfunktionen, die mit Hilfe von Standardtechniken des Internets realisiert wird. (Snell, Tidwell und Kulchenko, 2002, S. 1) Sie definiert Web Services als Vereinigung des Entwurfsparadigmas Service-orientierter Architekturen mit der Technologiemenge des World Wide Web. Damit genügt sie als knappe Einführung, benennt aber nicht die charakteristischen Eigenschaften. Die kanonische Definition vom World Wide Web Consortium (W3C) ist spezifischer und benennt auch bereits konkrete Technologien. Sie wird als Grundlage für diese Arbeit verwendet: Ein Web Service ist ein Software System, das dazu entwickelt wurde, die interoperable Maschine-zu-Maschine Interaktion über ein Netzwerk zu unterstützen. [...] Ein Service besitzt eine Schnittstelle, die in einem maschinenlesbaren Format (WSDL) beschrieben ist. [...] Andere Systeme interagieren mit einem Web Service in einer durch die Beschreibung vorgeschriebene Art und Weise und verwenden dazu SOAP- Nachrichten, die meist mittels HTTP und XML-Serialisierung, sowie in Verbindung mit weiteren Web Standards übermittelt werden. (siehe Original unter W3C Working Group, 2004b) In der Praxis wird ein Web Service bisher häufig eingesetzt, um eine sprach- und plattformunabhängige Kommunikation für den Zugriff auf eine Anwendung zu realisieren. Ein Web Service übernimmt dabei die Rolle einer generischen Schnittstelle, deren Benutzung Anwendern auf unterschiedlichen Plattformen ermöglicht wird. In Abbildung 4.1 ist dieses Szenario dargestellt. Die Effekte der Maschine-zu-Maschine Kommunikation (siehe Kapitel 3.3, Embedded SOA ) werden in der Abbildung durch die Notwendigkeit eines Agents deutlich, der es dem Nutzer ermöglicht, über den Web Service mit der Anwendung zu interagieren. Eine Agent-Software ist notwendig, um es einem menschlichen Nutzer zu ermöglichen, auf der Ebene der Services zu agieren, ohne die komplexen Vorgänge für eine Interaktion manuell durchführen zu müssen. An dieser Stelle wird das zugrunde liegende SOA- Paradigma durchbrochen, da nicht nur Services miteinander kommunizieren, sondern der Agent als Mittler beteiligt ist. Er ist kein originärer Bestandteil einer Service-orientierten Architektur, sondern viel mehr ein externes Hilfsmittel und Stellvertreter für menschliche Nutzer. 26

37 4.2 Die grundlegenden Konzepte von Web Services Plattform- und sprachspezfische Kommunikation öffentliche Schnittstelle Plattform- und sprachunabhängige Kommunikation Agent Web Service Anwendung Anbieter Nutzer Abbildung 4.1: Web Services als Schnittstelle zu Anwendungen (nach Snell, Tidwell und Kulchenko, 2002, S. 2) Die eigentliche Kommunikation zwischen verschiedenen Web Services und Agents erfolgt durch den Austausch von Nachrichten in einem festgelegten Format. Web Services werden daher auch als Nachrichten-orientierte Middleware charakterisiert (Dostal et al., 2005, S. 21). 4.2 Die grundlegenden Konzepte von Web Services Web Services basieren auf verschiedenen, grundlegenden Komponenten, die jeweils durch öffentlich verfügbare Standards spezifiziert sind. Bei diesen Komponenten handelt es sich um die Extensible Markup Language (XML), die Web Service Description Language (WSDL), das Simple Object Access Protocol (SOAP) sowie Universal Description, Discovery and Integration (UDDI). Dabei ist nur die Verwendung von XML und WSDL für die Erstellung eines Web Services zwingend vorgeschrieben. SOAP und UDDI bezeichnen dagegen nur häufig verwendete Standards, die auch durch andere Protokolle ersetzt werden dürfen (Josuttis, 2007, S. 211). In Anlehnung an Abbildung 3.2 enthält Abbildung 4.2 zusätzlich zu den kanonischen Abläufen der Kommunikation zwischen Web Services auch die Zuordnung der entsprechenden Web Service Komponenten, die die jeweilige Interaktion realisieren. In den folgenden Unterabschnitten werden die vier Basiskomponenten von Web Services (SOAP, XML, WSDL und UDDI) kurz beschrieben Das maschinenlesbare Textformat XML Die Extensible Markup Language (XML) bezeichnet ein maschinenlesbares Textformat zur Kodierung von Daten. Dabei werden die Rohdaten durch Metainformationen, die ihre Syntax, Struktur und Semantik beschreiben, ergänzt (Schmelzer und VanDersypen, 2002, S. 9). Abbildung 4.3 auf Seite 28 enthält ein Beispiel für die Darstellung der Rohdaten eines Einfamilienhauses zusammen mit den entsprechenden Metainformationen in einem XML-Dokument. 27

38 Kapitel 4 Umsetzung Service-orientierter Architekturen mit Web Services Verzeichnis aller Services (optional) (2) Service suchen (1) Service publizieren WSDL XML (3) Verweis auf Service erhalten WSDL XML SOAP XML öffentliche Schnittstelle Service A (Anbieter) (4) Abfrage der Service-Beschreibung SOAP XML (5) Nutzung des Dienstes öffentliche Schnittstelle Service B (Nutzer bzw. Agent) Abbildung 4.2: Interaktionen zwischen Web Services (nach Dostal et al., 2005, S. 28) <?xml version="1.0" encoding="utf-8"?> <haus> <typ>einfamilienhaus</typ> <hersteller>kampa</hersteller> <preis>234800</preis> <farbe>orange</farbe> <adresse> <strasse>hauptstraße 1</strasse> <ort>berlin</ort> <plz>10321</plz> </adresse> <notizen>dies ist ein Einfamilienhaus der Familie Müller </notizen> </haus> Reales Objekt Mögliche Darstellung in XML Abbildung 4.3: Beispiel für die Abbildung der Rohdaten eines Einfamilienhauses in einem XML-Dokument 28

39 4.2 Die grundlegenden Konzepte von Web Services Zwischen dem Datenaustausch in Textform ohne explizite Struktur und den für den Menschen schwer lesbaren Binärformaten, nimmt XML eine Zwischenposition ein. Die besondere Art der strukturierten Speicherung in Textform ermöglicht einerseits die Lesbarkeit der Daten für den Menschen und erleichtert andererseits das maschinelle Auslesen. Diese Eigenschaft ist für die Realisierung der Maschine-zu-Maschine Kommunikation von großer Bedeutung. Neben der Speicherung von Metainformationen, bietet XML auch weitere Vorteile. Durch die explizite Spezifikation der Struktur der XML-Daten kann deren syntaktische Gültigkeit automatisch überprüft werden. Die explizite Strukturspezifikation wird dabei durch frei definierbare Document Type Definitions (DTDs) oder XML Schema Definitionen (XSD) realisiert. Sie erlauben die spätere Validierung eines XML-Dokumentes (siehe dazu auch Abbildung 4.4). Damit kann die Anordnung, das Format und die Anzahl der Einträge innerhalb eines XML-Dokumentes genau festgelegt und anschließend überprüft werden, so dass Fehler bei der Datenübertragung frühzeitig erkannt werden. XML Schema oder DTD XML Daten Das XML Dokument entspricht den Strukturrichtlinien: Ja / Nein XML Validator Abbildung 4.4: Validierung von XML Dokumenten XML enthält neben den Roh- und Metadaten auch die notwendigen Angaben zur korrekten Interpretation dieser Daten und stellt diese explizit zur Verfügung. Beispielsweise wird in der ersten Zeile in Abbildung 4.3 die Kodierung des XML-Dokumentes explizit auf Unicode (encoding= UTF-8 ) gesetzt. Ein Empfänger benötigt durch diese Angabe kein weiteres Vorwissen zum korrekten Einlesen der Daten Beschreibung von Services mit WSDL Die Web Service Description Language (WSDL) ist eine Sprache im XML-Format zur maschinenlesbaren Beschreibung der öffentlichen Schnittstelle eines Web Services. Aufgrund der zentralen Rolle der öffentlichen Schnittstelle in einer Service-orientierten Architektur, bildet WSDL das Rückgrat eines verteilten Systems. Allerdings beschränkt sich WSDL nur auf die Beschreibung der Struktur der gültigen Nachrichten, die die öffentliche Web Service Schnittstelle verarbeiten kann. Bei der Spezifikation einer Schnittstelle durch WSDL wird zwischen einer abstrakten und einer konkreten Beschreibung unterschieden (Dostal et al. (2005), S. 78; W3C 29

40 Kapitel 4 Umsetzung Service-orientierter Architekturen mit Web Services Working Group (2004a)). Während bei der abstrakten Beschreibung ein Modell der Funktionalität des Services gebildet wird, widmet sich die konkrete Beschreibung den technischen Details, die definieren wie der Dienst konkret angeboten wird. Die Trennung der generischen Funktionalität von den spezifischen Anschlusseigenschaften erlaubt die einfache Wiederverwendung der generischen Funktionsmodelle in anderen, gleichartigen Web Services. Eine vollständige WSDL-Beschreibung der Schnittstelle eines Web Services besteht damit aus der Definition der Funktionalität und der notwendigen Angaben für den Zugriff. Die Semantik eines Web Services kann bisher nicht mit WSDL beschrieben werden (Dostal et al., 2005, S. 78). Für die explizite Definition der gültigen Nachrichten einer Schnittstelle ist primär die Festlegung von Datenstrukturen und Datentypen erforderlich. Um dabei eine möglichst große Flexibilität zu erreichen, wurde durch die Verwendung von XML Schema Definitionen die Möglichkeit geschaffen, nahezu beliebige Datentypen zu definieren und diese gleichzeitig auch automatisch validieren zu können. In der Praxis wird das WSDL-Schnittstellenbeschreibung zusammen mit dem darin beschriebenen Web Services angeboten. Der Nutzer kann dieses Dokument nutzen, um daraus automatisch Quellcode für den Zugriff mit einem Agent oder aus einem Web Service heraus zu generieren. Gerade die Möglichkeit Code-Generatoren zu verwenden und damit die Nutzung von Web Services zu vereinfachen, ist eine direkte Folge der Verwendung von XML als maschinenlesbare Sprache zur Beschreibung der Service- Schnittstelle Austausch von Nachrichten mit SOAP SOAP 1 bezeichnet ein standardisiertes Verpackungsprotokoll für Nachrichten, die zwischen Web Services ausgetauscht werden. Gleichzeitig ist auch die Beschreibung der Einbettung dieser Daten in ein Transportprotokoll 2 ist Bestandteil von SOAP (Snell, Tidwell und Kulchenko (2002), S. 13; Dostal et al. (2005), S. 27). Der Begriff einer Nachricht ist weit gefasst und kann eine Ereignismeldung eines Gerätes, eine Suchanfrage oder ganz allgemein einen Aufruf eines Services darstellen. Zur Unterstützung dieser vielfältigen Nachrichtentypen spezifiziert SOAP nur die folgenden drei Aspekte einer Nachricht: 1. Eine SOAP-Nachricht muss aus einem Envelope (Briefumschlag) bestehen, der einen optionalen Header (Kopf) und einen zwingend erforderlichen Body (Körper) enthält. Der Header beinhaltet Informationen, die die Verarbeitung der Nachricht betreffen (Adressierungs- und Routinginformationen). Der Body enthält die eigentliche Nachricht (siehe Abbildung 4.5). 2. Eine SOAP Nachricht muss in XML kodiert werden und automatisch validierbar sein. 1 SOAP steht ursprünglich für Simple Object Access Protocol, mittlerweile wird allerdings nur noch die Abkürzung verwendet. 2 Ein Transportprotokoll spezifiziert die Übertragung von Daten über ein Netzwerk. Ein Beispiel für ein populäres Transportprotokoll ist das Hyper Text Transfer Protocol (HTTP). 30

41 4.2 Die grundlegenden Konzepte von Web Services 3. Die Umwandlung von anwendungs- und plattformspezifischen Datentypen in XML erfolgt durch einen in SOAP spezifizierten Regelsatz. SOAP Envelope SOAP Header <?xml version="1.0"?> <s:envelope xmlns:s=" <s:header> </s:header> <s:body> SOAP Body </s:body> </s:envelope> Abbildung 4.5: SOAP Nachrichtenformat in abstrakter (links) und konkreter Form (rechts) SOAP-Nachrichten werden hauptsächlich in zwei unterschiedlichen Anwendungsbereichen verwendet: Remote Procedure Calls (entfernte Methodenrufe) und Electronic Document Interchange (Elektronischer Austausch von Dokumenten) Remote Procedure Calls (RPC) werden für das Aufrufen von Funktionen innerhalb eines verteilten Systems verwendet. Eine SOAP-RPC-Nachricht realisiert den Aufruf einer Methode auf einem anderem Gerät des verteilten Systems und enthält dazu die entsprechenden Parameter und Rückgabewerte im XML-Format. Es werden die folgenden Nachrichtentypen unterschieden (Dostal et al., 2005, S. 57): Request - eine entfernte Methode wird durch den Nutzer aufgerufen und die benötigten Parameter werden übergeben Response - das Ergebnis einer Anfrage wird an den Anfragenden zurückgeschickt Fault - der Anfragende wird über den Auftritt eines Fehlers informiert Der Anwendungsbereich des Electronic Document Interchange (EDI) umfasst die Realisierung geschäftlicher Transaktionen durch den Austausch von Dokumenten auf Basis von SOAP. EDI wird daher auch als Dokumenten-basiertes SOAP bezeichnet. Bei der vorliegenden Arbeit steht die Verwendung von SOAP-Nachrichten als Remote Procedure Call im Vordergrund, so dass auf eine weiterführende Einführung des Electronic Document Interchange verzichtet wird. Der SOAP-Standard legt nicht fest, welches Protokoll zur Übertragung der Nachrichten verwendet werden muss. Dies erlaubt die Auswahl eines geeigneten Transportprotokolls, das den Anforderungen der vorliegenden Umgebungssitutation am Besten gerecht wird. Neben dem häufig eingesetzten Transportprotokoll HTTP können alternativ auch SMTP, FTP oder RMI zur Übertragung einer SOAP-Nachricht verwendet werden. 31

42 Kapitel 4 Umsetzung Service-orientierter Architekturen mit Web Services Neben der Festlegung des Transportprotokolls muss auch der Standort definiert werden unter der ein Web Service erreicht werden kann. Diese Angaben bestehen neben den Adressierungsinformationen der SOAP-Schicht 3 auch aus den spezifischen Adressen des verwendeten Transportprotokolls 4. Obwohl beide Angaben für eine vollständige Beschreibung des Standortes 5 notwendig sind, spezifizierte SOAP ursprünglich nur die Einbettung von SOAP-Adressen in SOAP-Nachrichten. Erst spätere SOAP- Erweiterungen, wie zum Beispiel WS-Addressing, standardisieren die Einbettung einer vollständigen Adresse eines Services in einer SOAP-Nachricht und ermöglichen damit auch den Austausch von Adressierungsinformationen zwischen Web Services Ein zentrales Serviceverzeichnis mit UDDI Die Universal Description, Discovery and Integration (UDDI) Komponente wurde eingeführt, um die Analogie eines Marktplatzes mit den Rollen eines Anbieters, eines Konsumenten und eines Maklers in der Welt der Web Services zu realisieren. Durch UDDI sollte ein weltweites Verzeichnis für Web Services eingeführt werden, wobei UDDI dabei als Protokoll für die Registrierung und Suche innerhalb dieses Verzeichnisses vorgesehen war. Bedingt durch Schwierigkeiten bei der inhaltlichen Kategorisierung der verschiedenen Web Services und durch die fehlende Unterstützung der Authentifizierung von Einträgen (Snell, Tidwell und Kulchenko, 2002, S. 179), rückte UDDI immer mehr in den Hintergrund. Mittlerweile kann davon ausgegangen werden, dass UDDI das ursprüngliche Ziel, die zentrale Komponente zur Verwaltung eines globalen Web Service Marktplatzes zu werden, verfehlt hat. Zum Teil läßt sich die geringe Durchsetzung von UDDI gegenüber anderen Technologien durch die Tatsache erklären, dass anstelle der Einführung eines neuen, zentralen UDDI-Verzeichnisses oft bereits vorhandene Verzeichnisse (LDAP, JNDI,... ) für die Verwendung durch Web Services proprietär erweitert wurden (siehe Newcomer und Lomow, 2004). Mittlerweile existieren verschiedene Versionen von UDDI, die sich teilweise mit den neuen Web Service Standards aus dem WS-* Framework überschneiden. Ob sich UDDI in Zukunft zumindest gegen die neuen Standards, wie beispielsweise WS-Discovery (siehe Kapitel 4.5, Web Services auf eingebetteten Geräten ), behaupten kann, ist zum aktuellen Zeitpunkt nicht abzusehen. 4.3 Kritikpunkte von Web Services Web Services ist eine junge Middleware-Technologie, die von vielen Parteien stetig weiterentwickelt wird, um weiterhin den Standard für die Implementierung von Service-orientierten Architekturen zu setzen. Obwohl der aktuelle Entwicklungsstand viel 3 Eine Adresse der SOAP-Schicht als Beispiel: urn:uuid:c2f b3-11d1-a29f-00aa00c Eine Adresse des Transportprotokolls HTTP als Beispiel: 5 Eine vollständige Adresse kann damit wie folgt lauten: 32

43 4.3 Kritikpunkte von Web Services versprechend ist, ist die Nutzung von Web Services mit einer Reihe von Herausforderungen verbunden, die eine breite Durchsetzung dieser Technologie verhindern. Die folgenden Absätze geben einen kurzen Überblick über wesentlichen Hindernisse. Vielfalt der Standards Die gesamte Web Service Architektur kann auf eine umfangreiche theoretische Fundierung zurückgreifen, die sich in mehr als 100 Spezifikationen niederschlägt. Sie werden durch verschiedene Standardisierungsgremien, wie das W3C, OASIS und Web Services Interoperability Organization (WS-I) betreut. Während die Anzahl der Spezifikationen bereits zu Unübersichtlichkeit und Unsicherheit bei Entwicklern und Unternehmern führt, wird diese Situation durch Überlappungen und Widersprüche zwischen einzelnen Spezifikationen noch verstärkt. Auch die überlappenden Verantwortungsbereiche der beteiligten Standardisierungsgremien erschweren die Erstellung konsistenter Web Service Standards zusätzlich. Erhöhter Ressourcenbedarf durch die Verwendung von XML Ein großer Nachteil bei der Verwendung von XML liegt in der Nutzung des Textformates zur Kodierung der Daten. Im Vergleich zu Binärformaten oder zu einfacheren Textformaten ohne Metadaten, beansprucht XML wesentlich mehr Speicherplatz. XML-Dokumente können in der Praxis drei bis zwanzig Mal größer ausfallen, als vergleichbare Binärformate (Schmelzer und VanDersypen, 2002, S. 26). Dies verbietet den Einsatz von XML (und damit auch Web Services) in bestimmten Szenarien, falls die verfügbaren Ressourcen zur Verarbeitung dieser zusätzlichen Datenmenge nicht ausreichend sind. Optionale Bestandteile der Implementierungen von SOAP Für den SOAP-Standard gibt es verschiedene Implementierungen von unterschiedlichen Herstellern. Ein Hindernis liegt daher in der unterschiedlichen Auslegung des SOAP- Standards durch die Hersteller. Ist eine bestimmte Eigenschaft im Standard mit dem Schlüsselwort may versehen, dann ist ihre Implementierung optional. Ein Hersteller hat dann die Wahl, ob er diese Funktion in seine SOAP-Implementierung aufnimmt oder nicht. Durch diese unterschiedliche Mächtigkeit der Implementierungen können in der Praxis Probleme bei der Interoperabilität auftreten (siehe dazu auch Schmelzer und VanDersypen, 2002, S. 666ff.). Defizite von WSDL WSDL-Dateien enthalten viele Informationen über die Schnittstelle eines Web Services. Allerdings bieten sie keine vollständige Dokumentation eines Web Services, da es keine Möglichkeit gibt, dessen Semantik innerhalb von WSDL abzubilden. Dies ist 33

44 Kapitel 4 Umsetzung Service-orientierter Architekturen mit Web Services jedoch für den Aufbau eines zentralen Verzeichnisdienstes essentiell, um auch die Auswahl semantisch äquivalenter Dienste zu ermöglichen. Neben den fehlenden semantischen Informationen, können auch nicht-funktionale Attribute und Eigenschaften, wie beispielsweise Service Level Agreements, nicht in WSDL-Beschreibungen integriert werden. Eine WSDL-Datei kann beispielsweise keine Preisinformationen oder Informationen über die maximale Zeitdauer der Ausführung einer Methode enthalten. Es ist unklar, ob WSDL trotz der starken Beschränkung auf die funktionalen Aspekte eines Web Services weiterhin eine zentrale Komponente innerhalb von Web Services bleiben wird. Eventuell können neue Forschungsergebnisse aus dem Bereich Semantik Web für eine Erweiterung der Mächtigkeit von WSDL genutzt werden. Mit den Semantic Annotations for WSDL 6 wurde ein erster Schritt getan, um die beschriebenen Beschränkungen teilweise aufzuheben und eine semantische Klassifizierung von Web Services zu ermöglichen. 4.4 Dynamische Anwendungen auf der Basis von dynamischer Integration Bereits in Kapitel 2.1, Was sind eingebettete Systeme?, wurde das Verhältnis der dynamischen Entscheidungen zur Laufzeit und der statischen Logik zur Entwicklungszeit als eine der wesentlichen Entscheidungen beim Softwareentwurf erstmalig angesprochen. Im Kapitel 3.2, Service-orientierte Architekturen als Middlewarekonzept, wurden diese Erkenntnisse erweitert, in dem das Streben nach einer losen Kopplung zwischen Softwarekomponenten eines verteilten Systems als wichtige Voraussetzung zur Realisierung von dynamischen, kontextsensitiven Anwendungen auf der Basis des SOA-Paradigmas vorgestellt wurde. Da die bereits eingeführten Web Services eine weit verbreitete SOA-Implementierung darstellen, geht dieser Abschnitt der Frage nach, welcher Grad an Dynamik und loser Kopplung durch Web Services realisiert werden kann. Der Grad an Dynamik eines Web Services wird in dieser Arbeit dazu verwendet, die Menge an ex-ante Informationen (= Vorab-Informationen) zu charakterisieren, die ein Service-Nutzer über einen Service-Anbieter vor einer Interaktion besitzen muss. Je weniger ex-ante Informationen benötigt werden, um eine Interaktion zu realisieren, umso dynamischer ist die Anwendung. Je weniger ex-ante Informationen auf Seiten des Service-Nutzers vorliegen, umso mehr Angaben muss dieser allerdings zur Laufzeit bestimmen. Die Flexibilität dynamischer Anwendungen ist daher im Vergleich zu statischen Anwendungen mit einer geringeren Performance verbunden. Durch die Nutzung von XML sind bereits alle notwendigen Angaben zur korrekten Interpretation der Daten in den Daten selbst enthalten, so dass dafür keine weiteren Informationen notwendig sind. Bei Web Services sind damit nur die folgenden ex-ante Informationen für eine Interaktion erforderlich: 6 Mehr Informationen gibt es unter: 34

45 4.4 Dynamische Anwendungen auf der Basis von dynamischer Integration Service Typ Ist der Typ eines Services bekannt, so dass unter Angabe dieses Typen in einem Serviceverzeichnis nach aktiven Services gesucht werden kann? Service Schnittstelle Ist die Schnittstelle eines Services bekannt? Service Standort Ist der Standort eines Services im Netzwerk oder muss dieser erst lokalisiert werden? Falls alle aufgeführten Angaben dem Service-Nutzer vor einer Interaktion bekannt sind, wird die Anwendung in dieser Arbeit auch als statische Anwendung bezeichnet, da keine Informationen zur Laufzeit bestimmt werden müssen. Fehlen dem Nutzer Informationen, werden in Abhängigkeit davon, welche Angaben nicht vorhanden sind, verschiedene Grade an Dynamik unterschieden. Dieser Sachverhalt kann in einer Hierarchie der dynamischen Integration ausgedrückt werden (siehe Abbildung 4.6). 3 Dynamisches Entdecken und Binden an einen Web Service zur Laufzeit (Just-in-Time-Integration) Service Typ: unbekannt Service Schnittstelle: unbekannt Service Standort: unbekannt 2 Dynamische Bindung an einen vorher feststehenden Service Typ zur Laufzeit. Service Typ: vorher bekannt Service Schnittstelle: unbekannt Service Standort: unbekannt 1 Web Services werden zur Entwicklungszeit mit einem Service-Typ fest "verbunden" Service Typ: vorher bekannt Service Schnittstelle: vorher bekannt Service Standort: unbekannt Abbildung 4.6: Hierarchie der dynamische Web Service Integration (basiert auf Schmelzer und VanDersypen, 2002, S. 601) Auf der ersten Stufe der dynamischen Integration werden Service-Nutzer und Service-Anbieter bereits zum Entwicklungszeitpunkt softwareseitig miteinander verbunden (engl. binding). Zu diesem Zeitpunkt ist dem Nutzer die Service-Schnittstelle des 35

46 Kapitel 4 Umsetzung Service-orientierter Architekturen mit Web Services Anbieters bereits bekannt, so dass er die konkreten Methodenaufrufe und Datentypen vorbereiten kann. Nur der spätere Standort im Netzwerk ist noch unbekannt und muss später zur Laufzeit ermittelt werden. In der zweiten Stufe ist der Typ des Web Services ebenfalls bereits zum Entwicklungszeitpunkt bekannt. Im Gegensatz zu Stufe eins, fehlt nun die Beschreibung der Schnittstelle, so dass der Service-Nutzer in der Lage sein muss, eine dynamische Bindung zum Service-Anbieter aufzubauen. Der Anbieter profitiert von dieser Flexibilität, denn er könnte seine Schnittstelle nun zur Laufzeit modifizieren und dabei von der automatischen Anpassung der Bindung des Konsumenten Gebrauch machen. Die dritte Stufe wird auch als Just-In-Time-Integration bezeichnet und beschreibt das visionäre Entwicklungsziel von Service-orientierten Architekturen. In dieser Stufe bestimmt der Konsument erst zur Laufzeit den Typ des benötigten Services und verwendet diesen, um ebenfalls auch erst zur Laufzeit die Beschreibung der Schnittstelle zu bestimmen und auch erst dann die dynamische Bindung durchzuführen. Diese höchste Form der Dynamik wird bei der Beschreibung der Modernen technologischen Paradigmen in Kapitel 5 noch einmal aufgegriffen. Mit den aktuellen Web Service Standards können bereits dynamische Anwendungen der ersten Stufe realisiert werden. Anwendungen der zweiten Stufe lassen sich - mit Einschränkungen - ebenfalls umsetzen. Allerdings wird die dritte Stufe noch nicht erreicht, denn die dynamische Auswahl eines Service-Typen erfordert die semantische Spezifikation der Funktionalität eines Web Services. Dieser Aspekt ist im Augenblick noch Gegenstand der Forschung. Web Services ist nicht die einzige Middleware-Technologie, die eine dynamische Integration von Softwarekomponenten ermöglicht. Im Vergleich bieten Web Services auch erst durch das Erreichen der zweiten Stufe neue Funktionalität und einen neuen Grad an Dynamik. Die Funktionen der ersten Stufe können auch bereits mit anderen Middleware-Technologien realisiert werden. Obwohl Web Services als viel versprechender Middleware-Ansatz gesehen und vermarktet werden, ist zum aktuellen Zeitpunkt noch nicht absehbar, ob die dritte Stufe der dynamischen Integration mit dieser Technologie überhaupt erreicht werden kann. Eventuell sind dafür vollkommen neue Konzepte mit höheren Abstraktionsebenen notwendig. 4.5 Web Services auf eingebetteten Geräten In Kapitel 2.3, Softwarearchitektur für verteilte, eingebettete Systeme, wurde der Zielkonflikt bei der Softwareentwicklung zwischen einer möglichst hohen Abstraktion zur Steigerung der Softwarequalität und dem Streben nach einem minimalen Bedarf an Ressourcen vorgestellt. In diesem Abschnitt wird ein Kompromiss für dieses Dilemma vorgestellt: das Devices Profile for Web Services (DPWS). Es ist der Versuch, eine reduzierte Fassung der komplexen Middleware-Technologie Web Services zu standardisieren, die speziell auf die Anforderungen eingebetteter Geräte eingeht. 36

47 4.5 Web Services auf eingebetteten Geräten Einführung und Anwendungsbereiche von DPWS Der Einsatz von Web Services auf eingebetteten Geräten ist mit besonderen technischen Herausforderungen verbunden. Sie liegen sowohl beim gesteigerten Ressourcenbedarf durch die Nutzung des XML-Formates und der Einführung einer neuen Abstraktionsebene als auch in der Vielfalt der Web Service Standards, die zu Inkompatibilitäten bei den Implementierungen führen können und damit effektiv die Interoperabilität zwischen Web Services verhindern (siehe Kapitel 4.3, Kritikpunkte von Web Services ). Um dennoch die Nutzung von Web Services auf eingebetteten Geräten zu ermöglichen wurde zunächst und in einer überarbeiteten Version durch die Firmen Microsoft, Intel, Ricoh und Lexmark ein neues Profil für Web Services auf eingebetteten Geräten spezifiziert: das Devices Profile for Web Services (DPWS). Ein Profil ist die Bezeichnung für eine Teilmenge der Web Service Standards, die zusätzliche Richtlinien und Konventionen zur Verwendung dieser Standards enthält. Für Unternehmen und Entwickler wird damit die unübersichtliche Menge der vorhandenen Web Service Spezifikationen reduziert, so dass eine herstellerübergreifende Interoperabilität ermöglicht wird. Das Devices Profile for Web Services fasst dazu verschiedene Standards der allgemeinen Web Service Architektur und des darauf aufbauenden WS-* Frameworks zusammen, um eine Web Service Spezifikation für eingebettete Geräte mit eingeschränkten Ressourcen bereitzustellen. Mit dem Ziel eine leichtgewichtige Web Service Spezifikation zu entwickeln, wurden dazu die Freiheiten und Funktionalitäten von Web Services eingeschränkt. Beispielsweise ist in der DPWS-Spezifikation das Transportprotokoll vorgeschrieben (Chan et al., 2006, S. 8), obwohl Web Services im Allgemeinen verschiedene Transportprotokolle nutzen können. Im Juli 2008 wurde die DPWS-Spezifikation bei dem Standardisierungsgremium OASIS zur Standardisierung eingereicht. DPWS wurde für Geräte entwickelt, die auf der Basis des Internet Protocols (IP) miteinander vernetzt sind und ermöglicht ihnen die folgenden Funktionen (Chan et al., 2006, S. 3): Entdecken eines Web Services in der Umgebung ohne ein zentrales Serviceverzeichnis zur Laufzeit, Auslesen und Verarbeiten von Metadaten eines Web Services zur Laufzeit, Versenden und Empfangen verschlüsselter und signierter Nachrichten zwischen Web Services, wobei die Struktur der ausgetauschten Nachrichten durch DPWS nicht vorgegeben wird und frei definiert werden kann, Abonnieren und Erhalten von Ereignismeldungen eines Web Services zur Laufzeit. DPWS soll damit ein Plug and Play für Netzwerkgeräte (Microsoft Corporation, 2007, S. 1) ermöglichen, so dass es auch als USB für Ethernet (Kühner, 2008, S. 130) vermarktet wird. Durch die zugrunde liegenden Web Services und die Verwendung offener Standards können DPWS-basierte Geräte auch nahtlos in die Umgebung bestehender Web Services integriert werden. 37

48 Kapitel 4 Umsetzung Service-orientierter Architekturen mit Web Services Die avisierten Anwendungsgebiete von DPWS liegen in den Bereichen der Industrieautomation, im Automobilbereich, sowie beim Home-Entertainment. Der industrielle Einsatz soll die Flexibilität und Agilität des Fertigungsprozesses erhöhen, indem beispielsweise Statusinformationen aus dem Fertigungsbereich nahtlos zur Produktionsplanung und -vorhersage im Rahmen von Enterprise Resource Planning Systemen verwendet werden können (siehe dazu auch Kirkham et al., 2008, S. 2). Im Automobilbereich soll DPWS zur Einführung eines generischen Bussystems zur Vernetzung der verschiedenen Computersysteme in einem Fahrzeug genutzt werden können. Durch die offenen Standards und das Plug and Play Verhalten, könnten etablierte Systeme wie der CAN -Bus abgelöst werden. Infotainment-Systeme im Fahrzeug könnten durch den Einsatz von DPWS mit geringeren Kosten entwickelt und mit weniger Konfigurationsaufwand in Fahrzeugen installiert werden. Der Fokus von DPWS liegt nicht auf der Entwicklung neuer Dienste, sondern viel mehr auf der Konsolidierung und Vereinheitlichung von bereits bestehenden Anwendungen. Auch im Bereich des Home Entertainments soll DPWS bereits existierende, aber proprietäre Kommunikationsprotokolle, wie das Universal Plug and Play (UPnP) oder Home Audio/Video Interoperability (HAVi) ablösen und durch einen offenen Standard ersetzen. Motiviert wird diese Entwicklung durch die Idee einer zentralen Steuerung für die verschiedenen technischen Geräte eines Haushaltes, durch die der Bedienkomfort für den Anwender wesentlich erhöht werden soll. Auch bei der Nutzung von Peripherie-Geräten, wie zum Beispiel Druckern, kann DPWS eingesetzt werden, um deren Konfiguration und Verwendung zu erleichtern. Auf der Windows Hardware Engineering Conference (WinHEC) 2006 wurde der Einsatz von DPWS im Home-Entertainment-Bereich demonstriert und gleichzeitig auch dessen native Unterstützung durch das Betriebssystem Microsoft Windows Vista TM angekündigt. Sichtbar wird diese Unterstützung durch die automatische Integration von DPWS-Geräten in die Netzwerkumgebung von Microsoft Windows Vista TM (siehe Abbildung 4.7) DPWS Terminologien: Hosting Services und Hosted Services Bereits durch die Betrachtung der Terminologien in der DPWS-Spezifikation wird deutlich, dass dort ein Service-orientierter Ansatz verfolgt wird. Dementsprechend kommunizieren und kollaborieren Services miteinander und nicht Geräte. Die physikalischen Eigenschaften eines Gerätes werden dabei durch einen besonderen Service-Typ repräsentiert: die Hosting Services. Ein Hosting Service ist ein spezieller Service, der die primäre Funktion des Gerätes beschreibt und besondere Nachrichten empfangen kann. Nur ein Hosting Service kann durch eine Discovery-Nachricht im Netzwerk gefunden werden. Für die Bereitstellung von Funktionalität kann ein Hosting Service einen oder mehrere Hosted Services aufnehmen. Hosted Services sind ebenfalls Services, die nach außen sichtbar und einzeln für Nachrichten adressierbar sind. Im Gegensatz zu einem Hosting Service werden die Hosted Services zum Realisieren von konkreter Funktionalität 38

49 4.5 Web Services auf eingebetteten Geräten Abbildung 4.7: Integration der DPWS Geräte Klimaanlage und Lichtschalter in die Netzwerkumgebung von Microsoft Windows Vista TM 39