Verteilte Systeme - Web Services

Webservices – Anbieten, Verhandeln und Abarbeiten

In den letzten 10 Jahren hat das Web die Art und Weise verändert wie wir leben. Das war aber erst der Anfang. Das Web ist eine einfache, allgegenwärtige aber bis dahin wenig beachtete Plattform für verteilte Programmierung. Warum wenig beachtet? Nun, die meisten heutigen Webservices haben eigentlich nicht sehr viel mit dem Web zu tun. Im krassen Gegensatz zu seiner Einfachheit bringen diese eine schwergewichtige Architektur für einen verteilten Objektzugriff wie einst COM oder CORBA zu Tage. Viele Webservice Architekturen erfinden die Funktionalitäten des Web neu oder ignorieren diese die das Web so erfolgreich gemacht hat.

Aber das muss nicht so sein. Die nutzvollen Funktionen die Remote Services erfolgreich machen sind uns bekannt. Diese Services existieren bereits und wir benutzen sie jeden Tag. Und diese Services können riesig werden, z.B. die Google Suchmaschine. Was ist das anderes als ein Remote Service, um eine Datenbank abzufragen und eine schön formatierte Antwort zurückzubekommen? Wir denken über Webservices normalerweise nicht als „Services“, weil das Programmierer-vokabular ist und der letztendliche Client einer Web Seite ein Mensch ist, aber ein Service ist es immerhin.

Jede Web Applikation, jede Webseite, ist ein Service. Diese Macht kann man für programmierbare Applikationen nutzen, wenn man anstatt gegen das Web mit Web arbeitet und wenn man es nicht begräbt unter zahllosen Ebenen der Abstraktion. So sollte man dem Web die Webservices zurückgeben (siehe O’Reilly RESTful Services [B4]).

REST

Web Services werden meist mit SOAP oder XML-RPC in Verbindung gebracht. Aber auch mit dem sogenannten REpresentational State Transfer oder kurz REST, einem Architekturstil, können Web Services auf einfache und effektive Weise entwickelt werden.

„Der Begriff Representational State Transfer bzw. das Akronym REST bezeichnen einen Softwarearchitekturstil für verteilte Hypermedia-Informationssysteme wie das World Wide Web. Während dessen Architektur durch den URI-Standard und HTTP beschrieben werden kann, legt der REST-Architekturstil nahe, jede Ressource mit einer eigenen URI anzusprechen.

REST stammt aus der Dissertation von Roy Fielding aus dem Jahre 2000, in welcher der Erfolg des World Wide Webs auf bestimmte Eigenschaften der verwendeten Mechanismen und Protokolle (z. B. HTTP) zurückgeführt wird. Fielding war zuvor auch an der Spezifikation des Hypertext-Transfer-Protokolls (HTTP) beteiligt.

Der Begriff wird auch im weiteren Sinne verwendet, um grundsätzlich einfache Schnittstellen zu kennzeichnen, die Daten über HTTP übertragen, ohne etwa eine zusätzliche Transportschicht wie SOAP oder Sitzungsverwaltung über Cookies einzusetzen.

REST gilt in seiner Konsequenz als eine wichtige Richtlinie für die Nutzung von Web-Standards, in Abgrenzung zu vielen historisch gewachsenen Verfahren. Daraus folgt teils eine Rückbesinnung auf grundlegende Web-Technologien, die Implementierungen verteilter webbasierter Systeme vereinfachen soll.“ – Aus Wikipedia April 2010

REST meint: Das Web ist einfach

Internet Datenverkehr besteht noch immer hauptsächlich aus E-Mail (vielen Dank an alle Spammer) und Filesharing. Daten-Streaming ist gerade am Aufholen, siehe YouTube. Wenn es also das Internet morgen nicht mehr gäbe, würden die Menschen vor allem Ihre E-Mails vermissen. Wozu brauchen wir dann das Web im Allgemeinen? Warum ist HTTP so gut geeignet für Web Services wo es doch eigentlich dazu gedacht war Projekttexte in einem Physiklabor (CERN;-) hin und herzuschicken? Nun weil es einfach und efektiv ist. In frühen Zeiten wurden HTTP und HTML einfach nur als ein schlechter Witz der Datenübertragung gesehen. Und die allererste Version von HTTP sah wirklich ein wenig danach aus:

Client Request	Server Response
GET /hello.txt	Hello, world!

Das war alles. Man verbindet sich mit dem Server, gibt den Pfad zu einem Dokument an und der Server sendet den Inhalt des Dokumentes zurück. Viel mehr konnte man mit HTTP 0.9 nicht anfangen. Es war ein mehr oder weniger funktionsloser Abklatsch von Protokollen wie FTP. Aber genau dieses Fehlen von speziellen Funktionen prädestiniert es für verteilte Programmierung. Man sagt was man will und bekommt es. Die Einfachheit von HTTP ist seine Stärke.

Adressierbarkeit und „Statusfreiheit“ besser Statelessnes sind die beiden Designentscheidungen die HTTP so erfolgreich machten. Diese Eigenschaften machen es auch heute noch zu einem gut skalierenden Protokoll auf für „Mega-Sites“. Viele Funktionen die in HTTP 0.9 fehlen haben sich als unnötig erwiesen und würden das Web nur entstellen, wenn man sie hinzufügen würde. Die restlichen wichtigen Mechanismen wurden mit der Version 1.0 und 1.1 eingefügt. Die beiden verbleibenden Mechanismen die das Web so erfolgreich gemacht haben sind URIs und HTML; später auch noch XML. Auch diese Standards sind einfach in ihrem Kern und dabei effektiv und pragmatisch aufgebaut. Sie sind somit wichtig fürs Web. Offensichtlich sind diese einfachen Technologien mächtig genug das Web und dessen Applikationen am Laufen zu halten. Das World Wide Web ist eine einfache und flexible Umgebung für die Bedürfnisse von sowohl Menschen die konsumieren und produzieren als auch für Maschinen die miteinander kommunizieren.

