WebSphere Application Server-Anwendungsservertopologien für hohe Verfügbarkeit. Anwendungsserver

Woher weiß der Webserver, ob er den Inhalt der Datei, auf die die URL verweist, an den Client weitergeben oder die Datei ausführen soll? Es gibt zwei Möglichkeiten, Dateien zu erkennen, die CGI-Skripte enthalten.

• Die erste Möglichkeit besteht darin, dass bei der Installation des Webservers eines der Verzeichnisse speziell zum Speichern von Skripten zugewiesen wird. Typischerweise heißt ein solches Verzeichnis cgi-bin (oder Skripte für den IIS-Webserver). Wenn der Client in diesem Fall eine Datei aus dem cgi-bin-Verzeichnis anfordert, interpretiert der Server eine solche Anfrage als Befehl zum Ausführen des Skripts. Dateien aus anderen Verzeichnissen werden als HTML-Dokumente interpretiert.
• Der zweite Weg verwendet die Dateierweiterung. Die Serverkonfiguration gibt an, dass Dateien mit bestimmten Erweiterungen Skriptcodes enthalten.

Die Identifikation durch Erweiterung wird relativ selten verwendet. Meistens werden alle Skripte in cgi-bin , /Scripts oder einem anderen Verzeichnis abgelegt, das speziell dafür vorgesehen ist, sie zu speichern.

Die Ausgabe der Ergebnisse eines CGI-Skripts ist denkbar einfach. Damit die Daten an den Client übertragen werden, reicht es aus, sie auf den Standardausgabestrom zu drucken. Allerdings sollte man bei der Entwicklung eines CGI-Skripts nicht vergessen, dass es sich dennoch von einem Konsolenprogramm unterscheidet und folgende Eigenschaften hat.

An den Client übermittelte Informationen müssen dem HTTP-Protokoll entsprechen, d.h. bestehen aus einem Header und einem Response-Body. In der Regel fügt der Server nach dem Empfang von Daten aus dem Skript selbst die erste Kopfzeile hinzu.

HTTP/1.0 200 OK

Die Bildung der im Header enthaltenen Informationsfelder ist Aufgabe des Skripts. Damit die vom Skript übergebenen Daten vom Client richtig interpretiert werden, muss zumindest das Feld Content-type im Header vorhanden sein. Dem Titel muss eine Leerzeile folgen. Ohne Header-Felder ist die Antwort des Browsers unvorhersehbar. In solchen Fällen versucht der Browser in der Regel, die erhaltenen Informationen als Textdatei darzustellen.

Das natürlichste Format für einen Browser ist das HTML-Format. Die Ausgabe eines Skripts wird normalerweise als Webseite dargestellt, dh. Die zurückgegebenen Daten sollten mit HTML-Tags aufgefüllt werden. Daher sieht die Antwort eines CGI-Skripts an einen Client normalerweise so aus:

Inhaltstyp: text/html Skriptantwort ……………………

Beachten Sie die leere Zeile nach dem Ausdruck Content-type: text/html. Es muss in der Antwort vorhanden sein, sonst nimmt der Client alle nachfolgenden Daten als Fortsetzung des Headers wahr.

Nach dem Kompilieren des Programms müssen Sie die ausführbare Datei in das cgi-bin-Verzeichnis (oder in ein anderes Verzeichnis, das zum Platzieren ausführbarer Dateien vorgesehen ist) kopieren, von wo aus sie auf Anforderung des Clients vom Webserver zur Ausführung gestartet werden kann.

Um dieses Skript aufzurufen, fügen Sie einfach das folgende HTML-Code-Snippet in Ihre Webseite ein:

• Wenn das Methodenattribut auf " GET " gesetzt ist, wird die Parameterzeichenfolge zusammen mit der URL des aufzurufenden Skripts übergeben. Das Trennzeichen zwischen der URL und der Parameterzeichenfolge ist das „?“-Zeichen.
• Wenn das Methodenattribut auf " POST " gesetzt ist, wird die Parameterzeichenfolge im Hauptteil der HTTP-Anforderung übergeben.

Überlegen Sie, wie sich das CGI-Skript verhalten muss, um die Daten korrekt zu verarbeiten. Abhängig von der Methode, die zum Übergeben der Daten verwendet wird, wird die Parameterzeichenfolge auf verschiedene Weise an das CGI-Skript geliefert.

Wenn das METHOD-Attribut des Deskriptors war " GET ", wird die Parameterzeichenfolge als Wert einer Umgebungsvariablen an den Server übergeben QUERY_STRING.

Bei Verwendung der POST-Methode werden die Daten auf andere Weise an das Skript geliefert. Sie werden durch übertragen Standardeingabe(STDIN). Damit das Skript bestimmt, wie viele Zeichen von der Standardeingabe gelesen werden sollen, legt der Webserver fest variabler Wert Umgebung CONTENT_LENGTH gleich der Länge der Parameterzeichenfolge.

Nachdem das Skript die Kontrolle erhalten hat, muss es zunächst herausfinden, mit welcher Methode die ausgeführt wurde Parameterübergabe. Diese Informationen sind in der Umgebungsvariable enthalten REQUEST_METHOD.

Im einfachsten Fall reicht es also aus, den Zweck von drei Umgebungsvariablen zu kennen, um den Parameterstring zu verarbeiten:

Szenarien

Die Hauptvorteile der Entwicklung von Anwendungen auf der Seite des Webservers in Form von Skripten umfassen die folgenden:

• Da Skripte nicht kompiliert, sondern interpretiert werden, führen Fehler im Skript nur zu einer Diagnosemeldung, führen aber nicht zu einer Destabilisierung des Webservers oder des Betriebssystems.
• die besten Ausdrucksmöglichkeiten. Eine Skriptsprache hat normalerweise ihren eigenen domänenspezifischen Satz von Befehlen, und eine Skriptzeile kann das tun, was Dutzende von Zeilen in einer traditionellen Sprache tun können. Folglich kann ein ungelernter Programmierer in dieser Sprache schreiben.
• Plattformübergreifende Unterstützung.

Da Skripte bei jeder Ausführung dynamisch aus dem Quellcode interpretiert werden, laufen sie normalerweise viel langsamer als fertige Programme, die zur Kompilierzeit in Maschinencode übersetzt werden.

In Bezug auf die Geschwindigkeit Skriptsprachen kann aufgeteilt werden in:

• Dynamische Parsing-Sprachen(z. B. command.com). Der Interpreter liest Anweisungen aus der Programmdatei in den minimal erforderlichen Blöcken und führt diese Blöcke aus, ohne weiteren Code zu lesen.
• Vorkompiliert(wie Perl). Zuerst wird das gesamte Programm gelesen, dann entweder in Maschinencode oder in eines der internen Formate kompiliert, wonach der resultierende Code ausgeführt wird.

Werfen wir einen kurzen Blick auf die bekanntesten Skriptsprachen für Webanwendungen.

Dabei wurden die Möglichkeiten von zwei Serverplattformen für Terminallösungen betrachtet. Aber der Markt hat sich verändert: Ein neuer Server von Microsoft ist erschienen - "MS Windows 2000 Advanced Server", der die Unterschiede zwischen Microsoft- und Citrix-Produkten fast vollständig beseitigt. Der neue Server hat folgende Features:

• Clustering- und Lastverteilungsdienst
• Unterstützung des RDP5-Protokolls
• Unterstützung für den Zugriff auf den Server über den IE-Browser (Bestandteil von ACTIVE X)
• Zugriff auf den Druckserver, COM-Anschlüsse und die Client-Zwischenablage.

Erwähnenswert ist auch das Erscheinen eines Produkts von Corel auf dem Markt, das in Russland leider nicht zum Verkauf angeboten und noch keinem unabhängigen Test unterzogen wurde.

Die Hauptaufgaben, die der Anwendungsserver ausführt, sind das Ausführen von Client-Aufgaben und das Senden des geänderten Client-Fensters. Es ist sinnvoll, hier zwei Punkte zu beachten.

Erstens, mit welcher Geschwindigkeit der Server Aufgaben ausführt. Wenn die Verbindungsgeschwindigkeit hoch ist, hängt die Gesamtleistung des Systems von der Geschwindigkeit der Aufgabenausführung ab.

Der zweite Indikator ist die Liefergeschwindigkeit des aktualisierten Client-Bildschirms. Auch hier ist es sinnvoll, darauf zu achten, dass selbst wenn Ihr Server phantastisch schnell ist, die Geschwindigkeit der Verbindung zwischen Server und Client Einfluss auf die Leistungssteigerung hat.

Das heißt, das Optimum beim Aufbau von Terminalsystemen, sowohl im kleinen als auch im großen Maßstab, hängt zuallererst nicht von Benutzeranforderungen ab, sondern von Technische Fähigkeiten, die Sie bereitstellen können, und das Gleichgewicht zwischen Servergeschwindigkeit und Verbindungsgeschwindigkeit, das Sie erreichen können. Dieses Problem ist in erster Linie ökonomischer Natur, da die oben beschriebene Abwägung die Wahl zwischen einer schnelleren Verbindung zum Client und einem schnelleren und damit teureren Server ist.

Achten Sie auch auf den Komfort beim Arbeiten mit dem Terminal, den die Nutzer bereitwillig akzeptieren. So muss zum Beispiel eine Schreibkraft, die Zahlungen in einer Bank eintippt, das Ergebnis ihrer Arbeit nicht sofort auf dem Bildschirm sehen – eine Pause von 0,1 Sekunden kann ihr perfekt passen. Außerdem kann der Benutzer beim Starten der Anwendung mit 16 statt 256 Farben ziemlich zufrieden sein. Einfach ausgedrückt: Bevor Sie ein Terminalsystem erstellen, müssen Sie sich mit den technischen Möglichkeiten des Unternehmens, den Benutzeranforderungen und den damit verbundenen Geschäftsaufgaben vertraut machen auf dem Server durchgeführt werden.

Auswahl des Anwendungsservers

Die Hauptaufgabe bei der Auswahl eines Anwendungsservers besteht darin, die Prozessorleistung und die Größe des Arbeitsspeichers zu optimieren. Das Hauptproblem besteht darin, die erforderlichen Ressourcen für eine große Gruppe von Benutzern zu berechnen, die wenig Ahnung davon haben und wie sie den Server belasten können. Das heißt, Sie können sicher davon ausgehen, dass eine Sekretärin wenig Ressourcen verbraucht, aber was passiert, wenn mehr als 50 solcher Benutzer mit dem Server verbunden sind?

Erstens nutzen diese Benutzer die ihnen zur Verfügung gestellten Rechenressourcen nicht ständig, und zweitens kommt es selbst bei ihrer Arbeit zu erheblichen Aktivitätsausbrüchen - beispielsweise beim Herunterladen von Word. Es muss auch davon ausgegangen werden, dass es andere Nutzer gibt, die möglicherweise andere Parameter für das Laden des Servers haben – zum Beispiel Programmierer.

In dieser Phase müssen Sie vielleicht zum ersten Mal das "Verhalten" der Benutzer analysieren, die Sie mit dem Terminalserver verbinden werden.

Beispiel

Die Gesamtzahl der Stellen beträgt 20. 10 Benutzer verwenden nur Microsoft Word, Excel, Outlook, IE (Vertrieb, Marketing und PR), 3 Benutzer verwenden nur 1C (Buchhaltung), 4 Benutzer verwenden IE, Outlook (Abteilungsleiter), 2 Benutzer verwenden selten Word und enden schließlich damit, dass ein Systemadministrator alles von PhotoShop auf J++ herunterlädt.

