Don Box: "That simply isn't what SOAP was meant to solve."

Date view	Thread view	Subject view	Author view

From: Adam Rifkin -4K (adam@XeNT.ics.uci.edu)
Date: Sat Aug 05 2000 - 14:44:10 PDT

Next message: Adam Rifkin -4K: "[Slate] Plato, Aristotle, and the 2000 Election."
Previous message: Håkon Wium Lie: "Re: Suck To Moziila--Fuck Off and Die"
Next in thread: Kragen Sitaker: "Re: Don Box: "That simply isn't what SOAP was meant to solve.""
Reply: Kragen Sitaker: "Re: Don Box: "That simply isn't what SOAP was meant to solve.""

[Background: Rohit and I downloaded Opera 4.2 on Win2K last night to
test out a lot of our JavaScript demos and unfortunately found that it
hung Opera in several cases. This is the problem with developing
JavaScript on IE 5.x -- you gotta forget any hope of one day being cross
platform unless you're willing to throw much more time/resources at the
problem. Too bad, SOAP-enabled Opera ("SOAP Opera! Ha!" :) would have
been fun to show off. BTW, Opera fun fact of the day: with Java, Opera
is a 9Meg download. Without the JVM Opera is a 1.8 Meg download. Ouch!]

Okay, on to the main post. Recall that Don Box and Rohit have an (ahem)
interesting history together:

http://www.xent.com/FoRK-archive/summer96/0398.html

Ok, enough Don Box background, let's go back to SOAPspeak...

Does anyone on FoRK know of *any* open implementation of a
(de)serializer of SOAP written in JavaScript? I find it hard to believe
that in the middle of August 2000 that neither Google nor Alltheweb can
find me any open examples of people doing this. Then again, I can only
find a single open JavaScript XML parser on the web right now...

http://www.jeremie.com/Dev/XML/

...and Jeremie pretty much hasn't updated that page since the beginning
of 1998. [Enter Tom rant about how JScript is owned by the script
kiddies and far be it from me to try to use it for anything but script
kiddie color-and-graphics hacks.]

Anyway in the midst of searching last night, Rohit and I encountered
this interesting thread on develop.com from February 2000 on using a
web browser as a SOAP client:

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=15013

> Date: Tue, 8 Feb 2000 22:29:11 -0800
> Reply-To: SOAP <SOAP@DISCUSS.DEVELOP.COM>
> From: Shripathi Kamath <skamath@HOME.COM>
> Subject: SOAPMethodName HTTP header being made mandatory
>
> In my exercise of running through scenarios as to ascertain
> applicability of SOAP to our product, one of the environments we wanted
> to use was any vanilla browser (IE5 and Navigator would be this set for
> us) as a SOAP client. The use of Java/plug-in is not an for our product --
> browsers that support HTML and Javascript only. With HTML, XML, XSLT,
> and a little help from the server side, I ran many useful scenarios
> using SOAP.
>
> Now that SOAPMethodName HTTP header is mandatory, how does one set this
> header in these browsers?
>
> Please do not give me details of how this is being planned/promised in
> an upcoming browser version, or that I really need to use Java/plug-in.
> was hoping to use SOAP because it was based on *existing technologies*, I
> just hope that along these lines someone does not get the bright idea of
> making M-POST a MUST.
>
> While I understand that the special header makes it possible to optimize
> firewall-based redirection, it might be nice to NOT have it as a MUST,
> but have it as a STRONGLY RECOMMENDED!

Well, Don Box pretty much scoffed at that request:

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=22344

> Date: Tue, 15 Feb 2000 03:53:08 -0800
> From: "Box, Don" <dbox@DEVELOP.COM>
> Subject: Re: SOAPMethodName HTTP header being made mandatory
>
> Since a SOAP request is an HTTP POST that carries non-form data, I know
> of no browser that allows you to simply type in a URL and invoke a
> method. Rather, one must PROGRAMMATICALLY issue the post. If you are
> using IE or Netscape, the java.net.URLConnection.setRequestProperty does
> the trick quite nicely. If you are using IE5, the
> IXMLHTTPRequest.setRequestHeader works as well.
>
> ...
>
> SOAPMethodName turns out to be important for certain server scenarios
> as well. Since SOAP doesn't support users typing in a URL, requiring
> the SOAPMethodName header is innocuous and makes many interesting
> server scenarios possible.

But Shripathi Kamath had the right idea, and reiterated:

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=28280

