Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rise and Fall of CORBA (2006)

queue.acm.org

Post reply on HN
Print view View original

121–130 of 156 posts

Re: The Rise and Fall of CORBA (2006)

#121

Post by stickfigure »

atombender wrote: post #96
stickfigure wrote: post #18

Earlier quoted context omitted.

We've finally come full circle with gRPC, which is basically a simplified CORBA. I went through the whole cycle, and while I don't exactly miss CORBA, I do wonder why it took us so long to get back to that baseline of functionality.

gRPC arguably isn't anything like CORBA. It's just RPC. The thing that CORBA (and COM/DCOM) gives you on top of RPC is object references, what's called location transparency in DCOM. That is, if you have an API like this: *Pie getPie() then the remote server simply returns an object reference. What you have on the client-side is a "stub" (what COM/DCOM calls a proxy), which might look like this: class Pie { int getSi…

That's true, but my impression back when I was using CORBA and EJB and Java RMI is that nobody really cared about remote object identity and really just wanted a convenient RPC solution. Ie use EJB stateless beans instead of stateful beans.

So while CORBA could do a lot more, it wasn't necessarily being used that way. At least not anywhere I saw; maybe there were shops out there doing more exotic things.

Re: The Rise and Fall of CORBA (2006)

#122

Post by Animats »

eternityforest wrote: post #64
Animats wrote: post #27

We might see a comeback of something like CORBA. One of the things CORBA was supposed to do was to enable a mechanism to ask a server "How do I talk to you"? While that wasn't really used much, it has real potential for the LLM era. We need technologies where a client asks the server how to talk to it, then generates the appropriate requests automatically. For example, you should be able to ask anything with a shoppi…

I think negotiation can be a bad thing. Instead of just making a standard so a server can say "This server complies with the BuyCrap 2.0 protocol", and a way to discover this fact, people make up garbage like "This server has a method called AddToCart which takes a string and an integer in this range". The introspection mostly is used to ask "do you have this feature I already know about from the spec that really sho…

> about the same level of effort as just reading a REST API document anyway, at least for basic use cases.

The idea is to automate that, using a LLM to read a description and create the appropriate reply messages, retrying until it works. You need at least a rough specification and semi-useful error messages. Then let the system work until it has established communication.

Re: The Rise and Fall of CORBA (2006)

#123

Post by lelanthran »

naasking wrote: post #99
stickfigure wrote: post #86

Earlier quoted context omitted.

This is also nonsense. 99% of the time these failure modes are irrelevant. A remote call fails, the error propagates up the call stack, and someone gets an error message. Just like any of the thousands of other things that can produce errors in complex systems. In the rare case you need to harden a particular call, you add caching or retries or whatever other logic fits your use case. It matters not one bit whether y…

> A remote call fails, the error propagates up the call stack, and someone gets an error message. Uh-huh, but did the message actually get through? Can they safely just retry? These are very uncommon failure modes on local systems but very common on networked systems. Without a proper stateful abstraction beyond just "procedure call", like a promise, you can't address these failure modes properly. > In the rare case…

> Uh-huh, but did the message actually get through? Can they safely just retry?

...

> The use of promises and await indicates a possibility of failure semantics that would otherwise not be apparent in the program's control-flow.

They don't, though. They don't indicate if the message got through. They don't indicate if you can safely retry. Their failure mode is exactly as opaque or as transparent as synchronous calls.

The reason for their existence and mandatory use in Javascript is due to a deficiency of the platform (single thread, so all synchronous calls block).

If the platform was better they would never have existed.

Re: The Rise and Fall of CORBA (2006)

#124

Post by webnrrd2k »

jodrellblank wrote: post #90
tragomaskhalos wrote: post #12

The old adage: "the first rule of distributed objects: don't distribute your objects". DCOM and EJB also came unstuck by failing to observe this rule. It's impossible for young'uns to appreciate just how obsessed the software world was by 'objects', OO and the chimera of reusability in those days; I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke develo…

> " I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application. " One drum I keep beating is that COM in Windows is amazing for scripting and interoperability between programs. Before PowerShell and "everything is an object [but you're stu…

COM was awesome tech! I wish we had an equivalent today.

I did a ton of python-com projects for a big aerospace company in the late 90's and it was amazingly easy to get a lot of well-integrated functionality for little time and effort. Really sad that it's not more common now.

Re: The Rise and Fall of CORBA (2006)

#125

Post by anthk »

jodrellblank wrote: post #90
tragomaskhalos wrote: post #12

The old adage: "the first rule of distributed objects: don't distribute your objects". DCOM and EJB also came unstuck by failing to observe this rule. It's impossible for young'uns to appreciate just how obsessed the software world was by 'objects', OO and the chimera of reusability in those days; I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke develo…

> " I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application. " One drum I keep beating is that COM in Windows is amazing for scripting and interoperability between programs. Before PowerShell and "everything is an object [but you're stu…

>don't know what they're missing

Maybe you don't kow what you are missing by just using pipes with small binaries for everything :)

Re: The Rise and Fall of CORBA (2006)

#126

Post by pjmlp »

webnrrd2k wrote: post #124
jodrellblank wrote: post #90

Earlier quoted context omitted.

> " I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application. " One drum I keep beating is that COM in Windows is amazing for scripting and interoperability between programs. Before PowerShell and "everything is an object [but you're stu…

COM was awesome tech! I wish we had an equivalent today. I did a ton of python-com projects for a big aerospace company in the late 90's and it was amazingly easy to get a lot of well-integrated functionality for little time and effort. Really sad that it's not more common now.

COM is the main Windows API since Longhorn ideas were redone as COM.

It isn't going anywhere, even if the tooling keeps as clunky as ever.

Re: The Rise and Fall of CORBA (2006)

#127

Post by pjmlp »

tragomaskhalos wrote: post #12

The old adage: "the first rule of distributed objects: don't distribute your objects". DCOM and EJB also came unstuck by failing to observe this rule. It's impossible for young'uns to appreciate just how obsessed the software world was by 'objects', OO and the chimera of reusability in those days; I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke develo…

The world is still obsessed.

REST, GraphQL and gRPC language specific SDKs aren't any different, and now we have containers and kubernetes in addition.

Re: The Rise and Fall of CORBA (2006)

#128

Post by pjmlp »

jodrellblank wrote: post #90
tragomaskhalos wrote: post #12

The old adage: "the first rule of distributed objects: don't distribute your objects". DCOM and EJB also came unstuck by failing to observe this rule. It's impossible for young'uns to appreciate just how obsessed the software world was by 'objects', OO and the chimera of reusability in those days; I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke develo…

> " I subscribed to 'Object' magazine, and still recall one article breathlessly predicting that in the future bespoke development would become bunk as folks would just buy e.g. an Aircraft object off the peg and plug it into their application. " One drum I keep beating is that COM in Windows is amazing for scripting and interoperability between programs. Before PowerShell and "everything is an object [but you're stu…

On macOS you can take advantage of Objective-C runtime or XPC.

On mobile OS, entitlements or OS IPC like Binder.

In what concerns Windows it is still pretty much present tense, how COM is spread all around the OS, specially since Vista.

Re: The Rise and Fall of CORBA (2006)

#129

Post by pjmlp »

js2 wrote: post #2

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_A... In my 25+ year career I haven't seen it in use anywhere. I only ever encountered it while getting my CS degree.

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.

Post reply on HN