Roadmap for developers

In this topic

---

About roadmap for developers

ArcGIS Server for Microsoft .NET offers developers a robust, standards-based set of components to build and deploy geospatial applications and services with the Microsoft .NET framework. These components are packaged in a set of software development kits (SDKs) for .NET developers. The Server SDK (this help system) and Server content in the ArcObjects SDK for Microsoft .NET (installed separately) include the following:

Software developers can use the ArcGIS Server and ArcObjects SDK for Microsoft .NET to create geographic information system (GIS) solutions in both server and client-side application environments. The purpose of an application and its ease of distribution often dictates which environments are most suitable. 

The following illustration shows the types of applications you can build, and the frameworks and APIs that can be used to work with ArcGIS Server services in these applications. Each application type is discussed in further detail in the following sections in this topic. This Help system includes a section Managing your ArcGIS Server under topic Creating ArcGIS Server solutions > Getting started. This information is provided as a resource for developers interested in learning more about the capabilities and configuration options of an ArcGIS Server services.

The ArcObjects API supports working with ArcGIS Server services remotely using standard coarse and fine grained interfaces and components.  In fact, the ArcGIS Server SOAP and REST APIs are built on the capabilities of coarse grained, stateless ArcObjects interfaces defined for each service type.  ArcObjects can also be utilized locally, within the ArcGIS Server to enhance service capabilities.  This involves creating a custom Server Object Extension, deploying it with ArcGIS Server, and associating it with an ArcGIS Server service.  Server Object Extensions enable the developer to access to the breadth and depth of ArcObjects functionality within a service and expose it to client APIs and frameworks.  In the diagram below, the ArcObjects API is presented as a client API which requires COM proxies to work with ArcObjects remotely, hosted in a service.  Using ArcObjects to extend ArcGIS Server means working with ArcObjects locally and requires knowledge of patterns and practices involved in ArcGIS Engine application development.  In either case, use the ArcObjects SDK to take advantage of ArcObjects capabilities within the context of ArcGIS Server. More information on creating Server Object Extensions is available in ArcObjects SDK for Microsoft .NET under topic Developing with ArcGIS > Developing with ArcGIS Server > Extending ArcGIS Server . 

Web applications

A Web application provides content from a server to a client as a visual interface for a user, often within a Web browser. Much of the business logic, data, and other processes are managed on the server-side using a rich programming environment, such as C# or Visual Basic .NET. Since the user interacts with a Web application by a Web browser, the client-side application is built using Web standards to create a user interface, such as Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and scripting languages, such as JavaScript.
  
A number of resources are provided to get you started. To create feature rich Web applications without writing code, use the Manager Web application. Manager creates a predefined Web application based on the Web Mapping Application template, ready for deployment. For more information, see Introduction to creating Web applications with Manager under Managing your GIS server > Creating Web applications > ArcGIS Server Manager or access the Help system within the Manager application. Although Manager provides a number of options to customize your Web application, you can choose to extend it further. For more information on customizing the Web application generated by Manager, see Customizing the Web Mapping Application.

If you have access to Visual Studio 2005 or 2008, use the Web ADF. The Web ADF provides a comprehensive and extensible framework for developing ArcGIS Server Web applications. The product is built on the Active Server Pages (ASP) .NET Asynchronous JavaScript and XML (AJAX) platform, which is designed to enhance Web application usability and performance. 

The Web ADF includes a set of custom AJAX-enabled Web controls to display and interact with GIS data from multiple data sources as well as a Common Data Source API to interact with different data sources using the same techniques. A task framework is provided to package and distribute custom components to use in a Web ADF application via Manager or Visual Studio. A public Web ADF JavaScript library is also included to leverage pure-browser technology when interacting with server resources. 

The Web ADF JavaScript library is different than the ArcGIS JavaScript APIs used to build pure JavaScript applications. The ArcGIS Server SOAP and ArcObjects APIs are utilized extensively and available within and outside of the Web ADF framework components. For more information, see Developing Web applications using the Web ADF.

Rich Internet applications