Nehmen wir an, dass innerhalb der Benutzergruppen die Last gleichmäßig verteilt ist (alle essen zur gleichen Zeit zu Mittag), nehmen wir auch an, dass die Software, die Benutzer verwenden, den Server im Allgemeinen gleichmäßig belastet (mit anderen Worten, das Eintippen von Word erzeugt keine Spitze bei der Prozessorauslastung).

In gewisser Weise sehen Sie sich also an, wie der Benutzer den Computer während des Arbeitstages verwendet. Das heißt, beobachten Sie, welche Aktionen er für ihn ausführt. Данный контроль можно осуществлять двумя способами, во-первых, запустить какого-нибудь робота, что бы он записывал нажатия на клавиши и щелчки мышью, во-вторых, вы можете подключить пользователя к какому-либо свободному терминальному серверу и посмотреть какую нагрузку он будет производить im Laufe des Tages. Darüber hinaus lassen sich die Arbeitsergebnisse des Roboters bereits auf dem Terminalserver reproduzieren und die Systemauslastung feststellen.

Welche Parameter sollten Sie erhalten:

1. Spitzenbelastung des Prozessors. Die Häufigkeit der Spitzenbelastung des Prozessors pro Tag. Die durchschnittliche Dauer einer solchen Belastung.
2. Durchschnittliche CPU-Last pro Tag. Es ist auch wünschenswert, die stündliche durchschnittliche Last zu finden.
3. Spitzenspeicherauslastung. Spitzenlasthäufigkeit pro Tag. Die durchschnittliche Dauer einer solchen Belastung.
4. Durchschnittlicher Speicherverbrauch während des Tages, stündlicher Lastdurchschnitt.

Sie sollten dies mit allen Benutzergruppen testen.

Außerdem können Sie leicht die sogenannten "Minimum" -Indikatoren des Anwendungsservers erhalten - multiplizieren Sie die Durchschnittswerte mit der Anzahl der Benutzer in der Gruppe und addieren Sie alle Gruppen. Sie erhalten fantastische Speicheranforderungen - für unser Beispiel: etwa 780 MB RAM und etwa 2 GHz CPU-Auslastung insgesamt.

Aber keine Angst - die oben beschriebene Methode ist falsch :), da der Terminalserver weiß, wie man Speicher effizient nutzt.

Beispielsweise beträgt die Gesamtmenge der herunterladbaren Microsoft Word-Komponenten im Speicher etwa 9 MB, aber 8 MB dieses Blocks entfallen auf Wörterbücher, Grafiken und einen Assistenten. Wenn die nächste Kopie von Word gestartet wird, werden diese 8 MB nicht heruntergeladen oder dupliziert – sie stehen beiden Kopien zur Verfügung. Wenn einer von ihnen versucht, diesen 8-Megabyte-Teil zu modifizieren, wird der modifizierte Teil abgestreift und benötigt etwas Speicher. Die Verwendung dieses Speicherzuweisungsmechanismus spart Speicher. Den Grad dieser Einsparung können Sie aber nur über den zweiten mit dem Terminalserver verbundenen Client ermitteln. Das heißt, Sie verbinden einen zweiten Client oder führen das zuvor vom Roboter aufgezeichnete Aktionsprogramm ein zweites Mal aus.

So konnten Sie beim Neustart die ungefähre Größe der Anwendungen ermitteln. Als Nächstes müssen Sie eine ungefähre temporäre Tabelle der Auslastung dieser Anwendung im Arbeitsspeicher erstellen. Zum Beispiel: Word – 27 % der Zeit, Excel – 10 % der Zeit, IE – 100 % der Zeit. Als Nächstes multiplizieren Sie den tatsächlich benötigten Speicherplatz mit der Anzahl der Benutzer, die diese Anwendung verwenden, und mit der resultierenden Tabelle. Das resultierende "Megabyte-sapiens" ist die minimale Speichermenge, die Sie benötigen (in unserem Beispiel etwa 340 MB).

Auch die Prozessorleistung lässt sich ganz normal berechnen – man addiert einfach die durchschnittliche Auslastung des Terminalservers. Übersetzen Sie diese Arbeitslast dann in einige skalierbare Einheiten - zum Beispiel Megahertz oder Leistungsindikatoren einiger Prozessortests. Hier ist darauf zu achten, dass Megahertz die schlechteste Option ist, da 166MMX nicht 5-mal langsamer als 800 MHz Athlon arbeitet, aber leider ist es schwierig zu sagen, welcher Indikator zum Vergleich der beste ist.

So können Sie für unser Beispiel einen Indikator auf dem Niveau von 500-600 MHz erhalten. Wenn Sie berechnen, wie viel jede einzelne Anwendung den Server belastet, und dieses Ergebnis mit den Zahlen aus der zuvor erhaltenen Tabelle multiplizieren, erhalten Sie möglicherweise ein kleineres und wahrheitsgemäßeres Ergebnis.

Als nächstes müssen Sie herausfinden, wie sich Überlastungen auf den Server auswirken. Nehmen wir an, dass es zwei Arten von Überlastungen gibt - morgens und gewöhnlich. Mit Morgen meinen wir den üblichen Download von Stationen ohne Festplatte, mit gewöhnlich - den Download neuer Anwendungen.

Sie sollten sich der Anzahl solcher Momente während des Arbeitstages und ihrer Verteilung bewusst sein. Wenn es nur wenige solcher Überladungen gibt, können Sie sie getrost vergessen, aber wenn es viele gibt, müssen Sie zusätzlichen Speicher und Prozessorressourcen zuweisen. Es stellte sich beispielsweise heraus, dass alle 20 Minuten eine normale Überlastung auftritt. Gleichzeitig steigt die Prozessorlast um 200 MHz, dazu werden durchschnittlich ca. 10 MB Arbeitsspeicher verbraucht. Dauer etwa 15 Sekunden. In der Praxis müssen Sie diese Indikatoren zum Minimum hinzufügen. Die morgendliche Überlastung hat jedoch andere Qualitäten – sagen wir 20 Überlastungen in 10 Minuten, die etwa 20 Sekunden dauern. Sie müssen dann eine komplexere Situation berücksichtigen - beispielsweise das Auftreten von zwei Überlastungen zur gleichen Zeit.

Am Ende haben Sie also die Indikatoren: Prozessorleistung - etwa 600-Megahertz-Prozessor, 400 Megabyte RAM. Als nächstes müssen Sie Speicher für das Betriebssystem selbst und seine Dienste zuweisen. Wenn Sie beispielsweise Windows 2000 Advanced Server installieren, können Sie 128 MB Speicher und etwa 40 MHz für interne Aufgaben hinzufügen.

Das Ergebnis sind 640 MHz für 512 MB RAM.

Mit diesem Algorithmus können Sie die Serverkapazität ermitteln, die Ihr Unternehmen benötigt. Ich habe bewusst keine Ergebnisse von Tests angegeben, die ich selbst durchgeführt habe, oder Ergebnisse westlicher Unternehmen veröffentlicht, damit Sie selbst die Wirksamkeit von Terminallösungen bewerten können.

Wenn Ihre Benutzer die Festplatte häufig verwenden müssen, ziehen Sie die Verwendung eines SCSI-Controllers und einer SCSI-Festplatte in Betracht – dies entlastet den Prozessor und reduziert die Anzahl der Überlastungen.

Selbst wenn Ihre Organisation über viele Ressourcen verfügt, um solche Aufgaben auszuführen, sollten Sie auf jeden Fall keine Xeons kaufen und Gigabyte Speicher installieren - das Hinzufügen eines zweiten Prozessors ist oft viel einfacher, als ein paar tausend Dollar umsonst auszugeben.

Nach Auswahl

Sie haben also den richtigen Server gekauft, getestet und stehen nun vor der Aufgabe, Software zu konfigurieren und zu installieren.

Zunächst müssen Sie entscheiden, ob Sie Citrix-Produkte verwenden oder bei Microsoft-Produkten bleiben. Eine teurere Option - Metaframe, hat mehrere Funktionen, die aus meiner Sicht nicht sehr wichtig sind:

• Programm Nachbarschaft. Der Einsatz dieser Komponente ist praktisch sinnlos, wenn die Anzahl der Benutzer weniger als 100 beträgt, in jedem Fall können Sie mit Standardverwaltungstools die gleiche Effizienz erzielen
• Video Frame - diese Komponente ermöglicht es mehreren Bedienern, oder sagen wir einfach Ihnen, die Arbeit von Kunden zu beobachten und bei Bedarf in ihre Arbeit einzugreifen.
• Unterstützung der Audioübertragung
• Unterstützung für IPX/SPX und mehrere andere Protokolle, einschließlich Nullmodem-Kabelverbindung.

Der wichtigste Unterschied zwischen diesen Terminalservern liegt im Client-Verbindungsprotokoll. Microsoft verwendet dafür RDP 5.0, Citrix verwendet ICA.

Diese Protokolle haben ihre eigenen Vor- und Nachteile. Beispielsweise ist ICA ein plattformunabhängiges Protokoll, der Client kann auf jeder Plattform laufen, sei es ein Webbrowser oder das gute alte Lunix. Das Microsoft-Protokoll funktioniert nur auf 2 Clients – WIN16 und WIN32, aber dies gibt ihm die Möglichkeit, WINAPI-Aufrufe zu verwenden, wodurch die Größe und Anzahl der übertragenen Pakete drastisch reduziert wird. Infolgedessen zeigt dieses Protokoll häufiger die Möglichkeit eines komfortablen Betriebs bei einer Bandbreite von 4-8 KB pro Sekunde, wenn Citrix selbst mit der Installation von SPEEDSCREEN2 (ICA-Stream-Komprimierungsdienstprogramm) nicht besser als 10 Kilobyte pro Sekunde anzeigt .

Wie könnte sich dies auf Ihr Geschäft auswirken? Wenn Sie eine entfernte Zweigstelle anschließen müssen, ist die Verwendung kommerzieller Leitungen oft sehr teuer, und die Stream-Komprimierung ist sehr wichtig. Für eine sehr komfortable Verbindung eines Clients über RDP5.0 müssen Sie beispielsweise zwei 33.6-Modems verwenden, und über ICA ist ein dedizierter Kanal obligatorisch.

Der zweite Faktor beim Kauf dieser Produkte ist die Möglichkeit, sie in Russland zu kaufen. Wenn noch Microsoft-Produkte vorhanden sind, müssen Sie nach Produkten von Citrix suchen. Als zusätzliches Plus ist anzumerken, dass Microsoft-Produkte russifiziert sind.

Installation

Windows 2000 Advanced-Server

Die Installation verläuft in der Regel problemlos, das einzige, was von Ihnen verlangt wird, ist die Installation von Terminal Services als Komponente. Außerdem benötigen Sie keine speziellen Einstellungen, Sie müssen den Server nur für mehr als 2 verbundene Clients lizenzieren, und dies wird die Einstellung vervollständigen.

Citrix-Metaframe 1.8

Auch die Installation sollte Ihnen keine Probleme bereiten, Sie müssen während der Installation keine aufwendigen Einstellungen vornehmen.

Wenn Sie jedoch Probleme bei der Installation eines dieser Produkte haben, finden Sie leicht Installationsanweisungen auf mehreren russischen Servern.

Server-Setup nach der Installation

Hier werde ich einige Tipps geben, um den Zustand der Server zu verbessern:

