Flashforum - Einzelnen Beitrag anzeigen

Albu · 25-11-2001, 00:17

Hi All,

Also mit CFM hab ich noch nicht gearbeitet, aber vielleicht kann ich die Sprachen durch eine Klassifizierung noch genauer beleuchten:

CGI ist die für den Webserver einfachste Schnittstelle. Sie sollte von jedem Server unterstützt werden. Dies ist auch gleichzeitig die einzigste Möglichkeit perl Applikationen ins Web zu bringen. Was der Webserver bei einem CGI-Aufruf da für einen Prozess startet ist ihm egal. Alle GET und POST Parameter werden an den Prozess / das Programm über die Standardeingabe reingegeben und können dort abgeholt werden. Sämtliche Ausgaben des Programms müssen dann konsequenterweise über die Standardausgabe geschrieben werden, welche der Server 1:1 an den Browser weiterleitet.
Die Tatsache, daß ein extra Programm mit _jedem_ CGI Aufruf gestartet wird zeigt schon, daß dieses Interface nicht besonders schnell ist / sein kann. Es gibt allerdings ein FastCGI Interface, welches durch Pooling und Caching versucht ein bißchen Geschwindigkeit herauszuholen.
Prinzipiell würde ich aber eher die Finger von CGI lassen (auch wenn es Leute geben mag, die darauf schwören.), da z.B. PHP gegenüber Perl/CGI die weitaus unkomplizierte Variante bietet, bei ähnlicher Syntax der Programmiersprache.

Server Side Includes (SSI) bieten einen einfachen sehr minimalen Sprachumfang zur Erzeugung dynamischer Seiten (.shtml). Befehle werden hier in Form von eignen Tags im HTML selbst untergebracht. Der Webserver muß also jede .shtml Datei lesen und interpretieren, bevor sie an den Browser zurückgeht (Dies ist aber bei serverseitigen Skripten nicht unbedingt vermeidbar

). Auch diese Technik sollte von jedem Webserver unterstützt werden, ist aber wegen des relativ geringen Befehlssatzes und der Notwendigkeit bei komplexen Skripten auf CGI zurückgreifen zu müssen auch nicht das gelbe vom Ei.

ASP ist eine serverseitige Skriptsprache, die eigentlich keine Wünsche offen läßt. Durch die Möglichkeit beliebige ActiveX, bzw. COM Komponenten einzubinden, kann jede erdenkliche Funktionalität abgebildet werden. Wer mit VB programmiert, dem fällt ASP relativ leicht (Natürlich kommt HTML dazu und man muß sich in ein zustandsloses Protokoll (HTTP) hineindenken können). Auch hier werden die ASP Befehle und Codefragmente nahtlos in den HTML Code eingebettet und durch eigene Tags gekennzeichnet.
ASP erfordert zwingend einen Server von Microsoft und damit die Windows Plattform. Wer diese sowieso einsetzt, der hat mit ASP ein starkes Gespann, denn üblicherweise spielen Microsoft Komponenten untereinander i.d.R. problemlos zusammen. Protabilität kann man dabei aber vergessen. Einmal diese Plattform, immer diese Plattform

Datenbankzugriffe erfolgen hier mittels ODBC, DAO oder ADO.

PHP ist wie schon meine Vorredner erwähnten eine frei verfügbare serverseite Skriptsprache, die einen umfangreichen Befehlssatz mitbringt. PHP wird meist in Form von LAMP oder WAMP eingesetzt (Linux, Apache, MySQL und PHP oder Windows, Apache, MySQL und PHP), läuft aber auch mit anderen Webservern zusammen. PHP kann zum einen als CGI eingebunden werden, aber auch als Modul in den Webserver integriert werden (was zu favorisieren ist). Die beste Integration ist logischerweise mit Apache zu erreichen, aber auch mit IIS habe ich schon ein PHP zum Laufen gebracht. Auch in PHP sind Code und HTML in einer Datei vereint und durch entsprechende Tags gekennzeichnet.
Die Verfügbarkeit für nahezu jede erdenkliche / sinnvolle Plattform, bzw. Webserver + Betriebssystem Kombination sorgt für eine sehr hohe Plattformunabhängigkeit.
Datenbankzugriffe werden hier teilweise über ODBC angeboten, aber für die "grossen" DBMS gibt es direkte Funktionen (wie etwa für MSSQL, Oracle, mySQL, DBase, Progress, usw..), so daß man nicht das langsame ODBC verwenden muß (welches ja nur auf einem Windows Server verfügbar wäre).