Große Webservices sind nicht einfach

Es existieren eine Reihe von Protokollen und Standards die, meist auf HTTP aufbauend, dafür gemacht wurden, um Webservices zu bauen. Diese Standards werden zusammengefasst unter dem WS-* Stack. Dieser schließt WS-Notification, WS-Security, WSDL und SOAP mit ein. Etwas lachs könnte man diese als die großen oder fetten Webservices bezeichnen. Komplexe Webservices basieren meist auf diesen Protokollen. Für die meisten Szenarien kann man aber einfach nur die RESTful Architektur, also HTTP und sonst nichts anwenden und kommt zu einem guten Ergebnis.

Die REST Architektur und die Resource Oriented Architecture (ROA) sind kompatibel mit einigen WS-* Standards. Diese WS-* Standards werden dazu benutzt, um Remote Procedure Calls über HTTP abzusetzen. Manchmal ist so ein RPC Stil angemessen. Was aber Probleme aufwirft ist die damit verbundene Komplexität. Allzu oft werden die großen/fetten Webservices angeboten, wo doch das gute alte HTTP den Job genauso gut hätte erledigen können. Der Effekt der dabei eintritt ist, dass HTTP auf ein Transportprotokoll reduziert wird, welches eine riesige Masse an XML Information überträgt die dann beschreiben was „eigentlich“ an Stelle des HTTP Requests passieren soll. Der daraus resultierenden Service ist komplex, nur schwer zu debuggen und wird außerdem wohl nur dann richtig funktionieren wenn all Clients das gleiche Setup besitzen wie das der Entwickler.

Große Webservices haben den Vorteil, dass moderne Tools den zugehörigen Code mit einem Klick produzieren können, besonders wenn man in Java oder C# implementiert. Wenn man solche Tools verwendet scheint es nicht wichtig die einfacheren RESTful Methoden zu verwenden. Die Tools verstecken die Komplexität und Bandbreite und Rechenzeit ist billig.

Diese Einstellung funktioniert, wenn man in einer homogenen Umgebung arbeitet, hinter der eigenen Firewall oder der von „befreundeten“ Gruppen. Also z.B. im Intranet einer Produktionsstätte. Aber wenn die Services, und vor allem deren Benutzung, sich im gesamten Internet ausbreiten sollen, dann muss man Client Programme berücksichtigen von denen man vielleicht nie etwas gehört hat. Die Benutzer des eigenen Service wollen vielleicht, dass dieser mit anderen unbekannten Services interagiert. Man muss dann proprietäre Mapping Software erstellen, damit andere den Service in einer Weise verwenden können, über die die Entwickler selbst nicht nachgedacht haben. Nun, das ist das tägliche Brot in der Welt der Webprogrammierer.

Abstraktionen echter Funktionalität sind niemals perfekt. Jeder zusätzliche Layer erzeugt Fehlerquellen, Probleme bei der Zusammenarbeit, und Skalierbarkeitsprobleme. Neue Werkzeuge können Komplexität verstecken aber nicht rechtfertigen – und sie erzeugen immer noch mehr Komplexität. Um einen Service zum funktionieren zu bringen muss man das Web als ganzes im Sinn haben, das bedeutet man muss Adaptierbarkeit, Skalierbarkeit und Verwaltbarkeit berücksichtigen. Die Einfachheit und Qualität von HTTP 0.9 sind Grundvoraussetzungen für diese Anforderungen. Je komplexer ein System ist, desto schwieriger wird es dieses zu reparieren oder zu erweitern wenn etwas schief geht oder neue Anforderungen erfüllt werden müssen.

Wenn man nun RESTful Webservices anbietet, kann man die entstehende Komplexität dazu einsetzen, um zusätzliche Funktionalität anzubieten oder um mehrere Services miteinander reden zu lassen. So ist ein erfolgreicher Service ein Teil des Web aber setzt nicht darauf auf oder benutzt es. Die Information, der Dienst, sollte verfügbar gemacht werden, nach den Regeln die all die anderen Sites im WWW anwenden. Je näher man dabei an den Basis-Web-Protokollen ist desto einfacher wird es.

Grundlagen moderner Webservices

Web Service sind ein aussichtsreicher Versuch, Service Oriented Architecture Prinzipien praktisch umzusetzen, sie stellen die technische Realisierung der SOA dar.

Den Web Services ereilte allerdings ein ähnliches Schicksal wie den Web-Portalen als um die Jahrtausendwende die Dotcom Blase geplatzt ist. Sie wurden schnell berühmt, tauchten im Gartner Hype Cycle auf und jeder versteht darunter etwas anderes. Mit dem Auftauchen eines neuen Paradigmas, des Cloud Computing welches später in diesem Skriptum behandelt wird scheinen die Webservices allerdings Ihre Bestimmung endgültig gefunden zu haben.

Die vielen Definitionen darüber, was einen Webservice zu einem solchen macht gehen leicht auseinander, je nachdem wer diese anbietet.

Das SaaS Konzept

Software as a Service (SaaS) ist eine Form von Cloud Computing, bei der Nutzer eine Applikation über das Internet beziehen. Dabei werden Infrastruktur-Ressourcen und Applikationen zu einem Gesamtbündel kombiniert. Nach ihrem Wesen, Applikationen situativ zu nutzen und nutzungsabhängig zu bezahlen, wird SaaS häufig als „Mietsoftware“ bezeichnet.

