4 ms·

The Wikipedia page says the most recent version of the standard is 3.4, published in 2021: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architect

by js2 3y ago

The Wikipedia page says the most recent version of the standard is 3.4, published in 2021: https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A... In my 25+ year career I haven't seen it in use anywhere. I only ever encountered it while getting my CS degree.

iguessthislldo 3y ago
I graduated in 2018 and it was only mentioned off hand in a systems programming class in a discussion of RPC frameworks. That was basically all I knew about it until I became a maintainer of a CORBA implementation as part of my job. It's not the main part of my job and honestly I still don't know a lot about actually using CORBA. The only part I know a lot about is the interface description language (IDL) used for code generation, which we use a ton of in another framework that I'm actually paid to maintain.
lelanthran 3y ago
> In my 25+ year career I haven't seen it in use anywhere. I only ever encountered it while getting my CS degree. Too bad you didn't join the company I left in the 90s. It was used in production. I learned about it in my CS degree too, and (because I was a fulltime dev at the time as well as a part time student) I went ahead and used it at work[1]. From what I remember of using it in production, the only difficulty I had was in sourcing a free ORB (server software) that supported inter-ORB routing so that I could load-balance.[2] My employer eventually shelled out a small fortune (it was the 90s, we were drowning in VC money) for something from, IIRC, IBM[3] that ran on Sun Enterprise Servers (another small fortune). My experience with CORBA was GREAT! I mean, compared to the way we do it now with browser tech: 1. I could use any language to write the client software, not limited to only Javascript. 2. Making a server call from the client was transparent. It looked like any other function call, unlike how it has to be done now using promises/futures or callbacks. 3. The tech supported exceptions which were also transparent to the programmer. In C++ you could do the following and it would work as expected. try { myObj->foo() } catch { /* ... */ } 4. It was all strongly typed; if you used an argument with the wrong type you'd get either (in compiled languages) a compilation error or (in Interpreted languages) a runtime exception before the call is made. 5. Developer velocity was great. I wrote my object specification, the tools generated both the server-side and the client-side wrappers, and all I had to do was call them. [1] I was young, still in the phase of resume-driven-development. [2] I used a free ORB written in C++ called either Mico or Micro; I don't remember the specifics. [3] Maybe Sun, I'm not sure.
- brazzy 3y ago
  > Making a server call from the client was transparent. It looked like any other function call That is a very bad idea and one of the reasons this kind of thing rightfully died out. Because a server call isn't like any other function call. It has orders of magnitude higher latency, and additional failure modes that you actually have to take care of. It shouldn't look like any other function call.
  - lelanthran 3y ago
    > That is a very bad idea and one of the reasons this kind of thing rightfully died out. I agree, but, like everything else that is a bad idea, naming conventions help.[1] Namespacing helped too. I used naming conventions to ensure that network calls looked different, and namespaces that kept network objects in their own module. [1] Right now we rely on naming conventions in most codebases to differentiate between #define'd literals and variables (C), between constants and variables (Java), between variables and methods (Kotlin, Java, everything else), between interfaces and classes (C#, C++, everything else too, probably), for everything in Python (pep8). Using naming conventions to identify remote calls is no different than using naming conventions to identify interfaces.
  - stickfigure 3y ago
    > It shouldn't look like any other function call. I'm sorry, This is the stupidest thing I see commonly repeated in public discourse about software. Every single distributed application I've ever worked on in my 30-year career (including working for multiple companies you've heard of) wrapped remote calls in something that looks like a normal function call. It doesn't matter if your low-level RPC stub throws RemoteException or returns RemoteError, somewhere up the call stack someone has wrapped this into a simple method that looks like this: doSomethingUseful(); In real life, you make a call to a function and you live with the consequences. If you're lucky, the docs let you know the performance and failure characteristics. If not, you make some assumptions. When those assumptions are wrong, you spend some time debugging and profiling. Adding a bunch of syntactic noise to the callsite doesn't help. The first thing any competent programmer will do is abstract your noise away in convenience methods. Because 99% of the time, it doesn't matter that your call is remote. Take a look at your own codebase that makes client REST calls to some other service - you may hand-wire a bunch of http calls, but somewhere up the stack there's a function that hides the http mess. Everything below that function is accidental complexity.
