<div dir="ltr"><div dir="ltr">On Wed, Aug 5, 2020 at 2:01 AM Ron Sigal <<a href="mailto:rsigal@redhat.com">rsigal@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Brian,</p>
<p>Sorry for the late response. I've been on PTO.</p>
<p>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.</p>
<p>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.</p></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>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.</p></div></blockquote><div>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. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>Anyway, if anyone wants to talk about it, this thread might be a
good place to start.</p>
<p>-Ron<br>
</p>
<div>On 7/28/20 8:44 AM, Brian Stansberry
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div style="font-family:"trebuchet ms",sans-serif">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.</div>
<div style="font-family:"trebuchet ms",sans-serif"><br>
</div>
<div style="font-family:"trebuchet ms",sans-serif">This does feel like something that needs a
subsystem. I'm not sure I completely follow the <span style="color:rgb(0,0,0);font-family:Arial,Helvetica,sans-serif">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</span> concern of the jaxrs
subsystem, but providing the general gRPC infrastructure is
not a natural responsibility of the jaxrs subsystem.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jul 24, 2020 at 12:56
PM Ron Sigal <<a href="mailto:rsigal@redhat.com" target="_blank">rsigal@redhat.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>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 (<a href="https://github.com/wildfly/wildfly-proposals/pull/326" target="_blank">https://github.com/wildfly/wildfly-proposals/pull/326</a>)
for exposing JAX-RS resources as gRPC servers (<a href="https://issues.redhat.com/browse/WFLY-13530" target="_blank">https://issues.redhat.com/browse/WFLY-13530</a>).
Briefly, it would work as follows. Compiling the proto
file<br>
<br>
service Greeter {<br>
rpc SayHello (HelloRequest) returns (HelloReply) {}<br>
...<br>
}<br>
<br>
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:<br>
<br>
class GreeterImpl extends GreeterGrpc.GreeterImplBase {<br>
<br>
@Override<br>
public void sayHello(HelloRequest req,
StreamObserver<HelloReply responseObserver) {<br>
JAXRSForwarderBuilder builder = new
JAXRSForwarderBuilder();<br>
builder.servlet("ResteasyServlet").pathTranslator((String
s) -> ("test/" + s)); // Configure the JAXRSForwarder<br>
JAXRSForwarder forwarder = builder.build();<br>
forwarder.forward(req, (StreamObserver)
responseObserver);<br>
}<br>
}<br>
<br>
The gRPC infrasture would catch a request, dispatch it to
GreeterImpl, and the JAXRSForwarder would <br>
<br>
1. create an HttpServletRequest and an
HttpServletResponse<br>
2. find and invoke the appropriate RESTEasy servlet<br>
3. pass the result to the gRPC StreamObserver<br>
<br>
The idea is to hide the complexity behind the
JAXRSForwarder.<br>
<br>
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:<br>
<br>
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.<br>
<br>
2. Maybe there should be a separate gRPC subsystem.<br>
<br>
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.<br>
<br>
4. Darren has suggested that Elytron should be involved.<br>
<br>
In fact, I'm going to quote one of Darren's recent
remarks:<br>
<br>
</p>
<blockquote>
<blockquote type="cite">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.</blockquote>
</blockquote>
<p><br>
Any comments are welcome.<br>
</p>
</div>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">
<div dir="ltr">Brian Stansberry
<div>Manager, Senior Principal Software Engineer</div>
<div>Red Hat</div>
</div>
</div>
</blockquote>
</div>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote></div></div>