# Java EE (am Cleint) und websocket



## ArkLut (1. Aug 2018)

Hi,

Ich hab ja immer wieder meine Verständnisprobleme mit java EE.
In meinem Weltbild ist Java EE eigentlich nur eine Library die Java SE erweitert.

Jetzt will ich eine Anwendung schreiben die am Client läuft, die aber mit einem Browser per WebSocket kommuniziert (Simpler Heart Beat + dann was auf dem Java Client auch anzeigen).

Ich habe dazu folgendes Tutorial gefunden:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/HomeWebsocket/WebsocketHome.html

Das sieht auch eigentlich ganz leicht allerdings ist das ja nur für Applikation Server gedacht.
meine Anwendung ist aber eine einfache Swing Anwendung -> kann man in diese nicht mit Java EE integrieren (also am Client)?

Wenn nein was würdet ihr für Standard JRE empfehlen (gibts da was) um WebSocket mit einem browser zu sprechen?


----------



## mihe7 (1. Aug 2018)

ArkLut hat gesagt.:


> In meinem Weltbild ist Java EE eigentlich nur eine Library die Java SE erweitert.


Java EE ist eine Menge an Spezifikationen. Eine davon ist JSR 356 "Java API for WebSocket" (https://www.oracle.com/technetwork/articles/java/jsr356-1937161.html). Die Referenzimplementierung von JSR 356 ist "Project Tyrus". 

Wenn ich den Rest Deines Posts richtig verstehe, möchtest Du einen WebSocket-Server in eine Swing-Anwendung integrieren. 

Dafür gibt es verschiedene Libraries, die ggf. nicht JSR 356 umsetzen sondern ein eigenes API anbieten. Gibt man z. B. "java websocket" (ohne Anführungszeichen) in Google ein, erhält man als erstes Ergebnis https://github.com/TooTallNate/Java-WebSocket.

Allerdings scheint auch Tyrus ohne App-Server auszukommen: https://tyrus-project.github.io/documentation/1.12/index/getting-started.html


----------



## ArkLut (2. Aug 2018)

@JavaEE : Jah eh, das ist natürlich viel präzisiere.

@Websocket:
Was ich mir immer bei solchen libraries denke ist - wie soll ich sie auswählen.
Sie sollen:
- natürlich das erfüllen was ich brauche
- das möglichst einfach
- und ohne Overhead

aber, und das ist genau so wichtig - wie sieht es mim "LTS" aus - also wird das Projekt auch gewartet? auf längere Zeit (ich meine da schon mehre Jahre).
Deshalb bevorzuge ich immer wenn es da was direkt im JDK gibt.
Bei anderen Projekten fällt es mir dann immer schwer zu beurteilen wie verläßlich das noch länger lebt (Bin schon mal auf die Nase gefallen - und in einem professionelleren Umfeld ist das sowieso wichtig)

Kleine Frage nebenbei:
Gibt es einen Standard wie man seine eigenen Packages (also die GroupID) benennn soll?
Normalerweise nutzt man ja sZs die Domain rückwärts - aber private haben ja nicht alle eine Domain - was soll man da den nutzen?


----------



## mrBrown (2. Aug 2018)

ArkLut hat gesagt.:


> aber, und das ist genau so wichtig - wie sieht es mim "LTS" aus - also wird das Projekt auch gewartet? auf längere Zeit (ich meine da schon mehre Jahre).


Die Java-EE-Referenzimplementierung dürfte schon recht guten Support haben. Bei kleineren Projekten muss man im Zweifelsfall forken, wenn das von einzelnen Privatpersonen getragen wird, hängt das von denen und der Community ab, dabei Aussagen zu treffen, ist meist schwierig.



ArkLut hat gesagt.:


> Gibt es einen Standard wie man seine eigenen Packages (also die GroupID) benennn soll?
> Normalerweise nutzt man ja sZs die Domain rückwärts - aber private haben ja nicht alle eine Domain - was soll man da den nutzen?


Entweder die Domain (kostet ja kaum noch was  ) oder sonst den Sourcecode-Hoster statt eigener Domain, also z.B. com.github.foo, io.github.bar, net.sourceforge.baz


----------



## ArkLut (4. Aug 2018)

mrBrown hat gesagt.:


> Entweder die Domain (kostet ja kaum noch was  ) oder sonst den Sourcecode-Hoster statt eigener Domain, also z.B. com.github.foo, io.github.bar, net.sourceforge.baz


naja und wenn der source code hoster local.wohnzimmer ist 



mrBrown hat gesagt.:


> Die Java-EE-Referenzimplementierung dürfte schon recht guten Support haben. Bei kleineren Projekten muss man im Zweifelsfall forken, wenn das von einzelnen Privatpersonen getragen wird, hängt das von denen und der Community ab, dabei Aussagen zu treffen, ist meist schwierig.


Naja ich versuche es Grad in einer normalen Client Anwendung zum laufen zu bekommen .... Aber bevor ich mcih da noch mehr rein stürzte, wollte ich noch eine frage stellen:

Das eigentlich zugrundeliegende Problem:
Ich muß auf einer Desktop Maschine zwischen einer Java Client Anwendung (Swing) und einer Anwendung im Browser kommunizieren. Soll keine Große Kommunikation sein. Immer vom Browser zum Java Client: geht um einen Heartbeat (so 1 mal alle 15 Sekunden) + hin und wieder ein String (nie mehr als 256 Charakters) + einen Int.
Als Möglichkeit sehe ich nur Websocket oder http. Ist wohl aber beides blöd im Java Client einzubauen.
Kennt wer was passendes.


----------



## mrBrown (4. Aug 2018)

ArkLut hat gesagt.:


> naja und wenn der source code hoster local.wohnzimmer ist


Wenn der Code niemals dein Wohnzimmer verlässt, ist eh egal, wie du ihn nennst 



ArkLut hat gesagt.:


> Ich muß auf einer Desktop Maschine zwischen einer Java Client Anwendung (Swing) und einer Anwendung im Browser kommunizieren. Soll keine Große Kommunikation sein. Immer vom Browser zum Java Client: geht um einen Heartbeat (so 1 mal alle 15 Sekunden) + hin und wieder ein String (nie mehr als 256 Charakters) + einen Int.
> Als Möglichkeit sehe ich nur Websocket oder http. Ist wohl aber beides blöd im Java Client einzubauen.
> Kennt wer was passendes.


Das Problem ist eher die Verbindung von lokaler Anwendung und lokalem Browser (warum braucht es die überhaupt?)

Websocket und Http sind völlig normal auf Client-Seite und üblicherweise auch völlig problemlos  Kommt doch mittlerweile kein Programm mehr ohne aus...


----------



## mihe7 (4. Aug 2018)

ArkLut hat gesagt.:


> Ist wohl aber beides blöd im Java Client einzubauen. Kennt wer was passendes.


Der Java Client soll - wenn ich es richtig verstanden habe - zum Server für den Browser werden. Es ist schon etwas seltsam, in einer Desktop-Anwendung einen Server zur Verfügung zu stellen, damit vom gleichen Rechner aus per Browser zugegriffen werden kann.


----------



## ArkLut (5. Aug 2018)

mihe7 hat gesagt.:


> Der Java Client soll - wenn ich es richtig verstanden habe - zum Server für den Browser werden. Es ist schon etwas seltsam, in einer Desktop-Anwendung einen Server zur Verfügung zu stellen, damit vom gleichen Rechner aus per Browser zugegriffen werden kann.


Das tift es - seltsam aber war 



mrBrown hat gesagt.:


> Das Problem ist eher die Verbindung von lokaler Anwendung und lokalem Browser (warum braucht es die überhaupt?)


Ja, genau - naja um Daten aus zu tauschen und zu wissen ob die Anwendung im Browser offen ist.



mrBrown hat gesagt.:


> Websocket und Http sind völlig normal auf Client-Seite und üblicherweise auch völlig problemlos  Kommt doch mittlerweile kein Programm mehr ohne aus...


Naja, aber der "server teil" ist wohl nicht so problemlos.


----------



## mrBrown (5. Aug 2018)

Also soll *lokal* ein Server gestartet werden, auf den *lokal* zugegriffen wird?



ArkLut hat gesagt.:


> Naja, aber der "server teil" ist wohl nicht so problemlos.


Doch, ist weiterhin problemlos 
Man sollte nur nicht auf dem Gedanken beharren, dass man alle Anforderung ohne externe Libs umsetzt, dann sitzt man wirklich endlos dran und es ist nicht problemlos.

In dem Fall kann man lokal auch durchaus einen Applikation Server nutzen, zB Payara Micro


----------