kanzenryu2 3y ago
Some older Java application servers still feature a tiny amount of CORBA underneath the covers
sk5t 3y ago
Lotus Notes/Domino supported it for IPC and it worked pretty well, e.g. from .NET which did not have a vendor language binding.
inferiorhuman 3y ago
Gnome used CORBA in the form of Bonobo and KDE reinvented the wheel with DCOP.
- sirtaj 3y ago
  KDE tried and discarded CORBA in KOM/KParts well before GNOME got around to putting it in production. DCOP was a response to CORBA's complexity and fragility, and was almost "reinvented" in the form of DBUS.
  - inferiorhuman 3y ago
    Now there's a name I've not seen in a while. And, yeah, if memory serves CORBA worked well enough for Gnome but not KDE because the C++ story was not great. Whatever bindings being used were dependent on features not well supported by G++, templates being painfully slow to compile, etc.
    - tguvot 3y ago
      if my memory serves me right, corba (if form of orbit) worked well enough for gnome because almost nothing used it. kde in it's turn were heavily reliant on it (mico) for embedding and communication. but compilation was indeed painfully slow (i still remember never ending kde compiles in 99-2000) so they came up with dcop/kparts after having few drinks and deciding that they can do better
      - sirtaj 3y ago
        Apart from the template bloat, at the time CORBA meant exceptions IIRC. The bits of GNOME that used orbit dealt with the same errors mostly by ignoring the return codes. In the end, both teams decided that assuming components running in remote processes was the wrong default. I'm not sure what GNOME replaced them with, but KParts rescued KDE 2.0
        tguvot 3y ago
seren 3y ago
I am still working on a code base that has slowly evolved from around 2000 with as its core CORBA as the internal communication bus between actors, so we still use it. We likely want to remove it because it is a bit an overkill in our application, but at the same time it is working and no one wants to pay for a rewrite.
willis936 3y ago
I worked at a defense contractor small business for a short while that used CORBA in some of its products. Previous engineers declared it impossible to update, so they asked me to do it. I had to upgrade the C++ version for the first time in a decade. I didn't find it very fun, but it was satisfying to see an ancient program compile on a more modern toolchain.
pjmlp 3y ago
It was used by Nokia Networks for all their HP-UX based infrastructure, in a mix of C++ and Perl. Eventually it was replaced by a new server infrastructure based on Java EE and Red-Hat Linux.
- SSLy 3y ago
  CORBA itself is still used there for that purpose.

by js2 3y ago

iguessthislldo 3y ago

I graduated in 2018 and it was only mentioned off hand in a systems programming class in a discussion of RPC frameworks. That was basically all I knew about it until I became a maintainer of a CORBA implementation as part of my job. It's not the main part of my job and honestly I still don't know a lot about actually using CORBA. The only part I know a lot about is the interface description language (IDL) used for code generation, which we use a ton of in another framework that I'm actually paid to maintain.

lelanthran 3y ago

> In my 25+ year career I haven't seen it in use anywhere. I only ever encountered it while getting my CS degree. Too bad you didn't join the company I left in the 90s. It was used in production. I learned about it in my CS degree too, and (because I was a fulltime dev at the time as well as a part time student) I went ahead and used it at work[1]. From what I remember of using it in production, the only difficulty I had was in sourcing a free ORB (server software) that supported inter-ORB routing so that I could load-balance.[2] My employer eventually shelled out a small fortune (it was the 90s, we were drowning in VC money) for something from, IIRC, IBM[3] that ran on Sun Enterprise Servers (another small fortune). My experience with CORBA was GREAT! I mean, compared to the way we do it now with browser tech: 1. I could use any language to write the client software, not limited to only Javascript. 2. Making a server call from the client was transparent. It looked like any other function call, unlike how it has to be done now using promises/futures or callbacks. 3. The tech supported exceptions which were also transparent to the programmer. In C++ you could do the following and it would work as expected. try { myObj->foo() } catch { /* ... */ } 4. It was all strongly typed; if you used an argument with the wrong type you'd get either (in compiled languages) a compilation error or (in Interpreted languages) a runtime exception before the call is made. 5. Developer velocity was great. I wrote my object specification, the tools generated both the server-side and the client-side wrappers, and all I had to do was call them. [1] I was young, still in the phase of resume-driven-development. [2] I used a free ORB written in C++ called either Mico or Micro; I don't remember the specifics. [3] Maybe Sun, I'm not sure.

