Ask HN: Why did COM/SOAP/other protocols fail?

SOAP lost to JSON because JSON was easier to handle in a browser or a shell script.

In the world I'm living in, corporate IT, there's a ton of COM and SOAP. I don't see COM running across the Internet (other than thru VPN tunnels), but I see a ton of SOAP for interop with third-party interfaces. Pretty much any of the "enterprise" Java-based apps I work adjacent to have SOAP-based interfaces.

COM is alive and well in the LAN space, too. I see it in industrial automation under the guise of OPC, fairly frequently, too.

Re: COM: I'd say it really depends on how you define "fail." I'm going to suggest that you're asking why it does not come up with most developers on a day-to-day basis.

I say this because COM and DCOM are very much alive in the Windows ecosystem, underlying WinRT, which underlies the object-oriented APIs for modern Windows apps.

You should throw in CORBA from the 90s for completeness.

My view mostly it was a confluence of poor dev experience and over-engineering that killed them.

Some of those protocols were well designed. Some were secure, all were pretty awful to implement.

It’s worthwhile calling out REST as a long term success. Mainly because it was simple and flexible.

Whether MCP will have that staying power I dunno, personally I think it still has some flaws, and the implementation quality is all over the shop. Some of the things that make it easy (studio) also create its biggest flaws.

Security was a pain to implement and easy to punch holes through. Unregistering, updating, reregistering libraries across remote sites sucked unless you had a good method, which we didn’t.

Same reason most of the dev tools fail sooner or later: overengineering

Because they were complex shit made for elitist purist morons.

Simple is beautiful.

Early Javascript and HTTP based APIs killed a lot of it. People generally did not want to put a ton of serialization code into their websites, just to call some API. Building XML and JSON APIs into the browsers was much more attractive.

That's started going the other direction, with people are more willing to do things like generate code for GraphQL, now that code size is less of an issue.

Besides that, a lot of these protocols come with other baggage due to their legacy. Try reading the COM documentation relating to threading: https://learn.microsoft.com/en-us/windows/win32/com/in-proce...

Having spent quite a bit of time on this in the past, a few things: 1. there has not been enough adoption of Data Oriented Programming (DOP) vs OOP, and how things like COM or CORBA (RPC essentially) are different than loosely-coupled REST (XML-RPC or some of SOAP or say Kafka) - 2. they "failed" in the sense of not taking over the world, but they were very successful in taking share of the world, and are still used widely, as others pointed out 3. there is an unfortunate tendency not to study data interoperability and instead repeat the past - which makes it hard to "build on the shoulders of giants" 4. there are some specific technical issues in encoding and tooling that hampered adoption of the specific ones you cite (MSFT platform constraints for some of them, OMG CORBA licensing, XML syntax and ecosystemc complexity friction, JSON ascendancy but without structure, etc.)

Could do a whole API AMA on this.

I think it's more that the landscape has evolved. When systems that needed to exchange information were maintained by enterprises, SOAP made sense (and still does, if you ask some of my ex-colleagues).

When web development became accessible to the masses and the number of fast-moving resource-strapped startups boomed, apps and websites needed to integrate data from 3rd parties they had no prior relationship/interaction with, and a lighter and looser mechanism won -- REST (ish), without client/server transactional contracts and without XML, using formats and constructs people already knew (JSON, HTTP verbs).

SOAP achieved functional obsolescence. If you go back before 2005 JSON did not exist and nobody except a Microsoft webmail client were making dynamic HTTP calls. XML was young and growing wildly out of control.

XML had two problems. Most obviously it is verbose, but people didn’t care because XML was really smart. Amazingly smart. The second problem is that XML technologies were too smart. Most developers aren’t that smart and had absolutely no imagination necessary to implement any of this amazing smartness.

JSON kind of, but not really, killed XML. It’s like how people believe Netflix killed Blockbuster. Blockbuster died because of financial failures due to too rapid late stage expansion and format conversion. Netflix would have killed Blockbuster later had Blockbuster not killed itself first. JSON and XML are kind of like that. JSON allowed for nested data structures but JSON tried to be smart. To the contrary JSON tried to be as dumb as possible, not as dumb as CSV, but pretty close.

What amazes me in all of this is that people are still using HTTP for so much data interchange like it’s still the late 90s. Yeah, I understand it’s ubiquitous and sessionless but after that it’s all downhill and extremely fragile for any kind of wholesale large data replication or it costs too much at the thread level for massively parallel operations.

SOAP was actually pretty easy to use, once it settled out.

For the most part, everyone used some kind of SDK that translated WSDL (Web Services Description Language) specifications to their chosen language.

So you could define almost any function - like PostBlog(Blog blog), and then publish it as a WSDL interface to be consumed by a client. We could have a Java server, with a C# client, and it more or less just worked.

We used it with things like signatures, so the data in the message wasn't tampered with.

Why did it stop getting popular? It probably really started to fall out of favor when Java/C# stopped being some of the more popular programming languages for web development, and PHP and Ruby got a lot more momentum.

The idea was that REST/JSON interfaces would be easier to understand, as we would have a hypermedia interface. There was sort of an attempt to make a RESTy interface work with XML, called WebDAV, that Microsoft Office supported for a while, but it was pretty hard to work with.

