| Re: [ee4j-community] Charter Feedback |
Good points, Reza and John.Most important points I agree with:- using application runtimes instead of application servers- it's a more flexible term and many Java EE implementations aren't traditional servers anymore- cloud-native or cloud-ready instead of just microservices- at some point we'll need to address serverless and FAAS and I believe Java EE has a potential to be used there too- target on both standalone, in-container and later possibly FAAS environments- CDI 2.0 already does that, with a core spec and additions for Java SE and EE and it's brilliant and easy to follow- Java SE version shouldn't, however, contain anything that can be provided by another API from the umbrella, for example, it shouldn't provide its own DI mechanism if it's provided by CDI, or at most a very simplistic one based on Java SE or EE standards--Ondro2017-10-07 7:24 GMT+02:00 John Clingan <jclingan@xxxxxxxxxx>:Reza, good points. Comments below.On Oct 3, 2017, at 6:19 PM, Martijn Verburg <martijnverburg@xxxxxxxxx> wrote:Hi Reza,My 2c on thisOn 3 October 2017 at 18:04, <reza_rahman@xxxxxxxxx> wrote:As promised, I went through the charter in detail and have the feedback below. Items are roughly in priority order. I will try to encourage others to also provide feedback. Please let me know if it is best to split up into separate threads. Please also let me know if anything needs further clarification. I really hope this helps.
* The charter fairly clearly targets application servers. Personally I certainly value the application server model. However, I think at this point it is clear developers also value being able to utilize the Java EE programming model in embeddable, modular, compose-able run-times (aka fat jars). I think it is best to remove references to application servers and simply say something like run-times for server-side Java applications. I think the reality is that most EE4J implementations will support both models. I can even see implementations that provide no support for the application server deployment model.
Completely agree, there are perhaps even APIs / Specs that we develop which would run serverless so to speak.Thanks for bringing this up in the “Opening Up Java EE” panel as well. Everyone agreed with this during the session.* I think it is important to point out that most of the time (of not all of the time) APIs and technologies under the EE4J umbrella are expected to run standalone in Java SE environments. This is one of the continuing source of criticism for the current Java EE model. While most Java EE APIs are essentially standalone, the platform specification text says nothing about this. In the same vein, I think it is wise to make some reference to modularity even in integrated run-times.
I do like “standalone on Java SE" as a "guiding principle”. It will facilitate broad adoption of EE4J technologies, not to mention other pragmatic reasons (easier testing, etc).* I see references to micro-services, which is good. I think we should also make a point to reference the cloud. While it is implicitly understood that server-side can mean the cloud, I think specifically mentioning the cloud in the charter has value. I can envision run-times that are completely cloud native (e.g. Functions as a Service) that do not support the on-premises model at all. It may actually be handy to have cloud native in the text somewhere.
I prefer we simply replace “microservices” with “cloud native”, which is a broader, more abstract conceptual description that encompasses both FaaS and microservices. Oddly, “server side” is more broad that “cloud native”, and encompasses both traditional on-premise and cloud native architectures :-) However, I agree that referring to the cloud is a good balance.Good call - the ecosystem at large needs to know that Java can be a cloud native platform, EE4J could make a strong statement here.* I think its smart to say *modern* server-side Java applications instead of just server-side Java applications.
+1The definition of “Modern" changes on a monthly basis - by definition. Adding this future-proofs EE4J! :-) I actually think that using “cloud native” as discussed above covers this point.______________________________
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-community
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j- community