1. Deaktivieren Sie die Stream-Komprimierung, wenn Ihre Clients nicht über leistungsstarke Prozessoren verfügen. Dadurch soll auch die Belastung des Servers reduziert werden.
2. Verwenden Sie den Server nicht als Proxy, Webserver oder Datenbankserver. Wählen Sie für diese Zwecke eine andere Workstation aus.
3. Deaktivieren oder reduzieren Sie das Bitmap-Caching auf 1-2 MB, wenn Sie Clients ohne Festplatte verwenden. Dadurch wird das Netzwerk entlastet und die Arbeit beschleunigt.
4. Reduzieren Sie die Größe des Client-Desktops auf 640 x 480 Pixel und 16 Farben. Dadurch wird die Belastung des Netzwerks drastisch reduziert und dem Server mehr Ressourcen zur Verfügung gestellt.
5. Deaktivieren Sie alle Bildschirmschoner auf der Client-Seite oder installieren Sie sie einfach nicht.
6. Versuchen Sie, alle DOS-Komponenten oder grafikintensiven Komponenten loszuwerden.
7. Deaktivieren Sie alle Arten von Videoeffekten, Bildschirmschonern, Desktop-Hintergründen und dergleichen.
8. Deaktivieren Sie die Verschlüsselung, da sie den Client um etwa 5 Prozent verlangsamt.
9. Versuchen Sie, das Netzwerksegment zu trennen, in dem Ihr Anwendungsserver und Ihre Clients ausgeführt werden. Dadurch wird die Belastung des Netzwerks verringert.
10. Erhöhen Sie den Bitmap-Cache auf das Maximum, wenn Sie Disk-Clients verwenden. Dadurch wird die Bildschirmaktualisierungsrate drastisch erhöht.
11. Verbieten Sie Benutzern, andere Mittel als die regulierten zu verwenden (stellen Sie sicher, dass Sie den Flipper ausschalten, wenn Sie den Server installieren, da diese Anwendung bereit ist, alle ihr angebotenen Kräfte herunterzuladen;))

Ich hoffe, dass diese Tipps dazu beitragen werden, bestimmte Ressourcen freizugeben, sowohl das Netzwerk als auch den Anwendungsserver. Aber es gibt Situationen, in denen Sie bei der Nutzung des Netzwerks noch bessere Ergebnisse erzielen müssen - zum Beispiel, um mit einer Bandbreite von 2-3 Kilobyte arbeiten zu können.

Solche Situationen sind leider nicht ungewöhnlich, wenn eine Organisation über ein umfangreiches Netzwerk geografisch entfernter Terminals verfügt und nicht über die Ressourcen verfügt, um teure Kanäle zu verwenden. Seit der Veröffentlichung des ersten Artikels habe ich 3 Briefe mit Fragen zum Aufbau genau solcher Netzwerke erhalten.

Die Hauptfrage in solchen Netzwerken ist, wie sich eine starke Verringerung der Bandbreite auf die Arbeitsqualität auswirkt.

Ich habe eine spezielle Software verwendet, um die Kapazität meiner Netzwerkkarte zu reduzieren und zu bewerten, wie sich die drastische Reduzierung der Kapazität des Kanals auf den Betrieb auswirkt.

Die Verzögerung bei der Datenübertragung wurde auf 0,25 Sekunden gezwungen (ich denke, dass es selbst in Russland schwierig ist, große Verzögerungen zu bekommen). Alle Bitmaps wurden vorab zwischengespeichert. Benutzte RDP 5.0.

Kanal 8 KB pro Sekunde

Beim Öffnen eines Fensters ist eine Pause zu spüren, es scheint, dass beim Drücken der Taste erst nach einer Sekunde ein Dialogfeld auf dem Bildschirm angezeigt wird. Beim Eingeben von Text hat man das Gefühl, dass sich auf der Tastatur ein riesiger Puffer befindet - auf diese Weise etwa 30. Die Verbindung zum Server dauert sehr lange: Der Autorisierungsbildschirm wird erst nach 15 Sekunden angezeigt.

Kanal 6 KB pro Sekunde

Erhöht die Zeit für das Erscheinen von Dialogen dramatisch, auch bei einer zweiten Anfrage. Die Pause zwischen der Ausgabe eines Zeichens in Word und dem Drücken des Buttons beträgt etwa eine Sekunde. Ein normaler Betrieb ist aber weiterhin möglich.

Kanal 4 KByte pro Sekunde

Ich hatte erwartet, dass sich der Anmeldebildschirm etwa eine Minute lang öffnet. Technisch ist ein Arbeiten noch möglich, aber weder Scrollen noch eine grafische Ausgabe sind bereits möglich. Wenn Sie versuchen, auf die Schaltfläche "Start" zu klicken, müssen Sie etwa 2 Sekunden warten. Dieser Modus ist nur für spezielle Anwendungen geeignet.

Kanal 2 KByte pro Sekunde

Technisch gesehen können Ihnen diese Informationen bei der Entscheidung helfen, ob Sie eine Gegenstelle anschließen möchten. Wenn das Terminal als Bediener verwendet wird, erhöht die Migration von DOS auf ein solches System den Komfort nicht (wie bei Windows üblich), verringert jedoch auch nicht die Arbeitsqualität.

Wenn Sie einen Server speziell für diese Art von Clients installieren, sollten Sie darüber nachdenken, die Kosten dafür zu senken. Da der Client immer noch nicht in der Lage sein wird, Informationen sofort zu erhalten, ist eine sofortige Ausführung von Aufgaben nicht erforderlich.

Wenn Sie Beratung bei der Installation von Terminalservern oder dem Aufbau von darauf basierenden Unternehmensverwaltungssystemen benötigen, dann schreiben Sie mir per Mail.

Durch den Einsatz einer sinnvollen Kombination bestehender Technologien können die erstaunlichen Möglichkeiten dieser Art von Anwendung realisiert werden. Wenn wir beispielsweise den Apache-Webserver mit der Skriptsprache des PHP-Servers verbinden, erhalten wir einen Anwendungsserver. Doch im Marketing bezeichnet dieser Begriff meist eine komplexe Lösung, die alle notwendigen Technologiekomponenten enthält. Dieser Ansatz zum Aufbau eines Anwendungsservers erleichtert manchmal sogar die Entwicklung, da es Vereinheitlichungen der entwickelten Modelle und deren zentralisierten Support gibt.

Um die Frage zu beantworten, ob eine bestimmte Dienstsoftware als Anwendungsserver angesehen werden kann, ist es notwendig, ihre deklarierten Funktionen mit den Attributen zu vergleichen, die diesem Servertyp innewohnen:

Bereitstellung von Dienstleistungen für Programme.

Bereitstellen eines Containermodells für Anwendungen.

Anwendungsverwaltung bereitstellen. Darstellung der Mittel ihrer Entwicklung.

Einhaltung von Normen und Industriespezifikationen.

Pflege von Webseiten, weil es eine echte Nachfrage danach gibt.

Vorteile bei der Arbeit mit Applikationsservern:

Code- und Datenintegrität. Die Platzierung auf einem dedizierten Server garantiert allen Kunden den Zugriff auf die aktualisierte Software. Die Arbeit mit Daten aus veralteten Programmen ist ausgeschlossen.

Zentralisierte Verwaltung. Alle Änderungen an der Konfiguration von Anwendungsprogrammen werden zentral durchgeführt.

Sicherheit. Die Bedeutung des Artikels wird nicht diskutiert. Die Dienstanbieterprüfung wirkt sich nicht auf die Datenbankschicht aus, potenziell nicht vertrauenswürdige Clients werden in der mittleren Schicht aussortiert.

Leistung. Dem Anwendungsserver kann die Aufgabe zugewiesen werden, den Netzwerkverkehr auszugleichen. Das Ergebnis ist eine gleichmäßige Lastverteilung zwischen den physikalischen Servern des Systems.

Wie rentabel ist es, mit einem Applikationsserver zu arbeiten? Die Praxis beweist, dass eine Umverteilung der Gerätekosten von der Clientseite auf die Serverorganisation Geld sparen kann. Auch die Praxis, Software zu mieten, hat sich bewährt. Aber gleichzeitig scheinen die Kosten für die Serversoftware selbst und die Mittel, die für ihre Implementierung und Wartung erforderlich sind, (auf den ersten Blick) ziemlich beeindruckend zu sein.

Es gibt vielleicht nur einen Nachteil: Das auf der Basis des Anwendungsservers aufgebaute System ist zentralisiert. Kommt es plötzlich zu einem „Absturz“ des Servers, führt dies zur Nichtverfügbarkeit von Programmen für alle Clients. Bei Problemen mit der Netzwerkverbindung erhalten wir den gleichen Effekt. Dies ist jedoch ein Problem aller Netzwerklösungen, die die Infrastruktur öffentlicher Netze zur Datenübertragung nutzen.

Zuerst gab es einen Fileserver und einen Printserver, der Mailserver kam ziemlich schnell dazu. Wir hatten keine Zeit, uns richtig an Webserver zu gewöhnen, da uns das Schicksal vor neue Prüfungen stellt - bitte beherrschen Sie den Anwendungsserver. Ein besonderes Problem ergibt sich bei der Übersetzung des Konzepts ins Russische. Hier wird die Verwirrung einfach unvorstellbar. Ein erfahrener Leser mag verärgert ausrufen: „Eh! Was ist hier neu? Es ist nur ein einfacher Multilink: ein Anwendungsserver, ein Datenbankserver und ein Client!“ - und hör auf zu lesen. Der Anwendungsserver ist jedoch Fedot, aber nicht ganz dasselbe.

Beginnen wir also der Reihe nach, damit auch ein weniger erfahrener Leser versteht, was gemeint ist. Gegenstand unserer Überlegungen ist der Application Server bzw. der Application Server. Heutzutage ist es in Mode, Anzeigen als Vorwort in umgekehrter Reihenfolge zu geben - um aufzulisten, was nicht in dem steht, was geschrieben steht; entweder aus falscher Bescheidenheit oder nach Michelangelos Gebot: alles Überflüssige entfernen. Daher finden Sie in diesem Artikel keinen seriösen, evidenzbasierten Vergleich technischer Implementierungen von Anwendungsservern, Beschreibungen von Methoden und Techniken zum Arbeiten mit diesen Implementierungen, Beispieldateien, Auflistungen und Codefragmente - nur eine Liste von Quellen, in denen Sie finden können all dies ist gegeben. Hier werden wir uns mit allgemeineren, aber nicht weniger spannenden Fragen befassen – was ist ein Anwendungsserver, warum wird er benötigt, wie kauft und wählt man ihn aus und wie arbeitet man damit. Ich sehe die Unzufriedenheit der Leser voraus, die davon überzeugt sind, dass sie nicht in die "Küche" dürfen und daher niemand weiß, was in das gekochte Gericht gemischt wird. Ich werde kurze Überlegungen anstellen, warum man nicht nur rein technische Artikel lesen und schreiben sollte. Vor der Zubereitung von Speisen müssen Sie festlegen, was - Suppe oder Beilage, ein leichtes Abendessen oder Mittagessen für geladene Gäste - Sie müssen ein Menü erstellen, Speisen zubereiten, einen Herstellungsplan entwickeln und erst dann mit dem Kochritual fortfahren. Welche Phase wichtiger ist – dazu gibt es ein bekanntes Märchen, in dem sich ein Zimmermann, ein Schneider und ein Puppenspieler darüber streiten, wem die von ihnen gefertigte Puppe gehören soll. Soweit ich mich erinnere, hat der Puppenspieler im Märchen gewonnen, weil er es war, der der Puppe Leben eingehaucht hat. In diesem Sinne ist ein solcher Assistent zweifellos ein Programmierer-Entwickler. Ohne ihre Rolle im Geringsten zu unterschätzen, möchte ich dennoch feststellen, dass moderne Softwareanwendungen immer das Ergebnis von Teamarbeit sind. Daher kann das Versagen oder gar die unbefriedigende Leistung irgendeiner Zwischenstufe das Ganze hoffnungslos ruinieren.

Aber genug Knicks. Wir warten auf den Application Server, der es kaum erwarten kann, Sie davon zu überzeugen, dass Sie nicht darauf verzichten können.

