Soap Discussion

A good thing about the SimpleObjectAccessProtocol is that it is OS-independent, machine-independent, programming-language independent, protocol-independent. In other words it can transport CORBA IIOP packets if you wanted to.

Now look at the protocol at http://www.mobilelink.org and imagine how it could be fixed via SOAP. (There are some severe problems with MAL, like the fact that they send device-specific data in almost every case, but then they're trying to come up with a non-device-specific internationalization scheme.)

SOAP was primarly created by DonBox and DaveWiner with input from people at MicroSoft and Lotus. The second version had significant changes from IBM and many others. Even Sun is on the bandwagon now.

See MSDN Magazine article "A Young Person's Guide to The Simple Object Access Protocol: SOAP Increases Interoperability Across Platforms and Languages"

http://msdn.microsoft.com/msdnmag/issues/0300/soap/default.aspx

SOAP sessions held by DonBox and DevelopMentor guys were the hottest sessions at WinDev this year, overflowing and leaving the DCOM sessions virtually empty. -- sg

So, this clarifies (a bit) the details of this article from The Register: http://www.theregister.co.uk/content/archive/10986.html. Doesn't sound very encouraging for an open cross-platform spec. There's a good article covering interoperability issues and conformance between the MS SoapToolkit and IBM/Apache SOAP at http://windows.oreilly.com/news/soapreview_0600.html -- StevenNewton

Well, DonBox is none too thrilled about Microsoft's moves with SOAP (especially since he essentially wrote it). -- sg

I want to implement a web application which uses SOAP as a server-to-server protocol. I use servlets to do my web apps. Can anyone suggest a good Java library/framework that supports getting and posting on a server using https? Thanks in advance. --

This article suggests that SOAP is designed to bypass firewall protections:

http://www.counterpane.com/crypto-gram-0006.html#SOAP

SOAP itself is not tied to the HyperTextTransferProtocol anymore. However, the original transport protocol was tied to HTTP to overcome the fact that IT people seem wary of opening any incoming port except 80. Now they have to worry not only about the fact that there's traffic over HTTP, but what type of traffic it is (i.e. further interrogating the contents of the packet). I don't really grasp how IT people envision having to filter the incoming packets at the content level is easier or more efficient to do. -- DrewMarsh

Unlike other Internet protocols, SOAP is specifically designed to support filtering: By comparison, what part of telnet would enable a firewall to keep people from logging in as root, or using setuid programs? And what part of FTP helps a firewall prevent people from deleting or uploading over server files?

Because SOAP standardizes the request syntax and makes it more visible, SOAP requests are relatively easier to filter. [Furthermore, if the SOAP envelope is transmitted via HTTP, which is the protocol firewalls today understand, then filtering of SOAP is that much easier.] I'd expect that should you decide to enable SOAP request processing in your web server, any minimally competent web server would also let you set up at least minimal filtering and security at the same time. Even without SOAP, you're already relying on your web server to provide some level of security. -- JeffGrigg

While request syntax may be standardized, request semantics are not, and that's a security issue. For contrast, standard request semantics are well represented by the HTTP methods "GET", "PUT", "POST", etc. While a firewall may be able to locate the "method" element in a SOAP-RPC message "easily", it has no way to judge the safety of that method or the cacheability of the response.

A question, to which I should probably know the answer: if you use SOAP, do you escape the godawful long timeouts which RPC and DCOM suffer from, if the host/app you're trying to talk to goes away? -- AnonymousCoward

Yes.

errr, no. Unless you consider 180 seconds to not be godawful long. I see that regularly, using SoapLite? to hit a service hosted under IIS. Said IIS instance hangs due to buggy code, so that it gets the request but won't respond (classic "IIS is hung" symptoms) and SoapLite? won't come back for 180 seconds. Things come back much more quickly if it literally can't connect to the server. I'm sure there's a way to set the timeout in SoapLite?, but I've not found it. I don't think the SimpleObjectAccessProtocol specifies anything in the way of timeouts.

Can people list examples of software that now uses SOAP?

DotNet most prominent, I think

Several MicroSoft technologies support SOAP (DotNet, SqlServer, WindowsServer2003, InfoPath) and others rely on SOAP, including Windows Update, Sharepoint, and several chunks of LongHorn? (Windows V.next).

http://www.xmethods.org syndicates public services, like stock quotes and fortunes

ManilaByDaveWiner uses SOAP to access the content management system functions

http://jaugment.sourceforge.net/, infrastructure for wearables, uses either Jini, SOAP, or CORBA for RPC

GeeForge uses SOAP for its Java client - http://infoether.com/~tom/gforge/soapclient/

Is SOAP the same as SOAP-RPC, or is SOAP-RPC a subset of SOAP?

SOAP started out as a method for using XML for the on-the-wire representation of an RPC call, but since its adoption by the W3C XML Protocols working group, it is being influenced by the REST camp to be primarily a message exchange protocol which could be used to support RPC semantics.

Apache Axis (next generation SOAP) is an implementation of JAX-RPC, and hence as of this writing (2002-04-24), its interface is all about RPC, not messaging. (The JAX-M interface is still unimplemented and considered low priority.) Ironically, you can bend Axis' RPC interface to send a message, but it's not absolutely clear from the documentation (of which there is precious little right now) how to do that. That should change as the Axis product matures, though.

The REST (RestArchitecturalStyle) guys claim that SoapRpcBreaksRest because any SOAP RPC call over HTTP, even an idempotent one, must use a POST and not a GET, which goes against the design of HTTP 1.1 and the REST architecture, and therefore the web.

See http://internet.conveyor.com/RESTwiki/moin.cgi/HowSoapComparesToRest -- AndrewJoyner

Also see RestInSoap

So how should the wiki.wdsl should look like? It cannot be that PhpWiki is the only wiki engine so far, which supports SOAP.

I roughly thought of the following methods: (everything UTF-8 encoded)

  get the page content (pagename) => wiki-formatted string, base64 encoded, 
  save a new page (pagename, wiki-formatted string) => int success code, 
  get array of all pagenames () => array of strings,
  get all backlinks for a page () => array of strings

http://phpwiki.sourceforge.net/phpwiki/PhpWiki.wdsl

Well, someone should come up with a RFC for such a wdsl sooner or later, similar to XmlRpc. Should I be the first? As the tiki guys came up with a totally ridicoulous Wiki RFC: http://www.ietf.org/mail-archive/ietf/Current/msg24290.html

--ReiniUrban, PhpWiki developer

CategoryXml