Help coderanch get a
new server
by contributing to the fundraiser
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Migrating from Corba Application to J2EE(Jakarta EE) platform

 
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Hello,
Are there any Best Practices documents telling what could be the most practical way to migrate Corba based aplication to J2EE(Jakarta EE) platform?
 
Saloon Keeper
Posts: 27930
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
CORBA has been dead so long that anything that would have existed would be long out of date. In fact, the last time I saw CORBA was over a decade ago and that was for a project looking to modernize for lack of CORBA support (including vendor support).

CORBA is basically a service to make remote objects look local in a language-independent way. It turns out that even after resolving things like its firewall issues, that sort of approach has horrible overhead, and isn't the most secure architecture in the world.

Apache Axis went through 2 major API evolutions and I think that Axis2 was more CORBA-like and original Axis was more API-like, but I have have that backwards. At any rate, the migration to Axis2 went so badly that I gave up on Axis altogether.

The closest modern thing to CORBA would be remote Enterprise JavaBeans. However remote EJBs is another technology that mostly flopped. We still have EJBs, but they are primarily local-only and in many cases, we're actually just using the JPA part without actual EJB services at all. Plus EJB, unlike CORBA, required that the client be a Java application, and unless someone has since leveraged RMI-IIOP, that means you cannot invoke remote EJBs from C# or Python or whatever.

Your best bet is probably to migrate to a ReST interface. You could pass "object handles" for the client to get that CORBA feel, but ReST is properly intended to provide services, not object access, so that's actually complicating things a bit.
 
Marshal
Posts: 4550
572
VSCode Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Take a look a gRPC.  It might be a good fit if you need to maintain the same system architecture.  It is framework and language agnostic, and takes advantage of the features of HTTP2 (like connection persistence and bi-directional streams).  The usual protocol stack is: Protobuf/gRPC/HTTP2/TLS/TCP, but there is flexibility to use different a data model layer, and remove TLS.

I use it quite a bit for inter-component communications in a microservice-based systems, and as the API for command line tools  and GUI servers which interact with the system.

Here's an example of what a proto file (IDL) looks like:
 
Ron McLeod
Marshal
Posts: 4550
572
VSCode Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I merged your stuff with the following thread. I hope that is okay by you.
 
Baktha Elumalai
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
plan to migrate from com.inprise.vbroker.CORBA.* to Jakarta EE. Please advice me is it possible and what are all the steps to follow to migrate
 
Saloon Keeper
Posts: 15656
367
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bog-standard Jakarta EE doesn't really do RPC (yet).

The closest you'll get are either Jakarta Enterprise Web Services or Jakarta RESTFul Web Services.

In the future, there will probably be a Jakarta RPC standard that is based on gRPC, but it doesn't exist yet. Even so, it will be wildly different from CORBA.

If you want to stick to CORBA, you will probably have to find some third party library. There is no guarantee that you will not have to rewrite major parts of your application, that is, if you can find a newish implementation in the first place. You might as well bite the bullet and rewrite your application to use either JAX-RS, JAX-WS or gRPC.
 
Tim Holloway
Saloon Keeper
Posts: 27930
198
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Java did RPC via Remote Method Invocation (RMI), but that required compatible JVMs on both sides of the conversation. EJB added RMI IIOP, but again, that was Java-to-Java. You had to include a skeleton on the client that paired with an implementation on the server.

CORBA attempted to be object-oriented, not method-oriented. It did not go well, even after they wised up about the firewall issues. Turns out that low-level object access via remote object interfaces was just too much overhead. Same reason why remote EJBs are so rare these days.

CORBA was vendor/language neutral, which RMI is not. The preferred alternative these days is generally web services, where you're doing higher-level operations and thus less overall overhead and don't need a domain-language compiler to produce a client-side stub. Unless you want to.

No one ever tried to open-source CORBA that I know of. As far as I can recall, the last available CORBA implementation was from a descendant of Borland and their CORBA product and it was very definitely orphanware.

From a résumé "must have" to a "¿what's CORBA?" took only about 10 years. Few technologies ever failed quite that hard. SOAP comes close, but you can still find SOAP support and even SOAP use in a few odd corners.
 
If you have a bad day in October, have a slice of banana cream pie. And this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/t/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic