Migrating to 9.3.1


Summary The most important feature in ArcGIS 9.3.1 that has a migration impact is the new ArcGIS Java WebServices toolkit. A vast majority of ArcGIS Server’s clients use Web services to consume the server’s capabilities. Among these clients, the WebADF and Representational State Transfer (REST) serve as the foundation for building applications that bring ArcGIS to the Web.

Having an optimized Simple Object Access Protocol (SOAP) stack in these clients is paramount for performance. Until ArcGIS 9.3, Java clients used Apache’s Web services toolkit called Axis as the SOAP stack. When ESRI adopted Axis, it was the most robust toolkit available.

Things have changed considerably in the recent past with Sun putting its weight behind a new Web services toolkit standard known as JAX-WS (Java application programming interface [API] for Extensible Markup Language [XML] Web Services). However JAX-WS could not fit into the JavaADF model efficiently. Initial load time and memory size does not fit with the WebADF or REST model. Each Stub object takes about 6MB and load time is around 4.5 seconds per user. JAX-WS runtime libraries were too large (for example, webservices-rt.jar was about 12MB). Also, Web application server related issues prevented the use of the JAX-WS stack.

The preceding issues resulted in developing a custom SOAP toolkit leveraging JAX-B as the Java XML binding technology called the ArcGIS Java WebServices toolkit.

In this topic


Migrating to the ArcGIS WebServices toolkit

At ArcGIS 9.3.1, all new applications created through ArcGIS Manager or the Eclipse/Netbeans plug-ins will use the new ArcGIS Web Services (AgsJWS) toolkit. To upgrade existing applications to the new stack, users will need to redeploy them if they exist in Manager or manually update them as follows if they exists outside of Manager:
  1. Copy the 9.3.1 Java Archive (JAR) file, Javascript, Cascading Style Sheets (CSS), Java, Images, Properties, Extensible Style Language (XSL), and XML files from <ARCGISHOME>\java\web\webcontrols and <ARCGISHOME>\java\web\web_mapping_application folders into the appropriate folders for the Web application’s project or Web Application Archive (WAR) file. This process is similar to upgrading Web applications to a newer service pack.
  2. Remove the following Axis specific libraries from the application's WEB-INF\lib folder:
    • axis.jar
    • axis-ant.jar
    • axis-schema.jar
    • wsdl4j-1.5.1.jar
    • saaj.jar
Users that use the Java Web Service API directly outside of the Java Web Application Developer Framework (ADF) Web Mapping application, need to replace the Axis specific libraries previously mentioned with the new ArcGIS Java Web Service dependant libraries. The following libraries are located under <ARCGISHOME>\java\web\webcontrols\WEB-INF\lib and are required for direct Java Web Service usage: 
  • activation.jar
  • arcgis_agsws_stubs.jar
  • arcgis_ws_runtime.jar
  • commons-codec-1.3.jar.
  • commons-httpclient-3.0.1.jar
  • commons-logging-1.0.4.jar
  • jaxb-api.jar
  • jaxb-impl.jar
  • jsr173_1.0_api.jar
For more information about the WebADF runtime files, see Java WebADF Runtime Files and Components
No further steps are required for migrating an out-of-the-box Web mapping application to the new AgsJWS toolkit. However, if the application contains customizations that directly invoke the ArcGIS Server SOAP APIs, users might need to make minor changes to their application code to accommodate the new AgsJWS stack as follows:
  • The old SOAP API used to throw java.rmi.RemoteException or org.apache.axis.AxisFault. The new SOAP API throws java.lang.RuntimeException.
  • The old SOAP API used classes (and string constants internally) for enumerations, such as EsriImageFormat. The new SOAP API uses Java enums.
  • The old SOAP APIs used org.apache.axis.types.UnsignedByte types shorts for elements of the type xs:unsignedByte in the WSDLs, for example, RGBColor::setBlue(). The new SOAP API uses primitives.
  • The SOAP API used java.util.Calendar for dates. The new SOAP API uses javax.xml.XmlGregorianCalendar.
  • The old SOAP API used ArrayOfIntHolder and ArrayOfDoubleHolder classes. The new SOAP API replaces these with a Holder class.
Even though every attempt has been made to make the new AgsJWS stack-based SOAP APIs appear similar to Axis-based APIs for the purpose of maintaining backwards compatibility, many Axis-specific API artifacts are being deprecated wherever possible to encourage users to adopt new techniques and practices. These deprecated artifacts will be removed at the next version of ArcGIS to complete the transition from Axis to the new AgsJWS stack. For example, see the following:
  • The parameterized constructor of ***ServerBindingStub objects is being deprecated to encourage users to change from and to the following code example:
[Java]
// Change from the following:

MapServerBindingStub stub = new MapServerBindingStub(URL, null);

// Change to the following:

MapServerBindingStub stub = new MapServerBindingStub(url);
  • The parameterized constructor of SOAP value objects is being deprecated because the signature of the constructor changes when a new property is introduced on the object. Users should change from and to the following code example: 
[Java]
// Change from the following:

