[wildfly-dev] gRPC in WildFly

[Brian Stansberry]

I haven't had time to properly digest this so I don't have much to say now
beyond that I think Darran makes a lot of good points and we should take
our time to evaluate the full picture.

This does feel like something that needs a subsystem. I'm not sure I
completely follow the JAXRSForwarderBuilder concept, but it sounds like a
JAXRS-specific integration with a general server-side gRPC implementation.
>From a separation of concerns point of view, that integration sounds like
an appropriate concern of the jaxrs subsystem, but providing the general
gRPC infrastructure is not a natural responsibility of the jaxrs subsystem.

On Fri, Jul 24, 2020 at 12:56 PM Ron Sigal <rsigal at redhat.com> wrote:

> Recently the RESTEasy group has been looking at protobuf and gRPC and
> discussing how they might fit into the JAX-RS world. We now have a feature
> request (https://github.com/wildfly/wildfly-proposals/pull/326) for
> exposing JAX-RS resources as gRPC servers (
> https://issues.redhat.com/browse/WFLY-13530). Briefly, it would work as
> follows. Compiling the proto file
>
> service Greeter {
>   rpc SayHello (HelloRequest) returns (HelloReply) {}
>   ...
>   }
>
> will create a class GreeterGrpc, and a gRPC service can be created by
> subclassing an inner class. Rather than implementing a gRPC service, we
> propose passing the request to the appropriate JAX-RS resource, something
> like this:
>
> class GreeterImpl extends GreeterGrpc.GreeterImplBase {
>
>    @Override
>    public void sayHello(HelloRequest req, StreamObserver<HelloReply
> responseObserver) {
>       JAXRSForwarderBuilder builder = new JAXRSForwarderBuilder();
>       builder.servlet("ResteasyServlet").pathTranslator((String s) ->
> ("test/" + s)); // Configure the JAXRSForwarder
>       JAXRSForwarder forwarder = builder.build();
>       forwarder.forward(req, (StreamObserver) responseObserver);
>    }
> }
>
> The gRPC infrasture would catch a request, dispatch it to GreeterImpl, and
> the JAXRSForwarder would
>
>   1. create an HttpServletRequest and an HttpServletResponse
>   2. find and invoke the appropriate RESTEasy servlet
>   3. pass the result to the gRPC StreamObserver
>
> The idea is to hide the complexity behind the JAXRSForwarder.
>
> Now, this proposal is limited to extending RESTEasy. However, Darren
> Lofthouse has been reading it carefully and has suggested that it could be
> part of a larger discussion of how WildFly could incorporate gRPC. Some
> discussion points:
>
>   1. Right now we're proposing to open a dedicated socket for the gRPC
> infrastructure, which runs on top of Netty. When Undertow incorporates
> Netty, maybe gRPC could share a socket with other subsystems.
>
>   2. Maybe there should be a separate gRPC subsystem.
>
>   3. Maybe we should go beyond servers and consider supporting gRPC
> clients. For example, maybe gRPC clients could be injected into JAX-RS
> resources the same as MicroProfile REST Clients.
>
>   4. Darren has suggested that Elytron should be involved.
>
> In fact, I'm going to quote one of Darren's recent remarks:
>
> Starting to research gRPC myself it feels like the kind of thing where the
> general support / strategy within the application server should be defined,
> the individual subsystems such as JAX-RS and EJB which want to expose their
> existing deployments would then dynamically make their resources available
> through this. For areas such as security this would be provided
> consistently within the general support.
>
> For gRPC initially if feels like it could have a good fit with CDI, I
> don't know how practical that would be and if it would cause a lot of
> considerations that may make it a better fit as a SmallRye project. On one
> side if that gets too complex it may be something that makes more sense as
> a SmallRye project to define how gRPC deployments are handled, on the other
> side unless the exposing of JAX-RS endpoints is 100% automated including
> the protobuf generation it sounds like a level of user deployment may be
> necessary anyway which may mean deployment handling is required.
>
> I think the exposed socket is possibly less of an issue compared to the
> general strategy. Maybe it will be necessary to expose a separate server
> socket for now, I would have thought something like this could justify it's
> own subsystem which would mean it can be defined in it's own Galleon layer
> but that would mean as a subsystem it could follow a similar path the
> Remoting subsystem took i.e. exposing a port and once possible adding
> support to delegate through Undertow.
>
> Regarding the other comments about how this could integrate with Undertow,
> the main motivation for gRPC seems to be the use of this binary protocol we
> probably should be cautious that we are not adding too many layers on our
> side that requests need to be translated thought otherwise we may be
> negating the benefits from the outset.
>
> Recently the tasks I have been working through have involved a lot of
> DeploymentUnitProcessor refactoring to restore better collaboration between
> subsystems regarding how they share security policy information, so far it
> has been slow going and considering backwards compatibility there is still
> quite a long way to go. This is the reason for something like this I am
> interested in the overall architecture first so we can hopefully avoid this
> kind of retrospective refactoring as we need to enhance it further.
>
>
> Any comments are welcome.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200728/d126a1a5/attachment.html