Do we need a REST Client in MP, now REST is at EE4J?

62 views
Skip to first unread message

Werner Keil

unread,
Nov 27, 2017, 5:38:43 PM11/27/17
to Eclipse MicroProfile
Hi,

As the first concrete projects take shape at EE4J, especially REST (https://projects.eclipse.org/proposals/eclipse-restful-web-services-api-java) being one of them, is there really a need to develop the "glue" which so far exists in the "MicroProfile Rest Client" outside the actual REST project rather than contributing it to the actual REST project?

A vast majority of MicroProfile efforts build around Microservice Patterns like http://microservices.io/patterns/index.html, but there is no such pattern as "Typesafe Rest Client". It is mostly wrappers around JAX-RS and things that may be missing from JAX-RS till Java EE 8, which is why it feels more natural to propose and contribute it there, rather than separately and isolated now that this project is also at Eclipse and https://projects.eclipse.org/projects/ee4j/charter explicitly states, MicroProfile is such a project that EE4J will review as a source of innovations for incorporation into EE4J. 

I'll also talk to the Java EE/EE4J and MicroProfile reps at JVM-Con tomorrow.

What do others think in the meantime?

Werner

John D. Ament

unread,
Nov 27, 2017, 5:46:45 PM11/27/17
to Eclipse MicroProfile
Definitely.

Werner Keil

unread,
Nov 27, 2017, 5:57:16 PM11/27/17
to Eclipse MicroProfile
Can you elaborate?

What prevents any of these improvements or needs from being part of the future REST API?
CDI-integration, that is done everywhere. Some more, others less, but especially what was stopped in JMS 2.1 was proposed for at least two of the other new EE4J projects. 

It was discussed in this list, but will be done under EE4J now.

John D. Ament

unread,
Nov 27, 2017, 6:02:17 PM11/27/17
to Eclipse MicroProfile


On Monday, November 27, 2017 at 5:57:16 PM UTC-5, Werner Keil wrote:
Can you elaborate?

What prevents any of these improvements or needs from being part of the future REST API?
CDI-integration, that is done everywhere. Some more, others less, but especially what was stopped in JMS 2.1 was proposed for at least two of the other new EE4J projects. 

It was discussed in this list, but will be done under EE4J now.

What was discussed on this list, but will be done under EE4J now?

m.reza.rahman

unread,
Nov 27, 2017, 7:29:48 PM11/27/17
to microp...@googlegroups.com
I agree this could eventually wind up in the EE4J version of JAX-RS, but it should continue here for two important reasons:

* In all reality it will take a while before anything usable comes out of EE4J.
* The JAX-RS.next EG may not agree that this needs to be standardized. Let's remember - loose coupling is a big part of the dogmatic side of REST.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Werner Keil <werne...@gmail.com>
Date: 11/27/17 5:38 PM (GMT-05:00)
To: Eclipse MicroProfile <microp...@googlegroups.com>
Subject: [microprofile] Do we need a REST Client in MP, now REST is at EE4J?

Hi,

As the first concrete projects take shape at EE4J, especially REST (https://projects.eclipse.org/proposals/eclipse-restful-web-services-api-java) being one of them, is there really a need to develop the "glue" which so far exists in the "MicroProfile Rest Client" outside the actual REST project rather than contributing it to the actual REST project?

A vast majority of MicroProfile efforts build around Microservice Patterns like http://microservices.io/patterns/index.html, but there is no such pattern as "Typesafe Rest Client". It is mostly wrappers around JAX-RS and things that may be missing from JAX-RS till Java EE 8, which is why it feels more natural to propose and contribute it there, rather than separately and isolated now that this project is also at Eclipse and https://projects.eclipse.org/projects/ee4j/charter explicitly states, MicroProfile is such a project that EE4J will review as a source of innovations for incorporation into EE4J. 

I'll also talk to the Java EE/EE4J and MicroProfile reps at JVM-Con tomorrow.

What do others think in the meantime?

Werner

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e9b5d7e0-70ac-4b11-84c3-2652f164a639%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ken Finnigan

unread,
Nov 27, 2017, 7:42:23 PM11/27/17
to MicroProfile
+1, this is what I was going to say about it as well.

It's important to remember that MicroProfile was founded on the principle of moving faster than Java EE. If we stop innovating because "we might be able to get X added to an existing Java EE spec", that would be a huge disappointment to our community, and also significantly prolong when an innovation is available for anyone to use.

Quite apart from the discussion that what we do with a spec may not be appropriate or agreed upon by an EG for inclusion.

Werner, with respect to your comment about talking with some representatives at JVM-Con tomorrow, I hope you weren't implying that this thread was a secondary aspect to you speaking with people directly? While in person communication is always more efficient and beneficial, for the community as a whole to continue to thrive we mustn't foster side discussions as a focus.

Ken

On Mon, Nov 27, 2017 at 7:29 PM, m.reza.rahman <m.reza...@gmail.com> wrote:
I agree this could eventually wind up in the EE4J version of JAX-RS, but it should continue here for two important reasons:

* In all reality it will take a while before anything usable comes out of EE4J.
* The JAX-RS.next EG may not agree that this needs to be standardized. Let's remember - loose coupling is a big part of the dogmatic side of REST.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Werner Keil <werne...@gmail.com>
Date: 11/27/17 5:38 PM (GMT-05:00)
To: Eclipse MicroProfile <microp...@googlegroups.com>
Subject: [microprofile] Do we need a REST Client in MP, now REST is at EE4J?

Hi,

As the first concrete projects take shape at EE4J, especially REST (https://projects.eclipse.org/proposals/eclipse-restful-web-services-api-java) being one of them, is there really a need to develop the "glue" which so far exists in the "MicroProfile Rest Client" outside the actual REST project rather than contributing it to the actual REST project?

A vast majority of MicroProfile efforts build around Microservice Patterns like http://microservices.io/patterns/index.html, but there is no such pattern as "Typesafe Rest Client". It is mostly wrappers around JAX-RS and things that may be missing from JAX-RS till Java EE 8, which is why it feels more natural to propose and contribute it there, rather than separately and isolated now that this project is also at Eclipse and https://projects.eclipse.org/projects/ee4j/charter explicitly states, MicroProfile is such a project that EE4J will review as a source of innovations for incorporation into EE4J. 

I'll also talk to the Java EE/EE4J and MicroProfile reps at JVM-Con tomorrow.

What do others think in the meantime?

Werner

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/5a1cadf7.e639ed0a.52119.9ce4%40mx.google.com.

Alasdair Nottingham

unread,
Nov 27, 2017, 8:05:52 PM11/27/17
to microp...@googlegroups.com
+1 to continuing to do the work here. 

Alasdair Nottingham
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

Mike Croft

unread,
Nov 28, 2017, 6:47:22 AM11/28/17
to Eclipse MicroProfile
A vast majority of MicroProfile efforts build around Microservice Patterns like http://microservices.io/patterns/index.html, but there is no such pattern as "Typesafe Rest Client". 

I don't think this is a particularly good argument against any given spec. There has never been any suggestion that those patterns have any influence over MicroProfile or the reasoning behind creating one. 

John D. Ament

unread,
Nov 28, 2017, 9:33:38 AM11/28/17
to Eclipse MicroProfile


On Tuesday, November 28, 2017 at 6:47:22 AM UTC-5, Mike Croft wrote:
A vast majority of MicroProfile efforts build around Microservice Patterns like http://microservices.io/patterns/index.html, but there is no such pattern as "Typesafe Rest Client". 

I don't think this is a particularly good argument against any given spec. There has never been any suggestion that those patterns have any influence over MicroProfile or the reasoning behind creating one. 


And in all actuality, multiple patterns listed there are covered by MP Rest Client:

- Client Side Service Discovery
- Remote Procedure Invocation
- API Gateway
- Backend for Front end

Werner Keil

unread,
Nov 28, 2017, 10:52:32 AM11/28/17
to Eclipse MicroProfile
Hi

I asked Ivar, if he ever heard about this part of MicroProfile. He has not seen it in detail. The closest equivalent (also featured by another JVM-Con Speaker right now;-) would be Spring RestTemplate. 

The whole argument of "We want to be faster than Java EE" is not going to work for much longer although the EE4J umbrella project and PMC have not yet presented a schedule or plans for releasing in particular intervals, but with some being involved in both projects putting your "MicroProfile hat" on and saying "I am so fast" and then putting the "EE4J hat" on saying "I am slow" does feel a little odd. Duplication of effort will certainly slow down both of them and should be avoided if possible.

Werner


On Tuesday, November 28, 2017 at 1:42:23 AM UTC+1, Ken Finnigan wrote:
+1, this is what I was going to say about it as well.

It's important to remember that MicroProfile was founded on the principle of moving faster than Java EE. If we stop innovating because "we might be able to get X added to an existing Java EE spec", that would be a huge disappointment to our community, and also significantly prolong when an innovation is available for anyone to use.

Quite apart from the discussion that what we do with a spec may not be appropriate or agreed upon by an EG for inclusion.

Werner, with respect to your comment about talking with some representatives at JVM-Con tomorrow, I hope you weren't implying that this thread was a secondary aspect to you speaking with people directly? While in person communication is always more efficient and beneficial, for the community as a whole to continue to thrive we mustn't foster side discussions as a focus.

Ken
On Mon, Nov 27, 2017 at 7:29 PM, m.reza.rahman <m.reza...@gmail.com> wrote:
I agree this could eventually wind up in the EE4J version of JAX-RS, but it should continue here for two important reasons:

* In all reality it will take a while before anything usable comes out of EE4J.
* The JAX-RS.next EG may not agree that this needs to be standardized. Let's remember - loose coupling is a big part of the dogmatic side of REST.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

-------- Original message --------
From: Werner Keil <werne...@gmail.com>
Date: 11/27/17 5:38 PM (GMT-05:00)
To: Eclipse MicroProfile <microp...@googlegroups.com>
Subject: [microprofile] Do we need a REST Client in MP, now REST is at EE4J?

Hi,

As the first concrete projects take shape at EE4J, especially REST (https://projects.eclipse.org/proposals/eclipse-restful-web-services-api-java) being one of them, is there really a need to develop the "glue" which so far exists in the "MicroProfile Rest Client" outside the actual REST project rather than contributing it to the actual REST project?

A vast majority of MicroProfile efforts build around Microservice Patterns like http://microservices.io/patterns/index.html, but there is no such pattern as "Typesafe Rest Client". It is mostly wrappers around JAX-RS and things that may be missing from JAX-RS till Java EE 8, which is why it feels more natural to propose and contribute it there, rather than separately and isolated now that this project is also at Eclipse and https://projects.eclipse.org/projects/ee4j/charter explicitly states, MicroProfile is such a project that EE4J will review as a source of innovations for incorporation into EE4J. 

I'll also talk to the Java EE/EE4J and MicroProfile reps at JVM-Con tomorrow.

What do others think in the meantime?

Werner

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

Ken Finnigan

unread,
Nov 28, 2017, 10:55:22 AM11/28/17
to MicroProfile
I can understand your point Werner, but right now EE4J is progressing with its move to Eclipse, but in terms of standards its completely stopped.

Until such time as standards are being developed and released, we have no yardstick to determine the speed of EE4J.

So right now, MicroProfile is very much moving a great deal faster than EE4J/Java EE.

Ken

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/15d6f263-5fa6-4553-8824-fb3d14be6de7%40googlegroups.com.

Werner Keil

unread,
Nov 28, 2017, 10:56:11 AM11/28/17
to Eclipse MicroProfile
The slides should be available at some point, but for 7 of the most common patterns, Ivar used exactly those patterns and demonstrated how MicroProfile is one manifestation of these patterns: http://jvm-con.de/a-collection-of-microservice-patterns/

Werner Keil

unread,
Nov 28, 2017, 11:06:29 AM11/28/17
to Eclipse MicroProfile
As long as it does not lead to circular dependencies (EE4J using MicroProfile using EE4J using MicroProfile...) there's no problem experimenting with things. 
APIs will not stop, but if there's ever going to be a standard defined as such by ISO, IETF or Ecma (just to name 3 plausible organizations that do this for languages or data) or similar to Spring the Eclipse APIs stand as de-facto-standards, I guess that is not clear at this point.

Werner

John D. Ament

unread,
Nov 28, 2017, 1:09:08 PM11/28/17
to Eclipse MicroProfile
Why would circular dependencies be an issue?  I actually suspect a huge success of both projects would be the inclusion of a MP Spec directly in an EE4J project.

John

Guillermo González de Agüero

unread,
Nov 28, 2017, 1:40:03 PM11/28/17
to microp...@googlegroups.com
With EE4J, you mean "Eclipse Java EE" in that case, right?

My only concern there would be package chaning names (or having inconsist package names depending on wether the spec was a "Java EE" or a Microprofile one).

Werner Keil

unread,
Nov 29, 2017, 5:46:28 AM11/29/17
to Eclipse MicroProfile
If EE4J aims at true standardization, that's not going to happen. Did OpenJDK include JodaTime directly?;-) Or the Batch JSR SpringBatch. No, they all may have influenced those standards, some like java.time are even pretty much a fork of JodaTime, but neither of them use something from an Open Source project how ever popular it may be.

If EE4J was to follow the Spring-like path that MicroProfile uses, where "Mix & Match" is possible e.g. directly using other frameworks by Netflix, Dropwizard, Spring/Pivotal or what suits your needs, then it would be possible.

Werner

Emily Jiang

unread,
Nov 29, 2017, 6:11:06 AM11/29/17
to Eclipse MicroProfile
+1 on keeping on moving!

Once we release it and then can be included by EE4J (as mentioned by John). Therefore, there is no duplication. When this specification is pushed forward for being standardised, it will be just package name changes, which is not a big issue, as we have done so in Config JSR, derived from MP Config.

In my view, the relationship between MicroProfile and EE4J is complimentary not defeating/replacing each other. One important message is that MP must not stop and wait. MP is an innovative community and stays nimble. We should keep this way to be successful.

Thanks
Emily
Reply all
Reply to author
Forward
0 new messages