Neue Exchange-Programmierschnittstellen

In den vergangenen Jahren haben sich die technischen Gegebenheiten für die Softwareentwicklung im Windows-Bereich durch die Einführung der .NET-Technologie stark gewandelt. Dies wird sich in den kommenden Jahren weiter fortsetzen, da zunehmend Produkte auf den Markt kommen, die auf .NET zurückgreifen oder zumindest auf diese Technologie ausgerichtet sind. Im Bereich System- und Unternehmenssoftware kommen weitere Neuerungen auf die Anwender zu, wie beispielsweise die neue Kommandozeilenumgebung MSH beziehungsweise Monad, die speziell das administrative Scripting neu gestalten wird.

Entwickler im Exchange-Bereich werden diese Entwicklung wohl mit einem lachenden und einem weinenden Auge betrachten. Einerseits war die API-Unterstützung für Exchange immer recht komplex und lückenhaft. Auf der anderen Seite erfordert der Schritt zu anderen Programmierschnittstellen einen beachtlichen Lernaufwand und reduziert erst einmal den Wert des vorhandenen Know-hows.

E12 steht ganz im Zeichen der genannten Umstrukturierung der vorhandenen Programmieransätze. Da mit der neuen Software gleichzeitig ein großer Versionsschritt vollzogen wurde, nutzt Microsoft die Gelegenheit, einigen alten Ballast loszuwerden. Exchange 12 unterstützt dann eine Reihe neuer Programmiermodelle, verschiedene alte APIs werden aber dafür nicht mehr weiter enthalten sein. Einige andere ältere Schnittstellen werden als so genannte „deemphasized technologies“ eingestuft. Diese Bereiche bleiben zwar in der nächsten Version enthalten, werden zukünftig aber nicht mehr weiterentwickelt. Im nächsten großen Versionsschritt werden sie dann ebenfalls nicht mehr enthalten sein. Das bedeutet letztendlich, dass diese APIs bei Neuentwicklungen nach Möglichkeit vermieden werden sollen, weil sie zukünftig nicht mehr unterstützt werden.

Nicht mehr unterstützte API	Wird ersetzt durch
ExWin32,ExIFS	Web Services
EDK Gateway	Managed Agents
Transport Event Sinks	Managed Agents
Routing Objects	Managed Agents
Exchange 5.5 Event Service	Managed Agents
CDOExM	Monad-Skripts
WMI-Klassen	Monad-Skripts
Queue Viewer	Monad-Skripts
Backup/Restore (ESEdbcli2)	Monad-Skripts
CDOWF, Workflow Designer	Windows Workflow Foundation
Web Forms	ASP.NET

Neues Konzept

Exchange ist im Grund ein System, dessen relativ kompakte Struktur erst in den letzten Versionen durch die Einführung von Rollen etwas aufgebrochen wurde. Hierdurch ist eine gewisse Modularität entstanden. Real besteht Exchange aus einer Reihe unterschiedlicher Komponenten, die entwicklungstechnisch eine ganz unterschiedliche Historie aufweisen, beispielsweise der X.400-MTA, der SMTP-Dienst oder die Webkomponenten. Die Schnittstellen dazwischen sind deshalb eher ad hoc entstanden und nicht besonders gut aufeinander abgestimmt. Die APIs für Entwickler anderer Firmen sind vielfach ohne Blick auf das heutige Gesamtkonzept entstanden. Viele der Schnittstellen stammen noch von anderen Produkten, wie beispielsweise Simple MAPI, welches bereits mit MS Mail 3.0 im Jahre 1992 eingeführt wurde.

Ziel bei der Entwicklung von Exchange 12 war eine modulare Neukonzeption des Systems, bei der die Schnittstellen zwischen den Komponenten besser aufeinander abgestimmt sind. Exchange12 wird aus einer größeren Anzahl von Modulen bestehen, die sich mit unterschiedlichen Konfigurationen an verschiedene Rollen anpassen lassen. Die Schnittstellen zwischen den Modulen sollen idealerweise auch diejenigen sein, die externen Entwicklern zur Erweiterung des Systems zur Verfügung stehen. Die hierbei bereitgestellten APIs sollen sich auf die Kernfunktionen von Exchange beschränken und keine Komponenten unterstützen, die schon durch andere Schnittstellen abgedeckt sind.

Um diesem Ziel gerecht zu werden, wurden oder werden eine ganze Reihe von Exchange 12- Teilen mit so genanntem Managed Code, das heißt Programmteilen, die .NET verwenden, neu geschrieben. Insbesondere werden viele Mailfunktionen in den gerne mit .NET verwendeten Web Services zur Verfügung stehen. Außerdem wird E12 eigene Monad-Objekte beinhalten, die die Verwaltung des Servers stark vereinfachen sollen. Insbesondere für die Monad-Umgebung gilt diese Vereinfachung aber erst nach einiger Einarbeitungszeit, die notwendig ist, um sich mit der neuen Technologie vertraut zu machen.

