appserver.io – mittelfristig eine alternative zu J2EE?

Java hat sich über Jahre im Enterprise Umfeld als der defacto Standard für die Entwicklung von Enterprise Anwendungen etabliert. Keine bekannte Bank oder Versicherung verwendet eine Lösung die in einer anderen Programmiersprache realisiert wurde. Warum gibt es keine Alternativen zur Java Plattform? Diese Frage haben sich sicherlich schon viele Entwickler anderer Sprachen auf der einen Seite, Entscheider die nach kostengünstigeren, schneller zu entwickelnden und flexibleren Lösungen suchen, auf der anderen Seite gestellt.

PHP und die lange Geschichte hin zur Standardisierung

Mittlerweile hat sich, die im Webumfeld sehr populäre Programmiersprache PHP seit ihrer Entstehung 1995 zu einer ernstzunehmenden Alternative entwickelt. Ernstzunehmend deshalb, weil sich der Sprachkern von einer einfachen Skriptsprache hin zu einer modernen, objektorientierten Programmiersprache entwickelt hat und, was sicherlich im Enterprise Umfeld nicht weniger Gewicht hat, die Standardisierung der Sprache und damit auch von Komponenten und Libraries Einzug gehalten hat.


Was im Java Umfeld die JSRs (Java Specification Requests) sind, sind mittlerweile die PSRs für PHP. Eingeführt durch die PHP Framework Interop Group, die sich selbst 2009 während der php|tek aus einer Gruppe von 5 Framework Entwicklern gründete, sind mittlerweile, neben der PHP Community, über 20 stimmberechtigte Mitglieder in den Prozess der Definition neuer PSRs eingebunden.

Zwar haben mittlerweile erst fünf PSRs den Status ‚accepted‘, jedoch haben bereits PSR-0 bis PSR-2 dafür gesorgt, dass mittlerweile ein Großteil der auf GitHub zu findenden PHP Libraries diesen Standards folgen und somit, in fast allen Fällen, ohne Anpassungen in jedem beliebigen Projekt verwendet werden können. Dependency Manager wie z. B. Composer, die das direkte Einbinden von Libraries und deren Abhängigkeiten, auch aus einem Git Repository heraus, erlauben haben somit in den letzten beiden Jahren zu einer unglaublichen Vielfalt an neuen, qualitativ hochwertigen und sofort einsetzbarer Komponenten geführt. Genau diese Standardisierung und die damit verbundenen Merkmale hinsichtlich Wiederverwendbarkeit und Qualität von Komponenten ist, neben der Plattformunabhängigkeit, einer der Gründe warum sich Java so früh als die Programmiersprache für Enterprise Anwendungen etablieren konnte.

Welche Probleme treten bei der Entwicklung mit PHP auf?

Neben der Sprache an sich, die kompontentenbasierte Softwareentwicklung unterstützen sollte, spielen jedoch auch Services und die Infrastruktur die für den Betrieb einer Enterprise Anwendung benötigt werden, eine maßgebliche Rolle. Aktuell steht PHP hier vor dem Dilemma, dass zwar die Sprache mittlerweile alles Notwendige bietet, jedoch hinsichtlich Services und Infrastruktur eine starke Abhängigkeit zu externen Lösungen besteht. Das bedeutet, das neben PHP als Programmiersprache in einem größeren Projekt auch auch Know-How für alle der eingesetzten Lösungen vorhanden sein muss. Neben der teils komplexen Konfiguration des eingesetzten Webservers und der Datenbank (Cluster oder Master-Slave System) zählen hierzu hauptsächlich die Integration und Konfiguration von Caching-Systemen wie Memcache oder Varnish sowie etwaiger Message-Queues, Mailsystemen, Load-Balancern oder anderer Tools die die HA gewährleisten bzw. gewährleisten sollen.