I've got some old SOAP code from 2001 here at the bottom of this article:

https://www.infoworld.com/article/2160672/build-portals-with...

They were trying to solve both enterprise integration and user app deployment. In another example of "worse is better", HTTP/REST (ish) for the former and browsers for the latter won. Just so much easier and good enough. That browsers and HTTP were the same "platform" of course helped. COM/DCOM/SOAP/CORBA and others were just way way too much work.

Relatedly, nobody really does REST as Roy F initially defined, which is now referred to as HATEOS. Also too much work.

If you haven't read the Worse is Better paper, definitely worth it. Top 5 all time.

SOAP started life as XmlRpc. It was a simple model used in Python. It was a simple serialisation format. It was a micro format and could be implemented in a day. It didn’t cover encryption, signing , routing, cyclic references. But it could be implemented in a day. It’s all text and easy for implementers to fix. Since these were early days of the web, there were no openidconnect, no jwt, no encryption standards. If you used Ruby you couldn’t easily interoperate if there were standards calling for all these things. The SOAP specs were big documents.

Many comments highlight their complexities. Ironically, SOAP itself stands for Simple Object Access Protocol. What strikes me as remarkable is that CORBA, COM, and SOAP all emphasized distributed object communication, while more recent alternatives—REST, JSON, gRPC, and GraphQL—focus instead on message formats and discard the entire notion of distributed objects.

SOAP had a lot of security holes.

A lot of the top vulnerabilities are from SOAP: https://owasp.org/www-project-top-ten/

This is one that affects SOAP:https://owasp.org/www-community/vulnerabilities/XML_External...

XML Injection is tied to that and with the decline of SOAP, it was no longer a top vulnerability.

There's another more comprehensive list here: https://brightsec.com/blog/top-7-soap-api-vulnerabilities/#t...

DCOM "failed" because (a) it's based on COM which is based on C++ style vtables and is hard to version/consume, and (b) because doing reference counting over the internet is never going to work well.

But I work in the industrial automation space and we deal with OPC-DA all the time, which is layered on top of DCOM which is layered on COM on Windows. DCOM is a pain to administer, and the "hardening" patch a couple of years ago only made it worse. These things linger.

SOAP was nice and simple until the Architecture Astronauts got their hands on it and layered-on lots of higher level services.

MCP isn't really like either of these - its an application-level protocol, not a general-purpose one.

> Why did these 2000s era interoperability protocols fail?

They didn't. SOAP is still widely used. COM and CORBA and similar IPC were mostly replaced by HTTP-based protocols (which would have seemed as a wasteful overkill for a few decades ago, now nobody bats an eye) like REST or GraphQL.

> what does MCP do different?

Nothing, it reinvents the wheel. To be charitable, let's call it starting from a clean slate :)

> Was it a matter of security issues in a newly networked world?

Lol, no. As we all know, "S" in "MCP" stands for "security". These older geezers like SOAP can be secure when properly implemented.

> A matter of bad design?

They are definitely much more complex then some of the newer stuff, mostly because they grew to support more complex use cases that newer protocols can avoid or simplify. And yeah as commented on other comments, heavy "oop" influence which new stuff has rolled back considerably.

> A matter of being too calcified

More a matter of not being in vogue and not supported out of the box in languages such as JS or Python.

One thing I would mention is that COM and CORBA have explicit support for object references, which is a concept that disappeared from later protocols.

With these technologies, a server can return a reference to, say, a Person. The client can then do "person.GetName()" or similar. The method calls are implemented as "stubs" that act as proxies that simply send the RPC along with the references to the objects they operate on. The server-side RPC implementation keeps a mapping between references and actual in-memory objects, so that calls to references call the right thing in the server process.

The benefit is that you can work with APIs in ways that feel natural. You can do "persons.GetPerson("123").GetEmployer().GetEmployees()" or whatever — everything feels like you're working with in-memory objects.

This has drawbacks. One is that the cost of method calls is obscured by this "referential transparency", as it's never obvious what is remote or local. Another problem is that the server is required to keep an object around until a client releases it or dies. If the client dies without first releasing, the objects will live until a keepalive timer triggers. But because a malformed client can keep objects around, the system is vulnerable to high memory use (and abuse). In the end you'd often end up holding a whole graph of objects, and nothing would be released until all references were released. Leak can be difficult to find.

My knowledge of COM/CORBA may be incomplete, but never understood why the server couldn't implement these in terms of "locators". For example, if a server has a "GetPerson(string id) -> Person" type method, rather than sending an object reference that points to an in-memory person object, it could return a lightweight, opaque string like "person:123". Any time the client's internal proxy passed this back to the server, the server could look it up; the glue needed to resolve these identifiers back into real objects would be a little more work on the part of the developer, but it would sidestep the whole need to keep objects around. And they could cached quite easily.

Cap'n Web [1] is the first RPC system in a long time (as far as I know) that implements object references. However, it does this in a pretty different way with different pros and cons.

[1] https://blog.cloudflare.com/capnweb-javascript-rpc-library/

[dead]

This is a good enough question that I wrote a whole essay to answer it!

https://medium.com/@octskyward/why-did-the-%C3%BCber-protoco...

COM components, such as ActiveX, are available only on Windows.