Berater und Strategen preisen gerne die Segnungen von serviceorientierten Architekturen (SOA). Admins und Entwickler hören dann weg, wenn nicht greifbar ist, wie die Technik funktioniert. Zeit für sie, selbst einen Webservice zu programmieren, bei dem heterogene Anwendungen miteinander kooperieren.

© joexx, Photocase.com

IT-Strategen verlieren sich gerne im Allgemeinen. Serviceorientierte Architekturen (SOA) halten viele ebenso für die Universallösung wie der dort am häufigsten eingesetzte Kommunikationsstandard Webservices [1]. Aus akademischer Sicht spricht einiges dafür, aber wieso ist dieses Thema immer so unkonkret und missverständlich, fragen viele Anwender.

Das fängt schon mit dem Namen an: Ein Webservice hat per se nicht viel mit dem World Wide Web zu tun, außer vielleicht dem Detail, dass sowohl Webservices als auch WWW dasselbe Transportprotokoll HTTP benutzen. Webservices müssen keine Web-Applikationen und auch nicht über das WWW öffentlich erreichbar sein. Vermutlich trifft dies nur auf wenige Anwendungen zu, die Webservices verwenden.

Auf der anderen Seite erlauben sie, komplexe Anwendungen auf mehrere Systeme zu verteilen. Wie das genau geht, erläutert ein fiktives Anwendungsbeispiel: Ein Client stellt eine Kundenanfrage in Textform und ein Server beantwortet sie in einer Weise, wie sie typischerweise ein Call Center liefert. Beide unterhalten sich per Webservice. Das Beispiel ist in Java implementiert, eine Sprache, die SOA-Entwickler gern einsetzen.

Miteinander reden

Oft besteht die Architektur eines Unternehmens aus mehreren heterogenen Systemen. Die wollen untereinander Funktionen aufrufen. Es gibt viele Techniken, um Remote Procedure Calls (RPCs) umzusetzen, und dafür vermutlich noch viel mehr Namen. Ein Webservice ist ein Ansatz, der sich auf zwei Aspekte konzentriert. Erstens greift er auf bestehende Standards und Techniken zurück, um zu kommunizieren. Zweitens legt er einen Schwerpunkt darauf, bei Bedarf möglichst einfach von einem Dienstanbieter auf einen anderen zu wechseln, ohne die Anwendung selbst nennenswert zu verändern.

Um diese Ziele zu erreichen ist ein hohes Maß an Abstimmung notwendig. Eine Reihe von Standards definiert, was ein en Webservice ausmacht [2]. Die wichtigsten sind hierbei XML als grundlegende Beschreibungssprache, SOAP als Nachrichtenformat in XML, WSDL als Schnittstellenbeschreibung in XML und HTTP als ein mögliches Transportprotokoll. Im Unterschied zu früheren Ansätzen wie DCOM oder Corba wurden Webservices entworfen, um Systeme über das Internet und über Firewall-Grenzen hinweg zu verbinden. So integrieren Systemarchitekten ihre Anwendungen leichter [3].

XML beschreibt Nachrichten

XML beschreibt sowohl die Schnittstellen als auch die darüber ausgetauschten Nachrichten - unabhängig davon, für welche Plattform sie der Entwickler entworfen hat (siehe Abbildung 1). In der Praxis laufen viele Systeme unter Java, aber es lassen sich durchaus auch Mainframes oder kleinere Serversystem mit eigenen Programmiersprachen anbinden. XML fungiert dabei als eine Art universelle Sprache. Die Partner können so miteinander interagieren, ohne dass ihre jeweiligen Entwickler sie auf technologischer Ebene angepasst haben. Wer solche Systeme einsetzt, hat den Vorteil, dass er keine Adapter für jedes System benötigt, mit dem er kommunizieren will.

Abbildung 1: Webservices nutzen XML, um leichter zwischen unterschiedlichen Technologien zu vermitteln. So spielen Endianness oder Textcodierung keine Rolle mehr.

SOAP ist ein leichtgewichtiges Protokoll, mit dessen Hilfe Webservices Informationen austauschen [4]. Es verwendet einerseits XML, um die Nachrichten zu beschreiben und andererseits Protokolle wie HTTP oder SMTP, um sie auszutauschen.

Die Ziele von SOAP sind Einfachheit und Erweiterbarkeit. Dies bedeutet, dass SOAP keine Querschnittsbelange wie Sicherheit oder Routing definiert. Andere Standards setzten auf SOAP auf und erweitern es so. Eine SOAP-Nachricht verhält sich wie eine Art Briefumschlag, der Steuerdaten und Nutzdaten enthält (siehe Abbildung 2). Der Inhalt der Datenfelder ist applikationsspezifisch.

Abbildung 2: Eine SOAP-Nachricht enthält mehrere Datenbereiche. Sie besteht aus Steuerdaten und Nutzlast, ähnlich wie ein Briefumschlag.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Berater und Strategen preisen gerne die Segnungen von serviceorientierten Architekturen (SOA). Admins und Entwickler hören dann weg, wenn nicht greifbar ist, wie die Technik funktioniert. Zeit für sie, selbst einen Webservice zu programmieren, bei dem heterogene Anwendungen miteinander kooperieren.