Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] RMI-IIOP and CORBA

All,

I've attempted to create a history of remoting in EJB from version 1.0 to 2.0 in an attempt to help people understand how we evolved to where we are now, how EJB has always had a nuanced view of CORBA and the target we need to hit in effectively rolling back to "enabling CORBA", but without "requiring CORBA."

If you see CORBA as all one thing, please read:

 - https://github.com/eclipse-ee4j/jakartaee-platform/pull/249#issuecomment-716067199

We will try to close this out on this Tuesday's Platform call.  Please read before that call if you can.  Note those are open to the public.  If the topic interests you, please come and ask questions:

  Jakarta EE Platform Weekly Call
  Tuesday, October 27⋅8:00 – 9:00am Pacific
  Weekly on Tuesday
  https://eclipse.zoom.us/j/596957191


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

> On Sep 30, 2020, at 7:53 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
> 
> All,
> 
> I have a PR up that details the current state of RMI-IIOP, what remains and what doesn't, as well as some thoughts on how we might need to provide more portability if people start implementing more custom protocols.
> 
>  - https://github.com/eclipse-ee4j/jakartaee-platform/pull/249
> 
> I'm sensitive there is a bit of a bus factor with me on this; the very first line of open source and Java EE code I ever wrote was a custom protocol in OpenEJB.  My intent is to be complete enough with the contents and comments on the PR that we have enough material for others to understand the topic more clearly.
> 
> Could I request that we get more people to review it and ask questions here where they are permanently archived?
> 
> Things like Google protocol buffers could absolutely be used for EJB remote calls and if that becomes an interest, we will need to expand knowledge on this topic.  What remains of our RMI-IIOP guarantees is enough to allow something like that to happen without developers seeing odd inconsistencies in the serialized/deserialized object graphs.
> 
> 
> -- 
> David Blevins
> http://twitter.com/dblevins
> http://www.tomitribe.com
> 
>> On Jan 9, 2020, at 7:05 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:
>> 
>> I just realized that the Jakarta EE 9 Release Plan doesn't say anything
>> explicit about RMI-IIOP or CORBA.   They are both removed from JDK 11,
>> and Jakarta EE 9 explicitly removes EJB interoperability, which depends
>> on RMI-IIOP, but nothing is said about RMI-IIOP or CORBA themselves.
>> 
>> My original Jakarta EE 9 proposal was explicit that RMI-IIOP and CORBA
>> would not be included.  I think we should update the current plan to make
>> this explicit as well.
>> 
>> Note that this means any product providing backwards compatibility will
>> need to provide a complete ORB and RMI-IIOP support, including the javax.rmi
>> APIs.  (The javax.rmi APIs would not be migrated to the jakarta namespace.)
>> 
>> Comments?
>> _______________________________________________
>> jakartaee-platform-dev mailing list
>> jakartaee-platform-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> 



Back to the top