Sie sind hier: Lexikon/Glossar
Logo der Firma www.IT-Visions.de
MENU

Erklärung des Begriffs: Windows Application Server (WAS)

Werbung
Begriff Windows Application Server
Abkürzung WAS
Eintrag zuletzt aktualisiert am 24.11.2022

 Zur Stichwortliste unseres Lexikons

Was ist Windows Application Server ?

Die Bezeichnung Windows Application Server hat bei Microsoft eine lange, bewegte Geschichte. Stand Januar 2009 ist Windows Application Server kein konkretes Microsoft Produkt. Auch gehört die Abkürzung "WAS" nicht zu "Windows Application Server", sondern "Windows Process Activation Service" (ab Windows Vista enthalten).

Transaction Server statt Application Server

Das erste Produkt, das eigentlich den Namen "Windows Application Server" verdient gehabt hätte, war der Microsoft Transaction Server (MTS), der mit dem Windows NT 4.0 Option Pack im Jahr 1998 erschienen ist. Der MTS war ein Host für Dienste, die von COM-basierten Softwarekomponenten angeboten wurden. Er bot verteilte Transaktionunterstützung, Sicherheitskonfiguration bis auf Methodenebene, Protokollierung, Packetierung und Mechanismen zur Skalierbarkeit (Object Pooling und Just-in-Time-Activation). Er war (bis auf die fehlende Objektpersistenzunterstützung) dem ebenbürtig, was die Java Enterprise-Welt einen Application Server nannte. Aber der MTS durfte eben in Microsofts Denke nicht "Application Server" heißen. Auch die nachfolgende Version hieß nicht so, sondern COM+ und ist seit Windows 2000 fester Bestandteil jeder Windows-Version.

Von MTS über COM+ zu Enterprise Services

Als dann .NET erschien, klebte Microsoft ein neues Etikett auf COM+: ".NET Enterprise Services" hieß das unveränderte System fortan aus der Sicht von .NET. Man kann .NET-Komponenten in COM+ hosten, aber auf Kosten der ständig notwendigen Interoperabilitätsaufrufe zwischen der COM-Welt und der .NET-Welt. Es verwunderte sehr, dass Microsoft keinen in .NET geschrieben Application Server anbot (wo man doch ansonsten Java so viel nachgemacht hatte). Für das Hosting von ASP.NET-basierten Webservices war der Internet Information Server (IIS) eine gute Lösung. Aber für nicht HTTP-basierte .NET Remoting-Dienste redete Microsoft nur von "self-hosting", was auf deutsch so viel hieß, dass sich der Entwickler selbst einen Application Server schreiben musste.

