GEOG 865
Cloud and Server GIS

Publishing a service

PrintPrint

In the previous part of this lesson, you copied a map document to your EC2 instance. However that map is still only available inside ArcMap on your instance. Now you'll take the step of publishing the map as a web service so that it can be used by anyone.

Whenever you publish a service, you begin the process in ArcMap, having opened the map document that you would like to publish. You run an analysis process on the map to find anything that might prevent it from being drawn by ArcGIS Server's drawing engine. You then set service properties and publish the service.

Opening and analyzing the map

  1. Log in to your instance using Windows Remote Desktop Connection.
  2. Start ArcMap and open D:\data\AppalachianTrail\Trail.mxd.
  3. Examine the Table of Contents window in ArcMap. Several subtle techniques have been used in preparing this map document that will improve its quality as a web service.
     
     Screen capture to show the ArcMap TOC
    Figure 2.3: Available Drives
    • Scale ranges have been set on the layers to symbolize them differently as the user zooms in and out. Group layers are used to organize the layers for each scale range.
    • The layers have been given intuitive names. This ArcMap table of contents won't be available to the user of the web service. However, apps that use the service will sometimes construct a legend or table of contents given information that the app can read for the service. Since the app is going to read the layer names, it's important to name them intuitively. For example, "Trail" is a more user-friendly layer name than the default "Centerline". Also, the default data frame name of "Layers" has been changed to "Appalachian Trail Shelters".
    • The bright colors and shadowed labels of this map have been chosen with the anticipation that the map will overlay satellite and aerial imagery. The imagery itself has not been included in the map because it will be obtained through a different web service. When designing web services, it's a good practice to separate base map layers such as imagery into their own services. The trail data we are working with consists of business layers, or operational layers. These types of layers are usually the main datasets of interest in the web map, and they are often separated into their own services and symbolized with the anticipation that they will overlay the base map service.
  4. Click File > Share As > Service. This launches a wizard that will help publish the service.
  5. Click Publish a service and click Next.
  6. From the Choose a connection drop-down list, choose your ArcGIS Server. You should have a connection listed here because you made one in the Catalog window during the previous section of the lesson.
  7. Type a Service name of Trail, or something else that is intuitive. Then click Next.

    You can put your ArcGIS Server services in "folders" if you want to group them together for security or logistical purposes. These don't translate to physical folders on disk, they are just an organizational mechanism. For example, you might remember seeing the PrintingTools and Geometry services in the Utilities folder back when you were touring Manager.

    In the lesson exercises, we won't bother with folders because you won't have that many services to keep track of.
  8. Choose Use existing folder [root] and click Continue.

    After a few moments, a window called the Service Editor appears. This is where you can analyze your map for performance issues and set the service properties before you publish.
  9. Click the Analyze button and then examine the Prepare window that appears in ArcMap.

    The Prepare window displays a report of anything that might prevent the service from being created. The ArcGIS Server drawing engine is optimized for speed on the web and does not support some of the less-common layers and symbols that you can view in ArcMap. If your map contains something that's not supported, you will see an Error in the report and you must remove the layer from your map before you can publish. See the ArcGIS help document Supported functionality in map services to learn which types of layers are available.

    The report also lists Warning and Info messages about things that might slow down or otherwise hinder your service once its published. On the web, speed is king. It's usually worth your time to fix as many of the warnings as you can before publishing your service.

    If you don't understand a particular message, you can right-click it and click Help to see documentation about that specific message.

    The most important warning you see in your Trail map is that the data is stored in a different coordinate system than the data frame. This means the data frame is projecting the layers "on the fly" every time the map draws. Since this projection is computationally intensive, it's best if your server does not have to perform it on every map draw, especially if hundreds of people will be hitting the service at the same time. Let's change the data frame projection to match the source data and re-analyze.
  10. Without closing the Service Editor (you can minimize it using the arrow in the upper-right corner) return to the ArcMap Table of Contents window, right-click the data frame name (Appalachian Trail) and click Properties.
  11. Click the Coordinate System tab, then browse to Projected Coordinate Systems > World > WGS 1984 Web Mercator (Auxiliary Sphere) and click OK.

    Your data frame projection now matches the projection of your data. The Web Mercator (Auxiliary Sphere) projection is a common one used by online mapping services such as ArcGIS Online, Bing Maps, and Google Maps.
  12. In the Service Editor, click Analyze again and notice that the warning about the coordinate system has gone away.

    Now let's adjust a few of the default properties on this map service before publishing it. This will also take care of the remaining warnings about your missing summary and tags.
  13. On the left menu of the Service Editor, click the Parameters tab.
  14. Change Anti-Aliasing to Normal.

    Anti-aliasing is a technique that smooths the edges of lines and labels and makes them look presentable to a web audience. Anti-aliasing introduces some performance cost, but if you don't enable it, your maps will have a pixelated ArcMappy feel to them that will make your web app users feel like they are in 1996.
  15. On the left menu, click the Capabilities tab and examine the available capabilities.

    ArcGIS Server capabilities define the ways that users can access your service. All web services have strictly defined ways that they are allowed to communicate with clients. They also expose a set of methods or operations, which are things they can do (like draw a map). By adding more capabilities here, you thereby expand the ways that clients can use your service. The WMS capability, for example, allows clients to communicate with your service through the Open Geospatial Consortium (OGC) Web Map Service (WMS) specification, an open specification for how GIS map web services should communicate. The ArcGIS Help topic What kinds of services can you publish? lists all the available capabilities.

    Since you're publishing a simple service for test purposes, leave the default capabilities. In Lesson 3 you'll get a chance to work with the Feature Access capability.
  16. On the left menu, click the Item Description tab and type some basic metadata for your service in the input boxes.

    The Summary is a concise, one-line description of your service, while Tags are very brief descriptors (usually one or two words) used by web indexing mechanisms. Trails, hiking, shelters, or Appalachian Trail might be good tags for this service. The Description is a longer explanation of your service and how it was created.

    The item details you add here are used when searching services that have been registered with ArcGIS Online (Esri's cloud-based catalog of services). They're also visible to web developers who are browsing your services.
  17. Click Analyze again. In the Prepare window, you should see no warnings now that you have added a summary and tags.
  18. Click the Publish button.

    This creates a web service for your map. In a few minutes, you should be able to see the service listed in Manager or the Catalog window (when you double-click your GIS server connection).

    When you publish a service, a copy of your map is placed in a special folder on your server (arcgissystem). If you ever update the layers or symbology in your map, you must overwrite your service so that a new copy of the map can be placed there. You overwrite a service using the same wizard that you use for publishing. In the first panel, you choose Overwrite an existing service instead of Publish a service.
  19. Open the Services Directory and verify that you see your new trail service. The URL to your Services Directory, which you can use from any machine, is http://<Elastic Load Balancer address>/arcgis/rest/services.

Ways of working with web services

When you publish a service, you are giving the server a set of things that it can do with a particular map. In order for this to be useful to anyone, the client application and the server need to be able to communicate with each other in a way that both understand. There are several ways that an ArcGIS Server map service can allow itself to communicate with client applications.

REST

Representational State Transfer (REST) allows a client to discover information about a service or invoke operations on a service using a known structure of URLs. REST is not really a communication protocol, but rather an architecture; a way of building a web service so that it has a hierarchy of resources and operations that can be accessed by formulating the correct URL.

The actual bits of information sent "across the wire" can vary in format, but JavaScript object notation (JSON) is often used. JSON is desirable because of its well-known structured format and the fact that it can compact information into a minimal amount of characters.

Here's an example of some JSON that describes a wildfire mapping web service. Take a few moments to examine all the properties exposed in this JSON. This is actually an easy-to-read format of JSON with extra line breaks and spaces called "pretty JSON." Removing the spaces to get pure JSON makes it more difficult for you to read, but reduces the information that the computer has to read and can, therefore, make your web service more efficient.

REST is stateless, meaning that any one request cannot depend on information sent in a previous or future request. All requests are independent of each other. This requirement can make for some interesting architectural considerations. For example, to support an interactive web editing session with REST, you must send an entire digitized feature to the database at once; you cannot send the feature vertex by vertex as it is digitized.

Because of REST's simplicity and efficiency, the Esri web mapping APIs for JavaScript, Flex, and Silverlight communicate with ArcGIS Server web services using REST.

SOAP

SOAP is an XML-based protocol for communicating with web services. XML is a structured way of providing information based on tags. This tends to take more text than the JSON you saw previously, and SOAP is not used in the newer Esri web mapping APIs. However, desktop clients like ArcMap use SOAP to communicate with ArcGIS Server web services.

Each SOAP web services has a web service description language (WSDL) that describes what clients can do with the service and how to structure their requests. Here's the WSDL for the fire mapping service you saw previously. Take a close look and see if you can recognize some of the things this service can do.