Interessanter Weise machen sich im PHP Umfeld, im Gegensatz zu anderen Programmiersprachen, nur relativ wenige Entwickler darüber Gedanken, ob und welche Vorteile die Entwicklung einer PHP basierten Lösung für einen Großteil der vorgenannten Tools bieten würde. Der Hauptgrund hierfür scheint zum einen darin zu liegen, dass „es bisher immer so war“, zum Anderen im Ursprung von PHP, nämlich dem einer Skriptsprache die den Ansatz „share nothing“ verfolgt. „Share nothing“ bedeutet, dass jeder Aufruf einer Webseite die z. B. Inhalte dynamisch über PHP generiert, vollständig separat ohne Verbindung zu anderen Seitenaufrufen abläuft. Im einfachsten Fall bedeutet das, dass Resourcen wie z. B. Datenbankverbindungen bei jedem Seitenaufruf erneut aufgebaut, Daten gelesen und wieder geschlossen werden. Beim Einsatz moderner Frameworks wie TYPO3 Flow, Symfony oder Yii werden so bei jedem Aufruf, neben den zuvor angesprochenen Datenbankverbindungen, während des Bootstrappings Konfigurationsdateien eingelesen und verarbeitet, aus den dort hinterlegten Informationen Objekte erzeugt, die dann lediglich einen einzigen Request verarbeiten und anschließend wieder verworfen werden. Der Aufwand für die Bearbeitung eines Requests ist somit, relativ gesehen, enorm hoch. Trotz dieses hohen Initialaufwands für die Bearbeitung eines Requests, der sich durch die Modernisierung der Programmiersprache und der Einführung komplexer Frameworks noch erhöhen wird, scheint dieser Ansatz in weiten Teilen der Community als unwiderruflich akzeptiert, was ein Umdenken, der Weiterentwicklung und Optimierung der Programmiersprache in dieser Richtung stark einschränkt. Aktuell versuchen nahezu alle Frameworks, und damit auch alle Anwendungen die auf diesen Frameworks aufbauen, diesen Initialaufwand durch Caching, so weit wie möglich, zu reduzieren. Caching stellt die Entwickler jedoch, gerade bei dynamischen Anwendungen, vor die große Herausforderung, den Cache immer aktuell zu halten. Aufgrund der Komplexität moderner Applikationen treten insbesondere hier in der Realität häufig Probleme auf, die durch die tiefe Integration in den Anwendungskern schwer zu finden und deren Lösung sich somit häufig als kostenintensiv entpuppen.

Wie kann Multithreading bei der Lösung dieser Probleme helfen?

Mit Joe Watkins hat im August 2012 erstmals ein PHP Entwickler mit dem „share nothing“ Paradigma gebrochen und durch die Einführung von POSIX Threads eine völlig neue Welt mit nahezu unbegrenzten Möglichkeiten für die Entwicklung von Anwendungen eröffnet. Im Gegensatz zu den zuvor beschriebenen Abläufen lassen sich, durch den Einsatz von Threads, das Bootstrapping eines Frameworks oder einer Anwendung, einmalig auf den Start der Anwendung verlegen, einmal instanzierte Objekte persistent im Speicher des Servers ablegen und für die parallele Bearbeitung aller eingehenden Requests erneut verwenden. Diese Vorgehensweise spart zum Einen wertvolle Rechenzeit, optimiert die Ausnutzung der vorhandenen Server Infrastruktur hinsichtlich CPU und Speichernutzung und verspricht zum Anderen, neben dem Potenzial von Energieeinsparmöglichkeiten, eine höhere Performance bei der Bearbeitung von Requests was sich wiederum in geringeren Antwortzeiten beim Surfen, z. B. auf einem Shopsystem wie Magento, niederschlägt.

Bereits vor dem Erscheinen dieser PHP Erweiterung wurde vereinzelt versucht Lösungen zu entwickeln, die die gemeinsame Nutzung von Resourcen und Objekten ermöglichen. Jedoch erst die Einführung von Multithreading ermöglicht die Implementierung von schnellen, effizienten Diensten und Services, die auch genau dieser Anforderung gerecht werden können. Als eines der ersten Projekte hat sich appserver.io dieser Thematik gewidmet und zeigt, dass auch mit PHP als Programmiersprache die Entwicklung von Diensten wie einem stabilen und hochperformanten Webserver oder einer Message-Queue, die wiederum für den Einsatz von PHP basierten Anwendungen optimiert wurden, möglich sind.

