Many corporations are already experimenting with next-generation distributed applications, which were developed using Simple Object Access Protocol (SOAP). In this article, we’ll take a look at the upcoming toolsets offered by two major vendors who’ve made significant commitments to advancing the development tools and support for open standards like XML (Extensible Markup Language) and SOAP—IBM and Microsoft.

SOAP as an extension of existing object models
Given the investment that corporations and consulting firms make to buy development tools, train their staffs, and build repositories of code, it makes sense for development-tool vendors to position new toolsets as extensions of the prior generation. Most of today’s development tools target a specific platform and object model and then provide tools and compilers for that platform. For example, Microsoft’s Visual Studio development environment generates code that runs on Windows32 platforms and communicates using the Microsoft Component Object Model (COM). IBM’s WebSphere product generates code that runs on UNIX or Windows32 platforms, but uses Common Object Request Broker Architecture (CORBA) as its object communication mechanism.

To create an application development platform that can communicate cross-platform with any other system that supports the SOAP and XML standards, a vendor must modify its tools to replace the reliance on COM or CORBA with support for XML and SOAP.

Catch up on Tim Landgrave’s SOAP opera

This is the final installment in a four-part series on SOAP. If you missed an earlier installment, here’s your chance to get up to date.

Evolution: The IBM approach
With its release of the 4.0 version of the WebSphere Application Server, IBM will expand the tool’s support for open standards to include Universal Description, Discovery, and Integration (UDDI), Java 2 Enterprise Edition (J2EE), Web Services Description Language (WSDL), and, of course, SOAP. IBM touts their platform as a supporter of cross-platform, heterogeneous process flow and provides a tool called the WebSphere Business Integrator. The WebSphere Business Integrator uses IBM’s message queuing product, MQSeries, to design asynchronous transaction flows that manage the delivery of SOAP messages between Web services applications.

The IBM approach adds the ability to generate code that supports the new standards without forcing customers to make radical changes to their existing code or infrastructure. Of course, this approach presupposes that the platforms they deploy on already have some underlying infrastructure from IBM (e.g., to use the Business Integrator component, both systems have to be running MQSeries software). The IBM approach also assumes that anyone new to their platform will be satisfied running Java as their development language, since the WebSphere toolkit is very tightly tied to Java. Given the fact that IBM’s Global Services organization is the largest Java development shop in the world, and they work extensively in the Fortune 500, it’s a sure bet that the WebSphere environment will “open up” a significant number of systems using SOAP interfaces.

Revolution: The Microsoft approach
I’ve always found it humorous to talk to the ABM (Anything But Microsoft) crowd whenever Microsoft introduces a new product. According to them, Microsoft never does anything original, Jobs and Apple created the graphical user interface (without help from Xerox PARC), and Linus Torvalds wrote Linux on the back of a napkin in a flash of brilliance (and didn’t use or benefit from any prior implementation of UNIX). I’m looking forward to hearing their take on the .NET platform.

The first thing they’ll say is that the Microsoft .NET Common Language Runtime (CLR) is a knockoff of Java’s Virtual Machine technology. Of course, they’ll choose to ignore two key differences. First, the CLR allows any language vendor (more than 25 have already committed) to port their language to the CLR, allowing their customers to develop highly interoperable, SOAP-based systems without having to learn a proprietary language (like Java). Next, they’ll say that the CLR is proprietary as well, so Microsoft isn’t doing anything different than Sun. Of course, this is wrong, but the ABMers won’t accept two important facts. First, Microsoft submitted key technologies like the CLR to the European Computer Manufacturers Association (ECMA) for acceptance as an open standard. Second, when Microsoft ships their Visual Studio.NET development environment and the runtimes for Windows NT 4.0 and Windows 2000 later this year, there will already be versions of the CLR released by third parties that allow applications developed in any .NET language to be deployed on Linux platforms.

Microsoft’s .NET introduces new computing concepts like “stack machines,” radically improves existing p-code technologies employed by Java and QuickBasic with Intermediate Language (IL) and Just in Time (JIT) compilers, and enforces an object oriented methodology on applications developed on the .NET platform. Microsoft is taking a huge risk, in that they have to move a large body of programmers from their proprietary (albeit hugely successful) COM architecture and the mostly non-object oriented development tools (Visual Basic being the largest) to an open XML/SOAP architecture using next-generation development languages like C# and VB.NET with built-in, “from the ground up” object oriented support. Although existing systems will continue to run without using the .NET Framework, most new systems developed to take advantage of SOAP will have to be rewritten to support .NET. To assist in the conversion process, Microsoft has already released a SOAP Toolkit for the existing version of Visual Studio. This allows developers with COM objects to generate SOAP wrappers for these objects and create SOAP-compliant systems without having to port their code to the .NET Framework.

Pick your poison
Other companies, like Sun and Oracle, will also be introducing both extensions to their development environments and new versions that allow their developers to move applications forward using SOAP as the underlying object protocol. The good news here is that if you’ve learned to use tools from any major vendor, once they update their tools with XML/SOAP support, you’ll no longer be trapped by their choice of the underlying operating system and object protocol—you’ll be able to interoperate with any other system that has SOAP support.

ABMers, speak up!

Would you like to challenge Tim Landgrave’s perspective on Microsoft’s new products? Or maybe you’d like to ask a question or offer a concurrent opinion. Whatever your viewpoint, we’ll listen. Send us an e-mail or post a comment below.