Rich Internet applications or RIAs are Web applications that have the functionality of a desktop client.   RIAs are hosted on a Web server, downloaded to a client, and run within a browser.   Typcially an RIA consumes data from remote Web services, includes logic to consolidate and process the data, and utilimately provides the end user with an enhanced presentation environment to visualize and interact with the data.   All RIAs require a client engine which provides the traditional desktop features in a browser.  If the client engine has not been installed, it is usually downloaded and installed along with the application components.  RIAs are often viewed as an alternative to desktop clients, server-side Web applications, and pure-browser JavaScript applications.   Instead of installing a desktop application, an RIA can be distributed and consumed in standard Web browser clients.   RIAs can include operational and presentation logic without requiring a round-trip to the server to process and rerender content, thus reducing network traffic.  In addition, the presentation and interaction capabilities of an RIA are superior to the native scripting environment packaged with a browser.   Note, there are a few limitations associated with RIAs.  Since RIAs run within a browser, they operate within a secure environment known as a sandbox, which limits accessibility to local resources.   In addition, the fact that a client engine must be installed and plugged into the browser can be a concern for some clients.   It's also possible that functionality in a desktop or server-side Web application is not available in an RIAs client engine.

Adobe® FlexTM and Microsoft® SilverlightTM provide a cross-browser, cross-platform development environment for building and delivering rich interactive applications (RIA) for the Web.  ESRI provides two RIA APIs built on these industry standard platforms: the ArcGIS® API for FlexTM and the ArcGIS® API for Microsoft® SilverlightTM.   Both APIs enable you to integrate ArcGIS Server and Microsoft's Bing MapsTM services and capabilities in a rich Internet application.   The core components for both ArcGIS RIA APIs are available for download on the ArcGIS Resource Center.

JavaScript applications

ESRI provides a set of JavaScript APIs that utilize ArcGIS Server services to build light-weight, high performance, pure browser GIS applications, as well as integrate or "mashup" GIS functionality with other content. The JavaScript APIs are built on the ArcGIS Server REST API, a simplified architectural style for accessing resources using an Hypertext Transfer Protocol (HTTP) request. For more information on JavaScript libraries and documentation, see the ArcGIS Resource Center.

The ArcGISJavaScriptAPI is a stand-alone set of components designed to consume ArcGIS Server resources. Use it to embed a map or perform a task, such as querying spatial data, in a JavaScript application.       

The ArcGISJavaScript Extension for MicrosoftBing Maps allows you to extend the Bing Maps SDK to use ArcGIS Server services. With this extension, you can work within the Bing Maps SDK to combine ArcGIS Server resources with a Bing map control. 

The ArcGISJavaScriptExtension for the Google Maps API allows you to extend the Google Maps API to use ArcGIS Server services. With this extension, you can work within the Google Maps API to combine ArcGIS Server resources with Google mapping components.

Mobile applications

Mobile applications are designed for hand-held devices, such as personal digital assistants (PDAs), smart phones, pocket personal computers (PCs), or Tablet PCs. ESRI provides an out-of-the-box ArcGIS Mobile client application and a Mobile SDK. The ArcGIS Mobile client is designed as a pre-packaged solution and is not extensible. The ArcGIS Mobile SDK is packaged with ArcGIS Server and includes an ADF.

Using the Mobile SDK, developers can build geocentric applications that provide basic GIS functionality including map display and navigation, Global Positioning System (GPS) support, and GIS editing. It can also be used to enhance existing non-spatial line-of-business applications, such as customer relationship management and field service automation systems, with geospatial capabilities. ArcGIS Mobile solutions are designed to be deployed to mobile devices and operate in a connected or disconnected environment, allowing updates to be made on the server in real time.

Web services

Web services provide content from a server to a client as information, usually by simple or structured text. Access to business logic, data, and other processes are managed on the server-side using a rich programming environment, such as C# or Visual Basic .NET. Since the user interacts with a Web service programmatically, the Web service developer is responsible for providing access to information on the server using Web standards for Web service description and distribution, such as SOAP, Web Service Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI).

From the ArcGIS perspective, the following types of Web services can be created:

A GIS Web service is an ESRI standard for publishing ArcGIS server objects (an ArcGIS local data source) as an ArcGIS Server Web service (an ArcGIS Internet data source). For more information on publishing GIS Web services, see Managing your GIS server > Publishing services. GIS Web services are not developed, instead they are published and consumed. Some existing ESRI products, such as ArcMap, are designed to consume a GIS Web service without requiring any custom components or developer experience. 

