integration with SOAP-based web services?

[Kralidis,Tom [Burlington]]

> -----Original Message-----
> From: UMN MapServer Developers List 
> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Robert Hollingsworth
> Sent: 03 January, 2008 12:07 PM
> To: MAPSERVER-DEV at LISTS.UMN.EDU
> Subject: [UMN_MAPSERVER-DEV] integration with SOAP-based web services?
> 
> About 18 months ago I added a CONNECTIONTYPE to mapserver to 
> consume ESRI ArcWeb Services via the SOAP api for obtaining 
> map images.  My client uses GE Smallworld and needed 
> up-to-date landbase without purchasing datasets. 
> We basically used mapserver as a translator from ArcWeb to 
> WMS because Smallworld knows how to consume WMS.
> 

Wow!  It would be interesting to hear about your approach and
implementation experiences.

> I did this as a hack on ms4.8.3.  We may have to revisit this 
> mechanism because of some changes in the ArcWeb protocols.  
> We may, in fact, attempt to add the ArcWeb access directly in 
> GE Smallworld to improve performance.
> 
> But I've been wondering if mapserver would benefit from 
> having some SOAP client capabilities.  My original hack built 
> the SOAP request and decomposed the SOAP reply directly -- 
> bypassing the WSDL files.  I would think an "official" 
> mapserver SOAP client would want to use as much WSDL 
> automation as possible.
> 

Somewhat.  Because SOAP request parameters are (a lot of times) drawn
from WSDL defs, a generic WSDL parser would be required.  Since most
SOAP operations have their own specific bindings and parameters, etc.,
this would be tough to abstract.  This also gets complicated because
WSDL is along a discovery use case, whereas an actual SOAP request would
be analogous to a CONNECTIONTYPE WMS in MapServer.  That is, MapServer
never parses GetCapabilities to construct a GetMap (whether it should or
not is another discussion), because the GetMap request has fixed request
parameters, thus bypassing Capabilities XML parsing, and setting as
little request params as possible in LAYER/METADATA/wms_*.  WMC works in
a similar way, allowing a 'bookmarkable' application state without
having to go back to Capabilities XML to construct a map.

And this is just at the request level.  How would MapServer know what to
do with a given SOAP response.  Parsing the response would involve
MapServer knowing _what_ the response is and what to do with it.  OGC
standards are a bit easier to work with because you have a pretty good
idea what you're getting back from, say, a WMS GetMap request.

> It might be difficult to generalize SOAP client behavior over 
> more than one specific service.  For example, ESRI ArcWeb is 
> a commercial service and requires purchase of "credits" which 
> are expended at varying rates depending on what data sources 
> you're using.  You have to acquire a "token" before accessing 
> map images.  Also, ArcWeb has specific constructs for naming 
> data sources and for turning individual layers on or off.  
> And its product is a raster image; I could imagine another 
> SOAP-based map service returning individual shapes with attributes.
> 
> Anyway, I'm wondering if the mapserver dev community sees any 
> value in adding some type of SOAP client processing to mapserver.
> 

One thing we often hear is SOAP/WSDL support for OGC standards, so they
can play within common IT dev environments.  I believe OGC has
discussion papers on such approaches.  If, say, WMS was SOAPed, then
MapServer could conceivably support client and server because the
behaviour is well known (enough) at runtime.  In this case, it would
just be a matter of a building or parsing the soap:Envelope.

One idea here would be to define a SOAP message as a template, with
substitutable values, i.e.:

"soap_request" '
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
  <soap:Body xmlns:m="foo">
    <m:GetMapImage>
      <m:Layers>[layers]</m:Layers>
    </m:GetMapImage>
  </soap:Body>
</soap:Envelope>
'

..and have a clever way of defining what is coming back.

> And what about mapserver as a SOAP SERVER?  That's another 
> can of worms entirely...
> 

MapServer would have to be able to:

- output WSDL documents, which wouldn't be too complicated, and a neat
way to expose, say, the CGI interface parameters
- support subsequent SOAP request messages

At any rate, from the little I know about SOAP, I do know this: you
still have to process soap:Body (in a request or response context) just
as you would a CGI query string, an XML POST request, an XML response,
etc.  So even if we supported SOAP, we're still tasked with processing
the request/response.  This would be easier for already known types
(such as WFS, SOS, etc.).

..Tom