My comment on this is not based on the technical merit of the details of this specification rather than on the process.
When faced with a creation review should we be looking at the technical details of what is proposed at this stage and whether it does or does not map to each vendor’s implementation? Surely the
question at this stage is whether there is sufficient interest in creating a specification project with broad product and community input that can create an api, specification and TCK. I would assume the purpose of any specification project development before
ratification is to get to the point where the majority of these technical questions have been resolved.
If we insist on a fully formed api that has multi-party agreement at Creation Review then where does this work collaborative work occur? My assumption was that the purpose of a specification project
was to do this work at the Eclipse Foundation.
So my decision process in this is;
Are there multiple products trying to do this thing in their own way – yes in this case.
Would there be benefit to Jakarta EE developers to have a single api and therefore portability across the products – yes in this case.
Therefore in my mind the creation review should pass .
Passing creation review, in my view, is just the decision to collaborate on development work. To become a specification it has to pass the release review before which the technical details of the
approach and api should have been be thrashed out and broad consensus achieved.
Thanks
Steve
From: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx>
On Behalf Of Scott Stark
Sent: 23 November 2021 17:01
To: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec] Jakarta RPC Creation Review Comments...
This is a more detailed reply. This has been posted to the creation review page, but I'm not seeing comments show up there, so repeating it here.
The Red Hat gRPC from Quarkus has come up with the following annotated pros/cons lists:
Pros
·
Marshaller; Clearly a great point and very interesting. The usage of JSON (as in their example) is somewhat weird (remember, gRPC is intended to be “fast”
·
REST Client-Like Clients; That’s a very neat idea. Allows reducing the service surface and implement ambassadors (integration with MP Fault Tolerance) It may not be practical in the sense that the method name must exactly match
(which is not the case for the rest client as only the VERB + Path) must match.
·
Simplified Development model; It has always been a hurdle for gRPC (Java). It may require the user to write lots of message classes which could be automatically generated using protoc or similar tooling. Typically, the demo is
using Lombok… That does not sound right (maybe records can help).
Cons
·
Blocking first; gRPC is non-blocking by default. Making the experience blocking first is wrong. Typically, bi-directional streaming is not possible. How is the gRPC back-pressure implemented with such an approach?
·
No tooling; We can see that it looks attractive, but the IDL and tooling around gRPC is also the reason it’s working: clear contract definition, handle schema evolution. Sending unstructured text messages feels wrong. Most of
the time, it’s just because the tooling is not correctly integrated into the framework. In Quarkus, you drop the IDL, and you're done. No tooling.
·
Generic dispatching; The proposed approach will need dynamic dispatching at runtime. It will introduce a performance cost.
·
No implementation check; Nothing verifies that the implementation / client matches the IDL. It may introduce complex debugging, as name must exactly match (and proto method name <-> Java is NOT simple)
·
No gRPC metadata; The proposed development model does not allow custom gRPC fields or headers, which are often useful to pass metadata.
In summary, the approach is very interesting. It explores gRPC beyond the classical usage. At the moment, it feels that it still needs a lot of work to provide something relevant. In our opinion, this does not feel like gRPC, and
not like JAX-RS, something in-between and it would benefit the project to have a multi-vendor implementation prototype(s) to validate the direction the specification should take.
The concern Red Hat has is that the current proposal is exposing implementation choices that are not consistent with our implementation. Full support for protobuf for cross language support, streams/non-blocking
and security are some issues that have come up in the review so far. On the review I have requested additional time to be able to provide a more complete response.
In the meantime, choice in our implementation can be found here:
https://quarkus.io/guides/grpc-service-implementation
I'm certainly willing to help! My Eclipse username is: pnicolucci
I've just been able to review the spec proposal and the (great) presentation Aleksander gave - this is very promising. We implemented support for gRPC
in Open Liberty last year, although our current implementation does not provide the same features as Helidon or the spec proposal. "Eliminating the need for IDL/proto files and build-time code generation" in particular will be great for users.
As far as naming goes, +1 for "Jakarta API for gRPC Services" - I agree it should be made clear that this spec is for gRPC.
IBM WebSphere Development
----- Original message -----
From: "Aleksandar Seovic" <aleks.seovic@xxxxxxxxx>
Sent by: "jakarta.ee-spec" <jakarta.ee-spec-bounces@xxxxxxxxxxx>
To: jakarta.ee-spec@xxxxxxxxxxx
Cc:
Subject: [EXTERNAL] [jakarta.ee-spec] Jakarta RPC Creation Review Comments...
Date: Fri, Nov 12, 2021 1:24 AM
Hi,
I was just reviewing the material for this new Jakarta
RPC spec project proposaland I see that the Creation
Review processhas been initiated, with conclusion by Nov 24. We have several comments that I would like to ensure that our wider Spec Committee can participate on. (Providing
comments on the proposal itself or the creation review record seem to get "lost" and most people do not see them.)
First off, the overall content and direction of the Jakarta RPC project proposal seems sound. Creating a Specification based on the gRPC programming model is a good step forward. But, ...
·
The name of the project is confusing. I'm afraid it would be very easy to confuse Jakarta RPC with JAX RPC, and it's my understanding that this Spec is not a reincarnation
of JAX RPC. From the associated issue,
it seems that Jakarta gRPC is also not acceptable since "gRPC" is already trademarked. Since gRPC is based on "protocol buffers", maybe we should be more verbose and call it "Jakarta Protocol Buffering RPC" or "Jakarta pRPC", for short. Just an idea. But,
I think we need to do something other than "Jakarta RPC".
Mentioning Protocol Buffers explicitly is wrong, when one of the goals of the spec is to make it easier to use gRPC *without* ProtoBuf. gRPC itself
is marshaller agnostic, and allows you to specify a different marshaller (if you really want to) for the request and response payloads for every single method. It is in no way tied to ProtoBuf
at the architectural level.
What makes it tied to it at the moment is the tooling and the lack of documentation on how to support other formats. The spec we are proposing eliminates
the need for tooling, for the most part, and makes it very easy to support any serialization format.
However, that does leave us in a bit of a limbo when it comes to the name… The two latest proposals were "Jakarta RPC" and "Jakarta for gRPC", and
I guess Maria Teresa renamed the creation review issue to reflect the first option. I just posted a comment asking if a bit longer name of "Jakarta API for gRPC Services” would work, as I really see this spec as a gRPC equivalent of JAX-RS (Jakarta API for
RESTful Web Services), and was at one point even proposing JAX-gRPC. Unfortunately, trademarks, both Oracle’s and CNCF’s do not make this easy… :-(
I do agree though that Jakarta RPC does not make it obvious enough that this spec focuses on gRPC, and implies other RPC frameworks may or should be
supported, which is not where we want to go, imo.
·
·
The initial set of committers is too single vendor heavy. When we first created all of the Jakarta Specification Projects, we enlisted two reps from each strategic
member plus other interested parties for the initial set of committers. This helps diversify the community and provides some balance to the direction of the project. I'd like to see us go back to those roots and encourage/enlist participation by other strategic
members and limit the number of initial committers from any one organization. To that end, IBM would like to put forth two names to participate on this spec project -- Bill Lucy and Paul Niccoluci. (FYI, Bill would even be interested in co-leading the project,
if Aleksander is looking for any assistance.)
This is just a consequence of the fact that we are proposing something we’ve built as part of Helidon for standardization, so I only added the people
who have worked on the original design and implementation as committers.
I’m certainly happy (actually, hoping) to add contributors from other orgs, including Bill and Paul, and to have a chat with Bill to discuss whether
it makes sense to add him as a lead. Personally, I’m happy to share the burden, especially with someone who is likely more familiar with the Jakarta processes than I am, but I want to make sure we are in agreement at least at the high level, as once again,
what we are proposing is largely a derivative of something we’ve already built.
I would suggest that anyone interested watches the recording of the Jakarta Tech
Talk I did on Tuesday, and then we can have a more informed conversation on contributors, leads, etc. In the meantime, I’ll add both Bill and Paul to the proposal, under the assumption that they will still want to help, even after watching me for 50 minutes
or so ;-) I just need their Eclipse.org emails.
·
·
Once a diverse set of initial committers is identified, then the selection of the patent license could be determined. I know that Oracle took the initiative to create
this project proposal (thank you!) and they would prefer the CPL license, but once we get more participation from the wider pool, would CPL still be the desired patent license? With all of the initial participants coming from one organization, I think it
sways the selection of the patent license. As was done with the Config spec project, having an informal vote from the eventual diverse membership would produce a better view of the desired patent license.
I really have no comment on this one. I’ll leave it at that… ;-)
·
Thanks!
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
|
