Ivan,
Yes, this approach is used by some other systems, and still, I don't like
it very much.
Let's hear more opinions.
On Sat, Oct 9, 2021 at 9:00 PM Ivan Daschinsky <ivanda...@gmail.com> wrote:
> Hi.
> Pavel T., Ok, http rest dosn't have the clean design, in your opinion.
>
> But what about grpc? The same?
>
> As for me, it is ok to pass additional parameters as list of key-value
> pairs with keys as strings and values as bytearrays or strings. It is ok to
> allow user to set up middlewares for services and allow to enrich request
> context in this middlewares. It is very common approach everywhere and is
> very useful in distributed systems. The use cases are so obvious, aren't
> they?
>
>
>
> сб, 9 окт. 2021 г., 20:14 Pavel Tupitsyn <ptupit...@apache.org>:
>
> > Pavel,
> >
> > Thanks for the explanation, I understand the use cases.
> >
> > > in REST service, he can set such parameters in request headers
> >
> > I don't consider HTTP-based services as a good example of a
> > clean architecture.
> > Data can be passed in URL parameters, in headers, and in body, and each
> of
> > those ways has its own limitations.
> > There is no obvious correct way to do things.
> >
> > >> Ambient state is not obvious and the API looks confusing even though I
> > understand our services stack quite well both in Java and .NET
> > > Can you clarify please?
> >
> > The proposed API adds a "side channel" for the data.
> > Some is passed as arguments, which is obvious, and some becomes magically
> > available on the server side through some external context.
> > - You have to know about the context
> > - You have to understand that the context is only available during the
> > method call (can't use it in some background logic)
> >
> > In my opinion, this is a bit too clever. I'm a fan of the functional
> > programming approach where everything you need is passed as arguments.
> >
> >
> >
> > On Fri, Oct 8, 2021 at 4:29 PM Pavel Pereslegin <xxt...@gmail.com>
> wrote:
> >
> > > Igor, Pavel.
> > >
> > > > Why can not a user implement such context on application level? I
> > > believe Ignite provides all necessary tools for that.
> > > The user wants to trace the source of the service call. For example, a
> > > service must log the name of the user who made the calls of the
> > > service. For now, there's no possibility to do that without modifying
> > > the service interface and implementation. Moreover, the user must
> > > modify all methods of service to pass this parameter. For example, in
> > > REST service, he can set such parameters in request headers, why we
> > > can't provide such usability in Ignite.
> > >
> > > > This will reduce the performance of all calls
> > > This feature is optional, if the context is not passed - then there's
> > > shouldn't be any performance difference.
> > >
> > > > Ambient state is not obvious and the API looks confusing even though
> I
> > > understand our services stack quite well both in Java and .NET
> > > Can you clarify please?
> > >
> > > пт, 8 окт. 2021 г. в 15:46, Pavel Tupitsyn <ptupit...@apache.org>:
> > > >
> > > > Agree with Igor.
> > > >
> > > > I'm not sure this feature is a good fit for Ignite.
> > > > Ignite should not be responsible for such a high-level concept, this
> > > should
> > > > be on the application side instead.
> > > >
> > > > - As Eduard noted, it is hard to make this type-safe
> > > > - Ambient state is not obvious and the API looks confusing even
> though
> > I
> > > > understand our services stack quite well both in Java and .NET
> > > > - This will reduce the performance of all calls
> > > >
> > > > On Fri, Oct 8, 2021 at 3:44 PM Igor Sapego <isap...@apache.org>
> wrote:
> > > >
> > > > > Hi guys,
> > > > >
> > > > > Why can not a user implement such context on application level?
> > > > > I believe Ignite provides all necessary tools for that. User can
> just
> > > > > implement such a context as user type and pass it to services they
> > > > > need. Are the arguments why would Ignite need a separate feature
> > > > > for such a use case?
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Fri, Oct 8, 2021 at 2:17 PM Eduard Rakhmankulov <
> > > erixon...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I am not aware .NET capabilities, but as I can see service must
> be
> > > > > > implemented in *java* and even if can't serialize other that Map
> on
> > > .NET
> > > > > > side, on java side we can wrap this map with provided
> TypedContext
> > > > > (context
> > > > > > should be convertible from map in this case).
> > > > > > That leads to a situation when Java can use TypedContext but
> other
> > > > > clients
> > > > > > can't. I believe that the majority of services users are using
> Java
> > > and
> > > > > it
> > > > > > should be taken in accordance.
> > > > > >
> > > > > > P.S. I think it is possible to send plain objects from .NET
> context
> > > to
> > > > > > cluster.
> > > > > >
> > > > > > Best regards, Ed
> > > > > >
> > > > > > On Fri, 8 Oct 2021 at 14:40, Pavel Pereslegin <xxt...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Hi, Eduard!
> > > > > > >
> > > > > > > Thanks for your feedback.
> > > > > > >
> > > > > > > The idea sounds very good, but don't forget about the platform
> > > > > services.
> > > > > > > For example, we may call Java service from .Net and vice-versa.
> > I'm
> > > > > > > not sure if the context can be implemented as a custom class
> > > (instead
> > > > > > > of Map/Dictionary) in this case.
> > > > > > >
> > > > > > > пт, 8 окт. 2021 г. в 14:21, Eduard Rakhmankulov <
> > > erixon...@gmail.com>:
> > > > > > > >
> > > > > > > > Hi, Pavel
> > > > > > > >
> > > > > > > > Is it possible to provide type-safe API for
> > ServiceProxyContext ?
> > > > > > > > I think constructions like int arg1 = ctx.attribute("arg1");
> > are
> > > > > error
> > > > > > > > prone.
> > > > > > > >
> > > > > > > > Can we make something like this :
> > > > > > > >
> > > > > > > > //Signature with two generic params which allow the compiler
> to
> > > check
> > > > > > > > if the service will be called with the wrong type context.
> > > > > > > >
> > > > > > > > public <T extends ContextedWith<CtxType>, CtxType> T
> > > > > > > > serviceProxyTyped(ClusterGroup prj, String name, Class<?
> super
> > T
> > > >
> > > > > > > > srvcCls, CtxType optCtx, boolean sticky, long timeout)
> > > > > > > >
> > > > > > > > //new interface which services with scoped context should
> > > implement
> > > > > > > >
> > > > > > > > public interface ContextedWith<T> {
> > > > > > > > T getCtx();
> > > > > > > > }
> > > > > > > >
> > > > > > > > // implementation can delegate to Map-like context or be
> POJO.
> > > > > > > > interface MyServiceContext {
> > > > > > > > int getArg1();
> > > > > > > > String getUserId();
> > > > > > > > }
> > > > > > > >
> > > > > > > > class MyService implements ContextedWith<MyServiceContext> {
> > > > > > > > void doThings() {
> > > > > > > > MyServiceContext ctx = getCtx();
> > > > > > > >
> > > > > > > > System.out.println("ctx.getArg1() = " + ctx.getArg1());
> > > > > > > > }
> > > > > > > >
> > > > > > > > @Override public MyServiceContext getCtx() {
> > > > > > > > return ServiceProxyContext.current();
> > > > > > > > }
> > > > > > > > }
> > > > > > > >
> > > > > > > > WDYT?
> > > > > > > >
> > > > > > > > Best regards, Ed.
> > > > > > > >
> > > > > > > > On Fri, 8 Oct 2021 at 13:26, Pavel Pereslegin <
> > xxt...@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello Igniters!
> > > > > > > > >
> > > > > > > > > I want to implement a feature to support a custom "caller"
> > > context
> > > > > in
> > > > > > > > > ignite services (see example in ticket description [1]).
> > > > > > > > >
> > > > > > > > > Sometimes, when using Ignite services, it becomes necessary
> > to
> > > pass
> > > > > > > > > custom parameters from the "request source" to the service.
> > > This is
> > > > > > > > > most commonly used to track the origin of a service call
> > (user
> > > id,
> > > > > > > > > request id, session id eg see this user question [2]).
> > > > > > > > > At the moment, the only way to pass such parameters to a
> > > service is
> > > > > > by
> > > > > > > > > adding argument(s) to all called methods of the service,
> > which
> > > > > makes
> > > > > > > > > the code messy and also complicates development and
> > > maintenance.
> > > > > > > > >
> > > > > > > > > I propose letting the user set a custom context for the
> > service
> > > > > proxy
> > > > > > > > > and implicitly pass that context to the methods being
> called.
> > > This
> > > > > > > > > function should not affect the execution of service methods
> > in
> > > any
> > > > > > way
> > > > > > > > > unless the user has specified a context.
> > > > > > > > >
> > > > > > > > > An example of using the proposed API [1].
> > > > > > > > > PoC (except thin clients) [3].
> > > > > > > > >
> > > > > > > > > WDYT?
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-15572
> > > > > > > > > [2]
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
> https://stackoverflow.com/questions/57459071/apache-ignite-service-grid-service-call-context
> > > > > > > > > [3] https://github.com/apache/ignite/pull/9440
> > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> >
>