Was ist ein Anwendungsserver?

Als Anwendungsserver, englisch Application Server, wird gemeinhin eine Software bezeichnet, die Anwendungsprogramme ausführt. Diese wenig aussagekräftige Definition beschreibt natürlich nur sehr vage das Potenzial das heutige Anwendungsserver im J2EE Umfeld zur Verfügung stellen. Eine etwas detailliertere Definition eines Anwendungsservers bietet hier das J2EE Komponentenmodell das im Jahre 2000 von Sun Microsystems als Plattform für unternehmensweite Anwendungen vorgestellt wurde. Neben der Plattform für die plattformunabhängige Ausführung von Programmen, also der Anwendungsserver an sich, spezifiziert J2EE auch die sogenannten Komponentenmodell, wobei das bekannteste sicherlich das der Enterprise Java Beans sein dürfte. Die Idee hinter J2EE ist, dass Softwarekomponenten, Dienste und Schnittstellen, die der SUN erstellten Spezifikation genügen, auch herstellerübergreifend interoperabel sind, sprich über Schnittstellen untereinander kommunizieren können.

Wie bereits angesprochen, konnte sich zwar im PHP Umfeld erst im Laufe der letzten Jahre eine Standardisierung etablieren, die jedoch noch sehr weit von der, im Java Umfeld akzeptierten, entfernt ist und aufgrund des völlig anderen Ursprungs und Aufbau der Community wohl auch nie erreicht werden wird. Ausserdem sollte man natürlich auch hinterfragen ob eine so tiefgreifende Standardisierung notwendig ist, und nicht an der ein oder anderen Stelle die Kreativität eher einengt also fördert. Nichtsdestotrotz lässt sich auch auf den bereits bestehenden Standards einiges Spezifikationen ableiten, die die Realisierung eines eigenen PHP Anwendungsservers zulässt.

So stellt appserver.io einen Stack an Services zur Verfügung, der die Basis für einen Großteil der in vielen PHP Projekten häufig benötigten Anforderungen, abdeckt. Bei den Services handelt es sich, wie bereits zuvor angedeutet, um Infrastruktur Dienste und Komponenten, die keine fertige Businesslogik, wie z. B. den Katalog in einem Shop zur Verfügung stellen, sondern vielmehr den Entwickler bei der Lösung, von immer wieder auftretenden Problemen, während der Realisierung des Katalogs unterstützen. Da eCommerce aktuell eines der beherrschenden Themen ist und viele Menschen, auf die ein oder andere Art damit in Kontakt kommen, lässt sich, um bei Beispiel des Katalogs zu bleiben, gut aufzeigen, wo Entwickler bei der Entwicklung eines Shops auf Probleme stoßen und welche, zum Teil erheblichen, Auswirkungen diese Probleme später auf den Betrieb und somit die Kunden als auch den Betreiber und seinen Geschäftserfolg haben.

Wie trägt ein Anwendungsserver zur Lösung meiner Probleme bei?

Nahezu jeder, der bei der Entwicklung seines eigenen oder dem Shop seines Arbeitgebers beteiligt war, wird die Frage der Entwickler nach der Anzahl an Artikeln, die später im Katalog gelistet werden sollen, kennen? Die Hintergründe der Frage beruhen fast immer auf der Problematik, dass mit zunehmender Anzahl an Artikel die Ladezeiten des Katalogs und die Zeit für den Import/die Aktualisierung der Artikel exponentiell zunehmen. Beide Probleme resultieren letztlich aus Einschränkungen, die die Programmiersprache PHP mit sich bringt. Wie bereits zuvor diskutiert, folgt PHP dem Programmieransatz „Share nothing“. Im diesem Fall führt das dazu, dass es standardmäßig nicht möglich ist, die einmal aus der Datenbank geladenen Produkte im Speicher des Servers zu halten und Diese mit jedem Request erneut zu laden. Um dieses Problem zu umgehen, haben sich mittlerweile Caching-Systeme etabliert, die jedoch, dazu führen, dass bei einer Änderung der Daten auch immer der Cache aktualisiert werden muss. Da in einem Anwendungsserver die Möglichkeit besteht, Objekte in den Arbeitsspeicher zu laden und dort vorzuhalten, lässt sich das Problem an dieser Stelle somit ohne den Einsatz eines Cache-Systems lösen.