Record record = new Record(values);

// Change to the following:

Record record = new Record();
record.setValues(values);
  • When sending SOAP over Distributed Component Object Model (DCOM), users should change from and to the following code example:
[Java]
// Change from the following:

mapServer._setProperty(org.apache.axis.client.Call.TRANSPORT_NAME,
    AGSLocalTransport.AGS_LOCAL_TRANSPORT_NAME);
mapServer._setProperty(AGSLocalSender.AGS_LOCAL_HANDLER, serverobject);
mapServer._setProperty(AGSLocalSender.AGS_LOCAL_CAPABILITIES, capabilities);

// Change to the following:

mapServer.setSoapOverDCOM(serverobject, capabilities);
  • When setting parameters, such as username, password, and referrer, users should change from and to the following code example:
[Java]
// Change from the following:

mapServer._setProperty(javax.xml.rpc.USERNAME_PROPERTY, username);
mapServer._setProperty(javax.xml.rpc.PASSWORD_PROPERTY, password);
mapServer._setProperty(ADFFilter.HTTP_REFERRER, referrer);

// Change to the following:

mapServer.setEndPointAddress(URL, userName, password);
mapServer.setHttpReffer(referer);
  • All ESRI constants do not have "_" static members. For example, EsriJobStatus has _esriJobCancelled, _esriJobExecuting, _esriJobSucceeded, and so on. Static string members in Axis generated stubs. JaxB generated stubs do not have these members.

    If your Web ADF application uses Axis as shown in the following code example, you will have to change it while upgrading to the new ArcGIS Java WebService toolkit:
[Java]
// If your Web ADF uses Axis as follows:

if (jobStat.toString().equals(EsriJobStatus._esriJobSubmitted)){
    System.out.println("SubmitJob()");
}


// Change to the following while upgrading to the new ArcGIS Java WebService toolkit:

if (jobStat.toString().equals(EsriJobStatus.esriJobSubmitted.toString())){
    System.out.println("SubmitJob()");
}
  • The com.esri.arcgisws.holders package is no longer available. Instead, use com.esri.arcgisws.runtime.Holder class from the new ArcGIS Java WebServices toolkit. This is a generic class that can take any type.

    For example, if your Web ADF application has the following Axis based usage, change it in the new ArcGIS Java WebServices toolkit:
[Java]
// If the Web ADF has the following Axis based usage:

ArrayOfDoubleHolder areas = new ArrayOfDoubleHolder();
ArrayOfDoubleHolder lengths = new ArrayOfDoubleHolder();
geomStub.getAreasAndLengths(sf, polys, areas, lengths);


// Change it as follows in the new ArcGIS Java WebServices toolkit:

Holder < double[] > areas = new Holder < double[] > ();
Holder < double[] > lengths = new Holder < double[] > ();
geomStub.getAreasAndLengths(sf, polys, areas, lengths);
ArrayOfDoubleHolder and ArrayOfIntHolder are used only in MapServerBindingStub and GeometryServerBindingStub generated by Axis.
  • The usage of RemoteException has been removed.
  • The usage of UnsignedByte has been removed. All the Color objects in ESRI's custom SOAP stack take short values in place of UnsignedBytes.
  • The new ArcGIS Java WebServices toolkit uses XMLGregorianCalendar instead of java.util.GregorianCalendar. If there is a date type data field in the query results returned by MapServer, the date type field value is of type XMLGregorianCalendar as opposed to java.util.GregorianCalendar in Axis. Also, the following ArcGIS Java WebServices generated stubs take and return XMLGregorianCalendar as opposed to java.util.GregorianCalendar in Axis:
    • GPDate
    • NACompactStreetDirection
    • NAStreetDirection
    • NAServerRouteParams

Deployment

Every effort has been made to make the deployment of Web applications with the new AgsJWS stack transparent to the user.

The only necessary change is to add application server specific deployment descriptor files in the \WEB-INF\ folder for WebLogic 10.0 and Oracle Application Servers shown in the following code example, respectively:
If you are a WebLogic user, you do not need to make changes to your deployment descriptor file (weblogic.xml) if you are using WebLogic 9.2 or WebLogic 10.3. The change in the following code example is only required for WebLogic 10.0 users:
[XML]
<?xml version="1.0" encoding="UTF-8"?>
<!-- weblogic.xml -->
<weblogic-web-app>
  <container-descriptor>
    <prefer-web-inf-classes>true</prefer-web-inf-classes>
  </container-descriptor>
</weblogic-web-app>
[XML]
<?xml version="1.0"?>
<!-- Orion-web.xml -->
<orion-web-app
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/orion-web-10_0.xsd"
  deployment-version="10.1.3.0.0"
  jsp-cache-directory="./persistence"
  jsp-cache-tlds="standard"
  temporary-directory="./temp"
  schema-major-version="10"
  schema-minor-version="0">
  <web-app-class-loader search-local-classes-first="true"/>
  <web-app/>
</orion-web-app>
  • The presence of these files does not affect deployment to other application servers.






Development licensing Deployment licensing
Server Server