[wildfly-dev] gRPC in WildFly

Wed Aug 5 03:28:01 EDT 2020

On Wed, Aug 5, 2020 at 2:01 AM Ron Sigal <rsigal at redhat.com> wrote:

> Hi Brian,
>
> Sorry for the late response. I've been on PTO.
>
> The only reason the feature request is jaxrs specific is just because it
> comes out of RESTEasy. If there's a desire for a more general gRPC
> treatment, we would be happy to contribute to it.
>
> The point of the JAXRSForwarder is to massage a gRPC request to match a
> JAX-RS resource. For example, gRPC has its own way of matching HTTP paths
> to services. We could either write a JAX-RS resource to match the gRPC
> conventions, or modify the gRPC request in order to dispatch it to an
> existing JAX-RS resource. The latter seems like the more likely use case.
>

I think in the JAX-RS case it would need some form of forwarding providing
as JAX-RS doesn't provide a way to call endpoints directly already.

> Now, I don't know anything about EJB internals, but I can imagine doing
> something similar to dispatch a gRPC request to an EJB. So, maybe we need a
> general purpose Forwarder interface.
>
In the EJB case however in-vm invocations from one component to an EJB are
already possible. For gRPC it feels like it may be natural for a class to
be deployed as a service which in turn could call EJBs if it chooses.

> Anyway, if anyone wants to talk about it, this thread might be a good
> place to start.
>
> -Ron
> On 7/28/20 8:44 AM, Brian Stansberry wrote:
>
> 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
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200805/987e8d15/attachment-0001.html 