Aufgrund der Art und Weise, wie die Dienstleistung erbracht wird, passt diese Bezeichnung jedoch nicht: Der Kunde mietet keine Software, vielmehr bezieht er einen Anwendungsservice mit allen Eigenschaften, die ein Service bietet: Abnahme nach Bedarf, leichte Erweiterbarkeit und Bezahlung nach Abnahmemenge. Dieser Service beinhaltet alle für die Nutzung notwendigen Komponenten: Hard- und Software (Lizenzen), Wartung und Betrieb. Die Anbindung an den Dienstleister sowie alle kundenseitigen Komponenten und Aufwände sind nicht enthalten.

Anders als beim Application Service Providing bietet der Dienstleister beim SaaS-Modell nicht für jeden Kunden eine eigene Installation an. Hier nutzen alle Kunden dieselbe Anwendung und Infrastruktur, die sich bei einem Dienstleister befindet. Ein Vorteil eines 1 zu n-Ansatzes ist, dass Änderungen und Erweiterungen, wie z.B. notwendige Updates und Upgrades, die alle Kunden betreffen, nur einmal vorgenommen werden müssen. Dieser hohe Grad an Standardisierung schränkt jedoch die individuelle Anpassbarkeit der Lösung an die jeweiligen Kundenbedürfnisse ein (Industrialisierung von IT).

Anwendungsbeispiele für SaaS:

Da es sich bei SaaS um Standardanwendungen handelt, die bereits für andere Benutzer betrieben werden, sind die Anwendungen „sofort“ verfügbar. Sie sind in Unternehmen einfach und schnell zu testen, zu implementieren und zu verwalten. Vor dem Einsatz sind nur grundlegende unternehmenseigene Einstellungen vorzunehmen. SaaS bildet exemplarisch zwei Aspekte von Cloud Computing ab, die dynamische Skalierbarkeit und den Servicegedanken.

Bereits verbreitete Anwendungsbeispiele für SaaS sind „Communication as a Service“ oder „Collaboration as a Service“. Hierbei bezieht der Nutzer Kommunikations- oder Zusammenarbeitsdienste aus dem Internet. In der Regel verbirgt sich hinter einem solchen Angebot die Palette von Unified Communications-Diensten, also insbesondere Voice over IP-Telefonie und Instant Messaging, aber auch Webkonferenzen und E-Mail.

Unternehmen lagern hierbei also ihre Kommunikations-Infrastruktur an einen Dienstleister aus, der diese als Dienst bereitstellt. Die Schwelle, solche branchenunabhängigen Anwendungsdienste auszulagern, ist gering und kann einen einfachen Start in Cloud Computing markieren. Die in der Regel IP-basierte Kommunikations-Infrastruktur erleichtert zudem die Integration in die Geschäftsprozesse und die Addition zusätzlicher Funktionalitäten.

„Communication as a Service“ markiert einen Zugangspunkt zum Cloud Computing von der Seite der Telekommunikation.

Collaboration as a Service (ColaaS) kann als Weiterentwicklung von Communication as a Service verstanden werden. Hier steht der gemeinsame Zugriff auf Dokumente im Vordergrund, so dass Arbeitsgruppen eine Basis für ihre gemeinsame Arbeit erhalten – über Grenzen und Zeitzonen hinweg. Solche kollaborativen Organisationsformen verbreiten sich immer mehr. Die Basiskommunikation in solchen Systemen liefert das E-Mail-System, das entweder Bestandteil des Angebots ist oder via Standardprotokoll von anderen Anbietern mitgenutzt werden kann. Bestandteile eines „Collaboration as a Service“-Angebots können darüber hinaus sein: Kalender, Adressverwaltung, Instant Messaging/Chat, Telefonie, Web- und Video-Conferencing, Team-Sites oder Blogs/Wikis/Foren.

Begriffsdefinition Webservice

Die Web Services Architecture Arbeitsgruppe der W3C definiert Web Services als:

”Ein durch eine URI (nach RFC2396) identifiziertes Softwaresystem, dessen öffentliche Schnittstellen und Protokollbindungen durch XML definiert und beschrieben sind.“

Eine etwas pragmatischere Definition aus der Industrie lautet:

”A Web Service is a piece of server-side software that provides a certain functionality (as a black box) and is accessible through Internet protocols using XML/SOAP messages with a described and published interface (typically by means of WSDL). Those interface descriptions should be registered in a (global) registry such as UDDI.“ -siehe [P11]

Und weitere Definitionen aus dem „Programmierervolksmund“ lauten:

Webservices sind nichts wirklich neues, aber stellen einen neuen Ansatz dar, um die Fehler der Vorgängertechnologien zu mindern. Sie basieren auf modernen und offenen Standards und eignen sich nur für eine Computer zu Computer Kommunikation. Dabei benötigen sie ein Transportprotokoll, und unabhängig von der Programmiersprache und dem Betriebssystem. Letzteres ist nur idealer Weise richtig und gilt für die Verwendung von Webservices, nicht aber unbedingt für deren Implementierung.

Der Ausgangspunkt der Entstehung von Webservices geht eigentlich zurück auf die Zeit in der Mensch zu Mensch Kommunikation, also das Verschicken von (unstrukturiertem) Text via E-Mail. Als nächster Schritt kam dann das WWW, die Mensch zu Computer Kommunikation, bei der der Mensch konsumiert, und im Web2.0 auch produziert, und der Computer passiv bleibt (abgesehen von der dynamischen Aufarbeitung der zu präsentierenden Information) . In der dritten Phase treten nun die Webservices auf, die Computer zu Computer Kommunikation bei der ein Computer eine Dienstleistung für einen anderen Computer erbringt. Darüber hinaus verfolgt das Semantic Web die Vision wobei die beteiligten Computer sich gegenseitig „verstehen“ und „wissen“ was ihnen von anderen Computern angeboten wird. Die Dienste bieten nicht nur eine Schnittstelle mit deren syntaktischer Beschreibung an, sondern darüber hinaus auch noch semantische Metadaten die vom Benutzer verstanden werden können.

