Der Status der Middleware für Java-Anwendungen, Teil 1

Client / Server ist tot. Das ist die Begeisterung, jetzt, wo neuere internetbasierte Technologien florieren. Diese neuen Technologien sind jedoch nur die natürliche Weiterentwicklung früherer Ansätze, die mit neueren, offeneren Protokollen implementiert wurden und eine größere Skalierbarkeit, Verwaltbarkeit und Vielfalt bieten sollen.

Das Ausmaß dieser Entwicklung ist erstaunlich. Die meisten großen Client / Server-Anbieter haben ihre Produkte modernisiert und lenken ihre Marketing-Dollars jetzt in dreistufige Technologien. In den meisten Fällen sind die neueren Produkte Java-zentriert und Internetprotokoll-zentriert. Zum Beispiel habe ich bei der letzten Zählung mindestens 46 Java-Middleware-Produkte identifiziert. Vor zwei Jahren wäre es schwierig gewesen, die Hälfte dieser Zahl zu finden.

Dies ist der erste Teil einer zweiteiligen Artikelserie, in der die allgemeine Java-Middleware in ihren aktuellen Formen erläutert wird. In diesem ersten Artikel werde ich die Funktionen aktueller Produkte untersuchen und erklären, warum diese Funktionen wichtig sind. Im zweiten Teil wird Anil Hemrajani Enterprise JavaBeans (EJB) untersuchen und zeigen, wie sich die aktuelle Generation von Java-Middleware-Produkten auf diesen wichtigen Komponentenstandard bezieht und diesen unterstützt.

Hintergrund

Definieren wir zunächst die Java-Middleware.Der Begriff umfasst Anwendungsserver wie BEA WebLogic, Messaging-Produkte wie ActiveWorks von Active Software und SpiritWAVE von Push Technologies sowie Hybridprodukte, die auf einem DBMS-Legacy aufbauen und serverbasierte Java-Objektausführungsfunktionen hinzufügen. Ich hätte mich auf ein engeres Segment wie Anwendungsserver konzentrieren können, aber das wäre unfair gegenüber den vielen Produkten gewesen, die nicht genau in diese Kategorie passen, aber dennoch für mehrschichtige Anwendungen in Betracht gezogen werden sollten. Selbst unter Anwendungsservern gibt es ein ziemlich breites Spektrum, einschließlich solcher, die hauptsächlich Servlet-Server sind, sowie solcher, die ORB- oder OODB-basiert sind. Es wird immer schwieriger, eine Grenze zwischen all diesen Produkten zu ziehen. Die vereinheitlichende Funktion ist jedochist, dass alle versuchen, das Problem der Bereitstellung mehrerer Anwendungen mithilfe von Java- und Internet-Technologien zu lösen.

Der Business Case für die Verwendung von Java in Middleware ist überzeugend. Zu den Vorteilen der Java-Middleware gehören:

  • Die Fähigkeit des Internets, Büros und Organisationen wirtschaftlich miteinander zu verbinden

  • Die Notwendigkeit für Organisationen, durch den Austausch von Daten und Geschäftsprozessen zusammenzuarbeiten

  • Der Wunsch, generische Dienste zu konsolidieren und diese Dienste zu verwalten

  • Der Wunsch nach zentraler Anwendungsverwaltung, einschließlich Start, Herunterfahren, Wartung, Wiederherstellung, Lastausgleich und Überwachung

  • Der Wunsch, offene Dienste und Protokolle zu nutzen

  • Der Wunsch, die Geschäftslogik nach Belieben und ohne Einschränkung durch die Infrastruktur neu einzusetzen; Dies erfordert die Verwendung offener APIs und Protokolle, die von den meisten Infrastrukturprodukten weitgehend unterstützt werden

  • Die Notwendigkeit, kooperierende Anwendungen mit gemischter Architektur zu unterstützen

  • Der Wunsch, Netzwerk- und Service-Infrastrukturentscheidungen aus dem Anwendungsbereich zu verschieben, damit Systemmanager Infrastrukturentscheidungen treffen können, ohne durch Anwendungen behindert zu werden, die von proprietären Protokollen oder Funktionen abhängen

  • Der Wunsch, die Vielfalt und das Niveau der erforderlichen Fähigkeiten der Programmierer zu verringern und den Bedarf an fortgeschrittenem Fachwissen im Bereich Werkzeugbau innerhalb von Projekten zu minimieren

  • Der Wunsch, objektorientiertes Fachwissen zu nutzen, indem es auf den Serverbereich ausgedehnt wird - daher neuere objektorientierte Serverprodukte und Brücken zwischen Objekt und Beziehung