Monad-Skripts

Die vielleicht wichtigste Änderung innerhalb der kommenden Systemsoftware-Versionen, dürfte für Administratoren die Einführung der neuen Verwaltungsumgebung mit Codenamen „Monad“ sein. In diesem Zusammenhang wird auch oft die neue Kommandozeile Microsoft Shell (MSH) genannt. Im Grunde genommen handelt es sich

hierbei allerdings um zwei verschiedene Dinge. Monad ist eine objektorientierte Funktionsbibliothek, die grob der WMI-Umgebung entspricht, die sie ersetzen wird. Die neue Kommandozeile wird als eigenes Programm darauf aufsetzen. Sie entspricht damit ungefähr der Windows Scripting-Umgebung WSH.

Listing 1a: Abfragen von Postfachstatistiken mit WMI
Set listExchange_Mailboxes = _
GetObject("winmgmts:{impersonationLevel=impersonate}!\\COMPUTERNAME\ROOT\MicrosoftExchangeV2").InstancesOf("Exchange_Mailbox")
For Each objExchange_Mailbox in listExchange_Mailboxes
WScript.echo "AssocContentCount =” + _
objExchange_Mailbox.AssocContentCount
...
WScript.echo "TotalItems =” + _
objExchange_Mailbox.TotalItems
Next

Listing 1b: Abfragen von Postfachstatistiken mit Monad
get-mailboxstatistics -server $servername

WSH ist nur eine mögliche Art und Weise, auf die WMI-Funktionen zuzugreifen. Analog ist auch Monad unabhängig von MSH. Monad-Anwendungen lassen sich auch mit allen .NET-Programmiersprachen erstellen. C# und Visual Basic gehören hier genauso dazu wie Perl oder Python. Insbesondere wird auch die Microsoft Management Console (MMC) ihre Verwaltungsaufgaben über neue Snap-Ins mittels Monad vollziehen können. Auch der System-Manager von Exchange 12 wird voraussichtlich auf Monad basieren.

Genau wie bei WMI erfolgt auch bei Monad die Einbindung der verwaltbaren Systemkomponenten über Treiber und so genannte Namespaces. Die Funktionen, die Monad für diese Komponenten bereitstellt, zum Beispiel new-mailbox, werden auch als „Cmdlets“ bezeichnet.

Der Hauptgrund für die Entwicklung von Monad dürfte die Bereitstellung eines .NET-basierten Gegenstücks zur WMI-Technologie gewesen sein. WMI beruht auf COM-Objekten und damit auf Unmanaged Code, der nicht von den Vorteilen der .NET-Laufzeitumgebung profitiert. Die Struktur der Systemarchitektur wurde bei Monad vom Vorgänger WMI wie gezeigt übernommen. Gerade bei der Erstellung von Skripts in der MSHKommandozeile zeigt sich aber, dass Microsoft viel Mühe darauf verwendet hat, die Schnittstelle zu vereinfachen. Die Komplexität, die viele Anwender von WMI abgeschreckt hat, ist deutlich verringert worden.

Listing 2a: Erstellen eines Postfachs mit VBScript
objMailbox As CDOEXM.IMailboxStore
Set objMailbox = _
GetObject("LDAP://..,CN=users," + DomainName)
objMailbox.CreateMailbox _
"LDAP://...,CN=First Storage Group,..."

Listing 2b: Erstellen eines Postfachs mit MSH
new-mailbox –id domainSer –database
“First Storage Group\Private MDB”

Während beispielsweise zur Abfrage der wichtigsten Informationen der vorhandenen Exchange-Postfächer ein komplizierter Aufruf eines WMI-Objekts nötig war, bei dem die einzelnen Informationen explizit abgefragt werden mussten, reicht bei MSH ein Befehl mit Angabe des Servers (Listing 1a und 1b).

Die Anlage eines Postfachs demonstriert, wie Monad die parallele Verwendung mehrerer Schnittstellen unnötig macht. Wenn dieser Vorgang heute mit VBScript programmiert wird, müssen in den wenigen Zeilen CDOExM, ADSI und LDAP miteinander kombiniert werden. In Monad reicht wiederum eine Zeile. In dieser müssen nur noch die unbedingt notwendigen Informationen übergeben werden, nämlich die Postfach-Datenbank, auf der das Postfach angelegt werden soll, und der Benutzer, mit dem das Postfach verbunden wird. Die komplexe X.500-Adressierung entfällt dabei.

