[Biogeosdi] Report from OGC meeting

[Javier de la Torre]

Hi Renato,

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.

Cheers Renato.

Javi.