Tcp-IP Server an Rest Schnittstelle

[LucieneGarlet]

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]

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]

Dienst der über das TCP-IP Protokoll kommuniziert.

 

[mihe7]

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]

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]

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]

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]

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]

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

 

[mrBrown]

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]

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.

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]

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]

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]

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]

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]

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]

Eingehende Nachrichten puffern

Das war ja nicht gewollt:

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

Aber ohne gehts halt nicht...

 

[httpdigest]

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]

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]

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]

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...