Eigenschaften von Webservices

Web Services ermöglichen die Kommunikation zwischen verschiedenen heterogenen Systemen und erleichtern dabei die Integration von existierender Soft- und Hardware in neue Systeme. Webservices agieren als Fassade, Stellvertreter oder Proxy für eine Menge von sich hinter dem Service Interface verbergenden Anwendungen. Es gibt zwei Protokollvarianten für Webservices: Dokument und RPC, wobei letztere Variante eher veraltet ist und in der Praxis bei neuen Deployments nicht mehr eingesetzt wird. Zur Beschreibung der Service Schnittstellen und der zu übertragenden Daten kommen hauptsächlich, ja fast ausschließlich, XML Protokolle wie SOAP oder XML-RPC vor und als unterliegendes Übertragungsprotokoll kommt zur Zeit hauptsächlich HTTP und HTTPS zum Einsatz. Daraus geht hervor, dass Webservices eigentlich nur für die Computer zu Computer oder „Machine to Machine“ (M2M) Kommunikation gedacht sind. Dabei ermöglichen sie einen leichteren Zugriff auf sonst unerreichbare Systeme, unter anderem auch den Aufruf über Firewalls hinweg die nur den Port 80 für HTTP Verkehr offen halten. Letzteres hat den Effekt, dass strikte Schutzmechanismen sich nun auch noch den Inhalt der HTTP Nachrichten ansehen müssen, um einen unerlaubten Kontakt zu verhindern.

Service Interface und Implementation, XML als Basis für SOAP

Das implementieren eines Dienstes als Webservices ist verhältnismäßig einfach, unabhängig davon, ob es sich dabei um einen Client oder einen Server handeln soll.

Folgende bekannte Bibliotheken zur Erstellung von Webservices basieren auf dem SOAP Protokoll:

• Apache AXIS
• Perls SOAP::Lite
• Pythons pywebsvcs
• Rubys Webservice Framework für Ruby-on-Rails
• .NET Framework
• Systinet
• IBM: ETTK
• Sun: WSDP
• Cape Clear

Wenn es jedoch dazu kommt, komplexe standardisierte Dienste zu implementieren die mit Hilfe eines WSDL Dokumentes definiert werden sollen, muss dann meist dieses WSDL Dokument per Hand erstellt werden, was ebenso komplex sein kann wie das Programmieren selbst. Für den Alltag allerdings gibt es genügend Tools welche alle notwendigen WSDL Dateien Client Stubs und Server Skeleton Klassen automatisch erstellen.

Typischer Webservice Aufruf

Um Webservices implementieren zu können sollte man die Prinzipien des SOAP Protokolls kennen und um dies wiederum leichter zu verstehen kommt man nicht umhin, sich mit speziellen XML Themen auseinanderzusetzen.

XML ist, die eXtensible Markup Language, ist ein Ableger von SGML, dem Vater aller Markup Sprachen (auch HTML). XML ist eine Metasprache die die Grundlage von Web Services, basierend auf SOAP oder einfach nur XML-RPC. Dabei bietet XML die Möglichkeit, strukturierte Dokumente zu erzeugen (SOAP request/response, WSDL oder UDDI Dokumente). Es wurde von der W3C standardisiert und die Verwendung ist frei. Es gibt viele Erweiterungen zum Basis XML Standard, einige davon sind essentiell für die Definition und Verwendung von Web Services. Für SOAP sind folgende Themengebiete wichtig: XML, Information Set (oft auch nur InfoSet), Namensräume, Schema, XPath, Signature und Encryption.

XML Information Set

Das XML Information Set ist eine mögliche Darstellung von XML Dokumenten bei dem jedes XML Dokument einem Information Set entspricht. Die vollständige Information des Dokuments wird dann als Baum dargestellt. Die Wurzel des Baums ist das „Document Information Item“. Dieses kommt daher auch nur genau einmal vor.

XML Namensräume

Es gibt für XML eine eigene Spezifikation (Recommendation), die: „Namespaces in XML“. Diese wurde ein Jahr nach der ersten XML Version veröffentlicht als eine Lösung zu dem Problem der identischen Bezeichner. Das Problem ist vergleichbar mit dem von identischen Variablennamen bei der Programmierung. Das Problem ist vor allem bei der Wiederverwendung von XML-Strukturen evident und wird durch die Verwendung einer URI als Präfix (URLs sind echte Teilmenge der URIs) gelöst (Beispiel: Das Präfix ffh: wird allen FernFh relevanten XML Tags vorausgestellt und das Präfix selbst dann über die komplette Angabe der URL www.fernfh.at definiert. Dadurch können XML Tags weltweit eindeutig bezeichnet werden).

XML Schema

Die XML Schema Description Language (XSD) ist vermutlich die wichtigste Sprache zur Formulierung von beliebigen aber „wohlgeformten“ XML Strukturen. XSD bildet zusammen mit XML 1.0 (2nd Edition) und den Namensräumen die Basis für zukünftige Entwicklungen um XML. Ein XML Schema ist ein XML Dokument, welches die Struktur von XML Dokumenten beschreibt. Ein XML Dokument bewertet man als gültig hinsichtlich eines bestimmten Schemas dem ein Dokument entspricht welches über ein solches Schema verfügt und einen zu diesem konformen Aufbau hat.

XML XPath

