<p>For a typical Web client -to- Servlet/WS -to- Business Tier (Spring or EJB) app, what are the trade-offs of approaches like remote RPC or messaging for Web (Servlet) tier to remote Business tier, aside from the basic sync/async aspects?</p>

[{'answer_id': 71945, 'author': 'Chris Kimpton', 'author_id': 48310, 'author_profile': 'https://Stackoverflow.com/users/48310', 'pm_score': 1, 'selected': False, 'text': '<p>We use RMI via Spring and find it very easy to use, fairly robust and fast.  Although our requirements were for a fairly responsive link and there was no real need to add a messaging component.</p>\n'}, {'answer_id': 72833, 'author': 'James Strachan', 'author_id': 2068211, 'author_profile': 'https://Stackoverflow.com/users/2068211', 'pm_score': 3, 'selected': True, 'text': '<p>By web client do you mean web browser? If so looking at stuff like DWR or JAX-RS are my recommendations. RMI or JMS only really work when both sides are Java code.</p>\n\n<p>With any remoting technology the biggest issue using them tends to be how intrusive the technology becomes on your business objects. e.g. using RMI interface/exceptions everywhere or using the JMS APIs inside your business code.</p>\n\n<p>My recommendation is to use POJOs everywhere in Java then use a technology like <a href="http://static.springframework.org/spring/docs/2.5.x/reference/remoting.html" rel="nofollow noreferrer">Spring Remoting</a> to layer on your middleware whether its RMI or JMS or whatever - but totally de-couple the middleware code from your business logic so you can switch between technologies at any time (and keep your business logic code simpler and focussed on your business problem).</p>\n\n<p>For example see the <a href="http://activemq.apache.org/camel/spring-remoting.html" rel="nofollow noreferrer">Camel implementation of Spring Remoting</a> which then allows you to use <a href="http://activemq.apache.org/camel/components.html" rel="nofollow noreferrer">any of these transports and protocols</a> such as RMI, JMS or even plain HTTP, email, files or XMPP - then switch between them trivially using a simple URI string change.</p>\n'}, {'answer_id': 2849885, 'author': 'Joe', 'author_id': 343143, 'author_profile': 'https://Stackoverflow.com/users/343143', 'pm_score': 0, 'selected': False, 'text': "<p>SUN RMI broke for us. </p>\n\n<p>The settings and garbage collection for a very long running application with continuous meassaging. We are patching to make it work continuously.  JMS applications we run don't get the out of memory errors or gc problems that RMI does. Anything that needs to call System.gc() periodically and doesn't work with incremental collection to recover resources is coded wrong. </p>\n\n<p>RMI reliability improves with the JDK 6 and the correct property settings, but JHC, it's a bodgey framework.  RMI would be vastly improved by using channels in nio and fixing the sun nio uses of system.gc(). </p>\n\n<p>The correct answer - seperate communication (mechanism) from the domain code. RPC is tightly coupled, and the protocol and application can interfere with each other. JMS seperates the protocol from the application, a much better paradigm. </p>\n"}]
['https://Stackoverflow.com/questions/71144', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/11645/']