Viewpoints-The latest SOAP Opera

Viewpoints

Last month, Microsoft submitted a new specification to the Internet Engineering Task Force (IETF). This new XML-based specification for distributed applications has been christened SOAP. Simple Object Access Protocol (SOAP), is being touted as a way to handle remote procedure calls (RPC) across the Internet. SOAP is useful for inter-object communication between disparate components. I would go ahead and argue that this is a master-stroke from Microsoft

It is nice for a few reasons:

1. You can use it to bridge between any two component models. It is a relatively easy process to write RMI stub/skeletons, COM proxy/stubs, or CORBA stub/skeletons to allow interoperability between say, your desktop COM application and your EJB enterprise backend system.

2. It makes WAN deployment really nice. You don’t have to worry about firewall configuration issues.

3. It makes it easy to install security filters (as a simple web server extension).

4. It makes it easy to transform a synchronous system into an asynchronous system. Calls can be sent using MQSeries or a JMS provider.

5. It makes for a really open standard. For example, if a competing standard emerges (from say OMG), there is a good chance (barring causality problems or other protocol intricacies) that it could interoperate with SOAP (or any other XML RPC) via a simple XSLT filter.

The list goes on. This is just a sample. SOAP has almost nothing to do with whether you are creating an EJB or an MTS based application (other than Microsoft is the underdog in the space and they want an easy way to interoperate).

SOAP will be bundled into Windows 2000 and will be used transparently when you make calls over the internet.

At least the way I understand it they intend this to be a communication mechanism to allow rich clients (i.e. VB clients) to communicate with server components over the Internet, and to allow easy integration of server-side applications over the Internet.

Using DCOM for this is virtually impossible, but the same is more or less the case with RMI/IIOP because of firewall problems, although in a controlled extranet configuration one could configure the firewall to let through IIOP packets. SOAP is a way to package a DCOM call as an XML message and thus overcoming the firewall problem, while COM components running on an intranet would still use DCOM to communicate.

A similar approach would IMHO be very useful also for the EJB/CORBA world.

Some vendors have this capability in their CORBA orbs. Visigenic’s orb, e.g. can (pretty much transparently) wrap IIOP in HTTP or HTTPS to tunnel through client firewalls. Over the Internet, HTTP tunneled IIOP is 25% slower than native IIOP.

My concern about this approach, whether it’s SOAP or HTTP tunneling of IIOP is that it’s a cobbled together solution for what should be a non-problem. We need to do a lot of evangelism in the corporate security community to convincingly demonstrate that properly configured, IIOP channels in their firewalls (and around their proxy servers!) are no more (and probably less), dangerous than the ubiquitous HTTP on port 80. The only reason we’re even tempted to migrate to doing RMI/RPC via HTTP is because it’s the lowest common denominator for security.

However, As far as SOAP as a way to tie together CORBA, RMI and DCOM is concerned: I doubt that’s Microsoft’s goal. Even if it is, XML is a small part of the solution. Any of us could write code to re-marshal and un-marshal IIOP or DCOM into XML very easily. But these three protocols are not semantically equivalent, and you can bridge them only with significant effort, or by applying (again) a least common denominator approach that throws away as much as it salvages.

IMHO, a better approach is to figure out how to solve the firewall “problem”. The lemming strategy is not always a good one. Let’s be innovative. However, even if we did come out with a new protocol, and assuming for a moment that every company in the software industry supported it (!!!!), how do we convince all the web masters around the world, who ever owned a Web Server to support it? Even if 20% did not support our new innovative protocol, our components will not be able to communicate with that 20% of the machines through the internet. So ultimately, it comes down to, Who’s to bell the cat??!! Which goes back to the point I made early on in the article about this being a master-stroke by Microsoft. Is this the only way out?