So traurig es auch sein mag, sich wieder der allen Interessierten vertrauten Geschichte der Computertechnologie zuzuwenden, ohne dies wird der Application Server vor uns als Vagabund ohne Clan oder Stamm erscheinen. Aber ich werde versuchen, mich kurz zu fassen, zumal die Geschichte erst 50 Jahre alt ist, allerdings sehr flott. Die Hauptstadien dieser Geschichte sind in Abb. 1 dargestellt. ein.

Die erste Ära ist die Ära des exklusiven "Monolithen", als Computerprogramme oder später Softwarepakete auf einem einzigen Computer liefen. Zu dieser Zeit hatten potenzielle Verbraucher von Softwareprodukten keine große Wahl - entweder selbst entwickeln oder bei erfahrenen Leuten bestellen. Die damaligen Betriebssysteme gönnten sich keine Fülle von Möglichkeiten - die Anwendung funktioniert auf dem Rechner - und das ist gut so. Es konnte jahrelang funktionieren und die ein für alle Mal festgelegten Funktionen erfüllen, und alle waren glücklich. Diese Zeit wird oft als „Ära des Mainframes“ bezeichnet, obwohl gerade der Mainframe der „stillen Revolution“ nahe kam. Von ihnen aus wurde es möglich, mehrere „Augen“ an einem Server zu befestigen - Terminals, die einen reibungslosen Übergang in die „Client-Server-Ära“ ermöglichten. Hier kommt der „Server“ ins Spiel. Der Server arbeitet, dient und erfüllt die Aufgaben Seiner Majestät des Kunden. Der Client wächst von einem einfachen "schüchternen" Terminal zu einem wichtigen und bedeutenden Oberherrn. Der aktuelle revolutionäre Moment ist dadurch gekennzeichnet, dass Server nicht mehr in der alten Form existieren können und Clients nicht existieren wollen. Erstere kommen mit der Fülle an gestellten Anforderungen nicht zurecht, während letztere mit der Servicequalität für ihre Anfragen unzufrieden sind. Der Ausweg ist die weitere Spezialisierung. Was der unglückliche Server schnauft und schnauft, wird nun auf viele Server verteilt – Komponenten, von denen jede erfolgreich ihre Funktion erfüllt. In einem solchen Unternehmen werden Kunden zu gleichberechtigten Komponenten, deren Aufgabe es ist, funktionale Partner (andere Komponenten) für den vor dem Display sitzenden Benutzer darzustellen.

Da wir den Konstruktionsbegriff Monolith eingeführt haben, werden wir eine Konstruktions- und Architekturparallel angeben. Die erste ist die monolithische Ära, die Ära der Dolmen und Cromlechs, individuelle Lösungen, die spezifische Produktionsaufgaben für den Kunden automatisieren. Es gibt noch wenig Erfahrung – jedes Gebäude ist gewissermaßen ein Kunstwerk. Die zweite Ära - Siedlungen des gleichen Typs, von denen jede durch eine Burg (Server) und einfachere Gebäude (Clients) gekennzeichnet ist. Und wenn einfache Gebäude keinen großen architektonischen Wert haben, dann sind Schlösser stückweise und teure Lösungen. Und wir bewegen uns in die Ära der Massenentwicklung, wenn die "Konstruktion" von Softwareanwendungen in Betrieb genommen wird. Und egal wie sehr wir eine solche Entwicklung schelten, es ist diese Methode, die es uns ermöglicht, Gehäuse – Softwareanwendungen – für jeden zu einem vernünftigen Preis und in Echtzeit bereitzustellen.

Typische moderne Häuser werden normalerweise aus Blöcken oder Platten gebaut. Moderne Softwareanwendungen werden also aus Komponenten gebaut bzw. werden gebaut. (Eine Komponente ist ein unabhängiges Softwareprodukt, das das Objektparadigma unterstützt, einen separaten Bereich der Geschäftslogik implementiert und über offene Schnittstellen mit anderen Komponenten interagieren kann.) Diese Technologie wird die dringendsten Probleme der Computerwelt beantworten - reduzieren die Entwicklungszeit einer Softwareanwendung, Erleichterung des Implementierungsprozesses und Unterstützung der Flexibilität der implementierten Lösung. Auf Abb. 2 zeigt die Phasen des Lebenszyklus einer Softwareanwendung.

Die derzeitige Praxis, wenn eine ernsthafte Anwendung in mindestens zwei Jahren entwickelt wird, ist sowohl für Entwickler als auch für Verbraucher nachteilig. Erstere produzieren veraltete, nicht beanspruchte Softwareprodukte, während letztere keine Zeit haben, die Früchte der Automatisierung zu genießen, um eine Rendite und Kosten zu erzielen. Kaum war das Haus errichtet, stellte sich heraus, dass es nicht modernen Standards entspricht, die Mieter nicht darin wohnen wollen und es nur Platz beansprucht, der für den Neubau eines modernen Hauses genutzt werden kann.

Unter dem Motto „Schneller, leichter und flexibler“ entstehen moderne Business-Komponenten. Die Vorteile dieses Ansatzes lassen sich in einer langen Liste zusammenfassen: Skalierbarkeit, Stabilität, Verwaltbarkeit, Anpassbarkeit, Flexibilität, Portabilität, Wiederverwendbarkeit. Aber leider passieren im Leben keine Wunder, und wenn Schwierigkeiten und Probleme an einem Ort abgenommen haben, dann haben sie an einem anderen nur zugenommen. Damit die Komponenten interagieren können, muss ein „Kleber“ – eine Software-Zwischenschicht – entwickelt werden.

Wenn also auf der geschäftlichen Seite alles schön ist, wie auf einem verschlungenen Perserteppich, dann gibt es innen jede Menge allerlei Knoten und Haken. In den letzten Jahren hat die weltweite Software-Community eifrig versucht, Ordnung in diese falsche Seite zu bringen, wobei sie, wie gesagt werden muss, sehr erfolgreich war. Die Hauptmöglichkeit besteht hier in der Standardisierung von Komponenten, um sie auf eine einheitliche Natur zu bringen. Bausteine ​​müssen aufeinander abgestimmt sein. Teppichfäden sollten aus ähnlichen Materialien sein. Die Idee dabei ist ganz einfach – die externen Schnittstellen der Komponenten sollten im gleichen Stil – in der gleichen Sprache – beschrieben werden. Daher haben zwei derzeit bekannte Standards, CORBA und COM+, eigene Versionen von IDL – Interface Description Language – geschaffen. CORBA-, COM+- und Java-Technologie, die natürlich die Java-Sprache zur Beschreibung von Schnittstellen verwendet, bieten enge Ansätze für die Interaktion von Komponenten. Basierend auf der Beschreibung externer Schnittstellen werden für Client und Server Proxies (Proxys) erstellt, die es ihnen ermöglichen, in Echtzeit miteinander zu kommunizieren. Ein Proxy für einen Client wird Stub genannt, und ein Proxy für einen Server wird Skeleton genannt. (Wir waren uns einig – ich erhebe nicht den Anspruch, Technologien vorzustellen, sondern gebe nur einen kurzen Einblick. Daher gehe ich insbesondere nicht auf die Möglichkeiten des dynamischen Zusammenwirkens von Komponenten in der CORBA-Technologie ein, wenn externe Schnittstellen nicht an der definiert sind Zeitpunkt der Systemkompilierung und zusätzliche dynamische Elemente erscheinen.)

Nach der Standardisierung von Schnittstellen bewegte sich die globale Computergemeinschaft auf die nächste Standardisierungsstufe – die Komponenten selbst. Von Abb. 3 ist klar, was ich mit der nächsten Stufe der Standardisierung meine – weiter weg von der Hardware, näher und näher – zum Anwender. In der CORBA-Technologie ist dies:

• ССМ (CORBA Component Model) - Komponentenobjektmodell, Komponentenentwicklung des BOM-Geschäftsmodells - Business Object Model;
• BOCA (Business Object Component Architecture) - Prinzipien der Architektur von Komponentensystemen, Entwicklung von OMA (Object Management Architecture) zu einem höheren Standardisierungsniveau;
• CDL (Component Definition Language) - Komponentendefinitionssprache, Entwicklung von IDL.

Die Entwicklung dieser Standards schreitet jedoch nicht so schnell voran, wie es sich alle Interessenten wünschen. Aber die Enterprise Java Beans (EJB)-Technologie von Sun hat sich zu einem anerkannten Helden auf dem Gebiet der Komponentenstandardisierung entwickelt. Vielleicht liegt der Grund für seinen Erfolg darin, dass es im "Familienkreis" einer Programmiersprache viel einfacher ist, Interoperabilitätsprobleme zu lösen. Außerdem ist die Sprache jung und verspielt, was viele Probleme, wie zB das Aufrufen entfernter Methoden (RMI - Remote Method Invocation), alleine lösen kann. Es ist möglich, dass die universellen Ziele des OMG-Konsortiums, das die CORBA-Technologie entwickelt – die Kombination von Komponenten, die in verschiedenen Programmiersprachen geschrieben sind und auf verschiedenen Systemen und verschiedenen Computern in verschiedenen Teilen der Welt laufen – in diesem Fall eine Art Bremse sind. In Zukunft werden wir sehen, wie die beiden Technologien, nachdem sie ihre Ambitionen geschlossen und verworfen haben, zur Freude aller interessierten Parteien ein wunderbares Ergebnis liefern.

Was ist diese "Bohne" (Bohne - Bohne) und warum hat sie, nachdem sie schnell wie ein Flaschengeist in die Computerwelt gesprungen ist, bereits eine solche Popularität erlangt? Um die Definition von Sun so nah wie möglich an das Original zu übersetzen: „Es ist ein Modell zum Erstellen und Bereitstellen wiederverwendbarer Serverkomponenten, das in der Java-Sprache geschrieben ist.“ Lassen Sie uns mit Sun fortfahren, um diese Definition zu enträtseln: „Komponenten sind vorgefertigte Teile von Programmcode, die in laufende Anwendungssysteme installiert werden können.“ Wenn Java-Klassen ein Komponentenmodell für den Entwurf von Anwendungen in der Java-Technologie bilden, dann entwickeln Java Beans dieses Modell logischerweise auf der nächsten Ebene der Integration bei der Erstellung automatisierter Systeme und der Abstraktion vom Programmierprozess – der Implementierungsphase. Tatsächlich ist dies ein Übergang von der Entwicklung einer benutzerdefinierten Anwendung aus vorgefertigten Softwarekomponenten zum Zusammenbau vorhandener Komponenten aus vorgefertigten EJBs. Wenn die Häuser früher aus Ziegeln gebaut wurden, bestehen sie jetzt aus Abschnittsräumen. Das Wort „Enterprise“ im Namen von Enterprise Java Beans bedeutet eine neue Ebene technischer Herausforderungen, denen Softwareanwendungen gegenüberstehen. Solche Aufgaben sind Anwendungen auf Unternehmensebene vertraut: Unterstützung für Verteilung, Benennungsdienste, Transaktionen, Sicherheit, Benachrichtigungsmeldungen, Persistenz und so weiter. Es überrascht nicht, dass diese Liste der Liste der CORBA Technology Services ähnelt.

Aus Sicht der Entwicklung sind EJBs Java-Klassen eines speziellen Typs, zusammen mit einem Bean-Passport-Deskriptor und Laufzeiteinstellungen, die die Bean handhaben kann. Der Deployment Descriptor der Bean wiederum ist eine XML-Datei, die Regeln enthält, die sich auf die Verwaltung der Bean beziehen, wie z. B. Benutzerzugriffsrechte auf die Bean. Mehrere Beans können kombiniert werden, um Anwendungen, Java-Applets und neue Beans zu bilden.

