RMI vs REST

[Gast2]

Hallo zusammen,

ich habe einen Desktopclient und einen Appplication-Sever (JBoss6). Ich frage mich was wohl am einfachsten und besten für die Kommunikation ist.
Beim JBoss6 ist RMI ja schon dabei und kann über JNDI Naming gleich genutzt werden oder? Stichwort @Remote

Schon mal jemand Erfahrungen mit REST oder RMI gemacht und kann mir sagen was er gut und schlecht fand/findet?

 

[mvitz]

Wenn wirklich nur dein Client darauf zugreifen muss und der auch in Java implementiert wird, hat RMI sicher den Vorteil sehr schlank und performant zu sein. Sobald die Schnittstelle auch für andere Clients/Sprachen verfügbar sein soll, ist RMI halt proprietär und REST eine bessere Wahl.

 

[Gast2]

Ja ich denke auch, dass ich erstmal RMI nehme, da es (bis jetzt) nicht vorgesehen ist, dass außer dem Java-Client jemand darauf zugreifen soll.

Aber ist RMI nicht veraltet?

 

[FArt]

Hallo zusammen,

ich habe einen Desktopclient und einen Appplication-Sever (JBoss6). Ich frage mich was wohl am einfachsten und besten für die Kommunikation ist.
Beim JBoss6 ist RMI ja schon dabei und kann über JNDI Naming gleich genutzt werden oder? Stichwort @Remote

Schon mal jemand Erfahrungen mit REST oder RMI gemacht und kann mir sagen was er gut und schlecht fand/findet?

Kann man eigentlich so nicht vergleichen, weil ja REST auch ein völlig ander Ansatz gegenüber RPC (also nicht RMI im Speziellen) ist.

JBoss hat die Transportschicht von der Enterpriseschicht getrennt. Wenn es also wie in deinem Fall um EJB Kommunikation geht, kann man da verschiedene Transportschichten verwenden (die heißen bei JBoss in dem Kontext "Invoker"). Ich weiß nicht wie es im JBoss 6 als Default festgelegt ist, aber ich glaube bis JBoss 5 wurde JBoss Remoting mit RMI als Transportschicht verwendet, wovon du aber nichts mitbekommst.

 

[Gast2]

Kann man eigentlich so nicht vergleichen, weil ja REST auch ein völlig ander Ansatz gegenüber RPC (also nicht RMI im Speziellen) ist.

Das ist mit bewusst, darum ja der vergleich welche übertragung besser geeignet ist

JBoss hat die Transportschicht von der Enterpriseschicht getrennt. Wenn es also wie in deinem Fall um EJB Kommunikation geht, kann man da verschiedene Transportschichten verwenden (die heißen bei JBoss in dem Kontext "Invoker"). Ich weiß nicht wie es im JBoss 6 als Default festgelegt ist, aber ich glaube bis JBoss 5 wurde JBoss Remoting mit RMI als Transportschicht verwendet, wovon du aber nichts mitbekommst.

Ja ich bekomme soweit was mit, dass ich merke dass mein SessionHandling über RMI nicht mehr funktioniert und ich überlege die Übertragung mit HTTP zu machen, da sollte es evtl. wieder funktionieren.

 

[FArt]

Ja ich bekomme soweit was mit, dass ich merke dass mein SessionHandling über RMI nicht mehr funktioniert und ich überlege die Übertragung mit HTTP zu machen, da sollte es evtl. wieder funktionieren.

Wie "dein Sessionhandling über RMI"?
Wenn du eine eigene Kommunikation parallel über RMI aufziehst, sollte das immer noch funktionieren, denn davon weiß der AS ja nichts... oder wie ist das gemeint?

 

[Gast2]

Wie "dein Sessionhandling über RMI"?
Wenn du eine eigene Kommunikation parallel über RMI aufziehst, sollte das immer noch funktionieren, denn davon weiß der AS ja nichts... oder wie ist das gemeint?

siehe Probleme http://www.java-forum.org/application-tier/117196-jboss6-remoting.html

Standard Transportschicht ist RMI und da geht kein SessionScoped.
Jetzt versuch ich mal die Transportschicht zu HTTP wechseln nicht so ohne.

 