CFM kenne ich zwar nicht, ich zähle es aber mal zu den serverseitigen Skriptsprachen. Viel sagen kann ich dazu nicht, allerdings ist CFM eine proprietäre Lösung von einem einzigen Hersteller und fällt damit fast zusammen mit ASP. Da nicht abzusehen ist, daß CFM ein derart hohe Verbreitung wie PHP oder Perl sollte man trotz der vermutlich sehr guten bis exzellenten Einbindung in die Entwicklungsumgebung auf eine zukunftsträchtigere Lösung setzen.

JSP gehört ebenfalls zu den serverseitigen Skriptsprachen und basiert auf Java. Auch hier wird der Code in HTML eingebettet. Bei der Programmierung steht der komplette Umfang von Java zur Verfügung, mit Ausnahme der grafischen und darstellenden Element. Diese können lediglich (wie überall sonst auch) als Applets über entsprechende Tags geladen werden. Bei JSP geht es ausschliesslich um die Erzeugung von dynamischen HTML Dateien.
Als Vorraussetzung für JSP ist ein installiertes JDK und eine JSP Engine wie z.B. Tomcat Jakarta zu nennen.
JSP Dateien werden auf dem Server beim ersten Aufruf kompiliert, und fortan als Servlet in der Engine gehalten. Dies erhöht die Geschwindigkeit beim erneuten Aufruf (Java ist ja allgemein als langsam verschriehen).
Durch den Einsatz von Java erkauft man sich einerseits eine enorme Plattformunabhängigkeit (noch größer als bei PHP), aber andererseits ist eine JSP Engine Pflicht, und die bekommt man bei einem normalen Provider i.d.R. nicht oder nur gegen Aufpreis (PHP dagegen ist fast schon Standard).
Datenbankzugriffe lassen sich nur über JDBC Treiber durchführen, diese sind aber für alle Datenbanken verfügbar.

Java Servlets sind in Java geschriebene Klassen, die eine ganz bestimmte Schnittstelle implementieren. Servlets werden, wie oben schon erwähnt, beim ersten Aufruf kompiliert und dann in einem Pool vorgehalten, um schnelle Zugriffe ab dem zweiten Aufruf zu ermöglichen. Anders als bei den serverseitigen Skriptsprachen liegt hier schon eine richtige Web Applikation vor. HTML Code ist kein Bestandteil mehr, der gleichberechtigt mit Skript Teilen in einer Datei wohnt, sondern wird jetzt über entsprechende write Befehle in den Ausgabestrom geschrieben (Dies ist in etwa vergleichbar mit der Standardausgabe der CGI Schnittstelle). Servlets erfordern eine Servlet Engine und ein installiertes JDK. Auch hier kann z.B. der Tomcat Jakarta zum Einsatz kommen (ob eine Servlet Engine auch JSP unterstützt kann vom Hersteller abhängen).
Der Unterschied zwischen JSP und Java Servlet ist hauptsächlich in der Schnittstelle zwischen Webserver und JSP, bzw. Servlet und in den darüber mitgelieferten Informationen zu sehen. Auch die Trennung von Code und Darstellung kann eine Rolle spielen, dies hängt aber auch stark von der Programmiertechnik ab.

EJBs Enterprise Java Beans sind fast schon der Mercedes der serverbasierten Logik. Hier spricht man nicht mehr von Skripts (denn es sind keine) oder von Servlets, sondern von Komponenten oder vielmehr Middleware. Dabei bilden EJB Beans lediglich die Business Logik ab, die Darstellung und die Datenhaltung macht "jemand anderes". Dies entspricht dem Three-Tiered Ansatz. EJBs können nicht alleine aufgerufen werden, es bedarf immer eines Servlets, einer JSP Seite, oder eines Browser Applets, um sich der Dienste sprich Logik zu bedienen. Dafür bietet EJB eine Menge Features, wie z.B. Objekte, die ihre Daten automatisch, ohne größere Programmierung oder Zutun des Entwicklers mit der Datenbank abgleichen (wird ein neues Objekt instanziert, legt man zugleich einen neuen Datensatz an, wird ein Objekt gelöscht, so wird auch der Datenssatz entfert, usw.), beliebige Verteilbarkeit der Komponenten auf mehrere Server, atomare Transaktionen zur Abwicklung eines Geschäftsprozesses oder Funktion, usw.
Um in den Genuß dieser Features zu kommen brauchst man allerdings einen Application Server und einen dazugehörigen Server. Die Referenzimplementation von Sun gibt es zum kostenlosen Download. Allerdings hat das Ganze nun rein gar nichts mehr mit Skripten zu tun und geht in Richtung Anwendungsentwicklung.

So hoffe der kurze

Überblick hilft weiter....

Ciao,

Albu

