The Glory and Twilight of WS-*: How Enterprise IT Lost to "Implementation" [Learning from IT History]

Hello.

—— From SOA in 2003 to AI in 2026 ——

This article looks back at past technology trends and reflects on the lessons we can draw from them.

History always teaches us that what seems obvious in hindsight was invisible at the time.

And what we believe to be "right" today may well be judged differently twenty years from now.

That is exactly why looking back is worthwhile — so we do not repeat the same mistakes.

Introduction: Do You Remember the Frenzy of Twenty Years Ago?

The early 2000s.

I was seriously committed to SOA (Service-Oriented Architecture).

At the time, SOA was hailed as "the next generation of enterprise architecture," and the entire industry was swept up in the excitement.

Conferences were packed, vendor booths drew crowds, and related books were showing up in bookstores.

SOAP, SOAP with Attachments, JAX-RPC, WS-Security, WS-ReliableMessaging, WS-AtomicTransaction... my days were spent wrestling with mountains of specifications.

More than twenty years have passed since then.

Is anyone today considering implementing WS-ReliableMessaging in a new project? Most developers probably do not even know the specification exists.

We at Qualiteg now operate in the generative AI space, working on everything from GPU cluster construction to deep learning model development and LLM platform implementation.

And that experience has taught us something.

In the world of technology, the same patterns repeat themselves.

That is why I want to look back at the grand experiment that was WS-* and SOA. This is not nostalgia. It is a modest exercise in learning from the past, so that those of us living in the AI era do not repeat the same failures.

Chapter 1: When Words Are Born

1996: The Birth of a Magic Phrase

"Service-Oriented Architecture" — the phrase first appeared in a 1996 Gartner report. One of its authors, Roy Schulte, would go on to coin a string of terms such as "Enterprise Service Bus" (2002) and "Business Activity Monitoring."

The invention of terminology holds a peculiar power in the IT industry.

When a new term is born, products bearing that name follow, reports explaining it sell, and CIOs who read those reports secure budgets. A term creates an ecosystem of its own.

Schulte's vision was grand. He positioned the ESB as an integration layer combining the reliability of message-oriented middleware with the service abstraction of SOA, and in his 2003 report "Predicts 2003: Enterprise Service Buses Emerge," he foretold that the ESB would become the core of enterprise IT.

In a sense, the prediction was self-fulfilling.

When an influential analyst says "this is coming," CIOs start preparing. Vendors build products. Consultants sharpen their expertise. And a market is born.

"Enterprise": The Magic Adjective

Do you remember the atmosphere back then?

The word "enterprise" had a magical quality.

"Enterprise-grade" meant serious, reliable, worthy of a large corporation.

"SOAP alone is not enough." "Serious systems need WS-*." Such voices echoed through conference hallways. SOAP is a heavy enough protocol as it is, yet its simplicity was, if anything, regarded as a flaw. Complexity itself may have been the badge of expertise.

I myself was immersed in that atmosphere at the time.

Being able to decipher complex specifications was a kind of status symbol. Looking back, it may have been a case of the emperor's new clothes.

I also remember being overwhelmed by the intensity of a one-on-one meeting with a Gartner analyst visiting from the United States.

Chapter 2: The Battlefield Called Standardization

The Turf War Over Specifications

As the concept of SOA spread, standardization efforts accelerated.

Standards bodies such as OASIS and the W3C drew the major vendors: IBM, Microsoft, Oracle, and Sun.

They championed the noble goal of "interoperability." But what actually went on in the meeting rooms appears to have been a rather more human game of maneuvering.

Take WS-Security as an example.

The specification was originally published jointly by IBM, Microsoft, and VeriSign in April 2002 (with contributors from other IT companies and manufacturers listed among the authors).

But when it was later submitted to OASIS for standardization, the specification underwent "major" changes. As a result, systems built on the original specification and systems built on the OASIS standard could no longer interoperate.

