Tim Woodcock wrote:
> "SOAP" and simple do not belong together in the same sentence.
>
> If you want simple, XML is ok. But SOAP is a way of adding software
> context on top of data. That is not simplicity.
Yes, the SOAP on-the-wire protocols are complicated, especially when you
start adding WSDL into it. It's not fast, either.
But - you don't have to look at the wire protocol to use it, because
pretty much every combination of platform and language has a SOAP client
library available. A reasonable library should make accessing a SOAP API
simple - as an example, it's more than possible to write SOAP client
one-liners with Perl and SOAP::Lite ... yes, you can leave the 'all Perl
looks like a one liner' gags right there :)
Seriously though, this *is* simple:
use SOAP::Lite;
print SOAP::Lite
-> uri('http://www.soaplite.com/Temperatures')
-> proxy('http://services.soaplite.com/temper.cgi')
-> f2c(32)
-> result;
(from http://www.soaplite.com)
That's a trivial example though, and any OpenSRS SOAP API would
necessarily have more elaborate methods than 'f2c', but as the library
should take care of type conversions and so on, using the methods should
be no less simple.
This isn't to say, however, that SOAP is the only way forward. All I'd
like to see is simply OpenSRS accepting that what's needed is an API,
not a set of client CGI scripts with a reasonable but underdocumented
API buried underneath. Sure, the methods themselves are pretty well
documented, but as far as I can see, the documentation for the transport
is XML_Client.pm and friends.
Perhaps a reasonable first step would be to document the entire protocol
in a language-neutral way, and then there'd be no excuse for those who
don't speak Perl not to build a client for the current API with whatever
system they choose.
Chris.
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:37:48 EDT