ADF to fully exploit the use of Web services for communicating with ArcGIS Server services. Directly as a developer with the ADF and ArcGIS Server, it is important to understand the use of SOAP and its relationship with the WSDL file with ArcGIS. This article describes some of the basics of working with Web Services, SOAP and WSDL with ArcGIS Server. After this article you must read some documents that explain how the ideas discussed here apply in relation to a specific ADF.

Web services applications can communicate via messages from different protocols. Because Web services means for communication between applications in the program itself is written in a programming language, is language-independent communications. XML is the format used to maintain present information about applications. XML messaging via SOAP (Simple Object Access Protocol). SOAP defines a header and a valid means of message exchange. This exchange of messages is usually via HTTP, but actually a protocol such as SMTP, FTP, or DCOM, to be known. SOAP, XML, and wrap the message so that the applications received and processed they can be transferred appropriaptely.

WSDL, but also explains what Web services do not, what methods it has, what parameters and the guy who knows how you and the port used for communication. WSDL defines the valid content of XML SOAP messages are transmitted. WSDL is a specification, such as IDL, interfaces and parameters to describe the Web. The available methods are usually together in “port”, which can be viewed as a Web destination for the various activities they are interested in groups. A WSDL may contain one or more ports. Has the WSDLs provided by ESRI, a single interface for WSDL. For example, all methods show the MapServer WSDL recorded as part MapServerPort. Another feature of the Web service described in WSDL that specifies a protocol for sending messages, and optionally the URL of the corresponding server. WSDL specification does all this work in a very general, so that the toolkit in various languages, such as the Axis in Java, to generate code from WSDL descriptions.

WSDLs and ArcGIS Server
If you are in the installation directory under the XmlSchema found eight WSDL file. Each fits the description of the ArcGIS Server Web service can publish. Each WSDL corresponds roughly with the ArcObjects classes, for example, corresponds to the object MapServer.wsdl MapServer and GeoDataServer.wsdl GeoDataServer consistent with the object. Because Web services are usually only text messages (XML) to send between applications, there are differences in method signatures and data types from WSDL and ArcObjects. If you are open GeocodeServer.wsdl there are two major stages, you need to understand. The first part is <types> element and the second part is an element PortType.

Value of the items
<types> All the elements that defines the data type for WSDL, and valuables. This section contains definitions for all elements that are used as parameters to a web service method to pass. Object value can consist of objects of value, but at the end of the “end” must be a valid data type schema type such as String, int length or XML data. When a Java toolkit for the sale of all classes of the Java-like element in the WSDL Java objects of value, as the old Java objects (POJOs). For example, if you look at the point in the WSDL Look, this is an XML representation of a point sufficient to ArcObjects Web service operation:

<xs:complexType name=”PointN”>
<xs:complexContent>
<xs:extension base=”Point”>
<xs:sequence>
<xs:element name=”X” type=”xs:double”/>
<xs:element name=”Y” type=”xs:double”/>
<xs:element name=”M” type=”xs:double” minOccurs=”0″/>
<xs:element name=”Z” type=”xs:double” minOccurs=”0″/>
<xs:element name=”ID” type=”xs:int” minOccurs=”0″/>
<xs:element name=”SpatialReference” type=”SpatialReference” minOccurs=”0″/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

The Javadoc for the class generated using the AXIS toolkit, shows a Java class which is very similar to a POJO. From the WSDL definition we can see that M, Z, ID, and SpatialReference are not required properties since their minOccurs attribute is equal to 0. Therefore when you need to use a PointN value object you can create it using the default construct, set the X and Y, and then pass it as a parameter. There is no need to create the object on the Server Context, it is created on the local machine. When you are setting the object’s properties since they are set locally no remote call is made to the ArcGIS serverl.

Port Usage

Inside the <portType> element is the listing of all the methods that can be called on the web service. For example, one of the calls you can make is ReverseGeocode, which takes a point and figures out the closest address.

