# Tcp-IP Server an Rest Schnittstelle



## LucieneGarlet (14. Mrz 2019)

Hallo, 
ich muss eine Übersetzungssystem zwischen einem TCP-IP Server und einer Rest Schnittstelle bauen.

Ich habe daran gedacht alles in einem Wildfly laufen zulassen. Mein aktuelle Idee ist es die Kommunikation des TCP-IP Server mittels JCA zu handhaben. Über JCA wird dann die  Kommunikation des TCP-IP Server über eine MDB weiter an die Rest Schnittstelle gereicht. Natürlich sollte auch der Weg Rest zu TCP-IP auf dem selben Verfahren funktionieren.

Hat sonst jemand vielleicht noch einen anderen Ansatz?

VG

Lucy


----------



## mrBrown (14. Mrz 2019)

LucieneGarlet hat gesagt.:


> ich muss eine Übersetzungssystem zwischen einem TCP-IP Server und einer Rest Schnittstelle bauen.


Was meinst du in dem fall mit "TCP-IP Server"?


----------



## LucieneGarlet (14. Mrz 2019)

Dienst der über das TCP-IP Protokoll kommuniziert.


----------



## mihe7 (14. Mrz 2019)

Du sollst also eine TCP-Socketverbindung aufbauen und darüber mit einem Dienst kommunizieren. Welches Protokoll spricht der Dienst? Ein proprietäres? Wenn ja: gibt es dafür einen Client oder musst Du das Protokoll auch implementieren?


----------



## LucieneGarlet (14. Mrz 2019)

Der TCP-IP Dienst arbeitet asynchron und kann auch von selbst ausgehende Nachrichten senden. Darauf muss eine Socket Verbindung lauschen, aber auch selber Nachrichten an den Dienst senden. Diese Kommunikation muss dann an eine Restful Webschnittstelle weitergeleitet werden.


----------



## httpdigest (14. Mrz 2019)

Das passt nicht ganz zueinander. REST bzw. HTTP als verwendetes Transportprotokoll arbeitet synchron bzw. mittels Request-Response. Ein Client stellt eine Anfrage, z.B. HTTP GET, und bekommt synchron eine Antwort. Was du machen kannst, ist, alle Nachrichten, die vom Dienst kommen, zu puffern und dann bei einem REST GET Request auszuliefern.
Du könntest natürlich auch Long Polling oder WebSockets verwenden.


----------



## LucieneGarlet (14. Mrz 2019)

Ja die Probleme zwischen den Protokollen sind mir da schon bewusst. Puffern funktioniert da nicht wirklich, weil es muss ähnlich eines Chats recht flüssig laufen.


----------



## httpdigest (14. Mrz 2019)

Wenn dir das bewusst ist, warum willst du dann REST verwenden? Das geht ja offensichtlich nicht.
Ich würde das ganze mit einem ganz einfachen WebSocket Relay mit Spring Boot realisieren. Oder noch nicht mal mit Spring, sondern z.B. einfach mit Tomcat oder Undertow.
Wenn ich den ganzen overengineerten Java EE Mist schon wieder sehe, könnte ich kotzen.


----------



## mihe7 (14. Mrz 2019)

Hast Du Dir das schon angesehen? https://docs.oracle.com/javaee/7/tutorial/connectorexample.htm


----------



## mrBrown (14. Mrz 2019)

LucieneGarlet hat gesagt.:


> Dienst der über das TCP-IP Protokoll kommuniziert.


Das trifft halt auch auf die üblichen REST-Umsetzung Umsetzungen zu, von daher ist diese Aussage ziemlich nutzlos 
Das es eine asynchrone dauerhafte Socket-Verbindung ist, hilft da schon eher


----------



## LucieneGarlet (14. Mrz 2019)

httpdigest hat gesagt.:


> Wenn dir das bewusst ist, warum willst du dann REST verwenden? Das geht ja offensichtlich nicht.
> Ich würde das ganze mit einem ganz einfachen WebSocket Relay mit Spring Boot realisieren. Oder noch nicht mal mit Spring, sondern z.B. einfach mit Tomcat oder Undertow.
> Wenn ich den ganzen overengineerten Java EE Mist schon wieder sehe, könnte ich kotzen.



