Date: Fri, 11 May 2012 10:54:26 +0200
Well pretty much 10 years ago, I even had to do a RMI-DDE bridge for one
vendor, AFAIK the only one ever required in the world, that was the most
black art I probably did[?] while running the Web UI on several mobile
devices from Nokia to Palm and even Windows CE (in 2002!) has just gained
momentum now, around 10 years later.
The modularity argument is also a good one. While EE8 and a post-Jigsaw
version of the spec may make it even easier to declare a module optional or
redundant (and those in need could still add it) where the use cases are as
rare as CORBA or DDE, maybe it's not worth waiting till EE8.
Unless there are patches to existing SE7, those changes mentioned that
could affect the underlying Java platform probably won't make it into SE
prior to 8 anyway.
Werner
On Fri, May 11, 2012 at 7:43 AM, David Blevins <david.blevins_at_gmail.com>wrote:
>
> On May 10, 2012, at 8:54 PM, Markus Eisele wrote:
>
> > Hi,
> >
> > sounds alluring :) Haven't used it in a while and could do without. I
> > still like to express that I actually have seen use of it. I even have
> > seen people bridging J2EE to Java EE with it (single vendor only).
>
> That would still be required.
>
> > It's clearly some kind of black art and a burden to implement (for
> > both container providers and users).
>
> The story here is originally, vendors could and still can use whatever
> protocol they want for remoting. Later, CORBA was added for
> vendor-to-vendor interop. Some of us who have our own protocol or simply
> use RMI have to maintain both; the one that is used and the one that's
> there only for compliance.
>
>
> -David
>
> > On 11 May 2012 00:59, David Blevins <david.blevins_at_gmail.com> wrote:
> >> I think "Amen" might be the best word. From a Geronimo perspective,
> we've had significant troubles retaining enough expertise to keep that
> section certified and meanwhile it's never once been used.
> >>
> >> From a TomEE perspective, this is one of the things preventing our
> "more than web profile" distro from being certified. Tough to motivate
> volunteers to write an integration for something they'll never use.
> >>
> >>
> >> -David
> >>
> >> On May 10, 2012, at 12:50 PM, Linda DeMichiel wrote:
> >>
> >>>
> >>> The Java EE Platform and EJB specifications currently require the
> >>> capability of using RMI-IIOP to export EJB components and to access EJB
> >>> components over a network. This requirement enables interoperability
> >>> between Java EE products.
> >>>
> >>> It has been suggested that we consider removing the requirement for
> >>> such interoperability support from the Java EE Platform and EJB
> >>> specifications.
> >>>
> >>> There are several reasons behind this proposed change:
> >>>
> >>> * RMI/IIOP has been largely superseded by modern web technologies
> >>> that provide interoperability support, such as SOAP and REST.
> >>> Hence, few developers are currently relying on RMI/IIOP for this
> purpose.
> >>> * Implementing the required support is seen as an unnecessary
> >>> burden on Java EE implementors.
> >>> * There is a perception that this requirement makes Java EE seem
> >>> heavyweight at a time when we're trying to appeal to developers
> >>> who want a lightweight solution.
> >>>
> >>> Removing this requirement would mean that an implementation of the
> >>> Platform would still be required to support remote access to EJBs, but
> >>> would not be required to use IIOP to do so. That is, we would be
> >>> removing requirements that provide interoperability across products,
> >>> but would not be removing requirements that require support for remote
> >>> access within a single product, since other protocols could be used.
> >>>
> >>> Further, please note that because Java EE 7 requires support for Java
> >>> SE 7, we would also not be removing requirements for the ability to
> >>> use the CORBA functionality that is required as a part of Java SE.
> >>>
> >>> If we pursue this direction, the first step, of course, would be to
> >>> designate support for RMI-IIOP interoperability as "Proposed Optional".
> >>>
> >>> Please let us know whether you support this proposed change or not.
> >>>
> >>> thanks,
> >>>
> >>> -Linda
> >>>
> >>
>
>
(image/gif attachment: 347.gif)