Showing posts with label arcgis. Show all posts
Showing posts with label arcgis. Show all posts

Saturday, January 24, 2009

Consuming ArcGIS Server SOAP services in Silverlight 2.0

Microsoft's Silverlight platform offers yet another application environment in which to consume SOAP services. The Silverlight platform is truly tantalizing - the ability to blend\mash\mix services and data with a rich user experience in a web client is undeniably sexy and powerful. Unfortunately some of the backend plumbing still needs to be worked out. This includes Silverlight's ability to consume SOAP services, let alone ArcGIS Server's SOAP service stack. Sure, everyone's talking about REST and WCF, but W3C standard, contract based, explicitly typed interaction with SOAP services is still prevalent - just take a look at the recent release of the Virtual Earth Web Service SDK.

So how do you consume a SOAP service in a Silverlight application or class library? Once you install the Silverlight tools with Visual Studio (or Web Developer) 2008 sp1 you will be provided with a context menu item off the project in Solution Explorer. The item is named "Add Service Reference" and opens a dialog box for a developer to define the endpoint to a service (WCF,SOAP) and a namespace for the native client types that will be generated.



This capability is synonymous with the "Add Web Reference" capability for SOAP services in standard .NET projects. A single url to a WSDL is used to construct a SOAP proxy and a set of value object types. This provides a nice interface for one-off services, but if you have a set of services that share value object types and you want to generate a single library with a single namespace, you need to use a command line tool. This is possible with the NET 2.0 and 3.5 SDKs which include the web service utilities wsdl.exe and svcutil.exe, respectively. Note, wsdl.exe output is supported in .NET 2.0 - 3.5. Unfortunately Silverlight does not provide the same or similar utility. Before Silverlight 2.0 final was released, a utility named slwsdl.exe was available for this purpose. Unfortunately it was removed from the 2.0 final release for reasons unknown. In addition, the output from wsdl.exe and svcutil.exe will not work with Silverlight applications. Both wsdl.exe and svcutil.exe generate references to types that are not available in the Silverlight platform. Problematic type references generated in svcutil.exe output can be removed so reference code can actually be built as a Silverlight class library. Unfortunately the proxy class includes both synchronous and Begin\End asynchronous methods. Neither pattern is supported in a Silverlight application. In fact, the Silverlight "Add Service Reference" tool only generates Async\Completed asynchronous methods, which is the "promoted" pattern for event-based asynchronous programming. Apparently there is no way to trigger svcutil.exe to only generate the appropriate asynchronous methods for Silverlight and synchronous methods are not officially supported in Silverlight, apparently due to cross-browser support issues.

So with all this in mind, how can you generate a single library that contains all the proxy classes and value object types for all ArcGIS Server service types? It’s hokey, but you need to manually merge all WSDLs into a single WSDL – being careful to place the element types in the same locations (e.g. element vs. operation, etc.). You only need to do this once since the library you generate will be distributable thus reusable for all Silverlight applications\libraries. In fact, the sample included with this post includes the reference class file generated from this process, so you don’t need to mess around with the ArcGIS Server WSDLs – just download the sample and compile the ArcGIS_SOAP_Silverlight project. Or just use the precompiled ArcGIS_SOAP_Silverlight.dll in the bin folder.

The sample is available here.

The sample also contains a Silverlight application that illustrates a simple use case for consuming an ArcGIS Server dynamic map service and navigating the map. Left mouse click on the map zooms in, Shift+left mouse click zooms out. Note you’ll need Visual Studio 2008 sp1 and the Silverlight tools to load and build the projects in the solution (see http://silverlight.net/getstarted for more info). You can give a test run below. It's designed to be instructive, so it's pretty simple.



One additional note, the Web site that hosts the ArcGIS Server services must have a clientaccesspolicy.xml(Silverlight) or crossdomain.xml(Flex) in place to support cross domain\site requests. Silverlight will work with either. If using crossdomain.xml the following entry will enable SOAP interaction for all consumers:

<allow-http-request-headers-from headers="*" domain="*">

Sunday, November 2, 2008

ArcGIS Server: Expose a custom server object extension via SOAP

Extending ArcGIS Server using ArcObjects can take two forms: a utility COM object or a server object extension. A utility COM object is simply a COM component created and managed explicitly in server context. A server object extension (SOE) is coupled with a server object and thus can share initialization, resource utilization, and disposal. Use of a COM utility has been possible since the first version of ArcGIS Server (9.0). Custom SOEs were introduced for ArcGIS Server .NET at version 9.2. ArcGIS Server Java does not offer an SOE solution at the moment, but it is likely forthcoming. The reasons for extending ArcGIS Server and differences between both techniques are available elsewhere so I'll skip that discussion here. I want to discuss exposing ArcObjects logic in a custom server object extension via a prepackaged ArcGIS Server Web service handler. Two major protocols are supported, SOAP and REST. Let's dive in...

The ArcGIS Server SOAP API is implemented at the server object level. This means that SOAP messages are processed directly by a server object or extension (SOE). The ArcGIS Server SOAP Web service handler directs SOAP messages to a server object for you. The ArcGIS Server REST API is not implemented at the server object level. The ArcGIS Server REST Web service handler processes restful requests and (in general) uses the ArcGIS Server SOAP API to communicate with ArcGIS Server. How does this relate to exposing a custom SOE as a Web service? The SOAP Web service handler contains logic to discover custom SOEs with a SOAP interface (see sample and discussion below). The REST Web service handler does not contain the logic to discover custom SOEs at this time. Consequently, to expose a custom SOE as a REST service you’ll need to create your own Web service to handle restful requests and work with the SOE. Unfortunately this means you'll need to work with ArcObjects remotely in the Web service logic, which will require an ArcGIS Server license in the app-tier... a less than optimal solution. The folks at ESRI who work on the REST handler may resolve this in the future.

I've included a sample that illustrates how to expose a custom SOE via the ArcGIS Server SOAP Web service handler. It builds on the current
Server SDK sample which shows how to create a simple SOE.

I’ve modified this sample to illustrate how to support exposing a custom SOE using an ArcGIS Server Web service endpoint. The sample is merely instructive, so it just provides the basics of custom SOE development. To expose a WSDL for the custom SOE and make it available via an ArcGIS Server Web service endpoint, create a WSDL and put it in the \XmlSchema folder on the machine where the SOM is running. The name of the registered server object extension and the name of the *.wsdl file must be the same. To process SOAP requests, implement the IRequestHandler and IRequestHandler2 interfaces in the custom SOE class. In this example, the implementation code parses the incoming SOAP request and generates a raw SOAP response string. The response should match the WSDL definition.

Download the sample here.

Everything is pretty raw and simple at the moment, but it works. I’m sure there’s a better way to create the WSDL and generate SOAP responses, but that’ll take some additional research. Once the custom SOE is deployed and enabled on a map service, you can use the following url to get the WSDL: http://localhost/arcgis/services/<service name>/MapServer/SimpleSOE_CSharp?wsdl