Reis. 4. Enterprise Java Beans-Container

Gemäß der EJB-Technologie werden Beans-Bohnen in einer Hülse platziert - einem Container (Abb. 4). Der Container ist dafür verantwortlich, die Beans zu schützen und ihre Beziehung zur Außenwelt zu unterstützen: Registrierung und Registrierung von Objekten, Bereitstellung externer Schnittstellen für sie, Erstellen und Zerstören von Implementierungen dieser Objekte, Schutz der Sicherheit, Verwalten ihrer Zustände und Koordinieren von Transaktionen. Die Technologie gibt nicht vor, wie der Container konkret implementiert werden soll. Diese können von Multithreading-Prozessen auf einem einzelnen Server reichen, auf denen die Beans ausgeführt werden, bis hin zu kompletten Softwareanwendungen, die über Server und/oder Prozesse übertragen oder verteilt werden können. Client-Beans werden in virtuellen Containern wie Webseiten, Formularen, zusammengesetzten Dokumenten usw. verarbeitet.

Die Technologie definiert zwei Haupttypen von Bohnen. Session Beans – Client-Server-Interaktionssitzungen verarbeiten Client-Aktionen wie das Schreiben in eine Datenbank, das Durchführen von Berechnungen usw. Dies sind die Fenster des Kunden in die Welt der Softwareanwendungen. Sie wiederum sind ebenfalls von zwei Arten:

• Zustandslose Sitzung - wissen nicht, wie sie ihren Zustand speichern und nur während der aktuellen Sitzung existieren. Bei einem Ausfall kann die Sitzung nicht wiederhergestellt werden;
• Zustandsbehaftete Sitzung – ihren Zustand speichern; die Sitzung kann wiederhergestellt werden.

Entity Bean – Komponenten der Objektdarstellung von Daten, die im Speicher abgelegt werden. Entity Beans sind transaktional und wiederherstellbar. Jede Implementierung hat eine eindeutige Bezeichnung namens Primärschlüssel, ähnlich wie bei Datenbanktabellen. Diese Beans werden wiederum in zwei Gruppen eingeteilt, je nachdem, wie bestimmt wird, wo, in welchem ​​Speicher und wie Daten gespeichert werden:

• Bean-Managed Persistence - Unabhängige Beans, Speicherverwaltung erfolgt auf Bean-Ebene;
• Container-Managed Persistence – „Custodial“-Beans, deren Speicherung vom Container gesteuert wird.

Zusätzlich zu der Klasse, die die Funktionalität der Bean implementiert, enthält sie zwei obligatorische Klassen, die zwei Arten von Schnittstellen implementieren:

• Home-Schnittstelle - Zugriff auf die "Home"-Dienste der Bean, wie z. B. Starten oder Auflegen für eine Session-Bean oder Suchen nach einer Entity-Bean. Diese Schnittstelle implementiert alle Lebenszyklusdienste der Bean und ermöglicht es dem Container, sein Verhalten zu verwalten und zu verwalten.
• Remote Interface – Zugriff auf die Geschäftsdienste der Bean.

Clientanwendungen kommunizieren mit Beans über einen Container, der beide Schnittstellen der Bean verfügbar macht: Home und Remote. Mit Hilfe des ersten wird eine Sitzung eröffnet oder die gewünschte Bean gefunden, und mit Hilfe des zweiten werden die Aktionen des Clients in der Sitzung oder der Transaktionsmechanik der Verarbeitung der Entität verarbeitet.

Wiederholen wir also die Idee der Technologie aus angewandter Sicht. Die angewandte Geschäftslogik einer Anwendung wird in isolierte Geschäftsobjekte unterteilt, die jeweils als EJB implementiert sind. Sie werden auf dem Application Server oder EJB Server installiert und implementieren die angeforderte Logik für den Client (lokal oder remote). Lassen Sie uns gleich beim ersten Auftauchen des Konzepts des Application Servers in der Java-Technologie mit dem bereits am Anfang des Artikels erwähnten Missverständnis aufräumen. Indem wir beide Wörter, aus denen das Konzept besteht, in Großbuchstaben geschrieben haben, haben wir den Anwendungsserver, eine echte Maschine aus einem Gehäuse, Füllung und Kabeln, auf magische Weise in eine Softwareanwendung verwandelt.

Kehren wir zu Suns Interpretation zurück. Anwendungsserver in der Java-Technologie bezieht sich auf eine Softwareanwendung, die eine optimale Umgebung zum Ausführen von EJBs bereitstellt. Der Application Server ist an den "kommunalen Diensten" des Hauses - dem Softwaresystem - beteiligt. Es hat die Aufsicht über Systemressourcen wie Prozesse, Threads, Speicher, Datenbankkommunikation, Netzwerkbeziehungen und verteilten Knotenlastausgleich. Darüber hinaus besteht die wichtigste Aufgabe des Anwendungsservers darin, Schlüsselkomponenten bereitzustellen.

Ich möchte noch einmal betonen, dass die EJB-Technologie jedoch ebenso wie die CORBA-Technologie keine vorgefertigten Softwarelösungen – Container, Application Server, sondern nur Standards für diese Art von Software bereitstellt.

Standards sind die einzige Möglichkeit, in der boomenden Computerwelt für etwas Ordnung zu sorgen. Standards sind für alle drei interessierten Parteien im Bereich der Informationstechnologie notwendig: Entwickler, Verbraucher-Kunden und Zwischenglied - Berater, Integratoren, Verkäufer. Die erste – für die Bereitstellung wettbewerbsfähiger, marktfähiger Lösungen, die zweite – als Mittel zur Bekämpfung des „Zoos“ von Softwaresystemen, die dritte – als Möglichkeit, flexible, integrierte Softwareumgebungen für ihre Kunden aufzubauen.

Standards erobern weiterhin neue Bereiche der Informationstechnologie. Aber wenn sich Standards in Netzwerktechnologien vollständig durchgesetzt haben, dann gewinnen sie im Bereich der Softwareanwendungen nur an Bedeutung. Nachvollziehbar sind die Befürchtungen von Experten, bei eigenen Entscheidungen den „falschen“ Standard heranzuziehen, der oft trotz der dahinter stehenden kompetenten technischen Lösungen nicht über hervorragende Initiativen hinausgeht und keine Weiterentwicklung erfährt. Bei der Wahl eines Weges besteht immer die Gefahr, in einer Sackgasse zu landen. Deshalb sollten Sie die Schilder (im Sinne von Verkehrszeichen) sorgfältig lesen und auf die Meinung der Weltgemeinschaft hören. Anwendungsserver haben bereits Implementierungen von den meisten großen Softwaresystemherstellern (Inprise, Oracle, Sybase, Sun, BEA, Iona, IBM). Darüber hinaus ist in diesem Bereich der Softwareanwendungsarchitektur noch kein würdiger Konkurrent aufgetaucht. Der einzige Stil ist also bisher der Anwendungsserver.

Wenn Sie die Anwendungsserver mit den Augen des Endbenutzers betrachten, sind sie die wichtigsten unterstützenden Strukturen einer Struktur, die als verteiltes Softwaresystem mit mehreren Ebenen bezeichnet wird. Es sind die Anwendungsserver, die die Geschäftskomponenten bereitstellen und das erforderliche Maß an Systemdiensten für diese Komponenten bereitstellen, d. h. das gesamte öffentliche Lebenserhaltungssystem. Die Anwendungen, die unser Server den Kunden zur Verfügung stellt, können sich überall befinden, und diese Anwendungen wissen möglicherweise nicht einmal, wo die Daten, mit denen sie arbeiten, gespeichert sind – auf welchem ​​Server und in welcher Datenbank. Für Clients öffnet und schließt der Anwendungsserver Sitzungen. Für Anwendungen können Sie Systemdienste konfigurieren, von denen die wichtigsten der dauerhafte Speicherdienst, die Entity Beans-Speicherrichtlinie, der Transaktionsdienst und der Sicherheitsdienst sind.

„Ist es notwendig, den Garten einzuzäunen?“, wird ein ungläubiger Leser fragen. „Warum brauche ich eine solche zusätzliche Software für meine hochspezifische Softwareanwendung?“

Der Garten muss vielleicht nicht eingezäunt werden, aber es ist notwendig, unser Blockhaus mit Gas, Strom und Warmwasser zu versorgen, eine Softwareanwendung. Ja, und ein zuverlässiges Zahlenschloss an der Haustür schadet nicht. Natürlich können Sie diese Probleme den Mietern selbst überlassen. Lassen Sie jeden allein Wasser kochen und die Haustür stärken. Dann lieber einfach auf einen Baum klettern (ich meine damit keineswegs den NDS-Auskunftsdienst) und Bananen essen (nicht verwechseln mit Baan).

Damit der Aufbau einer Softwareanwendung nicht dem Bau des Turms von Babel gleicht, legt die EJB-Technologie fest, wer genau an dem Projekt teilnehmen soll. Das integrierte Bauteam des Gebäudes besteht laut Sun aus den folgenden Fachleuten.

Architekt

Ein EJB-Serveranbieter ist eine verteilte Plattform und ein Dienstanbieter. Es stellt die Entwicklungsinfrastruktur und Laufzeitumgebung für Softwareanwendungen bereit.

Konstrukteur

Der EJB Container Provider ist Experte für verteilte Systeme, Systemsicherheit und Transaktionsunterstützung. Es stellt einen Container auf Systemebene bereit, d. h. einen System-Wrapper für eine oder mehrere Enterprise Beans.

Anbieter

Ein Enterprise Bean Provider ist ein Analyst in einem Funktionsbereich, der als Entwickler Business Beans implementiert oder fertige auswählt.

Installateur

Der Application Assembler ist auch ein funktionaler Experte, der eine Softwareanwendung aus Bausteinen – Geschäftskomponenten – zusammensetzt. Seine Sicht auf das relevante Geschäft sollte allgemeiner und universeller sein als die des Einkäufers - Anbieter von Geschäftskomponenten.

Vorarbeiter

Deployer – spezialisiert auf die Installation von Anwendungen. Es richtet die Anwendung für die reale Umgebung ein.

Bauleiter

Systemadministrator (Systemadministrator) - stellt die Funktionsfähigkeit des Systems während der Betriebsphase sicher.

Nur weil Sun genau solche Rollen beschrieben hat, heißt das natürlich nicht, dass jedes Enterprise Java Beans-Projekt unbedingt eine und nur eine dieser Personen benötigt, und das ist die Zusammensetzung des integrierten Teams. Und es ist nicht so einfach, beispielsweise einen Lieferanten für fertige Container zu finden. Es ist absolut notwendig, die für das Komponentenprojekt spezifischen Momente nicht zu verpassen: die Auswahl der Architektur und die Art und Weise, wie Systemdienste implementiert werden, die Definition der Struktur und des Verhaltens von Containern und die Untersuchung von Implementierungsproblemen (Bereitstellung).

Nachdem wir den Ausflug ins EJB abgeschlossen haben, können wir die Definition des Application Server „mit einem Großbuchstaben“ geben. Ein Application Server ist ein Softwareprodukt, das eine Laufzeitumgebung für Anwendungskomponenten bereitstellt, die sich zwischen dem Client – ​​einerseits und Daten und Anwendungsprogrammen – andererseits befindet und die verschiedene Datenquellen und Anwendungsressourcen integrieren und den Komponenten zur Verfügung stellen kann die Dienstleistungen, die sie benötigen.

