[Biogeosdi] Report from OGC meeting

[Renato De Giovanni]

Hi Javi,

It's also a pleasure for me to discuss this with you. I still have a 
few comments after your last message.

You said that you still don't know how you would design "createModel" 
as a REST call. I think I can already anticipate that: you'll need to 
send an XML request, exactly like we have now, but without the SOAP 
envelope. The reason is very simple: you may easily want to pass more 
than 100 occurrence points (lat, long) and more than 50 references to 
environmental layers to create a model. It would therefore be 
impractical to send them as simple URL parameters. Anyway, if you 
discover a better way to do that in REST, please let me know!!

This means that by using REST, you would still need to deal with "low-
level HTTP requests" (using PEAR or the new HTTP extension for PHP or 
any other library). By the way, for me REST also means "make full use 
of HTTP because it has many other useful features that most people 
don't even know". So I think that the most basic toolkit for a REST 
developer is to have a good HTTP library.

So in this case (createModel request), the only difference between 
using REST and SOAP considering those seven lines of low-level HTTP 
code, would be an additional line before sending the request:

$xmlBody = WrapWithSoapEnvelope($xmlBody);

Please don't consider the Perl client that I mentioned in my previous 
message a requirement to get things working. If you have a local copy 
of the openModeller source code, you can look at src/soap to find one 
file for each request and response of each operation (e.g. 
openModeller.getLayers.req.xml). I forgot that they were 
automatically generated by gSOAP and can be used as a reference.

I really don't know why PEAR is difficult to install in mac os x. 
Afaik, PEAR is just a set of PHP scripts that only need to be in you 
PHP include path. You don't need to compile anything or do anything 
fancy (?).

Best Regards!
--
Renato

On 18 Jul 2007 at 0:52, Javier de la Torre wrote:

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