When publishing a geoprocessing service, you can choose to view the result of your task as a map (in addition to any other results of your task). The map is created on the server using ArcMap for transport back to the client as an image (a .jpeg, for example). The symbology, labeling, transparency, and all other properties of the returned map are the same as the output layer in your current ArcMap session.
Project data is a term used by geoprocessing to describe input data that is not a parameter; that is, the data is not supplied by the user of the tool or task, but is used internally by the tool or task. For example, the San Francisco Network Dataset variable in the model below is project data because it is used by the model but not exposed as a parameter. Essentially, a model's project data is a blue oval without a P next to it.
Project data can appear in scripts as well, as shown in the Python code snippet below.
A data store is a catalog of data that can be found on the server. The data store is a way for you to give the server a list of data locations that the server can access. When the data can be accessed by the server, the data found on your local machine will not be copied to the server when publishing. Typically, you use the data store for your project data.
When you create a geoprocessing task within a geoprocessing service, you decide how the client will input values for each task parameter by choosing an input mode for the parameter value. In general, there are three input modes:
A GIS service has to work with the simplest of all clients: a web browser running on a computer that does not have any GIS capabilities. Such simple clients know only how to transport (send and receive) packets of simple data to a server, such as text, numbers, files, and geographic features and their attributes (fields). In the context of geoprocessing tasks, GIS datasets can be divided into two distinct categories: transportable and non-transportable.
Asynchronous and synchronous define how the client will submit parameters for execution and get the result from the task. When a service is set to synchronous, the client waits for the task to finish. Typically, a synchronous task executes quickly—5 seconds or less. An asynchronous task typically takes longer to execute and the client must periodically ask the server if the task has finished, and if it has finished, get the result. A web application using an asynchronous task must have logic implemented to check the status of a task and handle the result once execution is finished.