Re: [jakarta.ee-community] About Profiles

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Just to expand on the MicroProfile correlation
a bit...

Each MicroProfile component specification
(ie. Config, Fault Tolerance, Rest Client, etc) is required to develop
a TCK.  Successfully passing the TCK indicates that a given implementation
is compatible with a given specification and version.

The umbrella MicroProfile specification
is a defined collection of component specification versions.  We currently
do not have any additional tests at the umbrella/platform level.  If
you want to claim compliance with MicroProfile 1.3, for example, your implementation
needs to pass the TCKs for all of the included component versions.

You can see our tracking of compliant
versions (both component and umbrella versions) here:  https://wiki.eclipse.org/MicroProfile/Implementation.
 We use the honor system.  If an implementation has stated they
have passed the TCK, they can update the wiki.  Other members of the
community could challenge, if they so desired.  So far, this has been
working out well.

As various people have pointed out,
we should aim to do something similar for Jakarta EE.  After CTS/TCK
re-factoring, we should have individual TCKs for each component of Jakarta
EE.  But, we also need to define collections of these components that
make sense and provide the rules for compliance.  Maybe in some cases,
it will be as easy as MicroProfile and it will just involve passing the
TCKs of the various components.  But, in other cases, maybe there
will be additional tests defined at the "platform" levels to
verify that these components work together in a cohesive manner.

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:      
 Ian Robinson <ian_robinson@xxxxxxxxxx>
To:      
 Jakarta EE community
discussions <jakarta.ee-community@xxxxxxxxxxx>
Date:      
 05/03/2018 07:49 AM
Subject:    
   Re: [jakarta.ee-community]
About Profiles
Sent by:    
   jakarta.ee-community-bounces@xxxxxxxxxxx

---

I agree there's a useful balance between
"composable everything" and "specific profiles" - and
with complementary goals. I also share the weariness that many of us experience
over continually pointing out that Java EE is not a monolithic technology
and that there are several highly composable implementations of the full
platform. We'd be in good shape if we aimed for an approach that enables
Jakarta EE providers to view the platform like a venn diagram of composable
technologies around which a small number of profile can be drawn for compliance
verification purposes. Whether and how much they overlap would be a detail
that can fill up our inboxes. But we don't need many. There are some good
practical reasons for a small number of profiles beyond pure a la carte
that have already be described including being able to certify technology
distributions to a minimum set of behaviours - without constraining how
much of other profiles is also included. Packaging and delivery has also
been mentioned - we need to make it simple to build and package an a la
carte app-centric solution but we have plenty of feedback from Liberty
users that starting with a "profile" that may be ultimately a
superset of needed capability can simplify the getting-started experience.
Some people just want prix fixe. 

The notion of a "cloud native" profile was one of the motivations
of MicroProfile. In MP we identified the most common features and biggest
gaps for microservice applications and set out a roadmap to build that
up over reasonable short-iteration releases of MicroProfile. MP 1.3, the
current release, has a core of CDI, JSON-P and JAX-RS and adds the set
of capabilities described in https://github.com/eclipse/microprofile-bom/releases/download/1.3/microprofile-spec-1.3.html
I hope what we're doing there will help some the Jakarta EE 9 thinking
(we agreed that versioning - right? :). 
If we have profiles we should expect to need to concretely describe them
with a version/release and for them to continue to grow from one release
to the next. In MP, we agreed some priorities and each release so far has
been the set of capabilities that were ready at the time we chose to bake
the release - each release building on the previous. Whether an approach
like this works for Jakarta EE remains to be seen but we've had some good
success with it. 

We'll need to modularize CTS regardless - but that will make profile compliance
simpler. I'd also expect to see profiles reflected in performance benchmarks
- a good (small) set of profile ought to be possible to apply to the design
of a benchmark workload. Although anyone who's been following the comedy
of getting a web profile of the SpecJEnterprise benchmark won't plan to
stay up to watch til the end of that. 


Regards, 
Ian Robinson 




From:        "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:        Jakarta
EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Date:        03/05/2018
12:26 
Subject:        Re:
[jakarta.ee-community] About Profiles 
Sent by:        jakarta.ee-community-bounces@xxxxxxxxxxx

---

For non-functionals practically profiles don't achieve a lot. For example
Payara Micro contains most of web profile + batch, concurrency apis, JCA
and JMS client and weighs in approx. 70MB jar and 30MB JVM heap usage and
boots in 2-3s without clustering. When we looked at shipping a pure microprofile
version we could perhaps shave 30-40% off some of those numbers but nothing
that made the effort super worthwhile.

However for compliance profiles help to enable vendors to ship a subset
of specs without having to implement everything. Therefore I agree with
Jason's view that it is compliance restrictions that likely need relaxing
with the ability to state levels of compliance. The tricky piece is relaxing
compliance while maintaining portability. My suggestion would be for max
3- 4 profiles. Something like; nucleus (very minimal core), web, legacy
free (full), Full whereby each is a superset of the previous. Then it is
up to vendors, if they so wish, to add mechanisms to layer additional specs
on each and compliance shouldn't be affected by adding additional specs.
So Full is naturally also nucleus, web and legacy free compliant as well.
 Also adding newer spec versions that are backwards compatible should
