Unterschiede ASP, PHP, JSP, CFM und CGI

[vinter]

hi!

weiss zwar das dieses thema nix mit flash zutun hat aber ich habe keine ahnung wo ich sonst ne antwort finden kann.

ich arbeite seit kurzem mit ultradev und CFM will aber auch mal was mit PHP machen.

eins hat mich aber schon immer interessiert ... wo liegen die unterschiede zwischen ASP, PHP, JSP, CFM etc und CGI. die unterschiede zu CGI sind mir im groben eigentlich klar ... aber beim rest
wo sind die vor- und nachteile? wäre froh wenn mir da jemand weiterhelfen könnte vielleicht auch mit nem guten link.

grüsse vinter

[vinter]

ist die frage so dumm oder warum bekomm ich keine antwort?

[schorleschorsch]

also
ich bin nicht so versiert, aber ich habe mal mit ASP entwickelt, wobei ASP ja nur die Technik (Dynamik)ist und dann mit VBscript oder Javascript realisert wird. Habe damals auch mit ultradev mit die Seiten generieren lassen.
schön war, dass relativ schnell erste erfolge zu sehen waren.
aso erfordert (meines wissens) microsoft-umfeld (proprietär), also IIS oder PWS für dich zu hause zum testen.
angeblich war mal ein plugin für linux in arbeit (no guarantee).

php ist ganz einfach plattformunabhängig und finde ich ein bissl einfacher. wie es mit performance aussieht, oder welche technik mehr features bietet kann ich dir leider nicht sagen, da ich eigentlich nur kleine sachen, wie dynamische inhalte, pflegebereich und suchfunktionalität für webseiten brauche, dafür nehme ich php und mysql.
bei dem asp-kram damals war es mit access.
cfm ist auch eine dynamische technik und erfordert den coldfusionserver, welcher in meinen augen keine gute performance bringt.
hoffe ich konnte dir bissl was erzählen.
was man benutzen soll, hängt denk ich von der infrastruktur und der foirmenstrategie zusammen

[vinter]

also könnte man so sagen für asp braucht man nen personalwebserver und es ist ne microsoft erfindung?

php ist unabhäniger? aber meines wissens nach kann man php auch mit access verwenden oder? was muss dafür auf dem server wo es laufen soll installiert sein?

das für cfm coldfusion auf dem server installiert sein muss war mir klar weil ich damit arbeite

sind sich pws sich in der funktionsweise eigentlich ähnlich?

weiss jemand hier vielleicht noch was über JSP?

fragen über fragen

grüsse winter

[schorleschorsch]

natürlich kann man php auch mit Access benutzen, über ODBC, zum Beispiel, vielleicht auch anders.
access kann auf einem anderen rechner laufen (DB-Server) und im ODBC muss nur der Pfad hinterlegt werden, wobei ODBC auch von Microsoft implementierter Quasi-Standard ist als Schnittstelle zwischen Applikationen und Datenbanken.
Du brauchst halt PHP und zum Beispiel Apache-Webserver und Aceess und dann läufts.
JSP ist der objektorientierte Ansatz von serverbasiertem Sciptcode, man braucht auf dem Serber glaub ich irgendeine Javaengine oder sowas

Das wichtigste vorab: asp, php, jsp und cgi sind serverbasierte Scriptsprachen, d.h. die Scripte werden auf einem Server aufgerufen, interpretiert und als Standard-HTML-Seite an den Client zurückgegeben. Um die Scripte zu testen benötigt man also zumindest den Personal Webserver, besser ist natürlich ein Apache oder IIS o.ä.

ASP ist eine Erfindung von Winzigweich und basiert auf der Active-X-Technologie. Der Sprach- und Objektumfang ist relativ klein, Scripte können aber durch Einsatz von VBScript und eigenen Objektbibiliotheken erweitert werden.

PHP ist eine Entwicklung der OpenSource-Gemeinde und deshalb frei verfügbar. Der Befehls- und Objektvorrat ist ziemlich umfangreich; die Sprache selbst schnell zu lernen.

