# RMI vs REST



## Gast2 (27. Apr 2011)

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 (27. Apr 2011)

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 (27. Apr 2011)

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 (28. Apr 2011)

SirWayne hat gesagt.:


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



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 (28. Apr 2011)

FArt hat gesagt.:


> 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



FArt hat gesagt.:


> 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 (28. Apr 2011)

SirWayne hat gesagt.:


> 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 (28. Apr 2011)

FArt hat gesagt.:


> 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 (29. Apr 2011)

SirWayne hat gesagt.:


> 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 (29. Apr 2011)

FArt hat gesagt.:


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



FArt hat gesagt.:


> 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 (29. Apr 2011)

SirWayne hat gesagt.:


> 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 (29. Apr 2011)

FArt hat gesagt.:


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



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


----------



## FArt (29. Apr 2011)

Dann verlinke ihn, mache diesen zu oder so.


----------



## Gast2 (29. Apr 2011)

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


----------