> I fail to see where I implied that one can supply the request method
> with a URL in a browser. The point is that I *can* do a POST using HTML
> and Javascript only, when I do not have to set an HTTP header. I never
> inferred from the SOAP spec that it can ONLY be used with non-form data.
> I have a HTTP server that is capable of parsing the form-encoded data,
> extracting the SOAP request, and then processing it. Now if I did not
> have the mandate of having to set the header, I believe that on the
> browser end all I need is HTML (and Javascript), but not Java. In this
> case I see SOAP being encoded using x-www-url-encoded, and then
> unencoded on the server. I am pretty sure that this does not violate
> any SOAP rules.
>
> Neither of your solutions are on NN or IE5 are acceptable for
> requirements I stated in the original post. Use of Java is just not
> palatable on the client for us.
>
> However, based on your response, the only way I can see handling it is
> to collect the form-encoded request, extract the SOAP part, and then
> send it on for processing dummying the now mandatory header. Yuck! but
> I think I can make it work. I had a cleaner server design before.
>
> I readily (did already) concede that *nicer* or *important* reasons may
> exist for the header name to be present. I still do not see why it has
> to be *mandatory*. It is creeping inclusions (or restrictions if you
> wish) such as this that start morphing what is a nothing-new-simply-
> reuse-of-technology into a revolutionary new 'paradigm'. I still have
> not seen as to what is being prohibited by making the header a SHOULD as
> it originally was, instead of the upcoming MUST.

Don Box's response just floored me:

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=28611

> Could you send me a minimal code fragment showing a POST of XML to a URL
> from javascript? I was unaware that you could do that without resorting
> to Java in a browser-neutral manner.

!!! Is he kidding? Does he think JavaScript is just a script kiddie
language? Does he think SOAP is just a way to cram COM/DCOM through
firewalls? [Actually, I believe his answer to that one would be an
unrepentant yes, with David Chappell backing him up 100%... so much for
not going POSTal...]

Don continues...

> The spec clearly states that SOAP requests MUST use the mime type
> "text/xml" so already you are deviating from 100% pure soap. That
> stated, feel free to use the section 8 rules and SOAP:Envelope
> constructs to your heart's content. However, don't expect to directly
> interoperate with anyone else at the method invocation level without
> some gateway stripping out the Envelope from your form data.
>
> ...
>
> I've got news for you. The mandatory header is the least of your
> problems. No SOAP server on earth is expecting form-encoded requests.
> That stated, keep your "cleaner" server design and use parts of SOAP
> where you feel they help and ignore interoperation.
>
> ...
>
> Again, you are focusing on the wrong part of SOAP. Your problem is more
> related to using form-encoded requests. That simply isn't what SOAP was
> meant to solve.

Does this mean we would be completely out of line developing a SOAP
server that *does* expect form-encoded requests? I would think there
would be a lot of utility for developers if they had access to such a
programming platform. (Insert drooling-over-the-concept-of-a-SOAP-router
rhetoric here...)

Anyway, Dick Brooks pretty much came to the rescue...

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=30847

Don Box, naturally, was nonplussed (does that mean he was minussed?)

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=32426

> I'd love to know how you did it. Will the technique work with
> Netscape? Will the technique for IE4?
>
> ...
>
> Could you send me the URL for your spec? Frankly, everyone with an XML
> over HTTP technology looks at SOAP as a "rogue effort" when compared to
> their own solution. That's the nature of the industry.
>
> DB
> http://www.develop.com/dbox

Enter Mark Seelye from Tallan (pre-merger with CMGi Solutions):

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=32987

> Don, wow, do you get stuff like that all the time? You seem a bit...
> aggravated? :P

Thanks for lightening the mood. Dick Brooks comes back with his solution:

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=34041

