Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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)

New public API entities

...

Public API

...

Java API

  • ServiceCallContext -  immutable user parameter map that can be implicitly passed to the service

...

  • (and interceptor) on every method call.

  • Code Block
    languagejava
    theme

...

  • RDark
    title

...

  • ServiceCallContext.java

...

  • collapsetrue

...

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


  • ServiceCallInterceptor  - intercepts service method calls.

    Code Block
    languagejava
    themeRDark
    titleServiceCallInterceptor.java
    collapsetrue
    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

...

  • .
         *

...

  •  

...

languagejava
themeConfluence
titleListener
linenumberstrue

...

  • @return Service method call result

...

  • .
         */
        public 

...

  • Object 

...

  • invoke(String mtd, Object[] 

...

  • args, ServiceContext 

...

  • ctx, 

...

  • Callable<Object> 

...

  • call) throws Exception;
    }

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).
  • 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)


Usage example

draw.io Diagram
width
bordertrue
diagramNamemiddleware
simpleViewerfalse
linksauto
tbstyletop
lboxtrue
diagramWidth1001
revision913

...

Code Block

...

Code Block
languagejava
themeConfluenceRDark
titleExample.java
collapselinenumberstrue
    ServiceCallInterceptor security = (mtd, args, ctx, svcCall) -> {
        if (!CustomSecurityProvider.get().checkPermissionsaccess(mtd, ctx.currentCallContext().valueattribute("sessionId")))
            throw new SecurityException("Method invocation is not permitted");

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

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

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

        try {
            AuditProvider.get().recordEvent(mtd, ctx.value("sessionId"), err// 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(Arrays.asList(security, audit));

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

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

    // Set context parameters for Make service proxy.
     MyService proxy = ignite.services().serviceProxy("service", MyService.class, false, Collections.singletonMap("sessionId", sessionId)callCtx, 0);

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

Risks and Assumptions

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.

draw.io Diagram
bordertrue
diagramNameinvocation
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth471
revision3

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

[1] https:/// Links to various reference documents, if applicable.

Tickets

pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware

Tickets

Jira
serverASF JIRA
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
maximumIssues20
jqlQuerylabels = IEP-79 order by fixVersion
serverId5aa69414-a9e9-3523-82ec-879b028fb15b
// Links or report with relevant JIRA tickets.