>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).