Allmählich fügt sich das Puzzle jener neuen Technologien zusammen, die Microsoft in den für Ende 2006 angekündigten XP-Nachfolger "Windows Vista" (Codename Longhorn) packen wird. Als wichtige Infrastrukturkomponente für die Entwicklung und den Betrieb verteilter Anwendungen wurde zuletzt "Indigo" vorgestellt, das in der für September erwarteten Longhorn-Testversion Beta 1 erstmals enthalten sein soll. Dabei handelt es sich um ein Applikations-Framework, das die bisher bestehenden Kommunikationsmechanismen unter .NET vereinheitlicht und Entwicklern ein darauf aufbauendes, konsistentes Programmiermodell liefern soll. Als nachgereichte Erweiterung des noch für dieses Jahr angekündigten .NET-Framework 2.0 (mit Visual Studio 2005) dürfte Indigo insbesondere jenen Entwicklern die Arbeit erleichtern, die im aktuellen Windows-Standard die Qual der Wahl aus fünf unterschiedlichen Kommunikationsmechanismen haben. Künftig wird die Interaktion von Anwendungskomponenten vollständig auf dem Web-Service-Protokoll Soap (Simple Object Access Protocol) basieren.
Objektorientierung versus Serviceorientierung
Die Idee verteilter Anwendungen, die aus wiederverwendbaren Komponenten bestehen, ist nicht neu. Allerdings unterscheidet sich der aus den 90er Jahren stammende Ansatz der Objektorientierung deutlich von den Service-orientierten Architekturen. Diese basieren auf vier Prinzipien:
Gemeinsames Schema statt gemeinsamer Klasse:
Kennzeichnend für die objektorientierte Programmierung ist die permanente Schaffung neuer Abstraktionsebenen in Form von Klassen. Für Programmierer ist das bequem, weil Struktur und Verhalten zu einer Einheit verschmelzen. Services hingegen interagieren unter strikter Trennung von Strukturen und Contracts. Dadurch erübrigt sich unter anderem die Notwendigkeit einer gemeinsamen Ausführungs- und Sicherheitsumgebung.
Services sind autonom:
Eine Service-orientierte Umgebung setzt niemals eine oberste Kontrollinstanz für das Gesamtsystem voraus. Services und konsumierende Clients können völlig unabhängig voneinander installiert und betrieben werden. Im Gegensatz dazu sind objektorientierte Programme berüchtigt für die vielschichtigen Abhängigkeiten der Komponenten untereinander - ein Grund übrigens, weshalb sich viele klassische Windows-Programme nicht durch einfaches Kopieren installieren lassen.
Grenzen sind eindeutig:
Ältere Objekttechniken wie DCOM versuchten, die Unterschiede zwischen lokalen und im Netz verteilten Objekten zu verwischen, um so das Programmiermodell zu vereinfachen. Sie verschleierten dabei aber gleichzeitig viele unausweichliche Differenzen. Services verbergen diesen Umstand nicht, stattdessen machen sie die Grenzen zwischen den agierenden Instanzen sowie die dazwischen liegenden Kommunikationsmechanismen deutlich sichtbar.
Kompatibilität basiert auf Richtlinien:
Objektorientierte Designs vermischen oft strukturelle mit semantischer Kompatibilität. Serviceorientierung zieht hier eine klare Grenze: Die strukturelle Kompatibilität basiert auf Contract und Schema und kann per Prüfroutinen validiert werden. Semantische Kompatibilität basiert auf ausdrücklichen Statements über Fähigkeiten und Anforderungen in den Richtlinien.
Quelle: Don Box, Indigo-Entwicklerteam
Hier lesen Sie …
• welche Rolle Indigo im Rahmen von Windows Vista (Longhorn) zukommen wird;
• wie die Infrastrukturkomponente die Kommunikationsmechanismen der Applikationen vereinheitlicht;
• wo die Grenzen des Frameworks liegen.
www.computerwoche.de/go/
*80263: SOA-Risiken werden gern verschwiegen;
*77858: Sun setzt auf Middleware-Karte;
*76985: ESB jetzt auch als Open Source;
*75895: SAP schmiedet ESA-Allianzen.
Komplizierte Objekte
Service-orientierte Softwareplattformen stellen eine Zäsur gegenüber dem seit den 90er Jahren vorherrschenden Konzept der Objektorientierung dar. Letztere ermöglichte es erstmals, Anwendungen im großen Stil aus vielen gekapselten und wiederverwendbaren Bauelementen (Komponenten) zusammenzustellen. Zu den bekannten objektorientierten Techniken zählen Corba (Common Object Request Broker Architecture) sowie Microsofts COM (Component Object Model). Mit ihnen wurde es selbstverständlich, nicht mehr jede Geschäftsfunktion und jedes Element einer grafischen Oberfläche neu zu entwickeln, sondern bereits vorhandene Funktionen alternativ von Drittanbietern zu beziehen oder aus bestehenden Projekten wiederzuverwenden. Als kompliziert erwies sich die Objekttechnologie jedoch spätestens ab dem Punkt, wo es um die Entwicklung von über das Netz verteilten Anwendungen ging. Microsoft brachte dazu Mitte der 90er Jahre DCOM (Distributed Component Object Model). Aus Entwicklersicht war die Idee zunächst charmant, denn mit DCOM sollte der Unterschied zwischen lokalen und verteilten Objekten dank transparenter Methodenaufrufe nicht mehr wahrnehmbar sein.
Allerdings hat diese Form der abstrahierten Verdrahtung auch gravierende Nachteile. So setzt die Interaktion von Objekten mittels Methodenaufrufen in der Regel eine einheitliche Betriebssystem-Plattform voraus, was im Fall von DCOM "Windows-only" hieß. Ebenso müssen Entwickler sehr viel über die genaue Funktionsweise der verwendeten Komponenten wissen, um diese auch korrekt miteinander in Verbindung zu setzen. Genau das gestaltet sich aber in größeren verteilten Systemen sehr schwierig und aufwändig.
Service-orientierte Architekturen eignen sich für solche Fälle besser, weil sie eine allgemeinere Form der Abstraktion verwenden und dabei eine Art Black-Box-Prinzip zugrunde legen. Hierbei geht man davon aus, dass die konsumierende Komponente (Client) kein Vorwissen über ihren Gegenpart am Server hat, umgekehrt muss der Service nichts über die Clients wissen. Notwendigerweise müssen dabei aber die Regeln der Interaktion zwischen Client und Service sehr allgemein formuliert sein, denn nur so lassen sich Mechanismen eines automatisierten Verbindungsaufbaus realisieren. Mittlerweile existieren bereits viele populäre Beispiele für diese Form der unverdrahteten, lose gekoppelten Vernetzung - so etwa die von Amazon oder Ebay angebotenen Web-Services. Diese Dienste wissen weder, welche Clients zu welchem Zweck zugreifen, noch setzen sie eine vordefinierte Plattform auf einer der beiden Seiten voraus.
Die Entwicklung von SOA geht einher mit dem Aufkommen plattformunabhängiger Web-Service-Standards auf XML-Basis. Diesem seit einigen Jahren vorherrschenden Trend ist auch Microsoft gefolgt, indem es Soap in seine erste Version des .NET-Frameworks integriert hat. Allerdings war der XML-basierende Datenaustausch bisher nur eine Option unter vielen - insgesamt konnten Entwickler unter .NET 1.x aus fünf völlig unterschiedlichen Anbindungsvarianten wählen.
Fünf Optionen
Wer beispielsweise einen einfachen, interoperablen Web-Service aufbauen möchte, dem bietet sich derzeit die Option ASP.NET (ASMX) - also eine klassische Web-Anwendung mit Server-seitig eingebetteter Programmlogik. Für die Verdrahtung von .NET-Client-Anwendungen im gewohnten Windows-Look-and-Feel (Windows Forms) kommt hingegen häufig das Protokoll .NET Remoting zum Einsatz. Falls Geschäftsanwendungen geplant sind und dabei Faktoren wie Transaktionssicherheit und Security im Vordergrund stehen, dann fällt die Wahl meist auf den COM+-Nachfolger Enterprise Services. Will man die neuesten Web-Service-Spezifikationen wie WS-Security oder WS-Adressing nutzen, müssen Programmierer bislang auf die Web Services Enhancements (WSE) zurückgreifen. Als fünfte Option schließlich steht noch Microsoft Message Queuing (MSMQ) bereit, das bei asynchronen Prozessen Verwendung findet.
Einheitliches Modell
Mit Indigo wollen die Redmonder einen Schlussstrich unter diese verwirrende Vielfalt ziehen und mit einem einheitlichen Schnittstellen- und Programmiermodell alle genannten Einsatzbereiche abdecken. Soap dient nun als allgemeingültiger Kommunikationsmechanismus für alle relevanten Interaktionsszenarien. Aus Sicht von Microsoft sind das folgende drei Varianten:
• Indigo-Anwendungen, die auf derselben Windows-Maschine in verschiedenen Prozessen laufen;
• Indigo-Anwendungen, die auf verschiedenen Windows-Rechnern laufen und Nachrichten austauschen;
• Indigo-Anwendungen, die mit Nicht-Windows-Plattformen kommunizieren, sofern diese auf Standard-Web-Services basieren - beispielsweise J2EE unter Linux, Solaris oder z/OS.
Da XML aber nicht nur Vorteile hat, sondern in Sachen Datenmenge und Verarbeitungsgeschwindigkeit binären Codierungen unterlegen ist, bietet Indigo alternativ auch die Verwendung eines binären Nachrichtenformats. Dessen Datenstruktur entspricht ebenfalls den Soap-Infoset-Konventionen. Entwicklern steht es offen, ihre Software um der Kompatibilität willen parallel mit beiden Kommunikationsmethoden auszustatten.
Kompatibilität ist natürlich auch ein Thema für jene Microsoft-Kunden, die bereits .NET-Anwendungen in Betrieb haben. Hierzu stellt die Gates-Company fest, dass allein die Installation der Indigo-Infrastruktur keine Beeinträchtigung für bestehende Anwendungen bedeute. Außerdem soll Indigo in vielen Bereichen reibungslos mit bisherigen .NET-Standards kooperieren. So sei beim Soap-basierenden ASP.NET (ASMX) die Interoperabilität prinzipiell gewährleistet. Programme, die via Enterprise Services kommunizieren, sollen sich "wrappen", also in Indigo-Schnittstellen einpacken lassen. Nach außen verhalten sie sich dann wie ein echter Indigo-Service. Zudem können auch bisherige MSMQ-Produkte problemlos integriert werden, da Indigo auf MSMQ basiert.
Grenzen von Indigo
Bei aller Plattformunabhängigkeit sind den Einsatzmöglichkeiten von Indigo aber auch klare Grenzen gesetzt, wie Microsoft selbst feststellt. So fokussiert das neue Framework ausschließlich den Bereich der direkten Kommunikation zwischen Web-Service-fähigen Applikationen. Die Anwendungsintegration via Enterprise Application Integration (EAI) bleibt somit außen vor. Überall dort, wo Daten von einem Geschäftssystem zum anderen per Mapping über Daten-Broker weitergereicht werden, sind weiterhin Lösungen wie Konnektoren oder Bussiness-Process-Management-Plattformen (BPM) nötig. (ue)