Der frustrierte Leser wird empört sein: „Warum haben sie uns EJBs erklärt, wenn in der Definition kein Wort darüber vorkommt!“ Ich werde versuchen zu erklären. Ich habe bewusst eine universelle Definition des Application Servers gegeben, die für alle Arten von Komponenten (CORBA, EJB, COM+) gilt. Anwendungsserver, die ihren Ursprung in der EJB-Technologie haben, haben sich als so komfortabel erwiesen, dass sie als eine Lösung für alle Komponententechnologien ziemlich selbstbewusst voranschreiten. Application Server-Implementierungen wissen bereits, wie man mit verschiedenen Komponenten arbeitet. Als Beispiel nenne ich den Inprise Application Server, der im Umfeld von EJB- und CORBA-Komponenten erfolgreich eingesetzt werden kann. Ein weiterer beobachteter Prozess ist die Konvergenz von Java- und CORBA-Technologien. Mit etwas Überwindung können wir davon ausgehen, dass EJBs eine doppelte Staatsbürgerschaft haben können, nämlich auch CORBA-Objekte sein können. Aus meiner Sicht ist die CORBA-Unterstützung eine notwendige Voraussetzung für die wettbewerbsfähige Implementierung des Application Servers. Tatsächlich unterstützt von allen aufgeführten Technologien nur diese Legacy-Systeme – funktional geeignet, aber technisch veraltet. Wenn wir den Automatisierungspark eines modernen Unternehmens oder einer Gesellschaft als eine Siedlung betrachten - ein Dorf oder eine Stadt, sollte die geschaffene intelligente Computerumgebung bestehende Gebäude umfassen. Ebenso falsch ist es, den Abriss bestehender Gebäude zu fordern oder zu ignorieren.

Ein weiterer Aspekt bei der Auswahl einer Application Server-Implementierung ist die priorisierte Funktionalität. Lassen Sie uns versuchen, Anwendungsserver in Gruppen zu unterteilen.

1. Integrationsanwendungsserver. (AAnwendungsserver)

Die Hauptaufgabe eines solchen Servers ist die Integration von Geschäftsanwendungen in eine einzige geistige Umgebung. Solche Server sind besonders relevant für die Organisation von Anwendungen im Zusammenhang mit Aufgaben wie Supply Chain (Supplier Chain) und E-Commerce. Zu diesen Servern gehören die Implementierungen der größten Anbieter von Object Request Brokern, Inprise und Iona.

2. Information Application Server (datenzentrischer Anwendungsserver)

Die Aktivität eines solchen Servers konzentriert sich auf die Datenmanipulation. Als Repositories können beliebige Anwendungen fungieren, die insbesondere nicht notwendigerweise relationale Datenbanken und erst recht Objektdatenbanken sind. Solche Server übernehmen die Organisation der Präsentation von verteilten Daten, die in verschiedenen Quellen im Objektparadigma gespeichert sind. Natürlich liefert Oracle Server dieser Art.

3. Verarbeitungszentrierter Anwendungsserver

Das zentrale Anliegen solcher Server ist die Bereitstellung spezifischer Geschäftslogik. Beispielsweise ein Server, der verteiltes Rechnen implementiert, oder ein ERP-Systemserver. Diese Implementierungen umfassen IBM Websphere.

4. Regelbasierter Anwendungsserver

Solche Server sind eine Teilmenge von Anwendungsverarbeitungsservern, aber im Gegensatz zu diesen konzentrieren sie sich auf die Ausführung bestimmter Geschäftsregeln. Sie konzentrieren sich vor allem auf den Bereich E-Commerce. Ein Beispiel für solche Server ist eine Implementierung von Vision Software.

5. XML-Server (XML-Server)

Dieser Server ist eine Untermenge des Information Servers, mit dem einzigen Unterschied, dass XML-Dokumente als Datenspeicher fungieren. Andererseits kann ein solcher Server eine Teilmenge des Integration Servers sein, in dem XML als Integrationsmechanismus gewählt wird. Bekannte Implementierung eines solchen Servers von der Firma Bluestone Software.

Sie sollten nicht glauben, dass die Einteilung der Anwendungsserver in Gruppen so eindeutig ist. Die interessantesten Instanzen von Application Servern kombinieren harmonisch die Vorteile verschiedener Gruppen. Darüber hinaus entwickeln Entwicklungsunternehmen ihre Produkte aktiv weiter. Und jede neue Version ist natürlich reichhaltiger als die vorherige.

Ich sehe die nächste Frage der Leser voraus: - „Geht das schon irgendwo?“ Die Antwort ist ja!". Anwendungsserver sind besonders gefragt rund um die Nutzung des Internets. Und durch die Unterstützung von Verteilung, Lastausgleichsfunktionen, Verfolgung verteilter heterogener Transaktionen, Sicherheitsverwaltung und vielen anderen Funktionen. Genau diese intelligenten Anwendungen finden in Application Servern starke Unterstützung.

Reis. 5. Java 2 Enterprise-Edition

Ich werde nebenbei die nächste Anstrengung in der Komponentensoftwaretechnologie erwähnen, die wiederum Java betrifft. Dies ist J2EE (Java 2 Enterprise Edition) – ein Standard für Multi-Tier-Systeme auf Unternehmensebene, eine Anwendungsplattform, die eine Interaktion zwischen Enterprise Java Beans, Java Server Pages, Applets und Servlets ermöglicht. Reis. Abbildung 5 zeigt genau, wie es bei Sun aussieht.

Die Interaktionsmittel zwischen den Komponenten befinden sich am unteren Rand der Figur. J2EE war das erste, das die Ausführung von Javas nativem Remote Method Invocation Protocol über das Internet, IIOP (Internet InterOrb Protocol), standardisierte. Damit ist die Zusammenarbeit zwischen CORBA und Java um einen weiteren Punkt reicher. Serverkomponenten sind in Container eingeschlossen, die über spezielle Konnektoren interagieren. Auf Containerebene werden Systemdienste festgelegt: Transaktionen, Nachrichten und E-Mail. Auf der obersten Ebene befinden sich die API und die Steuerelemente. Ich war gezwungen, im Zusammenhang mit Application Servern über diese Technologie zu sprechen, nicht nur durch die Tatsache, dass dieser Standard eine logische Weiterentwicklung der EJB-Technologie ist, in der unser Held zuerst definiert wurde, sondern auch durch die Tatsache, dass Application Server die erfüllen neue Standards erscheinen bereits. Ich meine den bereits erwähnten Application Server (Inprise).

Aber halt, ich fürchte, Sie sind schon müde von der Fülle an Technik und der Anhäufung von Standards? Wenn ja, siehe Abb. 6, wo ich versucht habe, alles zusammenzubringen.

Zur Verteidigung dieser ganzen Wirtschaft möchte ich anmerken, dass unsere Affenvorfahren, wie sie sagen, wunderbar in Bäumen lebten und wenn sie so etwas wie Nester für sich selbst bauten, aber keiner von uns zustimmen würde, dauerhaft dort zu leben, außer vielleicht, um es zu tun ein spannendes Abenteuer erleben. So kletterten Softwareanwendungen nach und nach von den Bäumen herunter und begannen, ihre eigenen Häuser zu bauen. Und wenn wir von Normen im Bauwesen sprechen, dann gibt es davon noch viel mehr als heute in der Informationstechnik. Als Trost möchte ich hinzufügen, dass unsere Standards gut miteinander auskommen. Zumindest lernen sie, wie es geht. Als Beispiel möchte ich Ihre Aufmerksamkeit auf die wiederholte Erwähnung des schmackhaften modernen XML-Standards in diesem Artikel lenken, der anscheinend über ganz andere Standards geschrieben wurde.

Ist es einfacher, Softwaresysteme mit Application Server zu erstellen? Ich hätte das Gesicht verzogen, wenn ich unmissverständlich geantwortet hätte – „ja“, obwohl ich das wirklich möchte. Wie bei jedem Werkzeug, und nicht einfach, muss man lernen, wie man es benutzt. Es sollte nur unter bestimmten Bedingungen angewendet werden, sowohl in Bezug auf die Infrastruktur als auch auf die Software. Eine separate Frage ist, welche Implementierung des Anwendungsservers verwendet werden sollte. Der Anwendungsserver ist ein wahrer Freund, aber nur für einen fürsorglichen und kompetenten Besitzer.

Über den Autor

Marina Anshina- ein Mitarbeiter der Systemintegrationsabteilung von TopS, Systemintegrator. Sie ist per E-Mail erreichbar unter: [E-Mail geschützt]

Moralkodex für einen jungen Softwareentwickler - Application Server

Quellen

27 Antworten

In den meisten Fällen werden diese Begriffe Webserver und Anwendungsserver synonym verwendet.

Im Folgenden sind einige der wichtigsten Unterschiede in der Funktionalität eines Webservers und eines Anwendungsservers aufgeführt:

• Der Webserver ist darauf ausgelegt, HTTP-Inhalte bereitzustellen. Der Anwendungsserver kann auch HTTP-Inhalte bereitstellen, ist aber nicht nur auf HTTP beschränkt. Es kann bereitgestellt werden, um andere Protokolle wie RMI/RPC zu unterstützen
• Der Webserver ist hauptsächlich darauf ausgelegt, statische Inhalte bereitzustellen, obwohl die meisten Webserver Plugins zur Unterstützung von Skriptsprachen wie Perl, PHP, ASP, JSP usw. haben, über die diese Server dynamische HTTP-Inhalte generieren können.
• Die meisten Anwendungsserver hosten einen Webserver, was bedeutet, dass ein Anwendungsserver alles tun kann, was ein Webserver tun kann. Darüber hinaus verfügt der Anwendungsserver über Komponenten und Funktionen zur Unterstützung von Diensten der Anwendungsschicht wie Verbindungspooling, Objektpooling, Transaktionsunterstützung, Messaging-Dienste und so weiter.
• Da sich Webserver gut für statische Inhalte und Anwendungsserver für dynamische Inhalte eignen, verfügen die meisten Produktionsumgebungen über einen Webserver, der als Reverse-Proxy für den Anwendungsserver fungiert. Das bedeutet, dass bei einer Seitenanforderung statischer Inhalt (wie Bilder/statisches HTML) von dem Webserver bereitgestellt wird, der die Anforderung interpretiert. Unter Verwendung einer Art Filtermethode (meistens Erweiterung der angeforderten Ressource) identifiziert der Webserver die dynamische Inhaltsanforderung und leitet den Anwendungsserver transparent weiter.

Ein Beispiel für eine solche Konfiguration ist der HTTP-Server Apache Tomcat und der WebLogic-Server von Oracle (früher BEA). Apache Tomcat HTTP Server ist ein Webserver und Oracle WebLogic ist ein Anwendungsserver.

In einigen Fällen sind die Server eng integriert, wie z. B. IIS und die .NET-Laufzeit. IIS ist ein Webserver. Bei Verwendung der .NET-Laufzeit kann IIS Anwendungen bereitstellen.

Beide Begriffe sind sehr allgemein, der eine enthält den anderen und in manchen Fällen auch umgekehrt.

Webserver: Dient für Inhalte im Internet unter Verwendung des http-Protokolls.

Apps-Server: Hostet und stellt Geschäftslogik und -prozesse bereit.

Ich denke, die Hauptsache ist, dass der Webserver alles über das HTTP-Protokoll verfügbar macht, während der Anwendungsserver nicht darauf beschränkt ist.

In vielen Szenarien werden Sie jedoch feststellen, dass der Webserver zum Erstellen eines Front-End-Anwendungsservers verwendet wird, was bedeutet, dass er eine Reihe von Webseiten bereitstellt, die es dem Benutzer ermöglichen, mit den Geschäftsregeln auf dem Anwendungsserver zu interagieren.

Dies ist eine detaillierte Antwort mit einigen Szenarien, um die Unterschiede und Ähnlichkeiten klar zu verstehen und wie beide zusammenarbeiten können, und das war's

