I like (1) options.
@ServiceRequestContextResource
private Function<String, Object> ctxFunc;
Because, we use this style of API for injection of other resources - logger,
ignite instance, etc.
It may be confusing for the user to use several API styles for solving similar
tasks.
> 19 окт. 2021 г., в 11:04, Pavel Tupitsyn <ptupit...@apache.org> написал(а):
>
> (2) seems to be the cleanest and most discoverable to me,
> also simpler to implement (no reflection necessary).
>
> But existing ServiceContext properties are for the entire instance, not for
> the current call.
> So, to make it clear and obvious, let's do
> ServiceContext.currentCallContext().attribute(...).
>
> On Mon, Oct 18, 2021 at 7:20 PM Pavel Pereslegin <xxt...@gmail.com> wrote:
>
>> Folks,
>>
>> I agree with Ivan that we can improve the user experience in Ignite
>> services by adding support for "middleware".
>> And as a first step, we need to pass the "caller context" to the service.
>>
>> I see the following API options for reading this "context" inside a
>> service:
>> (please see "API proposal" section in Jira [1] for full formatted examples)
>>
>> 1. Using a custom annotation (ServiceRequestContextResource) and
>> reading context attributes with a function.
>>
>> @ServiceRequestContextResource
>> private Function<String, Object> ctxFunc;
>>
>> public void serviceMethod() {
>> String login = (String)ctxFunc.apply("login");
>> }
>>
>> 2. Using a new method of the existing ServiceContext.
>>
>> private ServiceContext svcCtx;
>>
>> public void init(ServiceContext svcCtx) {
>> this.svcCtx = svcCtx;
>> }
>>
>> public void serviceMethod() {
>> String login = svcCtx.attribute("login");
>> // and/or
>> String login = (String)svcCtx.attributes().get("login");
>> }
>>
>>
>> The next two options require wrapping Map<String, Object> into a new
>> ServiceRequestContext class.
>>
>> 3. Read context "wrapper" using special annotation and supplier.
>>
>> @ServiceRequestContextResource
>> private Supplier<ServiceRequestContext> ctxSupplier;
>>
>> public void serviceMethod() {
>> String login = ctxSupplier.get().attribute("login");
>> }
>>
>> 4. Using the special static method of the "wrapper" class.
>>
>> public void serviceMethod() {
>> String login = ServiceRequestContext.current().attribute("login");
>> }
>>
>> Let's discuss which one is the way to go.
>>
>> [1] https://issues.apache.org/jira/browse/IGNITE-15572
>>
>> вт, 12 окт. 2021 г. в 13:51, Ivan Daschinsky <ivanda...@gmail.com>:
>>>
>>> Hi, Val
>>>
>>>>> The examples you mentioned are more related to internal activities
>> (e.g.,
>>>>> if authentication is handled by an Ignite server node, it can create
>> its
>>>>> internal context for a connection - this is certainly reasonable). I'm
>>> only
>>>>> worried about exposing this to the end user.
>>>
>>> I'm talking about not Ignite auth, but external auth. Here I am
>> considering
>>> Ignite Service Grid as a microservice platform.
>>> Authentication microservice can be not related to Ignite at all, but
>> author
>>> of service may want to retrieve or authenticate user by user_id, that is
>>> provided in request headers or context in jwt token, for example.
>>>
>>> The same is for tracing or metrics. Ignite internal mechanisms here
>> cannot
>>> help at all, because there is no context related to user's code.
>>>
>>> If we want to leave Ignite Service Grid as dump as possible, it is ok.
>> But
>>> therefore it cannot compete with more functional variants.
>>>
>>> But just adding request headers at first step and custom interceptors
>>> (client and server side) we can give to user's of Ignite Service Grid a
>>> lot of opportunities.
>>>
>>> There is an example of golang grpc middlewares -- see how many
>> interesting
>>> use cases here:
>>> https://github.com/grpc-ecosystem/go-grpc-middleware
>>>
>>> вт, 12 окт. 2021 г. в 07:31, Valentin Kulichenko <
>>> valentin.kuliche...@gmail.com>:
>>>
>>>> Ivan,
>>>>
>>>> I'm a bit confused :) Unless I misread the initial suggestion, the
>> idea is
>>>> to provide a public API to create the context. In other words, it will
>> be
>>>> up to the end user to create this context properly, which affects the
>>>> business code - and that's exactly where I see an issue.
>>>>
>>>> The examples you mentioned are more related to internal activities
>> (e.g.,
>>>> if authentication is handled by an Ignite server node, it can create
>> its
>>>> internal context for a connection - this is certainly reasonable). I'm
>> only
>>>> worried about exposing this to the end user.
>>>>
>>>> Maybe you can pick one of the use cases that you think would benefit
>> from
>>>> this feature the most, and provide a little more detail? How would you
>> like
>>>> to see the use case to be addressed and what is currently missing?
>>>>
>>>> Also, just to be clear: I'm not necessarily against the suggestion, and
>>>> it's highly unlikely that I will want to veto it if you or someone else
>>>> will decide to implement it. Just expressing my concerns.
>>>>
>>>> -Val
>>>>
>>>> On Sun, Oct 10, 2021 at 11:52 PM Nikolay Izhikov <nizhi...@apache.org>
>>>> wrote:
>>>>
>>>>> +1 to have service proxy context.
>>>>>
>>>>>> 11 окт. 2021 г., в 09:43, Ivan Daschinsky <ivanda...@gmail.com>
>>>>> написал(а):
>>>>>>
>>>>>> Val, Pavel both of you are right, but on the other hand there are
>> some
>>>>>> other tasks
>>>>>>
>>>>>> 1. Distributed tracing.
>>>>>> 2. Custom metrics/measurements
>>>>>> 3. Auth and some related tasks (i.e. ingests full User info by
>> calling
>>>>> some
>>>>>> auth service in middleware).
>>>>>>
>>>>>> Do you both think that this is a good idea in business code?
>>>>>>
>>>>>> Without this functionality, our service grid cannot compete with
>> grpc
>>>> and
>>>>>> others as microservice framework, unfortunately.
>>>>>>
>>>>>> But if we introduce limited support for this "request headers", it
>> can
>>>>>> drastically improves this aspects of our service grid framework.
>>>>>>
>>>>>>
>>>>>> пн, 11 окт. 2021 г. в 00:48, Valentin Kulichenko <
>>>>>> valentin.kuliche...@gmail.com>:
>>>>>>
>>>>>>> I agree with Pavel. The suggested approach is indeed utilized
>> quite
>>>>>>> frequently, but it's inherently error-prone.
>>>>>>>
>>>>>>> The main issue is that it creates implicit assumptions about the
>>>>> behavior
>>>>>>> of both the service and the user's code. For example, if the
>> user's
>>>> code
>>>>>>> must provide a username, what if it doesn't? I assume it will get
>> an
>>>>> error,
>>>>>>> which is very counterintuitive. Even more importantly, how should
>> one
>>>>> learn
>>>>>>> about this requirement in the first place? It is not reflected in
>> the
>>>>> API
>>>>>>> in any way - and that's a big problem.
>>>>>>>
>>>>>>> The fact that the service implementor needs to update the API
>> methods
>>>>> when
>>>>>>> such requirements are introduced is actually a good thing, in my
>>>>> opinion.
>>>>>>> This forces the developer to stop and think about how the updated
>> API
>>>>>>> should look like and how to make sure it's backward-compatible (or
>>>> not,
>>>>> in
>>>>>>> case the new requirements are mandatory). Doing this through an
>>>> external
>>>>>>> context is basically the equivalent of saying "let the end user
>> deal
>>>>> with
>>>>>>> this". Not a good practice, in my view.
>>>>>>>
>>>>>>> Conversely, passing everything exclusively via method arguments
>>>>> guarantees
>>>>>>> that:
>>>>>>>
>>>>>>> - The user's code is always compliant with the service
>> contract. You
>>>>>>> can't "forget" to pass something to the service.
>>>>>>> - Any changes in the service contract (backward-compatible or
>>>>> otherwise)
>>>>>>> are explicitly reflected in the API.
>>>>>>>
>>>>>>>
>>>>>>> -Val
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Oct 10, 2021 at 6:21 AM Pavel Tupitsyn <
>> ptupit...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ivan,
>>>>>>>>
>>>>>>>> Yes, this approach is used by some other systems, and still, I
>> don't
>>>>> like
>>>>>>>> it very much.
>>>>>>>> Let's hear more opinions.
>>>>>>>>
>>>>>>>> On Sat, Oct 9, 2021 at 9:00 PM Ivan Daschinsky <
>> ivanda...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi.
>>>>>>>>> Pavel T., Ok, http rest dosn't have the clean design, in your
>>>> opinion.
>>>>>>>>>
>>>>>>>>> But what about grpc? The same?
>>>>>>>>>
>>>>>>>>> As for me, it is ok to pass additional parameters as list of
>>>> key-value
>>>>>>>>> pairs with keys as strings and values as bytearrays or strings.
>> It
>>>> is
>>>>>>> ok
>>>>>>>> to
>>>>>>>>> allow user to set up middlewares for services and allow to
>> enrich
>>>>>>> request
>>>>>>>>> context in this middlewares. It is very common approach
>> everywhere
>>>> and
>>>>>>> is
>>>>>>>>> very useful in distributed systems. The use cases are so
>> obvious,
>>>>>>> aren't
>>>>>>>>> they?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> сб, 9 окт. 2021 г., 20:14 Pavel Tupitsyn <ptupit...@apache.org
>>> :
>>>>>>>>>
>>>>>>>>>> Pavel,
>>>>>>>>>>
>>>>>>>>>> Thanks for the explanation, I understand the use cases.
>>>>>>>>>>
>>>>>>>>>>> in REST service, he can set such parameters in request headers
>>>>>>>>>>
>>>>>>>>>> I don't consider HTTP-based services as a good example of a
>>>>>>>>>> clean architecture.
>>>>>>>>>> Data can be passed in URL parameters, in headers, and in body,
>> and
>>>>>>> each
>>>>>>>>> of
>>>>>>>>>> those ways has its own limitations.
>>>>>>>>>> There is no obvious correct way to do things.
>>>>>>>>>>
>>>>>>>>>>>> Ambient state is not obvious and the API looks confusing even
>>>>>>>> though I
>>>>>>>>>> understand our services stack quite well both in Java and .NET
>>>>>>>>>>> Can you clarify please?
>>>>>>>>>>
>>>>>>>>>> The proposed API adds a "side channel" for the data.
>>>>>>>>>> Some is passed as arguments, which is obvious, and some becomes
>>>>>>>> magically
>>>>>>>>>> available on the server side through some external context.
>>>>>>>>>> - You have to know about the context
>>>>>>>>>> - You have to understand that the context is only available
>> during
>>>>>>> the
>>>>>>>>>> method call (can't use it in some background logic)
>>>>>>>>>>
>>>>>>>>>> In my opinion, this is a bit too clever. I'm a fan of the
>>>> functional
>>>>>>>>>> programming approach where everything you need is passed as
>>>>>>> arguments.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Oct 8, 2021 at 4:29 PM Pavel Pereslegin <
>> xxt...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Igor, Pavel.
>>>>>>>>>>>
>>>>>>>>>>>> Why can not a user implement such context on application
>> level? I
>>>>>>>>>>> believe Ignite provides all necessary tools for that.
>>>>>>>>>>> The user wants to trace the source of the service call. For
>>>>>>> example,
>>>>>>>> a
>>>>>>>>>>> service must log the name of the user who made the calls of
>> the
>>>>>>>>>>> service. For now, there's no possibility to do that without
>>>>>>> modifying
>>>>>>>>>>> the service interface and implementation. Moreover, the user
>> must
>>>>>>>>>>> modify all methods of service to pass this parameter. For
>> example,
>>>>>>> in
>>>>>>>>>>> REST service, he can set such parameters in request headers,
>> why
>>>> we
>>>>>>>>>>> can't provide such usability in Ignite.
>>>>>>>>>>>
>>>>>>>>>>>> This will reduce the performance of all calls
>>>>>>>>>>> This feature is optional, if the context is not passed - then
>>>>>>> there's
>>>>>>>>>>> shouldn't be any performance difference.
>>>>>>>>>>>
>>>>>>>>>>>> Ambient state is not obvious and the API looks confusing even
>>>>>>>> though
>>>>>>>>> I
>>>>>>>>>>> understand our services stack quite well both in Java and .NET
>>>>>>>>>>> Can you clarify please?
>>>>>>>>>>>
>>>>>>>>>>> пт, 8 окт. 2021 г. в 15:46, Pavel Tupitsyn <
>> ptupit...@apache.org
>>>>> :
>>>>>>>>>>>>
>>>>>>>>>>>> Agree with Igor.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not sure this feature is a good fit for Ignite.
>>>>>>>>>>>> Ignite should not be responsible for such a high-level
>> concept,
>>>>>>>> this
>>>>>>>>>>> should
>>>>>>>>>>>> be on the application side instead.
>>>>>>>>>>>>
>>>>>>>>>>>> - As Eduard noted, it is hard to make this type-safe
>>>>>>>>>>>> - Ambient state is not obvious and the API looks confusing
>> even
>>>>>>>>> though
>>>>>>>>>> I
>>>>>>>>>>>> understand our services stack quite well both in Java and
>> .NET
>>>>>>>>>>>> - This will reduce the performance of all calls
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Oct 8, 2021 at 3:44 PM Igor Sapego <
>> isap...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi guys,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why can not a user implement such context on application
>> level?
>>>>>>>>>>>>> I believe Ignite provides all necessary tools for that. User
>>>>>>> can
>>>>>>>>> just
>>>>>>>>>>>>> implement such a context as user type and pass it to
>> services
>>>>>>>> they
>>>>>>>>>>>>> need. Are the arguments why would Ignite need a separate
>>>>>>> feature
>>>>>>>>>>>>> for such a use case?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Igor
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Oct 8, 2021 at 2:17 PM Eduard Rakhmankulov <
>>>>>>>>>>> erixon...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I am not aware .NET capabilities, but as I can see service
>>>>>>> must
>>>>>>>>> be
>>>>>>>>>>>>>> implemented in *java* and even if can't serialize other
>> that
>>>>>>>> Map
>>>>>>>>> on
>>>>>>>>>>> .NET
>>>>>>>>>>>>>> side, on java side we can wrap this map with provided
>>>>>>>>> TypedContext
>>>>>>>>>>>>> (context
>>>>>>>>>>>>>> should be convertible from map in this case).
>>>>>>>>>>>>>> That leads to a situation when Java can use TypedContext
>> but
>>>>>>>>> other
>>>>>>>>>>>>> clients
>>>>>>>>>>>>>> can't. I believe that the majority of services users are
>>>>>>> using
>>>>>>>>> Java
>>>>>>>>>>> and
>>>>>>>>>>>>> it
>>>>>>>>>>>>>> should be taken in accordance.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> P.S. I think it is possible to send plain objects from .NET
>>>>>>>>> context
>>>>>>>>>>> to
>>>>>>>>>>>>>> cluster.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards, Ed
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, 8 Oct 2021 at 14:40, Pavel Pereslegin <
>>>>>>>> xxt...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi, Eduard!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for your feedback.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The idea sounds very good, but don't forget about the
>>>>>>>> platform
>>>>>>>>>>>>> services.
>>>>>>>>>>>>>>> For example, we may call Java service from .Net and
>>>>>>>> vice-versa.
>>>>>>>>>> I'm
>>>>>>>>>>>>>>> not sure if the context can be implemented as a custom
>>>>>>> class
>>>>>>>>>>> (instead
>>>>>>>>>>>>>>> of Map/Dictionary) in this case.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> пт, 8 окт. 2021 г. в 14:21, Eduard Rakhmankulov <
>>>>>>>>>>> erixon...@gmail.com>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi, Pavel
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Is it possible to provide type-safe API for
>>>>>>>>>> ServiceProxyContext ?
>>>>>>>>>>>>>>>> I think constructions like int arg1 =
>>>>>>>> ctx.attribute("arg1");
>>>>>>>>>> are
>>>>>>>>>>>>> error
>>>>>>>>>>>>>>>> prone.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Can we make something like this :
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> //Signature with two generic params which allow the
>>>>>>>> compiler
>>>>>>>>> to
>>>>>>>>>>> check
>>>>>>>>>>>>>>>> if the service will be called with the wrong type
>>>>>>> context.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> public <T extends ContextedWith<CtxType>, CtxType> T
>>>>>>>>>>>>>>>> serviceProxyTyped(ClusterGroup prj, String name, Class<?
>>>>>>>>> super
>>>>>>>>>> T
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> srvcCls, CtxType optCtx, boolean sticky, long timeout)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> //new interface which services with scoped context should
>>>>>>>>>>> implement
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> public interface ContextedWith<T> {
>>>>>>>>>>>>>>>> T getCtx();
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> // implementation can delegate to Map-like context or be
>>>>>>>>> POJO.
>>>>>>>>>>>>>>>> interface MyServiceContext {
>>>>>>>>>>>>>>>> int getArg1();
>>>>>>>>>>>>>>>> String getUserId();
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> class MyService implements
>>>>>>> ContextedWith<MyServiceContext>
>>>>>>>> {
>>>>>>>>>>>>>>>> void doThings() {
>>>>>>>>>>>>>>>> MyServiceContext ctx = getCtx();
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> System.out.println("ctx.getArg1() = " + ctx.getArg1());
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> @Override public MyServiceContext getCtx() {
>>>>>>>>>>>>>>>> return ServiceProxyContext.current();
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards, Ed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, 8 Oct 2021 at 13:26, Pavel Pereslegin <
>>>>>>>>>> xxt...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello Igniters!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I want to implement a feature to support a custom
>>>>>>>> "caller"
>>>>>>>>>>> context
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> ignite services (see example in ticket description
>>>>>>> [1]).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sometimes, when using Ignite services, it becomes
>>>>>>>> necessary
>>>>>>>>>> to
>>>>>>>>>>> pass
>>>>>>>>>>>>>>>>> custom parameters from the "request source" to the
>>>>>>>> service.
>>>>>>>>>>> This is
>>>>>>>>>>>>>>>>> most commonly used to track the origin of a service
>>>>>>> call
>>>>>>>>>> (user
>>>>>>>>>>> id,
>>>>>>>>>>>>>>>>> request id, session id eg see this user question [2]).
>>>>>>>>>>>>>>>>> At the moment, the only way to pass such parameters to
>>>>>>> a
>>>>>>>>>>> service is
>>>>>>>>>>>>>> by
>>>>>>>>>>>>>>>>> adding argument(s) to all called methods of the
>>>>>>> service,
>>>>>>>>>> which
>>>>>>>>>>>>> makes
>>>>>>>>>>>>>>>>> the code messy and also complicates development and
>>>>>>>>>>> maintenance.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I propose letting the user set a custom context for the
>>>>>>>>>> service
>>>>>>>>>>>>> proxy
>>>>>>>>>>>>>>>>> and implicitly pass that context to the methods being
>>>>>>>>> called.
>>>>>>>>>>> This
>>>>>>>>>>>>>>>>> function should not affect the execution of service
>>>>>>>> methods
>>>>>>>>>> in
>>>>>>>>>>> any
>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>>>> unless the user has specified a context.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> An example of using the proposed API [1].
>>>>>>>>>>>>>>>>> PoC (except thin clients) [3].
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-15572
>>>>>>>>>>>>>>>>> [2]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>> https://stackoverflow.com/questions/57459071/apache-ignite-service-grid-service-call-context
>>>>>>>>>>>>>>>>> [3] https://github.com/apache/ignite/pull/9440
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sincerely yours, Ivan Daschinskiy
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Sincerely yours, Ivan Daschinskiy
>>