Ziel der Middleware ist die Zentralisierung der Software-Infrastruktur und ihrer Bereitstellung. Client / Server stammt aus einer Ära der Integration in eine einzelne Abteilung. Unternehmen versuchen heute häufig, sich über Abteilungsgrenzen hinweg zu integrieren - sogar von einem Unternehmen zum anderen. Das Internet, das Unternehmen dazu verleitet, als globales Netzwerk zu fungieren, über das Abteilungen und Partner effizient und schnell miteinander kommunizieren können, hat die Nachfrage nach dieser Integration geweckt.

Java bietet eine Verkehrssprache für die einfache Verbindung von Daten und Anwendungen über Unternehmensgrenzen hinweg: In einer verteilten globalen Umgebung, in der Sie keine Kontrolle darüber haben, welche Technologieentscheidungen Ihre Partner treffen können, wählen intelligente Unternehmen offene und plattformneutrale Standards. Unternehmen können nicht vorhersehen, wer in zwei Jahren ihre Kunden, Partner oder Tochterunternehmen werden wird. Daher ist es nicht immer möglich, eine gemeinsame Infrastruktur mit ihren Partnern zu planen. In dieser unsicheren Situation kann die beste Entscheidung darin bestehen, möglichst universelle und anpassungsfähige Technologien einzusetzen.

Mit Java können Sie die Anzahl der Programmiersprachen und Plattformen reduzieren, die Ihre Mitarbeiter verstehen müssen. Warum? Da Java jetzt in so unterschiedlichen Kontexten wie Internetbrowsern, gespeicherten Prozeduren in Datenbanken, Geschäftsobjekten in Middleware-Produkten und clientseitigen Anwendungen bereitgestellt wird.

Im Alter von drei Jahren ist die Java-Technologie jedoch noch etwas unausgereift, und dies gilt auch für die in diesem Artikel behandelten Produkte. Auf der anderen Seite befinden wir uns möglicherweise in einer Zeit, in der Produkte nie wirklich ausgereift sind, weil sich die zugrunde liegenden Technologien, auf denen sie basieren, so schnell ändern. Tatsächlich habe ich bei praktisch jedem von mir verwendeten Middleware-Produkt erhebliche Probleme festgestellt, einschließlich vermeintlich ausgereifter Produkte, die seit einigen Jahren auf dem Markt sind und kürzlich bedeutende neue Funktionen herausgebracht haben. Der Punkt ist, dass bis ein Anbieter Probleme beheben kann, neue Funktionen hinzugefügt wurden. Der Zyklus zum Hinzufügen neuer Funktionen ist jetzt viel kürzer als je zuvor, sodass Produkte nicht genügend Zeit haben, um stabil zu werden, bevor sie den nächsten wichtigen Funktionsumfang enthalten.Daran müssen wir uns möglicherweise gewöhnen, und das Erlernen der Stärken und Schwächen der von uns ausgewählten Produkte ist ein wichtiger Bestandteil jedes Anwendungsdesigns und Prototypzyklus.

Ziele für Middleware

Der EJB Middleware-Komponentenstandard wurde mit folgenden Zielen entwickelt:

  • Bereitstellung der Interoperabilität von Komponenten. Enterprise Beans, die mit verschiedenen Tools entwickelt wurden, arbeiten zusammen. Außerdem können mit verschiedenen Tools entwickelte Beans in jeder EJB-Umgebung ausgeführt werden.

  • Bereitstellung eines benutzerfreundlichen Programmiermodells unter Beibehaltung des Zugriffs auf APIs auf niedriger Ebene.

  • Beheben von Lebenszyklusproblemen, einschließlich Entwicklung, Bereitstellung und Laufzeit.

  • Gewährleistung der Kompatibilität mit vorhandenen Plattformen, wodurch vorhandene Produkte erweitert werden können, um EJB zu unterstützen.

  • So behalten Sie die Kompatibilität mit anderen Java-APIs bei

  • Bereitstellung der Interoperabilität zwischen EJB- und Nicht-Java-Anwendungen.

  • Kompatibel mit CORBA.

