SOAP frustrations

[Graham Dumpleton]

Derek Thomson <derek at wedgetail.com> wrote in message news:<TAcr9.454$i84.53593 at news.optus.net.au>...
> Hi Graham,
> 
>
> > 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 ;)

Agree. In distributing your own clients, you get back to the problem of having
to identify what platform the client has to run on. At least in an Intranet
the client desktop is usually mostly standardised and it is possible to get
away with one or perhaps two client implementations. On the Internet though
you are always going to dissappoint someone because your specialised client
doesn't work for them. Okay, you could use Java as you client, but at that
point you may as well use something like RMI.
 
> 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.

I agree that the object references thing is an issue. In the main though
I would suggest this is a deficiency of the bulk of web service toolkits
available. The problem with many toolkits is that they only support the
concept of a single fixed URL as the gateway into the application. To
dynamically define new URLs which can be accessed is nigh on impossible.

I identify this as a problem, because a simple way of having an object
reference is for each to have a unique URL. Some people get around it
by passing an object reference as a parameter to every method they
call which relates to an object, but I see this as a clumsy way of doing
it. First off you need the magic parameter and second, if you aren't
careful, your method namespace potentially gets polluted with large numbers
of unrelated methods for different object types.

Thus what I do is when you want to create a new server side object from a
remote client, you call a create() method which returns a new URL. The client
then uses this new URL to talk to the object. When the client no longer
wants the object, it can explicitly call a destroy() method on it, or just
leave it, and an idle timer on the server side will reclaim it after a period
of not being used.

How does this compare with what you do with Fnorb? Do you use a separate
URL or do you pass an object reference as a parameter? Or do you do it some
other 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.

There is also the problem of reliability and actually detecting when calls
fail and where, whether you have to undo the transaction and all the
associated mechanisms. Such things would all have to be built from scratch,
even if you had a way of referring to objects.

To my mind another feature which is lacking in a pure XML-RPC or SOAP
system is the idea of presence. In a complicated system it can be extremely
useful to subscribe to the existance of a service and be able to be notified
when such a service comes into existance or dissappears. Another useful
feature is being able to subscribe to values published by a service. In
both cases it requires an ability for a service to call back to a client
at any time. The idea that a client should run its own little web service
to allow this to be done just isn't practical.

> > 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.

I am not suggesting one would look at the XML directly. You definitely
need to use something to present the data in a more palatable form. The
easiest way of doing this is to construct a web page which uses a Perl
or Python SOAP or XML-RPC client to call into the backend service to get
the data and then render it as HTML to the browser.

Yes you could also have some specialised GUI client to achieve the same
thing, but you then get back to having to deploy it to all desktops. At
least if such things are rendered as HTML pages delivered up by a web server
you only have to deploy it to one spot and any browser can be used. By
using XML-RPC or SOAP in this case, you also still get a clean seperation
between backend model and presentation.

Back tracking a bit, I also don't think this is the answer for everything.
All my own low level debugging tools are stanadlone GUIs which talk the
messaging system protocol. For what they are doing this is preferred as
they get access to the presence functionality along with ability to
subscribe to values published by services.
 
> > 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.

And it is unfortunately where many toolkits are very lacking.