Apps-Server ist ein Begriff, mit dem manchmal verwechselt wird Webserver. Während der Webserver hauptsächlich behandelt HTTP-Protokolle, befasst sich der Anwendungsserver mit mehreren verschiedenen Protokollen, einschließlich unbegrenzt, HTTP.

Die Hauptaufgabe eines Webservers ist Website-Inhaltsanzeige, und dem Anwendungsserver Logik verantwortlich, die Interaktion zwischen dem Benutzer und dem angezeigten Inhalt. Apps-Server arbeitet zusammen mit einem Webserver, wo einer angezeigt wird und der andere interagiert.

Informationen, die zwischen einem Server und seinem Client übertragen werden, sind nicht auf ein einfaches Bildschirmlayout beschränkt, sondern auf die Interaktion zwischen ihnen.

In den meisten Fällen erstellt der Server diese Interaktion über Komponenten-API, wie J2EE (Java 2-Plattform), EJB (Enterprise JavaBean) und verschiedene andere Anwendungsmodelle.

Beispiel:

Der beste Weg, um den Unterschied zwischen Szenarien zu verstehen, in denen ein Anwendungsserver mit einem Webserver zusammenarbeitet, und einem Szenario, in dem es keinen Anwendungsserver gibt, ist ein Onlineshop.

Szenario 1: Webserver ohne Applikationsserver

Sie haben einen Online-Shop mit nur einem Webserver und einem Anwendungsserver. Auf der Website wird ein Bildschirm angezeigt, auf dem Sie ein Produkt auswählen können. Wenn Sie eine Anfrage senden, führt die Site eine Suche durch und gibt das HTML-Ergebnis an ihren Client zurück. Der Webserver sendet Ihre Anfrage direkt an den Datenbankserver (haben Sie Geduld, ich werde dies in unserem nächsten Nugget erklären) und wartet auf eine Antwort. Nach Erhalt formt der Webserver die Antwort in eine HTML-Datei und sendet sie an Ihren Webbrowser. Diese hin- und hergehende Kommunikation zwischen dem Server und dem Datenbankserver findet jedes Mal statt, wenn eine Abfrage ausgeführt wird.

Szenario 2: Webserver mit Anwendungsserver

Wenn die Abfrage, die Sie ausführen möchten, bereits zuvor ausgeführt wurde und sich die Daten seitdem nicht geändert haben, generiert der Server die Ergebnisse, ohne dass eine Abfrage an den Datenbankserver gesendet werden muss. Dies ermöglicht eine Echtzeitabfrage, bei der ein zweiter Client auf dieselben Informationen zugreifen und gültige Echtzeitinformationen erhalten kann, ohne eine weitere doppelte Abfrage an den Datenbankserver zu senden. Der Server fungiert im Wesentlichen als zwischengeschalteter Datenbankserver und Webserver. Dadurch können Informationen abgerufen werden, die wiederverwendet werden können, während es sich im ersten Szenario nicht um einen wiederverwendbaren Vorgang handelt, da diese Informationen in eine bestimmte und "kundenspezifische" HTML-Seite eingebettet sind. Der zweite Client müsste die Informationen erneut anfordern und eine weitere eingebettete HTML-Seite mit den angeforderten Informationen erhalten – sehr ineffizient. Ganz zu schweigen davon, dass dieser Servertyp sehr flexibel ist, da er seine eigenen Ressourcen verwalten kann, einschließlich Sicherheit, Transaktionsverarbeitung, Messaging und Ressourcenpooling.

Um so viele komplexe Aufgaben zu unterstützen, muss dieser Server über integrierte Redundanz, viel Rechenleistung und viel RAM verfügen, um alle Daten, die er in Echtzeit abruft, zu verarbeiten.

Hoffe das hilft.

Wie Rutesh und jmservera betonten, ist die Unterscheidung unscharf. Historisch gesehen waren sie unterschiedlich, aber in den 90er Jahren verschmolzen diese beiden zuvor unterschiedlichen Kategorien Funktionen und verschmolzen effektiv. Im Moment ist es am besten anzunehmen, dass die Produktkategorie Anwendungsserver eine strikte Obermenge der Kategorie Webserver ist.

Einige Geschichten. In den frühen Tagen des Mosaic-Browsers und der Inhaltsverlinkung gab es so etwas wie einen „Webserver“, der Webseiteninhalte und Bilder über HTTP bereitstellte. Der größte Teil des Inhalts war statisch, und HTTP 1.0 war nur eine Möglichkeit, Dateien zu senden. Die Kategorie „Webserver“ hat sich schnell dahingehend entwickelt, dass sie die Fähigkeit von CGI umfasst, bei jeder Webanforderung effizient einen Prozess auszuführen, um dynamische Inhalte zu erstellen. Auch HTTP ist ausgereifter geworden und die Produkte sind komplexer geworden, mit Caching-, Sicherheits- und Verwaltungsfunktionen. Als die Technologie ausgereift war, erhielten wir Java-spezifische serverseitige Technologie von Kiva und NetDynamics, die schließlich in JSP fusionierten. Microsoft hat ASP, glaube ich, 1996 zu Windows NT 4.0 hinzugefügt. Der statische Webserver lernte einige neue Tricks, sodass er für viele Szenarien ein effizienter „App-Server“ war.

In der parallelen Kategorie hat sich der Anwendungsserver entwickelt und existiert seit langem. Unternehmen lieferten Unix-Produkte wie Tuxedo, TopEnd, Encina, die philosophisch von Mainframe-Anwendungsverwaltungs- und Überwachungsanwendungen wie IMS und CICS abgeleitet waren. Microsoft bot den Microsoft Transaction Server (MTS) an, der sich später zu COM+ entwickelte. Die meisten dieser Produkte haben "geschlossene" produktspezifische Kommunikationsprotokolle zum Verbinden von "Thick"-Clients mit Servern spezifiziert. (Für Encina war das Kommunikationsprotokoll DCE RPC, für MTS war es DCOM usw.). 1995/96 begannen diese traditionellen Anwendungsserverprodukte damit, grundlegende HTTP-Kommunikationsfunktionen zu implementieren, zunächst über Gateways. Und die Linien begannen zu verschwimmen.

Webserver sind in Bezug auf die Handhabung höherer Lasten, mehr Parallelität und besserer Funktionen immer ausgereifter geworden. Anwendungsserver stellen immer mehr HTTP-basierte Kommunikationsfähigkeiten bereit.

An dieser Stelle ist die Grenze zwischen „Anwendungsserver“ und „Webserver“ fließend. Aber die Leute verwenden die Begriffe weiterhin anders, als Akzent. Wenn jemand „Webserver“ sagt, denkt man oft an HTTP-basiert, webbasiert, anwendungsorientiert. Wenn jemand „Application Server“ sagt, denken Sie vielleicht an „schwerere Workloads, Unternehmensfunktionen, Transaktionen und Warteschlangen, Multi-Channel-Kommunikation (HTTP+ mehr). Aber oft ist es dasselbe Produkt, das beide Arten von Workload-Anforderungen erfüllt.

Webserver

Führen Sie python -m "SimpleHTTPServer" aus und navigieren Sie zu http://localhost:8080 . Was Sie sehen, ist der Webserver in Aktion. Der Server stellt einfach HTTP-Dateien bereit, die auf Ihrem Computer gespeichert sind. Der entscheidende Punkt ist, dass all dies auf dem HTTP-Protokoll basiert. Es gibt beispielsweise auch FTP-Server, die dasselbe tun (gespeicherte Dateien bereitstellen), jedoch über ein anderes Protokoll.

Apps-Server

Nehmen wir an, wir haben eine winzige App wie die unten (Auszug aus Flask).

@app.route("/") def Homepage(): return " Meine Homepage" @app.route("/about") def about(): return " Mein Name ist John"

Ein kleines Beispielprogramm bildet die URL / auf die homepage() der homepage()-Funktion und /about auf die about()-Funktion ab.

Um diesen Code auszuführen, benötigen wir einen Anwendungsserver (wie Gunicorn) – ein Programm oder Modul, das auf Anfragen des Clients warten und unseren Code verwenden kann, um dynamisch etwas zurückzugeben. Im Beispiel geben wir einfach sehr schlechtes HTML zurück.

Über welche Geschäftslogik sprechen alle anderen? Da die URL also irgendwo in unserer Codebasis zugeordnet ist, zeigen wir hypothetisch eine gewisse Logik darüber, wie unser Programm funktioniert.

zusammenfassend

Webserver- liefert Dateien, die irgendwo gespeichert sind (meistens .css, .html, .js). Gängige Webserver sind Apache, Nginx oder sogar Pythons SimpleHTTPServer.

Apps-Server- bedient Dateien, die im laufenden Betrieb erstellt wurden. Tatsächlich verfügen die meisten Webserver über eine Art Plugin oder verfügen sogar über integrierte Funktionen, um dies zu tun. Es gibt auch strenge Anwendungsserver wie Gunicorn (Python), Unicorn (Ruby), uWSGI (Python) usw.

Beachten Sie, dass Sie tatsächlich einen Webserver mit Anwendungsservercode erstellen können. Dies geschieht in einigen Fällen während der Entwicklung, wenn Sie nicht möchten, dass mehrere Milliarden verschiedene Server auf Ihrem Computer laufen.

Wie bereits erwähnt, handhaben Webserver HTTP-Petitionen und Anwendungsserver handhaben Petitionen für verteilte Komponenten. Der einfachste Weg, den Unterschied zu verstehen, besteht also darin, die beiden Produkte in Bezug auf die von ihnen angebotene Programmierumgebung zu vergleichen.

Webserver → Programmierumgebung

Anlegestelle: Servlet

Apache: PHP, CGI

Anwendungsserver → Programmierumgebung

WebLogic-Anwendungsserver: EJB

Der wichtigste Unterschied besteht darin, dass die Anwendungsserver die Technologie unterstützen verteilte Komponente, das Funktionen wie Remote-Aufruf und verteilte Transaktionen wie z EJB in der Java-Welt, bzw COM +/strong > auf der Microsoft-Plattform. Der HTTP-Server unterstützt oft einige einfachere Programmierumgebungen, oft Skripte wie ASP (.NET) im Fall von Microsoft oder Servlet einschließlich JSP und viele mehr im Fall von Java oder PHP und CGI im Fall von Apache.

Andere Funktionen wie Lastausgleich, Clustering, Sitzungs-Failover, Pooling usw., die früher im Bereich von Anwendungsservern lagen, werden jetzt auf Webservern sowie direkt oder über einige Produkte von Drittanbietern verfügbar.

Schließlich ist anzumerken, dass das Bild durch „leichte Container“ wie das Spring Framework verzerrt wird, die den Zweck von Anwendungsservern häufig auf einfachere Weise und ohne Anwendungsserverinfrastruktur ergänzen. Und da sich der Verteilungsaspekt von Anwendungen von einer verteilten Komponente zu einem Serviceparadigma und einer SOA-Architektur verlagert, gibt es immer weniger Platz für herkömmliche Anwendungsserver.

Der Webserver verarbeitet ausschließlich HTTP/HTTPS-Anfragen. Es stellt Inhalte im Internet unter Verwendung des HTTP/HTTPS-Protokolls bereit.

Ein Anwendungsserver dient der Geschäftslogik für Anwendungsprogramme über eine beliebige Anzahl von Protokollen, möglicherweise einschließlich HTTP. Ein Anwendungsprogramm kann diese Logik genauso verwenden, wie es eine Methode für ein Objekt aufrufen würde. In den meisten Fällen stellt der Server diese Geschäftslogik über eine Bean-API bereit, wie z. B. das EJB-Bean-Modell (Enterprise JavaBean), das in Java EE-Anwendungsservern (Java Platform, Enterprise Edition) zu finden ist. Die Hauptsache ist, dass der Webserver alles über das HTTP-Protokoll bereitstellt, während der Anwendungsserver nicht darauf beschränkt ist. Somit bietet ein Anwendungsserver viel mehr Dienste als ein Webserver, was normalerweise Folgendes umfasst:

