Geodata services
Geodata services |
|
| Release 9.3 |
|
A geodata service allows you to access a geodatabase through a local area network (LAN) or the Internet using ArcGIS Server. The service exposes the ability to perform geodatabase replication operations, make copies using data extraction, and execute queries in the geodatabase. A geodata service can be added for any type of geodatabase including ArcSDE geodatabases, personal geodatabases, and file geodatabases.
Geodata services are useful in situations where you need to access geodatabases in remote locations. For example, a company may want to set up ArcSDE geodatabases to manage data in its Los Angeles and New York offices. Once created, each office can publish its ArcSDE geodatabase on the Internet using a geodata service. The geodata services can then be used to create replicas for the ArcSDE geodatabases. With geodatabase replication, the geodata services can also be used to periodically synchronize the changes in each geodatabase over the Internet.
Before working with geodata services, you should have a basic understanding of how geodatabases, geodatabase replication, and data extraction work. The topic Understanding distributed data in the ArcGIS Desktop Help is a good starting point. Additionally, it's helpful to have some experience performing replication and data extraction in the ArcGIS Desktop environment before attempting these operations with ArcGIS Server.
The first step to publishing any GIS service is to create the GIS resource that it will reference. For geodata services, the resource is either an ArcSDE geodatabase, a personal geodatabase, or a file geodatabase. You can create any of these types of geodatabases using ArcCatalog. In the Geodatabases and ArcSDE section of the help, you can find much information on geodatabase design and creation. Additionally, ESRI Press has published several books on architecting effective geodatabases.
If you plan on using your geodata services for geodatabase replication, you must make sure that the data is configured properly and is from an ArcSDE geodatabase. See the topic Preparing data for replication in the ArcGIS Desktop Help for additional information.
Two types of publishing operations can yield a geodata service: publishing from a geodatabase directly and publishing a geodata service with a map service. Once published, the geodata service can be used for synchronizing replicas or working with a geodatabase in a Web application or Web service.
Publishing from a geodatabase directly involves referencing a personal geodatabase, file geodatabase, or ArcSDE connection file that you want to publish as a service. The geodatabase or connection file needs to be in a location that is accessible to the server object container (SOC) account. For example, ArcSDE geodatabases in ArcCatalog are located in your profile directory under Application Data\ESRI\ArcCatalog. (Example: C:\Documents and Settings\myUserName\Application Data\ESRI\ArcCatalog\Connection to myServer.sde.) Unless you were logged in as the SOC account when the .sde connection file was created, the SOC account does not have access to this file. Before publishing the geodata service, it is recommended that you copy the connection file to a common directory to which the SOC account has been granted access.
When publishing a geodata service from ArcSDE for SQL Server Express, you need to save the connection to your geodatabase to create the connection file. To do this, browse to the geodatabase in ArcCatalog under the Database Servers node of the Catalog tree. Right-click the geodatabase you want to publish and click Save Connection. This creates a connection (.sde) file in your profile directory as described in the previous paragraph. You need to reference this connection file when publishing the geodatabase. As suggested, copy the connection file to a common location to which the SOC account has access before you publish the service.
Follow these steps to publish a geodata service:
To publish a geodata service with a map service, you must enable geodata access from the capabilities list when publishing the map service. In this case, the map document must contain data from only one geodatabase. When the publishing process is completed, a map service and a geodata service with the same name are created and can be managed independently. Publishing a geodata service with a map service allows you to use the commands from the Distributed Geodatabase toolbar when you add the map service to ArcMap. The ArcGIS Desktop Help contains more information about using the commands on the Distributed Geodatabase toolbar.
Since the services are managed independently, you can configure each service to work well for different types of operations. For example, you may want to allow more instances and set longer time-outs to support replication operations with a geodata service. With the map service, however, you may want to keep shorter time-outs and limit the maximum number of instances to support operations such as viewing.
Follow these steps to publish a geodata service with a map service:
Geodata services expose three capabilities. You can enable these capabilities when you create the service, or you can enable them later by editing the service properties:
WCS makes the raster contents of your geodatabase available as an Open Geospatial Consortium, Inc. (OGC) Web Coverage Service (WCS). WCS is an open specification for serving raster data over the Web. The WCS capability is not enabled by default.
WFS makes the vector contents of your geodatabase available as an OGC Web Feature Service (WFS). WFS is an open specification for serving data as vector features over the Web. The WFS capability is not enabled by default.
By default, geodata services are created with Query and Data extraction as allowed operations. To perform geodatabase replication, you must manually allow the Replication operation. See this link from Tuning and configuring services to learn about operations and how to set them.
When configuring a geodata service, consider the following:
Output directory vs. embedding data: Replica operations, such as replica creation and synchronization, as well as data extraction involve data transfer. If you do not set an output directory for the geodata service, the data is transferred embedded with the messages sent and received by the server. This is subject to a maximum message size limit, which is 5 MB by default.
If you plan on creating large replicas, synchronizing large numbers of edits, or extracting large amounts of data, it is recommended that you set an output directory. Contents are uploaded and downloaded from the output directories independently of the service messages. This allows you to perform these larger operations without exceeding message size limits. In some cases, it will also reduce the total amount of data transfer needed to complete the operation.
Geodata service allowed operations: By default, the Query and Extract operations are enabled. With these operations, you can perform read-only actions such as extracting copies of data or performing queries from a published geodatabase. If you have ArcGIS Desktop and an ArcGIS Server Standard edition license, you can use the data extraction command in ArcMap to extract copies. To perform queries, you must write code using the SDK. Replication, which exposes the ability to update the published geodatabase, is not enabled by default. To allow the Replication operation, use the Capabilities tab or panel on the Service Properties dialog box.
Implementing security: When publishing geodata services for access over the internet, you may want to enable HTTP authentication for security reasons. This will require clients to log in when attempting to access the service. It is also important to enable HTTP authentication for both the geodata service and the virtual output directory. When enabling HTTP authentication, make sure the same users can access both the geodata service and the virtual output directory. Messages should also be encrypted since they will include login information. You can use an encrypted communication channel which can be enabled through secure sockets layer (SSL) to do this.
A client can connect via LAN or Internet to ArcGIS Server. Enabling HTTP authentication for the geodata service and its associated virtual directory is supported only for Internet connections to the server. For instance, you can connect via Internet to a secured geodata service and extract data into a local file geodatabase or create a replica to a local ArcSDE geodatabase in SQL Server Express. The same credentials used to connect to the service are used when downloading the data from the virtual directory.
On the other hand, connecting via LAN to the same secured service will fail to download the data from the virtual directory.
Techniques for creating replicas from geodata services: Several tools and options are available for creating replicas from geodata services. Choosing the most appropriate method depends on the situation.
If you can connect to the geodatabase locally, use the local connection to specify the geodatabase to replicate to instead of a connection to a geodata service. If you must use a geodata service, be aware that the operation may time out. By default, the time-out time is 600 seconds per geodata service. You can increase the time-out by setting the maximum time a client can use a service in the geodata service properties.
If you are creating a replica for a very large amount of data, consider using the Register Existing Data option in the Create Replica wizard in ArcMap. To use this option, the data must already exist in both geodatabases. The option is more efficient since it doesn't copy data. It simply validates that the data exists and registers the replicas in the geodatabases referenced by the geodata services. To get the data from the source geodatabase to the destination geodatabase, you can do the following:
The following diagram and examples describe how geodata services are consumed:
Enterprise geodatabase: In the diagram above, a replica exists between an enterprise geodatabase in New York and an enterprise geodatabase in Los Angeles. The replica was created by first publishing the Los Angeles geodatabase as a geodata service with the Replication operation enabled in ArcGIS Server. An administrator in New York then accessed this geodata service over the Internet and used the ArcGIS Desktop tools to create a replica. (See the preceding section for information on how you can create replicas from geodata services.)
Once replicated, editors perform updates to each enterprise geodatabase locally. The administrator in New York periodically runs a geoprocessing model to connect to the geodata service in Los Angeles and synchronize changes in both directions. This keeps the geodatabases synchronized, allowing users to access the same information at either location.
Single user geodatabases: There are also replicas between the Los Angeles enterprise geodatabase and local geodatabases running on field workers' laptops. The field workers disconnect from the network, make updates to their local geodatabases during the day, then synchronize with the Los Angeles database at the end of each day.
In this case, field workers can use checkout replicas to personal or file geodatabases. At the end of each day, the laptops are connected to the Los Angeles geodatabase, and changes are checked in. Once check-in completes, new checkouts need to be created for the next day's work. This can be done using a geoprocessing model that is scheduled to run overnight. To avoid having to run the checkout process each night, two-way replicas can be used instead of checkout replicas. A two-way replica allows multiple synchronizations, which can both send and receive changes. Therefore, at the end of the day, each laptop can run through a synchronization process to both upload changes and get the latest modifications from the Los Angeles geodatabase. ArcSDE geodatabases in SQL Server Express running on each laptop can be used to create the two-way replicas.
These processes can be run locally in the office by plugging the field laptops into the LAN each night. In cases where the field workers are too remote to make it back to the office each night, they can also run the processes on the Internet. Here, instead of accessing the geodatabase directly, they connect to the geodata service published for the Los Angeles geodatabase over the Internet.
Once integrated, the changes from the field workers are also shared with the New York office when the enterprise offices synchronize.
The URL for a Web-enabled geodata service takes the following format:
http://<server name>/<instance name>/services/<folder name (if the service resides in a folder)>/<service name>/GeoDataServer
For example, if you had a service Lima in the folder Peru running on a server myServer with the default instance name of arcgis, the URL would look like this:
http://myServer/arcgis/services/Peru/Lima/GeoDataServer