Vor den Applikationsservern wurden Dienste, die später in Applikationsservern zusammengefasst wurden als Middleware bezeichnet. Im Falle von Transaktionen als Service sind die prominentesten Produkte CICS ( Customer Information Control System) von IBM, Tuxedo von Oracle bzw. früher BEA und der MTS (Microsoft Transaction Server). Diese Systeme wurden als Transaktionsmonitor bezeichnet, nicht zu verwechseln mit einem Transaktionsmanager, der lediglich den transaktionellen Kontext bereitstellt. Solche Middleware gab es zunächst auf Mainframes für sogenannte OLTP-Anwendungen (Online Transaction Processing).

Jetzt muss ich wohl definieren was man denn unter einem Applikationsserver oder auch Anwendungsserver versteht. Dazu kurz Wikipedia konsultiert und dort findet man folgende Definition: “Ein Anwendungsserver (engl. application server) ist im Allgemeinen ein Server in einem Computernetzwerk, auf dem Anwendungsprogramme ausgeführt werden. Im engeren Sinne bezeichnet der Begriff eine Software, die spezielle Dienste zur Verfügung stellt, wie beispielsweise Transaktionen, Authentifizierung oder den Zugriff auf Verzeichnisdienste und Datenbanken über definierte Schnittstellen.”

Damit ist auch schon erklärt warum ich die Anwendungsserver in einer eigenen Folge meiner Blogreihe erklären möchte. Denn üblicherweise bietet ein Applikationsserver auch eine Schnittstelle um Transaktionen für die Anwendung auf einer höheren Abstraktionsebene zur Verfügung zu stellen.

Im Falle von Microsoft war das erste Release eines “Application Servers” das Windows NT 4.0 Option Pack, welches als Ergänzung zum Windows NT Server 4.0 kostenlos heruntergeladen werden konnte. Es war dann aber so , dass der Markt dies nicht so wahrgenommen hat,  weil dies eben nicht als “Application Server” vermarktet und beworben wurde. Wenn man damals von Application Servern redete, haben die meisten Leute an IBM WebSphere, BEA bzw. Oracle Weblogic, JBOSS usw. gedacht. Also war eigentlich fast automatisch J2EE  oder heute nur JEE bezeichnet (Java Enterprise Edition) im Spiel.

Aber zurück zur Microsoft bzw. Windows Plattform. Teil des Windows NT 4.0 Option Packs war auch der “Microsoft Transaction Server” (MTS), der das erste Mal Transaktionsdienste auf der Windows Plattform zur Verfügung stellte. Mit Windows 2000 war dies dann alles Bestandteil von COM+ in Kombination mit dem “Internet Information Server” (IIS) war dann ein Application Server komplett in Windows mitgeliefert.

Mit dem Applikationsserver änderte sich auch die gängige Architektur einer Business Anwendung. Bis dahin war Client-Server oder auch 2-Tier Architektur das vorherrschende Architekturmodell. Mit dem Einzug der Applikationsserver änderte sich dies zum 3-Tier Modell, wobei der “Middle-Tier” die Geschäftslogik implementiert in Komponenten für den Applikationsserver, darstellt. Ein Bild aus dieser Zeit, welches dies vereinfacht darstellt:

image

Diese Unterteilung hat sich im Prinzip bis heute nicht geändert. Allerdings haben sich natürlich die Technologien und die Kommunikationsmechanismen zwischen den einzelnen Schichten verändert. Früher war hier CORBA, Java RMI und COM+ sowie später .NET Remoting im Spiel. Aber da es sich um proprietäre Protokolle handelt, war es sehr schwierig hier plattformübergreifende Lösungen zu bauen. Erst mit SOAP und den damit verbundenen Web Services hat sich dies so geändert, dass man relativ einfach z.B. einen .NET Client für eine JEE Anwendung implementieren kann.

Hier noch ein Schaubild aus dem noch aktuellen .NET Application Architecture Guide (2nd Edition):

image

Wobei hier der “Middle Tier” nochmal in Service Layer, Business Layer und Data Layer unterteilt. wird. Aber auch in .NET wird eigentlich nie von einem Application Server gesprochen, obwohl alle Services von COM+ auch in .NET verfügbar sind und mit Windows Workflow Foundation (WF) und Windows Communication Foundation (WCF) noch weitere Services dazugekommen sind. Nichtsdestotrotz hat .NET in Kombination mit dem Windows Server also auch dem Internet Information Server alle Services eines Application Servers. Seit einigen Windows Server Versionen, gibt es im Server Setup auch die Möglichkeit die Server Rolle festzulegen und hier taucht dann auch offiziell der Begriff Application Server auf. Hier ein Screenshot von Windows Server 2008 R2:

image

Bevor ich dann im nächsten Blogpost meine bescheidenen Ergebnisse beim Testen der Transaktionsmethoden auf der Windows Plattform präsentieren möchte, will ich doch auch auf die offiziellen Tests des Transaktionsdurchsatzes einer Datenbank in Kombination mit einem Transaktionssystem hinweisen. Das Transaction Processing Council gibt solche Tests vor, die dann Datenbankhersteller in Zusammenarbeit mit Hardwareherstellern durchführen und die Ergebnisse dann dort zur Veröffentlichung einreichen können. Wenn es um Datenbaken geht sind eigentlich nur 2 Tests erwähnenswert.

1. TPC-C ist der ältere Test wo es auch viele Einreichungen gibt. Interessant finde ich hier, dass man keinen einzigen Java Application Server in der Spalte TP Monitor findet. (Ausnahme: Websphere Enterprise Edition 3, aber wenn man im Test nachschaut wurde dann doch Encina verwendet. Also der TP Monitor auf Unix den IBM gekauft hat und daraus dann CICS entwickelt hat). Dagegen findet man sehr oft COM+ !! Sogar bei Tests von IBM und Oracle. Das treibt mich zu der Schlussfolgerung, dass wenn es um Performance geht, COM+ nicht so schlecht sein kann Smiley.

2. TPC-E ist ein neuerer Test, wo Microsoft SQL Server auch an der Spitze steht, was allerdings keine große Kunst ist, da es bis heute keine Einreichung eines anderen Datenbankherstellers zu diesem Test gibt. Microsoft hat sich entschlossen diesen Test zu verwenden, da er realistischer heutige Szenarien modelliert, als dies mit TPC-C der Fall ist. Wenn die Unterschiede genau interessieren kann das hier nachlesen.

 

Viele Grüße

Euer Martin