• API (nativ oder nicht) API
• Verwaltung des Objektlebenszyklus
• Staatsverwaltung (Sitzung)
• Ressourcenverwaltung (z. B. Datenbankverbindungspools)

Bei den meisten Anwendungsservern ist der Webserver ein integraler Bestandteil von ihnen, was bedeutet, dass der Anwendungsserver alles tun kann, wozu der Webserver in der Lage ist. Darüber hinaus verfügt der Anwendungsserver über Komponenten und Funktionen zur Unterstützung von Diensten der Anwendungsschicht wie Pooling, Objektpooling, Transaktionsunterstützung, Messaging-Dienste und so weiter.

Der Anwendungsserver kann (aber nicht immer) auf dem Webserver laufen, um Programmlogik auszuführen, deren Ergebnisse dann vom Webserver geliefert werden können. Dieses Beispiel ist ein Web-/Anwendungsserverskript. Ein gutes Beispiel in der Microsoft-Welt ist die Internet Information Server/SharePoint Server-Beziehung. IIS ist ein Webserver; SharePoint ist ein Anwendungsserver. SharePoint sitzt auf IIS, führt bestimmte Logik aus und stellt die Ergebnisse über IIS bereit. In der Java-Welt gibt es beispielsweise mit Apache und Tomcat ein ähnliches Szenario.

Da sich Webserver gut für statische Inhalte und Anwendungsserver für dynamische Inhalte eignen, verfügen die meisten Produktionsumgebungen über einen Webserver, der als Reverse-Proxy für den Anwendungsserver fungiert. Das bedeutet, dass bei einer Seitenanforderung statische Inhalte wie Bilder/statisches HTML von dem Webserver bereitgestellt werden, der die Anforderung interpretiert. Unter Verwendung einer Art Filtermethode (meistens Erweiterung der angeforderten Ressource) identifiziert der Webserver die dynamische Inhaltsanforderung und leitet den Anwendungsserver transparent weiter.

Ein Beispiel für eine solche Konfiguration ist Apache HTTP Server und BEA WebLogic Server. Apache HTTP Server ist ein Webserver und BEA WebLogic ist ein Anwendungsserver. In einigen Fällen sind die Server eng integriert, wie z. B. IIS und die .NET-Laufzeit. IIS ist ein Webserver. wenn Sie eine .NET-Laufzeitumgebung haben. IIS kann Anwendungsdienste bereitstellen.

Programmierumgebung für Webserver Apache PHP, CGI IIS (Internet Information Server) ASP (.NET) Tomcat Servlet Jetty Servlet Programmierumgebung für Anwendungsserver WAS (IBM WebSphere Application Server) EJB WebLogic Application Server (Oracle's) EJB JBoss AS EJB MTS COM+

Der Hauptunterschied zwischen Webserver und Anwendungsserver besteht darin, dass der Webserver zum Bereitstellen statischer Seiten wie HTML und CSS dient, während der Anwendungsserver für das Generieren dynamischer Inhalte durch Ausführen von serverseitigem Code wie JSP, Servlet oder EJB verantwortlich ist.

Welche sollte ich verwenden?
Sobald Sie den Unterschied zwischen Webserver und Anwendungsserver und Webcontainern kennen, ist es einfach zu wissen, wann Sie sie verwenden sollten. Sie benötigen einen Webserver wie Apache HTTPD, wenn Sie statische Webseiten bereitstellen. Wenn Sie eine Java-Anwendung mit einer JSP und einem Servlet haben, um dynamische Inhalte zu generieren, benötigen Sie Webcontainer wie Tomcat oder Jetty. Wenn Sie jedoch eine Java EE-Anwendung haben, die EJBs, verteilte Transaktionen, Messaging und andere nützliche Funktionen verwendet, benötigen Sie einen vollwertigen Anwendungsserver wie JBoss, WebSphere oder Oracle WebLogic.

Der Webcontainer ist Teil des Webservers und der Webserver ist Teil des Anwendungsservers.

Ein Webserver besteht aus einem Webcontainer, während ein Anwendungsserver aus einem Webcontainer und einem EJB-Container besteht.

Der Webserver führt das HTTP-Protokoll zum Bereitstellen von Webseiten aus. Der Anwendungsserver kann (aber nicht immer) auf dem Webserver laufen, um Programmlogik auszuführen, deren Ergebnisse dann vom Webserver geliefert werden können. Dieses Beispiel ist ein Web-/Anwendungsserverskript.

Ein gutes Beispiel in der Microsoft-Welt ist die Internet Information Server/SharePoint Server-Beziehung. IIS ist ein Webserver; SharePoint ist ein Anwendungsserver. SharePoint sitzt auf IIS, führt bestimmte Logik aus und führt die Ergebnisse über IIS aus.

In der Java-Welt gibt es beispielsweise mit Apache und Tomcat ein ähnliches Szenario.

Der Anwendungsserver ist in der Regel so konzipiert und bereitgestellt, dass er längere Prozesse ermöglicht, die auch ressourcenintensiver sind.

Der Webserver wird für kurze Bursts verwendet, die normalerweise nicht ressourcenintensiv sind. Es macht es im Grunde einfacher, Web-Traffic zu bedienen.

Einerseits stellt der Webserver Webinhalte (HTML und statische Inhalte) über das HTTP-Protokoll bereit. Andererseits ist ein Anwendungsserver ein Container, in dem Sie mithilfe verschiedener Protokolle, einschließlich HTTP, in einer N-Tier-Architektur Geschäftslogik und Prozesse erstellen und für Clientanwendungen verfügbar machen können.

Somit bietet ein Anwendungsserver viel mehr Dienste als ein Webserver, was normalerweise Folgendes umfasst:

• API (nativ oder nicht) API
• Verwaltung des Objektlebenszyklus,
• Staatsverwaltung (Sitzung),
• Ressourcenverwaltung (z. B. Datenbankverbindungspools),
• Load-Balancing, Fehler...

In Java-Begriffen gibt es noch einen: Web-Container(oder genauer gesagt ein Servlet-Container). Dies ist beispielsweise zwischen einem Webserver und einem Anwendungsserver der Fall. Ein Web-Container in Java-Begriffen ist ein Anwendungsserver, der im Grunde nur den JSP/Servlet-Teil von Java EE implementiert und dem einige Kernteile von Java EE wie die EJB-Unterstützung fehlen. Ein Beispiel ist Apache Tomcat.

Der Grat zwischen den beiden wird immer schmaler.

Anwendungsserver stellen dem Client Geschäftslogik bereit. Daher umfasst ein solcher Anwendungsserver eine Reihe von Methoden (nicht notwendigerweise, obwohl es sich um einen Netzwerkcomputer handeln kann, auf dem viele Leute Software ausführen können), um Geschäftslogik auszuführen. Es gibt also nur die gewünschten Ergebnisse und nicht den HTML-Inhalt aus. (ähnlich dem Aufruf einer Methode). Es ist also nicht unbedingt ein HTTP-Protokoll.

Aber Webserver liefern HTML-Inhalte an Webbrowser (streng auf HTTP basierend). Webserver konnten nur statische Webressourcen verarbeiten, aber das Aufkommen von serverseitigem Scripting half Webservern, auch dynamische Inhalte zu verarbeiten. Wo der Webserver die Anfrage entgegennimmt und sie an ein Skript (PHP, JSP, CGI-Skripte usw.) weiterleitet, um den an den Client zu sendenden HTML-Inhalt zu ERSTELLEN. Der Webserver weiß dann, wie er sie an den Client zurücksendet. DENN was der Webserver wirklich weiß.

Allerdings verwenden Entwickler heutzutage beide Methoden zusammen. Wenn der Webserver die Anforderung akzeptiert und dann das Skript aufruft, um den HTML-Code zu generieren, ABER das Skript ruft erneut die LOGIK des Anwendungsservers auf (z. B. Get Transaction Data), um den HTML-Inhalt zu füllen.

Somit wurden in diesem Fall beide Server effektiv genutzt.

Daher .... Wir können mit Zuversicht sagen, dass Webserver derzeit in den meisten Fällen als Teilmenge von Anwendungsservern verwendet werden. Aber das ist nicht so.

Ich habe viele Artikel zu diesem Thema gelesen und fand es ziemlich praktisch.

Ein Anwendungsserver ist eine Maschine (tatsächlich ein ausführbarer Prozess, der auf einer Maschine läuft), die (auf jedem Kanal, mit jedem Protokoll) auf Client-Anforderungen für den von ihr bereitgestellten Dienst „lauscht“ und dann basierend auf diesen Anforderungen etwas tut. (kann eine Antwort vom Client erfordern oder nicht)

Ein Webserver läuft auf einem Computer, der speziell auf einem TCP/IP-Kanal mit einem der „Internetprotokolle“ (http, https, ftp usw.) „lauscht“ und auf der Grundlage dieser eingehenden Anforderungen alles tut, was er tut ... Typischerweise (wie in der Originalsprache definiert) würde es eine HTML-Seite abrufen/generieren und an den Client zurücksenden, entweder aus einer statischen HTML-Datei auf dem Server abgerufen oder dynamisch basierend auf den Parametern der eingehenden Anfrage des Clients erstellt.

All das Obige verkompliziert nur etwas sehr Einfaches. Der Applikationsserver enthält einen Webserver, der Applikationsserver hat ein paar mehr Ergänzungen/Erweiterungen als die Standard-Webserver. Wenn Sie sich TomEE als Beispiel ansehen:

CDI - Apache OpenWebBeans EJB - Apache OpenEJB JPA - Apache OpenJPA JSF - Apache MyFaces JSP - Apache Tomcat JSTL - Apache Tomcat JTA - Apache Geronimo Transaction Servlet - Apache Tomcat Javamail - Apache Geronimo JavaMail Bean-Validierung - Apache BVal

Sie werden sehen, dass Tomcat (Web-Container/Server) ein weiteres Tool im Arsenal der Anwendungsserver ist. Sie können JPA und andere Technologien in einem Webserver erhalten, wenn Sie möchten, aber Anwendungsserver packen all diese Dinge nur für Ihre Bequemlichkeit. Um vollständig als Anwendungsserver klassifiziert zu werden, müssen Sie sich im Wesentlichen an die Liste der von einem Standard definierten Tools halten.

Eigentlich ist Apache ein Webserver und Tomcat ein Anwendungsserver. Wenn eine HTTP-Anfrage beim Webserver ankommt. Der statische Inhalt wird dann über den Webserver an den Browser zurückgesendet. Gibt es eine Logik, um dies zu tun, und dann wird diese Anfrage an den Anwendungsserver gesendet. Nachdem die Logik verarbeitet wurde, wird die Antwort an den Webserver gesendet und an den Client gesendet.

EIN Webserver kann entweder ein Computerprogramm oder ein Computer sein, auf dem ein Programm ausgeführt wird, das dafür verantwortlich ist, HTTP-Anforderungen von Clients zu akzeptieren und HTTP-Antworten zusammen mit zusätzlichen Dateninhalten zurückzusenden, bei denen es sich normalerweise um Webseiten wie HTML-Dokumente und zugehörige Objekte handelt.

Server Anwendungen ist eine Art von Software, die verschiedene Anwendungen für ein anderes Gerät bereitstellt. Dies ist ein Computer in einem Büro- oder Universitätsnetzwerk, der es jedem im Netzwerk ermöglicht, Software auf demselben Computer auszuführen.