[Biogeosdi] Report from OGC meeting
Javier de la Torre
jatorre at gmail.com
Wed Jul 18 00:52:50 CEST 2007
Cool discussion :)
> $http_request = new HTTP_Request();
> $http_request->setMethod( 'POST' );
> $http_request->addHeader('Content-Type', 'text/xml');
> $http_request->addRawPostData( $xmlBody );
> $http_request->setURL( $serviceUrl );
> $res = $http_request->sendRequest();
> $response = $http_request->getResponseBody();
Dont you need to set up the "action" in the HTTP header for SOAP to
work? Well, I suppose if you add it to the header as you did with the
content type it should work.
But, this in general, together with the rest of your message
explaining the use of a perl script to be able to actually get the
$xmlBody I think makes the whole thing pretty complicate, not so much
as a matter of number of lines, but to so much preknowledge you must
have to interact with the service.
And by the way... you need to have PEAR installed on your PHP, which
is not by default and I have to recognize I havent managed to install
in my mac os x... :(
> parameters like createModel and projectModel. The SOAP body envelope
> is always the same so you could have a separate function just to add
> it to the real body.
Again, thats kind of overload on the PHP side... but as you said
later this is just because there is no good SOAP library
implementation for PHP... what is for sure is that there are very
good libraries for almost every language to do simple http requests
without modifying actually headers.
> Anyway, the point is that it's not so bad to get things working with
> SOAP in the way I just exposed. And I suspect it would have saved a
> lot of time in the meeting.
Right!! ;) But I think that this also kind of demonstrate, that for
kind of average programmer, as I can probably be, this was not
obvious and needed the use of at least two different technologies, in
my case Nusoap + Oxygen, in your case PEAR and Perl.
> Now to answer your question...
>> do you really wanna have all that headaches for actually not
>> having any good back?
> Specifically about OMWS, my feeling is: If your programming language
> has a good SOAP library and you already know how to use it, then it
> should not be difficult to get it working with the OMWS WSDL. If your
> programming language doesn't have a good SOAP library or if it has
> one but you don't know how to use it, then maybe it's better to do
> everything manually (just as it would be necessary with REST).
My point actually is that, as you say, if your programming language
is not good enough, like probably PHP, then it does not matter if you
use REST or SOAP so you will have to handle the service yourself, the
only difference is that in the case of SOAP you have to take care of
some more stuff, for some people maybe obvious, but for me it was a
real headache :(
And I dont say that SOAP doesnt have advantages. Of course if you are
using gSOAP for client too then it is probably very easy and cool to
consume the service, but considering the learning curve to
understand the different SOAP kind of services, the problems in
interoperability (there is a reason for WS-I!)... well, if possible
(and thats another question I have to recognize), using REST looks
much much simpler...
Considering the operations from OMWS I would find very nice to have
ping, getLayers, getAlgorithms and getProgress as REST services... i
still havent finished reading my RESTful book from o'reilly so I can
not say how I would implement runModel as a REST service...
Still probably some documentation from OMWS with the SOAP request
messages as example for developers would be a really nice
documentation resource for anybody that want to use it.
More information about the tdwg-content