Das eine ist eine Altanwendung, welche nicht so leicht abgelöst werden kann. Daran muss eine neue Software (extern nicht selbst entwickelt) angekoppelt werden. Ob es nicht geht wird man erst sehen wenn man es versucht. 



mihe7 hat gesagt.:


> Hast Du Dir das schon angesehen? https://docs.oracle.com/javaee/7/tutorial/connectorexample.htm



Ja dadurch kam ich erst auf die Idee mit JCA und einer MDB.


----------



## mihe7 (14. Mrz 2019)

httpdigest hat gesagt.:


> Wenn ich den ganzen overengineerten Java EE Mist schon wieder sehe, könnte ich kotzen.


LOL - Du meinst das hier? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition


----------



## httpdigest (14. Mrz 2019)

LucieneGarlet hat gesagt.:


> Ob es nicht geht wird man erst sehen wenn man es versucht.


Du weißt aber schon, was HTTP genau ist und wie es genau funktioniert, oder?
Meine Empfehlung für Echtzeitverhalten: Implementiere einen JSR 356 (WebSocket) Endpoint in Wildfly und streame darüber die Nachrichten raus.


----------



## mrBrown (14. Mrz 2019)

LucieneGarlet hat gesagt.:


> Das eine ist eine Altanwendung, welche nicht so leicht abgelöst werden kann. Daran muss eine neue Software (extern nicht selbst entwickelt) angekoppelt werden. Ob es nicht geht wird man erst sehen wenn man es versucht.


Eigentlich kann man bei manchen Dingen von vornherein sagen, dass es nicht geht. Und das ist eines der Dinge, bei denen man einfach grundsätzlich sagen kann, es geht nicht.


----------



## httpdigest (14. Mrz 2019)

mihe7 hat gesagt.:


> LOL - Du meinst das hier? https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition


Das wiederum ist seeeehr seeehr cool! Sehr viele schöne Anekdoten zur Realität auch in den Issues. Ich könnt mich weghauen vor Lachen.


----------



## mihe7 (14. Mrz 2019)

Aber mal zurück zum Thema: warum sollte das nicht funktionieren? Eingehende Nachrichten puffern und beim Request (Polling) mit rausschicken. Wenn Antworten auf ausgehende Nachrichten sofort kommen, kann man auf die auch ein wenig warten. Es kommt halt sehr darauf an, was das für Anwendungen sind, die da miteinander kommunizieren (sollen).


----------



## mrBrown (14. Mrz 2019)

mihe7 hat gesagt.:


> Eingehende Nachrichten puffern


Das war ja nicht gewollt:


LucieneGarlet hat gesagt.:


> Puffern funktioniert da nicht wirklich, weil es muss ähnlich eines Chats recht flüssig laufen.



Aber ohne gehts halt nicht...


----------



## httpdigest (14. Mrz 2019)

Man kann die Kommunikationsstrecke natürlich auch umdrehen. Lasse deinen Wildfly Server einfach hierfür der REST _Client_ sein und bei eingehender Nachricht sofort einen HTTP Request an einen Consumer/Subscriber senden.
Da ist man dann aber schnell beim Java Message Service (JMS).


----------



## mihe7 (14. Mrz 2019)

mrBrown hat gesagt.:


> Das war ja nicht gewollt:


Oh, das hatte ich gar nicht gesehen  Das müssen die Tränen in den Augen gewesen sein, aufgrund des darauf folgenden Kommentars von @httpdigest.


----------



## mihe7 (14. Mrz 2019)

httpdigest hat gesagt.:


> Lasse deinen Wildfly Server einfach hierfür der REST _Client_ sein und bei eingehender Nachricht sofort einen HTTP Request an einen Consumer/Subscriber senden.


Jetzt komm hier nicht noch mit Lösungen an, wenn ich mich gerade damit abgefunden habe, dass es nicht geht.


----------



## httpdigest (14. Mrz 2019)

mihe7 hat gesagt.:


> Jetzt komm hier nicht noch mit Lösungen an, wenn ich mich gerade damit abgefunden habe, dass es nicht geht.


Sorry.  Ich hoffe noch auf @LucieneGarlet zu sagen, dass das in diese Richtung nicht gehen wird, weil ...something something... Client muss HTTP Anfrage stellen ...something...


----------

