Why did COM/SOAP/other protocols fail?

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.

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

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.

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

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.

Because they were complex shit made for elitist purist morons.

Simple is beautiful.

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.

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...

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.

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).