<operation name=”ReverseGeocode”>
<input message=”e:ReverseGeocodeIn”/>
<output message=”e:ReverseGeocodeOut”/>
</operation>

There is a definition for the input message (the input parameters) and the output message (the returned values) in another section of the WSDL. In this case they are defined earlier in the file as <message> elements, which are then mapped to <types>. Through this mapping you can see that a ReverseGeocode input message contains a location, which is a point, a boolean to indicate if intersections should be returned, and some properties in a PropertySet

<xs:element name=”ReverseGeocode”>
<xs:complexType>
<xs:sequence>
<xs:element name=”Location” type=”Point”/>
<xs:element name=”ReturnIntersection” type=”xs:boolean”/>
<xs:element name=”PropMods” type=”PropertySet”/>
</xs:sequence>
</xs:complexType>
</xs:element>

When the WSDL is used to generate Java proxies through AXIS a class will be generated named GeocodeServerPort which contains all the methods you can call on the ArcGIS Server GeocodeServer object using web services. The GeocodeServerPort object is instantiated in the local JVM but any method call on this class will execute a remote call to the server. Any object returned from the server will be a value object and therefore accessing its properties will not require calls to the server. Therefore, the only methods in the Java classes generated from the WSDL which make remote calls will be those methods exposed on a *Port object.

Implications for ArcGIS Server Developer

Using SOAP has several advantages for ArcGIS Server developers. The greatest advantage is that the value objects are Java objects in the local JVM. Because they reside in the local JVM and they are pure Java they are easier to debug and work with in general. Another serious advantage is that the only remote calls are those on the *Port objects. When using ArcGIS Server with the server API, each call to set a variable or execute a GIS operation is a remote call. Because the value objects are in the local JVM all calls to their mutators are local calls. When you call one of the methods on a *Port object you pass the value object as a parameter. The returned objects are also value objects, so retrieving values from this object are local calls as well. This overall reduction in remote calls greatly increases the performance of your application.

Here is an example which comes from the example below. It uses Value objects and the MapServerPort to query the count of features in a layer in the map. Using the server API every method call, from creating the envelope to the query feature count call would be a remote method call.

// The envelope is a value object so this constructor is not a remote call
EnvelopeN env = new EnvelopeN(webExtent.getMinX(), webExtent.getMinY(), webExtent.getMaxX(), webExtent.getMaxY(),
null, null, null, null, null);
// make a spatialfilter value object with the required parameters – none of these method calls are remote
SpatialFilter spatialFilter = new SpatialFilter();
spatialFilter.setFilterGeometry(env);
spatialFilter.setSpatialRel(EsriSpatialRelEnum.esriSpatialRelIntersects);
spatialFilter.setWhereClause(“”);
spatialFilter.setSearchOrder(EsriSearchOrder.esriSearchOrderSpatial);
spatialFilter.setSpatialRelDescription(“”);
spatialFilter.setGeometryFieldName(“”);

int layerId = layer.getId();
//because queryFeatureCount is found on the MapServerPort the call to queryFeatureCount goes back
//to the server which can throw an RemoteException
try {
numberOfFeatures =  mapServer.queryFeatureCount(mapServer.getDefaultMapName(), layerId, spatialFilter);
} catch (RemoteException e){}

There are also some drawbacks, especially for current ArcGIS Server programmers. Because of the requirements of the WSDL using simple types and the way different toolkits generate default values, some of the generated objects need more properties set before the methods will work. For example, using an Element for custom graphics needs to have its color set when using SOAP but not using the Server API. The implications of this for current ArcGIS Server developers is that your code will not translate directly and that you may have to set more values before the method call.

Now that you have basic understanding of the ArcGIS Server web services, you can go on to reading about how these generated Java proxies are used in the Web ADF and the Enterprise ADF. The Javadoc for the generated Java proxies can be found by themselves or as part of the Javadoc for the Web ADF and the Enterprise ADF

The custom command and tool example shows using the Value objects and Port calls.