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.
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.
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 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:
