Advantages of ArcObjects architecture

In this topic

Components of the architecture 

The ArcGIS architecture provides rich functionality to the developer, but it is not a closed system. The ArcGIS architecture is extendable by developers external to ESRI. The main focus of the ArcGIS architecture revolves around the following key concepts:
The following sections discuss each of these concepts.

Modularity

The esriCore object library, shipped as part of ArcGIS 8.3, effectively packaged all of ArcObjects into one large block of geographic information system (GIS) functionality (there was no distinction between components). ArcObjects components were divided into smaller groups of components, these groups being packaged in dynamic-link libraries (DLLs). The one large library—while simplifying the task of development for external developers—prevented the software from being modular. Adding the type information to all DLLs, while possible, would have greatly increased the burden on external developers and, hence, was not an option. In addition, the DLL structure did not always reflect the best modular breakup of software components based on functionality and dependency.
There is always a trade-off in performance and manageability when considering architecture modularity. For each criterion, thought is given to the end use and the required modularity for support. For example, the system could be divided into many small DLLs with only a few objects in each. Although this provides a flexible system for deployment options, at minimum memory requirements, it would affect performance due to the large number of DLLs being loaded and unloaded. Conversely, one large DLL containing all objects is not a suitable solution either. Knowing the requirements of the components allows them to be effectively packaged into DLLs.
ESRI has developed a modular architecture for ArcGIS by a process of analyzing features and functions, and matching those with end user requirements and deployment options based on the three ArcGIS product families. Developers who have extended the ArcGIS 9 architecture with custom components are encouraged to go through the same process to restructure their source code into similar modular structures.
The ArcGIS architecture is divided into a number of libraries. It is possible for a library to have any number of DLLs and executables (EXEs) within it. The requirements that components must meet to be within a library are well defined. For example, a library, such as esriGeometry (from the base services set of modules), has the requirements of being thread-safe, scalable, without user interface (UI) components, and deployable on various computing platforms. These requirements are different from libraries, such as esriArcMap (from the applications category), which has UI components and is a Windows only library.
An obvious functionality split to make is UI and non-UI code. UI libraries tend to be included only with the ArcGIS Desktop products.
All the components in the library will share the same set of requirements placed on the library. It is not possible to subdivide a library into smaller pieces for distribution. The library defines the namespace for all components within it and is seen in a form suitable for your chosen application programming interface (API).

Scalability

ArcObjects components within ArcGIS Engine and ArcGIS Server must be scalable. ArcGIS Engine objects are scalable because they can be used in many different types of applications; some require scalability, while others do not. ArcGIS Server objects are required to be scalable to ensure that the server can handle many users connecting to it, and as the configuration of the server grows, so does the performance of the ArcObjects components running on the server.
The scalability of a system is achieved using a number of variables involving the hardware and software of the system. In this regard, ArcObjects supports scalability with the effective use of memory within the objects and the ability to execute the objects within multithreaded processes.
There are two considerations when multithreaded applications are discussed, thread safety and scalability. It is important for all objects to be thread safe, but simply having thread safe objects does not automatically mean that creating multithreaded applications is straightforward or that the resulting application provides vastly improved performance.
ArcObjects components contained in base services, data access, map analysis, and map presentation categories are all thread safe. This means that application developers can use them in multithreaded applications; however, programmers must still write multithreaded code in such a way as to avoid application failures due to deadlock situations, and so on.
Thread safety refers to concurrent object access from multiple threads.
In addition to ArcObjects components being thread safe, the apartment threading model used by ArcObjects was analyzed to ensure that ArcObjects could be run efficiently in a multithreaded process. A model referred to as "threads in isolation" was used to ensure that ArcObjects architecture is used efficiently.
This model works by reducing cross-thread communication to an absolute minimum or better still, removing it entirely. For this to work, the singleton objects were changed to be singletons per thread and not singletons per process. The resource overhead of hosting multiple singletons in a process was outweighed by the performance gain of stopping cross-thread communication where the singleton object is created in one thread. Normally, the main single-threaded apartment (STA) and the accessing object are in another thread.
ArcGIS is an extensible system and for the threads in isolation model to work, all singleton objects must adhere to this rule. If you are creating singleton objects as part of your development, you must ensure that these objects adhere to the rule.
The classic singleton per process model means that all threads of an application will still access the main thread hosting the singleton objects. This effectively reduces the application to a single-threaded application.

Multiple platform support

As previously stated, ArcObjects components are C++ objects, meaning that any computing platform with a C++ compiler can potentially be a platform for ArcObjects. In addition to the C++ compiler, the platform must also support some basic services required by ArcObjects.
Although many of the platform differences do not affect the way in which ArcObjects components are developed, there are areas where differences do affect the way code is developed. The byte order of different computing architectures varies between little endian and big endian. This is most readily seen when objects read and write data to disk. Data written using one computing platform will not be compatible if read using another platform, unless some decoding work is performed. All ArcGIS Engine and ArcGIS Server objects support this multiple platform persistence model.
ArcObjects components always persist themselves using the little endian model. When the objects read persisted data, it is converted to the appropriate native byte order. In addition to the byte order differences, there are other areas of functionality that differ between platforms. For example, the directory structure uses different separators for Windows and UNIX—\ and /, respectively. Another example is the platform-specific areas of functionality, such as object linking and embedding database (OLE DB).
Microsoft Windows is a little endian platform, while Sun Solaris is a big endian platform.

Compatibility

Maintaining compatibility of the ArcGIS system between releases is important to ensure that external developers are not burdened with changing their code to work with the latest release of the technology. Maintaining compatibility at the object level was a primary goal of ArcGIS 9.x development effort. Although this object-level compatibility has been maintained, there are some changes between ArcGIS 8 and the current architectures that affect developers, mainly related to the compilation of the software.
Although the required changes for software created for use with ArcGIS 8 to work with current ArcGIS are minimal, it is important to understand that to realize any existing investment in the ArcObjects architecture at the current version of ArcGIS, you must review your developments with respect to ArcGIS Engine, ArcGIS Server, and ArcGIS Desktop.
While the aim of ArcGIS releases is to limit the change in the application programming interfaces (APIs), developers should still test their software thoroughly with later releases.
ESRI understands the importance of a unified software architecture and has made numerous changes for ArcGIS so the investment in ArcObjects can be realized on multiple products. If you have been involved in creating extensions to the ArcGIS architecture for ArcGIS 8, you should think about how the current ArcGIS architecture affects the way your components are implemented.