Jens Engel wrote on 08/03/2017 06:16 AM:
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
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
"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
But where is this aspect expressed in the specification? When reading
EE.2.7.4, EE.126.96.36.199 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
The EJB spec should have clear functionality requirements that are independent
of the remote protocol being used. If this isn't clear in the EJB spec, we'll
make it clear at the time we remove the RMI-IIOP requirement.
EE.2.7.4 is already clear that EJBs may use other protocols. This section will
be updated and can be clarified when RMI-IIOP is actually made optional. (It's
too late to do anything for Java EE 8 since we've already submitted the
materials for the Final Approval Ballot, to start next week.)
In any event, feel free to file issues against the platform spec or the EJB spec
for sections that you think need to be made more clear.
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.
This level of transaction support was absolutely key to Java EE's success 18
years ago, but many things have changed since then and distributed transactions
are no longer considered a key technology. We've learned much better approaches
for creating distributed and scalable applications, and Java EE supports these
new approaches very well.