> The multipart/form-data upload has worked as far back as Netscape
> 3.0 and IE 4.0.
>
> Here is how I did it:
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <TITLE> EDIINT AS2 TESTING</TITLE>
> <META NAME="GENERATOR" CONTENT="Mozilla/3.0b6Gold (Win16; I)
> [Netscape]">
> <META NAME="AUTHOR" CONTENT="Group 8760">
> </HEAD>
>
> <BODY LINK="#058cc8" VLINK="#058cc8" ALINK="#058cc8" bgcolor="white">
> <font size=2>
> <A NAME="top"></A>
>
> <CENTER>
> <TABLE border=1 WIDTH="98%" cellpadding=5>
>
> <TR align=center><TD><h1>EDIINT AS2 UPLOAD FORM</h1></TD></TR>
> <TR align=center>
> <TD colspan=3>
> <br>
>
> <form ENCTYPE="multipart/form-data"
> ACTION="http://localhost:9090/servlet/as2" METHOD=POST>
> <strong>Please send your EDIINT AS2 testdata</strong>
> <table cellspacing=2>
> <tr align=left>
> <td><b>From:</b></td>
> <td><input type="text" name="from" value="190723155"
> size=25></td>
> </tr>
> <tr align=left>
> <td><b>To:</b></td>
> <td><input type="text" name="to" value="006900518" size=25></td>
> </tr>
> <tr align=left>
> <td><b>Agent:</b></td>
> <td><input type="text" name="Agent" value="" size=25></td>
> </tr>
> <tr align=left>
> <td><b>Application:</b></td>
> <td><input type="text" name="Application"
> value="AccountsPayable.PaymentProcessor" size=25></td>
> </tr>
> <tr align=left>
> <td><b>Creation Date and Time:</b></td>
> <td><input type="text" name="DateTime" value=" Wed, 02 Feb 2000
> 10:09:27 -0600" size=25></td>
> </tr>
> <tr align=left>
> <td><b>RefNum:</b></td>
> <td><input type="text" name="RefNum" value="12345" size=25></td>
> </tr>
> <tr align=left>
> <td><b>User Parameter:</b></td>
> <td><input type="text" name="UserParam" value="second exchange"
> size=25></td>
> </tr>
> <tr align=left>
> <td><b>Version:</b></td>
> <td><input type="text" name="GISB-Version" value="1.0"
> size=25></td>
> </tr>
> <tr align=left>
> <td><b>Transaction Set:</b></td>
> <td><input type="text" name="Transaction-set" value="Invoice"
> size=25></td>
> </tr>
> <tr align=left>
> <td><b>Send Receipt To:</b></td>
> <td><input type="text" name="Receipt-disposition-to"
> value="190723155"
> size=25></td>
> </tr>
> <tr align=left>
> <td><b>Receipt Delivery Method:</b></td>
> <td><input type="text" name="Receipt-delivery-option" value=""
> size=25></td>
> </tr>
> <tr align=left>
> <td><b>Receipt Type:</b></td>
> <td><input type="text" name="Receipt-report-type"
> value="ebxml:APReceipt"
> size=25></td>
> </tr>
> <tr align=left>
> <td><b>Receipt Security Choices:</b></td>
> <td><input type="text" name="Receipt-security-selection"
> value="application/pgp-signature;micalg=md5" size=25></td>
> </tr>
> <tr align=left>
> <td><b>Format:</b></td>
> <td><input type="text" name="input-format" value="ebxml"
> size=8></td>
> </tr>
> <tr align=left>
> <td><b>Payload:</b></td>
> <td><input type="FILE" name="input-data" size=36></td>
> </tr>
> </table>
> <br>
> <br>
> <table border=0 cellpadding=5>
> <tr>
>
> <td width=50% align=center valign="top">
> <input type="submit" value="Submit"></td>
>
> </table>
> </form>
> </TD>
> </TR>
>
> </table>
> <br>
>
> <BR><BR><BR><BR><hr>
> </center>
> </body>
> </html>

And then Dick makes another plea for interoperability:

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=35111

> I understand the passion one feels for their own design. But there comes
> a time when we must work together in order to make significant strides.
> The Internet has accelerated the rate at which people can collaborate to
> create a "new software design" and it seems there are new "islands" of
> collaboration forming all over the place. At least with regard to XML
> several of the major camps are aware of each other and we have the
> opportunity to unite these camps at a formative stage. The SOAP camp has
> some excellent ideas, as does BizTalk, OASIS, OAG, W3C, IETF, DISA,
> ebXML, BQM, OMG, et al. It sure would be nice if we could coordinate
> these ideas into a global standard.
>
> The EDIINT AS2 spec, that is under consideration by ebXML, is located
> at:
> http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-06.txt
>
> I'll be happy to answer any questions you might have.
>
> Also, there will be another version of this spec posted shortly that
> includes some additional headers and expanded examples.

As an aside, CommerceOne's David Burdett has assembled a really nice
working draft for ebXML Transport, Routing, and Packaging's Overview and
Requirements:

http://www.ebxml.org/specdrafts/TRPv0-96.pdf

Anyway, back to the Don Box story. Here's where Don's misunderstanding
is revealed:

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=35231

> Wow. I didn't know about the <input type='FILE' /> construct in HTML.
> However, again, the request is not text/xml, but rather a form. I still
> don't see how making SOAPMethodName optional would help in this case,
> since a SOAP server must validate the content type as text/xml.

