...

When implementing microservices, users are often faced face with the task of separating the business logic from the common "middleware" logic.

...

Modern frameworks such as gRPC and Apache Thrift provide a very ^[1] provide flexible API for implementing request interceptors, with which you can solve almost any middleware task.

Apache Ignite does not provide any mechanisms for solving such problems in general. The user needs to implement it himself, which often results in a lot of boilerplate code. 

Description

...

The Ignite Service Grid must support the following capabilities:

1. Ability to pass custom context from caller to service (similar to HTTP request headers).
2. Ability to define custom interceptors for service calls.

Suggested design (draft)

Entities

1. RequestContext - shareable map with service method call implicit parameters.
2. Interceptor - executes before call service method.
3. Listener - called after service method

API

Public API

• ServiceCallContext -  immutable user parameter map that can be implicitly passed to the service (and interceptor) on every method call.
  

  Code Block
  language java theme

...

• RDark title

...

• ServiceCallContext.java

...

• collapse true

...

• public interface ServiceCallContext {

...

...

• public

...

• String

...

• attribute(String name); public byte[] binaryAttribute(String name); }

  
  

• ServiceCallInterceptor  - intercepts service method calls.
  

  Code Block
  language java theme RDark title ServiceCallInterceptor.java collapse true
  public interface ServiceCallInterceptor extends Serializable { /** *

...

• Intercepts a call to a service method

...

• . * * @param

...

• mtd Method name. * @param args Method arguments. * @param ctx Service

...

• context. *

...

• @param call Delegated call. * @return Service method call result. */ public

...

• Object

...

• invoke(String

...

• mtd, Object[] args,

...

• ServiceContext ctx, Callable<Object> call) throws Exception; }

  
  

Usage example

/**
 * Listener of the service method invocation.
 */
public interface ServiceCallListener {
    /**
     *
     * @param res Service method call result, if any.
     * @param t Error, if any.
     */
    public void onComplete(@Nullable Object res, @Nullable Throwable t);
}

Implementation requirements/limitations

• All specified interceptors are guaranteed to be executed before calling the service method.
• Listeners are notified asynchronously.
• The server interceptor binds to the service itself (it must be executed where the service is implemented, if on Java then in Java, if on Net then in Net).
• The client interceptor binds to the proxy invocation handler. In fact, the main task of the client interceptor is to transfer the parameters of the caller to the service instance (using the RequestContext).
• If the interceptor throws an exception, the service method is not executed, but the rest of the interceptors are executed. This exception is passed to the user and to the listeners.
• Any interceptor can change the RequestContext.
• RequestContext must be accessible inside the service(?).

Example of usage diagram

    ServiceCallInterceptor security = (mtd, args, ctx, svcCall) -> {
        if (!CustomSecurityProvider.get().access(mtd, ctx.currentCallContext().attribute("sessionId")))
            throw new SecurityException("Method invocation is not permitted");

        // Execute remaining interceptors and service method.
        return svcCall.call();
    };

    ServiceCallInterceptor audit = (mtd, args, ctx, svcCall) -> {
        String sessionId = ctx.currentCallContext().attribute("sessionId");
        AuditProvider prov = AuditProvider.get();

        // Record an event before execution of the method.
        prov.recordStartEvent(ctx.name(), mtd, sessionId);

        try {
            // Execute service method.
            svcCall.call();
        }
        catch (Exception e) {
            // Record error.
            prov.recordError(ctx.name(), mtd, sessionId), e.getMessage());

            // Re-throw exception to initiator.
            throw e;
        }
        finally {
            // Record finish event after execution of the service method.
            prov.recordFinishEvent(ctx.name(), mtd, sessionId);
        }
    }

    ServiceConfiguration svcCfg = new ServiceConfiguration()
        .setName("service")
        .setService(new MyServiceImpl())
        .setMaxPerNodeCount(1)
        .setInterceptors(security, audit);

    // Deploy service.
    ignite.services().deploy(svcCfg);

    // Set context parameters for the service proxy.
    ServiceCallContext callCtx = ServiceCallContext.builder().put("sessionId", sessionId).build();

    // Make service proxy.
    MyService proxy = ignite.services().serviceProxy("service", MyService.class, false, callCtx, 0);

    // A business method call to be intercepted.
    proxy.placeOrder(order1);
    proxy.placeOrder(order2);

Implementation details

Deployment

One service can have several interceptors. They are defined using the service configuration and deployed with the service.

To add/remove interceptor service should be redeployed.

Interceptor is located and executed where the service is implemented (for Java service - on Java side, for .NET-service on .NET side). Its execution should not cause additional serialization).

Invocation order

The user can specify multiple interceptors.Each interceptor invokes the next interceptor in the chain using a delegated call, the last interceptor will call the service method.

So the interceptor specified first in the configuration will process the result of the service method execution last.

Risks and Assumptions

Resource injection

Interceptor must support the injection of generic resources.

Interception scope

Interceptor does not apply to service lifecycle methods - init, execute andcancel,

Service call context

The user can create context (map with custom parameters) and bind it to the service proxy. After that, each call to the proxy method will also implicitly pass context parameters to the service.

Service method can read current context parameters using ServiceContext#currentCallContext method. It is only accessible from the current thread during the execution of a service method.

If one service calls another, then by default the current call context will not be bound to the created proxy - the user must explicitly bind it. But Java service has a special ServiceResource annotation to inject another service proxy into the current service. If the user wants to redirect the current call context to this (injected) proxy, he can set the forwardCallerContext option of this annotation.

Exception handling

Exception thrown by the interceptor will be wrapped into unchecked IgniteException and passed to the initiator.

Risks and Assumptions

The interceptor gives the user full control over the invocation of the service methods, so in case of implementation errors, the user may get unexpected behavior of the service// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.

Discussion Links

https://lists.apache.org/thread.html/r4236c1f23e524dc969bc55057467a2bbe7f9a59a6db7c7fcdc1b7d37%40%3Cdev.ignite.apache.org%3E

Reference Links

// Links to various reference documents, if applicable.

Tickets

[1] https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware

Tickets