Microsoft: Indigo

Ebenfalls Bestandteil des WinFX Frameworks und damit auch der kommenden Windows-Version mit dem Codenamen „Longhorn” ist die Kommunikationsinfrastruktur und Entwicklungsframework „Indigo”. Dieses stellt eine Vielzahl an Schnittstellen und Diensten zur Verfügung, damit Entwickler schnell und einfach Applikationen schreiben können, die Mitteilungen senden, empfangen und verarbeiten können – egal nach welchem Protokoll oder über welches Medium.
Microsoft hat sich bei der Entwicklung von Indigo vor allem die Vereinfachung der Programmierung auf die Fahnen geschrieben, ist doch die Entwicklung von kommunikationsorientierten Lösungen mit den bestehenden Frameworks relativ umständlich. Um dies den Entwicklern zu erleichtern, hat sich Microsoft dazu entschlossen, ein Service-orientiertes Programmiermodell zu entwickeln.
Einer der großen Vorteile von Indigo ist, das es daher ein einheitliches Programmiermodell und einen einheitlichen Stack für alle Remoting-Technologien der CLR (Common Language Runtime) bietet. Durch die Kombination von .NET Remoting, ASMX, System.Messaging und den .NET Enterprise Services in einem Framework können Entwickler Features wie deklarative Transaktionen oder XML-Schema basierte Serialization nutzen.

Hinzu kommt, dass Indigo neben den klassischen Netzwerk-Transportprotokollen wie HTTP, TCP oder UDP auch „lokale Protokolle” wie IPC versteht. Um mit einem Dienst über das Netzwerk anstatt lokal mittels IPC zu kommunizieren, ist im Sourcecode fast nichts zu ändern. Daneben unterstützt Indigo auch verschiedenste Netzwerktopologien. Neben der klassischen Punkt-zu-Punkt und Punkt-Proxy-Punkt-Verbindung kann Indigo auch Peer-To-Peer und Publish-Subscribe Topologien unterstützen. Nachdem Sicherheit vor allem im Netzwerkbereich groß geschrieben wird sind natürlich auch alle klassischen Sicherheitsfeatures wie Verschlüsselung mittels öffentlicher und symetrischer Schlüssel sowie Zertifikate in Indigo implementiert.

XML und SOAP, die beiden Schlüsselbestandteile der Web Services, werden, nachdem Web Services bei Microsoft und natürlich besonders in den neuen Produkten wie Office 2003 und Longhorn essentiell sind, ebenfalls über Indigo unterstützt. Damit wird die Entwicklung von Web Services oder Programmen, die Daten von Web Services konsumieren, deutlich einfacher. Mit Indigo ist Microsoft aber auch schon für die kommenden, erweiterten Web Services, an deren Spezifikation der Konzern ja engagiert mitarbeitet, auch schon bestens gerüstet. Zusätzliche Sicherheitsfeatures, eine verbesserte Verlässlichkeit und Transaktionsfähigkeit zeichnen XML und SOAP unter Indigo aus.

Verfügbarkeit

Im Gegensatz zu Avalon und WinFS, die höchstwahrscheinlich erst mir Longhorn offiziell verfügbar sein werden, wird Indigo nicht nur in Longhorn, sondern auch für Windows XP und Windows Server 2003 als eigener Download verfügbar sein. Was durchaus sinnvoll ist, wird dadurch die Service-orientierte Entwicklung von Applikationen für den Windows Server 2003 und XP deutlich einfacher. Einige spezielle Features von Indigo werden aber trotzdem nur in Longhorn verfügbar sein, sind diese doch wahrscheinlich zu eng an die Features von Avalon und WinFS gebunden.

Service orientiert

Bei der Entwicklung von Indigo, das für die Entwicklung von kommunikationsorientierten Applikationen – und welche sind das heutzutage nicht? - einiges vereinfachen wird, hat sich Microsoft an den Lektionen orientiert, die aus der langjährigen Praxis mit Komponenten-orientierter Software, Messaging-orientierter Middleware und der verteilten objektorientierten Programmierung gelernt hat.
Eine Serviceorientierung unterscheidet sich von der Objektorientierung prim’r dadurch, wie der Begriff „Applikation” definiert wird. Während sich die objektorientierte Entwicklung auf die Applikationen konzentriert, die aus mehreren, voneinander abhängigen Klassen konzentriert, sieht die serviceorientierte Entwicklung eine Applikation eher als eine Gruppe von autonomen Diensten, die über Messages miteinander kommunizieren und so die Aufgabe erledigen.

Diese beiden Begriffe entscheiden sich fundamental voneinander, wobei die serviceorientierte Sichtweise eher dem entspricht, was man bereits heute vorfindet, bzw. was sich in den nächsten Jahren entwickeln wird. Die Abwendung von den monolithischen Applikationen hin zu locker gebündelten Diensten, die erst durch eine Applikation in der Mitte, die alle Dienste bündelt, ihren wahren Wert offenbaren.

