SOAP frustrations

[Derek Thomson]

Hi Graham,

Graham Dumpleton wrote:
> Derek Thomson <derek at wedgetail.com> wrote in message news:<tS7r9.452$i84.53205 at news.optus.net.au>...
> 
>>Andrew Dalke wrote:
>>
>>>It's such that the more CS-y people at my client's site believe that
>>>web services in Python are still very immature and want to switch the
>>>project over to Java and WebLogic(!).  (I did point out that developing
>>>the library I did was still less time than setting that up, but there
>>>are other factors in the mix as well.)
>>
>>I think most CS-y people believe that web-services themselves are very 
>>immature, and are likely to remain so for a while yet.
> 
> 
> As far as the Internet goes I would probably agree on that point. After all,
> there aren't exactly many (any?) web services of any great significance which
> are generally available over the Internet through only a SOAP or XML-RPC
> interface. Where such SOAP or XML-RPC interfaces exist, they in general
> merely add something on top of what is an existing browser based service.

Yes, we've been doing this kind of thing via "web-scraping" for years.

> 
> The problem in the Internet arena is that you are asking too much in putting
> up a web service on the Internet, publishing your WSDL and expecting people
> to write their own clients. 

Why can't people just distribute their own clients for their services? 
Ah, because then you wouldn't need "web services" at all ;)

> Yes it may work for very simple stuff like Google
> searching or stock quote services, but not for anything too much more
> complicated than that.

There are other issues. How do you do distributed transactions between 
objects on different servers? Or asynchronous events? My basic problem 
is that SOAP is just re-inventing the wheel, because DCOM failed to 
scale (and now seems to have been swept under the carpet). I already 
have CORBA for all this stuff. Why do I need to wait for SOAP to catch up?

I also have a problem with the basic architecture. This whole "no object 
references" thing. How then, is it OO in any way? What does the 'O' in 
SOAP stand for? How can I implement a method that creates a new object 
on the server, and then returns a pointer/reference to that new object? 
How do I pass object references between clients and/or servers?

I got around this with XML-RPC on Fnorb by implementing my own object 
reference structure analogous to CORBA object references on top. Which 
is fine as XML-RPC makes no claim to OO-ness. SOAP has the letter 'O' in 
it, and yet it not only doesn't have object references, but by my 
reading explicity forbids using them in an way.

How then, can SOAP ever be used to create a non-trivial application, 
where objects are being created and passed about all the time?

And, I don't see how distributed transactions can ever work, given that 
you need to be able to say "here's a bunch of objects that are part of 
this transaction". If you can't refer to objects, just "services", it 
can't be done, as far as I can see.

> 
> Where web services make more sense at this point is on company Intranets
> where the application developers can also build and deploy the clients which
> might make use of such systems in a meaningful way. Even in this setting I
> still don't see services relying purely on XML-RPC or SOAP type protocols
> for communications. What is a better mix is to use more traditional frameworks
> for interprocess communications and/or messaging and have these web based
> protocols more as a convenience for accessing a restricted set of interfaces
> of a system as a whole.

Yes, perhaps. I can only see a non-hype niche for it where people, for 
political reasons, want a non-binary protocol flowing across the 
network. And when they are prepared to pay the bandwidth cost, and the 
large processing cost at each end. (every integer must be converted to a 
string and back again, for example).

I think that would be misguided, but I can see people just liking it 
regardless.

> 
> In such an approach, having such interfaces can be especially good as providing
> a way of monitoring or controlling the application. Even using such interfaces
> merely for the task of getting information out of an application during
> debugging and testing or even after it is deployed, can be enormously useful
> and save a lot of time and effort. 

Really? I don't find XML to be particularly readable, especially with 
SOAP, where the tag density is very high. Try looking at some XML for a 
complex structure that is correct, and then one that is bad. Can you 
really tell? You'll need some sort of dumper/visual tool to help, and I 
can easily create something like that for any binary protocol.

Anyway, as my XML-RPC experiment with Fnorb neatly demonstrates, I *can* 
run CORBA over XML, if I don't mind the overhead. And I get a decent 
object model :)

> 
> The trick of course in all of this, is having a framework where providing
> such interfaces isn't an undue burden. Preferably it shouldn't require any
> extra work at all over the minimum you have to do to get your work done in
> the first place. :-)

Yes.

--
D.