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.

Additory

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.

Prognosis

Thanks, but before to mark it as answered, the first one wouldn't be a valid reason, because I can implement a Web Service with an EJB exposing a local interface right? So the transaction would be the same. – Additory

True, the problem start when you need to do a number of separated calls in one transaction. Web Services are usually stateless, and one has to manage transaction "by hand", which can be cumbersome. Stateful EJB would give that for free. – Lucilius

Well, you can also have stateful web services, even using the last reason you gave before. So I will go for the second and third reasons, efficiency (a little bit I guess) and legacy. Thanks! – Additory

Good answer! Btw, purely theoretically CORBA clients in any language could connect to remote EJB as well. The protocol used is IIOP, which is not Java specific. Practice is probably different ;) – Ruffo

Very true, CORBA is in fact a really cool technology, but at the beginning it was kind of hard to use, so it never get real popularity. Which is sad, since we end up with strings of XML thrown from one place to the other using inefficient protocol (that's basically SOAP/WSDL web service is). – Lucilius

We must also take into account that REST easier to understand, especially now, because huge demand in IT market lowered the average skills of IT- specialists and they need simpler tools and solutions – Lassie

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.

Done

So it isn't worthy to keep learning EJB with remote interfaces anymore? Like if I want to learn Smalltalk (would just be for fun and learning, but not useful)? – Additory

I wouldn't go that far. The answer to that question depends on your circumstances. – Done

Ok but the only circunstance where it will be useful nowadays would be to integrate with Java legacy systems, right? – Additory

No, I can see EJB3 if you're writing an all-Java application from scratch, and you'll only have Java clients, and distributed, transactional componnents are worth something to you. Dogma is rarely helpful. – Done

Thanks @duffymo! but for example, I can have distributed, transactional web services also. Even I can implement Web Services using EJB3, under this, the RMI interface will only be worthy if I must connect with Java clients only, right? – Additory

No, stateless web services cannot participate in transactions. The only way to do it is to add "compensating transactions" to the API. I don't like that, because it forces my clients to know too much about managing transactions. An EJB service can easily enlist the transaction manager in the Java EE app server to do such a thing. So there's still a good reason for EJBs. – Done

Thanks, I'll check that because I'm not sure I fully understood what you said, but I need to go deeper in this knowledge. Really thanks! – Additory

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.

Incite

This might be another question, but it is possible to easily adapt the EJB to expose it interface as a Web Service, so, you could start the first architecture that you define and if in the future you need to expand you can expose it through web services, or not? – Additory

@ChristianVielma That's another question all right and you won't get an answer on it from me ;-) Ask it as a question. – Incite