I agree the graphic is not very professional and actually pretty cartoonish but I think it is good enough to give a mental picture of the discussion that follows.
On the right end of the above graphic, we can see the ArcGIS server. Although it might seem from the graphic that the SOC is the only component of the ArcGIS server, it is not entirely true. Another component of the server ecosystem is the SOM. I have simplified the diagram a bit and have not shown the SOM or the physical machine(s) that host those components. These facts are not relevant to this discussion.
The goal of any application that integrates ESRI’s ArcGIS Server is to offload geospatial computation to the server side. (Just to be clear, in this discussion the web application (normally hosted by a web application container like Tomcat) is the “client” that requests geospatial computations to the ArcGIS Server that is the “server”. In this discussion we are not going to talk about the DHTLM-JavaScript-CSS based user interface client that resides on a (human) user’s browser.) These geospatial computations are encapsulated by combinations of various ArcObjects.
Since the web application resides in a different process space than the ArcGIS Server (be it on the same machine or on a different machine as shown in the above graphic) how can we get hold of the ArcObjects? Well, ESRI exposes ArcObjects using Microsoft’s DCOM technology. So if you are familiar with DCOM programming (which I am not, so I am not going to dwell on it too much) then you get hold of the DCOM-based ArcObject proxies and invoke the relevant methods directly.
In my case, my web application is a Java based one. One way to make the Java code to invoke methods on ArcGIS hosted ArcObjects is by the use of SOAP. A method invocation is encapsulated in a SOAP message and then transmitted down the wire to the ArcGIS Server which converts the SOAP message to a call on an ArcObject and finally sends the response back to the caller, again using SOAP. We could easily have used DCOM’s in-built serialization protocol if that is supported in Java.
The ADF is made up of 2 primary packages: com.esri.adf.web.data and com.esri.adf.web.faces. The latter package is focused more on the front-end components that make up the web application and is not really the topic of discussion here. The former package can be thought of as containing all the “domain” objects that make up a geospatial application. These domain objects are quite intelligent in the sense that they are aware of where to get data and computation services from and how to manage their own lifecycles. These “intelligent domain” objects come preprogrammed with servicing the most standard geospatial computations. Essentially, these objects are preprogrammed with all the logic necessary to invoke SOAP requests to the ArcGIS Server and marshall and unmarshall data.
In the typical development scenario, the geospatial part of the web application consists of a combination of one or more objects from the com.esri.adf.web.data package. Classes like WebContext, WebMap, WebToc, WebQuery etc all have preprogrammed logic that knows how to interact with the ArcGIS Server to service standard operations like panning a map, zooming in and out, spatial queries etc.
Sometimes, the typical usage may not be enough. During that time one might want to manipulate the ArcObject proxies directly. These come in the package com.esri.arcgisws. Just to be clear, my guess is that the objects in the com.esri.adf.web.data package use the proxies in the com.esri.arcgisws package.
Hopefully the explanation above will help one understand how all the different packages are weaved together in the ESRI Java Web ADF ecosystem.
