search

jakartaee / enterprise-beans

Jakarta Enterprise Beans
https://eclipse.org/ee4j/ejb
Other
19 stars 29 forks source link

Remove references to RMI-IIOP and XML RPC #121

Closed hussainnm closed 4 years ago

hussainnm commented 4 years ago

I have left the RMI-IIOP references as-is in the following place:

Note: Programs using the cast operator for narrowing the remote component interface and remote home interface are likely to fail if the container implementation uses RMI-IIOP as the underlying communication transport.

JTS provides transaction interoperability using the standard IIOP protocol for transaction propagation between servers.

@dblevins Please review and let me know if further changes are required.

jeanouii commented 4 years ago

This one looks good but I'll review and merge your first PR which is probably bigger in terms of impact. Then can you rebase this one?

hussainnm commented 4 years ago

Re-based on top of master.

dblevins commented 4 years ago

@hussainnm Thanks for the PR and thanks even more in advance for the patience as this is one of the more nuanced and trick subjects and will take a bit of explanation/rework, but I'm very happy the knowledge will be spread around a bit so there's a handful of people more who understand the topic.

First, we need to revert back to the term RMI-IIOP as that term has been used since the first EJB 1.1 specification when CORBA was not a required protocol. Effectively what the concatenation "RMI-IIOP" meant in the EJB 1.1 specification was to communicate the following two audiences:

Overall in EJB 1.1 there are about 30 references to RMI-IIOP in this way which we still need to keep as they were all statements on how to retain protocol agnostic remote semantics. Later in EJB 2.0 when CORBA became an actual requirement, the number for RMI-IIOP references went up to 42.

So what we need to do is basically find those 12 references and make sure they're gone, while retaining the original 30. Those numbers are not exact in today's spec, but that's just to give an idea of the challenge.

It's tricky to find them, but the general pattern is the original RMI-IIOP references we need to keep tend to also use the words "compatible" or "compliant" in the same sentence. The "new" (EJB 2.0) references to RMI-IIOP tend to use the word "interoperable" in the same sentence.

It's definitely a bit of delicate surgery.

Still reviewing the PR in detail, but the other comment I'd make is that we definitely need the footnotes. If there's an issue with them, we likely need to figure out how to solve it.

hussainnm commented 4 years ago

The footnotes.adoc was originally contributed with the specification was not in a usable state. All footnotes are already inlined and this document is no longer referenced. Hence I have removed the document.

The additional references to RMI-IIOP added in 2.0 is mostly in Chapter 19 Support for Distribution and Interoperability which is already removed.

I chose to change RMI-IIOP value type references to Java RMI based on EJB 1.0. Since javax.corba is no longer available from JDK11+ there is no native RMI-IIOP implementation to support the CORBA protocol that the specification can refer to. Please correct me if I am wrong on this point.

dblevins commented 4 years ago

The footnotes.adoc was originally contributed with the specification was not in a usable state. All footnotes are already inlined and this document is no longer referenced. Hence I have removed the document.

Great. Thanks for that clarification.

The additional references to RMI-IIOP added in 2.0 is mostly in Chapter 19 Support for Distribution and Interoperability which is already removed.

Agree. I suspect if we do a search for the word "interoperable" or "interoperability" and don't find anything tied to RMI-IIOP we're good.

I chose to change RMI-IIOP value type references to Java RMI based on EJB 1.0. Since javax.corba is no longer available from JDK11+ there is no native RMI-IIOP implementation to support the CORBA protocol that the specification can refer to. Please correct me if I am wrong on this point.

I really like the way you phrase the logic you used -- very helpful. Yes, we need to go back to the "RMI-IIOP" term.

In this situation the Java SE team's decision to add and then later remove a CORBA ORB from the JVM is unrelated to the EJB specification's language around RMI-IIOP. In fact we actually tried to remove the requirement for CORBA support in Java EE 7, before the Java SE team removed it from their side, but one org came out very strongly against it (not Oracle).

It was the EJB 1.1 specification that introduced the concept that a vendor could implement their own protocol and also introduced the "RMI-IIOP" term to communicate "your protocol cannot interfere with either RMI or IIOP semantics." This was still the case through EJB 2.0 - 3.2 even when CORBA was a requirement as vendors could still implement their own RMI-IIOP compatible (not necessarily interoperable) protocols. Now that we're dropping required CORBA support our status with custom protocols is still the same in that it must not conflict with the serialization semantics of RMI or IIOP.

More tersely speaking, an application cannot be serialized over either RMI or IIOP is non-compliant and the spec still needs to explicitly say that. If it worked with RMI but not with IIOP (CORBA) it's still non-compliant as we know we have servers that use IIOP. Inversely, server protocols that cannot serialize applications that work fine on either RMI or IIOP are also non-compliant.

hussainnm commented 4 years ago

Understood, I have reverted the change to RMI-IIOP and only removed the RMI-IIOP Interoperability in RuntimeEnvironment.