XPath erlaubt es, nicht nur den ”Ort“ eines XML Dokumentes, sondern auch ein Element innerhalb eines XML Dokumentes anzugeben Damit können Teile eines Dokumentes lokalisiert oder extrahiert werden XPath kann dadurch für lesende Anfragen und Suchen (via XQuery) genutzt werden. XPath wird auch in Verbindung mit XSLT, zum transformieren von XML Information verwendet.

XML Beispiel:

<addresses>

<person>

<name>

<first>Oliver</first>

<last>Jorns</last>

</name>

<city>Wien</city>

<country>Austria</country>

</person>

<person>

<name>

<first>Joachim</first>

<last>Zeiss</last>

</name>

<city>Sopron</city>

<country>Ungarn</country>

</person>

</addresses>

SOA

Ein zentrales Versprechen welches Web Services geben, besteht in der erhöhten Flexibilität und Agilität, die sich durch die verschiedenen Möglichkeiten ergibt, Dienstleistungen im Internet zu nutzen bzw. mit Hilfe aus dem Internet zu realisieren. Mit diesem Anspruch und dem Ziel, die IT-Welt zu revolutionieren, ist vor Jahren das Paradigma der service-orientierten Architektur (SOA) angetreten. Viele Anwender haben begonnen, SOA-Initiativen zu realisieren und denken darüber nach, wie SOA im Kontext von Cloud Computing einzuordnen ist.

Es ist notwendig, die Begriffe zu präzisieren und unter dem Gesichtspunkt der jeweiligen Architektur zu betrachten. Eine stringent implementierte service-orientierte Architektur schafft erst die Voraussetzung dafür, verteilte, lose gekoppelte Dienste von Cloud Anbietern zu nutzen und zu orchestrieren, insbesondere über Abteilungs- und Unternehmensgrenzen hinweg oder wenn Private Clouds mit Public Clouds oder klassische IT-Infrastruktur im Unternehmen kombiniert werden sollen (hybride Architekturen). Ohne die Modularisierung und Kapselung von Technologie, die durch eine SOA geschaffen wird, können höherwertige Cloud-Dienstleistungen nicht genutzt werden, sondern lediglich Infrastruktur-Dienstleistungen also Infrastructure as a Service (siehe Lektion über Cloud Services).

Wenn Cloud Computing über „Infrastructure as a Service“ hinausgehen will, dann ist das Architekturkonzept einer SOA als Grundlage unverzichtbar, denn SOA erlaubt es Unternehmen, Applikationen in einzelne Dienste (Services) zu zerlegen, die jeweils einen realen Geschäftsvorgang abbilden und auf Basis standardisierter Schnittstellen interoperabel eingesetzt werden können. Eine SOA ermöglicht es, diese Dienste auf einfache Weise zu kombinieren, so dass Veränderungen in Geschäftsprozessen softwareseitig schnell nachvollzogen werden können. Dies bedeutet, dass die IT-Strategie schneller an eine veränderte Geschäftsstrategie eines Unternehmens angepasst werden kann und somit zu mehr Flexibilität, Agilität und gesteigerter Wettbewerbsfähigkeit beitragen kann.

Insofern stehen SOA und das später in diesem Heft behandelte Cloud Computing nicht in Konkurrenz zueinander. Cloud Computing ist nicht die nächste Evolutionsstufe von SOA, sondern es handelt sich um zwei einander ergänzende, orthogonale Konzepte. Beide Konzepte zusammen werden in den nächsten Jahren die Business- und IT-Anforderungen, also den Austausch und die verteilte Verarbeitung von Unternehmensinformationen in globalen Wertschöpfungsnetzen, beeinflussen.

SOAP

SOAP bedeutet „Simple Object Access Protocoll“. Eine euphemistische Namensgebung, denn im Vergleich zu anderen Methoden wie RESTful Services oder XML RPC ist SOAP alles andere als einfach. Einfach zu verwenden ist es nur durch die Unmenge an Tools und IDEs die dieses Protokoll mittlerweile exzellent unterstützen.

SOAP 1.0 wurde im Herbst 1999 von DevelopMentor, IBM, Microsoft, Lotus und UserLand Software veröffentlicht. Version 1.1 wurde Anfang 2001 als W3C Note eingereicht. Die Idee, entfernte Funktionsaufrufe mit einem XML Vokabular zu ermöglichen, wurde dabei von XML-RPC übernommen. Wie bereits gesagt stand damals SOAP für ”Simple Object Access Protocol“ wobei es aber weder einfach ist noch erlaubt es einen echten Zugriff auf Objekte. Daher steht SOAP mittlerweile nur für SOAP als Kunstwort und nicht mehr als Akronym für Simple oder Objekt ...

Die aktuelle Version, SOAP 1.2 (seit April 2007), ist eine W3C Recommendation. SOAP unterstützt das Versenden von synchronen und asynchronen Nachrichten an Dienste. und ist dabei Transportprotokoll unabhängig. Meistens wird SOAP allerdings via HTTP oder HTTPS übertragen (vergleiche []).

Das SOAP Protokoll (incl. SOAP über HTTP)

