SOAP - Revision history

Wiki-JoWalsh: /* Reports from the wild */

2008-02-18T20:55:07Z

Reports from the wild

Jive: /* OWS-3 */

2008-02-03T22:58:55Z

OWS-3

Jive at 22:56, 3 February 2008

2008-02-03T22:56:01Z

Wiki-JoWalsh: /* INSPIRE */

2007-12-20T18:27:38Z

INSPIRE

Wiki-JoWalsh at 15:43, 20 December 2007

2007-12-20T15:43:43Z

Wiki-JoWalsh at 13:06, 13 July 2007

2007-07-13T13:06:26Z

Wiki-JoWalsh at 21:43, 12 July 2007

2007-07-12T21:43:13Z

Wiki-JoWalsh: soap suxx0rs

2007-07-12T21:11:21Z

soap suxx0rs

New page

The Draft Implementing Rules for Network Services for geographic data under the INSPIRE directive may mandate a SOAP interface for access to all OGC web services. This means WMS, WFS, WCS, CSW et al - even when the behaviours of a SOAP interface are not fully-described in the OGC specifications.

Are there user community experiences, documentable, to do with SOAP working or not working in the wild? It is easy to collect a lot of opinions and a lot of references to opinions. 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? etc.

Help?

← Older revision		Revision as of 20:55, 18 February 2008
Line 28:		Line 28:

	=== OWS-3 ===		=== 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: [http://portal.opengeospatial.org/files/?artifact_id=12911]		In 2005 the combination of GeoTools and uDig played host to a range of Open Web Services, GeoDRM, and SOAP/WSDL conflict: [http://portal.opengeospatial.org/files/?artifact_id=12911]

@@ Line 29: / Line 29: @@
 === OWS-3 ===
-In 2005 the combination of GeoTools and uDig played host to a range of Open Web Services, GeoDRM, and SOAP/WSDL conflict.
+In 2005 the combination of GeoTools and uDig played host to a range of Open Web Services, GeoDRM, and SOAP/WSDL conflict: [http://portal.opengeospatial.org/files/?artifact_id=12911]
 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.

@@ Line 1: / Line 1: @@
-People say "SOAP vs [[REST]]" so there is a [[REST]] page.
+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.
 ----
@@ Line 27: / Line 26: @@
 Are there user community experiences, documentable, on how widely SOAP/WSDL for geodata services are implemented in the wild?
 == References ==

@@ Line 17: / Line 17: @@
 * 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.html
+* 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.''

@@ Line 1: / Line 1: @@
-People say "SOAP vs [[REST]] so there is a [[REST]] page.
+People say "SOAP vs [[REST]]" so there is a [[REST]] page.
 ----
-The Draft Implementing Rules for Network Services for geographic data under the INSPIRE directive may mandate a SOAP interface for access to all OGC web services. This means WMS, WFS, WCS, CSW et al - even when the behaviours of a SOAP interface are  not fully-described in the OGC specifications.
+== OGC ==
-Are there user community experiences, documentable, to do with SOAP working or not working in the wild? It is easy to collect a lot of opinions and a lot of references to opinions. 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? etc.
+The OGC has been revising many of its W*S specifications to supply SOAP bindings.
-Help?
+== INSPIRE ==
-References
+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.
-* http://www.somebits.com/weblog/tech/bad/whySoapSucks.html From Nelson Minar, who worked on several SOAP services for Google.
+The Network Services document offers 4 "arguments in favour" of SOAP bindings.

← Older revision		Revision as of 13:06, 13 July 2007
Line 1:		Line 1:
		+	People say "SOAP vs [[REST]] so there is a [[REST]] page.
		+
		+	----
		+
	The Draft Implementing Rules for Network Services for geographic data under the INSPIRE directive may mandate a SOAP interface for access to all OGC web services. This means WMS, WFS, WCS, CSW et al - even when the behaviours of a SOAP interface are not fully-described in the OGC specifications.		The Draft Implementing Rules for Network Services for geographic data under the INSPIRE directive may mandate a SOAP interface for access to all OGC web services. This means WMS, WFS, WCS, CSW et al - even when the behaviours of a SOAP interface are not fully-described in the OGC specifications.

← Older revision		Revision as of 21:43, 12 July 2007
Line 4:		Line 4:

	Help?		Help?
		+
		+	References
		+
		+	* http://www.somebits.com/weblog/tech/bad/whySoapSucks.html From Nelson Minar, who worked on several SOAP services for Google.