brazzy 3y ago
> Making a server call from the client was transparent. It looked like any other function call That is a very bad idea and one of the reasons this kind of thing rightfully died out. Because a server call isn't like any other function call. It has orders of magnitude higher latency, and additional failure modes that you actually have to take care of. It shouldn't look like any other function call.
- lelanthran 3y ago
  > That is a very bad idea and one of the reasons this kind of thing rightfully died out. I agree, but, like everything else that is a bad idea, naming conventions help.[1] Namespacing helped too. I used naming conventions to ensure that network calls looked different, and namespaces that kept network objects in their own module. [1] Right now we rely on naming conventions in most codebases to differentiate between #define'd literals and variables (C), between constants and variables (Java), between variables and methods (Kotlin, Java, everything else), between interfaces and classes (C#, C++, everything else too, probably), for everything in Python (pep8). Using naming conventions to identify remote calls is no different than using naming conventions to identify interfaces.
- stickfigure 3y ago
  > It shouldn't look like any other function call. I'm sorry, This is the stupidest thing I see commonly repeated in public discourse about software. Every single distributed application I've ever worked on in my 30-year career (including working for multiple companies you've heard of) wrapped remote calls in something that looks like a normal function call. It doesn't matter if your low-level RPC stub throws RemoteException or returns RemoteError, somewhere up the call stack someone has wrapped this into a simple method that looks like this: doSomethingUseful(); In real life, you make a call to a function and you live with the consequences. If you're lucky, the docs let you know the performance and failure characteristics. If not, you make some assumptions. When those assumptions are wrong, you spend some time debugging and profiling. Adding a bunch of syntactic noise to the callsite doesn't help. The first thing any competent programmer will do is abstract your noise away in convenience methods. Because 99% of the time, it doesn't matter that your call is remote. Take a look at your own codebase that makes client REST calls to some other service - you may hand-wire a bunch of http calls, but somewhere up the stack there's a function that hides the http mess. Everything below that function is accidental complexity.

kanzenryu2 3y ago

Some older Java application servers still feature a tiny amount of CORBA underneath the covers

sk5t 3y ago

Lotus Notes/Domino supported it for IPC and it worked pretty well, e.g. from .NET which did not have a vendor language binding.

inferiorhuman 3y ago

Gnome used CORBA in the form of Bonobo and KDE reinvented the wheel with DCOP.

sirtaj 3y ago
KDE tried and discarded CORBA in KOM/KParts well before GNOME got around to putting it in production. DCOP was a response to CORBA's complexity and fragility, and was almost "reinvented" in the form of DBUS.
- inferiorhuman 3y ago
  Now there's a name I've not seen in a while. And, yeah, if memory serves CORBA worked well enough for Gnome but not KDE because the C++ story was not great. Whatever bindings being used were dependent on features not well supported by G++, templates being painfully slow to compile, etc.
  - tguvot 3y ago
    if my memory serves me right, corba (if form of orbit) worked well enough for gnome because almost nothing used it. kde in it's turn were heavily reliant on it (mico) for embedding and communication. but compilation was indeed painfully slow (i still remember never ending kde compiles in 99-2000) so they came up with dcop/kparts after having few drinks and deciding that they can do better
    - sirtaj 3y ago
      Apart from the template bloat, at the time CORBA meant exceptions IIRC. The bits of GNOME that used orbit dealt with the same errors mostly by ignoring the return codes. In the end, both teams decided that assuming components running in remote processes was the wrong default. I'm not sure what GNOME replaced them with, but KParts rescued KDE 2.0
      - tguvot 3y ago

seren 3y ago

I am still working on a code base that has slowly evolved from around 2000 with as its core CORBA as the internal communication bus between actors, so we still use it. We likely want to remove it because it is a bit an overkill in our application, but at the same time it is working and no one wants to pay for a rewrite.

willis936 3y ago

I worked at a defense contractor small business for a short while that used CORBA in some of its products. Previous engineers declared it impossible to update, so they asked me to do it. I had to upgrade the C++ version for the first time in a decade. I didn't find it very fun, but it was satisfying to see an ancient program compile on a more modern toolchain.

pjmlp 3y ago

It was used by Nokia Networks for all their HP-UX based infrastructure, in a mix of C++ and Perl. Eventually it was replaced by a new server infrastructure based on Java EE and Red-Hat Linux.

SSLy 3y ago
CORBA itself is still used there for that purpose.