Auch mit .NET 1.1 und 2.0 gab es hier nichts. Stattdessen einigte man sich in Redmond auf die Marketing-Floskel, dass man keinen Application Server brauche, denn Windows enthalte schon alles, was andere Hersteller als teure Extras anböten. Manche Leute in Redmond setzten auch immer den IIS mit Application Server gleich und konnten sich einfach nicht vorstellen, dass es Leute gibt, die nicht über HTTP kommunizieren wollen. Diese Strategie kritisiert auch die Gartner Group: "Microsoft does not identify ist Enterprise Application Server capability as a distinct product. Technology representing the functionality of an EAS is spread across several products, confusing some users and complicating competitive positioning against Java EAS vendors." [http://mediaproducts.gartner.com/reprints/microsoft/vol3/article2/article2.html].

Tatsächlich haben wir mit .NET 2.0 gesehen, dass Microsoft die verteilte Transaktionsunterstützung nun auch außerhalb von COM+ anbot im Namensraum "System.Transactions". Und mit .NET 3.0 gab es dann durch die Windows Communication Foundation (WCF) auch wieder Sicherheitskonfigurationen auf Methoden, Skalierbarkeitsfeatures und Protokollierung. Aber was es nicht gab, war ein vorgefertigter Hostingprozess, eine Verwaltungskonsole und Packetierung. Auch in .NET 3.5 gab es keine Lösung.

Windows als Application Server

Vielmehr hatte Microsoft zwischenzeitlich den Begriff "Application Server" anderweitig ver(sch)wendet. Im Windows Server 2003 ist "Application Server" der Oberbegriff für einige Installationsoptionen des Windows-Betriebssystemes (siehe Systemsteuerung/Software/Windows-Komponenten). Dazu gehören der IIS, ASP.NET und Microsoft Message Queuing. Die "Application Server Console" war auch nur ganz alter Wein unter neuem Etikett: Hier fand man lediglich die Management-Konsole für COM+, die Verwaltung von Benutzern und Computern im Active Directory, den "Event Viewer" und die Steuerkonsole für Systemdienste. In Windows Server 2008 geht es noch weiter, denn dort ist "Application Server" eine Rolle des Betriebssystems. Neben den vorgenannten Bausteinen gehören dort auch .NET 2.0/3.0 und COM+ zu dem Begriff "Application Server".

Ebenfalls in diese Historie passt WAS. WAS steht für Windows Process Activation Services und ist ein allgemeiner Hosting-Prozess für WCF-Dienste als Verallgemeinerung des IIS. Der IIS öffnete sich damit für andere Protokolle wie TCP und Named Pipes. WAS gibt es in Windows Vista und Windows Server 2008 und befreit den Entwickler zumindest davon, einen eigenen Server-Prozess schreiben zu müssen. Hier hätte Microsoft noch einmal eine Chance gehabt, WAS für "Windows Application Server" verwenden zu können.

Ein Umdenken war erstmal auf der TechEd 2007 zu spüren als Steve Swartz und Clemens Vasters (den man hier in Deutschland noch als Prediger für COM+ kannte bevor er die "blaue Pille" schluckte und nach Redmond umzog) die Anforderungen an einen modernen Application Server skizzierten. Dabei hörte der interessierte Besucher dann wieder von eigenen Verwaltungskonsolen, Serverfarmen, Lastverteilung, der Überwachung durch Microsoft System Center und der Frage des Deployments. Das ganze vernahm man im Zusammenhang mit dem kommenden SOA-Produkt "Oslo."

Jetzt führt die Reise nach Dublin

Die "Dublin"-Katze ließ Microsoft dann schon kurz vor der Professional Developer Conference (PDC) 2008 Anfang Oktober aus dem Sack. Die norwegische Hauptstadt ist Oslo jetzt "nur" noch die Modellierungsplattform und die Laufzeit wird den Iren überlassen. Metaphorisch gesprochen wäre "Irland" dabei das Entwicklungsteam des IIS, das die Aufgabe bekam, den IIS für WCF und die Windows Workflow Foundation (WF) weiter zu öffnen. So erklärt sich dann auch, dass "Dublin" im Wesentlichen eine Erweiterung des IIS und seiner Verwaltungskonsole ist.

Während einerseits schon von "Windows Application Server" als Produktname zu lesen war, gab es auf der anderen Seite die Aussagen, dass das endgültige Produkt den eher kantigen Produktnamen "Windows Application Server Extensions for IIS" erhalten soll, um die bisherige Strategie, dass ja Windows Server selbst der Anwendungsserver sei nicht vollends zu konterkarieren. Mit der Nähe zum IIS läuft Microsoft aber Gefahr, Kunden abzuschrecken. Denn es gibt (große) Unternehmen, bei denen steht der IIS seit Nimda, Code Red & Co auf der roten Liste. "Suchen Sie sofort nach Alternativen zum IIS!" sagte die Gartner Group damals [http://www.tecchannel.de/news/themen/business/409292/gartnerempfiehlt_wegen_nimda_apache_stattiis/]. Zwar hat der IIS sich seitdem gebessert, aber mancherorts sind die Vorbehalte geblieben. In der aktuellen Vorabversion von Dublin, die auf der Professional Developer's Conference (PDC) 2008 als Virtual-PC-Image verteilt wurde (siehe auch Kasten "Aktuelle Version"), findet man immer wieder den Namen "Process Server" als interne Bezeichnung, z.B. in den dem .NET-Namensraum (Microsoft.ProcessServer), den PowerShell-Snap-Ins und schließlich auch im Setup-Programm.

Beratung & Support

Schulungen

  Anfrage für eine individuelle Schulung zum Thema WINDOWS APPLICATION SERVER WAS   Gesamter Schulungsthemenkatalog