Linux DCE, CORBA, and DCOM Guide (2001) | Hacker News Reader

Linux DCE, CORBA, and DCOM Guide (2001)

linas.org

36 pointsLammy32 comments

If not for TBL and Roy Fielding, these words would still mean something to people, and we would all be worse off.

Unfortunately I know exactly what CORBA means. Helming a legacy project that still contains the requirement of using CORBA is a real bugbear of mine. It takes non-trivial effort to even build the ORB we use (OmniORB) for each platform we support (the number is low, currently 4) that its effectively the only library we don't build from source each time. Every now and then, someone struggles to build it, we then check in the built libraries and forget about it for as long as we can.

Isn't that a problem with OmniORB and no CORBA?

I started writing then went on to automatically vent. I extend my apologies for wasting everyone's bandwidth. There are better technologies to use that can do pretty well everything that CORBA offers. That's the source of my general frustration, OmniORB just extends that frustration.

Nah, not a waste of time - I understand the feeling!

> extend my apologies for wasting everyone's bandwidth.

No excuses needed, it is still informative.

Curious question: What are the technical/political reasons to keep ORB/Corba in your project right now ?

There's no strict technical reason for keeping Corba around. It's primarily an issue of finance. Where I work there's no real way to get funding for a maintenance task if it doesn't directly relate to a specific project (we produce a product that is utilised by various projects, and through those projects get the funding for new features, and maintenance). There's no external call to not use Corba, so we will continue to use Corba.

This is now a compounding issue, the tool that uses Corba was initially quite standalone but managers started pushing the tool as an interface to the embedded system I actually work on, this has resulted in more tools utilising Corba.

I suspect it is related though - CORBA is a zombie technology, so a lot of the code related to it is old and crusty, predates contemporary best practices, etc - and all that could be fixed, but its status as a dying technology means almost nobody has the motivation to spend the effort to fix those issues (anyone hit by them is likely going to decide that time and money is better spent replacing CORBA than improving their CORBA implementation), and as a result many of those issues will likely never get fixed

More that most of the better quality stuff is proprietary, and often mixed with somewhat specific environments with specific kinds of clients... and thus not really supported in the open.

A lot of the time I'd say CORBA and related stack (DDS, for example) is better than what came to replace it, depending on the task :/

DCE/RPC is used today! Lots of factories running this crusty stuff to interconnect PLCs:

https://wiki.wireshark.org/PROFINET/IO

My favorite part of RPC is that it has a header with switchable endianness and a field for what floating point encoding you would like to use. For when your machine encodes Cray-compatible:

https://pubs.opengroup.org/onlinepubs/9629399/chap14.htm

DCE/RPC is basis for DCOM as well.

And honestly, Profinet is one of the best fieldbuses out there (DCE is used in the setup phase, afterwards it's pretty much always raw ethernet though there's UDP mode documented somewhere).

> DCE/RPC is basis for DCOM as well.

I wonder how interoperable DCE/RPC and MS-RPC are though?

I mean, if I have a DCE implementation (for example IBM Encina), can I successfully talk to it using the MS-RPC client and server libraries bundled with Windows?

Maybe back in Windows 9X days, nowdays the protocol has evolved enough that I seriously doubt it.

The main issue is that MSRPC runs DCE over SMB named pipes - so one can't just take random DCE implementation and make it talk to NT's.

But AFAIK once you get onto named pipe transport, the protocol at worst got extended but not changed too much (new crypto options mainly, iirc?)

There are all the changes related to turning Loghorn ideas from .NET into COM as of Vista, and then the WinRT evolution with a new type system based on .NET metadata.

Looking over protocol extensions from Microsoft, the changes aren't that big for RPC itself, and might be actually smaller for ORPC (aka what DCOM-over-RPC).

Samba file server started out this way.

More than that. DCE/RPC is what underlies DCOM and DCOM is the basis for OPC, a.k.a. "OLE for Process Control" which is (or was) widely used in factories and SCADA settings.

https://www.aboutmechanics.com/what-is-ole-for-process-contr...

OPC-DA is still big but mercifully slowly and surely replaced by OPC-UA, which is properly portable.

OPC-DA essentially operated a lot like TWAIN - it specified an interface for OLE-loadable DLL to load, which would then implement actual communication driver for your infrastructure. OPC-UA describes its own protocol to talk between devices.

I thought DCOM i.e. wire protocols were a big part of OPC too. But maybe it evolved in that direction over time? Like, if the COM interface is simple enough they realized you don't need a driver if DCOM is doing what the driver would do anyway.

Nope, you install an OLE control on the system that wants to communicate, then tell the SCADA/etc application to use it, and the control talks vendor-specific protocol.

Newer OPC-UA capable devices could arguably run like that (definitely enough power, even without going for the ones that have full Linux system with Docker), but those tend to run OPC-UA instead which is way more capable and interoperable.

Huh, I wonder what this sort of thing is about then:

https://www.matrikonopc.com/dcom-configuration-opc.aspx

It's essentially a proprietary proxy + tunnel - on the client, you install their COM object as OPC service, then it goes over tunnel to a server process which talks to actual vendor OPC DCOM library using local COM.

Understandable when configuring security can be a big PITA.

I’m sorry, what’s TBL?

And when you refer to Roy Fielding, do you mean REST is much better than CORBA/DCOM/etc.? On REST, all I can say is that while it’s okay, I’ve been using GraphQL pretty much exclusively for the last year, and it’s been quite superior to REST.

Tim Berners-Lee

https://en.wikipedia.org/wiki/Tim_Berners-Lee

GraphQL is orthogonal to REST. GraphQL is a query interface, nothing more. Now, if you (incorrectly) conflate HTTP and REST, I can see how you'd make this mistake given the limits on URL length, but even then there's absolutely nothing preventing a GraphQL query being serialised as a URL.

I disagree, given the tooling and how REST, graphQL and gRPC are a mess of lego blocks put together via clunky tooling without structure.

Also the reason why Google had to come up with gRPC, kind of proves the point how HTTP based protocols don't meet the performance demands of those protocols.

Also why Linux distributions use D-BUS, Android has Binder, Fuchsia FIDL, and Apple platforms XPC.

Let's not forget Cap'n Proto.

Sure, and there are yet others that I surely forgot.

Laughs in Google's Protobufs

If someone put a gun to your head and told you to talk to CORBA or DCOM today, would it be better to re-implement the protocols in a modern language or dig up ancient C++ code, compile it and just talk to the C++ with language interfaces?

Reimplement the protocols, talking with C++ is more painful than implementing complete CORBA or COM or DCOM.

For a bit of reference - When I was younger and more optimistic (actually maniacal phase in depression...) I figured I'd implement a C++ interop that didn't use a wrapper in C.

I think I stopped when I got a waking nightmare starring GCC's IA-64 ABI vtable layout after a night of digging deep in the shittiness that is C++ exception model and its handling in IA-64 ABI.

Reply on news.ycombinator.com