Ein noch größeres Problem stellt der Datenimport dar. Hier besteht seitens PHP die Einschränkung, dass es, gestartet über die Konsole, per Definition ausschließlich in einem einzelnen Prozess läuft. Dies hat zur Folge, dass bei einem Datenimport von z. B. 100.000 Produkten, dieser, mit PHP Bordmitteln, auch nur auf maximal einem CPU Core ausgeführt wird. Somit wird, auch wenn ein Server mit 8 CPU’s á 4 Cores zur Verfügung steht, beim Importprozess von den 32 verfügbaren Cores lediglich Einer verwendet. Rechnet man für den Import eines Artikels der Einfachheit halber 0.5 Sekunden, so kommt man auf immerhin stolze 14 Stunden, was sich in der Realität nur relativ schwer verkaufen lassen dürfte. Durch Multithreading ergeben sich hier vollkommen neue Möglichkeiten. Anstatt des Einen können alle 32 Cores verwendet werden. Die knapp 14 Stunden für den Import lassen somit drastisch reduzieren, im besten Fall rein rechnerisch auf 0.5 Stunden. Auch wenn dieser Wert, da im Normalfall die Datenbank hier zum Engpass wird, natürlich rein theoretischer Natur ist, verdeutlicht er jedoch den Ursprung des Problems, nämlich, dass PHP ohne Multithreading in diesem Fall nicht alle verfügbaren Resourcen nutzt. Auch für diesen Fall gibt es natürlich Workarounds. So könnte man z. B. eine externe Message-Queue verwenden oder über die Konsole mehrere separate PHP Prozesse starten. Eleganter und effizienter lässt sich das Problem jedoch durch den Einsatz von Multithreading, wie es z. B. die mit einem Anwendungsserver standardmäßig ausgelieferte Message-Queue zur Verfügung stellt, lösen. Über diese lässt sich beispielsweise der Import, durch eine Aufteilung der zu importierenden Produkte in Bunches von jeweils 100 Artikel, parallelisieren. Der Import jedes Bunches erfolgt dann in einem eigenen Thread.

Allein dieses simple Beispiel zeigt, dass durch die derzeit gegebenen Eigenheiten der Programmiersprache PHP eine Vielzahl an Problemen existiert, die für den Entwickler ohne den Einsatz von Multithreading, nur relativ schwer zu lösen sind. Genau für derartige Anforderungen stellt ein Anwendungsserver wie appserver.io bereits fertige und einfach zu verwendende Komponenten zur Verfügung. Die Entwickler brauchen somit lediglich Know-How in der von Ihnen bevorzugten Programmiersprache PHP, anstatt sich mit einer Vielzahl an Drittanbieter-Lösungen, die möglicherweise in anderen Programmiersprachen implementiert wurden, auseinanderzusetzen. Dieser Ansatz bietet somit erhebliche Zeit- und Kosteneinsparungspotenziale.

Wann wird appserver.io für den Produktiveinsatz zur Verfügung stehen?

Aktuell befindet sich appserver.io noch in der Entwicklung, so dass die oben aufgezeigten Lösungsansätze z. T. nur in der Theorie existieren. Jedoch wird bereits Version 0.6.0 von appserver.io den Webserver und den Servlet Container in einer stabilen Version zur Verfügung stellen, die den Betrieb auf Testsystemen ermöglicht. Die aktuelle Version 0.5.9-beta, die neben diversen Linux Distributionen und Mac OS X auch für Windows zum Download bereit steht, zeigt bereits, dass die Entwicklung eines Webservers auf Basis von PHP und POSIX Threads möglich ist und, was für viele überraschend klingen mag, eine Performance bietet, die die bekannter Webserver wie Apache und nginx erheblich übersteigt. Dadurch entfällt die unmittelbare Abhängigkeit von einem der bekannten Webserver und der damit verbundenen Installation und Konfiguration, die sich für Laien bislang doch relativ komplex gestaltet.

