Category: Developer

Custom Task to consume SOE

At 9.3.1, we introduced Server Object Extensions (SOE) in Java.  Java SOE’s offer developers an opportunity to encapsulate low level GIS functionality in desktop or web applications.  In the ArcGIS Server Java Development Help System we document two approaches to consuming SOE’s in a console application and in a web application.  In our web application approach, we document using a Java Server Faces (JSF) managed bean pattern where the business logic, SOE, is applied to a command button component in an action listener.  This pattern does not directly depend on the Java Web ADF, but it can be used to extend a Web ADF application.  To take advantage of patterns the Java Web ADF offers, we will take a look at extending the Java Web ADF Task Framework to consume a SOE using the Hello World SOE Developer walkthrough

 The Web ADF Task Framework is an extensible architecture where you can integrate and deploy custom functionality as “Web tasks” within a Web ADF application.  Creating a Custom Java Web ADF Task that consumes an SOE involves the following steps once you have successfully deployed the Hello World SOE:  

  1. Include the SOE jar File in your Web ADF libraries
  2. Create a Java Task Class to consume the SOE
  3. Register the Class as a Managed Bean
  4. Add the task control to the JSP page with a reference to the managed bean

Include SOE Jar File

Copy the HelloWorldSOE jar file into the WEB-INFlib folder of your Web ADF application so that you have local access to the SOE business object in your WEB ADF application. 

Create a Java Class to consume the SOE

To work with our HelloWorld SOE, we will want to create a command, or action, task and send the return to the Results panel.  Commands allow you to execute business logic in your SOE without any user interaction with the map.  To create a Web ADF Task, you can either manually create a Java class file and associated TaskInfo classes or use a supported developer IDE like Eclipse to stub out all your Task Class artifacts.  Once you have your Task Class created, implement the following method: 

  public void getMessage(TaskEvent event) {
    System.out.println(this.getClass().getName() ":getMessage()");
    try {
      // Get a handle to the Local ArcGIS Service
      AGSLocalMapResource resource = (AGSLocalMapResourceevent.getWebContext()
      // Get a handle to the SOE
      IServerObject so = resource.getServerContext().getServerObject();
      IServerObjectExtension soe = ((IServerObjectExtensionManagerso)
      IHelloWorldSOE hwSoe = (IHelloWorldSOE)soe;
      // Invoke the HelloWorld SOE
      String soeReturn = hwSoe.helloWorld();
      // Add attributes to a list to send to WebResults
      List<String> values = new ArrayList<String>();
      String id = "" + System.currentTimeMillis();
      values.add(id)// Unique identifier
      values.add(soeReturn)// SOE Message
      // Add a List of results to the WebResults object
      WebContext context = event.getWebContext();
      WebResults results = context.getWebResults();
      results.addResults"SOE Message",  values );

    catch (Exception e) {

Let’s explain the method code above.  First we need to get a handle to the Map Service which the SOE is enabled on.  In the WebADF, we can get this from the named resource in our faces-config file.  In our case the resource is named ‘ags1′ and we use a Local Connection to cast to.  Once we have the Map Service, we can get access to the associated Server Object and we can gain access to extensions with the method findExtensionbyTypeName( <soename> ).  The return object from this method call can be collected by IServerObjectExtension and this reference can be used to call a method on the SOE. At this point in our simple example, we just want to display the return from our SOE in our application.  We can easily use the WebADF Results Panel to post the return message.  The WebResults object is maintained by the WebContext and can be accessed via the WebContext.getWebResults() method.  The result objects that you add to WebResults can provide up to 4 types of information.  We will use the addResults() method to add a Results Header and the result data supplied as a java.util.List object.  That is all the code required to access our SOE and send the response to the Results Panel.  We take advantage of the simplicity of both the SOE and the Web ADF Framework in this pattern. 

Register the Class as a Managed Bean

When your Task code is complete, you need to register it as a managed bean. If you used a supported developer IDE, the Task template process created these entries for you.  If not, you can manually do this by opening the faces-config.xml file in your WEB-INF folder and scroll down toward the end of the file and append the following tag content below the last managed bean. 


And add the following as a map-entry under the root mapContext managed bean:


Add the task control to the JSP page with a reference to the managed bean

The final step in the process is to add the task control and link to your jsp page.  Open your mapviewer.jsp file and add the new task control to the list of tasks in your application.  The task tags are typically toward the bottom of the mapviewer.jsp file in the WMA.  Note, our task control assumes an associated TaskInfo class was created and links it appropriately here. 

  <!-- New SOE Task Tag in the JSP File -->
  <a:task id="helloWorldTask" value="#{mapContext.attributes.helloWorldSvc}"
taskInfo="#{mapContext.attributes.helloWorldSvc.taskInfo}" mapId="map1" />

Now add a task link to the ‘task-menu’.  In your WMA mapviewer.jsp file you will see this <div> tag content holding the applications Search Attributes task.

    <li class="menu-bar">
    <a href="#" class="menu-header" title="SOE Task" onclick="toggleWindow('win_EsriTaskCell_helloWorldTask');">
      <span>Hello World SOE</span>

 Run your application

 You nave now completed the steps to implement your custom task which consumes the HelloWorld SOE.  You can now deploy and run your application to see it work.  Once the application loads, you should see your ‘Hello World SOE’ link at the top of the Task Menu bar.  When executed the results are sent to the Results Panel as shown below: 


Consume your SOE in the Web ADF Task Framework

The Web ADF Task framework offers vast flexibility for you to consume your SOE’s in your web application.  The framework provides a mechanism that lets you focus on working with SOE’s instead of being concerned with low level implementations in your web application. 

Posted in Developer | Tagged , , , | Leave a comment

Resources for Getting Started with ArcGIS Server Web APIs

We’ve had quite a few requests from developers new to our JavaScript, Adobe Flex and Microsoft Silverlight APIs asking for pointers on where to start. There is a lot of good content out there, sometimes it exists in places you might not have thought to look.

The best place to start is in the Resource Centers. Each API has a dedicated Resource Center that contains a treasure trove of code samples, as well as concept docs, complete API reference, videos (Media Gallery) and community contributed sample apps (Code Galleries).

Read through the Concepts section, walk through all the code samples, and read the explanations. Each Media Gallery has full-length DevSummit tech session videos that offer an experience similar to taking an online course. And, be sure to subscribe to the Forums via RSS so you can get a feel for the types of questions that are being asked.

We have also pulled together a list of Hello World tutorials, introductory classes, articles and videos. The links are below. If you know of any other good getting started links that we may have left out or are new, be sure to post a comment and share them with the rest of the community.

ArcGIS API for JavaScript

ArcGIS API for Flex

ArcGIS API for Microsoft Silverlight/WPF

ArcGIS Server Services


Last but not least, there is also playlist on Youtube called ESRITV that contains short, Channel 9-style videos. These include behind-the-scenes interviews with the dev teams, as well as instructional, how-to videos.



Posted in Developer | Tagged , , , | Leave a comment

New Products, Websites, Community Resources, Samples, Videos…

As you may have noticed, there has been a lot of activity at ESRI these days.  So just to keep you up to date, here’s a quick list of what’s new and where to find it.

New MapIt Product (product info, demos and videos)

New MapIt Resource Center

Updated Silverlight/WPF API Resource Center 

New ArcGIS Explorer Release (learn what’s new)  

Updated ArcGIS Explorer Resource Center

Don’t forget to update your RSS feeds!

EDN Team

Posted in Developer | Tagged , | Leave a comment

ArcObjects Java, Swing/AWT…..but what about SWT?

I like Swing a lot. Am I a rationally-thinking programmer? Ha! No. But I like Swing for a number of my own reasons. Let me share:

1. Swing is guaranteed to run on any JVM. No special installations or special JVMs.

2. Swing is rich with so many components and events, richer than AWT. Uh, do I understand ALL of the models and events and patterns here? No.

3. The tooling for Swing is terrific. Eclipse and Netbeans both have great tools for Swing development. I like tools. I need tools.

4. Swing is “top-to-bottom” and ”bottom-to-top”: I don’t need to create a JPanel or JFrame before creating a JButton, or visa versa.

I do understand that there are drawbacks to using Swing as well. For starters:

1. Swing applications with heavy UIs may run a bit slow on certain platforms.

2. Swing look and feel may not always be consistent across all platforms

3. more….

SWT (The Standard Widget Toolkit) is a different beast when it comes to building UI-rich cross platform applications for the desktop. It is also a strong platform for doing what Swing and AWT do as windowing toolkits, but tries to fill the voids that Swing and AWT leave us with.

1. Swing and AWT do not render “native” widget components. SWT does use native widgets for a natural “look and feel”

2. Because Swing/AWT to not use the native widgets found on different platforms, the abstraction can cost you in performance. SWT is more native, and can perform better, as it provides the thinest possible widget support, natively, for the widest range of platforms. But care must be take when developing for specific platforms.

There are many compelling reasons for organizations to choose the RCP/SWT/Eclipse platform for their application development and maintenence environments.

OK. We have some development choices and options out there for rich Java Desktop applications. Excellent. But here is some harsh reality: SWT and AWT do not mix. Can SWT and AWT widgets co-exist in the same application? Not very well, but it can be accomplished with a little help from the SWT-AWT bridge and some complex development approaches. Here is an interesting article that goes into depth on this topic, outlining the pitfals and angst that can be experienced in trying this.

So, what does this mean for ArcGIS Engine Java developers? The high-level UI developer components that ship with the Java SDK for ArcGIS Engine are based on AWT. Period. These components have never been successfully tested in SWT or “mixed” application development environments.

What I strongly encourage Java Engine developers to do is this: avoid trying to mix SWT with ArcGIS Engine application development at all costs. At the current release, this usage will not be supported. ESRI will look into this for possible consideration later on, but at the present time, please don’t go there!

So, have fun on the Swing-set, and don’t hurt yourself!

Posted in Developer | Tagged , , | 5 Comments

Extending ArcGIS with Java

Extending ArcGIS is one of the most important features that
was released at 9.3.1. We tried hard to extensively document this new feature
and you will find most of the information in the help topics. So, I have jotted down some quick notes to get you started: 

The ability to extend ArcGIS using POJOs was introduced at 9.3.1. But, what does that mean? It means that you can add new custom functionality to ArcGIS applications using POJOs. How can you, the ArcGIS Engine/Server/Desktop/Geodatabase developer take advantage of ‘Extending ArcGIS’ feature?

An ArcGIS Desktop developer can 

  • Create custom Geoprocessing tools to accomplish specific GIS tasks. You can add the custom tool to any toolbox in ArcToolbox or chain it with other Geoprocessing tools in ModelBuilder. Since the custom Geoprocessing tool is built using POJOs, you can easily leverage external Java libraries in your tool to perform GIS tasks.
  • Create custom
    Feature renderers
    and access it through Desktop UI dialogs like other in-built feature renderers in ArcMap. Feature renderers allow you to symbolize the point/line/polygon data in a map. You can create your own renderers to symbolize the geometries specific to your data 
  • Create Plug-in data sources to integrate external data formats with ArcGIS and hence manage them through ArcCatalog or add them as a layer.

An ArcGIS Server developer can

An ArcGIS Engine Developer can

  • Create custom feature renderers that can be accessed and persisted to MXD documents programmatically.
  • Create and consume custom Geoprocessing tools through Geoprocessing APIs in their application.
  • Create plug-in data sources to integrate external data formats not supported by ArcGIS and access them programmatically using Geodatabase APIs in their applications. 
  • Create Utility objects to improve the performance of applications built
    using ArcObjects Java API (a.k.a. ArcGIS Engine applications)

A Geodatabase developer can

  • Create Class extensions to define data behavior in a geodatabase. Translation- you can define rules, alerts and actions that are triggered on data creation, modification and deletion.

You must also bear in mind; the ‘Extending ArcGIS’ using POJOs is limited to creating Geoprocessing Tools, Feature Renderers, Class Extensions, Plug-in Data Sources and the most famous Server Object Extensions only.
We have authored a short video on ‘Extending
’ and have posted it to the ArcGIS Developer Media
. In the video, Jim presents a very simple and straight forward introduction to ‘Extending ArcGIS’. By the way, the ability to extend ArcGIS, was available well at 9.0. However, the extensibility workflow was tedious – you must write C++ code using ArcObjects C++ APIs, generate proxies using Proxygen tool and access these proxies in your Java code to add custom functionality. But
now at 9.3.1, we have made the Java-Interop much smarter and it is possible to extend ArcGIS by creating POJOs and deploying them to

Our developers went back to the whiteboard several times to simplify the development/deployment workflow and present a native Java development experience. The development workflow is to create a POJO that implements specific ArcObjects interfaces and annotated with @ArcGISExtension annotation appropriately. The deployment workflow is even simpler, you must bundle the POJOs into a JAR file and drop them in %ArcGISHome%/java/lib/ext folder and when you launch the ArcGIS applications next time, the extensibility will be available for you to consume.

The help topics and samples are hosted on the resource center under Extending ArcGIS SDK. You can also watch the
DevSummit 2009 tech workshop videos on
Extending ArcGIS with Java and
Extending ArcGIS Server with
. You can also read Dan’s and David’s Server Object Extension blogs.

Posted in Developer | 3 Comments

ArcGIS Developers Tip #5: Working with Graphic Coordinates in ArcGIS API for Flex

As an ArcGIS API for Flex developer, knowing the basic differences between Stage, Point and MapPoint will save you a lot of time when you need to use geometry or shapes in your applications. The bottom line is every Flex display object has its own coordinate space which is essentially a graph upon which you can plot locations.

Stage represents the entire area where all Flash content is displayed. Stage coordinates start at the origin (0,0) or top left hand corner of the main drawing area, and are sometimes referred to as global coordinates. Stage coordinates can be used for such things as determining the location of a MouseEvent on a web page, or a map.

Point represents a set of x,y coordinates contained by a display object, with the top left hand corner of the display object being 0,0.  A Point can be represented in either Stage coordinates or  local coordinates. Local coordinates reside within a child display object, such as an instance of the ArcGIS API for Flex Map component.

Also, since both Stage and local use the Point object, be aware when converting between these two Adobe coordinate systems, and use well defined names to help keep things straight. Another item to keep in mind is the ArcGIS API for Flex Reference Doc refers to local Points as “screen points”. 

MapPoint represents an x,y location on a map. The x,y coordinates are in the same units as the ArcGIS Server map service; such as esriDecimalDegrees (lat/lon). 

To help determine the position of locations on a map, you can convert between Stage, local and MapPoint coordinates. Fortunately, there are already built-in methods for doing this:

ArcGIS API for Flex:

Adobe Flex:

The screenshot above shows the differences between Stage, a local Point (or screen point) and MapPoint. As an example, local Point 0,0 could also be translated into Stage Point 30,20 or MapPoint (Lat/Lon) of 64.9, -15.3.

You can also download and try out a sample Flex app that demonstrates these concepts.

Additional References:

ArcGIS API for Flex Resource Center 

Basics of Geometry and ActionScript 

Discussion on Point Objects 


Posted in Developer | Tagged , | 1 Comment

Creating an AgsJWS web application with Wicket Framework

Let’s build our first AgsJWS web application.  The AgsJWS API is a low level API for working with ArcGIS Server Web Services through published WSDL endpoint URL’s.  This makes the API easy to integrate into existing frameworks which simplifies web application development.  POJO data models make good sense when working with low level API’s and Apache Wicket provides a good POJO framework which makes developing web applications simple and enjoyable.  While this post will assume some knowledge of the Apache Wicket framework, if you are new to the framework you can read more about it here

Our application is going to extend on our previous post which described a console based application for displaying all services from an ArcGIS Server Service Directory.  In this post, we will turn that application into a web application using the Apache Wicket framework.  

In our example, we will put all the of the files in the same package directory.  This means that our markup files and java files will be in the same directory next to one another.

Each Wicket application is defined by an Application object.  The object defines the home page and allows for some configuration. 

package com.esri.agsjws.demo;

import org.apache.wicket.protocol.http.WebApplication;

public class CatalogServerApplication extends WebApplication {

    public Class getHomePage() {
        // TODO Auto-generated method stub
        return CatalogServer.class;


In our Application object, CatalogServerApplication, we defined the CatalogServer to be our home page.  When the base URL of our application is requested, the markup rendered by the CatalogServer page will be returned. 

package com.esri.agsjws.demo;

import org.apache.wicket.AttributeModifier;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.repeater.RepeatingView;
import org.apache.wicket.model.AbstractReadOnlyModel;

import com.esri.arcgisws.ServiceCatalogBindingStub;
import com.esri.arcgisws.ServiceDescription;

public class CatalogServer extends WebPage {

    // Constructor
    public CatalogServer(){
        // Get Version Info
        ServiceCatalogBindingStub catalog = getCatalogendpointURL );
        String version = catalog.getMessageVersion().toString();
        add(new Label("version", version));
        add(new Label("server", endpointURL));
        RepeatingView repeating = new RepeatingView"repeating" );
        // Get Service Info
        ServiceDescription[] sds = getServiceDesriptioncatalog );
        for (int i = 0; i < sds.length; i++) {
            WebMarkupContainer item = new WebMarkupContainer(repeating.newChildId());
            ServiceDescription sd = sds[i];
            item.add(new Label("ServiceName", sd.getName()));
            item.add(new Label("ServiceCapabilities", sd.getCapabilities()));
            item.add(new Label("ServiceType", sd.getType()));
            final int idx = i;
            item.add(new AttributeModifier("class", true, new AbstractReadOnlyModel()
                public Object getObject()
                    return (idx % == 1"even" "odd";
    public static ServiceCatalogBindingStub getCatalogString URL ){
        return new ServiceCatalogBindingStubURL );
    public static ServiceDescription[] getServiceDesriptionServiceCatalogBindingStub catalog ){
        return catalog.getServiceDescriptions();
    private static String endpointURL = "";

Here we integrate the console based CatalogServer class but instead of printing out to the console we are going to return our output to Wicket components to be rendered by a markup page.  First we print version and server url to Labels which take two parameters.  The first parameter is the component identifier and the second parameter is the message which the label should render.  

Next we need to iterate through our ServiceDescription and print them out in tabular form.  For this we use a WebMarkupContainer which allows us to dynamically add rows filled with Labels which we will populate with our Service Name, Capabilities, and Service Types.  I added a modifier to render alternating row colors for viewer clarity.  


The HTML that defines our CatalogServer functionality has two obvious points to discuss
1. The wicket component declaration in form of <span wicket:id=”server” id=”endpointURL”>
2. The message [endpointURL]

The component declaration is the Wicket identifier and the component identifier message.  The component identifier is the same as the name of the component defined as our WebPage, the CatalogServer class.  The text in between the <span> tags gets removed when the component renders its message.  The content which is rendered is determined by the CatalogServer class.


In order to deploy our web application we need to make it known to the application server through the standard web.xml file.  


We map our Application object, CatalogServerApplication, to the Wicket Filter which handles all requests.  We then provide the applicationClassName parameter linked to the fully qualified path to our CatalogServerApplication class to let Wicket know which application is available.  Also take note of the url-mapping to /*.  The Wicket filter will only process requests that are Wicket requests, everything else is ignored.  This ensures that static content will be served appropriately by the container.  


We can now create a WAR file for deployment to our Java Application Server.  There is no further configuration necessary.  Once deployed, point your browser to the url:  http://<servername>/<warfilename> where <servername> & <warfilename) map appropriatly such as, http://localhost:8080/CatalogServer.

We have now seen how to take a console based application and easily convert it into a web application using the Wicket Framework.  Integrating the AgsJWS API with Web Application frameworks is an easy way to make efficient use of the API.  The web application described here is the foundation for building a web enabled service catalog to accurately show which services are available from appropriate servers.  I have posted the full web application with source code to the Code Gallery for you to download, deploy, and extend. I encourage you to give it a try for yourself.   

Posted in Developer | Tagged , , , , | Leave a comment

Using ArcGIS Java WebServices API

Since the release of JavaEE 5, Java has become a powerful development platform for Service Oriented Architectures (SOA) as this release significantly enhanced the Web Services capabilities.  Most of these enhanced features were later included in the subsequent release of Java SE 6.  Of course Java supported Web Services through JAX-RPC 1.1 in J2EE 1.4, but the enhancements made in the latest versions of Java Web Services (JWS) API’s allow developers to more easily build enterprise class applications with Web Services. 

Up until and through the release of ArcGIS Server for Java 9.3, Java clients used Apache’s Axis implementation of the SOAP protocol.  Axis has proven to be a stable platform to implement Java Web Services, but in order to take advantage of the enhancements we looked into implementing the updated JWS stack at ArcGIS Server for Java 9.3.1.  Included in this stack is JAX-WS, the Java API for XML-Based Web Services, and JAXB, the Java Architecture for XML Binding.  Ultimately, JAX-WS did not fit our Java Web ADF model efficiently so we customized our own API based on JAXB called the ArcGIS Java WebServices (AgsJWS) API.  AgsJWS uses two XML-based W3C specifications, Web Service Description Language (WSDL) and SOAP to describe and communicate through a services based API.  The AgsJWS stack is provided by the ArcGIS Server for Java runtime and a vast majority of ArcGIS Server’s clients use it to consume the server’s capabilities. Among these clients, the WebADF and REST serve as the foundation for building applications that bring ArcGIS to the web.

To familiarize ourselves with the API, we will first get a description of services from an ArcGIS Server for Java services directory.  Then we will form a URL from one of the returned services to create a console based app to generate a Map Image. 

An ArcGIS Server instance maintains a list of services and their properties, such as name, type, and folder.  The Catalog service enables you to traverse and explore the services exposed by an ArcGIS Server instance.  Each instance provides one Catalog service.  An ArcGIS Server instance includes the ArcGIS Server Web services application to handle SOAP requests and responses.  The application is configured for use in a folder named “services”.   

 WSDL Syntax to send to the service directory is as follows: 


We will use ArcGIS Online Service Directory with the following WSDL syntax URL:

ArcGIS Server for Java Service Directory

public class CatalogServer {

    // Constructor
    public CatalogServer(){}
    public ServiceCatalogBindingStub getCatalogString URL ){
        return new ServiceCatalogBindingStubURL );
    public ServiceDescription[] getDesriptionServiceCatalogBindingStub catalog ){
        return catalog.getServiceDescriptions();
    public static void main(String[] args) {
        // Create CatalogServer object
        CatalogServer catalogServer = new CatalogServer();
        // Get the ServiceCatalogBindingStub
        ServiceCatalogBindingStub catalog = catalogServer.getCatalogendpointURL );
        // Print out basic information
        System.out.println("Version: " + catalog.getMessageVersion());
        System.out.println("requiresTokens: " + catalog.requiresTokens());
        System.out.println("TokenServiceURL: " + catalog.getTokenServiceURL());
        ServiceDescription[] sds = catalogServer.getDesriptioncatalog );
        for (int i = 0; i < sds.length; i++) {
            ServiceDescription sd = sds[i];
            System.out.println("Service Name: " + sd.getName());
            System.out.println("Service Capabilities: " + sd.getCapabilities());
            System.out.println("Service Type: " + sd.getType());
    private static String endpointURL =;

Running the CatalogServer class will result in the following condensed output to the console: 

Version: esriArcGISVersion93
requiresTokens: false
Service Name: ESRI_StreetMap_World_2D
Service Capabilities: Map
Service Type: MapServer

Your output will be much longer as there are many services available from ArcGIS Online.  We can now form a URL based on the Service Name returned to generate a Map Image using the standard ArcGIS Scheme for all SOAP Web Service URL’s: 


The URL for the ESRI_StreetMap_World_2D would look like the following:

The MapServerBindingStub.exportMapImage() method generates a dynamic map image from a data frame (map) in an ArcGIS Server map service.  

Export Map Image from Service Catalog

public class ExportMapImage {

    public ExportMapImage(){}
    public MapServerBindingStub getMapString URL ){
        return new MapServerBindingStubURL );

    public MapDescription getMapDescriptionMapServerBindingStub map ){
        MapServerInfo mapInfo = map.getServerInfomap.getDefaultMapName() );
        return mapInfo.getDefaultMapDescription();
    public ImageDescription getImageDescriptionImageType imgType, ImageDisplay imgDisplay ){
        ImageDescription imgDesc = new ImageDescription();
        imgDesc.setImageTypeimgType );
        imgDesc.setImageDisplayimgDisplay );
        return imgDesc;
    public static void main(String[] args) {
        ExportMapImage mapImage = new ExportMapImage();
        MapServerBindingStub map = mapImage.getMapendpointURL );
        MapDescription mapDesc = mapImage.getMapDescriptionmap );
        // Set the image format and return type
        ImageType imgtype = new ImageType();
        imgtype.setImageFormatEsriImageFormat.esriImagePNG );
        imgtype.setImageReturnTypeEsriImageReturnType.esriImageReturnURL );
        // Set the image size and resolution
        ImageDisplay imgdisp = new ImageDisplay();
        imgdisp.setImageHeight500 );
        imgdisp.setImageWidth500 );
        imgdisp.setImageDPI96 );
        // Send image format and size to return an ImageDescritipn
        ImageDescription imgDesc = mapImage.getImageDescriptionimgtype, imgdisp );
        // Export a map image and generate Map Image URL
        MapImage mapImageUrl = map.exportMapImagemapDesc, imgDesc );
        String mapUrl = mapImageUrl.getImageURL();
        // Print out the URL
        System.out.println"Map Image URL = " + mapUrl );

    private static String endpointURL = 

Return Value

Executing the ExportMapImage class will return a URL to a MapImage referencing the properties of the generated map image set in the class such as image width and height, map extent, map scale, and dpi.

Using the two classes above you can get a list of services from an ArcGIS Server Services Catalog and generate a map image from the services returned.  This will be the foundation for building web applications using the ArcGIS Java Web Services API.  

You can find more information about the ArcGIS Server SOAP SDK from the Resource Center and usage of the ArcGIS Java WebServices (AgsJWS) API


Posted in Developer | Tagged , , , | 2 Comments

GIS, Web 2.0 and Social Media Demo Theater (Samples and PPT)

We want to thank all who attended this UC 2009 demo theater. We had great turnout and received lots of feedback and input on your real-world use cases. Since we have received quite a few requests for the session materials, here are some links to help get you started:

Web 2.0 is Evolving



Posted in Developer | Tagged , , | Leave a comment

ArcGIS Developers: ArcGIS Silverlight Toolkit on CodePlex (Open Source)


We are proud to announce that the ArcGIS Silverlight Toolkit is now available on CodePlex as an open source project.  The project contains the source for the ESRI.ArcGIS.Client.Toolkit.dll and is available for use under the Microsoft Public License (Ms-PL) agreement.  This source will be very helpful if you are customizing or extending the existing controls or if you are building your own mapping tools from scratch.

Inside the project is the Silverlight/WPF C# code and XAML for a set of widgets (controls) designed to work with the ArcGIS Silverlight Map control. You can find a complete list of components with help documentation on the ArcGIS API for Microsoft Silverlight™/WPF™ Resource Center under Library Reference.  

To learn more about CodePlex, please visit their FAQ page.

We hope you find this project valuable and we encourage you to participate in the developer community.




Posted in Developer | Tagged , | Leave a comment