Das XML-Vokabular SOAP stellt die Basis vieler Web Services dar. Es existieren auch Definitionen von Webservices welche nur SOAP Schnittstellen als solche akzeptieren. SOAP ist ein Protokoll; bestehend aus Nutzdaten und Verwaltungsinformationen (wie zum Beispiel Routing Daten). Es benötigt ein Transport-Protokoll, meist HTTP. Je nach Anwendung bieten sich aber auch SMTP (asynchron), FTP (für umfangreiche Nutzdaten) oder direkt TCP (für hohe Performanz) an. Die aktuelle Version, SOAP 1.2, ist eine W3C Recommendation (siehe http://www.w3.org/TR/soap12-part0/ .../part1 und .../part2 (vergleiche auch [P11]).

Die SOAP Nachricht

Einfaches Beispiel einer SOAP Nachricht, welches die wesentliche Struktur eines Requests zeigt, sieht wie folgt aus:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope%22>

<env:Header>

<n:hello xmlns:n="http://example.org/hello%22>

<n:expires>2003-10-28T18:00:00+01:00</n:expires>

<n:someint>1</n:someint>

</n:hello>

</env:Header>

<env:Body>

<my:message xmlns:my="http://www.mycompany.com/myns%22>

<my:text>Hello World!</my:text>

</my:message>

</env:Body>

</env:Envelope>

Jede SOAP Nachricht besitzt folgende Elemente (unabhängig davon, ob es sich um Request oder Response, synchronem oder asynchronem Aufruf handelt):

• Einen Envelope mit dem Namensraum, bei SOAP 1.2 ist dies http://www.w3.org/2003/05/soap-envelope Dort gibt es auch das Schema.
• Einen optionalen Header mit Verwaltungsinformationen und evtl. benutzerdefinierten Feldern.
• Einen Body mit mindestens einem Element. Der Body enthält die gesamten Nutzdaten.

Der SOAP Header

Der SOAP Header enthält Verwaltungsinformationen und Metadaten. Für die Header Elemente gilt, dass diese keine Nutzdaten enthalten, diese oft nicht nur für den (endgültigen) Empfänger angegeben werden und dass diese nicht von SOAP-Knoten verarbeitet werden (außer das Attribut mustUnderstand == true siehe unten). Typische Header Elemente sind Routinginformationen, Transaktionsdaten, Zugriffsdaten wie Name und Passwort (letztere sollten aber verschlüsselt sein, z.B. via WS-Security).

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope%22>

<env:Header>

<n:ext xmlns:n="http://example.org/ext%22 env:mustUnderstand="true">

<n:someint>1</n:someint>

</n:ext>

<m:ext2 xmlns:m="http://example.org/ext2%22 env:role="http://www.w3.org/2003/05/soap-envelope/role/next%22

env:mustUnderstand="true">

<m:someint>1</m:someint>

</m:ext2>

</env:Header>

<env:Body>

<my:message xmlns:my="http://www.mycompany.com/myns%22>

<my:text>Hello World!</my:text>

</my:message>

</env:Body>

</env:Envelope>

Beachtung und Verarbeitung von Header-Elementen ist optional, außer das Attribut mustUnderstand ist logisch wahr, also true oder 1. Kann ein SOAP-Knoten ein Header-Element in einem solchen Fall nicht bearbeiten, so muss dieser einen SOAP-Fault erzeugen und an den Sender zurückschicken. Ein SOAP-Knoten ist jeder Rechner zwischen Sender und Empfänger, der SOAP versteht.

Einschränkungen werden durch das Attribut role bestimmt. Im gegebenen Beispiel (oben) muss das Element ext2 nur vom Knoten http://example.org/ext2 verstanden werden. Dieser Knoten wird nach Bearbeitung das Element aus der Nachricht löschen. Andere mögliche Rollenattribute sind ultimateReceiver oder none.

Der SOAP Body

<?xml version="1.0" encoding="UTF-8"?>

<env:Envelope

xmlns:env="http://www.w3.org/2003/05/soap-envelope%22

xmlns:b="http://www.fernfh.at/AddService>

<env:Body>

<b:add env:encodingStyle="http://www.w3.org/2003/05/soap-encoding

<b:a>2</b:a>

<b:b>3</b:b>

</b:add>

</env:Body>

</env:Envelope>

Jede SOAP Nachricht muss einen Body mit mindestens einem Element haben welches aus einem anderen Namensraum als dem von SOAP stammen muss. Dies ist für eine eventuelle Überprüfung des Schemas notwendig. Wie man im Beispiel oben sehen kann beinhaltet der Body alle Nutzdaten, d.h. alle Parameter für einen Service Aufruf beziehungsweise alle Rückgabewerte einer Service Antwort (siehe auch [P11]).

Fehlerbehandlung in SOAP

Entsteht bei einem Web Services Aufruf ein Fehler, so muss ein sog. Soap-Fault an den Sender geschickt werden. Der Body eines Faults besteht nur aus einem fault Element. Dieses muss ein Code und ein Reason Element enthalten. Weitere Elemente wie Detail sind optional. HTTP Fehlermeldungen wie 403 oder gar ein HTTP redirect sind nicht zulässig.

Folgendes Beispiel zeigt einen SOAP Timeout Fehler (siehe [P11]):

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope%22

xmlns:m="http://www.example.org/timeouts%22

xmlns:xml="http://www.w3.org/XML/1998/namespace%22>

<env:Body>

<env:Fault>

<env:Code>

<env:Value>env:Sender</env:Value>

<env:Subcode>

<env:Value>m:MessageTimeout</env:Value>

</env:Subcode>

</env:Code>

<env:Reason>

<env:Text xml:lang="en">Sender Timeout</env:Text>

</env:Reason>

<env:Detail>

<m:MaxTime>P5M</m:MaxTime>

</env:Detail>

</env:Fault>

</env:Body>

</env:Envelope>

SOAP und WSDL

WSDL ist die Web Services Description Language. Es ist ein XML Vokabular zum Beschreiben von Schnittstellen. Bei Web Services ist eine maschinenlesbare Schnittstellenbeschreibung nicht erzwungen, aber unbedingt empfehlenswert, den unter anderem werden WSDL Definitionen von entsprechenden Tools zur Codeerzeugung verwendet. Andere Tools können aber auch aus einer lokalen Klassendefinition (in welcher Sprache auch immer) ein WSDL Generieren, damit andere Applikationen diese Klasse als Service ansprechen und verwenden können. Entsprechende Beschreibungen dienen auch als Dokumentation für den Dienst an sich.

Die wichtigsten Elemente eines WSDL Dokuments sind :

• Interface aller exportierter Funktionen
• Definition der Ein- und Ausgabedatentypen
• Binding Information (wie rufe ich den Dienst auf )
• Adressangaben (wie genau finde ich den Dienst)

Ein WSDL Dokument ist wie folgt aufgebaut:

• Root-Element: <definitions>
• Kind-Elemente bei WSDL 1.1 sind (WSDL 2.0):
• <types> enthält die verwendeten Datentypen
• <message> gibt an, welcher Nachrichteninhalt übertragen werden kann.
• <portType> (interface) Signaturen der Methoden
• <binding> liefert Details zur Implementierung inklusive der Protokolle zum Aufruf.
• <port> (endpoint, Teil von service)
• <service> enthält eine Sammlung von einem oder mehreren Ports: wo überall finde ich die Services (Server Adressen).

WSDL root element:

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions

targetNamespace="http://localhost/axis/Calc.jws%22

xmlns="http://schemas.xmlsoap.org/wsdl/%22

xmlns:apachesoap="http://xml.apache.org/xml-soap%22

xmlns:impl="http://localhost/axis/Calc.jws%22

xmlns:intf="http://localhost/axis/Calc.jws%22

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/%22

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/%22

xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/%22

xmlns:xsd="http://www.w3.org/2001/XMLSchema%22>

<!-- portType -->

<!-- message -->

<!-- binding -->

<!-- service -->

</wsdl:definitions>

WSDL Signatur der Methode:

<!-- definitions -->

<wsdl:portType name="Calc">

<wsdl:operation name="add" parameterOrder="a b">

<wsdl:input message="impl:addRequest" name="addRequest"/>

<wsdl:output message="impl:addResponse" name="addResponse"/>

</wsdl:operation>

</wsdl:portType>

<!-- message -->

<!-- binding -->

<!-- service -->

WSDL Binding:

<!-- definitions -->

<!-- portType -->

<!-- message -->

<wsdl:binding name="CalcSoapBinding" type="impl:Calc">

<wsdlsoap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http%22/>

<wsdl:operation name="add">

<wsdlsoap:operation soapAction=""/>

<wsdl:input name="addRequest">

<wsdlsoap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/%22

namespace="http://DefaultNamespace%22 use="encoded"/>

</wsdl:input>

<wsdl:output name="addResponse">

<wsdlsoap:body

encodingStyle="http://schemas.xmlsoap.org/soap/encoding/%22

namespace="http://localhost/axis/Calc.jws%22 use="encoded"/>

</wsdl:output>

</wsdl:operation>

</wsdl:binding>

<!-- service -->

Aus obigem ergibt sich, dass man den Dienst im RPC-Style über HTTP anspricht und dass es eine Methode add gibt. Ein- und Ausgabe sind auch referenziert.

WSDL Port definition:

<!-- definitions -->

<!-- portType -->

<!-- message -->

<!-- binding -->

<wsdl:service name="CalcService">

<wsdl:port binding="impl:CalcSoapBinding" name="Calc">

<wsdlsoap:address location="http://localhost/axis/Calc.jws%22/>

</wsdl:port>

</wsdl:service>

Der Service rennt auf: localhost Verzeichnis axis und hat den Namen Calc.java

SOAP und UDDI

UDDI bedeutet: Universal (Service) Description, Discovery and Integration. Während WSDL eine rein technische Beschreibung der Schnittstelle bietet ist UDDI ein SOAP basierter Dienst, der die WSDL Information erweitern und ergänzen soll. UDDI kann mit den gelben Seiten einer Telefongesellschaft (oder dem Herold) verglichen werden, also eine Art Branchenbuch für Webservices. Meta-Daten zu den Diensten (z. B. um was für einen Dienst es sich handelt) können erfasst werden. Außerdem werden Suchmöglichkeiten nach Diensten spezifiziert.

UDDI wird seit Herbst 2000 von Ariba, IBM und Microsoft entwickelt. Es ist ein Register/Broker für Dienste inklusive Beschreibung und Suchmethoden. Wichtige Daten sind Kontaktinformationen, Infos über die Dienste, kategorisierte Listen und Protokoll-Informationen. UDDI besteht aus einem Netzwerk von (UDDI)-Knoten, die via SOAP Informationen austauschen. Dies erlaubt verteiltes veröffentlichen und (hoffentlich auch) finden von Webservices.

Ein UDDI Verzeichnis und dessen Daten sind intern als Baum strukturiert, wobei einmal mehr XML zur Anwendung kommt. In dieser Struktur gibt es vier wesentliche Elemente:

• Firmen (Business-Entity)
• Dienste (Business-Service)
• Bindungen (Binding-Template)
• Technisches Modelle (TModel)

Die ersten drei Elemente bilden die oberen Knoten im Baum und TModels bieten und erlauben Referenzen auf externe Informationen (siehe [P11]).

SOA im Detail

Erklärung und Definition

Die Grundidee von SOA ist Dienste verteilt in einem Computernetz anzubieten. Dienste können von anderen Diensten genutzt werden und so aus einzelnen bekannten Diensten einen neuen mehrwertigen Dienst zusammenstellen. Die Dienste werden veröffentlicht und in Verzeichnissen aufgenommen. Andere Dienste können diese dann finden und bekommen Informationen darüber, wie man den gefundenen Dienst nutzen kann.

SOA wird oft im Zusammenhang mit EAI (Enterprise Application Integration) unter dem Topic Interoperabilität genannt. Dabei geht es um Integration von alten in neue Systeme. Ein paar Beispiele dazu:

• Beispiel 1: Buche einen Flug, reserviere einen Sitzplatz, bezahle den Flug.
• Beispiel 2: Automatisches Lager, das automatisch nachbestellt und dabei den billigsten Anbieter sucht.
• Beispiel 3: Kühlschrank mit Barcodeleser und automatischer „Lagerführung“ und Nachbestellung im Internet.

Ein möglicher Ansatz zur Umsetzung der SOA Paradigmen sind Web Services.

Es gab bereits einige Ansätze in diese Richtung, z.B. RPC, RMI, DCOM oder CORBA. Diese haben den Nachteil, dass sie abhängig von Betriebssystem oder Programmiersprache sind. Deren Verwendung war oft sehr komplex. Softwaresysteme bestehen mehr und mehr aus kleinen Komponenten, die über immer mehr Rechner verteilt sind, eine Anforderung die mit den oben genannten „alten“ Systemen nicht realisierbar war. Außerdem konnte kaum eine Integration von externen Systemen bei anderen Institutionen (Zuliefererintegration) erstellt werden. Moderne Webservices versprechen diese Probleme via SOAP, WSDL und UDDI diese Probleme zu lösen

Probleme die SOA Implementierungen lösen müssen sind:

• Wie findet man die Funktionalität, die gerade braucht wird?
• Wie benutzt man ein Modul, nachdem man es gefunden hat?
• Braucht ich bestimmte Soft- oder Hardware, um den Dienst nutzen zu können?
• Wie kann man sicherstellen, dass andere den bereitgestellten Dienst überhaupt finden können?

Rollenvergabe für und Ablauf von Services

Es gibt 3 wesendliche Rollen in einem SOA basierten System:

1. Dienstanbieter

Implementiert den Dienst und publiziert diesen auf einem meist über das Internet zugänglichen Server. Er dokumentiert die Aufrufschnittstelle (das Interface) in einer computerlesbaren Form und ist verantwortlich für die Bereitstellung (hosting).

2. Dienstverzeichnis

Hier werden die von den Anbietern veröffentlichten Schnittstellen in einer katalogisierten Form verwaltet und präsentiert. Ein solches Verzeichnis kann mit den gelben Seiten verglichen werden.

3. Dienstnutzer

Er nutzt den angebotenen Dienst, nachdem dieser meist über einen Verzeichnisdienst gefunden wurde.

In einem SOA Szenario laufen meist folgende Schritte ab:

1. Ein Anbieter (Service Provider) implementiert einen Dienst.
2. Der Dienst wird inklusive der Beschreibung veröffentlicht (deployment).
3. Der Dienst wird bei einem Verzeichnisdienst (Service Broker) registriert (siehe UDDI).
4. Ein Nutzer sucht im Verzeichnis nach einem Dienst und erhält eine Liste möglicher Kandidaten inkl. Schnittstellenbeschreibung (siehe WSDL).
5. Der Nutzer ruft einen Dienst mit Hilfe der erhaltenen Informationen auf.

Sämtliche Schritte laufen unter Zuhilfenahme standardisierter Protokolle und einem einheitlichen Datenformat ohne menschliche Interaktion ab.

Praktische Übung

In dieser Übung geht es um die Bereitstellung und Konzeptausarbeitung von Webservices welche dazu verendet werden können um in einem Cloud Computing Szenario eingestzt werden zu können.

Bearbeiten Sie dazu folgende Aufgabenstellung:

1. Installieren Sie einen EJB und SIP Servlet Server und deployen und testen Sie ein Beispielservice welches über Technologie- und Marktdomänen hinweg eine Gesamtdienstleistung bereitstellt.
2. Verfassen Sie, basierend auf den Erfahrungen zu Punkt 1, ein formloses Konzeptdokument von circa 10 Seiten in dem Sie eine mögliche Geschäftsidee ausformulieren. Dabei geht es um die Darstellung des Konzeptes und zu möglichen verwendeten Technologien und Designansätzen. Sollte Ihre Idee so fortschrittlich sein, dass sie aus Ihrer Sicht gegenwärtig nicht umgesetzt werden kann, dann diskutieren Sie bitte entsprechende Fragen und Probleme die es zu beantworten bzw. zu lösen gilt, um den Dienst in die Realität umzusetzen

Nähere Erläuterungen zu Punkt 1.:

• Installieren Sie den frei erhältlichen Applikationsserver Sailfin. Laden Sie dazu zunächst das Installationspaket herunter unter https://sailfin.dev.java.net/downloads/download_windows.html für Windows, .../download_mac.html für Apple Rechner oder .../donwload_linux.html für Linux. Laden Sie das „Promoted Build“ JAR-File herunter.
• Die Vorgehensweise zur Installation und Konfiguration entnehmen Sie bitte folgender Seite: https://sailfin.dev.java.net/downloads/instructions.html
• Starten und Testen Sie nun das CallSetup Beispiel, welches zusammen meit dem Server beim Installieren auf Ihren Rechner kopiert wurde. Folgen Sie dabei den Anweisungen auf der Seite https://sailfin.dev.java.net/downloads/sampleinstructions.html
• Beachten Sie, dass die Anweisungen zum Starten und Testen auch ausführlich beschreiben, wie die Client-Applikationen installiert und Konfiguriert werden müssen. Es handelt sich dabei um die X-Lite Software die Verwendet wird um SIP basierte Voice und Video Kommunikation durchzuführen.
• Testen Sie den Dienst indem Sie die In der Anleitung beschriebene Webseite aufrufen, Zwei Client-Instanzen starten und dann via Klicks auf der Webseite einen Voice-Call initieren.