[Biogeosdi] Report from OGC meeting

Renato De Giovanni renato at cria.org.br
Tue Jul 17 19:12:08 CEST 2007


Hi Javi,

The "low level requests in HTTP" are actually very easy. For example, 
if you use the PEAR/HTTP/Request.php library you need 7 lines of code 
to interact with the service:

$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();

Of course you need to know the $xmlBody for each type of request, 
which in the case of OMWS should include the SOAP stuff. But this I 
can easily get from the Perl command-line client that dumps all 
messages. The messages also used to be publicly available from the om 
website (I need put them again there). Anyway, I can get one request 
right now from the Perl client... So for ping it would be:

<?xml version="1.0" encoding="iso-8859-1"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<omws:ping xsi:nil="true" 
xmlns:omws="http://openmodeller.cria.org.br/ws/1.0" />
</soap:Body>
</soap:Envelope>

So it's just copy & paste for most methods, except those that need 
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.

As I said, it would obviously be cleaner to just call:

http://myservice/service.cgi?op=ping

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.

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

I have to say that there were some advantages on the server side 
because gSOAP is a very powerful library. After the initial learning 
curve, you can easily do lots of things with it, and I think it can 
handle anything related to SOAP. It also comes with a single program 
that can run as CGI, fast CGI, daemon listening on specific port, 
multi-threaded or not. And it's C++ so it was easy to integrate with 
om.

You know I'm not claiming that OMWS is perfect and should not be 
changed, my point is just that it doesn't need to be so difficult as 
seemed to be during the meeting to interact with it. 

Best Regards,
--
Renato

On 17 Jul 2007 at 17:29, Javier de la Torre wrote:

> Right Renato,
> 
> What you say is totally true for the response. I dont mind ignoring  
> the SOAP envelope when parsing results from the SOAP service  
> (Although I still dont find it very useful). The problem actually is  
> in performing request. Because SOAP makes mandatory to send specific  
> SOAP headers on the HTTP request, more concretely the action, it  
> becomes pretty hard to use directly with simple PHP. That is actually  
> the ONLY reason why we were using NUSOAP, to not have to handle  
> having to create our own functions to do such low level requests in  
> HTTP.
> Actually when parsing problems with the service I came to look at how  
> NUSOAP handles doing requests to SOAP services and it is definitely  
> not done in 5 lines of PHP code.
> 
> Well, this is only one part of the story. The other is how difficult  
> is to actually debug and program this document style SOAP services.  
> Because it was so hard to use in PHP we actually finished using the  
> Oxygen program as a SOAP client for testing. This way we could  
> actually know what was coming from the services. I know we could have  
> created a little bit more of code in PHP to do better "inspropection"  
> of the services, but actually this was the easiest way to do it...  
> not that nice.
> 
> The SOAP extension in PHP I believe didnt work with SOAP document/ 
> style but I might be wrong... at least that is what I remember. I  
> think it was created mainly for SOAP-RPC style.
> 
> I did not know wsdl2php when we started I have to say :((( Maybe it  
> works fine...
> 
> At the end I believe it is a matter of compensation... do you really  
> wanna have all that headaches for actually not having any good back?  
> I mean, if you are gonna handle the results the way you want (I am  
> also exceptical about code generators from WSDL as they usually  
> generate huge objects for document style services that does not  
> benefit you, it is the service developer point of view, not the  
> client point of view and I might dont want most of your stuff), by  
> parsing the document at the end as if it was not SOAP... then... what  
> is the point about it?
> 
> Cheers.
> 
> Javi.
> 
> 
> On 17/07/2007, at 16:57, Renato De Giovanni wrote:
> 
> > Hi,
> >
> > Most of you already know that I really like the REST style, but in
> > the case of OMWS I think these would be the only benefits:
> >
> > - Simple methods like getAlgorithms, getLayers, getProgress, etc.
> > could be invoked without using any XML.
> > - No need to have SOAP headers and SOAP envelopes.
> >
> > This would certainly simplify things, but at the same time it's not
> > such a big difference. If during the biogeosdi meeting you had to
> > deal with a REST API instead of the SOAPish one, my feeling is that
> > the biggest benefit would be that you would not spend any time trying
> > to get it working with existing SOAP libraries. I suppose this was
> > the biggest problem: trying to get it working with a SOAP library
> > that doesn't support document/literal well, or with a SOAP library
> > that doesn't have good documentation.
> >
> > If you didn't spend any time trying to get it working with SOAP
> > libraries and if you concentrated only in generating the XML requests
> > by hand and parsing the XML responses by hand (ignoring the SOAP
> > headers), you could get it working with approximately the same effort
> > as if it was a REST API. The document/literal SOAP style doesn't
> > require you to deal with SOAP encoding, which would force you to use
> > a SOAP library and could bring incompatibilities between SOAP
> > libraries.
> >
> > Another alternative would be to use the SOAP extension in PHP:
> >
> > http://www.php.net/manual/en/ref.soap.php
> >
> > Or even this interesting tool, since OMWS has a WSDL file:
> >
> > http://www.urdalen.no/wsdl2php/
> >
> > Anyway, I just wanted to make these general comments about the
> > subject.
> >
> > Regards,
> > --
> > Renato
> >
> > On 15 Jul 2007 at 19:58, Tim Sutton wrote:
> >
> >> Hi All
> >>
> >> I got a chance to read through through the final report - really  
> >> great
> >> job! I think we need to take the comments on omws into account and
> >> implement it as a rest service at some stage. Javi thanks for  
> >> bringing
> >> it all together and getting it sent off to Lee.
> >>
> >> Regards
> >>
> >> Tim
> >
> > _______________________________________________
> > biogeosdi mailing list
> > biogeosdi at lists.tdwg.org
> > http://lists.tdwg.org/mailman/listinfo/biogeosdi





More information about the tdwg-content mailing list