For the REST services implementors out there!! There is a book from o'reilly called RESTful services that is a must! I am sure you will like it... In the other hand there is another one called Dont make me think that is really really good too! If you wanna take OGC people into account in OMWS then also implement OMWS as a WPS service, but this we might find someone in the OGC world interested in doing it so... It seems not too dificult to implement a wrapper WPS in front of SOAP services. Let see if someone contact after the OGC meeting. Cheers. On 16/07/2007, at 0: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

2007/7/12, Javier de la Torre <jatorre@gmail.com>:

...

Hey Lee,

Here I send you what I have written at my return from the OGC meeting. You asked me also for a comment on how i think TDWG should continue working with OGC. I will write that in a later message ok?

By the way... i couldnt find any news announcing the MoU between TDWG and OGC :(

Cheers.

--------- Report of the July 2007 OGC Technical Committee Meeting --------------------- The Open Geospatial Consortium (OGC) held its 61st Technical Committee and Planning Committee Meetings during the week of July 9, 2007 in Paris. TDWG was there represented by Donald Hobern and Javier de la Torre who gave two presentations on the Earth Observation and Natural Resources and Environment Working Group.

OGC Technical Committees meetings are a fundamental tool for OGC process in building standards and assure interoperability. During a week, OGC members meet in different working groups, discuss and vote in the process of making or reviewing standards.

Thanks to the new MoU between TDWG & OGC (link here but I could not find any news item about this ???) now there can be a representation of TDWG in every OGC meeting and push the interest from the biodiversity informatics community in the development of geospatial standards.

In this meeting topics varied from Geographic Markup Language, coverages, the GEOSS project, Web Map Service, Sensor Web Enables and many more. During the Earth Observation, Natural Resources & Environment Working Group Meeting TDWG was presented in two different presentations from Donald Hobern and Javier de la Torre.

Donald Hobern presented (available here) the TDWG infrastructure project and GBIF. The new GBIF REST services were presented together with how TDWG is creating a new set of vocabularies that can be use by services which data has something to do with biodiversity.

Javier de la Torre presented (available here) the results of the BioGeoSDI meeting (link http://wiki.tdwg.org/twiki/bin/view/ Geospatial/InteroperabilityWorkshop1) with a presentation that made emphasis on the use of primary data and niche modelling together with OGC and TDWG standards.

In the other hand there has been several presentations about the Global Earth System of Systems (GEOSS) and the pilot projects that are starting now. GEOSS have recently released their catalog service, a registry where geographic data providers and services can be found to create a truly world wide Spatial Data Infrastructure for the observation of the earth. For the moment only a few services are registered, but they plan in the upcomming months to complete the catalog with every service related to the observation of the earth.

Related to the observation of the earth, there is the Sensor Web Enabled (SWE) working group in OGC that has presented several papers in their continuos effort to provide an interoperability framework where all kind of sensors can "talk to each other" in a seamless way.

During the meeting the new OGC interoperability program, OWS-5, was discussed. This new initiative include more than a hundred participants with a budget of at least a million dollars. The program is organized in 6 different threads: Sensor Web Enablement (SWE), Geo Processing Workflow (GPW), Information Communities' Semantics (ICS), CAD/GIS/BIM, Agile Geography, Compliance Testing (CITE). Significant work items include geospatial Web service chaining and workflow, enhancements to the KML language, practical application of the Sensor Web, and application of GML to real-world scenarios.

There were also discussions on the so called GeoAPI. Together with the creation of standards there are efforts to provide APIs that implement the standards so that different vendor, software producers, can implement them using the same interfaces. The API is available in sourceforge and is implemented in Java.

The Web Coverage Service (WCS) was also discussed. There is open discussions on implementing asynchronous services and the use of SOAP encodings, although this seems to be a general discussion among all OGC standards.

The meeting about OGC for the Mass was a very crowded one. The aim of the meeting was to identify current trends on the use of geospatial information on Internet. Things like GeoRSS, KML, WMS tiling, etc. Specially interesting is the process of making KML an OGC standard. This has been included in the OWS-5 initiative.

In general it has been a nice meeting with lot of ongoing discussions. The OGC procedures seems to work quite well and lots of discussion papers are being prepared continuously that expand or improve OGC vision and their standards.

[maybe you want some more personal comments Lee?]

_______________________________________________ biogeosdi mailing list biogeosdi@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/biogeosdi

-- Tim Sutton QGIS Project Steering Committee Member - Release Manager Visit http://qgis.org for a great open source GIS openModeller Desktop Developer Visit http://openModeller.sf.net for a great open source ecological niche modelling tool Home Page: http://tim.linfiniti.com Skype: timlinux Irc: timlinux on #qgis at freenode.net

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@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/biogeosdi

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.

Hi Renato,

impractical to send them as simple URL parameters. Anyway, if you discover a better way to do that in REST, please let me know!!

I think I might have a better approach, but I have to finish reading a bit to tell you more... again if you have the opportunity get http://www.oreilly.com/catalog/9780596529260/

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.

Right, but for the basics, you dont really need anything but just open a url... so, make things complicate where they need to be right?

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

I still think that if you dont set the SOAPAction in the http header your gSOAP library will raise an error. And the problem with this is that once you have to start defining your own http headers to do a request then you cant use most of libraries to http request because they dont expose normally this functionality.

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.

Well, you used a Perl program, I used Oxygen SOAP debugger, and someone might get the sample code after checking out the server code... probably some documentation somewhere about this thing would help a lot, but then you start looking very much as REST, documentating the service in natural language :D Cheers.