Is still useful to implement EJB with RMI when you can implement Web Services (SOA/REST)?

Question

This might sound similar to this , but it's not.

I kind of understand EJB and RMI, and I have been working with web services under SOA for a while. I want to know why is useful to work using EJB exposing remote interfaces under RMI instead of publishing Web Services (SOA/REST, but mostly SOA). I'm not asking which one is better, just I want to know a very good reason of why should I prefer to implement EJB with remote interfaces over Web Services.

I have reviewed a lot of webpages but all seemed outdated. Until now, what I have is that EJB exposing remote interfaces is only better than WS when integrating with Java legacy system. If I want to manage transactions I could implement EJB with local interfaces. Also I don't think choosing EJB over RMI is more efficient than a Web Service interface.

Am I right? Is there something I'm missing?

Really thanks in advance.

Answer 1

EJBs are better if

• you need to perform number of calls which should be done in one transaction (in theory we have transactional web services, but not every implementation provides them), (stateful) EJBs shine when it comes to transaction management. Almost anytime you need statefulness EJB would be better then Web Service;
• you need performence - Web Services are slow - they use XML/JSON pushed through HTTP, RMI over IIOP protocol used by EJB is way more efficient;
• you need to connect to some legacy system which uses outdated spec for Java Web Services (ugly Axis 1.0 stuff, not compatible with JAX-WS) it can be a nightmare to connect everything with web services, deal with not compatible WSDL definitions, strange SOAP envelopes. EJBs are backward compatible, old EJB 2 could be connected without any problem with EJB 3.1;
• modern EJBs (EJB 3.X) can expose their interface as a JAX-WS SOAP/WSDL service or JAX-RS REST service by adding two or three simple annotations

Why (REST) Web services are so popular then? EJBs can be connected only to another Java application. Majority of modern Rich Internet Applications are written in JavaScript, so the only way to connect them with any backend is to use some kind of web service (usually REST + JSON). For such applications EJBs are pretty useless.

Answer 2

Both the client and service must be written in Java if you use RMI as the wire protocol.

SOAP uses XML over HTTP, and REST uses pure HTTP for communication between client and service. Either end of the conversation can be written in any language that can send appropriate requests over HTTP, which is far less restrictive.

I think this is one reason why web services over HTTP have won out over RMI. Simple and open win, every time.

Answer 3

They are different things for different purposes.

EJBs are for use within an N -tier system that is tightly coupled and you are in control of all elements. They offer direct coding in the language using what appear to be ordinary method calls, and LAN-type performance over IIOP or whatever other protocol the EE vendor has deployed.

SOAP/REST is best for use across the Internet, or in B2B or other situations where you aren't in control of both ends and you need loose coupling. You get much slower performance due to all the XML, but you also get an industry standard protocol in the middle which gives both ends protection against single-sourcing problems.