Since a GIS Web service is based on Web service standards, it can also be consumed as a traditional Web service. Two ArcGIS Server core APIs—SOAP and REST—provide standard protocols for interacting with ArcGIS Server services as Web resources. The ArcGIS Server SOAP API and ArcGIS Server REST API can be used by developers to interact programmatically with a GIS Web service.

An application Web service is a custom application built using Web service standards that can programmatically leverage interaction with an ESRI data source. Since Web services do not have a user interface, Web controls are not appropriate. Instead, working with ArcGIS Server core APIs—REST, SOAP, and ArcObjects—offer the best option for accessing ArcGIS Server capabilities. For more information about the development of a custom application Web service with an ArcGIS Server map and geocode services using the ArcObjects API, in the ArcObject SDK for Microsoft .NET see the sections under Developing with ArcGIS > Developing with ArcGIS Server. 

Desktop client and console applications

Desktop client applications are stand-alone applications with a visual interface, and have the business logic to consume and process local solutions or server solutions via the Web or a local area network (LAN). In general, desktop client applications are created by developers utilizing one or more APIs to access different functionalities. Those functionalities can include adding a control for a visual application or writing code to access and iterate through a data set. Console applications are also stand-alone applications, but offer only a command line (at best) for user interaction. Apart from the user interface, desktop client and console applications share the same basic capabilities for implementing business logic and thus can be grouped in the same category for this discussion. 

In general, all of the core Server APIs provided by ESRI can be utilized programmatically within a desktop client or console application. More specifically, the SOAP and REST APIs are designed from remote access via HTTP. 

The ArcObjects API can be utilized locally or remotely. Working with ArcObjects locally  creates and uses ArcObjects within the same application process. At the most basic level, ArcObjects is installed locally with ArcGIS Engine (runtime). ArcGIS Engine includes a set of controls and APIs that use ArcObjects to interact with GIS resources locally and consume ArcGIS Server services remotely. However, different components must be licensed before being used or distributed. If the ArcObjects SDK for Microsoft .NET is installed, see Welcome to the ArcObjects Help for .NET developers for more information. 

Working with ArcObjects remotely means creating and using ArcObjects in the context of a client-server relationship. The client application process creates ArcObjects in a server process and maintains references to these (remote) ArcObjects instances. This scenario includes a client application that works with ArcObjects via ArcGIS Server. This constitutes the ArcGIS Server ArcObjects API—working with ArcObjects remotely via ArcGIS Server. 

Working with ArcObjects remotely requires at a minimum the ArcObjects Component Object Model (COM) proxies on the client. The ArcObjects COM proxies are used to broker communication between ArcObjects references and instances, both within and across processes. 

In a .NET environment, primary interop assemblies are used to provide type information and manage interoperability with local and remote ArcObjects via the COM proxies. The primary interop assemblies, COM proxies, and connection libraries are included with the installation of ArcGIS Server for .NET (Web ADF runtime and Server Object Container), ArcGIS Engine runtime (via the .NET Support option), and the ArcObjects SDK for the Microsoft .NET Framework.

Server Object Extensions

The client-side APIs and frameworks discussed in this developer help system are designed to consume ArcGIS Server services.  ArcGIS Server includes a set of predefined service types, such as map, geocode, geoprocessing, and feature services, which provide access to established functionality. This functionality is defined in ArcObjects using a set coarse and fine grained interfaces on service components exposed in ArcGIS Server.  In fact the coarse grained, stateless interfaces provide the foundation for service definitions in the SOAP and REST APIs, which are subsequently used by the Web APIs and frameworks.  While service capabilities are very comprehensive, it may still be necessary to enhance a service, or in ArcObjects terms "server object", by extending its functionality.  This can be accomplished using Server Object Extensions, also referred to as SOEs.  Server Object Extensions are significantly different than client APIs and frameworks because they enable a developer to add functionality to an existing service locally, meaning on the server.  A developer can create custom logic in ArcObjects that utilizes service contents and attach it to a specific server object.  The extension executes in process with the service itself and shares its context and lifecycle.  There are two main reasons for creating a SOE:

Concepts and samples that show how to create, customize, and deploy Server Object Extensions are provided in the ArcObjects SDK for Microsoft .NET.  A comprehensive discussion of ArcObjects development with ArcGIS Server is provided under the topic Developing with ArcObjects > Developing with ArcGIS Server.