Topics

RMI-IIOP proposed optional

Jens Engel
 

Hello,

I'm trying to understand the impact of sections EE.2.7.4 and EE.6.2.3.6 of the specification declaring RMI-IIOP as proposed optional.
Does this just mean that JEE implementations > JEE8 might not interoperate with CORBA Orbs? Or does this even imply that such future JEE implementations may not provide the ability for transactional remote invocation of Session Beans between different JVM instances within the JEE product itself?

Will there be any replacements for transactional remote calls in the specification if RMI-IIOP falls optional? (I mean within the same JEE product; not necessarily between products of different vendors or to CORBA Orbs). Or will there at least be the requirement for JEE vendors that there has to be any (could even be vendor-specific) underlying protocol that enables transaction (and security) context propagation in remote calls?

A paragraph in the specification clarifying this would help (or maybe it's there and I haven't found it?).

Regards

-Jens

Bill Shannon
 

Hi Jens.

First of all, there is nothing named "JEE".  The correct name is "Java EE".

"Proposed optional" means that it might be declared optional in the next release.  In Java EE 8, it is still required.

In the next release, we will consider whether the time is right to make this technology optional.  If it is made optional, vendors will not be required to include it in their products.  Still, we expect many products with a large customer base to continue to provide it so as to support their existing customers.  If you depend on it and your vendor drops support for it, you might need to take advantage of the portability of Java EE applications and move to a new vendor.

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.

The feedback we've gotten from the vast majority of customers is that use of remote EJB invocations between independently deployed applications is no longer a best practice.  Web technologies such as JAX-WS or especially JAX-RS are greatly preferred.  Such loosely coupled components will not depend on distributed transactions.  We would encourage new applications to use a more web-centric architecture, although remote EJBs will remain for applications that need them.

    Bill

Jens Engel wrote on 08/ 2/17 07:34 AM:

Hello,

I'm trying to understand the impact of sections EE.2.7.4 and EE.6.2.3.6 of the specification declaring RMI-IIOP as proposed optional.
Does this just mean that JEE implementations > JEE8 might not interoperate with CORBA Orbs? Or does this even imply that such future JEE implementations may not provide the ability for transactional remote invocation of Session Beans between different JVM instances within the JEE product itself?

Will there be any replacements for transactional remote calls in the specification if RMI-IIOP falls optional? (I mean within the same JEE product; not necessarily between products of different vendors or to CORBA Orbs). Or will there at least be the requirement for JEE vendors that there has to be any (could even be vendor-specific) underlying protocol that enables transaction (and security) context propagation in remote calls?

A paragraph in the specification clarifying this would help (or maybe it's there and I haven't found it?).

Regards

-Jens

Jeff Genender
 


On Aug 2, 2017, at 1:03 PM, Bill Shannon <bill.shannon@...> wrote:

First of all, there is nothing named "JEE".  The correct name is "Java EE".


Bill, I wouldn’t get unwound about it.  You will see JEE, JavaEE, Java EE, etc etc.  Its par for the course and your attempts at boiling the ocean will be futile. ;-). Bigger fish to fry…

Jeff

Bill Shannon
 

Jeff Genender wrote on 08/ 2/17 12:08 PM:

On Aug 2, 2017, at 1:03 PM, Bill Shannon <bill.shannon@...> wrote:

First of all, there is nothing named "JEE".  The correct name is "Java EE".


Bill, I wouldn’t get unwound about it.  You will see JEE, JavaEE, Java EE, etc etc.  Its par for the course and your attempts at boiling the ocean will be futile. ;-). Bigger fish to fry…

I know it's like whack-a-mole, but I can whack those moles while still frying fish.  And if all the rest of you would help me whack those moles, it might actually have some effect.  :-)

 

The community does actually try to correct this when they can. Your efforts are not falling on deaf ears.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Bill Shannon <bill.shannon@...>
Date: 8/2/17 3:30 PM (GMT-05:00)
To: javaee-spec@javaee.groups.io
Subject: Re: [javaee-spec] RMI-IIOP proposed optional

Jeff Genender wrote on 08/ 2/17 12:08 PM:

On Aug 2, 2017, at 1:03 PM, Bill Shannon <bill.shannon@...> wrote:

First of all, there is nothing named "JEE".  The correct name is "Java EE".


Bill, I wouldn’t get unwound about it.  You will see JEE, JavaEE, Java EE, etc etc.  Its par for the course and your attempts at boiling the ocean will be futile. ;-). Bigger fish to fry…

I know it's like whack-a-mole, but I can whack those moles while still frying fish.  And if all the rest of you would help me whack those moles, it might actually have some effect.  :-)

Jason Greene
 


On Aug 2, 2017, at 2:30 PM, Bill Shannon <bill.shannon@...> wrote:

Jeff Genender wrote on 08/ 2/17 12:08 PM:

On Aug 2, 2017, at 1:03 PM, Bill Shannon <bill.shannon@...> wrote:

First of all, there is nothing named "JEE".  The correct name is "Java EE".


Bill, I wouldn’t get unwound about it.  You will see JEE, JavaEE, Java EE, etc etc.  Its par for the course and your attempts at boiling the ocean will be futile. ;-). Bigger fish to fry…

I know it's like whack-a-mole, but I can whack those moles while still frying fish.  And if all the rest of you would help me whack those moles, it might actually have some effect.  :-)

I’m with you!

-Jason

Guillermo González de Agüero
 