Die einzelnen Dienste sind so ausgerichtet, dass sie einerseits stabil und verlässlich sind, andererseits auch flexibel für Veränderungen sind. Gerade bei Web Services ist es, zumindest jetzt noch so, das sich deren Wert erst nach einiger Zeit zeigt, wenn auf einmal eine Applikation auftaucht, welche die Daten des Webservices auf eine neue, innovative und sinnvolle Art und Weise nutzt – der Nutzen eines Web Services vergrößert sich also mit der Zeit und bei der Entwicklung sollte man darauf Rücksicht nehmen.
Vier Eckpfeiler gibt es bei der serviceorientierten Entwicklung zu berücksichtigen.

Grenzen

Die einzelnen Dienste einer serviceorientierten Applikation können über weite Entfernungen, verschiedenste Zugriffskontrollen und Umgebungen getrennt sein. Da es – wenn man die benötigte Zeit, Komplexität und Ressourcen berücksichtigt – recht kostspielig ist, diese Grenzen zu überwinden, muss man bereits beim Design auf diese Beschränkungen Rücksicht nehmen, was sich im Normalfall durch einfachere, klarere und kleinere Schnittstellen bemerkbar macht. Die Kommunikation erfolgt über explizite Messages und nicht über den impliziten Aufruf einer Methode, wie es beim objektorientierten Ansatz gerne gemacht wird.

Diese Grenzen machen sich auch bei der verteilten Entwicklung einer Applikation bemerkbar. Durch die explizite Abschottung der einzelnen Dienste ist der Kommunikationsbedarf zwischen den Entwicklern einzelner Dienste relativ gering, was auch die Entwicklungskosten gering hält und den Prozess beschleunigt.
Einfachheit und Vielseitigkeit sind die Grundlegenden Merkmale, die eine serviceorientierte Applikation auszeichnen.

Autonomität

Klassische, objektorientierte Applikationen werden im Normafall als eine große Einheit ausgeliefert. Muss etwas an einem Teilbereich geändert werden, muss man wieder die komplette Applikation ausrollen.
Dienste spiegeln eher das wahre Leben wieder, es gibt keinen zentralen Punkt, der die Oberhoheit über ein System hat.

Das spiegelt sich auch bei der Verteilung einer serviceorientierten Applikation aus. Auch wenn sich ein Dienst längere Zeit nicht ändert, so ist doch der Gesamtzustand des Systems kaum länger „stabil”, was aber in diesem Zusammenhang nichts schlechtes ist. In einem serviceorientierten System können die einzelnen Dienste jederzeit ausgetauscht oder erweitert werden, ohne dass das Gesamtsystem darunter leidet. So kann eine darauf basierende Applikation schnell auf Änderungen reagieren, muss im Idealfall ja nur ein Dienst und das Benutzer-GUI aktualisiert werden.

Da diese Dienste autonom agieren, müssen auch Fehler anders als bisher abgehandelt werden – zu, Vorteil des Benutzers. Einerseits lassen sich Dienste durch Transaktionen und Clustering ausfallssicher machen, andererseits muss die Applikation auch elegant mit Fehlern umgehen können.
Dadurch, das die Mitteilungen in einer serviceorientierten Applikation oft über das Internet oder andere öffentliche Netze übertragen werden, muss eine serviceorientierte Infrastruktur wie Indigo auch entsprechende Ressourcen zur Verfügung stellen, damit die Validität der Messages überprüft werden kann. Dadurch entstehen auch sicherere Applikationen, muss der Entwickler nun doch im Bewusstein agieren, dass alles, was in seiner Applikation einlangt gefälscht und/oder gefährlich sein kann.

Abstraktion

Dienste beschäftigen sich nicht mit Klassen an sich. Die stellen ihre Schnittstellen in Form von Schemas (für Strukturen) und Verträgen für ihr verhalten zur Verfügung. Diese strenge Trennung von Struktur und Verhalten vereinfacht die Entwicklung und macht die Installation wesentlich einfacher als bei einem klassischen Programm.
Da die Definition dessen, was ein Service senden und empfangen kann maschinenlesbar ist, wird die Schnittstelle wesentlich einfacher und klarer und kann sogar automatisch überprüft werden, was zu sichereren Applikationen führt.

Kompatibilität

Im serviceorientierten Design wird, im Gegensatz zur objektorientierten Sichtweise, zwischen semantischer und struktureller Kompatibilität unterschieden. Während sich die strukturelle durch Schema und Vertrag auch maschinell überprüfen lässt, müssen für die semantische Kompatibilität explizite Aussagen über die Fähigkeiten und Bedingungen in Form von Regeln bestimmt werden.

Diese maschinenlesbaren Regeln bestimmen, welche Bedingungen und Garantien gegeben werden, damit ein normaler Betrieb des Dienstes gewährleistet wird. Dadurch wird die Kompatibilität nochmals verbessert und auch maschinell überprüfbar, was wiederum zu besseren, stabileren Appliaktionen führt.

Indigo

