Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Labels:
      None

      Description

      Although CORBA support in EJB was important once, CORBA usage has dropped precipitously in the past years in favor of REST and SOAP. Current CORBA use is so small that it makes the most sense to prune CORBA support going forward and significantly simplify EJB remoting.

        Issue Links

          Activity

          reza_rahman created issue -
          Hide
          marina vatkina added a comment -

          This request needs to be resolved at the Platform level

          Show
          marina vatkina added a comment - This request needs to be resolved at the Platform level
          marina vatkina made changes -
          Field Original Value New Value
          Project ejb-spec [ 11979 ] javaee-spec [ 11928 ]
          Key EJB_SPEC-16 JAVAEE_SPEC-16
          Affects Version/s 3.2 [ 14833 ]
          Fix Version/s 3.2 [ 14833 ]
          marina vatkina made changes -
          Link This issue blocks EJB_SPEC-17 [ EJB_SPEC-17 ]
          Hide
          Darious3 added a comment -

          While I'm all for pruning compatibility with CORBA, I hope this doesn't mean that (EJB) remoting will only have REST and SOAP as options.

          Ideally, CORBA interoperability is dropped, and some new more efficient and capable binary protocol introduced for standard @Remote beans.

          Show
          Darious3 added a comment - While I'm all for pruning compatibility with CORBA, I hope this doesn't mean that (EJB) remoting will only have REST and SOAP as options. Ideally, CORBA interoperability is dropped, and some new more efficient and capable binary protocol introduced for standard @Remote beans.
          Hide
          Bill Shannon added a comment -

          It's very unlikely that we would introduce a new, standard, binary protocol
          just for remote EJBs.

          The choices seem to be:

          1. Remove the requirement for CORBA interoperability while retaining
          the requirement for remote EJB access. Implementations could meet
          the requirement using a standard protocol such as CORBA or a
          proprietary protocol.

          2. Remove the requirement for CORBA interoperability and remove the
          requirement for remote EJB access. Implementations need not support
          remote EJBs at all, but if they did they could use CORBA or some
          other protocol.

          As mentioned above, we expect that most remote access to EJBs is moving
          to ReST using JAX-RS or SOAP using JAX-WS.

          We understand the difficulty that removing any of these capabilities presents
          to existing applications that depend on them, but we'd be very interested in
          hearing of functionality required by new applications that is not provided
          by JAX-WS or JAX-RS and would require new applications to choose the existing
          remote EJB capability.

          Show
          Bill Shannon added a comment - It's very unlikely that we would introduce a new, standard, binary protocol just for remote EJBs. The choices seem to be: 1. Remove the requirement for CORBA interoperability while retaining the requirement for remote EJB access. Implementations could meet the requirement using a standard protocol such as CORBA or a proprietary protocol. 2. Remove the requirement for CORBA interoperability and remove the requirement for remote EJB access. Implementations need not support remote EJBs at all, but if they did they could use CORBA or some other protocol. As mentioned above, we expect that most remote access to EJBs is moving to ReST using JAX-RS or SOAP using JAX-WS. We understand the difficulty that removing any of these capabilities presents to existing applications that depend on them, but we'd be very interested in hearing of functionality required by new applications that is not provided by JAX-WS or JAX-RS and would require new applications to choose the existing remote EJB capability.
          Hide
          arjan tijms added a comment -

          >It's very unlikely that we would introduce a new, standard, binary protocol
          just for remote EJBs.

          Wouldn't JRMP be an option here?

          >we'd be very interested in hearing of functionality required by new applications that is not provided
          by JAX-WS or JAX-RS and would require new applications to choose the existing
          remote EJB capability.

          What about the ease of use with which a remote bean can join a distributed transaction and propagate an established security context?

          The first one is a real issue that we encountered in production when doing two calls to a JAX-RS based service that should either both take effect or none at all.

          For SOAP there's WS-AT, but last time I looked it was quite a hassle to get this to work (maybe things have changed lately?).

          A binary protocol may also have the potential for better performance. In case the spec leaves the protocol open to the implementation, then there's still room for that. However, EJB remote communication between different application servers is already difficult or impossible. Instead of improving this, leaving even the protocol to the discretion of the vendor would completely destroy any interoperability.

          Ideally we would like to see a standardized method to lookup remote EJBs, some standardized notion of what many implementations now call a 'client lib' and a common protocol (e.g. JRMP, which is already available in the JDK).

          Show
          arjan tijms added a comment - >It's very unlikely that we would introduce a new, standard, binary protocol just for remote EJBs. Wouldn't JRMP be an option here? >we'd be very interested in hearing of functionality required by new applications that is not provided by JAX-WS or JAX-RS and would require new applications to choose the existing remote EJB capability. What about the ease of use with which a remote bean can join a distributed transaction and propagate an established security context? The first one is a real issue that we encountered in production when doing two calls to a JAX-RS based service that should either both take effect or none at all. For SOAP there's WS-AT, but last time I looked it was quite a hassle to get this to work (maybe things have changed lately?). A binary protocol may also have the potential for better performance. In case the spec leaves the protocol open to the implementation, then there's still room for that. However, EJB remote communication between different application servers is already difficult or impossible. Instead of improving this, leaving even the protocol to the discretion of the vendor would completely destroy any interoperability. Ideally we would like to see a standardized method to lookup remote EJBs, some standardized notion of what many implementations now call a 'client lib' and a common protocol (e.g. JRMP, which is already available in the JDK).
          Hide
          Bill Shannon added a comment -

          Some products use JRMP or a variant of JRMP, but we're unlikely to require
          use of a Java-specific protocol as an interoperability protocol.

          Getting things like distributed transactions working between vendors
          continues to be a challenge. The feedback we're getting is that most
          people are taking a different approach when they need to interoperate
          between different products.

          The existing capabilities will be around in products for years to come,
          but it doesn't seem like improving them is as important as the many
          other things developers are requesting.

          Thanks for your feedback.

          Note that detailed discussion of issues and requirements is probably
          better done on the users@javaee-spec.java.net mailing list.

          Show
          Bill Shannon added a comment - Some products use JRMP or a variant of JRMP, but we're unlikely to require use of a Java-specific protocol as an interoperability protocol. Getting things like distributed transactions working between vendors continues to be a challenge. The feedback we're getting is that most people are taking a different approach when they need to interoperate between different products. The existing capabilities will be around in products for years to come, but it doesn't seem like improving them is as important as the many other things developers are requesting. Thanks for your feedback. Note that detailed discussion of issues and requirements is probably better done on the users@javaee-spec.java.net mailing list.
          Bill Shannon made changes -
          Assignee ldemichiel [ ldemichiel ]

            People

            • Assignee:
              ldemichiel
              Reporter:
              reza_rahman
            • Votes:
              18 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: