Tag Archives: Java
This week the ArcGIS Java Technology Blog posted a State of the Union Address to the Esri Java Community. It’s a candid, easy-to-read summary of how Java technology integrates with Esri products, including ArcGIS Server. If you haven’t seen it, it’s worth a read.
Here we are already. It is already the middle of June, 2011. Another Esri User Conference is shimmering on the horizon again. ArcGIS 10 is making history and making a significant impact in and around the world, and yet at the same time, the buzz can already be heard surrounding prospects of a major, revolutionary release of the next ArcGIS System not so far down the road. Exciting times indeed!
So it seems as though it’s about time to pause now and take a realistic overview of where Esri’s Java Platform strategy is today and where it is trending. The intention of this post is to update you all, certainly. I would add, too, that an equally important goal of this post is to give confidence to you that Esri is committed to supporting your business needs with respect to the entire Java platform, from mobile to desktops to enterprise.
It’s been a while since we’ve collectively reviewed this Java state of the Union, so to speak. Let me clarify what I mean by “we”; I mean “you”, the Java users and developers as well as those of us at Esri that work to serve “you”. Together, I mean “us”. A community. I know, it sounds a bit “touchy-feely”, as Americans would say. I do mean that with all sincerity, but I’ll move on to the matter at hand.
Java continues to be an important platform for Esri’s GIS solutions and offerings going forward through versions 10.x and beyond.
Java also continues to be the world’s most widely used platform for building real, robust and secure enterprise systems. Industries such as finance, insurance, health care, government, national defense, all rely on the Java platform because of its proven reliability and versatility on many runtime platforms over the years. Esri recognizes the pervasiveness of Java throughout these industries where GIS is also critical.
Let’s take a closer look at how Esri is supporting the Java developer and user community today as well as what Esri’s plans are for the foreseeable future.
ArcGIS for Server
Typically, one thinks of Server as mapping to Java Enterprise Edition (Java EE); Web Services, Web Applications, and the various Java technologies surrounding these platforms. Historically, the showcase product here from Esri has been the Java Web ADF. This is a true JSF/MVC implementation for rapidly building GIS Web applications that consume services from ArcGIS Server and OGC standard servers.
With the WebADF, developers find a clearly defined Model/View/Controller (MVC) implementation, and the framework adheres to tried and true Java EE standards, i.e JSF, AJAX, SOAP/XML, and more. It is a beautiful stack, actually. The Java enterprise architect gets it. However, the pure GIS professional developer who is not familiar with these Java EE standards struggles with it. Is it finished and perfect? No. Is it successful, yes it is, or was, in many areas. In other spheres, though, it was quite complex. Users and developers found it difficult to scale and maintain, in the end.
At version 10.0 of ArcGIS, the Java Web ADF has been deprecated; the 10.1 version of ArcGIS will be the last release of the Web ADFs, both Java and .NET. Folks that are planning new projects having to do with ArcGIS Server are highly advised to eliminate the Web ADF from consideration.
Of course, the foundation for these APIs is REST. The ArcGIS REST API handlers define the basis of the “Controller” tier, if you will. The Model is core ArcGIS Server. This is key to Esri’s strong Services platform for Enterprise GIS. The ArcGIS REST API is a public specification, and is published as the open Geoservices API.
While the ADF has been deprecated, as previously mentioned, the ArcGIS Java Web Services API (AgsJWS), the underpinning API for the WebADF, has not. This is an important point to make. SOAP/XML is till the Web Services standard for SOA integration. Esri does not plan to deprecate this Web Services solution for ArcGIS Server. The AgsJWS is a pure Java Web Services API, based on JAXB, and is an excellent solution for building , connecting and integrating great geospatial analysis and visualization in your Java EE based solutions. Esri continues to cultivate and support its community today and into the future.
For the back-end Server, building Server Object Extensions (SOEs) with the ArcObjects SDK for Java has been and continues to be the leading solution for creating custom ArcGIS Server Web Services. There have been compelling success stories from users who to extend the Server with Java APIs, using the powerful Eclipse tooling to build and deploy them. A good example of a success story is ArcGIS for INSPIRE, a product that heavily relies on Java-based SOEs. SOEs can be exposed instantly as REST and SOAP, so if you develop with any of the RESTful Web APIs a front end to your system, your custom Java implementation and capabilities in the Server can immediately be realized in the View tier of MVC.
ArcGIS for the Desktop
ArcGIS Desktop is extensible using Java. Java developers can use the ArcObjects Java SDK Eclipse plug-ins to write, debug and extend ArcObjects and the Geoprocessing framework, and deploy their add-ins and extensions as jar files. ArcGIS Desktop is Java-enabled! ArcGIS Desktop ships with its own Java runtime. 5 or 6 years ago, could anyone have imagined that this would become possible? This came about in response to a lot of Java developers wanting to customize ArcGIS Desktop, ArcMap and ArcCatalog, using their chosen skill and expertise, and Esri listened and responded. The ArcObjects SDK for the Java platform continues to be the go-to developer kit for building custom, feature-rich desktop applications that leverage the powerful ArcGIS Engine runtime.
ArcGIS for Lightweight and Mobile Devices
At version 10.1 of ArcGIS, Esri will introduce a new suite of products under the platform strategy called “Lightweight GIS”. GIS is accessible and usable via mobile devices such as laptops, tablets and phones in connected, disconnected, and “sometimes”-connected environments. This lightweight GIS platform provides new developer APIs for Java desktop, mobile, and embedded device developers. There are two key products based on this platform that Java developers can take advantage of: The ArcGIS Runtime SDK for Java SE based GIS applications, and the ArcGIS for Android SDK for Android phones and tablets. These SDKs are founded upon the Web API and Smartphone API object models. They are pure Java APIs and both have strong Eclipse IDE
integration support, making development easy, quick and extremely intuitive.
ArcGIS versions 10 and 10.1 both support Java SE 6 and Java EE 5. Esri continues to monitor the progress of the Java EE 6 and Java SE 7 specifications to see if the features they offer will make sense for the ArcGIS product line.
To summarize, Esri’s ArcGIS and Java strategy is pervasive, in and through all of the key computing environments that Java is found in, from Mobility to the desktop and to the Enterprise. This makes Esri’s GIS and Java a perfect match for any Java-based implementation that requires the delivery of geospatial or location services and capabilities.
So until next time, please let us know your thoughts and feedback by sharing comments questions. This will help us in serving you better, the Java developer and user community. We hope to meet with you at the ESRI International User Conference in July!
Not long ago, we published an early deprecation notice announcing upcoming changes to ArcGIS Server in its 10.1 release. Reading between the lines, many of you realized that in the future, ArcGIS Server will become purely a server of GIS Web services. This is an architecture that has many advantages, but considering the code you may be accustomed to writing on top of local (DCOM) connections,it will bring significant changes to the way you think about developing with ArcGIS Server. Particularly, the 10.1 changes affect applications built with the Web ADF that make use of ArcObjects and nonpooled services.
This post is an early discussion of the path to move to a pure Web services pattern for communicating with ArcGIS Server. We will also disclose some additional information regarding our ArcGIS 10.1 plans so you have a better context to some of the changes in the deprecation notice. The intent of this post is not only to help you evaluate the impact of ArcGIS 10.1 on your existing applications, but also to outline and promote a Web services pattern in your development that aligns with the ArcGIS Server road map.
When ArcGIS Server first hit the market, we provided two hooks into it: you could access its Web services through HTTP, and you could also use local connections over DCOM. Local connections were handy when out-of-the-box Web services did not give you all the functionality you needed. In fact, through local connections, you could execute ArcObjects code on your server that your Web application could use. While the concept of executing ArcObjects logic in the server remains a powerful concept, the way in which this happens is changing.
This new Web services architecture is a simpler one. It results in easier-to-maintain applications, and faster and more scalable deployments. As of today, most ArcGIS Server development is happening through these APIs.
A particular point of concern for many developers revolves around ArcObjects access. The pattern for accessing ArcObjects functionality in the Web ADFs is widely known, but how do you get to ArcObjects from the ArcGIS Web Mapping APIs? And how will ArcObjects access occur in ArcGIS 10.1 with the deprecation of local connections?
In this post we’ll describe specific scenarios where Web ADF developers have traditionally used ArcObjects programming and local connections to ArcGIS Server. For some of these scenarios, we’ll describe how you might accomplish the same thing using alternative techniques. Where appropriate, we’ll also describe how you could address these scenarios using a Web services programming pattern with ArcObjects.
Reasons people use ArcGIS Server local connections…and some alternatives
As we browse the user forums and attend Esri conferences, we hear several common reasons that developers still use local connections in their Web applications. Here are a few of those reasons, accompanied by some alternatives.
Creating layouts for printing
We’ve met some developers who have used ArcObjects to access the Layout object of the map service, specifically for putting high quality printing functionality in their Web applications. They use ArcObjects to work with ArcMap-quality maps and their surrounding elements, generate printable documents in large formats, and so on.
At ArcGIS 10.0, we recommend you use the arcpy.mapping Python module to script your layout construction and map printing. Then, expose the script through a geoprocessing service. With arcpy.mapping, you can manipulate map documents to a very fine degree: you can add layers dynamically to the map, update their symbology, and more. You can also access the layout of the map, manipulating elements such as text and images.
See this blog post for a brief introduction to the arcpy.mapping module and its use within ArcGIS Server.
As we move on to ArcGIS Server 10.1, keep in mind that we will enhance the arcpy.mapping capabilities. Specifically, we plan to make it very easy to dynamically load the contents of a Web mapping application (including map services and graphics) into a map document using arcpy.mapping.
Changing symbols and renderers
Another reason developers use local connections is to change the symbology of a particular layer in a map service. This workflow often required the use of non-pooled services, limiting the scalability of your applications. Some developers managed to do this with pooled services, although switching the state of a service back and forth to satisfy requests from multiple users often resulted in poor performance and left a great deal of responsibility in the developer to keep a healthy state on the map instance itself. Let’s discuss a couple of alternatives here.
The ArcGIS Web APIs give you an easy way to symbolize features using a client-side feature layer or graphics layer, whose rendering properties can be changed at any time. The idea is that the geometry and the attributes of visible features are all downloaded to the client, so it’s easy for the client to draw the features using any colors, widths, or class breaks defined by the application developer.
The feature layer technique is particularly effective for thematic mapping, interacting with and highlighting features, and so on; but it falls short when you are working with thousands of features or very complex polygon features. In those cases, the best approach is to request symbology changes at the service level and have the map service render the map image. This currently requires ArcObjects.
ArcGIS Server 10.1 will enhance the map service such that you can alter the contents and symbology of the map at runtime (like you could with ArcIMS). You will no longer need to use nonpooled services and fine grained ArcObjects to change symbology on your map service layers. Instead, you will be able to decide, on a per request basis, the contents or symbology to be used in the map you want to create.
This enhancement will make your applications significantly more scalable, while simplifying development and maintenance. Defining the symbology of your layers in the map service at runtime will be done by including the renderer information in your Web service request to draw the map, along with the typical information such as visibility of layers, extent, and so on. All the Web Mapping APIs will include utility classes so you can esily define content, renderers, class breaks , symbology, and so forth.
In the early releases of ArcGIS Server, editing data over the Web had to be accomplished purely through ArcObjects custom code leveraging local connections. In version 9.2, an Editor Task was introduced in the Web ADF allowing basic editing such as creating, moving, and deleting features. Any customization of this task or the creation of editing tools from scratch still required extensive ArcObjects programming.
The REST-based APIs did not initially expose Web editing; however, with the introduction of the feature service at ArcGIS Server 10.0, editing is now possible through these APIs. Not only is editing possible through REST, it’s convenient to customize because many common editing methods such as cut, trim, extend, auto-complete polygons, and reshape are exposed through the REST implementation of the geometry service. Finally, when you edit with REST, you can use pooled services. This is a huge boon to performance.
There is one workflow for which support will not be continued in ArcGIS 10.1: long transactions. In the Web ADF, you can leverage nonpooled services to perform edits following a long transaction model. In essence, you can start updating features and roll back at any time. With the feature service, all operations are stateless, meaning that you can’t really roll back at the database level (although you could with business logic in your application). A long transaction model for Web editing is one of the very few workflows where the new architecture of ArcGIS Server 10.1 will not offer alternatives.
It is important to highlight that lack of support for long transactions does not preclude you from implementing undo-redo operations. In fact, in the 2.2 version of the ArcGIS Web APIs, undo-redo operations are possible right from the API at the application level.
Another unique capability that nonpooled services give you is the ability to change versions while editing. This allows, for example, Web users to store their changes in different versions that can be reconciled later from ArcGIS Desktop. While feature services support editing on versioned data (as well as non-versioned), it is not possible to switch the version at runtime in ArcGIS Server 10.0. That is, the only version that Web clients can edit through a feature service is the one that was used when authoring the map service itself. For the 10.1 release, we are aiming to enhance feature services so you can efficiently target a version for your edits at runtime from any web application.
Performing business logic
Some GIS applications run a specific series of tools to perform advanced GIS business logic. These tools might predict timber yield from a forest, identify suitable sites for a restaurant, or estimate where a toxic cloud could spread. Many developers went the ArcObjects route to accommodate this.
In many cases, these processes can be expressed in ArcGIS Model Builder, where you can graphically “chain” tools together. These geoprocessing models can be exposed as Web services and consumed from your Web applications. Go here for a quick introduction to geoprocessing in ArcGIS Server. The benefits of this are obvious: Using a geoprocessing service can save you a lot of coding. Also, you can take advantage of the asynchronous execution of geoprocessing services, which is challenging to achieve by writing your own ArcObjects code.
Custom geoprocessing tools
Aside from the flexibility of having hundreds of out of the box tools that you can combine in Model Builder, geoprocessing gives you the ability to develop custom tools. The simplest way is to create Python scripts that can either run on their own, or in combination with other tools within a model. We described an example of this earlier with the use of arcpy.mapping to create high quality maps over the Web. For general guidance on building python script tools for the geoprocessing environment, go here.
For even further control, you can go beyond Python to create a custom geoprocessing tool with C#, VB.Net or C++. This allows you to embed your own fine-grained ArcObjects logic within your models. Here is a help topic with details on how to create a custom geoprocessing tool with C#.
Whether you use Python or another language, the advantage of creating custom tools is that you can reuse them in different workflows, since they will behave just like any other out of the box tool. Additionally, your ArcObjects or python code can execute within the asynchronous execution model of geoprocessing services, which is quite handy for long-time running processes.
The geometry service
Geoprocessing services are handy, but just like you should not jump into ArcObjects development when something can be easily achieved with geoprocessing, it’s wise to avoid jumping into geoprocessing if out-of-the-box services can already do the job. You may check to see if the SOAP or REST-based geometry service offers the methods that you need. A geometry service can perform basic GIS operations such as buffering, determining spatial relationships, measuring lengths and areas, and so on. Calling a series of methods on a geometry service and combining that with the query capabilities of map services and client side logic can be simpler and faster than using a geoprocessing service. In this white paper we explore a scenario comparing the use of the Geometry service versus a geoprocessing service for solving a simple selection by distance problem.
For simple problems, geoprocessing and ArcObjects are too heavy-handed of a solution. You might save yourself some work by studying and understanding what is possible with map service queries, geometry service calls and so on.
Geoprocessing models are generally appropriate for long running and complex processes. As a developer you can always extend this framework with Python and custom ArcObjects geoprocessing tools to face the most challenging problems. In the next section we discuss yet another alternative, which may be the way to go for tasks that need to run very quick.
Server object extensions
If you have well-defined business logic that you want to execute quickly, an alternative approach is to develop a server object extension (SOE). SOEs are an advanced developer option that allow you to expand the base functionality of ArcGIS Server services. SOEs have two great advantages:
- SOEs encapsulate ArcObjects efficiently, and provide an ideal environment to execute your calls very quickly.
You might build an SOE to extract an elevation profile from a raster, or work with dynamic segmentation to get the location of a mile marker. In these cases, SOEs expose functionality that is either not available through any other means (through out of the box geoprocessing tools or other ArcGIS Server services) or functionality that needs to be executed quickly.
Here is an example showing an SOE being used from an ArcGIS API for Flex application. This SOE uses the 3D Extension libraries in ArcGIS Server to perform a quick terrain profile. In this particular scenario, we did not find geoprocessing tools that could help us with the profile generation, so we knew we were going to write our logic in ArcObjects. Given that this is a very quick operation not requiring asynchronous execution, we decided to use an SOE.
SOE development requires knowledge of ArcObjects,.NET or Java, and Web service communication technologies such as REST and SOAP. The ArcObjects SDK has several samples that you can examine, both for Java and .NET.
If you plan on developing new SOEs, keep in mind that in ArcGIS Server 10.1 you will be required to analyze your map documents before publishing them and fix any errors that appear. Thus, one of the things you can do to get your SOE’s ready for 10.1 is to make sure they work against MSDs at 10.0. Building SOE’s on top of MSD based map services with ArcGIS Server 10.0 is perfectly possible. The biggest requirement is that you avoid using MXD-specific interfaces (such as IMap, ILayer, anything to do with page layouts, and so on). Here is a blog post describing how you can use IMapServerDataAccess to get to the data sources of an MSD-based map service.
We realize that accessing layers and layouts is handy when you want to do some of the things we described earlier, like changing the symbology of layers, high quality printing, and so on. Much of the new functionality in 10.1 will help you through the places where it’s currently challenging to make an MSD-compliant SOE. By looking at some of the scenarios described in this post such as map printing through the arcpy.mapping module and changing the symbology of layers, you will begin to understand how to properly address your workflows at 10.1.
This post offers important direction for ArcGIS Server developers as you make plans for current and future releases. Information provided is based on the current status of our 10.1 work and is subject to adjustment during the 10.1 beta cycle. We look forward to communicating with you further on these and other topics of interest to Server developers. Please use the comments section of this blog post to leave questions.
Contributed by Ismael Chivite of Esri Product Management and Sterling Quinn of the ArcGIS Server development team
The Map Widget can be used to display geographic data stored in ArcGIS Server map services and Spatial Data feeds on ArcGIS Online or ArcGIS Server basemaps enabling ESRI to provide Geographic Business Analytics to the Desktop.
The Map Widget can be used to display geographic data stored in ArcGIS Server map services and Spatial Data feeds on ArcGIS Online or ArcGIS Server basemaps enabling ESRI to integrate GIS with Business Analytics.
Benefits of Map Widget for ArcGIS:
- Built to standard provided by IBM
- Lower development costs, deliver rapid integrated applications.
- Empower business users by improving effectiveness and save time
- Unlock siloed information from spreadsheets et. All, with geographical content by visualizing data
- Multiple deployment platforms, IBM Mashup Center & IBM Portal Server.
Included with Map Widget for ArcGIS
- Send/Recieve events to other iWidgets and Portlets
- Configure base maps for ArcGIS Online and ArcGIS Server
- Add operational layers from ArcGIS Online and ArcGIS Server
- Rich user interactive map operations
- You can download the Map Widget for ArcGIS from IBM Lotus and WebSphere Portal Business Solutions Catalog.
- The Map Widget for ArcGIS is open source. You can obtain the source code distribution for ArcGIS Online
- The Map Widget for ArcGIS is based on the iWidget 2.0 specification.
This is a first in a series of posts which will dive into using and extending the Map Widget for ArcGIS.
The following post is from Ralf, a member of the ArcObjects Team.
John and I were preparing for our Desktop migration technical workshop and realized that there are a lot of links to resources we wanted to share with you. So we figured the best way to bring this information to you and the rest of the Desktop developer community is through a blog post. Below are some links to help you in the migration process.
- Custom component migration overview:
- Standalone application migration overview
- Runtime binding for Visual C++ developers
- Bootstrapping the ArcObjects.Jar – Runtime binding for Engine Java developers:
- ArcGIS Code Migration Analyzer plugin for Visual StudioType changes between 9.3 and 10
- Intro to Add-ins .NET
- Add-ins Walkthrough
- VB6 migration overview
- VB6 migration walkthrough
- General VB6 migration topics
- Common issues when migrating VB6 to .NET
- Upgrading VB6 code to a more .NET style of programming
We hope you find these links useful when migrating your applications to ArcGIS 10.
Enjoy the Dev Summit!
We are excited to announce that the ArcGIS API for Android is in public beta and available for download…. more details.
We are excited to announce that the ArcGIS API for Android is in public beta and available for download from our beta community site! Use it to build Android mapping applications that:
· Access dynamic, tiled, and feature map services
· Overlay graphics
· Search and identify
· Perform advanced analysis
· Collect and edit data from your android phone and tablet devices
The Android Team
Server object extensions (SOEs) are a way that you can extend ArcGIS Server to run your own ArcObjects business logic. The nice thing about SOEs are that they are not application-specific; you can write one SOE and attach it to multiple services. You can also expose your SOE as a SOAP or REST Web service, a topic on which we’re preparing some future posts.
In today’s post, we’ll explain how to work with optimized map services when you’re writing an SOE. By “optimized map services”, we mean ArcGIS Server map services that are based on map service definitions (.msd files). This is the type of service that you get when you work with the Map Service Publishing toolbar in ArcMap. Optimized map services use a faster drawing engine than the traditional, MXD-based map services, so there are benefits to writing your SOE to support them.
Because optimized map service use a completely different drawing engine and source file than MXD-based services, they draw very quickly. However, this also means that they do not support full ArcObjects access from the Carto library. When working with optimized map services, you cannot use any ArcObjects directly related to the map document, such as IMapServerObjects, IMap, ILayer, and IFeatureLayer.
It turns out you can still do quite a few things when you use an optimized map service with your SOE. This post explains what objects are available, and how options have increased with ArcGIS 10.
What you can do
The Carto library contains a MapServer class that represents the map service. There are a number of supporting classes and interfaces surrounding MapServer that give you information such as the layer names, whether the service has a cache or not, and how queries should be performed with the service.
On page 6 of the .NET Carto object model diagram, you can see these classes and interfaces. You can use them with any type of map service, whether the source map is an MSD or an MXD. Avoid using other classes in the Carto library with optimized map services.
Getting to the source data at ArcGIS 10
At ArcGIS Server 10.0, the MapServer class implements a new interface IMapServerDataAccess, which allows you to access the data sources of the layers in your map. Using the GetDataSource method on this interface, you can access the IFeatureClass, IRaster, or ITable interface of the underlying data.
The typical pattern is to use the MapServer-related classes and interfaces to discover the layer names and indices in your map service; then use IMapServerDataAccess to get to the data beneath. Once you obtain the source data, you can do many things with it using ArcObjects, such as opening feature cursors or topological operators. You’re safe as long as you avoid the above-mentioned MXD-specific classes from the Carto library.
Here’s an example that gets the source feature class for a map layer named “States”.
string mapLayerToFind = "States";
//Access the map service and its layer infos
ESRI.ArcGIS.Carto.IMapServer3 mapServer = (ESRI.ArcGIS.Carto.IMapServer3)serverObjectHelper.ServerObject;
string mapName = mapServer.DefaultMapName;
IMapLayerInfos layerInfos = mapServer.GetServerInfo(mapName).MapLayerInfos;
// Find the index of the layer of interest
int c = layerInfos.Count;
int layerIndex = 0;
for (int i = 0; i < c; i++)
layerInfo = layerInfos.get_Element(i);
if (layerInfo.Name == mapLayerToFind)
layerIndex = i;
// Access the source feature class
IMapServerDataAccess dataAccess = (IMapServerDataAccess)mapServer;
IFeatureClass fc = (IFeatureClass)dataAccess.GetDataSource(mapName, layerIndex);
The above code gets all the layer information for the map service. IMapLayerInfos and IMapLayerInfo are legal to use because they do not require access to a map document; they just help you get information that the service exposes.
The code then iterates through the layer infos until it finds the index of the layer named “States”. That index is then passed into IMapServerDataAccess.GetDataSource(). At this point you’ve reached your goal of accessing the source data interface IFeatureClass.
For brevity, the above example contains no error handling; but you might want to add a check that IMapLayerInfo.Type is equal to “Feature Layer” before you go casting the result to IFeatureClass.
Registering SOEs that support optimized map services
When you register the SOE, you must also set a property defining that the SOE supports optimized map services. This property is called SupportsMSD and it is a Boolean. You have to set it to True in order for your SOE to show up in the list when you publish an optimized map service.
If you’re following the .NET SOE samples out of the SDK, you’re probably registering your SOE using a console application that calls IServerObjectAdmin2.AddExtensionType(). In this application, you set the properties of your server object extension. Here’s an example of how you’d set up the properties to support optimized map services:
IServerObjectExtensionType3 serverObjectExtensionType =
// Set properties for the SOE
serverObjectExtensionType.CLSID = "MySOE.MySOE";
. . .
// Register the SOE with the server
Notice the call to IServerObjectExtensionType3.Info.SetProperty() that sets the SupportsMSD property.
If you’re developing a Java SOE, the SupportsMSD property is not set at registration time. Instead, you set it directly in the SOE source code using Java annotations. When you later register the SOE, the property is forwarded to ArcGIS Server.
In summary, when using optimized map services with SOEs, you can do quite a bit if you stick to the MapServer-related classes. Also, with ArcGIS 10, you can use IMapServerDataAccess to access the source data for the layers in your map. From there you can do many things to work with the data directly.
Contributed by Sterling Quinn of the ArcGIS Server software development team
Map caching is a very effective way to serve map documents faster. When you create a map cache, the server draws the entire map at several different scales and stores copies of the map images. The server can then distribute these images whenever someone asks for a map. It’s much quicker for ArcGIS Server to hand out a cached image than to draw the map each time someone requests it. If you are unfamiliar with map caching, the What is map caching topic in the Server online help will help you get started.
ArcGIS Server provides many out-of-the box utilities to create and manage map caches. These utilities are also available on the Unix platform. In Windows, the cache management utilities are available as geoprocessing tools which you can access through ArcCatalog. Whereas on Unix, these tools are available as shell scripts in the “/ArcGIS Server installation directory/java/tools/caching” folder. These scripts will help you generate, update and manage your map caches on Unix. Let me give you a quick overview on using these scripts:
Before running any scripts, it is good practice to verify the permission of the script files and cache output folders. I have put together a brief checklist for successfully running the cache scripts.
- Your user account must be a member of ‘agsadmin’ group and must have read and execute access to the cache scripts. Managing user accounts on Linux/Solaris provides a detailed description of the user accounts created during ArcGIS Server installation and the Adding administrative users to the agsadmin group describes how you can add new users to agsadmin account.
- Your account must have write access to the cache output location.
- If you will be running long cache jobs using 9.3.1 or earlier versions, you must stop the server and update the <enginecontexttime> parameter in “/ArcGIS installation directory/server/system/Server.dat” file to “360000″ seconds. (This step is not required for the latest ArcGIS 10.0 release.)
If you are running cache scripts in a distributed setup, all the SOCs must have access to the map documents. Also, you will notice a marked increase in performance, if the map documents are available locally on all the SOC machines. You can also achieve optimum performance, if the number of SOC instances (S) that you created is at least one more than the no. of CPU cores. S = (no. of CPU cores) + 1.
After preparation, you can execute the appropriate shell script from “/ArcGIS Server installation directory/java/tools/caching” directory. The Cache generation and updates on Linux/Solaris topic provides a detailed description of all the scripts, their parameters and when they should be used. When executing the scripts you might notice that some of the parameters are exclusive to Unix. Here is a brief description of those exclusive parameters.
Context: In ArcGIS Server 9.3.1 and earlier versions, the user is prompted to choose between “engine” or “server” context. Choose “server” context to run the tool. This parameter is not required in ArcGIS Server 10.0.
- Domain: Enter the fully qualified hostname of the machine where ArcGIS Server is installed.
- Username/Password: Type in the user name/password used to connect to ArcGIS Server Manager.
- Server_name: Type in the name of the host machine where ArcGIS Server is installed or the ArcGIS SOM machine, hosting the service to be cached.
- Object_name: This gives you a list of map services currently running that meet the requirements of the script being executed. For example, if the cache tiling schema for a map service is not configured, it will not be listed in the options for the ManageMapServerCacheTiles script, even if the service is running.
All other parameters are similar to caching tools on Windows and you can find more information on them in the Cache generation and updates on Linux/Solaris topic that I mentioned earlier.
Some Additional Tips on Caching:
Lastly, here’s a short list on caching tips that might help you in general.
- Create cache on demand for regions that are not accessed very often. It helps in shrinking the cost of creating, storing & maintaining cache.
- Divide cache jobs into smaller tasks using feature classes or extents.
- Follow best practices to avoid label overlaps and to design cache customized to user requirements.
- You can create a cache schema using ArcGIS Manger. However, to create cache tiles based on the schema you must run ManageMapServerCacheTiles script.
- Generate cache in staging environment and then copy the cache over to production environment since cache generation is a resource intensive process.
If your source data tends to change and if you need to run the scripts very often, you can
- Create a Python script to automatically run the Manage Map Server Cache Tiles script on a regular basis to update all or selected areas of your cache. Before running caching scripts, you must execute the command source /arcgis/server10.0/servercore/.Server/init_server.sh as described in Step 2 of Viewing and Managing Network Ports on Linux/Solaris. See Automating cache creation and updates with geoprocessing for an example.
- Schedule the automated scripts to run at a particular time using “crontab” when trying to regularly update cache.
Hope these tips help you in getting started with map caching. Also, just as a fyi, we have added several new documents on caching and you can access them through online web help.
Content contributed by Garima Tiwari, Product Engineer, ArcGIS Java Team.