Der Schwerpunkt des EJB-Standards liegt daher auf der Erstellung eines Interoperabilitätsstandards für Java-Middleware, der Programmierer davor schützt, sich mit vielen der schwierigen Probleme zu befassen, die bei der Entwicklung verteilter Anwendungen auftreten. Auf diese Weise können sich Softwareentwickler auf die Geschäftslogik konzentrieren, anstatt anspruchsvolle, selbst entwickelte Infrastrukturen und Tools zu schreiben. Infolgedessen können Unternehmen den größten Teil ihrer Bildungsressourcen in die Schulung von Mitarbeitern in Geschäftsprozessen investieren, was in der Regel den größten Gewinn bringt.

Zur obigen Liste füge ich die folgenden zusätzlichen Ziele für Java-Middleware der Enterprise-Klasse hinzu. Diese Produktfunktionen werden langfristig benötigt, um eine Middleware-basierte Umgebung erfolgreich auszuführen und zu warten:

  • Es sollte die Verbindung mehrerer Geschäftsbereiche, Unternehmen und Kunden in einer verteilten Infrastruktur ermöglichen, ohne die Sicherheit zu beeinträchtigen oder Chaos zu verursachen

  • Es sollte flexible und dennoch zuverlässige Zugriffskontrollmechanismen ermöglichen, um sicherzustellen, dass auf Geschäftspartnerdaten nur auf die beabsichtigte Weise und nur von den beabsichtigten Parteien zugegriffen wird

  • Es sollte Systemadministratoren ermöglichen, eine verteilte Computerumgebung mit einer großen Anzahl von Geschäftslogikkomponenten auf einheitliche Weise zu verwalten, ohne bestimmte Verfahren verstehen oder auf bestimmte Komponenten anwenden zu müssen

  • Systemadministratoren sollten die Möglichkeit haben, Infrastrukturkomponenten auszuwählen, ohne die Anwendungen zu beeinträchtigen, diese Komponenten zu optimieren und zu skalieren und über eine einheitliche und allgemeine Methode zur Messung der Leistung und des Ressourcenbedarfs aller Anwendungen zu verfügen

  • Es sollte ermöglichen, Geschäftskomponenten zwischen Clients und Servern zu verschieben, ohne die Architekturen von beiden zu beeinträchtigen

  • Es sollte einen Sicherheitsmechanismus bieten, mit dem bestimmte Benutzer neue Komponenten hinzufügen können, ohne dem Serveradministrator Zugriff auf alle Komponenten und Datenquellen gewähren zu müssen (dies ist eine großartige Gelegenheit für Mehrwertfunktionen, da dies für Extranet- und Partnerschaftsanwendungen von entscheidender Bedeutung ist )

Komponenten und Funktionen von Java-Middleware-Plattformen

Die am schnellsten wachsende Kategorie der Java-Middleware sind heute wahrscheinlich Anwendungsserver. Es ist jedoch wichtig, die Vielzahl der vorhandenen Anwendungsserver (und anderer Arten von Middleware-Produkten) zu erkennen. Die Unterscheidung zwischen Java-Middleware-Produktkategorien wird heute nicht durch eine Linie, sondern durch ein großes Middleware-Kontinuum dargestellt. Ich werde nun die Funktionen der Java-Middleware anhand meiner eigenen Arbeitsvergleiche diskutieren, die alle mir bekannten Klassen von Java-Middleware-Produkten umfassen.

Objekt-, Komponenten- und Containermodelle

Anwendungskomponenten müssen einem Laufzeitbereitstellungsmodell entsprechen, das angibt, wie die Komponente mit ihrer Umgebung kommuniziert. (möglicherweise) wie es installiert, gestartet, gestoppt und aufgerufen wird; und wie es auf Dienste zugreift, die für seine Umgebung wichtig sind. Zu den gängigen Java-zentrierten Laufzeit- und Containermodellen für Serverkomponenten gehören RMI, EJB, CORBA, DCOM, Servlet, JSP (Java Server Pages) und gespeicherte Java-Prozeduren. Darüber hinaus können die Komponentenmodelle in einer Vielzahl von zugrunde liegenden Sprachen ausgedrückt werden, darunter Java, IDL, C ++ und viele andere.