[FArt]

siehe Probleme http://www.java-forum.org/application-tier/117196-jboss6-remoting.html

Standard Transportschicht ist RMI und da geht kein SessionScoped.
Jetzt versuch ich mal die Transportschicht zu HTTP wechseln nicht so ohne.

Sorry, aber das ist doch Schwachsinn.
Es liegt nicht an der Transportschicht, sondern am Kontext des Calls. Lies mal die Doku, wann SessionScoped denn nur funktioniert: SessionScoped (Java EE 6 )

The session scope is active: during the service() method of any servlet in the web application, during the doFilter() method of any servlet filter and when the container calls any HttpSessionListener, AsyncListener or ServletRequestListener.

Nicht immer einfach drauflos coden... man muss schon ungefähr verstehen, was man da gerade treibt.

 

[Gast2]

Sorry, aber das ist doch Schwachsinn.
Es liegt nicht an der Transportschicht, sondern am Kontext des Calls. Lies mal die Doku, wann SessionScoped denn nur funktioniert: SessionScoped (Java EE 6 )

Das es mit RMI so nicht geht war mir schon bewusst, aber eventuell gibt es mit RMI eine andere Lösung für das "SessionScoped". Irgendwie solltes es ja möglich sein.

Mein versuch wäre halt gewesen anstatt über RMI über HTTP zu gehen und ein Servlet leitet den call weiter.
[XML]
<servlet>
<servlet-name>Ejb3ServerInvokerServlet</servlet-name>
<description>The ServerInvokerServlet receives requests via HTTP protocol from within a web container and passes it onto the ServletServerInvoker for processing.</description>
<servlet-class>org.jboss.remoting.transport.servlet.web.ServerInvokerServlet</servlet-class>

[/XML]

Nicht immer einfach drauflos coden... man muss schon ungefähr verstehen, was man da gerade treibt.

Coden ist es ja nicht einfach nur versuchen ein Bean an eine Session zu binden über RMI. Wie gesagt wenn du eine Möglichkeit oder Alternative kennst immer her damit

 

[FArt]

Mein versuch wäre halt gewesen anstatt über RMI über HTTP zu gehen und ein Servlet leitet den call weiter.

Das ist ein seltsames Konstrukt, dessen Sinn sich mir nicht erschließt. Dennoch würde es funktionieren. Jedoch nur EJBs im Servletcall können den Scope verwenden, nicht ein EJB davor.

Warum redet der Client nicht direkt mit dem Servlet, wenn du unbedingt den Scope verwenden möchtest. Aber auch das wäre wohl nur ein Workaround.
Was ist eigenlich deine Anforderung? Denn ein SFSB hält ja auch einen Kontext, diesen über seine Lebensdauer, die der Client (aktiv) bestimmt bzw. über den Timeout des SFSB. Warum muss es der Servletkontext sein?

?????

Dir fehlt die Theorie hinter Webapplikationen, EJBs und deren Zusammenspiel in einem AS.

 

[Gast2]

Das ist ein seltsames Konstrukt, dessen Sinn sich mir nicht erschließt. Dennoch würde es funktionieren. Jedoch nur EJBs im Servletcall können den Scope verwenden, nicht ein EJB davor.

Warum redet der Client nicht direkt mit dem Servlet, wenn du unbedingt den Scope verwenden möchtest. Aber auch das wäre wohl nur ein Workaround.
Was ist eigenlich deine Anforderung? Denn ein SFSB hält ja auch einen Kontext, diesen über seine Lebensdauer, die der Client (aktiv) bestimmt bzw. über den Timeout des SFSB. Warum muss es der Servletkontext sein?

?????

Dir fehlt die Theorie hinter Webapplikationen, EJBs und deren Zusammenspiel in einem AS.

Sollten mal ein einem Thrad bleiben ich schreib im anderen die Antwort

 

[FArt]

Dann verlinke ihn, mache diesen zu oder so.

 

[Gast2]

Hier gehts weiter
http://www.java-forum.org/application-tier/117196-jboss6-remoting-2.html#post755614