On Wed, Aug 5, 2020 at 2:01 AM Ron Sigal <rsigal(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev