Re: [DISCUSS] Custom service proxy context
Pavel, > I would say it is linear, not geometric. Without service context, there were 2 serviceProxy methods. The patch with service contexts adds two more methods. Each next parameter according to this pattern will add the same amount of methods as there were before. > I suggest introducing "ServiceProxyConfiguration" class Seems to be too complicated :) If we compare two syntaxes with the same final result: ignite.services().serviceProxy(new ServiceProxyConfiguration().setContext(...), ...) vs ignite.services().withContext(...).serviceProxy(...); Second looks simpler and nicer to me. > Can you clarify please, is it going to be a new interface, let's say IgniteServicesSomething, and "IgniteServices extends IgniteServicesSomething"? Yes, ignite.services() returns IgniteServices, ignite.services().withContext(...) returns IgniteServicesSomething, that contains only serviceProxy(...) methods. пн, 20 дек. 2021 г. в 15:32, Pavel Tupitsyn : > Alex, > > > the count of methods will increase in geometric progression > > I would say it is linear, not geometric. > Anyway, a common fix for "too many parameters" issue is Parameter Object > pattern [1], > I suggest introducing "ServiceProxyConfiguration" class. > > > > We already using such an approach in transactions for example, where we > > have withLabel, withTracing modifier > > I'm not sure this is a good approach and I'd like to avoid using it in more > places. > - it looks like a builder pattern, but it is not > - there is no "withoutTracing" so I can't go back > - when I get "IgniteTransactions" instance in some method, I don't know if > tracing is enabled or not, there is no way to check, no way to disable > > > > I'm voting for option (3). > > Can you clarify please, is it going to be a new interface, let's say > IgniteServicesSomething, > and "IgniteServices extends IgniteServicesSomething"? > > > [1] https://wiki.c2.com/?ParameterObject > > On Mon, Dec 20, 2021 at 12:15 PM Alex Plehanov > wrote: > > > Pavel, > > > > As for option (1): the count of methods will increase in geometric > > progression with each new parameter. For example, if we decide to add > > tracing to services, we should keep current methods as-is for backward > > compatibility and add new methods supporting a tracing parameter. > > > > > Also, we don't provide methods like withTimeout, withSticky, so adding > > withContext will introduce another inconsistency. > > We already using such an approach in transactions for example, where we > > have withLabel, withTracing modifier, and the timeout method parameter. I > > think it's nothing wrong here. We can't get rid of timeout and sticky > > parameters due to backward compatibility. > > > > > (3) seems to be too complicate > > I see no complication here. From the user's point of view - almost > nothing > > changed. The user can use the same IgniteService interface when > > using services without modifiers. When using modifiers - only interface > > with methods related to modifiers will be available. In most cases, the > > user even no need to know about this new interface. > > > > I'm voting for option (3). > > > > чт, 16 дек. 2021 г. в 15:59, Pavel Tupitsyn : > > > > > Pavel, > > > > > > My vote is for option (1). Simple and clear. > > > > > > As you noted, with (2) it is not clear which methods are affected. > > > Also, we don't provide methods like withTimeout, withSticky, so adding > > > withContext will introduce another inconsistency. > > > > > > (3) seems to be too complicated. > > > > > > On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin > > wrote: > > > > > > > Hi folks! > > > > > > > > The discussed feature is currently under development and recently > > > > there was a proposal for an API improvement, which I want to discuss. > > > > > > > > It is about how the user can specify a service call context when > > > > getting a proxy. > > > > > > > > I see the following options: > > > > > > > > 1. Passing the context as an argument to the proxy getter method. > > > > > > > >Ignite.services().serviceProxy(name,..., callCtx) > > > > > > > >The disadvantage is that for ease of use, we add several > > > >overloads of this method with different combinations of > parameters. > > > > > > > > 2. Adding a new method "withCallContext(callCtx)" (returns > > > > IgniteServices) to the IgniteServices interface. > > > > > > > >Ignite.services().withCallContext(callCtx).serviceProxy(name,...) > > > > > > > >The disadvantage is that most of the IgniteServices methods > > > >are not related to the service call context (deploy, cancel > > > >of the service, etc.). > > > > > > > > 3. (extension of the 2nd option) Adding a new > > > > "withCallContext(callCtx)" method which returns a new interface. > > > > > > > >Ignite.service().withCallContext(callCtx).serviceProxy(name,...) > > > > > > > >Unlike the 2nd option, the "withCallContext()" method returns a > new > > > > interface > > > >(for example,
Re: [DISCUSS] Custom service proxy context
Pavel, > Can you clarify please, is it going to be a new interface, let's say > IgniteServicesSomething, and "IgniteServices extends IgniteServicesSomething"? Yes, that's what I meant (if we go this way). пн, 20 дек. 2021 г. в 15:32, Pavel Tupitsyn : > > Alex, > > > the count of methods will increase in geometric progression > > I would say it is linear, not geometric. > Anyway, a common fix for "too many parameters" issue is Parameter Object > pattern [1], > I suggest introducing "ServiceProxyConfiguration" class. > > > > We already using such an approach in transactions for example, where we > > have withLabel, withTracing modifier > > I'm not sure this is a good approach and I'd like to avoid using it in more > places. > - it looks like a builder pattern, but it is not > - there is no "withoutTracing" so I can't go back > - when I get "IgniteTransactions" instance in some method, I don't know if > tracing is enabled or not, there is no way to check, no way to disable > > > > I'm voting for option (3). > > Can you clarify please, is it going to be a new interface, let's say > IgniteServicesSomething, > and "IgniteServices extends IgniteServicesSomething"? > > > [1] https://wiki.c2.com/?ParameterObject > > On Mon, Dec 20, 2021 at 12:15 PM Alex Plehanov > wrote: > > > Pavel, > > > > As for option (1): the count of methods will increase in geometric > > progression with each new parameter. For example, if we decide to add > > tracing to services, we should keep current methods as-is for backward > > compatibility and add new methods supporting a tracing parameter. > > > > > Also, we don't provide methods like withTimeout, withSticky, so adding > > withContext will introduce another inconsistency. > > We already using such an approach in transactions for example, where we > > have withLabel, withTracing modifier, and the timeout method parameter. I > > think it's nothing wrong here. We can't get rid of timeout and sticky > > parameters due to backward compatibility. > > > > > (3) seems to be too complicate > > I see no complication here. From the user's point of view - almost nothing > > changed. The user can use the same IgniteService interface when > > using services without modifiers. When using modifiers - only interface > > with methods related to modifiers will be available. In most cases, the > > user even no need to know about this new interface. > > > > I'm voting for option (3). > > > > чт, 16 дек. 2021 г. в 15:59, Pavel Tupitsyn : > > > > > Pavel, > > > > > > My vote is for option (1). Simple and clear. > > > > > > As you noted, with (2) it is not clear which methods are affected. > > > Also, we don't provide methods like withTimeout, withSticky, so adding > > > withContext will introduce another inconsistency. > > > > > > (3) seems to be too complicated. > > > > > > On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin > > wrote: > > > > > > > Hi folks! > > > > > > > > The discussed feature is currently under development and recently > > > > there was a proposal for an API improvement, which I want to discuss. > > > > > > > > It is about how the user can specify a service call context when > > > > getting a proxy. > > > > > > > > I see the following options: > > > > > > > > 1. Passing the context as an argument to the proxy getter method. > > > > > > > >Ignite.services().serviceProxy(name,..., callCtx) > > > > > > > >The disadvantage is that for ease of use, we add several > > > >overloads of this method with different combinations of parameters. > > > > > > > > 2. Adding a new method "withCallContext(callCtx)" (returns > > > > IgniteServices) to the IgniteServices interface. > > > > > > > >Ignite.services().withCallContext(callCtx).serviceProxy(name,...) > > > > > > > >The disadvantage is that most of the IgniteServices methods > > > >are not related to the service call context (deploy, cancel > > > >of the service, etc.). > > > > > > > > 3. (extension of the 2nd option) Adding a new > > > > "withCallContext(callCtx)" method which returns a new interface. > > > > > > > >Ignite.service().withCallContext(callCtx).serviceProxy(name,...) > > > > > > > >Unlike the 2nd option, the "withCallContext()" method returns a new > > > > interface > > > >(for example, IgniteServiceProxies or IgniteContextAwareServices), > > > which > > > >contains only methods that use the service call context. > > > > > > > > WDYT? > > > > > > > > пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin : > > > > > > > > > > > 1. Add init/execute/cancel methods without parameters. > > > > > > 2. Add default no-op implementations for the new methods (this is > > > > required > > > > > > to preserve compatibility). > > > > > > 3. For old methods that take ServiceContext as a parameter, add > > > default > > > > > > implementations that delegate to new methods. > > > > > > 4. Deprecate the old methods on the API. > > > > > > 5. On the implementation level, still use the old methods (again - > >
Re: [DISCUSS] Custom service proxy context
Alex, > the count of methods will increase in geometric progression I would say it is linear, not geometric. Anyway, a common fix for "too many parameters" issue is Parameter Object pattern [1], I suggest introducing "ServiceProxyConfiguration" class. > We already using such an approach in transactions for example, where we > have withLabel, withTracing modifier I'm not sure this is a good approach and I'd like to avoid using it in more places. - it looks like a builder pattern, but it is not - there is no "withoutTracing" so I can't go back - when I get "IgniteTransactions" instance in some method, I don't know if tracing is enabled or not, there is no way to check, no way to disable > I'm voting for option (3). Can you clarify please, is it going to be a new interface, let's say IgniteServicesSomething, and "IgniteServices extends IgniteServicesSomething"? [1] https://wiki.c2.com/?ParameterObject On Mon, Dec 20, 2021 at 12:15 PM Alex Plehanov wrote: > Pavel, > > As for option (1): the count of methods will increase in geometric > progression with each new parameter. For example, if we decide to add > tracing to services, we should keep current methods as-is for backward > compatibility and add new methods supporting a tracing parameter. > > > Also, we don't provide methods like withTimeout, withSticky, so adding > withContext will introduce another inconsistency. > We already using such an approach in transactions for example, where we > have withLabel, withTracing modifier, and the timeout method parameter. I > think it's nothing wrong here. We can't get rid of timeout and sticky > parameters due to backward compatibility. > > > (3) seems to be too complicate > I see no complication here. From the user's point of view - almost nothing > changed. The user can use the same IgniteService interface when > using services without modifiers. When using modifiers - only interface > with methods related to modifiers will be available. In most cases, the > user even no need to know about this new interface. > > I'm voting for option (3). > > чт, 16 дек. 2021 г. в 15:59, Pavel Tupitsyn : > > > Pavel, > > > > My vote is for option (1). Simple and clear. > > > > As you noted, with (2) it is not clear which methods are affected. > > Also, we don't provide methods like withTimeout, withSticky, so adding > > withContext will introduce another inconsistency. > > > > (3) seems to be too complicated. > > > > On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin > wrote: > > > > > Hi folks! > > > > > > The discussed feature is currently under development and recently > > > there was a proposal for an API improvement, which I want to discuss. > > > > > > It is about how the user can specify a service call context when > > > getting a proxy. > > > > > > I see the following options: > > > > > > 1. Passing the context as an argument to the proxy getter method. > > > > > >Ignite.services().serviceProxy(name,..., callCtx) > > > > > >The disadvantage is that for ease of use, we add several > > >overloads of this method with different combinations of parameters. > > > > > > 2. Adding a new method "withCallContext(callCtx)" (returns > > > IgniteServices) to the IgniteServices interface. > > > > > >Ignite.services().withCallContext(callCtx).serviceProxy(name,...) > > > > > >The disadvantage is that most of the IgniteServices methods > > >are not related to the service call context (deploy, cancel > > >of the service, etc.). > > > > > > 3. (extension of the 2nd option) Adding a new > > > "withCallContext(callCtx)" method which returns a new interface. > > > > > >Ignite.service().withCallContext(callCtx).serviceProxy(name,...) > > > > > >Unlike the 2nd option, the "withCallContext()" method returns a new > > > interface > > >(for example, IgniteServiceProxies or IgniteContextAwareServices), > > which > > >contains only methods that use the service call context. > > > > > > WDYT? > > > > > > пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin : > > > > > > > > > 1. Add init/execute/cancel methods without parameters. > > > > > 2. Add default no-op implementations for the new methods (this is > > > required > > > > > to preserve compatibility). > > > > > 3. For old methods that take ServiceContext as a parameter, add > > default > > > > > implementations that delegate to new methods. > > > > > 4. Deprecate the old methods on the API. > > > > > 5. On the implementation level, still use the old methods (again - > > for > > > > > compatibility). > > > > > 6. Finally, add a @ServiceContextResource annotation to inject > > > > > ServiceContext. > > > > > > > > I like this idea and I have filed a ticket for this change [1]. > > > > If there is no objection, I plan to implement this shortly. > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15801 > > > > > > > > ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov : > > > > > > > > > > > and it fully switches to annotation-based injection.
Re: [DISCUSS] Custom service proxy context
Pavel, As for option (1): the count of methods will increase in geometric progression with each new parameter. For example, if we decide to add tracing to services, we should keep current methods as-is for backward compatibility and add new methods supporting a tracing parameter. > Also, we don't provide methods like withTimeout, withSticky, so adding withContext will introduce another inconsistency. We already using such an approach in transactions for example, where we have withLabel, withTracing modifier, and the timeout method parameter. I think it's nothing wrong here. We can't get rid of timeout and sticky parameters due to backward compatibility. > (3) seems to be too complicate I see no complication here. From the user's point of view - almost nothing changed. The user can use the same IgniteService interface when using services without modifiers. When using modifiers - only interface with methods related to modifiers will be available. In most cases, the user even no need to know about this new interface. I'm voting for option (3). чт, 16 дек. 2021 г. в 15:59, Pavel Tupitsyn : > Pavel, > > My vote is for option (1). Simple and clear. > > As you noted, with (2) it is not clear which methods are affected. > Also, we don't provide methods like withTimeout, withSticky, so adding > withContext will introduce another inconsistency. > > (3) seems to be too complicated. > > On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin wrote: > > > Hi folks! > > > > The discussed feature is currently under development and recently > > there was a proposal for an API improvement, which I want to discuss. > > > > It is about how the user can specify a service call context when > > getting a proxy. > > > > I see the following options: > > > > 1. Passing the context as an argument to the proxy getter method. > > > >Ignite.services().serviceProxy(name,..., callCtx) > > > >The disadvantage is that for ease of use, we add several > >overloads of this method with different combinations of parameters. > > > > 2. Adding a new method "withCallContext(callCtx)" (returns > > IgniteServices) to the IgniteServices interface. > > > >Ignite.services().withCallContext(callCtx).serviceProxy(name,...) > > > >The disadvantage is that most of the IgniteServices methods > >are not related to the service call context (deploy, cancel > >of the service, etc.). > > > > 3. (extension of the 2nd option) Adding a new > > "withCallContext(callCtx)" method which returns a new interface. > > > >Ignite.service().withCallContext(callCtx).serviceProxy(name,...) > > > >Unlike the 2nd option, the "withCallContext()" method returns a new > > interface > >(for example, IgniteServiceProxies or IgniteContextAwareServices), > which > >contains only methods that use the service call context. > > > > WDYT? > > > > пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin : > > > > > > > 1. Add init/execute/cancel methods without parameters. > > > > 2. Add default no-op implementations for the new methods (this is > > required > > > > to preserve compatibility). > > > > 3. For old methods that take ServiceContext as a parameter, add > default > > > > implementations that delegate to new methods. > > > > 4. Deprecate the old methods on the API. > > > > 5. On the implementation level, still use the old methods (again - > for > > > > compatibility). > > > > 6. Finally, add a @ServiceContextResource annotation to inject > > > > ServiceContext. > > > > > > I like this idea and I have filed a ticket for this change [1]. > > > If there is no objection, I plan to implement this shortly. > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15801 > > > > > > ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov : > > > > > > > > > and it fully switches to annotation-based injection. > > > > > > > > +1 to do it. > > > > > > > > > 19 окт. 2021 г., в 22:14, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> написал(а): > > > > > > > > > > That's actually a good point. In Java, we can do the following: > > > > > 1. Add init/execute/cancel methods without parameters. > > > > > 2. Add default no-op implementations for the new methods (this is > > required > > > > > to preserve compatibility). > > > > > 3. For old methods that take ServiceContext as a parameter, add > > default > > > > > implementations that delegate to new methods. > > > > > 4. Deprecate the old methods on the API. > > > > > 5. On the implementation level, still use the old methods (again - > > for > > > > > compatibility). > > > > > 6. Finally, add a @ServiceContextResource annotation to inject > > > > > ServiceContext. > > > > > > > > > > If I haven't missed anything, this is not a breaking change, and it > > fully > > > > > switches to annotation-based injection. > > > > > > > > > > I'm not sure this is possible in .NET though. > > > > > > > > > > -Val > > > > > > > > > > On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin < > xxt...@gmail.com> > > wrote: > > > > > >
Re: [DISCUSS] Custom service proxy context
Pavel, My vote is for option (1). Simple and clear. As you noted, with (2) it is not clear which methods are affected. Also, we don't provide methods like withTimeout, withSticky, so adding withContext will introduce another inconsistency. (3) seems to be too complicated. On Thu, Dec 16, 2021 at 3:34 PM Pavel Pereslegin wrote: > Hi folks! > > The discussed feature is currently under development and recently > there was a proposal for an API improvement, which I want to discuss. > > It is about how the user can specify a service call context when > getting a proxy. > > I see the following options: > > 1. Passing the context as an argument to the proxy getter method. > >Ignite.services().serviceProxy(name,..., callCtx) > >The disadvantage is that for ease of use, we add several >overloads of this method with different combinations of parameters. > > 2. Adding a new method "withCallContext(callCtx)" (returns > IgniteServices) to the IgniteServices interface. > >Ignite.services().withCallContext(callCtx).serviceProxy(name,...) > >The disadvantage is that most of the IgniteServices methods >are not related to the service call context (deploy, cancel >of the service, etc.). > > 3. (extension of the 2nd option) Adding a new > "withCallContext(callCtx)" method which returns a new interface. > >Ignite.service().withCallContext(callCtx).serviceProxy(name,...) > >Unlike the 2nd option, the "withCallContext()" method returns a new > interface >(for example, IgniteServiceProxies or IgniteContextAwareServices), which >contains only methods that use the service call context. > > WDYT? > > пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin : > > > > > 1. Add init/execute/cancel methods without parameters. > > > 2. Add default no-op implementations for the new methods (this is > required > > > to preserve compatibility). > > > 3. For old methods that take ServiceContext as a parameter, add default > > > implementations that delegate to new methods. > > > 4. Deprecate the old methods on the API. > > > 5. On the implementation level, still use the old methods (again - for > > > compatibility). > > > 6. Finally, add a @ServiceContextResource annotation to inject > > > ServiceContext. > > > > I like this idea and I have filed a ticket for this change [1]. > > If there is no objection, I plan to implement this shortly. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15801 > > > > ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov : > > > > > > > and it fully switches to annotation-based injection. > > > > > > +1 to do it. > > > > > > > 19 окт. 2021 г., в 22:14, Valentin Kulichenko < > valentin.kuliche...@gmail.com> написал(а): > > > > > > > > That's actually a good point. In Java, we can do the following: > > > > 1. Add init/execute/cancel methods without parameters. > > > > 2. Add default no-op implementations for the new methods (this is > required > > > > to preserve compatibility). > > > > 3. For old methods that take ServiceContext as a parameter, add > default > > > > implementations that delegate to new methods. > > > > 4. Deprecate the old methods on the API. > > > > 5. On the implementation level, still use the old methods (again - > for > > > > compatibility). > > > > 6. Finally, add a @ServiceContextResource annotation to inject > > > > ServiceContext. > > > > > > > > If I haven't missed anything, this is not a breaking change, and it > fully > > > > switches to annotation-based injection. > > > > > > > > I'm not sure this is possible in .NET though. > > > > > > > > -Val > > > > > > > > On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin > wrote: > > > > > > > >>> Removing parameters from a public interface method is a breaking > change, > > > >>> or do you mean something else? > > > >> > > > >> Sorry, I meant that we can inject the service context, but leave it > > > >> available in the init/execute/cancel methods and add a default > "no-op" > > > >> implementation in the interface for them. Can we do this? > > > >> > > > >>> Regarding .NET - let's have a separate ticket for that? > > > >> If we decide to "inject" a service context - this should be done in > a > > > >> separate ticket. > > > >> If you are talking about "proxy service context" - I can split it > into > > > >> 3 parts (java, Net, and thin clients) > > > >> > > > >> вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn : > > > >>> > > > >>> Pavel, > > > >>> > > > From my point of view, this should not break anything > > > >>> Removing parameters from a public interface method is a breaking > change, > > > >>> or do you mean something else? > > > >>> > > > >>> Regarding .NET - let's have a separate ticket for that? > > > >>> We can discuss and implement Java changes first. > > > >>> > > > >>> On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin > > > > >> wrote: > > > >>> > > > Thanks a lot for your suggestions. > > > > > > > We might consider injecting the ServiceContext instead of > passing it > >
Re: [DISCUSS] Custom service proxy context
Hi folks! The discussed feature is currently under development and recently there was a proposal for an API improvement, which I want to discuss. It is about how the user can specify a service call context when getting a proxy. I see the following options: 1. Passing the context as an argument to the proxy getter method. Ignite.services().serviceProxy(name,..., callCtx) The disadvantage is that for ease of use, we add several overloads of this method with different combinations of parameters. 2. Adding a new method "withCallContext(callCtx)" (returns IgniteServices) to the IgniteServices interface. Ignite.services().withCallContext(callCtx).serviceProxy(name,...) The disadvantage is that most of the IgniteServices methods are not related to the service call context (deploy, cancel of the service, etc.). 3. (extension of the 2nd option) Adding a new "withCallContext(callCtx)" method which returns a new interface. Ignite.service().withCallContext(callCtx).serviceProxy(name,...) Unlike the 2nd option, the "withCallContext()" method returns a new interface (for example, IgniteServiceProxies or IgniteContextAwareServices), which contains only methods that use the service call context. WDYT? пт, 22 окт. 2021 г. в 14:36, Pavel Pereslegin : > > > 1. Add init/execute/cancel methods without parameters. > > 2. Add default no-op implementations for the new methods (this is required > > to preserve compatibility). > > 3. For old methods that take ServiceContext as a parameter, add default > > implementations that delegate to new methods. > > 4. Deprecate the old methods on the API. > > 5. On the implementation level, still use the old methods (again - for > > compatibility). > > 6. Finally, add a @ServiceContextResource annotation to inject > > ServiceContext. > > I like this idea and I have filed a ticket for this change [1]. > If there is no objection, I plan to implement this shortly. > > [1] https://issues.apache.org/jira/browse/IGNITE-15801 > > ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov : > > > > > and it fully switches to annotation-based injection. > > > > +1 to do it. > > > > > 19 окт. 2021 г., в 22:14, Valentin Kulichenko > > > написал(а): > > > > > > That's actually a good point. In Java, we can do the following: > > > 1. Add init/execute/cancel methods without parameters. > > > 2. Add default no-op implementations for the new methods (this is required > > > to preserve compatibility). > > > 3. For old methods that take ServiceContext as a parameter, add default > > > implementations that delegate to new methods. > > > 4. Deprecate the old methods on the API. > > > 5. On the implementation level, still use the old methods (again - for > > > compatibility). > > > 6. Finally, add a @ServiceContextResource annotation to inject > > > ServiceContext. > > > > > > If I haven't missed anything, this is not a breaking change, and it fully > > > switches to annotation-based injection. > > > > > > I'm not sure this is possible in .NET though. > > > > > > -Val > > > > > > On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin > > > wrote: > > > > > >>> Removing parameters from a public interface method is a breaking change, > > >>> or do you mean something else? > > >> > > >> Sorry, I meant that we can inject the service context, but leave it > > >> available in the init/execute/cancel methods and add a default "no-op" > > >> implementation in the interface for them. Can we do this? > > >> > > >>> Regarding .NET - let's have a separate ticket for that? > > >> If we decide to "inject" a service context - this should be done in a > > >> separate ticket. > > >> If you are talking about "proxy service context" - I can split it into > > >> 3 parts (java, Net, and thin clients) > > >> > > >> вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn : > > >>> > > >>> Pavel, > > >>> > > From my point of view, this should not break anything > > >>> Removing parameters from a public interface method is a breaking change, > > >>> or do you mean something else? > > >>> > > >>> Regarding .NET - let's have a separate ticket for that? > > >>> We can discuss and implement Java changes first. > > >>> > > >>> On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin > > >> wrote: > > >>> > > Thanks a lot for your suggestions. > > > > > We might consider injecting the ServiceContext instead of passing it > > >> to > > > IgniteService methods, but I believe this will be a breaking change? > > > > From my point of view, this should not break anything. We can inject a > > service context when initializing a service and keep it accessible in > > state transition methods (init/execute/cancel). > > Currently, in .Net ServiceContext doesn't share the same instance, but > > this can be reworked - for example, we can store the service context > > (with a reference to the service) in the resource registry instead of > > the service itself. > > > > But
Re: [DISCUSS] Custom service proxy context
> 1. Add init/execute/cancel methods without parameters. > 2. Add default no-op implementations for the new methods (this is required > to preserve compatibility). > 3. For old methods that take ServiceContext as a parameter, add default > implementations that delegate to new methods. > 4. Deprecate the old methods on the API. > 5. On the implementation level, still use the old methods (again - for > compatibility). > 6. Finally, add a @ServiceContextResource annotation to inject > ServiceContext. I like this idea and I have filed a ticket for this change [1]. If there is no objection, I plan to implement this shortly. [1] https://issues.apache.org/jira/browse/IGNITE-15801 ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov : > > > and it fully switches to annotation-based injection. > > +1 to do it. > > > 19 окт. 2021 г., в 22:14, Valentin Kulichenko > > написал(а): > > > > That's actually a good point. In Java, we can do the following: > > 1. Add init/execute/cancel methods without parameters. > > 2. Add default no-op implementations for the new methods (this is required > > to preserve compatibility). > > 3. For old methods that take ServiceContext as a parameter, add default > > implementations that delegate to new methods. > > 4. Deprecate the old methods on the API. > > 5. On the implementation level, still use the old methods (again - for > > compatibility). > > 6. Finally, add a @ServiceContextResource annotation to inject > > ServiceContext. > > > > If I haven't missed anything, this is not a breaking change, and it fully > > switches to annotation-based injection. > > > > I'm not sure this is possible in .NET though. > > > > -Val > > > > On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin wrote: > > > >>> Removing parameters from a public interface method is a breaking change, > >>> or do you mean something else? > >> > >> Sorry, I meant that we can inject the service context, but leave it > >> available in the init/execute/cancel methods and add a default "no-op" > >> implementation in the interface for them. Can we do this? > >> > >>> Regarding .NET - let's have a separate ticket for that? > >> If we decide to "inject" a service context - this should be done in a > >> separate ticket. > >> If you are talking about "proxy service context" - I can split it into > >> 3 parts (java, Net, and thin clients) > >> > >> вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn : > >>> > >>> Pavel, > >>> > From my point of view, this should not break anything > >>> Removing parameters from a public interface method is a breaking change, > >>> or do you mean something else? > >>> > >>> Regarding .NET - let's have a separate ticket for that? > >>> We can discuss and implement Java changes first. > >>> > >>> On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin > >> wrote: > >>> > Thanks a lot for your suggestions. > > > We might consider injecting the ServiceContext instead of passing it > >> to > > IgniteService methods, but I believe this will be a breaking change? > > From my point of view, this should not break anything. We can inject a > service context when initializing a service and keep it accessible in > state transition methods (init/execute/cancel). > Currently, in .Net ServiceContext doesn't share the same instance, but > this can be reworked - for example, we can store the service context > (with a reference to the service) in the resource registry instead of > the service itself. > > But I don't see much usability improvement with such a feature if the > user still needs to implement state transition methods. I think it > would be nice to add default "no-op" implementations for them. > Unfortunately, we are currently unable to do the same in .Net because > such a feature is not supported in C# 4.0 (it's available in C# 8.0). > > Can we add default "no-op" implementations for init/execute/cancel > methods in Java and leave them unchanged in .Net? > > вт, 19 окт. 2021 г. в 18:51, Valentin Kulichenko > : > > > > I support #2, because we already have the ServiceContext. Having > > both ServiceContext and @ServiceRequestContextResource that injects > >> some > > function (or any other mechanism for that matter) will be VERY > >> confusing. > > Let's keep it simple. > > > > At the same time, I do agree with Nikolay that injection is the > >> approach > > taken across the platform, so I'm not sure why we are not using it > >> here. > We > > might consider injecting the ServiceContext instead of passing it to > > IgniteService methods, but I believe this will be a breaking change? > > > > -Val > > > > On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky >>> > wrote: > > > >> I am for limiting types of attributes values only to UTF-8 strings > >> and > >> bytearrays. > >> Also, I agree with Pavel, (2) is clear and without
Re: [DISCUSS] Custom service proxy context
> and it fully switches to annotation-based injection. +1 to do it. > 19 окт. 2021 г., в 22:14, Valentin Kulichenko > написал(а): > > That's actually a good point. In Java, we can do the following: > 1. Add init/execute/cancel methods without parameters. > 2. Add default no-op implementations for the new methods (this is required > to preserve compatibility). > 3. For old methods that take ServiceContext as a parameter, add default > implementations that delegate to new methods. > 4. Deprecate the old methods on the API. > 5. On the implementation level, still use the old methods (again - for > compatibility). > 6. Finally, add a @ServiceContextResource annotation to inject > ServiceContext. > > If I haven't missed anything, this is not a breaking change, and it fully > switches to annotation-based injection. > > I'm not sure this is possible in .NET though. > > -Val > > On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin wrote: > >>> Removing parameters from a public interface method is a breaking change, >>> or do you mean something else? >> >> Sorry, I meant that we can inject the service context, but leave it >> available in the init/execute/cancel methods and add a default "no-op" >> implementation in the interface for them. Can we do this? >> >>> Regarding .NET - let's have a separate ticket for that? >> If we decide to "inject" a service context - this should be done in a >> separate ticket. >> If you are talking about "proxy service context" - I can split it into >> 3 parts (java, Net, and thin clients) >> >> вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn : >>> >>> Pavel, >>> From my point of view, this should not break anything >>> Removing parameters from a public interface method is a breaking change, >>> or do you mean something else? >>> >>> Regarding .NET - let's have a separate ticket for that? >>> We can discuss and implement Java changes first. >>> >>> On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin >> wrote: >>> Thanks a lot for your suggestions. > We might consider injecting the ServiceContext instead of passing it >> to > IgniteService methods, but I believe this will be a breaking change? From my point of view, this should not break anything. We can inject a service context when initializing a service and keep it accessible in state transition methods (init/execute/cancel). Currently, in .Net ServiceContext doesn't share the same instance, but this can be reworked - for example, we can store the service context (with a reference to the service) in the resource registry instead of the service itself. But I don't see much usability improvement with such a feature if the user still needs to implement state transition methods. I think it would be nice to add default "no-op" implementations for them. Unfortunately, we are currently unable to do the same in .Net because such a feature is not supported in C# 4.0 (it's available in C# 8.0). Can we add default "no-op" implementations for init/execute/cancel methods in Java and leave them unchanged in .Net? вт, 19 окт. 2021 г. в 18:51, Valentin Kulichenko : > > I support #2, because we already have the ServiceContext. Having > both ServiceContext and @ServiceRequestContextResource that injects >> some > function (or any other mechanism for that matter) will be VERY >> confusing. > Let's keep it simple. > > At the same time, I do agree with Nikolay that injection is the >> approach > taken across the platform, so I'm not sure why we are not using it >> here. We > might consider injecting the ServiceContext instead of passing it to > IgniteService methods, but I believe this will be a breaking change? > > -Val > > On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky >> wrote: > >> I am for limiting types of attributes values only to UTF-8 strings >> and >> bytearrays. >> Also, I agree with Pavel, (2) is clear and without any reflection. >> >> вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov >> : >> >>> I like (1) options. >>> >>> @ServiceRequestContextResource >>> private Function 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 >> >>> написал(а): (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(...).
Re: [DISCUSS] Custom service proxy context
That's actually a good point. In Java, we can do the following: 1. Add init/execute/cancel methods without parameters. 2. Add default no-op implementations for the new methods (this is required to preserve compatibility). 3. For old methods that take ServiceContext as a parameter, add default implementations that delegate to new methods. 4. Deprecate the old methods on the API. 5. On the implementation level, still use the old methods (again - for compatibility). 6. Finally, add a @ServiceContextResource annotation to inject ServiceContext. If I haven't missed anything, this is not a breaking change, and it fully switches to annotation-based injection. I'm not sure this is possible in .NET though. -Val On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin wrote: > > Removing parameters from a public interface method is a breaking change, > > or do you mean something else? > > Sorry, I meant that we can inject the service context, but leave it > available in the init/execute/cancel methods and add a default "no-op" > implementation in the interface for them. Can we do this? > > > Regarding .NET - let's have a separate ticket for that? > If we decide to "inject" a service context - this should be done in a > separate ticket. > If you are talking about "proxy service context" - I can split it into > 3 parts (java, Net, and thin clients) > > вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn : > > > > Pavel, > > > > > From my point of view, this should not break anything > > Removing parameters from a public interface method is a breaking change, > > or do you mean something else? > > > > Regarding .NET - let's have a separate ticket for that? > > We can discuss and implement Java changes first. > > > > On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin > wrote: > > > > > Thanks a lot for your suggestions. > > > > > > > We might consider injecting the ServiceContext instead of passing it > to > > > > IgniteService methods, but I believe this will be a breaking change? > > > > > > From my point of view, this should not break anything. We can inject a > > > service context when initializing a service and keep it accessible in > > > state transition methods (init/execute/cancel). > > > Currently, in .Net ServiceContext doesn't share the same instance, but > > > this can be reworked - for example, we can store the service context > > > (with a reference to the service) in the resource registry instead of > > > the service itself. > > > > > > But I don't see much usability improvement with such a feature if the > > > user still needs to implement state transition methods. I think it > > > would be nice to add default "no-op" implementations for them. > > > Unfortunately, we are currently unable to do the same in .Net because > > > such a feature is not supported in C# 4.0 (it's available in C# 8.0). > > > > > > Can we add default "no-op" implementations for init/execute/cancel > > > methods in Java and leave them unchanged in .Net? > > > > > > вт, 19 окт. 2021 г. в 18:51, Valentin Kulichenko > > > : > > > > > > > > I support #2, because we already have the ServiceContext. Having > > > > both ServiceContext and @ServiceRequestContextResource that injects > some > > > > function (or any other mechanism for that matter) will be VERY > confusing. > > > > Let's keep it simple. > > > > > > > > At the same time, I do agree with Nikolay that injection is the > approach > > > > taken across the platform, so I'm not sure why we are not using it > here. > > > We > > > > might consider injecting the ServiceContext instead of passing it to > > > > IgniteService methods, but I believe this will be a breaking change? > > > > > > > > -Val > > > > > > > > On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky > > > > wrote: > > > > > > > > > I am for limiting types of attributes values only to UTF-8 strings > and > > > > > bytearrays. > > > > > Also, I agree with Pavel, (2) is clear and without any reflection. > > > > > > > > > > вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov >: > > > > > > > > > > > I like (1) options. > > > > > > > > > > > >@ServiceRequestContextResource > > > > > >private Function 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 > > > > > > > написал(а): > > > > > > > > > > > > > > (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
Re: [DISCUSS] Custom service proxy context
> Removing parameters from a public interface method is a breaking change, > or do you mean something else? Sorry, I meant that we can inject the service context, but leave it available in the init/execute/cancel methods and add a default "no-op" implementation in the interface for them. Can we do this? > Regarding .NET - let's have a separate ticket for that? If we decide to "inject" a service context - this should be done in a separate ticket. If you are talking about "proxy service context" - I can split it into 3 parts (java, Net, and thin clients) вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn : > > Pavel, > > > From my point of view, this should not break anything > Removing parameters from a public interface method is a breaking change, > or do you mean something else? > > Regarding .NET - let's have a separate ticket for that? > We can discuss and implement Java changes first. > > On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin wrote: > > > Thanks a lot for your suggestions. > > > > > We might consider injecting the ServiceContext instead of passing it to > > > IgniteService methods, but I believe this will be a breaking change? > > > > From my point of view, this should not break anything. We can inject a > > service context when initializing a service and keep it accessible in > > state transition methods (init/execute/cancel). > > Currently, in .Net ServiceContext doesn't share the same instance, but > > this can be reworked - for example, we can store the service context > > (with a reference to the service) in the resource registry instead of > > the service itself. > > > > But I don't see much usability improvement with such a feature if the > > user still needs to implement state transition methods. I think it > > would be nice to add default "no-op" implementations for them. > > Unfortunately, we are currently unable to do the same in .Net because > > such a feature is not supported in C# 4.0 (it's available in C# 8.0). > > > > Can we add default "no-op" implementations for init/execute/cancel > > methods in Java and leave them unchanged in .Net? > > > > вт, 19 окт. 2021 г. в 18:51, Valentin Kulichenko > > : > > > > > > I support #2, because we already have the ServiceContext. Having > > > both ServiceContext and @ServiceRequestContextResource that injects some > > > function (or any other mechanism for that matter) will be VERY confusing. > > > Let's keep it simple. > > > > > > At the same time, I do agree with Nikolay that injection is the approach > > > taken across the platform, so I'm not sure why we are not using it here. > > We > > > might consider injecting the ServiceContext instead of passing it to > > > IgniteService methods, but I believe this will be a breaking change? > > > > > > -Val > > > > > > On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky > > wrote: > > > > > > > I am for limiting types of attributes values only to UTF-8 strings and > > > > bytearrays. > > > > Also, I agree with Pavel, (2) is clear and without any reflection. > > > > > > > > вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov : > > > > > > > > > I like (1) options. > > > > > > > > > >@ServiceRequestContextResource > > > > >private Function 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 > > > > > написал(а): > > > > > > > > > > > > (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 > > > > > > > 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 ctxFunc; > > > > > >> > > > > > >>public void serviceMethod() { > > > > > >>String login = (String)ctxFunc.apply("login"); > > > > > >>} > > > > > >> > > > > > >> 2. Using a new method
Re: [DISCUSS] Custom service proxy context
Pavel, > From my point of view, this should not break anything Removing parameters from a public interface method is a breaking change, or do you mean something else? Regarding .NET - let's have a separate ticket for that? We can discuss and implement Java changes first. On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin wrote: > Thanks a lot for your suggestions. > > > We might consider injecting the ServiceContext instead of passing it to > > IgniteService methods, but I believe this will be a breaking change? > > From my point of view, this should not break anything. We can inject a > service context when initializing a service and keep it accessible in > state transition methods (init/execute/cancel). > Currently, in .Net ServiceContext doesn't share the same instance, but > this can be reworked - for example, we can store the service context > (with a reference to the service) in the resource registry instead of > the service itself. > > But I don't see much usability improvement with such a feature if the > user still needs to implement state transition methods. I think it > would be nice to add default "no-op" implementations for them. > Unfortunately, we are currently unable to do the same in .Net because > such a feature is not supported in C# 4.0 (it's available in C# 8.0). > > Can we add default "no-op" implementations for init/execute/cancel > methods in Java and leave them unchanged in .Net? > > вт, 19 окт. 2021 г. в 18:51, Valentin Kulichenko > : > > > > I support #2, because we already have the ServiceContext. Having > > both ServiceContext and @ServiceRequestContextResource that injects some > > function (or any other mechanism for that matter) will be VERY confusing. > > Let's keep it simple. > > > > At the same time, I do agree with Nikolay that injection is the approach > > taken across the platform, so I'm not sure why we are not using it here. > We > > might consider injecting the ServiceContext instead of passing it to > > IgniteService methods, but I believe this will be a breaking change? > > > > -Val > > > > On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky > wrote: > > > > > I am for limiting types of attributes values only to UTF-8 strings and > > > bytearrays. > > > Also, I agree with Pavel, (2) is clear and without any reflection. > > > > > > вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov : > > > > > > > I like (1) options. > > > > > > > >@ServiceRequestContextResource > > > >private Function 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 > > > > написал(а): > > > > > > > > > > (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 > > > > > 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 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 into a > new > > > > >> ServiceRequestContext class. > > > > >> > > > > >> 3. Read context "wrapper" using special annotation and supplier. > > > > >> > > > > >>@ServiceRequestContextResource > > > > >>private Supplier ctxSupplier; > > > > >> > > > > >>public void serviceMethod() { > > > > >>
Re: [DISCUSS] Custom service proxy context
Thanks a lot for your suggestions. > We might consider injecting the ServiceContext instead of passing it to > IgniteService methods, but I believe this will be a breaking change? >From my point of view, this should not break anything. We can inject a service context when initializing a service and keep it accessible in state transition methods (init/execute/cancel). Currently, in .Net ServiceContext doesn't share the same instance, but this can be reworked - for example, we can store the service context (with a reference to the service) in the resource registry instead of the service itself. But I don't see much usability improvement with such a feature if the user still needs to implement state transition methods. I think it would be nice to add default "no-op" implementations for them. Unfortunately, we are currently unable to do the same in .Net because such a feature is not supported in C# 4.0 (it's available in C# 8.0). Can we add default "no-op" implementations for init/execute/cancel methods in Java and leave them unchanged in .Net? вт, 19 окт. 2021 г. в 18:51, Valentin Kulichenko : > > I support #2, because we already have the ServiceContext. Having > both ServiceContext and @ServiceRequestContextResource that injects some > function (or any other mechanism for that matter) will be VERY confusing. > Let's keep it simple. > > At the same time, I do agree with Nikolay that injection is the approach > taken across the platform, so I'm not sure why we are not using it here. We > might consider injecting the ServiceContext instead of passing it to > IgniteService methods, but I believe this will be a breaking change? > > -Val > > On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky wrote: > > > I am for limiting types of attributes values only to UTF-8 strings and > > bytearrays. > > Also, I agree with Pavel, (2) is clear and without any reflection. > > > > вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov : > > > > > I like (1) options. > > > > > >@ServiceRequestContextResource > > >private Function 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 > > > написал(а): > > > > > > > > (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 > > > 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 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 into a new > > > >> ServiceRequestContext class. > > > >> > > > >> 3. Read context "wrapper" using special annotation and supplier. > > > >> > > > >>@ServiceRequestContextResource > > > >>private Supplier 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 : > > > >>> > > > >>> Hi, Val > > > >>> > > > > The examples you mentioned are
Re: [DISCUSS] Custom service proxy context
I support #2, because we already have the ServiceContext. Having both ServiceContext and @ServiceRequestContextResource that injects some function (or any other mechanism for that matter) will be VERY confusing. Let's keep it simple. At the same time, I do agree with Nikolay that injection is the approach taken across the platform, so I'm not sure why we are not using it here. We might consider injecting the ServiceContext instead of passing it to IgniteService methods, but I believe this will be a breaking change? -Val On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky wrote: > I am for limiting types of attributes values only to UTF-8 strings and > bytearrays. > Also, I agree with Pavel, (2) is clear and without any reflection. > > вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov : > > > I like (1) options. > > > >@ServiceRequestContextResource > >private Function 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 > > написал(а): > > > > > > (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 > > 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 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 into a new > > >> ServiceRequestContext class. > > >> > > >> 3. Read context "wrapper" using special annotation and supplier. > > >> > > >>@ServiceRequestContextResource > > >>private Supplier 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 : > > >>> > > >>> 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 > > >>
Re: [DISCUSS] Custom service proxy context
I am for limiting types of attributes values only to UTF-8 strings and bytearrays. Also, I agree with Pavel, (2) is clear and without any reflection. вт, 19 окт. 2021 г. в 14:18, Nikolay Izhikov : > I like (1) options. > >@ServiceRequestContextResource >private Function 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 > написал(а): > > > > (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 > 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 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 into a new > >> ServiceRequestContext class. > >> > >> 3. Read context "wrapper" using special annotation and supplier. > >> > >>@ServiceRequestContextResource > >>private Supplier 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 : > >>> > >>> 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. >
Re: [DISCUSS] Custom service proxy context
I like (1) options. @ServiceRequestContextResource private Function 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 написал(а): > > (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 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 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 into a new >> ServiceRequestContext class. >> >> 3. Read context "wrapper" using special annotation and supplier. >> >>@ServiceRequestContextResource >>private Supplier 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 : >>> >>> 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
Re: [DISCUSS] Custom service proxy context
(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 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 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 into a new > ServiceRequestContext class. > > 3. Read context "wrapper" using special annotation and supplier. > > @ServiceRequestContextResource > private Supplier 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 : > > > > 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 > > > wrote: > > > > > > > +1 to have service proxy context. > > > > > > > > > 11 окт. 2021 г., в 09:43, Ivan Daschinsky > > > > написал(а): > > > > > > > > > > Val, Pavel both of you are right, but on the other hand there are > some > > > > > other tasks > > > > > > > > > > 1. Distributed tracing. > > > > > 2.
Re: [DISCUSS] Custom service proxy context
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 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 into a new ServiceRequestContext class. 3. Read context "wrapper" using special annotation and supplier. @ServiceRequestContextResource private Supplier 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 : > > 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 > > wrote: > > > > > +1 to have service proxy context. > > > > > > > 11 окт. 2021 г., в 09:43, Ivan Daschinsky > > > написал(а): > > > > > > > > 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 < > > >
Re: [DISCUSS] Custom service proxy context
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 > wrote: > > > +1 to have service proxy context. > > > > > 11 окт. 2021 г., в 09:43, Ivan Daschinsky > > написал(а): > > > > > > 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 > > >> wrote: > > >> > > >>> Ivan, > > >>> > > >>> Yes, this approach is used by some other
Re: [DISCUSS] Custom service proxy context
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 wrote: > +1 to have service proxy context. > > > 11 окт. 2021 г., в 09:43, Ivan Daschinsky > написал(а): > > > > 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 > >> 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 > >>> 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 : > > > 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? >
Re: [DISCUSS] Custom service proxy context
+1 to have service proxy context. > 11 окт. 2021 г., в 09:43, Ivan Daschinsky написал(а): > > 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 >> 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 >>> 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 : > 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 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
Re: [DISCUSS] Custom service proxy context
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 > 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 > > 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 : > > > > > > > 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 > > > 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. > > > > >
Re: [DISCUSS] Custom service proxy context
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 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 > 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 : > > > > > 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 > > 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 : > > > > > > > > > > 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 > > > > >
Re: [DISCUSS] Custom service proxy context
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 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 : > > > 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 > 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 : > > > > > > > > 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 > 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 > > > wrote: > > > > > > > > >
Re: [DISCUSS] Custom service proxy context
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 : > 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 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 : > > > > > > 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 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 > > 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,
Re: [DISCUSS] Custom service proxy context
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 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 : > > > > 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 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 > 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 , CtxType> T > > > > > > serviceProxyTyped(ClusterGroup prj, String name, Class > > > > > > > srvcCls, CtxType optCtx, boolean sticky, long timeout) > > > > > > > > > > > > //new interface which services with scoped
Re: [DISCUSS] Custom service proxy context
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 : > > 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 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 > > 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 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 : > > > > > > > > > > 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 , CtxType> T > > > > > serviceProxyTyped(ClusterGroup prj, String name, Class > > > > > srvcCls, CtxType optCtx, boolean sticky, long timeout) > > > > > > > > > > //new interface which services with scoped context should implement > > > > > > > > > > public interface ContextedWith { > > > > > T getCtx(); > > > > > } > > > > > > > > > > // implementation can delegate to Map-like context or be POJO. > > > > > interface MyServiceContext { > > > > > int getArg1(); > > > > > String getUserId(); > > > > > } > > > > > > > > > > class MyService implements ContextedWith { > > > > > 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 > > > 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]). > > >
Re: [DISCUSS] Custom service proxy context
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 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 > 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 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 : > > > > > > > > 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 , CtxType> T > > > > serviceProxyTyped(ClusterGroup prj, String name, Class > > > > srvcCls, CtxType optCtx, boolean sticky, long timeout) > > > > > > > > //new interface which services with scoped context should implement > > > > > > > > public interface ContextedWith { > > > > T getCtx(); > > > > } > > > > > > > > // implementation can delegate to Map-like context or be POJO. > > > > interface MyServiceContext { > > > > int getArg1(); > > > > String getUserId(); > > > > } > > > > > > > > class MyService implements ContextedWith { > > > > 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 > > 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 > > > > > > > > > > >
Re: [DISCUSS] Custom service proxy context
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 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 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 : > > > > > > 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 , CtxType> T > > > serviceProxyTyped(ClusterGroup prj, String name, Class > > > srvcCls, CtxType optCtx, boolean sticky, long timeout) > > > > > > //new interface which services with scoped context should implement > > > > > > public interface ContextedWith { > > > T getCtx(); > > > } > > > > > > // implementation can delegate to Map-like context or be POJO. > > > interface MyServiceContext { > > > int getArg1(); > > > String getUserId(); > > > } > > > > > > class MyService implements ContextedWith { > > > 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 > 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 > > > > > > >
Re: [DISCUSS] Custom service proxy context
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 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 : > > > > 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 , CtxType> T > > serviceProxyTyped(ClusterGroup prj, String name, Class > > srvcCls, CtxType optCtx, boolean sticky, long timeout) > > > > //new interface which services with scoped context should implement > > > > public interface ContextedWith { > > T getCtx(); > > } > > > > // implementation can delegate to Map-like context or be POJO. > > interface MyServiceContext { > > int getArg1(); > > String getUserId(); > > } > > > > class MyService implements ContextedWith { > > 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 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 > > > >
Re: [DISCUSS] Custom service proxy context
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 : > > 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 , CtxType> T > serviceProxyTyped(ClusterGroup prj, String name, Class > srvcCls, CtxType optCtx, boolean sticky, long timeout) > > //new interface which services with scoped context should implement > > public interface ContextedWith { > T getCtx(); > } > > // implementation can delegate to Map-like context or be POJO. > interface MyServiceContext { > int getArg1(); > String getUserId(); > } > > class MyService implements ContextedWith { > 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 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 > >
Re: [DISCUSS] Custom service proxy context
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 , CtxType> T serviceProxyTyped(ClusterGroup prj, String name, Class srvcCls, CtxType optCtx, boolean sticky, long timeout) //new interface which services with scoped context should implement public interface ContextedWith { T getCtx(); } // implementation can delegate to Map-like context or be POJO. interface MyServiceContext { int getArg1(); String getUserId(); } class MyService implements ContextedWith { 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 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 >
[DISCUSS] Custom service proxy context
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