[wildfly-dev] gRPC in WildFly

Thu Aug 6 05:18:28 EDT 2020

On Wed, Aug 5, 2020 at 10:16 PM Ron Sigal <rsigal at redhat.com> wrote:

>
> On 8/5/20 3:28 AM, Darran Lofthouse wrote:
>
> 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.
>
> Specifically, I have RESTEasy maintain a map from servlet names to
> servlets, and the JAXRSForwarder is supplied with the appropriate servlet
> name. Btw, I tried to extract that information from undertow, successfully,
> but, as far as I could tell, it involved some messy digging.
>
> An alternative might be to automate turning a JAX-RS resource class into a
> gRPC proto file, and then automating the forwarding, but it doesn't seem
> feasible since JAX-RS has things like query method parameters and matrix
> method parameters, which, as far as I know, don't exist in gRPC.
>
>
>
>> 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.
>
> My example of building and calling the JAXRSForwarder was meant to be
> written by the application developer, with as much help as possible from
> RESTEasy.
>

This is the piece that is making me question if we need gRPC deployment
support first.

If an application developer is going to have to provide the forwarder
implementation it implies to me they will be deploying a service which
contains it.  So if that was the case would it be worth solving the
deployment of services issue first where we can consider the general
integration issues with the server and add support for the JAX-RS
forwarding to that.

> If forwarding to EJBs would work differently, then it seems reasonable for
> that code to look somewhat different. I.e., my comment about a general
> purpose Forwarder interface might make no sense.
>
>
>
>> 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/20200806/691316cf/attachment.html 