Administering ArcGIS for Server (2014)

Appendix B. Server Architecture

During its lifetime, ArcGIS for Server has proven resilient to the advances of technologies. It managed to adopt and evolve as more users started migrating to the technology despite the limitations of its architecture at that time. With 10.1, Esri has introduced a completely new architecture. This enabled the product to consume resources more efficiently and increase the execution throughput effectively utilizing the 64-bit instruction set and hyper multithreading. Upgrading from the previous architecture didn't come free of pain to Server users. The users, especially the developers, had to rewrite their websites along with any libraries they developed if they wanted to migrate to the new version. In this appendix, we will explain the difference between the previous and the new architectures, emphasizing on the benefits of the new architecture.

The rise of ArcGIS Server

When Esri released ArcIMS back in 2000, which was solely designed with one purpose in mind, to share maps over the Internet, they never anticipated that it would take off. The web was at its boom, but people were still reluctant to move from their comfort desktop zone to web browsers. Smart phones hadn't tipped yet, so there was no need for mobility and portability with the GIS data. Despite all that, ArcIMS did spread, and it became one of the most used software for sharing maps. The problem with ArcIMS was that it wasn't designed to run on a distributed environment. Changing the architecture of the product was indeed expensive, especially with all these users having stabled their customizations around this technology. The President of Esri has always been fascinated with the concept of cloud computing and sharing maps over thin clients. Therefore, Esri decided to start a new project. The project was named ArcGIS Server.

ArcGIS Server was designed to scale on multiple machines and was equipped with a load-balancing module to balance the requests between the different machines. Not only you could author, publish, and share maps on Server, but it was also equipped with a new feature, geoprocessing, which made it replace ArcIMS altogether. Users can now run tasks on their data to be processed and returned, and they can even combine different tasks into models and create more complex geoprocessing models. Recently, Esri changed the name of ArcGIS Server to ArcGIS for Server for marketing purposes. Ten years after its release, Esri ceases the support of ArcIMS and refocuses its resources on ArcGIS for Server.

Server architecture 9.x-10.0

The success of ArcGIS for Desktop and the rich fine-grained library of ArcObjects have helped shaping ArcGIS for Server. Server was designed around DCOM technology, which is the core of ArcGIS for Desktop. Although that decision made it possible to ship ArcGIS for Server swiftly, it did introduce a few problems and limitations along the way.

SOM and SOC

Prior to 10.1, GIS services had a number of instances hosted by a set of processes. These processes are called the Server Object Container (SOC) because as their name indicates, they act as a container for the instances. The SOC can be configured to run on separate machines to utilize more resources. These SOC processes are managed by another process called Server Object Manager (SOM). The SOM process can be hosted in a separate machine or in the same machine the SOC is hosted. All the requests are forwarded to the SOM process to control the requests' distribution and load balancing. All communications between SOM and SOC machines are bounded by DCOM, which requires special ports to be opened in order for the data exchange to be successful.

Web server

The Web server is another component of ArcGIS Server that can be installed separately. Websites are published on the Web server, which in turn connects to the SOM machine to consume services.

DCOM

DCOM is a classic Windows approach, which uses dynamic-link libraries for communication. All connections between SOM and SOCs are done through DCOM. There is a built-in Web server as we discussed in Chapter 1, Best Practices for Installing ArcGIS for Server, which replaced all the DCOM internal communication, thus avoiding opening all RPC ports that require firewall permissions. The communication in the new ArcGIS for Server is all wrapped using REST. SOAP is still used in the data exchange between ArcGIS for Desktop and Server. Please refer to Chapter 2, Authoring Web Services, for more details on this subject. The following diagram shows the ArcGIS Server system architecture:

Benefits of a 64-bit architecture

By replacing DCOM, Server has decoupled itself from the ArcGIS for Desktop environment, making it less dependent on the C++ library and the fine-grained ArcObjects, which were written and compiled on a 32-bit architecture. Esri designed a new architecture for Server that allowed migration to the 64-bit architecture, completely rewriting the code for Server along the way. I always like to use this metaphor when explaining the benefits of a 64-bit architecture. Imagine an eight-lane highway where four lanes are used for trucks while regular cars can use the full eight-lane highway. Cars will be able to navigate more smoothly on the highway unlike the trucks, which have only four lanes also shared by other cars. The following figure describes briefly the difference between 64-bit and 32-bit systems in a CPU. Notice how the 64-bit bus is wider, which allows more bits to flow between the memory and the CPU.

[Photo Credit to http://arstechnica.com/]

Trucks are the 32-bit applications running on a 64-bit processor, while regular cars are the 64-bit application getting the full advantage of the 64-bit architecture. The 64-bit applications will get more throughputs in terms of processed bytes and can address more than 4 GB of memory. This is practically useful for raster and image processing where huge chunks of data are moved to the memory where it is sliced and diced.

The CPUs have small storage units called registers. Although registers are very fast in storage and retrieval, they can store a small amount of data. In 32-bit CPUs there are generally eight 32-bit registers. Each register can store up to 4 bytes for fast CPU processing. If all registers are used, the CPU uses the RAM to store and process the data. This process takes more time of course, since the CPU has to send a request to access the RAM and wait for a signal back. In a 64-bit architecture, the size of the registers has been increased to 64-bit (8 bytes). This allows more room in the CPU to store and process more bits before it uses the RAM. Look at the following figure for clarification:

[Photo Credit to http://arstechnica.com/]

Summary

In this appendix, you have learned the difference between the old and the new ArcGIS for Server architecture. You now know the timeline of the hardware and software enhancement that Esri has implemented during its journey of ArcGIS for Server. Server has survived the 32-bit architecture locking-trap, which ArcGIS for Desktop still suffers from and jumped into the more effective 64-bit architecture. Reworking ArcGIS for Server to utilize the 64-bit architecture has improved the software performance to a completely new level.