<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 8/6/20 5:18 AM, Darran Lofthouse
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMxVf4NVxfKdSzd30cLV7c4iEkCV4g2=sShbP5kfnS+BT-=0BA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Wed, Aug 5, 2020 at 10:16 PM Ron Sigal <<a
href="mailto:rsigal@redhat.com" moz-do-not-send="true">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><br>
</p>
<div>On 8/5/20 3:28 AM, Darran Lofthouse wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Wed, Aug 5, 2020 at 2:01 AM Ron
Sigal <<a href="mailto:rsigal@redhat.com"
target="_blank" moz-do-not-send="true">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>
<p>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.</p>
<p>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.<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<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>
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. </div>
</blockquote>
<div><br>
</div>
<div>This is the piece that is making me question if we need
gRPC deployment support first. </div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<p>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.</p>
<p>2. On the other hand, yes, I imagined a jaxrs deployer having to
identify the classes generated by gRPC. For example, GreeterGrpc
looks like</p>
<blockquote>
<p>@javax.annotation.Generated(<br>
value = "by gRPC proto compiler (version 1.30.2)",<br>
comments = "Source: helloworld.proto")<br>
public final class GreeterGrpc { ... }</p>
</blockquote>
<p>So that could be broken out into a separate gRPC module.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAMxVf4NVxfKdSzd30cLV7c4iEkCV4g2=sShbP5kfnS+BT-=0BA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>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.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<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>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><br>
</div>
<div>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" moz-do-not-send="true">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"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">wildfly-dev@lists.jboss.org</a><br>
<a
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">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" moz-do-not-send="true">wildfly-dev@lists.jboss.org</a><br>
<a
href="https://lists.jboss.org/mailman/listinfo/wildfly-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>