also maintain compliance as long as the previous CTS/TCK can still be passed.

One of the advantages of Java EE is that it is all there and the developer
doesn't have to worry about fiddling around building their own runtime.
Now I know a vocal number of developers do want to do this and other frameworks
push their marketing at these people. There are also a large number of
developers that don't care about assembling runtimes and just want to ship
business functionality as quick as possible. For them there are a number
of up-sides to the JavaEE model, portability, simplicity and let's not
forget security. Having a single versioned baseline runtime in production
is way simpler to patch than trying to work out which vulnerable libraries
are packaged up into a hand crafted executable Uber Jar. We need to market
confidently the benefits of the Jakarta EE model. Adam does a lot of that
well with his work on thin wars and their advantage for docker containers
etc. 

Steve

-----Original Message-----
From: jakarta.ee-community-bounces@xxxxxxxxxxx <jakarta.ee-community-bounces@xxxxxxxxxxx>
On Behalf Of Adam Bien
Sent: 03 May 2018 12:00
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] About Profiles

Marketing is great, but the purpose should be crystal clear. 
Otherwise we get more profiles than use cases.  IMO "no profiles"
with an ultra thin platform would be the best case. 

Profiles imply the core is bloated and therefore we need to split it in
order to improve non-functional requirements. 

> On 3. May 2018, at 12:56, reza_rahman <reza_rahman@xxxxxxxxx>
wrote:
> 
> I agree too many profiles can be confusing, but I do think we need
to have at least a few if not for any other reason than for marketing.
Adding a core and microservices profile makes total sense from that perspective.
To be completely honest, modularity is needed for similar reasons. Whether
or not it is a practical need, skeptics constantly beat up Java EE due
to the absence of modularity. 
> 
> We need to try and remove these weaknesses going forward if Jakatata
EE is to succeed. I know it's easier said than done, but leaving these
things as talking points competitors can exploit for negative marketing
undermines everything else we do. It's tiresome to lose real world adoption
opportunities not because of solid technical reasons, but because the technology
leaves itself vulnerable in terms of marketing.
> 
> Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
> 
> -------- Original message --------
> From: Adam Bien <abien@xxxxxxxxxxxxx>
> Date: 5/3/18 1:06 AM (GMT-05:00)
> To: Jakarta EE community discussions 
> <jakarta.ee-community@xxxxxxxxxxx>
> Subject: [jakarta.ee-community] About Profiles
> 
> 
> 
> 1. From the usability, dev experience, we should aim for as few profiles
as only possible. 
> My selling point for Java EE in the past was the simplicity. There
was only one choice -- the Full Profile -- (there were no measurable advantages
of WebProfile, so we never used that) what was appreciated by the developers.
There were no unique "snow lake" project in the past what was
good for long term maintenance and corporate developers self support. With
the "one dependency" idea, even startups used Java EE with the
"time to market" advantage. There was no evals or dependency
fiddling. We started with use case implementation at the day one. 
> 
> 2. From the runtime vendor perspective, modular platform is easier
to maintain, develop and is good for the ecosystem. So vendors should modularize
the Java EE platform as far as it is useful. However this should be an
internal implementation detail.
> 
> IMO we should have one "main profile" which comprises similar
functionality to the "full profile" in Java EE (of course without
SOAP :-)) which should cover the 80% of the main use cases. This profile
could be implemented as a BOM (micropofile does that, what is really convenient
to use).
> 
> Exceptional usecases (e.g. scenarios like NetFlix with 10k of microservice
instances) could be covered by specific profiles. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=Y1sWSS4p7eGed1403ZHNBmMI215CGcX95LG-hhcQUFk&m=N66GHLycAb5alhJxqET500w-CxDFd3BL2TY6hxQZMZo&s=XOiCSRRJLO4hDU-Ob8N5tECTalzXxeuqTZKUKerY7U4&e=
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=Y1sWSS4p7eGed1403ZHNBmMI215CGcX95LG-hhcQUFk&m=N66GHLycAb5alhJxqET500w-CxDFd3BL2TY6hxQZMZo&s=XOiCSRRJLO4hDU-Ob8N5tECTalzXxeuqTZKUKerY7U4&e=

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=Y1sWSS4p7eGed1403ZHNBmMI215CGcX95LG-hhcQUFk&m=N66GHLycAb5alhJxqET500w-CxDFd3BL2TY6hxQZMZo&s=XOiCSRRJLO4hDU-Ob8N5tECTalzXxeuqTZKUKerY7U4&e=
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=Y1sWSS4p7eGed1403ZHNBmMI215CGcX95LG-hhcQUFk&m=N66GHLycAb5alhJxqET500w-CxDFd3BL2TY6hxQZMZo&s=XOiCSRRJLO4hDU-Ob8N5tECTalzXxeuqTZKUKerY7U4&e=




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://urldefense.proofpoint.com/v2/url?u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dcommunity&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=DUr0xHp3qYY2LdMTQnpri2mtkWEUKLf8co-_EUAD3r8&s=dRK7Y2brM2M7UyXC3kl9T9L7hNClVJ5zxKPlXtQOzYA&e=