Analyse und Vergleich von Applikations-Servern und ihren zugrundeliegenden Technologien

vorgeführt. Wesentlich einfacher ist das Wechseln der Plattform (z.B. von Windows zu Unix) innerhalb eines Herstellers. [Sess99-3] Preis COM+ ist in Windows 2000 enthalten. EJB muß als ein Add-On zu einem Betriebssystem erworben werden. Auch wenn es hier einige günstige Angebote geben wird, so werden es sicher nicht jene sein, auf denen man geschäftskritische ECommerce Anwendungen laufen lassen möchte. Allerdings sollte man die Entscheidung für oder gegen eine Plattform, auf der die zukünftigen E-Commerce Systeme laufen werden, nicht vom Preis des Servers abhängig machen, der sicher nur ein Bruchteil der Gesamtkosten ausmacht. 3.7.4.2 Zusammenfassung der Unterschiede EJB scheint, zumindest wenn man die Anzahl von verfügbaren EJB-Servern als Indikator betrachtet, ein großer Erfolg zu werden. Derzeit sind mehr als 30 EJBServer am Markt verfügbar [Sun99]. Diese große Anzahl an Herstellern ist auch ein Verdienst von IBM, die sich sehr stark für EJB einsetzt und die sehr enge Beziehungen mit der Finanzindustrie besitzt. Dabei ist sicher nicht jeder Server für jede Aufgabe gleicht gut gerüstet. Die EJB-Spezifikation läßt hier genügend Raum für eine Differenzierung der einzelnen Anbieter. [Sess99-4]. Vielleicht der größte Nachteil von EJB ist, daß es nicht von Microsoft unterstützt wird. Jene Firma, die laut den meisten Analysten das Betriebssystem der Geschäftslogik-Schicht beherrschen wird. Microsoft setzt ganz alleine auf COM+. Es besitzt außer COM+ kein anderes Produkt in einem für Microsoft absolut kritischen Segment: E-Commerce. Es wird also mit aller Macht versuchen COM+ zum Markterfolg verhelfen. Sollte dazu mehr Geld, neue Firmenübernahmen und neues Expertenwissen notwendig sein, wird Microsoft alle Wahrscheinlichkeit nach die dafür nötigen Schritte setzen. Da es mit Windows 2000 praktisch gratis ausgeliefert wird, scheint dieses Ziel auch in Reichweite. [Sess99-4] Aus technischer Sicht sind es, wie die Modelle in Abbildung 3.11 und Abbildung 3.12 beweisen, zwei ähnliche, sehr gute serverseitige Komponentenmodelle, die sich beide als Plattformen für Applikations-Server eignen, wobei EJB sicher ein wenig vom Vorgänger von COM+ beeinflußt wurde, der ja schon um zwei Jahre länger am Markt ist. Der größte Unterschied ist die Unabhängigkeit von der verwendeten Serverplattform und damit im gewissen Grad vom Hersteller bei EJB auf der einen und die Unabhängigkeit von der verwendeten Programmiersprache bei COM+ auf [...]

