SOAP

People say "SOAP vs REST" so there is a REST page. People also say WSDL vs OWS but there is no page for that yet.

---

OGC

The OGC has been revising many of its W*S specifications to supply SOAP bindings.

INSPIRE

The Draft Network Services Architecture for the INSPIRE European SDI suggests that INSPIRE may require a SOAP binding for access to all network data services. This means WMS, WFS, WCS, CSW et al. If the behaviours of a SOAP interface are not fully-described in the OGC specifications, the OGC specifications will be revised.

The Network Services document offers 4 "arguments in favour" of SOAP bindings.

• SOAP web services are becoming the standard information technology and thus support more sustainable implementing rules
• SOAP web service ensure smooth and complete integration in development environments
• SOAP web services yield a direct and full integration with other web service environments
• SOAP web services have the possibility to support geo rights management services by using SOAP envelope data
• http://www.eu-orchestra.org/publications.shtml apparently contains a "list of implementation specifications for SOAP/WSDL geoservices"

The European Commission will launch a project to study in detail whether a SOAP/WSDL based approach is feasible for the INSPIRE network services. Moreover all involved SDICs/LMOs are hereby requested to provide comments and reports on the usage of SOAP/WSDL in the frame of setting up an SDI.

Reports from the wild

It is necessary to put together a set of clear basic use cases and do as much benchmarking and testing as possible. If people are offering and documenting both SOAP and the common REST style interfaces to their repositories, what do the access statistics look like?

Are there user community experiences, documentable, on how widely SOAP/WSDL for geodata services are implemented in the wild?

OWS-3

The claims made in favour of SOAP are an exaggeration of the capacity of this protocol to deliver “seamless integration” in a real-world, rather than test-case, environment. The following commentary on experience with SOAP in the wild was offered by the PSC chair of the GeoTools project which participated in an OWS-3 SOAP evaluation effort:

In 2005 the combination of GeoTools and uDig played host to a range of Open Web Services, GeoDRM, and SOAP/WSDL conflict: [1]

You have to understand that for adaptive systems; like Web Feature Service (in which the shape of the data is described) the combination of SOAP and WSDL tends to fall down. If you look at things from a code generation standpoint (usually from a microsoft supported software stack) it is very hard to escape the notation that WSDL / SOAP combination is the best/only approach. So much so that GeoVideo services was done using WSDL / SOAP and we could never match (or communicate) the descriptive capability of classic OWS style services such as WFS, CAT, WCS.

The story usually goes; contact WSDL; generate objects that match the advertised data; construct a proxy class to talk to the operations declared in the WSDL description. This approach works well for a single service; it is not well suited to Feature data where the point is to allow the flexibility to declare new data formats and discover them in an add hoc manner.

For services like WMS where the format of the data is known up front WSDL / SOAP is a much more approachable concern. This matches the problem description for which SOAP/WSDL was constructed. Note you can also neuter WFS (the approach taken for GeoVideo Serivce) and limit the shape of the returned data; and the list of available operations to a fixed set. Done at a organization level it would severely limit what INSPIRE can do; but the ability to use off the shelf software stack may be worth it for them? Let me know if a list of of Feature Type has been settled on and then we can talk. It may be a small thing but the request of partial data (ie geometry with just one of the attributes) is also a very pragmatic concern; it is hard to do that sort of thing if the XML binding technology does not account for the use case.

Before proceeding you really should talk to RobA about service profiles (because it is what the issue is). Open Web Services are not modern; and they lack tool support; but they do fit our problem description. Remember our field makes use of (and expects) the same ability to classify domain data that us programmers have grown to love.

SOAP is trying to hit above its weight class on this one; I would love to say give it REST but I lack the experience to advise on this one.

References

• http://www.somebits.com/weblog/tech/bad/whySoapSucks.html From Nelson Minar, who architected several SOAP services for Google, on why Google moved to a REST approach.