Dick of course sets him straight:

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=35481

> No, it's not a form, it's just a MIME type that is capable of
> transporting several type of payloads, XML being one type. The best
> part of all, it's available today in all currently shipping browsers and
> companies have written agents to perform the same for
> Business-to-Business commerce!

And of course, this thread has the perfect ending: just how much pain is
still involved in using SOAP in native Web Application Integration.
Someone is going to make a ton of money coming out with a painkiller.
(Bowstreet? webMethods? Microsoft .NET? IBM? A dark horse maybe?)

Last post in the thread:

http://discuss.develop.com/archives/wa.exe?A2=ind0002&L=soap&F=&S=&P=36110

> Date: Fri, 18 Feb 2000 12:00:04 +0100
> Reply-To: SOAP <SOAP@DISCUSS.DEVELOP.COM>
> From: Kai Henningsen <kai.henningsen@CATS.MS>
> Subject: Re: SOAPMethodName HTTP header being made mandatory
>
> On 17 Feb 00, at 10:59, Dick Brooks wrote:
>
> > POST /servlet/as2 HTTP/1.1
> > Accept: application/vnd.ms-powerpoint, application/vnd.ms-excel,
> > application/msword, image/gif, image/x-xbitmap, image/jpeg,
> image/pjpeg,
> > application/pdf, */*
> > Accept-Language: en-us
> > Content-Type: multipart/form-data;
> > boundary=---------------------------7d03201c3e0
> > Accept-Encoding: gzip, deflate
> > User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
> > Host: localhost:2600
> > Content-Length: 9293
> > Connection: Keep-Alive
> >
> > -----------------------------7d03201c3e0
> > Content-Disposition: form-data; name="from"
> >
> > 190723155
> > -----------------------------7d03201c3e0
> > Content-Disposition: form-data; name="to"
> >
> > 006900518
> > -----------------------------7d03201c3e0
> [...snip...]
> > -----------------------------7d03201c3e0
> > Content-Disposition: form-data; name="input-format"
> >
> > ebxml
> > -----------------------------7d03201c3e0
> > Content-Disposition: form-data; name="input-data";
> > filename="C:\ebxml\CommissionEvents.xml"
> > Content-Type: text/xml
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > 
> > <HITISMessage xmlns="" Version="1.0">
> > <Header OriginalBodyRequested="false"
> ImmediateResponseRequired="true">
> > <FromURI>http://www.pms.com/HITISInterface>
> > <ToURI>http://www.crs.com/HITISInterface>
> [...snip...]
>
> My $DEITY. And all this butt-ugly stuff just for a *constant* (i.e.,
> file) XML payload?!
>
> I'm planning on using SOAP in our application. If it looked like
> that, I'd never even consider it for a second.
>
> This is just so absolutely awful, words fail me.
>
> Anyway, constant (or file) payloads are just completely uninteresting
> for what I'll be doing. Well, for the important part, anyway; I could
> easily do the few files via normal http, just giving out an URL. Or
> use Transfer-Encoding: chunked, which I'll need anyway for some large
> lists.

----
Adam@4K-Associates.Com
.sig double play!
IE5 Generic SOAP Client: Either choose one of the pre-configured test
endpoints or manually enter the SOAP request data below.
Note: Make sure you have the Access data sources across domains enabled
in IE's security settings. This setting is disabled by default. If
disabled, you'll get an access denied error when pressing the Call
Method button.
  -- http://www.skonnard.com/soap/
If an application is to allow method calls from clients across the
Internet, it must allow these calls through the company firewall. While
most firewalls are happy with HTTP, the native protocol for the Web,
they are not so happy to let DCOM calls through. As Don [Box] put it,
"We must disguise our method calls as HTTP calls."
  -- http://msdn.microsoft.com/componentresources/html/articles/ta/ta_009.asp

Next message: Adam Rifkin -4K: "[Slate] Plato, Aristotle, and the 2000 Election."
Previous message: Håkon Wium Lie: "Re: Suck To Moziila--Fuck Off and Die"
Next in thread: Kragen Sitaker: "Re: Don Box: "That simply isn't what SOAP was meant to solve.""
Reply: Kragen Sitaker: "Re: Don Box: "That simply isn't what SOAP was meant to solve.""

Date view	Thread view	Subject view	Author view

This archive was generated by hypermail 2b29 : Sat Aug 05 2000 - 14:44:16 PDT