"Standardization for interoperability" produced non-interoperability. Perhaps only the engineers who struggled with those implementations at the time can appreciate the irony. I was one of them.

Two Kinds of Reliability

Even more interesting is that two competing specifications emerged for the very same problem of "reliable messaging."

This was a well-known story in SOA circles at the time.

On one side was the specification championed by IBM and Microsoft, WS-ReliableMessaging.

On the other side was the one championed by Sun and Oracle, WS-Reliability. The goal was the same — to guarantee reliable delivery of messages. But the approaches differed, and naturally there was no interoperability between them.

Why could they not be merged into a single standard? There were surely technical reasons. But it is not hard to imagine that behind each specification lay each company's product strategy.

A similar rivalry played out between WS-Addressing and WS-MessageDelivery. Both were submitted to the W3C around the same time and treated as "a normal part of the standardization process." For implementers, however, it meant uncertainty about which one to bet on.

Even plain SOAP messaging differed between the Java camp and the Microsoft camp.

The split between rpc-encoded (rpc/encoded) and document-literal (doc/lit) meant that if you built something without paying attention to it, the two sides could not even communicate.

(That said, it was not all specification-first: implementation-driven web service and SOAP stacks such as Apache Axis did exist, and were popular open-source projects at the time.)

Giants Who Lost Patience

IONA's CTO later offered an interesting account: IBM and Microsoft, having "lost patience" with the slow pace of security standardization at the W3C, took their specification to OASIS instead.

There were subtle dynamics among the standards bodies as well. The W3C was cautious, and building consensus took time. OASIS was more agile and more receptive to vendor-driven specifications. The vendors simply chose the arena that favored them.

As a result, the WS-* specifications, while keeping up the appearance of "open standards," increasingly aligned with the product strategies of the major vendors. The situation practically invited a philosophical debate about the definition of the word "open."

Chapter 3: From the Peak of Hype to the Trough

2003: The Peak of Inflated Expectations

WS-* technologies made a splashy debut on the 2003 hype cycle. "WS-*-based business models" were presented as heralds of a new era.

Conferences thrived. Vendor booths drew crowds, sessions were standing-room only, and consulting engagements to draw up "SOA roadmaps" sold briskly.

I was in the middle of that whirlwind — wrestling with complex specifications, debating with vendor engineers, trying to build something that actually worked.

2005: The Trough of Disillusionment

Yet just two years later, in 2005, WS-* had fallen into the "trough of disillusionment."

What happened? Put bluntly: self-destruction through technical bloat. Developers hated writing WS-* APIs. The specifications were bewilderingly complex — understanding one required reading three others. Interoperability testing was a nightmare.

You could implement a specification perfectly, only to find it would not connect to another vendor's implementation. Contact support and you would be told, "We haven't implemented that part yet." "What was standardization even for?" — that question began to be heard across the developer community.

2009: The Death Notice

Then, in January 2009, a shocking "death notice" was issued.

Anne Thomas Manes, an analyst at Burton Group, published a blog post titled "SOA is Dead; Long Live Services." She wrote: "SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession."

This was not mere provocation. Manes and her colleagues had conducted extensive research on companies pursuing SOA initiatives. Their conclusions were harsh.

Only a handful of companies — Bechtel, British Telecom, MassMutual, and a few others — were cited as success stories. The vast majority had failed to achieve the "cost reduction" and "improved business agility" that SOA had promised.

If anything, things had gotten worse at many organizations. Costs rose, projects dragged on, and systems became more brittle than before. The number of parts (services) grew, but the infrastructure to manage them never caught up.

Manes's article sent ripples through the industry. Some agreed, some pushed back. But what no one could deny was that the word SOA had lost its "magic."

Chapter 4: The Economics Behind the Scenes

Who Profited

Looking back on the WS-*/SOA era, there is a question we cannot avoid: who actually profited?

The answer is fairly clear.

First, the people who coined the terms and concepts and sold the reports. Every time a new buzzword was born, demand arose for reports explaining it. Corporate IT departments bought reports "to keep up with the latest trends" and paid for analyst inquiry services (essentially, a service where you ask a question and someone gives you an answer).

