There are no dumb questions about ArcGIS Web services. Nor are there any dumb people who use ArcGIS Web services. But ArcGIS Web services provide a powerful tool that supports a rich implementation of GIS. So, this article aims to dumb things down a little so even more people can start using them or start putting them to use in re-inspired ways.
To understand ArcGIS Web services, it helps to think first about software design because an ArcGIS Web service is fundamentally a mini software system. Using software involves executing functions to manipulate and then share information. Thus, software must be designed to receive, execute and give instructions. A common approach to making that happen is with a service-oriented architecture.
SOA is a style of software design that lets us execute business activities across a network. In the context of software, a single service is used to package and share a discrete function. In this sense, a service is not unlike a basic wash on a car wash menu. It’s an offering that requires specific inputs and actions, and offers specific results. While the “basic” is one service you can get at the car wash, the business may also offer an exterior wax or interior detail. These types of car wash services can typically be combined depending on your needs.
With SOA, software services can also be combined to provide the capability of a multi-functional application. When end users are accessing services, they are taking advantage of one or multiple functions to meet their requirements. Think of a software function or service as a specific business activity.
Software services are designed in such a way that they can be easily and repeatedly shared and accessed by diverse types of applications and devices across a network. Understanding the purpose of a software service brings us one step closer to understanding ArcGIS Web services.
A Web service is a service that can be shared across the World Wide Web (i.e., the information-resources space that is accessible via the internet). How do you make a service shareable? To make a service shareable across the Web, it must be designed to support cross-Web, machine-to-machine communication. This is done using a key set of building blocks.
The building blocks used to create and publish Web services varies from architect to architect, from environment to environment, and as technology standards continue to evolve. To use ArcGIS Web services, it’s not necessary to understand these technical details. But, if you happen to ask a software architect or developer about behind-the-scenes construction of a Web service, they’re likely to utter one of these three common building blocks:
According to Esri, ArcGIS Web services are defined as the following:
“An ArcGIS Server web service represents a GIS resource—such as a map, locator, or image—that is located on an ArcGIS Server site and is made available to client applications”
The primary reasons for using ArcGIS Web services are:
Creating ArcGIS Web services entails designing and authoring types of information that others will find valuable AND publishing it in a manner that makes it easy for them to access and consume for review and analysis.
If you’ve used ArcGIS Desktop, then you should be familiar with ArcMap, ArcCatalog and/or ArcGIS Pro. When you author a Web service, you use one of these applications first to create what you’d like to share. Once you’ve created your service, you then use a simple wizard to publish it to ArcGIS Server. ArcGIS Server then takes care of making your Web services available to others across a network or the cloud. In doing so, ArcGIS Server ensures that your Web services are appropriately registered, discoverable and performing as expected.
Note: ArcGIS Server supports publishing to some Open Geospatial Consortium (OGC) standards where indicated by the respective acronym. These include: Web Feature Service (WFS), Web Map Service (WMS), Web Coverage Service (WCS), Web Map Tile Service (WMTS), Web Processing Service (WPS) and Keyhole Markup Language (KML) – all of which are designed for publishing specific types of geospatial data for viewing or editing by applications such as Google Earth. Click here for a more detailed description of each standard.
The following are some of the types of spatial resources that you can publish to ArcGIS Server. When you publish an ArcGIS Web service, you also activate the specific ways that the resource you’re sharing can be used.
Some services — such as those that serve up maps or individual layers or feature information — may represent a resource that is cached or dynamic. Dynamic maps or layers, for example, are retrieved from the data source at the time they’re requested by the user. As such, they reflect real-time data. Why would you want this? This dynamic approach is beneficial for serving resources that change frequently. For instance, you may have a field crew performing maintenance on a pipeline; in this case, being able to access the real-time pressure of the pipeline may be useful. Cached services provide static data and are the fastest way to deliver content to the consumer. A cached approach is beneficial for data such as basemaps because they typically don’t change (will not need to be re-published) very often.
Although each Web service is dedicated to serving up a single type of resource, multiple services can be assembled to form a web GIS application (i.e., a single user interface). For example, this type up mash up is commonly done to combine a basemap service (such as a road map) with one or more operational map services (such as primary circuit and utility pole or transformer feature sets).
To access an ArcGIS Web service, clients must know or be able to find the URL for the service – no differently than how you must know or find a URL to locate or return to a favorite shopping Web site. Organizations that publish services provide a Service Directory to help you navigate through a list of links that provide the URL for services in which you’re interested, and to which they allow member or public access.
Permissions for service access are established during or after publishing. For more information on how to establish permissions, click here.
If you have questions about services security and the type of access configured for the services authored within your organization, don’t hesitate to contact SSP and ask what the ArcGIS Online Jumpstart Package can do for you. For detailed information about security configuration, click here.