Wie passt nun Indigo in dieses Modell? Die primären Subsysteme von Indigo sind das „Indigo service model”, der „Indigo connector”, die „Hosting environments” und die „System and messaging services”.
Kernstück des ganyen ist aber der „Indigo Connector”, der ein manged Framework für sichere, messagebasierte Kommunikation bietet. Auf der Basisi von Ports, Messages und Channels stellt der Indigo Connector ein auf SOAP basierendes, vielschichtiges Framework zur Verfügung, das es erlaubt messagebasierte Applikationen zu schreiben, die unabhängig von der Transporttechnologie und der Zielplattform sind. In der Keynote auf der PDC wurde zum Beispiel gezeigt, wie man mit wenigen Änderungen die Kommunikation eines Dienstes von einem Web Service auf den Statusbar von Longhorn umdirigieren kann.

Fazit

Indigo und die Ausrichtung auf das serviceorientierte Entwicklungsnmodell sind sicherlich wichtige Punkte in Microsofts Bestreben, den Entwicklern das Leben zu vereinfachen. Da Indigo, zumindest in Teilen, auch für Windows XP und den Windows Server 2003 kommen wird, werden wir uns sicherlich noch öfter mit dieser äußerst interessanten Technologie beschäftigen dürfen.

Indigo

WinFS	Yukon	Indigo
Dies ist der Name des neuen Storage-Systems für Windows Longhorn, das über die normale Dokument-orientierte Betrachtungsweise eines Filesystems hinausgeht. Durch die Integration von Datenbanktechnologien kann man nun auf verschiedenste Weise Informationen suchen, anzeigen und bearbeiten. Durch XML-Schemas ist es leicht erweiterbar und bietet so nette Features wie eine gemeinsame Kontakt-Datenbank für alle Applikationen und „Agenten” kümmern sich darum, dass die Benutzer nicht mit Informationen überflutet werden.	Yukon ist der Codename für die langerwartete neue Version des Microsoft SQL Servers, in die Microsoft viel Zeit und Geld investiert hat. Mit Yukon und der kommenden Visual Studio Version mit dem Codenamen „Whidbey” ändert sich einiges für Entwickler, die auch auf Datenbanken zugreifen wollen/müssen.	Indigo ist die Basis für die Kommunikation unter Longhorn. Egal ob zwischen Applikationen, zwischen PCs oder zwischen PC und WebService – die Kommunikation erfolgt über Indigo. So kann man über Indigo Daten eines WebServices abrufen oder an ein solches schicken, aber auch Transaktionen durchführen. Gezeigt wurden aber auch Beispiele, wie man aus einer Applikation heraus Daten im Sidebar anzeigen kann oder einen „Videostream” des eigenen Dekstops an einen anderen PC senden kann. Aber auch Instant Messaging oder Datenaustausch über ein Peer-to-Peer Netzwerk wird in Longhorn über Indigo abgewickelt.
Avalon	Whidbey	.NET
Avalon ist der Name für die GUI-Klassen bzw. das GUI-Framework für das neue Betriebssystem. Neben vielen neuen Controls ist vor allem das Compositing - also das einfache überlagern von mehreren Elementen zu einem neuen - eines der herausragensten Merkmale in Avalon. Hinzu kommt, dass die Oberflächen mit XAML, einer XML-basierten Auszeichnungssprache, definiert werden, was völlig neue Möglichkeiten eröffnet. Hinzu kommt noch der One-Klick-Install, der auch schon mit der nächsten Visual Studio Version kommen soll, mit dem sich Applikationen ganz einfach von einer Webseiten installieren lassen sollen.	Die Verbesserungen in Whidbey, der Entwicklungsumgebung Visual Studio, sind vielfältig. Bereits lange vor Longhorn wird Whidbey die Technologien und Tools zur Verfügung stellen, dass Entwickler ihre bestehenden oder geplanten Applikationen auf die kommende Windows-Version und die damit verbundenen Änderungen (WinFX) anpassen können. Neben technischen Features wie „partial types”, C++ with CLR types und anderen Verbesserungen die Hardcore-Programmierer erfreuen werden, legt Whidbey vor allem auch auf die Verbesserung für den „Gelegenheitsprogrammierer” bzw. auf Verbesserungen, welche die Produktivität der Entwickler verbessern, wert.	Bill Gates, seines Zeichens reichster Mann der Welt und bald auch Knight Commander of the British Empire, begrüßt morgen, am 28.1.2004 rund 1.500 Entwickler zum Microsoft .NET DAY. Dieses IT-Ereignis, man kann es durchaus so nennen, findet im Austria Center Vienna statt und gilt als Wegweiser im Software-Bereich, zumindest wenn man sich in der Fensterwelt bewegt. Bill Gates wird freilich auch Longhorn, den Windows XP-Nachfolger ansprechen. WCM berichtete schon ausführlich über die Kernkomponenten Avalon, Indigo und WinFS, nun werden wir hoffentlich noch ein paar Neuigkeiten erfahren, außer dass es viel verändern und alles besser wird