Next, the vendors who sold expensive middleware built for the complex specifications. ESB products, SOA suites, integration platforms — none of these came cheap. And the more complex they were, the more expensive the support contracts became.

And then the consulting firms that supported adoption. Implementing SOA required enormous consulting hours, from architecture design to governance frameworks to migration planning.

One article from that period put it scathingly: the big consulting firms focused on tactics and billable hours rather than outcomes, and wrecked many an SOA project.

Who Lost

So who lost out?

First, the engineers who actually did the implementation work. They wrestled with bewildering specifications, suffered through "standards" that did not interoperate, and ultimately had to answer the question, "Why doesn't it work?"

And then the companies that invested millions, sometimes tens of millions, of dollars. They had been promised "cost reduction" and "greater agility." What they got was the opposite.

Manes's findings were merciless: after investing millions, IT systems were no better than before. In many organizations, things were worse — costs were higher, projects took longer, and systems were more fragile than ever.

Buzzwords as a Business Model

Once you understand this structure, you can see why buzzwords keep being born at regular intervals.

A new term is coined. Reports explaining it sell. Products bearing its name sell. Consulting to deploy those products sells. And a few years later, the term is declared "old" and replaced by a new one.

This cycle is structured to benefit everyone involved — except the end-user companies. That is precisely why it keeps repeating.

After SOA came cloud, big data, IoT, blockchain, the metaverse, and now generative AI — one buzzword after another. Of course, some of these are genuinely transformative technologies. But an eye for separating hype from reality is always necessary.

Chapter 5: What Was Happening in Another World

Google's Quiet Revolution

While the WS-* specifications were being debated in committees, a company in California was taking an entirely different approach.

In the early 2000s, Google faced the pressing problem of managing rapidly growing infrastructure. It had to handle billions of requests a day and operate thousands of servers efficiently. There was no time to wait for specifications to be finalized.

What they built was an internal system called "Borg." It managed containerized workloads as hundreds of thousands of jobs and made highly efficient use of resources. Gmail, Google Search, YouTube, Google Maps — all of them ran on Borg.

What matters is that Borg was built not from "features we might need someday" but from "features needed to solve today's problems." They did not write a specification and then implement it. They solved problems, then refined the solutions.

Netflix's Choice

Around the same time, Netflix was fundamentally rethinking its own architecture. In 2008, at the turning point from DVD rentals to streaming, they appear to have hit the limits of their existing monolithic architecture.

What Netflix chose was not WS-*, but a microservices architecture. And they built their own tools to tackle the distributed-systems challenges of service discovery, load balancing, and fault tolerance.

Even more notable is that Netflix released these tools as open source. These libraries, known as Netflix OSS, became invaluable resources for other companies facing similar challenges.

Here lies the decisive difference from the WS-* era.

Netflix did not draft specifications. They released working code.

Chapter 6: The Paradigm Shift

The Era When Implementations Make Standards

In 2014, Google made a surprising decision.

Building on the lessons of Borg, it released an open-source container orchestration system: Kubernetes.

The Kubernetes developers set out to build something that incorporated everything they had learned from designing and deploying Borg and Omega, combined with an elegant, simple, easy-to-use UI. The prototype was reportedly completed in just three months.

Open-sourcing made the feedback loop immediate. Problems surfaced quickly, and talented engineers around the world contributed improvements. By 2017, Kubernetes had overtaken Docker Swarm and Apache Mesos to become the industry standard for container orchestration.

This standardization process was fundamentally different from that of WS-*.

The specification was not decided in committee and then implemented.

The implementation came first, and through its widespread use it became the de facto standard.

The Victory of REST/JSON

The same thing was happening in the world of APIs.

Where WS-* demanded complex XML envelopes and rigid schemas, REST used HTTP's simple verbs (GET, POST, PUT, DELETE), and JSON offered a lightweight, human-readable data format.