Reading it a bit more thoroughly, "Proposed Optional" just means that a future Java EE version could make it optional. It will still be required to work on Java EE 8, but the EG can make it definitely optional on Java EE 9.

Regards,

Guillermo González de Agüero

El mié., 2 ago. 2017 a las 19:05, Guillermo González de Agüero (<z06.guillermo@...>) escribió:
Hi Jens,

As I read it, 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.

As for Java EE 7, remote EJBs *must * work over RMI-IIOP and implementations are *allowed* to use additional protocols.

Hopefully some EG member will be able to confirm my interpretation.


Regards,

Guillermo González de Agüero

El mié., 2 ago. 2017 a las 18:43, Jens Engel (<jens.engel@...>) escribió:
Hello,

I'm trying to understand the impact of sections EE.2.7.4 and EE.6.2.3.6 of the specification declaring RMI-IIOP as proposed optional.
Does this just mean that JEE implementations > JEE8 might not interoperate with CORBA Orbs? Or does this even imply that such future JEE implementations may not provide the ability for transactional remote invocation of Session Beans between different JVM instances within the JEE product itself?

Will there be any replacements for transactional remote calls in the specification if RMI-IIOP falls optional? (I mean within the same JEE product; not necessarily between products of different vendors or to CORBA Orbs). Or will there at least be the requirement for JEE vendors that there has to be any (could even be vendor-specific) underlying protocol that enables transaction (and security) context propagation in remote calls?

A paragraph in the specification clarifying this would help (or maybe it's there and I haven't found it?).

Regards

-Jens

Guillermo González de Agüero
 

Hi Jens,

As I read it, 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.

As for Java EE 7, remote EJBs *must * work over RMI-IIOP and implementations are *allowed* to use additional protocols.

Hopefully some EG member will be able to confirm my interpretation.


Regards,

Guillermo González de Agüero

El mié., 2 ago. 2017 a las 18:43, Jens Engel (<jens.engel@...>) escribió:
Hello,

I'm trying to understand the impact of sections EE.2.7.4 and EE.6.2.3.6 of the specification declaring RMI-IIOP as proposed optional.
Does this just mean that JEE implementations > JEE8 might not interoperate with CORBA Orbs? Or does this even imply that such future JEE implementations may not provide the ability for transactional remote invocation of Session Beans between different JVM instances within the JEE product itself?

Will there be any replacements for transactional remote calls in the specification if RMI-IIOP falls optional? (I mean within the same JEE product; not necessarily between products of different vendors or to CORBA Orbs). Or will there at least be the requirement for JEE vendors that there has to be any (could even be vendor-specific) underlying protocol that enables transaction (and security) context propagation in remote calls?

A paragraph in the specification clarifying this would help (or maybe it's there and I haven't found it?).

Regards

-Jens

Werner Keil
 

I tend to take those less serious than others, but as Java and IT consultant you still stumble over requests to help a project with "J2EE" after all those years ;-)

Werner Keil
 

And so does a relatively recent version of WebLogic (12.1.3.x, I know there were a few updates, but the 12.x has not been replaced yet) at least in the German translation of
something like http://localhost:7001/console/console.portal?_nfpb=true&_pageLabel=ServicesSummaryPage
There both "Messaging" and "jCOM" still use the term "J2EE".

 @Bill maybe you might like to check with your colleagues, I don't have the time to file a bug for it, just tried at Atlassian for a bad German translation of a new Confluence build...

Bill Shannon
 

At least "J2EE" was the correct term at one point, even though it's been obsolete for more than 10 years and we've been calling it "Java EE" longer than it was ever called "J2EE".

Suffering from our own branding success...

Werner Keil wrote on 08/03/2017 04:15 AM:

And so does a relatively recent version of WebLogic (12.1.3.x, I know there were a few updates, but the 12.x has not been replaced yet) at least in the German translation of
something like http://localhost:7001/console/console.portal?_nfpb=true&_pageLabel=ServicesSummaryPage
There both "Messaging" and "jCOM" still use the term "J2EE".

 @Bill maybe you might like to check with your colleagues, I don't have the time to file a bug for it, just tried at Atlassian for a bad German translation of a new Confluence build...


Jens Engel
 

Hi,

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)

and

"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.6.2.3.6 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.

Regards,
-Jens

Bill Shannon
 

Jens Engel wrote on 08/03/2017 06:16 AM:
Hi,

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)

and

"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.6.2.3.6 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.
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.

Jens Engel
 

Hi Bill,

thanks for your answer.

I know that there are new ways for building applications but - well - there are existing applications which cannot easily be transformed into this direction - and I reckon that there are domains where classical data consistency requirements still apply.

Where do I have to "file this issue" (clarification that declaring RMI-IIOP as optional does not mean dropping requirements for transactional remoting) officially, so it will be considered in the work for future Java EE specs?

Best regards

-Jens

Bill Shannon
 

Jens Engel wrote on 08/ 4/17 02:34 AM:
Hi Bill,

thanks for your answer.

I know that there are new ways for building applications but - well - there are existing applications which cannot easily be transformed into this direction - and I reckon that there are domains where classical data consistency requirements still apply.
Right, which is why I expect many Java EE vendors will be supporting these technologies for quite some time, even after they become optional.

Where do I have to "file this issue" (clarification that declaring RMI-IIOP as optional does not mean dropping requirements for transactional remoting) officially, so it will be considered in the work for future Java EE specs?
Java EE issue tracker
EJB issue tracker