Neben der hohen Performance bietet die Implementierung eines eigenen Anwendungsservers in PHP für PHP für die gesamte Community den großen Vorteil, dass jeder interessierte Entwickler sich im Rahmen eines Open Source Projektes über GitHub an der Weiterentwicklung beteiligen, oder optional sich die Sourcen, die unter der OSL 3.0 stehen, einfach herunterladen kann. Die Implementierung neuer Features sowie das Beheben von Bugs dürfte somit erheblich beschleunigt werden.

Zusätzlich zur RESTful API und dem Administrationsbereich, die die Installation weiterer Anwendungen wie z. B. Magento in Form von PHAR Archiven bequem per Drag-und-Drop erlauben, arbeitet das Entwicklungsteam derzeit an der Integration weiterer populärer Systeme wie TYPO3 CMS und TYPO3 Neos. Im Laufe der nächsten Versionen wird eine Kompatibilität mit allen Anwendungen, die für den Einsatz mit PHP 5.3+ ausgelegt wurden, angestrebt. Der Einsatz von Design-by-Contract, einem aus der Programmiersprache Eiffel übernommenen Programmieransatz, werden Stabilität, Robustheit und Sicherheit des Anwendungsservers auf ein für PHP Verhältnisse bisher nicht verfügbares Niveau heben.

Bis zur Version 1.0 werden dann alle für die Entwicklung benötigten Services in einer produktiv einsetzbaren Version fertiggestellt und ausgeliefert. Neben dem Webserver und dem Servlet Container zählen hierzu hauptsächlich der Persistence Container, die Message-Queue und der Timer Service. Ziel von appserver.io ist mittelfristig die Etablierung als defacto Standard für die Entwicklung von Enterprise PHP Anwendungen und als Alternative zu den schwerfälligen, teuren und mittlerweile auch in die Tage gekommenen J2EE Lösungen.

Wenngleich sich das Projekt aktuell noch in einem recht frühen Stadium befindet, setzen wir appserver.io zwischenzeitlich bereits für einige Projekte – sowohl im Magento-Umfeld – als auch im Bereich von Individualentwicklungen sehr erfolgreich ein und arbeiten aktuell an einigen Überraschungen, die wir auf absehbare Zeit vorstellen werden.

Ein Beispiel für die Verwendung von appserver.io im Bereich der Applikationsentwicklung ist das Open Source Projekt „EmberChat“ mit dem eine Open Source Chatsoftware auf Basis von appserver.io als Server und ember.js als Application Framework. Hierbei handelt es sich um eine Open Source Chatsoftware in etwa vergleichbar mit Hip-Chat, deren Besonderheiten u.a. in einer sehr ausgefeilten End-to-End-Encryption für Chats  besteht, wodurch das aktuell häufig heiß diskutierte Datenschutzthema in besonderem Maße berücksichtigt wird. Weitere Infos zu diesem Projekt findet man auf der EmberChat-Projektseite.

Mit appserver.io möchten wir eine extrem leistungsfähige und flexible PHP-Infrastruktur der Zukunft in einem Komplettpaket bereitstellen, das die nachfolgenden Komponenten enthalten wird:

Webserver
Stellt klassische Webserver-Funktionalitäten vergleichbar mit nginx oder Apache bereit, ist jedoch komplett in PHP implementiert

Timer Service
Ermöglicht dem Entwickler die Mikrosekunden genaue Ausführung von Funktionalitäten oder Jobs.

Persistence Container
Erleichtert dem Entwickler das Laden, Speichern, Aktualisieren und Löschen von Daten und kümmert sich ausserdem um das Management von Abhängigkeiten zwischen den Entitäten. Der Entwickler muss weniger Programmieren sondern kann einen Großteil der Aufgaben deklarativ erledigen, die Anwendung wird dadurch zusätzlich portabler.