Es gibt Überschneidungen mit verschiedenen Komponentenmodellen. Beispielsweise ist RMI ein triviales Komponentenmodell mit sehr grundlegenden Funktionen für die Objektaktivierung und -ortung und in erster Linie ein Standard für Remote-Aufrufe, während EJB RMI nutzt und RMI als primäres Objektaufrufmodell angibt. EJB unterstützt auch CORBA. Tatsächlich ist keines dieser Modelle exklusiv und viele Java-Anwendungsserver unterstützen die meisten oder alle der oben genannten Modelle.

Auf vielen Java-Middleware-Servern werden mehrere Business-Object-Instanzen (die von der CORBA-Welt jetzt als Servants bezeichnet werden) in einer einzigen Java Virtual Machine (JVM) ausgeführt. Die Typensicherheit der Java-Sprache ermöglicht es einem einzelnen JVM-Prozess, Anforderungen von mehreren Clients zu bearbeiten und Programmdatenstrukturen und Klassenlader zu verwenden, um Clientdaten getrennt zu halten. Solange Servants keine eigenen nativen Methoden verwenden, kann ein Servant andere Servants nicht herunterfahren, wenn sie abstürzen (es sei denn, es tritt ein Fehler in der JVM selbst auf) oder auf Daten zugreifen, die für andere Klassen privat sind . Ein ordnungsgemäß gestalteter Objektserver schützt seine privaten Objekte und verhindert, dass fehlerhafte Objekte auf Objekte zugreifen, die zu anderen Objekten gehören.

In einer Java-Klasse als statisch deklarierte Daten können jedoch von Clients innerhalb derselben JVM gemeinsam genutzt werden, wenn die Clients denselben Klassenlader verwenden. Daher müssen Regeln definiert werden, um festzulegen, wann eine separate JVM (oder das Äquivalent einer separaten JVM mit Speicher) verwendet werden soll. Partitionierungstechniken) oder ein separater Klassenlader sind erforderlich, um einem Client einen eigenen statischen Datenraum zu geben. Solche Regeln wurden für Applets angegeben, jedoch nicht für andere Ausführungsumgebungen. Der Java-Webserver von Sun verwendet eine einzige JVM für alle Servlets und einen separaten Klassennamenraum für Servlets mit einer anderen Codebasis. EJB umgeht das Problem, indem es nicht endgültige statische Daten verbietet.

Die Leistung kann gesteigert werden, wenn Objekte bei Nichtgebrauch inaktiviert oder passiviert werden, wodurch Ressourcen wie Datenbankverbindungen frei werden. Aus diesem Grund passivieren und reaktivieren viele Server Objekte entsprechend. In ähnlicher Weise halten einige Produkte häufig erstellte Objekte in einem Pool oder Cache in einem initialisierten Zustand und können sofort verwendet werden. Der Objektcontainer muss die Passivierung und Reaktivierung sowie die von der Passivierung betroffenen gepoolten Ressourcen verwalten.

EJB-Kompatibilität (Version)

Das EJB-Modell wird bereits allgemein unterstützt. Nahezu jeder Middleware-Anbieter hat versprochen, dies zu unterstützen, und viele tun dies bereits. Darüber hinaus hat die Object Management Group (OMG) im Rahmen der vorgeschlagenen CORBA-Komponentenspezifikation eine Zuordnung zu EJB vorgenommen . Es ist schwer vorstellbar, dass selbst Microsoft, das einzige und unerschütterliche Unternehmen, letztendlich keine EJB-Container für DCOM bereitstellen und bereitstellen wird.

Während verschiedene EJB-kompatible Middleware dieselben Anwendungskomponenten bereitstellen und betreiben können (solange diese Komponenten nur die standardmäßig erforderlichen EJB-Funktionen verwenden), gibt es zwischen EJB-kompatiblen Servern immer noch große Unterschiede. Zum einen entwickelt sich die EJB-Spezifikation selbst weiter. Eine wichtige Frage bei der Bewertung von Java-Middleware-Produkten lautet daher: Unterstützt der Server die neueste Version von EJB oder nur eine frühere Version? Eine weitere wichtige Frage lautet: Ist das Produkt EJB-zentriert oder ist die EJB-Unterstützung nur in den Mehrwertfunktionen des Produkts enthalten (und daher nicht verfügbar, wenn EJB-Dienste oder -APIs verwendet werden)? Und schließlich: Welche optionalen EJB-Funktionen sind enthalten (z. B. Entity Beans und Container-verwaltete Persistenz)?