Both service interceptors and server object interceptors (SOIs) extend ArcGIS Enterprise by allowing custom logic to run which can intercept requests and response. Although they sit at different layers of architecture, they share the common goal of enhancing, validating, or modifying service behavior. Choosing between them is not an either-or decision. In fact, many enterprise workflows can benefit from using both together.
Differences between service interceptors and SOIs
Server Object Interceptors
Server object interceptors are designed to extend the functionality of map and image services. They intercept and may modify service requests and responses, allowing developers to override or enhance existing service behaviors in ways that remain transparent to clients such as ArcGIS Pro, Map Viewer, and custom applications. Key characteristics of an SOI include:
- Tied to individual service—Once an SOI is registered with ArcGIS Server, it must be explicitly enabled on each target map or image service.
- Tight integration with service internals—An SOI executes within the server object context of a service and has fine-grained access to internal service objects and configuration details.
- Powerful native APIs—Developers can interact with service configuration, layers, and underlying data sources through ArcObjects and other native APIs.
- Supported languages—An SOI can be developed using Java or .NET.
- Wide range of service interfaces—An SOI can intercept REST, SOAP, and OGC (e.g., WMS, WFS) requests.
- Developer experience—Building an SOI generally requires familiarity with ArcObjects and the internal architecture of map and image services.
Service interceptors
Service interceptors, on the other hand, provide a more service-agnostic and lightweight approach to interception. Key characteristics of a service interceptor include:
- Global activation—Once registered with ArcGIS Server, a service interceptor is automatically activated and applies to all services that match the specified URL filtering pattern, without requiring individual service configuration.
- REST-only scope—Interception is limited to REST-based services.
- Limited-service configuration details—A service interceptor executes within the REST handler context and does not have access to internal service configurations or underlying data sources. Available metadata includes user identity, service name, service type, and provider information.
- Simplified development model—A service interceptor is written only in Java and does not require knowledge of ArcObjects, making it more accessible to Java developers without prior experience with ArcObjects.
In essence, SOIs offer deep customization for map and image services, providing full access to internal APIs, while service interceptors offer a broader, REST-centric interception mechanism that is easier to implement and maintain across various service types.
Compatibility of service interceptors and SOIs
It is important to note that service interceptors do not replace SOIs. Instead, both extensibility patterns are designed to complement one another and can coexist within the same ArcGIS Enterprise or standalone ArcGIS Server environment. Service interceptors and SOIs serve different purposes and operate at different layers within the service architecture:
- Service interceptors focus on high-level request and response interception for any REST-based service and are ideal for lightweight, cross-service logic such as logging, authentication, data transformation, or third-party system integration.
- In contrast, SOIs are deeply integrated with map and image services, allowing direct interaction with the internal service configuration and underlying data.
By combining both patterns, organizations can implement powerful, multi-layered customizations tailored to their specific business and technical requirements. For example, a map service could utilize the following:
-
A service interceptor to perform user authentication, audit logging, or request validation.
-
An SOI to manipulate map outputs (including watermarks in backgrounds while accessing map or image services), restrict access to specific layers or data (implementing masking for certain map areas), or dynamically alter the rendering behavior.
Both interceptors can be applied to the same service to fulfill different roles within the service lifecycle and extend ArcGIS Enterprise in a cohesive and modular way.