In theory, WS-Security offered richer security features. WS-ReliableMessaging offered stronger reliability guarantees.

But developers chose REST and JSON. Whether or not any given API was strictly REST"ful", that lineage is what caught on.

Today, nearly every new API is built with REST and JSON. The Google Maps API, the Twitter API, the GitHub API — the APIs of major services are overwhelmingly RESTful. WS-* has all but disappeared, except where integration with legacy systems requires it.

Chapter 7: What Separated the "Failures and Successes" of the Two Eras

The difference between WS-* and modern cloud-native technology is
not simply "old technology vs. new technology."

It is a difference in where standards are born.

Much of WS-* was born in the meeting rooms of standards committees.
There, anticipating "every case that might someday be needed" and
pursuing completeness in the specification were considered virtues.

In contrast, much of today's distributed-systems technology
was born on the front lines of operating enormous services.
What companies like Google, Netflix, and Amazon faced was
the reality that "the system could go down today, this very moment."

This difference shows up directly in design philosophy.

WS-* stood on the worldview that
"if you conform to the specification, it should work correctly"
.

Modern technology stands on the worldview of
"assuming things will break, and focusing on how to recover"
.

For example, WS-ReliableMessaging tried to
guarantee message delivery at the specification level.
Kafka and SQS, on the other hand,
start from the premise that messages can be lost, and
secure reliability through operational design: reprocessing, idempotency, and logs.

This is less an advance in technology than a shift in philosophy.

The place where this difference in philosophy appears most symbolically is
UDDI.

UDDI is often cited as a failure of "service discovery,"
but the idea itself was in fact remarkably ahead of its time.

What UDDI aimed for was
"a world where services are discovered by meaning, not by URL."

It was continuous with the school of thought later called the "Semantic Web."
A service, in this view, is not a mere endpoint;
it should carry
semantic metadata describing what it can do and which business functions it serves.

But UDDI lacked one decisive thing:

an entity that would actually "use" that meaning.

Chapter 8: Why SOA Was Too Early, and Why AI Is Starting to Work

In the world UDDI envisioned,
services were to be described by meaning and discovered by meaning (semantics).

In practice, however, it was humans who searched for and selected them.
Engineers chose categories, typed in keywords,
and ultimately read the specifications to make a decision. (And because the system was designed under the "pretense" that computers would do the searching, it was hard for humans to search.)

In this model,
the cost of rigorously describing meaning yields no matching return.
UDDI held the "right idea,"
but was born into a world — or rather an era — that had no intelligence capable of making use of it.

Now, let us bring our perspective back to 2026.

Today, we have acquired LLMs — "entities that can handle meaning".
And MCP and agent frameworks are
beginning to rebuild the world UDDI dreamed of, in an entirely different form.

The crucial difference is this.

• UDDI was a world where humans read the meaning
• MCP is a world where machines read the meaning

Tool definitions and schemas in MCP are
not documentation for humans.
They are descriptions for an LLM to understand as capabilities and execute.

One could say this took the problem the Semantic Web had always carried —
the "dual structure for humans and machines" —
and solved it by brute force.

Taking the AI-Era Lesson One Level Deeper

SOA did not fail.
Many of its ideas were simply too early.

• Trying to describe the world completely through specifications
• Trying to discover services by meaning
• Aiming for vendor independence

These are strikingly close to the values of today's AI era.

The difference is that
back then, no "intelligence" existed that could truly put them to use.

What we should watch for now, in the world of AI,
is not repeating SOA's mistakes.

Rather, it is
the awareness that "this time, it may actually come true".

Choosing tools by meaning,
judging correctness by execution results rather than specifications,
and letting working code set the standards.

This world is no longer a hypothesis.
It is already in motion.

History Rhymes

We at Qualiteg operate in the generative AI space — LLM platforms, AI avatars, LLM security — facing cutting-edge technology every day.

And sometimes it strikes us: does today's frenzy in the AI industry not resemble the SOA boom of 2003?

