Hallo Hornetracer,
ich hab zwar sowas noch nicht gemacht, da ich bisher nur Applikationen in Java geschrieben hab, aber ich kann sagen, dass Servlets eigentlich zur dynamischen Generierung von Dokumenten wie html, xml u.Ä. gedacht sind.

Als Startseite (meinst Du das mit hauptteil?) würde ich ne JSP bevorzugen, da diese besser geeignet sind, viel statischen html-code auszugeben.
Mir ist aber nicht klar geworden, ob Du dieses Spiel als Enterprise Applikation oder normale Client-Server Applikation aufsetzen möchtest.
Wenn es eine Enterprise Applikation werden soll, dann sollten Servlets nach dem MVC-Muster nur die Schnittstelle zwischen der Optik (JSP o. JSF, vieleicht auch Applet) und dem Modell (EJB) sein. Aber selbst ein einfaches Kartenspiel ist bei Enterprise Applikationen schon aufwendig, da man bei der Kommunikation und dem Deployen von Beans einiges beachten muss.
Eine einfache Client-Server Aplikationen wäre für ein einfaches Spiel vieleicht besser geeignet.
Bin halt bei Applets selber nicht so firn drin. :cry:

Hab nochmal nachgeschlagen und find diese Architektur sehr merkwürdig! :?

Wie ich schon mal angedeutet hab, sind Servlets dazu da, dynamisch HTML-Code an den Client (Browser) zu schicken und sind Teil der Java Enterprise Edition. Ein Servlet wird durch GET-Anfragen oder POST-Anfragen auf dem Applikationsserver erzeugt. Die GET-Anfrage wird durch aufrufen der entsprechenden URL mittels Browser erzeugt und die POST-Anfrage wird durch ein HTML-Formular erzeugt.
Ob ein Applet auch POST-Anfragen an den Applikationsserver schicken kann, bin ich überfragt, da diese Architektur sehr ungewönlich ist.

Ein Minimal-Servlet würde als Beispiel so aussehen:


Demnach würde dein Servlet oder JSP (JSPs werden ja bei Aufruf zuerst in Servlets übersetzt) den Browser mit dem Applet bedienen und nicht umgekehrt.
Um weitere Kommunikation mit dem Applet zu ermöglichen musst Du Enterprise Java Beans schreiben, die auf Applikationsserver von dem Servlet erzeugt werden. Diese Beans stellen die Funktionaltität dann Serverseitig zur Verfügung und können über die Protokolle RMI, CORBA oder JMS angesteuert werden. Das ist es, was ich mit MVC (Modell-View-Control) meinte.
Als einfache und preiswerte Einstiegslektüre wäre Java 2EE - eBusiness-Anwendungen effizient programmiert gut geeignet.

Viel einfacher wäre es natürlich, wenn man selber einen Server als Applikation schreibt. Dann könnte man selber das Protokoll definieren und die Java Standard Edition würde reichen, aber, wie das gehostet werden kann, wäre dann ne andere Frage.

Nach dem angegebenen Text brauchst Du nicht mal diese obskuren Surf2000-Objekte.
Die Objekt-basierte HTTP Komunikation würde für deine Zwecke vollkommen reichen.
Dennoch brauchst Du aber noch persistente Komponenten, die das Spielprinzip beinhalten und dafür wären Java Beans am besten geeignet.
Theoretisch könntest Du die Logik des Spiels auch in ein Servlet packen, das Erzeugt wird, wenn der erste Spieler sich anmeldet. Dieses Servlet hätte aber nur solange Bestand, bis der erste Spieler sich wieder abmeldet, obwohl andere vieleicht noch weiterspielen wollen.
Die Kommunikation mit Java Beans erfolgt mit der RMI Kommunikation, die im angegebenen Text auch angesprochen wird.

Normales Java läuft nur in der Java VM, Enterprise Java Beans laufen dagegen zusätzlich in einem Applikationsserver (Fachlich auch CTMs bezeichnet - Component Transaction Monitor), der eine speziellen Laufzeitumebung bereitstellt, so dass verteilte Systeme leichter geschrieben werden können. Falls Du schon mal ein verteiltes System in C versucht hast zu schreiben, dann weißt Du, dass es die Hölle sein kann. Dieser Applikationsserver verlangt aber bei der Programmierung, dass man gewisse Interfaces (Home, Remote) erstellt, damit die Bean von einem Entfernten Client (der auch ein Bean sein kann) auch aufzufinden sind. Zusätzlich braucht der App.server noch zusätzliche XML-Dateien wie z.B. den sogenannten Deployement Deskriptor. Sevlets laufen dagegen nur auf dem Webserver und dienen bei flexiblen, verteilten Applikationen als Bindeglied zwischen der Optik und dem Programmiermodell.
Alle Eigenschaften und Fähigkeiten zu beschreiben würde den Rahmen sprengen.
Hol dir am besten das kleine Büchlein, für das ich schon mal geworben hab, da dort eine kurze Einführung in diese Materie stattfindet und es wird beschrieben, wie die verschiedenen Java Komponenten (Applets, JSP, Servlets, und EJB) miteinader arbeiten und kommunizieren können. Natürlich mußt Du dir auch das SDK für die Enterprise Edition holen, wo Suns Application Server enthalten ist. Als IDE bevorzuge ich NetBeans, da man dort auf einfache Weise neue Enterprise Projekte erstellen kann, die schon alle minimal nötigen Dateien beinhalten. Zusätzlich kann man dann in jedem Enterprise Projekt auf einfache Weise neue Beans oder Servlets erstellen. Auch eine Ansteurung des Web- u. Applikations Server kann über NetBeans erfolgen.