integration with SOAP-based web services?

Robert Hollingsworth reh2 at PRODIGY.NET
Thu Jan 3 15:04:17 EST 2008


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

ArcWeb's behavior is roughly analogous to mapserver's, where the details of
the SOAP request correspond to many mapfile values.  And ArcWeb also
accesses a mix of vector and raster data sources and builds a raster image
as an output.

I basically intervened in the normal processing of TYPE RASTER so that
mapserver would generate the ArcWeb SOAP request, obtain the reply (which,
sadly, requires a second trip to the ArcWeb server to pull down the actual
jpg or png that has been produced), dump the image to IMAGEPATH under the
name specified as DATA.  Use TRANSFORM FALSE, because I've already seen to
it, by using EXTENT and UNITS and PROJECTION and SIZE in the request, that
the resulting image will perfectly overlay whatever else mapserver is
building from local sources.  So by the time mapserver is sweeping up its
RASTER data sources to add to the output, the ArcWeb product is just sitting
there waiting to get included.

I invented a CONFIG param to include the ArcWeb authorization token in the
SOAP request; we added it to the mapfile overnight automatically.

I also had to invent some LAYER metadata to introduce some request values
that don't correspond cleanly to existing mapfile constructs.  Chiefly, an
ArcWeb data source can have many layers you can activate or deactivate.  I
chose not to make this association: ( Mapfile LAYER == ArcWeb Data Source +
one of its internal Layers )  because of performance concerns.

Mapfile params OFFSITE and TRANSPARENCY (renamed OPACITY) are handy if you
want to overlay the ArcWeb content resulting from their vector data over
local vector and raster data layers.

It might have been better to design the ArcWeb processing to mirror the WMS
client code in mapserver.

By the time this all showed up via WMS in the GE Smallworld product,
performance was actually pretty poor.  ArcWeb SOAP requires the two round
trips to their server.  An ArcWeb REST api also exists, which has fewer data
sources and options wrt SOAP, but it makes just one round trip.  So that was
a bit faster.  But I also had to save ArcWeb's raster output as a file, then
have it copied to mapserver's output; there might have been some way to dump
ArcWeb's content directly to mapserver's output stream  -- if mapserver
isn't dishing out any non-ArcWeb layers...


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

There might be several stages of automation; my assumption is that the most
advanced, i.e., "I, mapserver executable, have never seen this WSDL before
now, but I'm going pick out the available SOAP requests, draw an association
between them and my mapfile constructs, build the requests on the fly,
interpret the responses on the fly, and build an output image from whatever
I encounter," IS COMPLETELY OUT OF REACH. (hello, semantics community, do
you concur?)

Lowest degree of automation, i.e., what I actually did in 06: capture SOAP
requests and responses with a packet analyzer, reverse-engineer them into a
series of functions compiled into mapserver.  Painful.

More automation: examine the SOAP-based service manually via help docs et.
al., Manually identify the association between desired mapping requests and
the mapserver model.  Use some kind of WSDL extractor to generate skeleton C
functions that build requests and pick apart responses, then compile them
into mapserver.

Still more automation: is it possible to anticipate a number of different,
general models of making association between mapserver mapfile constructs
and a SOAP-based map service?  Then pre-compile WSDL processing into the
executable so that binary-only users can concoct the association between ms
and SOAP service entirely with mapfile values.

*** are there enough SOAP-based map services out there to make all this
effort worthwhile??? probably not...

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

I'd say, if OGC builds established SOAP interfaces to its standards, then by
all means it would make sense to have mapserver adopt them as its SOAP
server.  In the absence of such, we'd still have the advantage of being able
to declare what our SOAP service would offer and then build WSDL to reflect
that.  For example, would a SOAP interface mirroring much of what one is
able to do in Mapscript be useful to anyone out there...?



More information about the mapserver-dev mailing list