The mail just keeps coming. As I’ve reviewed the barrage of electronic mail generated by the series of articles I wrote over the last four weeks discussing the impact of the Simple Object Access Protocol (SOAP), I noticed a few interesting “myths” developing as themes in the correspondence. I don’t think my columns served to create or propagate these myths, but I think it’s important to set the record straight once and for all.

Myth #1: SOAP is a Microsoft standard
This is a myth that comes from the “Microsoft conspiracy” camp. It’s both interesting and sad that ABMers (Anything But Microsoft) write off each new technology that Microsoft supports or shepherds through a standards process because it must be another “Microsoft standard.” It’s interesting because no public standard ever becomes dominant until one or more software companies embrace it. Some actually allow the standard to grow with support from the public (like Microsoft with its support of SOAP) while others decide that becoming “standard” isn’t worth the loss of potential revenue (like Sun with Java).

It’s sad because most of the people propagating these myths are actually very bright people who are advocates of Microsoft competitors like Sun and IBM. Calling SOAP a Microsoft standard is tantamount to saying that all of the people who Sun and IBM have committed to developing SOAP into a public standard are “slackers.” Given the heat of the competition in the market to develop next-generation Web services products, I think it’s a tribute to all the companies contributing to the SOAP specification that they’ve been able to balance their company’s competitive needs with the market’s need for an open, easily implemented, XML-based object protocol.

Myth #2: SOAP will replace DCOM, CORBA, and IIOP
SOAP may eventually evolve to the point that it has the robustness of Distributed Component Object Model (DCOM), Common Object Request Broker Architecture (CORBA), or Internet Inter-Orb Protocol (IIOP) for handling large-scale, transaction-intensive applications, but it’s not there yet. In the meantime, SOAP will primarily be a tool to help companies develop Web-facing service portals that will serve as front-end collectors and emitters for their back-end systems. I haven’t spoken to a single company that’s looking to replace all of their current back-end technology with a unified SOAP/XML system. Most are looking at this technology as a way to quickly expose the back-end systems in such a way that any consumer who can understand how to interface using SOAP can begin consuming their services. This myth will be the next favorite of those who believed all the similar “new technology” myths that preceded it, including:

  • ·        “COBOL will go away and be replaced by (FOCUS, C, Visual Basic, Java…).”
  • ·        “The last mainframe will be unplugged by (1995, 2000, 2005, 2010…).”

Myth #3: Developers will become obsolete
This is another one of my personal favorites, because I get to hear it about every five years. The logic goes something like this: Everyone rewrites their applications as services, services get cobbled together by scripting languages and Web pages, new products become simple recombinations of existing objects, and thus, the need for developers goes away. I still remember the day in early 1995 when the development manager of the team on which I worked announced that we would be rewriting all of our applications using FOCUS instead of continuing down the path of coding in COBOL and JCL. I was young and foolish enough at the time to agree with the senior developer on the team who moaned the “death of the programmer” when it became apparent to him that the difference in complexity between FOCUS and COBOL would make it simple for management to replace programmers with janitors.

What has become clearer to me since that time is that developers will always be around. Their ability to bridge the divide between existing business systems and processes and new technologies and the new process opportunities they create will ensure their survival. The tools they use will continue to get better at generating reliable and usable low-level code, allowing developers to spend more time analyzing problems and designing solutions. New development environments from Microsoft, IBM, and Sun will do a lot of the lower-level plumbing work that allows developers to create new SOAP-based systems or extend existing systems with SOAP wrappers, but they won’t obviate the need for people who understand how these systems will work.

Myth #4: SOAP will not be adopted
This myth is the exact opposite of the preceding one. There are a significant number of developers and development managers who believe that the learning curve for SOAP is too steep for the benefits it provides. And if they’re basing their opinions on the current effort required to create a SOAP-compliant application, register it, and keep it operational, then they’re probably right. But every new technology has a “settling in” phase where innovative companies create a support ecosystem around the technology that allows it to be used efficiently. SOAP is no different.

Tools vendors will release their SOAP support over the next 12 months. The books and magazines discussing the implementation specifics of SOAP are already flying off the shelf. The seminar, workshop, and training providers have already begun espousing the new technology. In fact, one way to determine the potential success of a platform or a technology is the number of people in the ecosystem around it that find ways to make money on it. If this is any indication, then SOAP adoption should be rapid and significant.

What’s your take on SOAP mythology?

Do you subscribe to any of these “myths?” Or do you agree with Landgrave? Post a comment below and let us know your thoughts.