spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

HTTP ist eine super Idee, das meine ich ganz ehrlich. Das REST Pattern/die REST Philosophie solltest Dir auf jeden Fall anschauen, wenn Du mit Jersey arbeiten willst! Ein schönes Buch dazu (allgemein, ohne Java Bezug): [amazon]3898647323[/amazon]

Die Google App Engine ist auch auf jeden Fall einen Blick wert! Problem bei den ganzen PaaS Sachen ist, dass man permanent in Versuchung geführt wird in den "Vendor Lockin" zu tapsen. Das ist nicht unbedingt was schlechtes, man ist dann eben etwas unflexibler, was das Deployment betrifft. Um das zu umgehen, kann man an den Stellen, wo es keine großen Probleme macht "Java Standards" verwenden.

Solltest Du das Prinzip von Java Spezifikationen / "Standards" noch nicht so richtig erkannt haben: Im Java Community Process (JCP) werden als Java Specification Request (JSR) eingereichte Erweiterungen verabschiedet. Insbesondere für die Java Enterprise Edition (Java EE) kommen so häufig neue APIs dazu. Diese können dann von verschiedenen Firmen implementiert werden. So kommt es zu zahlreichen Java Produkten, die alle im Kern das gleiche tun (und auf die gleich zugegriffen werden kann), aber von unterschiedlichen Firmen gepflegt, vertrieben und verbessert werden. Auch für den JAX-RS (Java API for RESTful Web Services) Standard gibt es zahlreiche Implementierungen. Die Referenzimplementierung ist bei JAX-RS 2.0 momentan Jersey.

Soweit ich das sehe, ist Jersey mit GAE nicht so super (aber es geht). Daher überleg Dir gut, ob Du diese technischen Hürden nehmen willst, um Dein Projekt auch mal außerhalb der GAE laufen lassen zu können, oder letzteres zwar nicht so einfach geht, dafür die Entwicklung schneller und für die GAE optimiert vorangeht. Deine Anwendung wird ja irgendwann auch mal eine Datenbank benötigen, da stehst Du dann vor einem ähnlichen Problem. Zur Nutzung der JPA (Java Persistence API) findest Du allerdings wesentlich mehr Unterstützung, auch bei den GAE Docs (https://developers.google.com/appengine/…re/jpa/overview).

Heroku kannst Du Dir bei der Evaluation auch mal anschauen. Das ist ein recht bekannter PaaS Anbieter, bei dem AFAIK viel natürlicher mit den Java Standards gearbeitet werden kann.

Wenn Du keinen PaaS Anbieter nutzen willst, kann ich Dir aus persönlicher Erfahrung http://www.rackspace.com/ empfehlen. Für meine Diplomarbeit hatte ich da zeitweilig um die 10 Server am laufen, konnte sie recht bequem bedienen und meine Tests durchführen. Um Sicherheit und Co. muss man sich dann natürlich um so mehr kümmern. AFAIR braucht man allerdings eine Kreditkarte und muss volljährig sein, aber da können vielleicht ja auch mal die Eltern aushelfen (nur dass Du das gleich weißt, zur Verifikation hat damals bei mir ein englischsprachiger Mitarbeiter aus deren Call Center in England angerufen, keine Ahnung ob das immer noch so ist).


Neben der Java und .Net Welt solltest Du Dir auch mal http://nodejs.org/ anschauen (ein kleines Tut nach kurzem Googlen: http://koding.info/2014/01/nodejs-http-server/). Ich persönlich finde zwar javascript schrecklich und liebe mein Java, aber die Plattform ist populär und recht einfach zu handhaben. Für Webanwendungen ist mir da insbesondere https://www.meteor.com/ positiv aufgefallen.

Achja, bevor Du Dir aufwändige Verwaltungssysteme für Deine Java Server baust, denk immer daran, dass es die Java Management Extensions (JMX) gibt . Je nach verwandtem Framework kann man praktisch jede Klasse für die JVisualVM o.Ä. etc. mit bloßen Annotationen extern erreichbar machen, Auswertungsfunktionen ausführen und Statistiken basteln.

Als neutralen PaaS Anbieter zum Ausprobieren fand ich OpenShift von Redhat ganz nett. Man bekommt 3 kleine Instanzen (Gears genannt) kostenlos und kann sich damit sogar eine kleine Infrastruktur aus Application/Web Server, DB und Build/CI Server zusammenstellen. Bei Java sind die vorgegebenen Systeme zwar hauptsächlich JBoss basierend, aber es gibt gute Anleitungen wie man z.B. eine Jetty Instanz erzeugen kann.

Wenn es etwas schlankes werden soll kann ich aber eigentlich auch nur nochmal auf Node.js (Ich bevorzuge da Coffeescript statt Javascript) oder Python hinweisen. Mit Restify (Nodejs) oder Flask (Python) ist ein Rest-Service in wenigen Codezeilen implementiert.

Bei SourceTree hast du direkt im Menü unter Tools die Möglichkeit einen SSH Key zu erzeugen. Unter https://www.openshift.com/page/install-a…ent-for-windows siehst du wie du die Adresse vom Repo etc. bekommst. Statt dem Putty Teil sollte es bei SourceTree eigentlich reichen den private SSH Key in den Optionen anzugeben.

Ich hab SourceTree bisher noch nicht zusammen mit publickey Verfahren verwendet. Gehen sollte es aber. Die Anleitung unter http://www.sourcetreeapp.com/faq/ (letzter Punkt) beschreibt das auch noch mal. Die URL mit ssh:// sollte auch die richtige sein.

Das Deployment über Versionsverwaltung ist in der Weise praktisch, dass einfach per commit hook der Dienst neu gestartet werden kann, wenn alle Dateien auf dem neuen Stand sind. Es ist nicht immer wie bei PHP gegeben das neue Dateien ohne Neustart verwendet werden.