Vorgänger von COM+ (MTS) ist jedoch schon seit vier Jahren verfügbar, ohne daß sich solch ein Markt entwickelt hätte. Bei EJB passierte dies hingegen in kurzer Zeit. Ein Grund dafür könnte die Plattformunabhängigkeit von Java sein. Sie ermöglicht die Entwicklung einer Komponente für mehrere unterschiedliche Plattformen, ohne Änderungen durchführen zu müssen. [Toma99]. Reifegrad COM+ ist im Vergleich zu EJB die ausgereiftere Technologie. COM+ ist die zweite Generation des MTS und hatte mehr als 3 Jahre Zeit zur Reife. Hinzu kommt, daß nur sehr wenige neue Eigenschaften hinzugefügt und in Betaversionen vorhandene Eigenschaften sogar entfernt wurden (z.B. Dynamische Lastverteilung, In Memory Databases) da sie anscheinend nicht stabil genug waren. Bei EJB ist bereits nach einem Jahr die erste Revision erschienen, die etliche neue und wichtige Eigenschaften hinzugefügt hat. Einen Langzeittest hat EJB somit noch nicht hinter sich, COM+ schon. Unterstützte Programmiersprachen COM+ bindet einen im Gegensatz zu EJB nicht an eine bestimmte Programmiersprache. Komponenten können in C, C++, Visual Basic, Cobol oder einer anderen Programmiersprache erstellt werden. EJBs können jedoch nur in der objektorientierten Sprache Java erstellt werden. Wenn man bedenkt, daß laut einer Umfrage in Kanada unter 1500 Entwicklern [Sess99-2] nur 1/12 in Java entwickeln, ist das eine risikoreiche Einschränkung – auch wenn der Trend in Richtung Java stark steigend ist. Entscheidet man sich für EJB, dann ist man für die nächsten Jahre an Java gebunden. Java ist zwar eine sehr saubere Programmiersprache die gegenwärtig einen großen „Hype“ erfährt, doch auch Smalltalk, Eiffel, Pascal etc. waren einmal sehr beliebt. Es ist zwar sehr unwahrscheinlich, daß Java seine Beliebtheit in naher Zukunft verliert, jedoch ist sie ohne Zweifel eine sehr neue Sprache, die den Test der Zeit noch nicht abgeschlossen hat. Portabilität Zur Zeit gibt es über 30 verschieden Hersteller die EJB-Server anbieten [Sun99]. EJB Komponenten sollten theoretisch in jedem dieser EJB-Server ablaufen können. Sollte ein EJB-Server schlecht skalieren, ist ein Wechsel einfach möglich, solange keine herstellerspezifischen Eigenschaften verwendet werden. Der Portierungsaufwand ist im Vergleich zu einer Portierung von einem EJB-Server zu COM+ vica versa mit Sicherheit vernachlässigbar. Bei einer Java-One Konferenz wurde dies bereits mit einer einzelnen EJB-Applikation auf 13 verschiedenen EJB-Servern [...]

dies nicht nötig, da Zustände im Speicher gehalten werden können. Jedoch erschweren zustandsbehaftete Komponenten ihre Wiederverwendung bei längere Inaktivität (engl. Object Pooling, siehe 4.8.2), da ihre Zustände zuerst zwischengespeichert werden müssen. Dies kann sich sehr negativ auf ihre Skalierbarkeit auswirkt. Persistenzmanagement EJB besitzt persistente Komponenten, die im Prinzip als Teil der Datenbank zu betrachten sind. Sie repräsentieren einen Ausschnitt der Datenbank als Objekt, was die Handhabung der Daten sehr vereinfacht. Der EJB Container kann die Datenzugriffslogik zum Speichern und Laden dieser Daten selbständig erstellen. Der Anwendungsentwickler wird daher von dieser Aufgabe befreit. Er muß die Abbildung der Daten in ein Objekt (O/R Mapping) nur deklarieren. COM+ bietet diese Möglichkeit nicht an. Message Oriented Middleware (MOM) COM+ integriert mit MSMQ und seinem Publish & Subscribe Modell eine MOM (siehe 3.2), die sowohl eine asynchrone Kommunikation zwischen Clients und Serverkomponenten, als auch lose gekoppelte Systeme ermöglicht. J2EE bietet zwar mit dem JMS auch einen MOM-Dienst an, integriert ihn bis jetzt jedoch nicht in EJB. Dies bedeutet, daß Clients ohne proprietären Verbindungscode nicht asynchron mit EJB-Komponenten kommunizieren können und EJBs an keinem Publish & Subscribe Modell teilnehmen können. Transaktionsmanagement COM+ verwendet den Microsoft Distributed Transaction Coordinator (MS DTC) als Transaktionsmanager. MS DTC ist XA-kompatibel (siehe XXX) und ermöglicht somit heterogene, verteilte Transaktionen. Java besitzt mit dem JTS ebenfalls eine Schnittstelle zu einem vollwertigen XAfähigen Transaktionsmanager. Jedoch verlangt EJB nicht, daß ein EJB-Server auch wirklich mit JTS ausgestattet ist. EJB schreibt lediglich die Verwendung von JTA zur Festlegung der Transaktionsgrenzen fest. Der Einsatz von JTS ist optional. Heterogene verteilte Transaktionen können daher nicht von jedem EJB-Server durchgeführt werden. Komponentenmarktplatz EJB ermöglicht einen Handel mit Software Komponenten, die aus verschiedenen Quellen erworben und relativ einfach und schnell in eine neue Applikation integriert werden können. Dies wäre natürlich auch für COM+ Komponenten denkbar. Der [...]