JSP sind die Java-basierten Serverscripte, also ähnlich ASP, nur eben nicht mit VBScripten, sondern mit Java-Objekten, -klassen und -applets versehen, die auf dem Server interpretiert werden.

CGI ist der Urahn dieser Serverbasierten Scriptsprachen. IMHO ist es sehr kryptisch, nicht ganz einfach zu lernen und wird deshalb durch das etwas "modernere" PHP wohl in Zukunft ersetzt werden.

Hoffe, das hat ein wenig Licht ins Dunkel gebracht!

[vinter]

also das es serverseitige scripte sind war mir schon klar

aber die unterschiede sind mir jetzt schon etwas deutlicher danke ....

wie ist denn so der befehlsumfang bei cfm? ähnlich viel wie bei php?

cgi unterscheidet sich doch von den anderen vier möglichkeiten weil es nicht in das html eingefügt wird sondern ein exteres script ist oder?

was ist eigentlich die Active-X-Technologie? und was heisst IMHO?
kann mir vielleicht noch jemand was über die notwendigen server (apache etc.) erzählen?

danke und viele grüsse vinter

Hi, viele deiner Fragen lassen sich nicht so ohne weit auszuschweifen klären, nur soviel: IMHO=In My Humble Opinion = meiner unmaßgeblichen Meinung nach...

Zu active-X gibbet sicherlich auf den Sites von Winzigweich mehr als ich erzählen könnte.

Zu den Servern: Was interessiert dich denn besonders? Mein Tipp: Zieh dir doch einfach den apache (www.apache.org oder so) aus dem Netz und spiel ein wenig damit rum oder installier den PWS aus dem NT Option Pack. Auch PHP bekommt man kostenlos im Internet...

CGI ist auch nur ein Script wie ASP oder PHP und wird ähnlich vom Server geparst. Es wird allerdings nicht wie die letztgenannten in eine HTML-Schablone gepackt.

[masterminded]

und ausserdem heisst CGI common gateway Interface und ist gar keine sprache, sondern nur eine schnittstelle. was ihr vermutlich meint ist perl...nur der korrektheit halber

[vinter]

Geschrieben von masterminded
und ausserdem heisst CGI common gateway Interface und ist gar keine sprache, sondern nur eine schnittstelle. was ihr vermutlich meint ist perl...nur der korrektheit halber

also das habe ich auch schon gelesen ... nur was meinen die mit schnittstelle?

[masterminded]

das heisst in diesem fall nix anderes, als das alle daten die rein oder raus gehen ueber diese schnittstelle laufen. es gibt zum beispiel eine standard ausgabe schnittstelle. das ist bei den meisten rechnern der monitor. das heisst einfach alles was das etikett 'ausgabe' traegt, wird vom system zum monitor geschickt.

in diesem fall bedeutet das das sich unseres lieben freunde, die scriptsprachen in dieser schnittstelle einnisten, und alle daten, die für sie interessant sind, abfangen, und bearbeiten...

bin leider kein computertechniker, deshalb kann ich nur versuchen meine idee davon wiederzugeben...

[dassoud]

jau, ist schon komisch, daß viele davon sprechen, sie könnten die scriptsprache CGI.

vielmehr müßte es heißen, "ich kann cgi-scripte schreiben".

vielleicht, weil manche scripte die endung .cgi haben?

dabei ist man ja nicht auf perl beschränkt, c/c++ geht ja auch.

ich muß zugeben, daß ich leider keinen plan von perl habe (ich bevorzuge php). die erklärung von masterminded finde ich aber klasse.

ach ja, die perl-scripte werden natürlich vom perl-interpreter geparst.

grüße, dassoud

[Albu]

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

[bobby]

@albu
vielen dank für diese ausführliche, sehr informative erklärung.

frage an die moderatoren:
könnte man diesen bericht vielleicht in den faq / tutorial bereich reintun ? sonst rutscht das schon in 2 tagen unten raus und das wäre schade.

[masterminded]

jepp! ab damit in den faq-bereich. ich finde albus statement sehr informativ und umfassend. koennte ja vielleicht von leuten die bspw. zu cfm mehr sagen koennen noch ewrgaenzt werden.