ID | IEP-79 |
Author | Pavel Pereslegin |
Sponsor | |
Created | 13 Oct 2021 |
Status | DRAFT |
When implementing microservices, users are often face with the task of separating the business logic from the common "middleware" logic.
An example of a typical “middleware” task is auditing calls to business service methods (the system must understand which user called which methods and with what result).
Modern frameworks such as gRPC[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.
The Ignite Service Grid must support the following capabilities:
ServiceCallContext - immutable user parameter map that will be implicitly passed to the service (and interceptor) on every method call.
ServiceCallInterceptor - intercepts service method calls.
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).
Interceptor must support ignite instance resource injection.
Interceptor should support LifeCycleAware
Interceptor only applies to user-defined service methods and does not apply to service lifecycle methods - init, execute and cancel,
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 an interceptor has been specified, but the user has not passed the caller context through the proxy, then for each call to the service method, an empty context will be dynamically created.
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.
Interceptor can only throw unchecked exceptions.
Any runtime exception thrown by the onInvoke/onComplete methods will be wrapped in a ServiceInterceptException. This exception will be passed to the initiator (user) and to onError method of the interceptor.
If onInvoke throws an exception, then the service method will not be called.
The exception thrown by the onError method will be added to the main exception as suppressed.
[1] https://pkg.go.dev/github.com/grpc-ecosystem/go-grpc-middleware