Re: [jakarta.ee-community] A Composable Platform Over Profiles

[Mrinal Kanti <mrinal.kanti@xxxxxxxxx>]

I think the proposed strategy should work well in most simple cases that involves deploying only an app or two. I see several challenges based on different scenarios:

Multiple app deployments: A typical application server instance in any large organization deploys multiple packages in its run-time. Different packages that are developed in-house by different teams may have different development life-cycles and without any strict version control regarding usage of underlying JEE specs they would definitely end up with conflicting dependencies sooner or later. At least in case of conflicting application libraries you have the option of loading them separately in distinct classloaders.

Third-party closed source packages: Several third-party vendors provide closed-source products which are packaged as deployable artifacts for their customers JEE runtime. A typical example is a rules engine packaged as WAR file. These products are typically certified on specific versions of app servers. And since they are closed source products they are not required to disclose the specific JEE technologies they require for functioning. They just specify the app server version they support. It is implicit that the app server supports full profile. How would you recommend composing the JEE runtime in such scenarios when these products are deployed alongside in-house developed packages? (Deploying those packages on separate app server instances can be ruled out due to server licensing cost constraints)

Product support environments: For argument's sake, lets assume that I am a product vendor and at any given time my product is supported on 3 different JEE versions based on implementations provided by 3 popular app servers. So I have a total of 9 different environments (combination of app server and their versions) to certify and support my product. Also assume that my product relies on 6 different JEE specs. A similar setup in a composable JEE runtime would result in 3^6=729 possible combinations of environments. Of course, this is based on the assumption that all 6 JEE specs would have been revised in each of the 3 JEE versions. Even if we depreciate that probability, the number of possible combination of environments is really impractical to certify and support. And I have only spoken about a single version of my product so far.

These is just a small list of possible scenarios that I could conjure up at 3 am here. I would suggest you to discuss this strategy with various solution implementors and product vendors that use your platform. They should be able to help you with more practical scenarios.

-Mrinal

On Tue, May 1, 2018 at 11:41 PM, 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-community