Sollte ich da was falsch verstanden haben, könnt ihr mich gerne korrigieren, wird mir mehr helfen als die vorherigen Posts
Der komplette Inhalt deines Postings ist entweder falsch, sehr ungenau oder irrelevant in Bezug auf deine ursprüngliche Fragestellung.
Ich möchte dir gerne noch einmal ans Herz legen meine bisherigen Antworten hierzu erneut zu lesen. Vielleicht mit ein bisschen Abstand - du sollst dich von den Antworten nicht persönlich angegriffen fühlen. Menschen neigen dazu, dann schnell auf Durchzug zu schalten und nichts, was nicht exakt ihren Vorstellungen entspricht, gelten zu lassen.
Ich kann auch gerne wieder dein gesamtes Posting zerpflücken und auf jeden Punkt einzeln eingehen, aber das hast du bisher auch nicht sonderlich wertgeschätzt.
Web Profil beinhaltet alles das, was man für eine typische Webapplikation benötigt
Kann man so ausdrücken, ja. Es ist aber wichtig zu verstehen, was mit der Aussage wirklich gemeint ist. Java EE allgemein kann man als Rahmenarchitektur (beziehungsweise eigentlich nur als die Spezifikation einer solchen) verstehen, die Standard-Lösungen zu Standard-Problem auf einem höheren Abstraktionslevel bereitstellt. Das Web Profile beschränkt sich dabei auf die Standard-Probleme (und -Lösungen) hinsichtlich der Web-Wntwicklung.
und der Vorteil ist das nicht benötigte Services abgeschaltet sind und es somit schlanker ist. (Full Profil habe nicht angeschaut)
Es wird nichts an- oder abgeschaltet. Dein Anwendungsserver stellt die entsprechenden Funktionalitäten zur Verfügung oder eben nicht. Der Anwendungsserver selbst ist der Teil, der leichgewichtiger wird, wenn er nicht die vollständige Spezifikation implementiert. Ein solcher ist dann in der Regel nicht so Resourcen-hungrig, wie ein vollständiger Java EE Anwendungsserver. Du musst im Grunde nur wissen, welche Teile der Spezifikation dein Anwendungsserver implementiert und kannst diese dann in deiner eigenen Anwendung nutzen. Beschränkst du dich in deiner Anwendung auf das Java EE Web Profile, dann ist diese (theoretisch jedenfalls) beliebig auf einen anderen Anwendungsserver, welcher (nur) das Java EE Web Profile implementiert, portierbar.
Per HTTP greift man auf den Server zu und übergibt per REST zwei zahlen, das erfolgt in so genanntem „Web Container“. Dann kommt EJB ins Spiel der „EJB Container“ EJB führt die Berechnung durch und greift auf die Datenbank zu um es abzuspeichern. Man kann es als Klassen verstehen eine Klasse Web Darstellung/Abfrage=„Web Container“ andere Klasse die Logik=„EJB Container“. Zusammen ergibt das einen Webserver.
Die Daten werden nicht per REST übergeben. Die Aussage ergibt überhaupt keinen Sinn! Die Daten werden (in der Regel) per HTTP(s) an den Server übergeben. REST ist eine
Eigenschaft des Webservices, der diese Daten verarbeitet. Das hatte ich aber auch in einem der vorherigen Postings bereits geschrieben... REST bedeutet in erster Linie einfach nur, dass der Service zustandslos ist. Das heißt insbesondere, dass jede Abfrage in sich geschlossen ist.
Der EJB Container führt deine Berechnungen nicht durch, das geschieht in "ganz normalem Java-Code". Der EJB Container ist auch nicht mit dieser Klasse für die Geschäftslogik gleichzusetzen, sondern der EJB Container ist ein Bestandteil des Anwendungsservers, der (u.A.) deine konkreten EJBs verwaltet. Du erstellst deine EJB nicht selbst, sondern fragst das Framework nach einer Instanz. Dadurch, dass das Framwork diese Instanz kennt, hat es die Möglichkeit in verschiedenster Art und Weise Einfluss auf das Geschehen zu nehmen.
auf die man per REST mit einem Client oder auch im Browser zugreifen kann.
Zu "REST" siehe oben. Desweiteren: Du scheinst den Begriff "Client" nicht richtig zu verstehen. Ein Webbrowser ist auch ein Client. Eine EJB kann auch ein Client einer anderen EJB oder eines WebServices sein. Ein WebService kann auch Client von was anderem sein. Ganz allgemein: ein A fragt ein B nach etwas. Optional antwortet B darauf an A. Dann ist A ein Client von B.