Es sollte aber nicht übersehen werden, dass die heute von Microsoft präsentierten Beispiele durchaus mit der Absicht ausgewählt sind, die neuen Technologien in positivem Licht erscheinen zu lassen. Wenn beispielsweise für ein Überwachungsskript bestimmte Eigenschaften eines Postfachs abgefragt werden sollen, dann müssen diese Angaben im Zweifelsfall als Parameter mit übergeben werden. Ein einzelner Befehl mit verschiedenen Kommandozeilenparametern und mehr als 100 Zeichen Länge ist aber genauso unübersichtlich wie ein strukturiertes WSH-Skript mit 15 oder 20 Befehlszeilen. Hier muss sich das Gespann Monad und MSH erst noch im Alltagsbetrieb beweisen.

Deempasized API

CDO 1.2.1
CDOEx
CDOSYS
ExOLEDB
WebDAV, OWA URL-Aufrufe
Store Events

SMTP-Dienst

Als Exchange entwickelt wurde, wurde in der Messaging-Welt an der Ablösung von SMTP gearbeitet. X.400 galt damals als das Protokoll der Zukunft, welches als Basis von Exchange hergenommen wurde. Durch den Siegeszug des Internets gelang SMTP aber ein Comeback, und heute ist es das dominierende Protokoll. Dementsprechend war der SMTP Connector ursprünglich nur als Zusatz erhältlich. Mit den 2000er Versionen von Exchange basierte die SMTP-Übertragung dann im Kern auf dem SMTP-Dienst des Internet Information Server, war also immer noch eine Art Zusatzkomponente. Mit Exchange 12 soll dieser Teil nun komplett überarbeitet werden und bekommt dabei auch vollkommen neue Schnittstellen. Die Transport Event Sinks des SMTP-Dienstes gehören damit der Vergangenheit an. An deren Stelle tritt die neue Transport Agent API.

Ähnlich wie heute in CDO wird es auch bei der neuen API mehrere Zugriffsmöglichkeiten auf eine E-Mail in verschiedenen Abstraktionsebenen geben. Übliche Nachrichtenbestandteile, wie Kalender und Kontakte werden wohl als eigene Nachrichtenobjekte verfügbar sein, auf die auch ein Low-Level-Zugriff möglich ist.

Nachrichtenspeicher

Heute ist der Zugriff auf in Exchange gespeicherte Nachrichtenobjekte auf verschiedene Schittstellen wie MAPI, CDO und WebDAV möglich. Die Programmierung ist teilweise auf verschiedene Arten gleichwertig möglich, wobei eine geringe Änderung des Konzepts aber einen Wechsel der Schnittstelle erfordern kann. In Exchange 12 sollendiese Schnittstellen, jedenfalls soweit es sich um serverseitig gespeicherte Nachrichten handelt, durch eine Web Service-API ersetzt werden. Dies wird wohl auch zu einer Neuprogrammierung von Outlook Web Access (OWA) führen, da WebDAV als Basis des heutigen OWA ebenfalls als „deemphasized“ eingestuft ist.

Web Services sind ein seit längerem etabliertes Programmierkonzept und Kernbestandteil von .NET. Sie stellen Funktionsaufrufe auf einem entfernten Rechner dar. Die Beschreibung inklusive der notwendigen Parameter wird in Form einer XML-Datei über das Webprotokoll HTTP an den Server übermittelt. Web Services sind speziell für den Programmierzweck entwickelt. Visual Studio .NET bietet heute vielfältige Unterstützung für die Entwicklung von Anwendungen, die auf Web Services zugreifen.

Das bislang verwendete WebDAV-Protokoll ist hingegen eine immer stärker verbogene Variante des Übertragungsprotokolls HTTP. Entwickler müssen sich deshalb zurzeit mit durch lange URLAdressierung kaum durchschaubaren Programmtexten abkämpfen und finden in den Entwicklungsumgebungen nur wenig Unterstützung für diese Art der Programmierung. Die Entwicklung von Messaging-Anwendungen auf Basis von Web Services sollte sich deshalb mit E12 deutlich einfacher gestalten.

Zusammenfassung

Die kommende Version von Exchange wird nicht nur für die Anwender, sondern vor allem für die Entwickler größere Veränderungen mit sich bringen. Eine Reihe von vertrauten Programmierschnittstellen wird komplett eingestellt oder nur noch aus Kompatibilitätsgründen mitgeschleppt werden. Hierzu zählen auch einige, die erst mit den 2000er-Versionen neu eingeführt wurden. Hintergrund hierfür ist, neben einer Neustrukturierung des Produkts, die Anpassung an neue Technologien, die mit Windows Vista eingeführt werden (Monad/MSH), sowie die Ausrichtung der APIs auf das .NET-Framework und Managed Code.

Entwickler sollten auf diesem Weg einen besser strukturierten Zugriff auf die Server-Funktionen erhalten. Zudem bringt beispielsweise die Einführung von Web Services eine bessere Unterstützung auf Seiten der Programmierwerkzeuge mit sich. Erkauft wird dies allerdings mit einem beträchtlichen Umlernbedarf und zwischenzeitlichem Verlust von anwendbarem Know-how.