| Re: [jakarta.ee-community] A Composable Platform Over Profiles |
Werner
+1 Arjan. I've worked at a company that built products to run on any compliant application server, which allowed customers to run our products on whichever server they had in house and were most comfortable with. I've also worked at many companies and helped them transition their applications from one application server to another. This happens all the time. I've always enjoyed the stability and vendor neutrality of the EE platform, which made exercises like this very simple.On Tue, May 1, 2018 at 6:43 PM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:Hi,On Tue, May 1, 2018 at 9:24 PM, James Roper <james@xxxxxxxxxxxxx> wrote:How important are (or were) the portability aspects? Is switching app servers/vendors something that is common to do for Java EE deployments? In my experience it's not, the ability to switch vendors is a perceived value for many users, but one that never actually gets exercised in practice, however my experience may not be representative.There's a few situations. One are applications that actually are designed to run on multiple if not all EE servers. The OmniFaces showcase is such an example. The Java EE KickOff application an other: https://github.com/javaeekickoff/java-ee-kickoff-app You really don't want to do a JBoss-KickOff, Payara-KickOff, TomEE-KickOff, etc.Closely related to the kickoff example app are the project templates used by consultancy/contracting firms. These are white labeled projects with functionality for logging-in, creating users, creating pages with a certain layout, default services for a number of things etc.This allows those firms to quickly get up to speed with new Greenfield development for various customers.In some cases the customer doesn't care about the EE implementation used, in some case they do. It's for the latter case that you want servers to be as compatible as possible and support all the various EE APIs, as those templates often touch every API.Coming back to your original comment; you don't just switch vendors om a whim for most serious projects, but a vendor can simply stop. In one company I worked we were based on Orion (yes, it's a long time ago ;)), and Orion at some point stopped after having been bought over by Oracle. So the code had to be migrated to something else. Same thing with an application coded against Geronimo. Geronimo just silently and without notice stopped at some point. TomEE was the obvious choice to migrate too, but they didn't support JACC, which was a real issue.Another thing to keep in mind regarding the profiles and subsets of specs, is that people quite often say they only need Tomcat to run on, but as the project grows a persistence solution is added, which necessitates a transaction manager, and then a bean validation solution, and then of course a DI product, etc etc. And before you know it there's basically all the EE libs in WEB-INF/lib.So yes, people like to say that they only need Servlet, but in practice they rarely do. All WebProfile implementations are also actually WebProfile+, where the + means they are almost full EE, just missing a few small things. This is maybe telling as well.Kind regards,Arjan TijmsHowever, there is another aspect to portability, and that's third party (eg open source) libraries and technology building on Java EE - the fact that a single library can run on many different vendors implementations is highly valuable and probably one of the biggest contributors to Java EE's success. That said, there's not a lot of cases that I've seen where open source libraries that depend on Java EE depend on the whole of Java EE, they tend to depend on a limited subset of specs. This I think would be generally compatible with a composable palette approach to Jakarta EE, as you suggest. There's certainly some scenarios where there may be problems, but in practice I would expect those to be rare and manageable.Another major goal and advantage of Jakarta EE, as I see, is portability of developer skillsets, which enables companies to select a particular implementation, but be able to hire skilled developers from a much larger pool of experience over many implementations. A composable palette approach doesn't impede this goal at all.I'm certainly for this direction.--On Wed, 2 May 2018 at 04:11, Jason Greene <jason.greene@xxxxxxxxxx> wrote:Over the years there has been vigorous debate about what makes the perfect profile. “Should spec X be included or not?” “Should we create a “plus” variant of the web profile?" “How many profiles is too many?" “How many is too few?" Recent threads you can see the topic rising again with Stable and Legacy profile proposals, and debate about whether or not JAX-WS should be part of the platform.
A related issue is that EE compliance is overly strict. An implementor must ship exactly what a profile defines, with limited exceptions on variation. As an example, a certified web or full implementation can’t ship a newer version of the Servlet API, even though it’s fully backwards compatible. The default run mode / config of the implementation is also not allowed to enable a subset of the profile, even though the implementor’s primary audience may not need all of the specified technologies.
The idea behind a rigid platform certainly had merit, and it arguably led to the very strong level of portability across containers we enjoy today. However, this one-size-fits-all approach just no longer fits the current state of software, with developers expecting a high degree of application specific tailoring.
I argue that a better approach would be to define the platform as a palette of composable standards[1], where profiles define only what must be available for a developer to choose from, and only limit the version of a given standard to the minimum that must be provided[2]. Under this model there is less of a need to define a perfect profile, since it can be freely adjusted by the developer to fit his or her needs. Instead, all that matters is that we have a sensible array of choice.
[1] It’s worth noting that this would require the TCK to be split up, as discussed previously, to facilitate the flexibility required in testing a near arbitrary combination of standards.
[2] For clarity, the full and web profiles would still be versioned (8.0 etc) as today, this is just a rule softening to support variation.
--
Jason T. Greene
Chief Architect, JBoss EAP
Red Hat
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-communit y
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee- community