[wildfly-dev] gRPC in WildFly
Ron Sigal
rsigal at redhat.com
Thu Aug 6 19:51:56 EDT 2020
On 8/6/20 5:18 AM, Darran Lofthouse wrote:
> On Wed, Aug 5, 2020 at 10:16 PM Ron Sigal <rsigal at redhat.com
> <mailto: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
>> <mailto: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.
1. I'm not sure if this is at odds with what you're saying, but I was
thinking of JAXRSForwarderBuilder as an actual RESTEasy class with slots
for a variety of configuration parameters, e.g., name of servlet and
path mapper. But I do imagine the developer writing something simple
like GreeterGrpc.GreeterImplBase.sayHello() in the example.
2. On the other hand, yes, I imagined a jaxrs deployer having to
identify the classes generated by gRPC. For example, GreeterGrpc looks like
@javax.annotation.Generated(
value = "by gRPC proto compiler (version 1.30.2)",
comments = "Source: helloworld.proto")
public final class GreeterGrpc { ... }
So that could be broken out into a separate gRPC module.
>
> 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 <mailto: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
>>> <mailto: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 <mailto: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/f7d0c129/attachment-0001.html
More information about the wildfly-dev
mailing list