New terms are being coined one after another: AGI, ASI, multimodal, RAG, agents, MCP... Conferences are packed.

Consulting engagements to draw up "AI strategies" are selling well (for which we are grateful).

An air of "adopt AI or fall behind" surrounds the executive suite.

Of course, generative AI is a genuine technological revolution.

We run our business in this space precisely because we believe in its potential. But that is exactly why we must not forget the lessons of SOA.

Three Questions

When evaluating an AI technology, I always ask three questions — lessons learned in the SOA era.

The first question: "Does it actually work?"

No matter how beautiful the specification or white paper, it means nothing if it does not actually run. We run and validate models on our own GPU infrastructure. There is always a gap between theory and implementation.

The second question: "Who profits?"

When a new technology or framework is proposed, understanding the incentive structure of its proponents is highly instructive.
It is only natural for those who want to sell something to say it is wonderful.
The question is whether it is also wonderful for the people who actually use it.

The third question: "Can it be solved more simply?"

Complexity is itself a risk. WS-*, in trying to handle every conceivable case, reached a level of complexity no one could use. We should always ask whether a problem can be solved with the minimum necessary complexity.

Remaining Implementers

In the SOA era, the biggest losers were the "implementers" — the people who wrestled with the specifications and were held responsible for systems that did not work.

We want to always be implementers. Not just talking about concepts, but building things that actually work: constructing GPU clusters, training models, operating in production.

Because the true worth of a technology can only be proven through implementation.

Kubernetes was born from Borg, which Google had operated internally for more than a decade. Kafka is the open-sourced version of a system LinkedIn used in its real data pipelines. OAuth 2.0 evolved through the trial and error of countless authentication systems.

In every case, working code came first.

Toward the Democratization of AI

The same thing is starting to happen in the world of generative AI.

The technology pioneered by OpenAI and Anthropic is being rapidly democratized by the open-source community: Llama, Mistral, Qwen, and models strong in Japanese. Anyone can download them, run them on their own infrastructure, and customize them.

Our Bestllam is a platform that provides access to more than 20 of the latest LLMs through a single interface. It is also an attempt to realize, in a different form, the ideal that the SOA era promised but never delivered: freedom from lock-in to any single vendor.

LLM-Audit is a security solution that detects and blocks information leaks to LLMs. In contrast to WS-Security, which was too complex to use, we aim for security that is simple and practical.

Conclusion: Working Code Beats Specifications

The transition from the era of WS-* and SOA to today's cloud-native world was, in a sense, a victory for democracy in technology.

Once, technical standards were decided in committee meeting rooms. Representatives of the major vendors drafted specifications, and following them was assumed to be "best practice."

Today, technical standards take shape in GitHub pull requests. Anyone can read the code, anyone can file an issue, anyone can contribute. The merit of a technology is now judged not by the thickness of its specification, but by whether it actually works.

Around 2003, I wrestled with SOA's complex specifications. In 2025, I wrestle daily with newly released AI papers, AI products, Python, and LLM prompts. The technology has changed. But the essential questions have not.

"Does it actually work?"

"Does it solve the problem?"

"Does it make the people who use it happy?"

In the AI era, too, I want to keep these questions in mind. Do not be swayed by buzzwords; stay honest to implementation. That is the modest lesson from someone who lived through the SOA era.

That said, today's AI era holds one more new temptation.
With tools like Claude Code, code is generated at astonishing speed.
It is an era in which code "gets written" faster than you can read a specification, before you can even finish the discussion.

That is why
the phrase "working code beats specifications"
has come to carry a slightly different ring than before.

Writing code itself now requires almost no effort.
Only the time spent thinking about what to write
quietly remains on the human side.

About the "Learning from IT History" Series

In this series, we look back at events in the IT industry's past and search for lessons that apply today. The aim is not nostalgia but — in the spirit of "history rhymes" — to share the wisdom needed to avoid repeating the same mistakes.