Resolution Service

Introduction

The Resolution Service is a standalone system component that provides identity and reference resolution capabilities within the DIRX Identity. It is responsible for processing incoming resolution requests and executing the internal resolution logic.

The Resolution Service serves as a modern replacement for the Resolution Adapter (since DXI version 8.10). It is designed as an independent, standalone service that can be deployed and operated separately from the Java application server. This approach enables customers to execute resolution logic in a more flexible, scalable, and observable manner, while maintaining seamless integration with existing system landscapes.

The service is delivered as a Spring Boot application and can be operated as:

  • a Windows service, or

  • a Linux daemon.

Purpose and Value

The primary purpose of the Resolution Service is to decouple resolution logic from the core application server and provide it as a dedicated, reusable system service.

From a system and operational perspective, the Resolution Service offers the following benefits:

Independence and flexibility

The service runs standalone and is not tied to the Java server lifecycle or deployment model.

Operational transparency

Built-in health, metrics, and monitoring endpoints allow administrators to observe system behavior, throughput, and performance.

Modern integration

The service is based on Spring Boot and Spring JMS, enabling easier integration with modern messaging infrastructures and simplifying maintenance and upgrades.

Future-proof architecture

JMS handling, monitoring, and logging are implemented using standard Spring mechanisms, supporting easier migration to future messaging technologies.

Position in the Overall Architecture

Within the overall system architecture, the Resolution Service acts as an intermediary between the messaging infrastructure and the internal resolution logic.

At a high level, the processing flow is as follows:

  1. External systems or internal components send resolution requests via JMS.

  2. The Resolution Service listens on the configured message queue or topic.

  3. The service processes the request using the internal resolver.

  4. Resolution results are applied to DIRX Identity.

The Resolution Service therefore acts as:

  • a message-driven resolution engine,

  • a boundary between messaging and business logic,

  • a central component for identity resolution.

By isolating this responsibility into a dedicated service, the overall system becomes more modular, scalable, and easier to operate.

Resolution Flow and Message Handling

The task of resolving a user is delegated to the Resolution Service.

The Resolution Service listens for resolution requests on the JMS destination:

dxm.request.user.resolve

If the configuration parameter topicIncludesDomain is set to true, the domain name is prefixed to the topic, for example:

my-company.dxm.request.user.resolve

Each incoming message contains:

  • the distinguished name (DN) of the changed user, and

  • the timestamp indicating when the change occurred.

Internal Resolution Process

Upon receiving a message, the internal resolver performs the following steps:

  1. Resolution Lock
    The user is locked using a so-called resolution lock. This ensures that no other resolution process can resolve the same user concurrently.

  2. User Resolution
    The resolver executes the standard resolution logic, which includes:

    • calculating new or removed group assignments,

    • determining required account creations or deletions,

    • applying privilege-based changes.

  3. Concurrency Behavior
    While a user is locked for resolution:

    • no other resolution process can resolve the same user,

    • other clients may still modify the user (for example by assigning or removing privileges).

This mechanism guarantees consistency of resolution while still allowing concurrent administrative changes.

When to Use the Resolution Service

Customers and administrators should consider using the Resolution Service when:

  • they want to replace the legacy Resolution Adapter,

  • they need a standalone resolution component,

  • they require improved scalability and monitoring,

  • they want to decouple resolution from the application server.

In most setups, the Resolution Service can be used as a direct replacement for the existing Resolution Adapter or as an additional optional component, depending on system architecture and operational requirements.