SOAP frustrations

[Graham Dumpleton]

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.

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

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.

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. 

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