Fog Creek Software
Discussion Board




Please re-read my article

Warning....overheated prose below. I'm a little bit tired of people NOT UNDERSTANDING (perhaps not entirely READING) the article and then commenting on it as if they did.

Joel says: "Many things in SOAP are there to make it easier. WSDL is there so that I can type "google" followed by a dot and immediately get a little intellisense popup telling me what methods I can call. Then I can choose doGoogleSearch from the popup list and get intellisense again prompting me for all the arguments, and I can get little wavy red underlines in my editor if I pass a string where a long was expected."

Guess what Joel! That isn't SOAP. SOAP is irrelevant. That's WSDL. My article was *PRO-WSDL*.

In the article I pointed you to an HTTP-based WSDL that should have *exactly the same behaviour* in Visual Studio.NET (I've only tried it with the command line tools myself). I had a whole section of the article on ease of use but it seems to have flown over people's heads.

This is what frightens me. People around the world are "choosing" SOAP without the slightest understanding about what it is or how it relates to the tools they use.

Here's another point about Joel's article. He says:

"The real problem with SOAP is that it's a completely inadequate remoting system. .... It doesn't support references (ditto). It has about 10 years to go before it gets to where CORBA and DCOM were 10 years ago."

Guess what Joel. That's the problem I'm *trying* *to* *freaking* *solve*. Re-read the article. It says:

"The point that has not yet filtered through to the mainstream of web services implementors is that linking is just as important for machine-to-machine applications as it is for human-facing applications. If it is impossible to link to SOAP-exposed resources, then they are less powerful and useful than HTTP-exposed ones. Until SOAP has an addressing mechanism as rich as HTTP URIs, SOAP is less, rather than more powerful than HTTP."

You use the term references. I use the term hyperlinks. We're talking about the same thing. We should be on the same side. SOAP doesn't support references because the reference syntax used on the Web is URLs and SOAP doesn't have properly support for exposing resources through URLs. I'm trying to fix the problem.

Paul Prescod
Thursday, April 25, 2002

What is needed is a light-weight mechanism to replace screen-scraping. I thought SOAP or even XML-RPC was that but they both seem over-kill. What confuses me a bit is formatting the request as a URI (it could be a POST as well, Paul, right?) and then a response in XML. Since many/most web development environments can't parse XML out-of-the-box, why not format the response in something like URL-encoded, key=value pairs? For many function calls, there's not a whole lot of data coming back.

pb
Thursday, April 25, 2002

Paul don't worry too much about Joel, he's just a cocky person who don't really understand software engineering.

Akira
Friday, April 26, 2002

I read your article.  It was a very easy read.  I even caught your pro WSDL sentiments (*gasp*).

The one thing that I have noticed is that everyone is hung up on SOAP 1.1.  The inventors of SOAP 1.1 have said that they screwed up when they made wrote the data model section.  That's a given.  They had to write their own data model because XML Schema didn't exist and DTD wasn't expressive enough.

So SOAP 1.2 breaks that model.  The 1.2 spec only talks about the envelope, headers, and body.  The SOAP Data Model (section 5 and 7) is just an addendum.  What is being pushed in the community (from what I've seen) is the XSD Data Model.  This means that you describe the body of your message using XSD.  No more weird ref and href stuff.  No more SOAP-ENC:array stuff.  Just good ole fashion XSD which you seem to like.

I do agree in general that some things are better as XML/HTTP/URI.  Most APIs that query can be rewritten as XML/HTTP/URI.  I'm finishing up an R&D project that proves that with our (my companies) current XML interface (which is SOAP using the XSD Data Model).  And what I've found is that some of our messages don't make sense as XML/HTTP/URI.  For example, we have a SOAP message (note not an RPC call) that allows a user to get certain preferences from our database.  So an XML request might look like this (sans SOAP envelope) -

<GetPreferences>
  <Preference Name="one"/>
  <Preference Name="two"/>
  <Preference Name="three"/>
</GetPreferences>

Now I came up with the following -
http://someserver/preferences?names=one,two,three

Or I could use a form-encoded POST.  Both work pretty well, but it is not as simple or as expressive as the XML above.  Also caching actually became a problem.  The following produce the same result -

http://someserver/preferences?names=one,two,three
http://someserver/preferences?names=three,two,one

But as far as most caching servers go, they are different.  Not a big deal, I'll just put a no-cache whereever I handle that URI.  But now I gotta remember to do that and analyze everywhere else that might have caching problems.  These are problems that I ran into during my research.  So its not quite "Just come up with the URI and move on".

One last thing...what is the difference in google sending the key plain text in a well defined element and basic authentication.  Last time I checked, basic auth uses a well defined HTTP header that simply base64 encodes the credentials.  Not exactly secure.  So how is it different?

Also why do you say that SOAP's RPC-over-HTTP hasn't solved the security problem.  What is to stop that RPC call from using Basic Auth?  I've done it many times.  It sits in the same header that it would for a good ol' fashion HTTP call.

But with SOAP (as well as SOAP-RPC), I get the extensibility of SOAP Headers.  And the existence of these headers can be verified by a schema validating parser.  Sure HTTP headers are extensible, but I have to validate them myself and I'm lazy.

Also by putting information in these headers (such as security credentials from WS-Security), I can easily change the transport from HTTP to SMTP.  Since I'm not dependent on any of the HTTP underpinnings (Basic Auth), this is very simple to do (in fact my company does it everyday).

So in short, I think that SOAP 1.2 is fixing most of the problems that you have.  Most of the forward thinkers (the people I know) are abandoning the SOAP Data Model (except for backwards compatibility) and moving to the XSD Data Model.

Keep up the good writing...

Justin Rudd

Justin Rudd
Friday, April 26, 2002

Justin: You are a rare soul. Someone who both chooses to read the whole article and actually has a sense of what SOAP really is. Congratulations!!!

In response to your questions:

"The one thing that I have noticed is that everyone is hung up on SOAP 1.1. The inventors of SOAP 1.1 have said that they screwed up when they made wrote the data model section. That's a given. They had to write their own data model because XML Schema didn't exist and DTD wasn't expressive enough.

So SOAP 1.2 breaks that model. The 1.2 spec only talks about the envelope, headers, and body. The SOAP Data Model (section 5 and 7) is just an addendum."

Okay, but the addendum is what everyone who says "SOAP is easy and interoperable" is talking about -- SOAP RPC. The "just envelope, headers and body" view is way too generic to "do much" and thus is not much more interoperable than pure XML. So you can either have ease of use and interoperability from the RPC stuff (what I call implemented-SOAP) or you can have this future-looking stuff (that I call idealized-SOAP). You can't have both. Really, I think SOAP is two (or more) specifications in one.

You said: "What is being pushed in the community (from what I've seen) is the XSD Data Model. This means that you describe the body of your message using XSD. No more weird ref and href stuff. No more SOAP-ENC:array stuff. Just good ole fashion XSD which you seem to like."

XSD is okay. My point is to get people thinking about what SOAP is actually doing for them. If XSD is doing all of the heavy lifting of type mapping then why are they using XSD?

"I do agree in general that some things are better as XML/HTTP/URI. Most APIs that query can be rewritten as XML/HTTP/URI. I'm finishing up an R&D project that proves that with our (my companies) current XML interface (which is SOAP using the XSD Data Model). And what I've found is that some of our messages don't make sense as XML/HTTP/URI. For example, we have a SOAP message (note not an RPC call) that allows a user to get certain preferences from our database. So an XML request might look like this (sans SOAP envelope) -

<GetPreferences>
<Preference Name="one"/>
<Preference Name="two"/>
<Preference Name="three"/>
</GetPreferences>

Now I came up with the following -
http://someserver/preferences?names=one,two,three

Or I could use a form-encoded POST. Both work pretty well, but it is not as simple or as expressive as the XML above."

I kind of dispute that, but anyhow....

"Also caching actually became a problem. The following produce the same result -

http://someserver/preferences?names=one,two,three
http://someserver/preferences?names=three,two,one

But as far as most caching servers go, they are different. Not a big deal, I'll just put a no-cache whereever I handle that URI."

Why turn off caching? It doesn't seem to hurt if the informtaion is cached three times...anyhow you wouldn't get caching with SOAP so as far as the comparison goes...SOAP doesn't win!

"One last thing...what is the difference in google sending the key plain text in a well defined element and basic authentication. Last time I checked, basic auth uses a well defined HTTP header that simply base64 encodes the credentials. Not exactly secure. So how is it different?"

I deleted the paragraph that discussed digest authentication because the article was getting long. Even Basic Authentication has the virtue that it separates the cachable part from user-specific part.

"Also why do you say that SOAP's RPC-over-HTTP hasn't solved the security problem. What is to stop that RPC call from using Basic Auth? I've done it many times. It sits in the same header that it would for a good ol' fashion HTTP call."

I said that SOAP doesn't have a standardized solution to this. That's just a fact. Because of the silliness of "protocol agnosticism", standardizing any SOAP over HTTP issue is a nightmare and some implementations will choose to use SOAP-specific solutions like the new "WS-security" stuff.

"But with SOAP (as well as SOAP-RPC), I get the extensibility of SOAP Headers. And the existence of these headers can be verified by a schema validating parser. Sure HTTP headers are extensible, but I have to validate them myself and I'm lazy."

It's a minor benefit but I agree that SOAP's XML headers are a benefit. When I get time I will show how there is really no need to use the rest of SOAP to get the benefit of SOAP headers.

"Also by putting information in these headers (such as security credentials from WS-Security), I can easily change the transport from HTTP to SMTP. Since I'm not dependent on any of the HTTP underpinnings (Basic Auth), this is very simple to do (in fact my company does it everyday)."

I'd be curious to hear more about this. Why do you do that? Of course it is possible to route any protocol over any other protocol but the practical advantages of this seem quite slight to me. I particular I'd be curious whether you write some apps to SMTP+SOAP and some to HTTP+SOAP or whether you really write apps to "SOAP" and then just change the transport. I'm skeptical because I don't see how you could construct an application that doesn't care whether there will be a reply and whether it should keep a connection open or expect an asynchronous callback etc.

"So in short, I think that SOAP 1.2 is fixing most of the problems that you have. Most of the forward thinkers (the people I know) are abandoning the SOAP Data Model (except for backwards compatibility) and moving to the XSD Data Model."

In this "just the envelope" model, SOAP's advantages are quite elusive.

"Keep up the good writing..."

Thanks for reading and actually thinking things through.

Paul Prescod
Friday, April 26, 2002

"What is needed is a light-weight mechanism to replace screen-scraping. I thought SOAP or even XML-RPC was that but they both seem over-kill. What confuses me a bit is formatting the request as a URI (it could be a POST as well, Paul, right?) and then a response in XML. Since many/most web development environments can't parse XML out-of-the-box, why not format the response in something like URL-encoded, key=value pairs? For many function calls, there's not a whole lot of data coming back."

Sure, I have no problem with that if it works for you. In my article I avoided XML for two out of the three methods. The third method was really pretty complicated so I did use XML.

Paul Prescod
Friday, April 26, 2002

"So in short, I think that SOAP 1.2 is fixing most of the problems that you have. Most of the forward thinkers (the people I know) are abandoning the SOAP Data Model (except for backwards compatibility) and moving to the XSD Data Model."

First, Justin, I don't have much of a problem because HTTP works fine for most applications, as I demonstrated with Google and have with UDDI in the past.

Second, SOAP 1.2 has no solution for SOAP's most pernicious problem, the one Joel mentions: the ability to handle object references. People do not run into that today because they aren't trying to integrate SOAP systems. Most corporations have at most one SOAP system (by which I don't mean a single piece of software but an actual information system). When they have multiple systems, and they want to integrate them and integrate them with their customers they will find it quite painful that there is no standardized way refer to a datum.

The Web solved that problem more than 10 years ago but today's SOAP advocates refuse to listen. Today one of them asked me if what I really wanted was COOKIES FOR SOAP! In my opinion this is a fatal flaw which makes SOAP useful for building large integrated systems.

Paul Prescod
Friday, April 26, 2002

I'm with Paul.

What turns me off about SOAP is that it looks so complex and hard to write, play with, debug. So not a lot of people will investigate it. The exact oppostite of what made HTML and the web so successful.

Joel calls SOAP the 'wire format', but that's wrong: HTTP is the wire format, SOAP is what meets the eye. No, says Joel, we'll have this smart editor (presumably by MS) to write/interpret our soap calls/responses with. The very fact that we would need such a tool is proof that SOAP is just too damn complex for the easy task of calling a (remote) script  and passing it some variables.

michel benevento
Friday, April 26, 2002

I was going to copy and paste portions of your response into this message, but I decided I'm just going to answer the general gist (at least what I picked up) of your response.

SOAP 1.1 (or SOAP-RPC as we have called it) says that interoperability will come from people supporting the exact specification.  You encode your data i their Data Model and magically everyone will be able to talk to you.  This works (somewhat) today.  There is interop.  But you are saying that it is overkill.  That it isn't really doing anything for you.  That by using URIs, HTTP, and XML responses you can get the same thing.  I'm inclined to agree with you...today. 

The SOAP Data Model is too complex.  But that complexity for the most part is hidden by tools.  This is good or bad depending on your viewpoint.  If you say its bad, but then you turn around an use RMI without knowing what RMI looks like on the wire, aren't you being a hypocrite?  The same for DCE-RPC, DCOM, and CORBA.  Millions (ok...probably just thousands) of people use these technologies without worrying about the wire encoding.  They don't need to.  It's been done for them.  Things get simpler with time. 

Take your URIs and HTTPs.  Every single one will be different.  Some might use query strings, others might use form encoded data, and still some might use an XML payload body (and from I understand this is evil in the REST world).  How do we make that easier for business developers?  What type of framework can we build that will be able to handle any type of URI and make that become a method call on their Java Bean or COM+ component.  Notice I say business developer.  I'm not talking about us the plumbers (to steal a phrase from Peter Drayton).  I would love to see the framework.  maybe that is the next step to write this framework that can take arbitrary URIs and HTTP headers and map them onto methods.

Now balance the above with SOAP 1.1.  It explicitely states how you must encode things.  It explicitely states how you are to pass structures around.  Because of the explicit nature, tool vendors (a.k.a. the plumbers) can build these frameworks that make the everyday life of the common business developer easier.  The business developer gets to go home and see his family.  The plumber...well...he moves on to the next challenge.

Now I realize you state the "envelope, header, and body" by themselves don't allow you to do much.  I disagree (obviously or I wouldn't be replying).  Defining my body using XSD gives me the best of both worlds.  As more and more tool vendors figure out the PSVI (Post Schema Validation Infoset), they will be able to map arbitrary XML messages onto methods (which is what ASP.NET does today).  Now add to that a structured way of passing in extra data (the SOAP headers), I'm not longer tied to the HTTP transport.  It is but one of the ways I can send a message.  This is all future.  It can be done today but mainly by plumbers and business developers that have no life :-)

You asked (or someone else) why I need to go from HTTP to SMTP.  I do this because I might need to forward a SOAP message to a consumer.  Right now most consumers don't have web servers.  So I forward a SOAP message to a mailbox that my application checks from the consumers desktop.  Pulls it down.  Executes the message.  Replies to the mail.  The server gets it and can use an HTTP SOAP Message to respond back to the original sender of the message.  No.  I can't tell you what app this is.  Because it doesn't have a name and it is being built by my (new) company and its huge engineer team (i.e. me).

NOTE: If Groove succeeds with their Edge Services, then all bets are off.  I'll build ontop of Groove :-)

To sum up - We started with raw TCP.  That sucked.  So RPC came out.  Better but still cumbersome.  So then we got CORBA and DCOM.  Even better but have issues.  So now SOAP a new protocol is invented.  It leaves behind a lot of the baggage that CORBA and DCOM have (ObjRefs which everyone seems to be hung up on).  It is really only about 2 years old.  It has a long way to go before it reaches the maturity of CORBA or DCOM.

Justin

Justin Rudd
Friday, April 26, 2002

One last reply to just to get my point across -

SOAP 1.1 defines the encoding.  It is no different from RMI, CORBA, or DCOM.  SOAP is on the wire.  The DCOM packet is on the wire.  The reason CORBA and DCOM are popular is because tools vendors have hidden this.  I believe that the wire format of SOAP is getting a bad wrap because the tools have not caught up.  Right now many vendors are saying - "It's just XML, parse it yourself."  And that is where the SOAP Data Model falls apart in my mind.  It supports things like sending an object once and having many different references to it.  It supports open and conformant arrays.

That is why people I know are pushing the XSD Data Model.  If we insist on people parsing the messages themselves at least lets make it easier on them and give them schema validating parsers, XML Infoset compliant tools, etc.  With this, plumbers can now build ontop of the XSD Data Model how to map to a method call.

It takes time.  It isn't going to happen overnight.

Justin

Justin Rudd
Friday, April 26, 2002

OK...this really is my last response for now (boss is looking at me funny).

If you believe that SOAP 1.1 is hard to look at - have you ever looked at RMI (or CORBA or DCOM) on the wire and tried to figure it out in your head?

Justin

Justin Rudd
Friday, April 26, 2002

POST/GET requests over http(s) with a set of key=value pairs as a response is looking better by the minute! What should we call it?

REST, I'm afraid, is unlikley to get anywhere until it is presented in a more utilitarian fashion. It feels much too much like a philosophy or religion or something. A "Wiki" site as it's home? Coined in a dissertation? "REpresentational State Tansafer"?

SOAP seems better suited for situations where a lot of data is returned. Since the average function call returns very little data, maybe it's not the right method?

pb
Friday, April 26, 2002

I think the issue there are simpler or technically better solution than SOAP is irrelevant.

SOAP is good simply because every single tool/platform/ERP/... vendor agreed to use it. Even with the problems pointed out, this wins hands down.

The other good point about SOAP is that it's transport independant. SOAP can be used over HTTP, SMTP, MQ/Series, IIOP, JRMP, pure socket, TUXEDO, (name your favorite transport layer) etc.

And SOAP is here not to be able to pass a couple of args to a remote function (aka Google), but a full business doc in a B2B exchange between partners (about 10k+ XML document in and out)

Of course, SOAP has strong limitations for real business ($$$) WebServices. That's why we have the myriads of other XML dialects (ex: ebXML) . It will be a while before everyone agrees on these ones, but then the promise of WebServices will be delivered.

Robert C.
Friday, April 26, 2002

Said pb: "SOAP seems better suited for situations where a lot of data is returned".

I thought it was the other way around -- SOAP allows you to put more data (than REST) as part of your request, because URLs cannot be too long. Am I missing something?

Ziv Caspi
Friday, April 26, 2002

"Take your URIs and HTTPs. Every single one will be different. Some might use query strings, others might use form encoded data, and still some might use an XML payload body (and from I understand this is evil in the REST world). How do we make that easier for business developers? What type of framework can we build that will be able to handle any type of URI and make that become a method call on their Java Bean or COM+ component. Notice I say business developer. I'm not talking about us the plumbers (to steal a phrase from Peter Drayton). I would love to see the framework. maybe that is the next step to write this framework that can take arbitrary URIs and HTTP headers and map them onto methods."

This framework is J2EE or .NET depending on your preferences. What do you think peole have been doing in their web development for the last six years?

Paul Prescod
Sunday, April 28, 2002

"You asked (or someone else) why I need to go from HTTP to SMTP. I do this because I might need to forward a SOAP message to a consumer. Right now most consumers don't have web servers. So I forward a SOAP message to a mailbox that my application checks from the consumers desktop. Pulls it down. Executes the message. Replies to the mail. The server gets it and can use an HTTP SOAP Message to respond back to the original sender of the message. No. I can't tell you what app this is. Because it doesn't have a name and it is being built by my (new) company and its huge engineer team (i.e. me)."

This is fundamentally a PULL-based applicatoin because it pulls from the mailbox. Therefore you could just pull directly from an HTTP server on the real web. Insofar as most end-users cannot set up their own mailbox it seems as if it will be much easier for either you or their ISP to maintain an HTTP-based "mailbox" than to try to reuse the SMTP infrastructure. This is what Microsoft does with the Outlook/Hotmail combination, as an example. Yes, Outlook talks to Hotmail via HTTP, not either POP nor SOAP.

Paul Prescod
Sunday, April 28, 2002

> This framework is J2EE or .NET depending on your
> preferences. What do you think peole have been doing in
> their web development for the last six years?

I think you missed my point.  Yes I can use .NET on the server, write a simple IHttpHandler implementation, and parse URIs.  Its very easy.  I've done it.  In fact ASP.NET supports this out of the box (first that I know of) as long as the parameters aren't too complex and the uris aren't complex (i.e. only query strings or form encoded). 

What I was talking about is for the business developer.  What happens when you do get a complex URI?  Or have to pass in a structure of data?  What toolset will allow me to transparently map that onto a business component method?  Remember I'm a business developer.  I don't want to write the plumbing myself.

Justin Rudd
Monday, April 29, 2002

"What I was talking about is for the business developer. What happens when you do get a complex URI? Or have to pass in a structure of data? What toolset will allow me to transparently map that onto a business component method? Remember I'm a business developer. I don't want to write the plumbing myself."

You can't transparently map that onto a method because you aren't making a DCOM wrapper for a COM method. You're making a networked application. It is well known that people who think that networked programs work just the same as local ones tend to hit brick walls hard. You may think that you are doing the business developer a favour by hiding this from them but when their system dies in deadlock or has security holes they'll find that you've done them a disservice.

Evne so, I think you've missed *my* point. Business developers have spent the last several years figuring out how to mediate between the world of objects and the world of HTTP resource representations. We should encourage them to use what they've learned about ASP, JSP, Java beans and other Web/object integration tools and discourage them from pretending that the network is invisible and that 1970s RPC techniques are appropriate.

By the way, in case Josh is reading: I'm still waiting for a clarification that demonstrates that you know the difference between SOAP and WSDL, and know that intellisense is not provided through SOAP. Hello? Josh?

Paul Prescod

Paul Prescod
Monday, April 29, 2002

Ziv, nope. Queries are typically simpler than results. For example, in the google case, a typical situation might be a sincle method call ("search") with one search term ("kournikova+penthouse") and would return 10 or 20 (or more) results, each having 10 or so pieces of data.

pb
Monday, April 29, 2002

Alright.  Obviously we aren't going to agree on this.  I believe that some layer of abstraction is necessary for productivity.  I don't want to work with the Request, Response, or Server objects.  I would like the runtime to map the SOAP or query string onto parameters onto a method call for me.  You even show in your article that ASP.NET does this.  But you turn around and say that is bad?  I don't get that.

I realize that we can't tell developers to ignore the network (although for strictly monetary reasons, I would like to not mention it :-).  But I can't see why we should force every business developer to implement the same thing.  Over the past 6 years, business developers have mapped requests onto objects.  Yes you are right about that.  And how many frameworks sprouted up to make this more seemless?

All I'm saying is that the toolkit I can build around SOAP because it codifies so many things for me is much more robust then the one I can build around URI/HTTP.  This toolkit does not have to hide the fact that it is a network application.  I never said it did.  If someone wants to drop down to dealing with the URI (or XML in the case of SOAP) directly fine, the framework should let them.

I only speak for myself and the developers I've worked with over the years.  We worked with those low level objects to create frameworks that our business components would sit in.  And we even went lower than ASP, we went to ISAPI.  Not one developer ever stopped realizing that they were building a network app.  But our productivity was much faster than another team that was doing it all by hand with Request, Response, and Server objects.

Justin Rudd
Monday, April 29, 2002

"Over the past 6 years, business developers have mapped requests onto objects. Yes you are right about that. And how many frameworks sprouted up to make this more seemless?"

Those frameworks tend to work just as well for XML as for HTML. In fact better, because you don't have to worry about browser variations. So nobody is asking anyone to go back down to coding the metal. I'm asking you to pick *appropriate* abtractions. On the Web, the appropriate abstraction is the resource with a URI. In some systems, the abtraction is the message.

But if I take a pre-existing object and in five minutes use Visual Studio.NET to build a SOAP wrapper for it then I've got wonderful ease of use around an inappropriate abstraction.

And despite the fact that my article showed how you can do *exactly the same thing* with HTTP, I am not going to defend it as an appropriate development strategy for networked applications.

"All I'm saying is that the toolkit I can build around SOAP because it codifies so many things for me is much more robust then the one I can build around URI/HTTP."

I think you've got this exactly backwards.

First, As the article shows, SOAP is typically irrelevant. WSDL codifies most things, not SOAP. I've not yet found something that can be done with SOAP+WSDL that cannot be done with HTTP+WSDL (what the specs say, not what Microsoft implements). If you have an example I'd appreciate it if you could tell me so I can submit it as a bug to the WSDL standardization group at the W3C.

Second, HTTP codifies *much more*. It codifies a set of known-in-advance methods. It codifies an addressing model which allows one application (e.g. Google) to reach into the middle of another application (e.g. the JoelOnSoftware discussion board) and address, fetch and in some cases manipulate the information in the middle of it. Web Services will not interoperate until they similarly share an addressing model. So yes, the first step is just disposing of the useless SOAP wrapper. But the second step is learning to use the features that HTTP provides that SOAP does not, including wonderful URI addressability.

Paul Prescod

Paul Prescod
Tuesday, April 30, 2002

*  Recent Topics

*  Fog Creek Home