25-11-2001, 00:17	#13 (permalink)
Albu Neuer User Registriert seit: Jul 2001 Beiträge: 62	Hi All, Also mit CFM hab ich noch nicht gearbeitet, aber vielleicht kann ich die Sprachen durch eine Klassifizierung noch genauer beleuchten: CGI ist die für den Webserver einfachste Schnittstelle. Sie sollte von jedem Server unterstützt werden. Dies ist auch gleichzeitig die einzigste Möglichkeit perl Applikationen ins Web zu bringen. Was der Webserver bei einem CGI-Aufruf da für einen Prozess startet ist ihm egal. Alle GET und POST Parameter werden an den Prozess / das Programm über die Standardeingabe reingegeben und können dort abgeholt werden. Sämtliche Ausgaben des Programms müssen dann konsequenterweise über die Standardausgabe geschrieben werden, welche der Server 1:1 an den Browser weiterleitet. Die Tatsache, daß ein extra Programm mit _jedem_ CGI Aufruf gestartet wird zeigt schon, daß dieses Interface nicht besonders schnell ist / sein kann. Es gibt allerdings ein FastCGI Interface, welches durch Pooling und Caching versucht ein bißchen Geschwindigkeit herauszuholen. Prinzipiell würde ich aber eher die Finger von CGI lassen (auch wenn es Leute geben mag, die darauf schwören.), da z.B. PHP gegenüber Perl/CGI die weitaus unkomplizierte Variante bietet, bei ähnlicher Syntax der Programmiersprache. Server Side Includes (SSI) bieten einen einfachen sehr minimalen Sprachumfang zur Erzeugung dynamischer Seiten (.shtml). Befehle werden hier in Form von eignen Tags im HTML selbst untergebracht. Der Webserver muß also jede .shtml Datei lesen und interpretieren, bevor sie an den Browser zurückgeht (Dies ist aber bei serverseitigen Skripten nicht unbedingt vermeidbar ). Auch diese Technik sollte von jedem Webserver unterstützt werden, ist aber wegen des relativ geringen Befehlssatzes und der Notwendigkeit bei komplexen Skripten auf CGI zurückgreifen zu müssen auch nicht das gelbe vom Ei. ASP ist eine serverseitige Skriptsprache, die eigentlich keine Wünsche offen läßt. Durch die Möglichkeit beliebige ActiveX, bzw. COM Komponenten einzubinden, kann jede erdenkliche Funktionalität abgebildet werden. Wer mit VB programmiert, dem fällt ASP relativ leicht (Natürlich kommt HTML dazu und man muß sich in ein zustandsloses Protokoll (HTTP) hineindenken können). Auch hier werden die ASP Befehle und Codefragmente nahtlos in den HTML Code eingebettet und durch eigene Tags gekennzeichnet. ASP erfordert zwingend einen Server von Microsoft und damit die Windows Plattform. Wer diese sowieso einsetzt, der hat mit ASP ein starkes Gespann, denn üblicherweise spielen Microsoft Komponenten untereinander i.d.R. problemlos zusammen. Protabilität kann man dabei aber vergessen. Einmal diese Plattform, immer diese Plattform Datenbankzugriffe erfolgen hier mittels ODBC, DAO oder ADO. PHP ist wie schon meine Vorredner erwähnten eine frei verfügbare serverseite Skriptsprache, die einen umfangreichen Befehlssatz mitbringt. PHP wird meist in Form von LAMP oder WAMP eingesetzt (Linux, Apache, MySQL und PHP oder Windows, Apache, MySQL und PHP), läuft aber auch mit anderen Webservern zusammen. PHP kann zum einen als CGI eingebunden werden, aber auch als Modul in den Webserver integriert werden (was zu favorisieren ist). Die beste Integration ist logischerweise mit Apache zu erreichen, aber auch mit IIS habe ich schon ein PHP zum Laufen gebracht. Auch in PHP sind Code und HTML in einer Datei vereint und durch entsprechende Tags gekennzeichnet. Die Verfügbarkeit für nahezu jede erdenkliche / sinnvolle Plattform, bzw. Webserver + Betriebssystem Kombination sorgt für eine sehr hohe Plattformunabhängigkeit. Datenbankzugriffe werden hier teilweise über ODBC angeboten, aber für die "grossen" DBMS gibt es direkte Funktionen (wie etwa für MSSQL, Oracle, mySQL, DBase, Progress, usw..), so daß man nicht das langsame ODBC verwenden muß (welches ja nur auf einem Windows Server verfügbar wäre). CFM kenne ich zwar nicht, ich zähle es aber mal zu den serverseitigen Skriptsprachen. Viel sagen kann ich dazu nicht, allerdings ist CFM eine proprietäre Lösung von einem einzigen Hersteller und fällt damit fast zusammen mit ASP. Da nicht abzusehen ist, daß CFM ein derart hohe Verbreitung wie PHP oder Perl sollte man trotz der vermutlich sehr guten bis exzellenten Einbindung in die Entwicklungsumgebung auf eine zukunftsträchtigere Lösung setzen. JSP gehört ebenfalls zu den serverseitigen Skriptsprachen und basiert auf Java. Auch hier wird der Code in HTML eingebettet. Bei der Programmierung steht der komplette Umfang von Java zur Verfügung, mit Ausnahme der grafischen und darstellenden Element. Diese können lediglich (wie überall sonst auch) als Applets über entsprechende Tags geladen werden. Bei JSP geht es ausschliesslich um die Erzeugung von dynamischen HTML Dateien. Als Vorraussetzung für JSP ist ein installiertes JDK und eine JSP Engine wie z.B. Tomcat Jakarta zu nennen. JSP Dateien werden auf dem Server beim ersten Aufruf kompiliert, und fortan als Servlet in der Engine gehalten. Dies erhöht die Geschwindigkeit beim erneuten Aufruf (Java ist ja allgemein als langsam verschriehen). Durch den Einsatz von Java erkauft man sich einerseits eine enorme Plattformunabhängigkeit (noch größer als bei PHP), aber andererseits ist eine JSP Engine Pflicht, und die bekommt man bei einem normalen Provider i.d.R. nicht oder nur gegen Aufpreis (PHP dagegen ist fast schon Standard). Datenbankzugriffe lassen sich nur über JDBC Treiber durchführen, diese sind aber für alle Datenbanken verfügbar. Java Servlets sind in Java geschriebene Klassen, die eine ganz bestimmte Schnittstelle implementieren. Servlets werden, wie oben schon erwähnt, beim ersten Aufruf kompiliert und dann in einem Pool vorgehalten, um schnelle Zugriffe ab dem zweiten Aufruf zu ermöglichen. Anders als bei den serverseitigen Skriptsprachen liegt hier schon eine richtige Web Applikation vor. HTML Code ist kein Bestandteil mehr, der gleichberechtigt mit Skript Teilen in einer Datei wohnt, sondern wird jetzt über entsprechende write Befehle in den Ausgabestrom geschrieben (Dies ist in etwa vergleichbar mit der Standardausgabe der CGI Schnittstelle). Servlets erfordern eine Servlet Engine und ein installiertes JDK. Auch hier kann z.B. der Tomcat Jakarta zum Einsatz kommen (ob eine Servlet Engine auch JSP unterstützt kann vom Hersteller abhängen). Der Unterschied zwischen JSP und Java Servlet ist hauptsächlich in der Schnittstelle zwischen Webserver und JSP, bzw. Servlet und in den darüber mitgelieferten Informationen zu sehen. Auch die Trennung von Code und Darstellung kann eine Rolle spielen, dies hängt aber auch stark von der Programmiertechnik ab. EJBs Enterprise Java Beans sind fast schon der Mercedes der serverbasierten Logik. Hier spricht man nicht mehr von Skripts (denn es sind keine) oder von Servlets, sondern von Komponenten oder vielmehr Middleware. Dabei bilden EJB Beans lediglich die Business Logik ab, die Darstellung und die Datenhaltung macht "jemand anderes". Dies entspricht dem Three-Tiered Ansatz. EJBs können nicht alleine aufgerufen werden, es bedarf immer eines Servlets, einer JSP Seite, oder eines Browser Applets, um sich der Dienste sprich Logik zu bedienen. Dafür bietet EJB eine Menge Features, wie z.B. Objekte, die ihre Daten automatisch, ohne größere Programmierung oder Zutun des Entwicklers mit der Datenbank abgleichen (wird ein neues Objekt instanziert, legt man zugleich einen neuen Datensatz an, wird ein Objekt gelöscht, so wird auch der Datenssatz entfert, usw.), beliebige Verteilbarkeit der Komponenten auf mehrere Server, atomare Transaktionen zur Abwicklung eines Geschäftsprozesses oder Funktion, usw. Um in den Genuß dieser Features zu kommen brauchst man allerdings einen Application Server und einen dazugehörigen Server. Die Referenzimplementation von Sun gibt es zum kostenlosen Download. Allerdings hat das Ganze nun rein gar nichts mehr mit Skripten zu tun und geht in Richtung Anwendungsentwicklung. So hoffe der kurze Überblick hilft weiter.... Ciao, Albu __________________ 1. Get people to play Space Taxi 2. ????? 3. Profit!