Developing Web applications using the Web ADF  

Overview of the Web ADF Architecture



Before you dig into your first example, it will be helpful to have a high-level overview of the Web ADF architecture. There are three tiers to the Web ADF architecture. The first tier is the view, or client tier, which is composed of the Web controls; the bottom of the stack is the GIS business objects tier, or model tier 2; and in between these are the model tier 1 objects that mediate between the view tier and the GIS business objects (figure 1).

Class diagram for Web ADF

Figure 1 - A high-level overview of the objects in the Web ADF. Please note that "Model" in the diagram refers to model in the Model-View-Controller (MVC) pattern. The (...) represents the presence of other similar objects.

 

The controls are the first tier, and they cover the view/controller part of the MVC architecture. Controls are in both the view and controller because they not only interact with and render output to the client but can also affect application flow during the phases of the request lifecycle. The Javadoc for the controls can be found in the package com.esri.adf.web.faces.component.

The tier below the controls is the first tier of the model in the MVC architecture; these are the data objects that work directly with the Web controls. These objects usually connect to business objects in other tiers but are not required to. The controlling object at this tier is the WebContext, which not only controls connections to resources (data sources) but also coordinates state between all the other objects in this tier. For that reason, all the other objects are registered as attributes on the context. By being attributes on the context and implementing an interface which will be covered later, they are notified about changes in application state as well as custom phases of the request life cycle provided by the Web ADF.

Other objects in this tier, such as WebMap and WebGeocode, contain information about the control they represent. For example if you look at the Javadoc for WebMap, there are properties for DPI of the output image, the height and width of the image, and various other attributes of the rendered map. There are also methods for working with the map, such as centerAt and getCurrentExtent. You can use these methods to obtain functionality without having to work against the server object directly. Similar properties and methods can be found on the other objects in this tier. The Javadoc for these objects can be found in the com.esri.adf.web.data package.

Also within this package are the interfaces and base classes for model tier 2. These objects, such as GISResource and MapFunctionality, are not tied to working with any of the presentation tier; instead they are closely tied to GIS data and analysis. There are two parent objects in this tier that are crucial to the Web ADF, the GISResource and the GISFunctionality. A GISResource is a data source that the Web ADF will use for display or analysis, and a GISFunctionality is used to expose GIS/mapping functionality for a particular GISResource. For example, the Web ADF has AGSMapResource, which is the concrete implementation of the GISResource to work with an ArcGIS Server Map Server data source. This resource will make the connection to the server and will be used by the functionalities, such as AGSMapFunctionality, to make calls to the server. There must be a child of the GISResource for every data source used in the application. Out of the box, the Web ADF has a resource for the following:

  1. ArcGIS Server using the Server API
  2. ArcGIS Server using Web services
  3. ArcIMS Server using the Java Connector
  4. ArcWeb Services using Web services
  5. WMS Servers
  6. ArcGIS Server EJBs

 

For a resource to work with the Web ADF framework, it must be associated with the context. Since the context is the controlling object for the other data objects of the controls, it coordinates pulling information from the appropriate resources and updating the controls.

The GISFunctionality interface is implemented by any class that will expose functionalities for particular GISResources. There are several subinterfaces that come out of the box for shared or common functionality, such as GeocodeFunctionality for working with geocoders, or TocFunctionality, for creating a list of layers in a table of contents. For a data source to expose a functionality, there has to be a concrete class. Certain data sources don't support certain functionalities. For example, there is no geocode functionality for a WMS server.

The key points covered in this article are as follows:

  1. There are three tiers to the Web ADF:
  2. In model tier 1, the controlling object is the context, and all the other controls have to be attributes of the context to work properly.
  3. In model tier 2, there is a concrete implementation of GISResource for each data resource.
  4. For a resource to work with the controls it has to be registered with the context.
  5. In model tier 2, there is a concrete implementation of GISFunctionality for each functionality for each data source that has that type of functionality.
  6. Each of the model tiers exposes functionality that you can use out of the box without having to communicate directly with the corresponding servers.
  7.  

With this understanding of JSF and the ArcGIS Web ADF, you can move on to building your first JSF application using either the ArcGIS Server Web ADF Java Platform connecting to ArcGIS Server or the ArcIMS Web ADF Java Platform.