Message-Queue
Abwicklung asynchroner, lang laufender Jobs wie z. B. den Import großer Datenmenge. Dieses appserver.io Features verwenden wir für den Import sehr großer Datenmengen in Magento. Durch die Unterstützung von Multi-Threading können Import-Prozesse signifikant beschleunigt werden.

Cache-Container
Einfache Möglichkeit häufig zu ladende Daten hochperformant im Speicher zu halten und somit z. B. rechenlastige Datenbankzugriffe zu minimieren.

WebSocket-Container
Erlaubt den Aufbau einer persistenten Verbindung zwischen Server und Client, z. B. über JavaScript, somit können auch aktiv vom Server Daten an den Client geschickt werden. Dieses Features wird beispielsweise für EmberChat genutzt.

SSH-Container
Erlaubt dem Admin/User/Betreiber den sicheren Zugriff und Verwaltung seines Servers.

 

Die genannten Dienste werden dabei über eine einfach zu bedienende Admin-Oberfläche gesteuert und konfiguriert. Derzeit verwenden wir hier eine rudimentäre Admin-Oberfläche. Die finale Version wird – soviel sei an dieser Stelle schon einmal verraten – richtig hübsch und wird es dem Administrator ermöglichen, seine PHP-Infrastruktur mit den relevanten Diensten über ein Cockpit zu überwachen und zu administrieren. Wie das Ganze dann aussehen wird, zeigen wir demnächst! Ein bisschen Spannung sollte ja erhalten bleiben…;-).

Über die Admin-Oberfläche lassen sich zudem – bereits jetzt schon – beliebige Applikationen (z.B. Magento) einfach per Drag & Drop installieren – ohne unnötigen Konfigurationsaufwand. Selbstverständlich behält der Administrator dabei jedoch nach wie vor alle Freiheiten und kann bei Bedarf manuell eingreifen, nachjustieren etc… Für  Standard-Anforderungen genügen wenige Mausklicks. Wie das Deployment von Magento mit appserver.io aussieht, zeigt dabei das nachfolgende Live-Video:

 

Da sowohl appserver.io als Technologie als auch die damit verbundenen Möglichkeiten noch sehr neu sind, würde uns das Feedback aus der Community enorm interessieren. Was haltet ihr von dieser Idee und diesem technologischen Ansatz? Wo seht ihr Einsatzmöglichkeiten? Wo gibt es aus Eurer Sicht noch Schwierigkeiten? Welche Fragen brennen Euch nach diesem Artikel auf der Seele? Was ist Euer erster Eindruck?

Wir freuen uns über jede Art von Feedback, Fragen, Kritik etc.!

(Autor: Tim Wagner, Head of Development / Design, TechDivision)

3 thoughts on “appserver.io – mittelfristig eine alternative zu J2EE?

  1. Appserver für PHP ist ja ganz nett.
    Aber Java Devloper werden einen PHP-Appserver sicher nicht als Alternative sehen.
    Nach Überfliegen des Artikels: Ja – PHP braucht (vielleicht) einen Appserver – aber was sollte einen JDev dazu bewegen das als Alternative zu sehen? Vor allem einen Appserver der sich noch nicht durchgesetzt hat …

  2. @unbekannt: Wir wollen mit appserver.io ja auch nicht die Java-Entwickler bekehren, sondern vielmehr einige der Vorteile aus Java – die zweifelsohne auch Probleme in PHP lösen können – für PHP bzw. PHP-Entwickler verfügbar machen. Es ist richtig, dass sich appserver.io noch nicht durchgesetzt hat. Aus unserer Sicht ist das aber auch nicht verwunderlich, weil es das Produkt erst in einer Beta-Version gibt und das Ganze noch Work-in-Progress ist… Wir sind da aber durchaus zuversichtlicht – zumal da noch einige Dinge in der Pipe sind… ;-). Wir haben inzwischen zwei erste große Projekte mit appserver.io im Livebetrieb und die Ergebnisse sind mitunter brachial. Nähere Infos dazu werden asap veröffentlichen.

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.