Getting started with the Web ADF

---

The Web Application Developer Framework (ADF) offers a number of ways to create Web applications. To create a Web application without writing code, use ArcGIS Server Manager ("Manager"). Manager creates a predefined Web application, based on the Web Mapping Application template, that is ready for deployment. Although Manager provides a number of options to customize your Web application, you can extend it further.

For additional information on Manager, In help system browse to Creating ArcGIS Server Solutions > Creating Web applications > ArcGIS Server Manager > Creating a new Web application in Manager, or access the help system in the Manager application. 

For additional information on customizing the Web application generated by Manager, see Customizing the Web Mapping Application.

While generating Web applications via Manager offers a quick and easy solution to create and deploy a Web ADF application, the Web ADF is designed as a full featured development environment with a set of controls, frameworks, and application programming interfaces (APIs) to create custom Web solutions. Because the Web ADF is built on Microsoft ASP.NET, you should be proficient in the techniques and technologies of ASP.NET Web development.

Web application development can take many forms. Client-side development leverages browser technologies—for example, Hypertext Markup Language (HTML), JavaScript, and Cascading Style Sheets (CSS)—to provide an interactive interface and to off load application logic for processing on the client. However, browser capabilities are often limited; security restrictions hinder resource access, remote services can be utilized via Hypertext Transfer Protocol (HTTP) only, and the scripting environment provides a somewhat rudimentary (sometimes unstable) platform for execution logic. Server-side development involves packaging application logic in the server or Web-tier with access to internal proprietary services and resources.

The full-featured, stable, true object-oriented development environment of the .NET Framework is accessible and extensible. ASP.NET Web controls encapsulate business logic on the server or Web-tier and provide presentation content to the client browser. Some client-side support content is provided (for example, JavaScript) to enable client-side interactivity with the server, but the majority of application logic resides on the server.

The ArcGIS Web ADF combines both in a hybrid approach to Web development by including client and server logic to balance performance and functionality. The Web ADF includes server-side Web controls with a scriptable interface so they can be utilized directly via JavaScript in a browser. The ASP.NET AJAX JavaScript Library provides a foundation for the Web ADF JavaScript Library to manage client events and synchronize state with server-side Web controls.

As an ADF developer, you need to be familiar with various Web technologies to take full advantage of Web ADF components in a custom ASP.NET Web application. These technologies include the following:

You also need to be familiar with Internet Information Services (IIS), the platform on which you will deploy your Web applications. Information related to enhancing performance, managing scalability, maintaining state, and monitoring ASP.NET worker process operations will benefit you when deploying a custom solution.

As an ASP.NET Web developer using Web ADF components, application requirements combined with your skill level dictate how functionality is added to and integrated in a Web application. In general, functionality is added to Web applications or components to handle user actions, process inputs, and generate results. How functionality is packaged for use in a Web application depends on whether you are a Page developer or a Server Control developer.

Page developers add functionality to a Web page by using Web controls, handling events on controls or the page, wiring up custom events, adding logic for custom actions to a code file, or packaging related content into user controls. These options are shown in the following graphic. Business logic is designed for a specific Web application, and the developer knows exactly what the application contains.

Most ASP.NET developers use Visual Studio 2005\2008 to create custom Web applications with Web ADF controls and components. To get started as a Page developer, you can open a Web application generated by Manager, use the Web Mapping Application template integrated with Visual Studio, or create a custom Web application from scratch. You can also modify an existing Web application by adding Web ADF controls or components.

A set of tutorials starts with the template and progresses through more complex topics, such as custom tool implementation and data source specific interaction. The Web ADF includes out-of-the-box Web controls on which you can handle events. Adding custom functionality can involve adding a custom toolbar item that uses Web ADF core classes, using the task framework to display results, creating a custom user control that contain Web ADF controls, or leveraging the Web ADF JavaScript Library to take advantage of browser capabilities.

Server Control developers extend or create custom composite Web controls designed to encapsulate business logic in a distributable component. These functionality options are shown in the following graphic. Creating custom Web controls means understanding how to construct a control interface programmatically and leverage control lifecycle with business logic as it operates within a page.

The custom Web control can be dependent on another control but generally it cannot depend on other page code, controls, or content. As a result, Server Control developers must include logic to check for the availability of a component. For example, the Page developer knows that if a ScriptManager is present in a page, the developer can work with the control reference in the page. Server Control developers may not know if the Web control they created is being utilized in a page with a ScriptManager. As a result, logic within the custom Web control must check for the presence of a ScriptManager and handle situations where one is not available.

While creating custom Web controls is more flexible than adding functionality to a page, implementation is more complex. In some cases, an ASP.NET Web developer operates as both  a Page developer and a Server Control developer to take advantage of both patterns when creating a custom Web solution. 

Server Control developers either extend an existing Web ADF control to add or modify functionality or create a custom composite Web control that contains Web ADF controls. This includes leveraging the Web ADF task framework to extend out-of-the-box Web ADF tasks or create new custom Web tasks (Web controls) that can be integrated with Visual Studio and Manager.

Another common situation involves packaging custom Web ADF controls and content in a single composite Web control for deployment in a portal (for example, SharePoint), multiview, or template. You start this process by creating a custom class library project in Visual Studio and implementing the appropriate interfaces or extending the appropriate classes to generate a custom Web control for the desired deployment environment.

In either case, business logic in a page or control can require working with one or more data sources at the same time. It is important to understand the relationship between Web ADF components and APIs that consolidate and use different data sources using a common methodology. From a data source perspective, the Web ADF provides custom Web controls to display and interact with map, geocode, and geoprocessing data from multiple data sources. This capability is based on a Common Data Source API (Common API) designed so that Web ADF controls can interact with different data sources in the same way. The following diagram shows the development paths that are available, increasing in complexity and functionality from path I to IV.

In general, the best practice is to start with the simplest path available and select a more complex path only when necessary. Selecting a more complex path depends on the functionality needed in your application. Developer paths I, II, and III are specific to the Web ADF. If you can accomplish the task using the out-of-the-box Web controls, use path I. If you want to customize the Web ADF to work with all data source types by using generic functionalities in the Common API, use path II. If you want to customize the Web ADF to work with a specific data source implementation of Common API functionality, use path III. For more information, see Working with the Common Data Source API.

To use functionality associated with a specific data source (such as an ArcGIS Server server object or an ArcIMS service), a data source specific API can be provided. This option is associated with developer path IV and offers the most functionality since you are working directly with the data source API. Most APIs can be used independent of the Web ADF controls and Common API. Data source specific components are installed with the Web ADF to support ArcGIS Server and ArcIMS.

ArcGIS Server data sources are supported by two APIs, ArcObjects and SOAP. In the Web ADF, both ArcGIS Server local and Internet data sources are built on the SOAP API; however, local data sources also offer access to the ArcObjects API. For more information, see ArcGIS Server implementation. Since the SOAP and ArcObjects APIs can be used apart from the Web ADF, two separate topics discuss their capabilities. Working with the ArcGIS Server SOAP API discusses the implementation and use of standard SOAP-based proxies and value objects for stateless communication with ArcGIS Server services. ArcObjects SDK for Microsoft .NET (installed separately) > Developing with ArcGIS Server includes various topics discussing programming techniques and capabilities of working with both coarse and fine-grained ArcObjects remotely via ArcGIS Server. ArcGIS Server also provides the ability to customize and extend functionality on the server. For more information on this refer to ArcObjects SDK for .NET >Developing with ArcGIS Server >Extending ArcGIS Server.

ArcIMS data sources are supported by the pure .NET ArcIMS API. For more information, see Introduction to the ArcIMS API.