JavaSpektrum April/Mai 2004 [antikvár]

^Auf den inoffiziellen Buzzword-Charts der ^ Softwarebranche nimmt „Service-oriented Architecture" (SOA) mittlerweile einen der vordersten Ränge ein. Über diese Tatsache lässt sich nur schwerlich streiten. So fördert eine Internet-Recherche problemlos Tausende Treffer zu Tage. Die Frage, was nun genau unter diesem Fachterminus zu verstehen ist, dürfte da schon mehr Raum für Diskussionen bieten. Zumindest weist die häufige Nennung von XML Web-Services in diesem Zusammenhang in eine tendenzielle Richtung. Doch was in aller Welt ist denn nun eine SOA? Prinzipiell verhält es sich recht einfach. Es handelt sich sozusagen um alten Wein in neuen Schläuchen, wie mir erfahrene CORBA-Entwickler bestätigen können. In einer SOA treten diverse Ingredienzien und Rollen in Erscheinung. Service-Anbieter offerieren Anwendungsfunktionalität über Schnittstellen, die sich entfernte Service-Konsumenten zu Nutze machen. Damit beide zusammenfinden, stehen globale Anmelde- beziehungsweise Suchdienste zur Verfügung. Hat ein Service-Konsument erst einmal einen passenden Anbieter lokalisiert, greift er über geeignete Kommunikationsmechanismen auf dessen Dienste zu. Fertig ist die Service-orientierte Architektur. In einer heterogenen und vernetzten Umgebung wie dem Internet darf ein Service-Konsument freilich keinerlei Annahmen über Implementierungsspezifika eines Dienstes machen, ebenso wenig wie umgekehrt. Zentrale Mechanismen wie die Kommunikation der beteiligten Entitäten, die Registrierung von Diensten und deren Lokalisation, sowie die Bereitstellung von Anwendungsfunktionalität Y Editorial Stets zu Diensten über Schnittstellen müssen einen offenen Ansatz verfolgen. Damit sind wir in der Welt derjenigen IT-Standards angelangt, die diese offene Integration adressieren. Einen ersten Ansatz hierfür bot und bietet CORBA, das bekanntlich eine sehr erfolgreiche aber leider nicht von allen Herstellern und Anwendern akzeptierte Integrationstechnologie repräsentiert. Da sich die so genannten „Main Players" wenigstens auf das Web aík kleinsten gemeinsamen Nenner verständigen konnten, fungieren heutzutage hauptsächlich XML und XML Web-Services als universelle Integrationshebel. Kein Wunder also, wenn sich Erörterungen über Service-orientierte Architekturen meistens auf diese Technologiefamilien beschränken. Soweit die gute Nachricht. Die schlechte Nachricht lautet, dass Ansätze wie SOAs in ihrer Tragfähigkeit natürlich direkt auf den Säulen der zugrundeliegenden Standards ruhen. Dass wir uns nicht falsch verstehen. In der Theorie gilt die Verfügbarkeit von Standards als heiliger Gral, bestünde die Alternative doch darin, sich von eigenen oder herstellerspezifischen Ansätzen abhängig zu machen. Leider verhält sich Sache in der Praxis nicht ganz so einfach. Würde zum Beispielfür jede Problemdomäne nur ein Standard existieren, wäre die Auswahl von Standards völlig unproblematisch. Stattdessen stehen wir dem Dilemma konkurrierender Standards und Standardisierungsgremien gegenüber (z. B. W3C, WS-I, OASIS). Selbst wenn wir diese erste Hürde zu meistern vermögen und uns auf eine Untermenge von SOA-relevanten Standards festgelegen können, gibt es weitere Stolpersteine: ˇ So sind Entwickler in Bezug auf SOAs mit vielen komplementären Standards konfrontiert, die sich ständig im Fluss befinden und jeweils zusätzliche Komplexität in die tägliche Projektarbeit injizieren. Die Kombination mehrerer Standards im selben Projekt kann dieses Problem durchaus potenzieren. ˇ Zu allem Überfluss erweisen sich manche Standards als unreif, unvollständig, fehlerhaft, praxisfern oder als nur eingeschränkt tauglich (UDDI). Trotzdem avancieren manche von ihnen schon frühzeitig zu Technologie-Hypes. Sie suggerieren IT-Managern, alle Weltprobleme zu lösen, und verursachen gerade dadurch erst Probleme. t Einige Hersteller unterstützen Standards nur partiell, interpretieren sie an einigen Stellen nach eigenem Gusto oder ergänzen ihre Implementierungen aus Differenzierungsgründen um proprietäre Bestandteile, meist ohne die jeweiligen Grenzen zu nennen. t Nicht alle Fragestellungen Service-orien-tierter Architekturen lassen sich heute mit Standards lösen. Ein paar Beispiele: Der in der Praxis wichtige Aspekt nicht-funktiona-ler Eigenschaften und Dienstgüten bleibt oft vernachlässigt. Standards fokussieren sich meistens auf horizontale Problemstellungen, und nur selten auf vertikale Anwendungsdomänen. Viele Standards stellen syntaktische statt semantische Eigenschaften in den Vordergrund. Neben diesen primär technischen Punkten sind auch geschäftliche Aspekte relevant. Was passiert zum Beispiel, wenn Standards wie XML Web-Services geistiges Eigentum kommerzieller Unternehmen beinhalten? Wie verhält es sich in diesem Zusammenhang mit Lizenzierungsfragen? Insgesamt erkennen wir also bei genauerer Analyse eine Vielzahl noch offener Fragen und Probleme. Was aber ist jetzt die Moral von der Geschieht? Generell stellen Service-orientierte Architekturen einen mächtigen architektonischen Ansatz dar. Ausgehend von der Prämisse, dass Webtechnologien in Zukunft immer mehr an Bedeutung gewinnen, scheint ihr Siegeszug nicht aufzuhalten. Bewusst muss sich aber jeder darüber sein, dass die Qualität einer SOA-Anwendung direkt von den verwendeten Standards beziehungsweise deren konkreter Implementierung abhängt. Um Projektrisiken zu minimieren, sollte deshalb diesem Aspekt gerade in der Inception-Phase besondere Aufmerksamkeit gewidmet werden. Überflüssig zu sagen, dass Java die beste Technologieplattform für SOAs darstellt. In diesem Sinne viel Vergnügen mit der neuen Ausgabe Ihr Michael Stal