<div dir="ltr"><div dir="ltr">On Wed, Aug 5, 2020 at 10:16 PM Ron Sigal &lt;<a href="mailto:rsigal@redhat.com">rsigal@redhat.com</a>&gt; 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 &lt;<a href="mailto:rsigal@redhat.com" target="_blank">rsigal@redhat.com</a>&gt;
          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&#39;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&#39;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&#39;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&#39;t seem feasible since JAX-RS has things like query
      method parameters and matrix method parameters, which, as far as I
      know, don&#39;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&#39;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><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&#39;t had time to properly
                    digest this so I don&#39;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&#39;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 &lt;<a href="mailto:rsigal@redhat.com" target="_blank">rsigal@redhat.com</a>&gt;
                    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&lt;HelloReply responseObserver) {<br>
                              JAXRSForwarderBuilder builder = new
                        JAXRSForwarderBuilder();<br>
                             
                        builder.servlet(&quot;ResteasyServlet&quot;).pathTranslator((String
                        s) -&gt; (&quot;test/&quot; + 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&#39;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&#39;m going to quote one of Darren&#39;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&#39;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&#39;s
                          own subsystem which would mean it can be
                          defined in it&#39;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>
    </blockquote>
  </div>

</blockquote></div></div>