Re: RMI-IIOP proposed optional

Jens Engel


thanks for your replies.

Sorry for the wrong wording. I still remember the rebranding vom J2EE to JEE which took a while to traverse through our company... I will now learn to say Java EE.

It's good to read that

"it just means that application servers won't need to provide remote EJBs based on RMI-IIOP starting from Java EE 8. Remote EJBs will still have the same features, although vendors will be able to base them on another technology." (Guillermo)


"While RMI-IIOP might be made optional, support for remote EJB invocations using EJB 3 style EJBs, including transaction support, will still be required.  The protocol used might be RMI-IIOP or it might be a vendor-specific protocol; the spec would no longer require a specific protocol." (Bill).

But where is this aspect expressed in the specification? When reading EE.2.7.4, EE. and EE.6.3 one might think remote EJB access might only be guaranteed to be done by protocols that do not suppport transactions. I would appreciate a clarification statement - added for example in section EE.2.7.4.

Although it's not following the latest design principles of microservice achitectures and such, I'm convinced that the support of transactions is one of the key features that helped Java EE Servers compete with established transaction processing systems and enter computing centers. The possibility of doing transactions remotely is then a subsequent requirement since Java EE claims to be decentralized and scalable. If such a basic feature could be removed from the infrastructure technology, decisions which platform to use for future applications might be taken against Java EE.


Join to automatically receive all group messages.